#219 - Triết lí Unix trong Apache Kafka và Samza

Để các hệ thống ở control plan như scheduler hay resource broker hoạt động hiệu quả, bền vững và nhanh chóng thì các hệ thống này cần phải sử dụng một hệ thống storage với đầy đủ các tính chất trên. Vào năm 2019, các đội ngũ kỹ sư ở Facebook đã công bố Delos, một hệ thống storage được thiết kế riêng cho các hệ thống ở tầng control plan. Trước khi Delos ra đời thì họ đã sử dụng Zookeeper cho phần control plan storage. Tuy nhiên, với việc Zookeeper chỉ đáp ứng được một số APIs nhất định, đi theo hướng monolithic và các chỉ số về hiệu suất và độ bền vững nhất định, các đội ngũ kỹ sư ở Facebook nhận ra rằng họ khó có thể đáp ứng được mọi yêu cầu từ các hệ thống ở control plane.

Do đó, Delos được sinh ra để giúp việc mở rộng hệ thống control plane storage một cách dễ dàng hơn bằng việc tách riêng các thành phần như là APIs, ordering, log, … Do việc tách riêng các thành phần này ra, họ có thể dễ dàng thay thế các bộ phận với nhiều công nghệ khác nhau để đáp ứng được các yêu cầu ở nhiều hệ thống control plane khác nhau. Để hiểu rõ hơn về cách đội ngũ kỹ sư ở Facebook đã thiết kế và áp dụng Delos như thế nào, các bạn có thể tham khảo qua bài viết sau.

Phát triển phần mềm thời hiện đại vẫn còn rất nhiều điều để học từ những năm 1970, một trong số đó là triết lí Unix. Chúng ta có thể làm được vô vàn khả năng chỉ với vài sự kết hợp của các lệnh awk, sed, grep, sort, uniq và xargs trong hệ điều hành Unix. Điều này không hề là ngẫu nhiên, đó là kết quả trực tiếp từ triết lí thiết kế của Unix:

Những nguyên tắc này là nền tảng cho việc kết hợp (compose) các chương trình lại với nhau để thực hiện một công việc phức tạp, thông qua pipe ( “|”). Ý tưởng chính ở đây là một chương trình không biết hoặc không quan tâm đầu vào của nó đến từ đâu hoặc đầu ra của nó sẽ đến đâu: nó có thể là một file hoặc một chương trình khác thuộc hệ điều hành hoàn toàn khác.

Trong thực tế, Kafka thực chất có rất nhiều điểm tương đồng với pipe trong Unix, liên kết đầu ra của một tiến trình với đầu vào của một tiến trình khác. Và Samza giống như một thư viện giúp bạn đọc từ đầu vào và viết vào đầu ra. Sử dụng Kafka và Samza, bạn có thể lập trình với phong cách xử lí luồng (stream-processing) giống với phong cách Unix truyền thống, gồm các tool nhỏ và có khả năng kết hợp (composable)

Các nguyên tắc thiết kế giống Unix của Kafka cho phép xây dựng các hệ thống phức tạp ở quy mô lớn. Trong một tổ chức lớn, Kafka giúp mỗi team có thể độc lập phát triển các công việc xử lí luồng (steam-processing job), consume từ một luồng và publish sang luồng mới. Các luồng dữ liệu trong Kafka đóng vai trò là kênh giao tiếp giữa các hệ thống của các team khác nhau. Mỗi team tập trung giúp hệ thống của họ làm tốt một việc duy nhất.

Giống như các tool trong Unix có thể được kết hợp với nhau để hoàn thành một nhiệm vụ cụ thể, các hệ thống phân tán này được kết hợp với nhau, điều hành toàn bộ hoạt động của cả tổ chức lớn. Nhờ tính loose-coupling, các thành phần riêng lẻ có thể được phát triển và deploy hoàn toàn độc lập. Nhờ khả năng chịu lỗi và buffering của Kafka, khi có lỗi xảy ra ở một phần của hệ thống, nó sẽ được khoanh vùng và tách biệt. Các tổ chức này giúp mỗi team có thể phát triển nhanh chóng mà không sợ ảnh hưởng hay gián đoạn các team khác.

Trong bài viết, tác giả có miêu tả chi tiết triết lí Unix, sự khác biệt trong thiết kế database so với Unix, so sánh và nêu những điểm lợi của Kafka so với Unix pipe, và nhiều ví dụ thực tế. Mời các bạn cùng đọc.

Khi một dịch vụ được triển khai, chúng ta sẽ muốn biết dịch vụ đó đang hoạt động như thế nào, bao nhiêu request mỗi giây, mức độ sử dụng tài nguyên v.v… Ngoài ra chúng ta cũng muốn nhận được những thông báo nếu có sự cố xảy ra như một service instance bị lỗi, hay ổ cứng hết dung lượng v.v.. Một cách lý tưởng nhất là nhận được thông báo trước khi nó gây tác động tới người dùng.

Do đó chúng ta cần triển khai một số pattern để giúp quản lý các service cũng như khắc phục sự cố một cách dễ dàng hơn. Một số pattern phổ biến hiện nay như: Log aggregation, Health check API, Distributed tracing, v.v…

Mời các bạn đọc bài viết sau để tìm hiểu kỹ hơn về các pattern này.

Trong các kỳ newsletter trước mục Góc Database đã giới thiệu cho các bạn về CAP theorem. Mặc dù CAP theorem đang được vận dụng khá rộng rãi trong các dòng distributed database hiện đại, nhiều người vẫn cảm thấy bản thân lý thuyết này vẫn có một vài khuyết điểm như:

Đến với góc Database kỳ này, mời các bạn cùng tham khảo bài báo của tác giả Daniel J. Abadi xuất bản năm 2012 chia sẻ về một PACELC, một phiên bản mở rộng từ CAP theorem trong đó cân nhắc đến nhiều yếu tố hơn.