1. Mở đầu

Đơn vị lưu trữ cơ bản của Kafka là partition replicas. Partittion không thể được tách nhỏ và lưu trữ giữa nhiều broker, và cũng không thể được tách nhỏ và lưu trữ trên nhiều ổ đĩa khác nhau trên cùng một broker. Do đó, kích thước của partition bị giới hạn bởi dung lượng có sẵn trên một mount point duy nhất.

Khi cấu hình Kafka, chúng ta sẽ định nghĩa một danh sách các thư mục nơi các partition sẽ được lưu trữ — đây là tham số log.dirs (không nên nhầm lẫn với vị trí mà Kafka lưu trữ log lỗi của nó, được cấu hình trong tệp log4j.properties). Cấu hình thông thường bao gồm một thư mục cho mỗi mount point mà Kafka sẽ sử dụng.

Vào cuối năm 2018, cộng đồng Apache Kafka bắt đầu hợp tác trong một dự án đầy tham vọng nhằm bổ sung thêm giải pháp lưu trữ phân tầng (tiered storage) cho Kafka. Công việc trên dự án này vẫn đang tiếp diễn và dự kiến sẽ được phát hành trong phiên bản 3.0.

Động lực cho dự án này khá rõ ràng: Kafka hiện đang được sử dụng để lưu trữ một lượng lớn dữ liệu, hoặc do thông lượng cao hoặc thời gian duy trì dữ liệu lâu dài. Những điều này gây ra các mối quan ngại, lo lắng sau:

• Chúng ta sẽ bị giới hạn về lượng dữ liệu có thể lưu trữ trong một partition. Kết quả là, thời gian duy trì tối đa và số lượng partition không chỉ phụ thuộc vào yêu cầu của sản phẩm mà còn bởi các giới hạn về kích thước ổ cứng vật lý.
• Lựa chọn về ổ cứng và kích thước cluster của chúng ta phụ thuộc vào yêu cầu lưu trữ. Các cluster thường lớn hơn cần thiết nếu độ trễ và thông lượng là yếu tố chính, điều này làm tăng chi phí.
• Thời gian di chuyển các partition từ broker này sang broker khác, chẳng hạn khi mở rộng hoặc thu hẹp cluster, bị ảnh hưởng bởi kích thước của các phân vùng. Phân vùng lớn làm cho cluster ít linh hoạt hơn. Ngày nay, các kiến trúc thường hướng đến độ linh hoạt tối đa, tận dụng các tùy chọn triển khai linh hoạt trên cloud.

2. Giải pháp lưu trữ

Trong cách tiếp cận lưu trữ phân tầng, Kafka Cluster được cấu hình với hai tầng lưu trữ: cục bộ (local tier) và từ xa (remote tier). Local tier sẽ giống như tầng lưu trữ hiện tại của Kafka—sử dụng các ổ cứng trên các broker của Kafka để lưu trữ các đoạn log. Remote tier mới sẽ sử dụng các hệ thống lưu trữ chuyên dụng, chẳng hạn như HDFS hoặc S3, để lưu trữ các đoạn log đã hoàn tất.

Người dùng Kafka có thể chọn thiết lập chính sách lưu trữ riêng biệt cho mỗi tầng. Vì local storage thường đắt đỏ hơn nhiều so với remote tier, nên thời gian lưu trữ cho local tier thường chỉ kéo dài vài giờ hoặc thậm chí ngắn hơn, trong khi thời gian lưu trữ cho remote tier có thể lâu hơn nhiều—vài ngày hoặc thậm chí vài tháng.

Local storage có độ trễ thấp hơn đáng kể so với remote storage, rất hiệu quả đối với các ứng dụng nhạy cảm với độ trễ. Các ứng dụng khôi phục từ sự cố hoặc các ứng dụng cần dữ liệu cũ hơn dữ liệu trong local tier sẽ được trích xuất từ remote tier.

Kiến trúc hai tầng lưu trữ trong phương pháp lưu trữ phân tầng cho phép mở rộng lưu trữ mà không phụ thuộc vào bộ nhớ và CPU trong cụm Kafka. Điều này giúp Kafka trở thành giải pháp lưu trữ lâu dài. Hơn nữa, nó có tác dụng giảm lượng dữ liệu lưu trữ cục bộ trên các broker Kafka, từ đó giảm lượng dữ liệu cần sao chép trong quá trình phục hồi và cân bằng lại. Các phân đoạn log (Log segments) luôn sẵn sàng trong remote tier nên không cần phải phục hồi trên broker hoặc phục hồi một cách chậm chạp và được trích xuất trực tiếp từ remote tier. Vì không phải tất cả dữ liệu đều lưu trữ trên các broker, việc gia tăng thời gian lưu trữ dữ liệu không còn cần thiết mở rộng dung lượng lưu trữ của cụm Kafka và thêm các nút mới. Thời gian lưu trữ dữ liệu tổng thể vẫn có thể kéo dài hơn nhiều, loại bỏ nhu cầu về các quy trình dữ liệu riêng biệt để sao chép dữ liệu từ Kafka sang các kho lưu trữ bên ngoài, như hiện tại đang được thực hiện trong nhiều cách triển khai.

Thiết kế của lưu trữ phân tầng được tài liệu hóa chi tiết trong KIP-405, bao gồm một thành phần mới—RemoteLogManager và các tương tác với các chức năng hiện có, chẳng hạn như các bản sao theo kịp nhà leader và cuộc bầu chọn leader.

Một kết quả thú vị được tài liệu hóa trong KIP-405 là các tác động đến hiệu suất của lưu trữ phân tầng. Nhóm triển khai lưu trữ phân tầng đã đo lường hiệu suất trong một số trường hợp sử dụng:

• Trường hợp đầu tiên là sử dụng với throughput cao. Trong trường hợp này, độ trễ tăng một chút (từ 21 ms lên 25ms trong p99), vì các broker cũng phải gửi các phân đoạn dữ liệu đến remote tier.
• Trường hợp sử dụng thứ hai là khi một số consumer đang đọc dữ liệu cũ. Nếu không có lưu trữ phân tầng, việc đọc dữ liệu cũ của consumer có ảnh hưởng lớn đến độ trễ (21 ms so với 60 ms p99), nhưng khi lưu trữ phân tầng được kích hoạt, ảnh hưởng giảm đáng kể (25 ms so với 42 ms p99); điều này là do việc đọc lưu trữ phân tầng được thực hiện từ HDFS hoặc S3 qua đường truyền mạng. Đọc từ mạng không cạnh tranh với việc đọc từ local storage hoặc bộ nhớ page cache, và giữ cho bộ nhớ page cache không bị thay đổi với dữ liệu mới làm cho cache k bị invalid.

Điều này có nghĩa là, ngoài việc cung cấp lưu trữ vô hạn, chi phí thấp hơn và khả năng mở rộng, lưu trữ theo cấp độ còn mang lại sự độc lập giữa việc đọc dữ liệu lịch sử và việc đọc dữ liệu thời gian thực.

3. Thông tin kết nối

Nếu anh em muốn trao đổi thêm về bài viết, hãy kết nối với mình qua LinkedIn và Facebook:

• LinkedIn: https://www.linkedin.com/in/nguyentrungnam/
• Facebook: https://www.facebook.com/trungnam.nguyen.395/

Rất mong được kết nối và cùng thảo luận!