- Kafka đã thành công như một distributed log của thời đại trung tâm dữ liệu, nhưng trên public cloud, chi phí mạng giữa các AZ và gánh nặng vận hành đĩa cục bộ ngày càng lớn
- WarpStream là một nền tảng streaming không đĩa tương thích với giao thức Apache Kafka, chạy trên object storage như S3 mà không cần đĩa cục bộ hay rebalancing broker
- Một cụm Kafka 3 availability zone, ngay cả trong trường hợp tốt nhất, cũng tốn khoảng $0.053 chi phí truyền tải giữa các AZ cho mỗi 1GiB streaming, cao hơn chi phí lưu 1GiB trên S3 trong một tháng là $0.021
- WarpStream tách biệt storage/compute và data/metadata bằng Agent là binary Go stateless cùng một kho metadata riêng; dữ liệu vẫn nằm trong object storage của tài khoản cloud của người dùng
- Chi phí có thể giảm 5–10 lần với phần lớn workload Kafka, nhưng đổi lại triển khai hiện tại phải chấp nhận độ trễ khoảng P99 400ms cho request Produce và P99 khoảng 1 giây từ producer đến consumer
Cấu trúc cơ bản của Kafka trở nên đắt đỏ trên cloud
- Apache Kafka được open source vào năm 2011 và từ đó trở thành hạ tầng nền tảng của kiến trúc streaming
- Vấn đề không hẳn nằm ở bản thân Kafka, mà ở chỗ thiết kế của nó được tối ưu cho trung tâm dữ liệu của LinkedIn năm 2011 nên không còn phù hợp với workload cloud hiện đại
- Chi phí và gánh nặng vận hành là hai điểm bộc lộ rõ nhất
- Tính kinh tế của cloud: cách Kafka sao chép dữ liệu có thể làm chi phí băng thông giữa các AZ tăng mạnh
- Gánh nặng vận hành: tự vận hành cụm Kafka đòi hỏi đội ngũ chuyên trách và công cụ tùy biến
- Các hệ thống tương tự lưu dữ liệu trên đĩa cục bộ cũng có thể gặp cùng vấn đề về chi phí và vận hành
Kafka-nomics: chi phí truyền tải giữa các AZ
- Trong một cụm Kafka 3 availability zone điển hình, dữ liệu được producer ghi vào sẽ có xác suất 2/3 phải đi qua zone khác do vị trí partition leader; sau đó leader tiếp tục sao chép dữ liệu sang follower ở hai zone còn lại
- Chi phí khi truyền 1GiB giữa các zone được tính là $0.022
- egress từ zone nguồn: $0.01
- ingress vào zone đích: $0.01
- Ngay cả trong trường hợp tốt nhất, chi phí streaming 1GiB cũng vào khoảng
0.02 * 2/3 + 0.02 * 2 = $0.053
- Lưu 1GiB trên S3 trong một tháng chỉ tốn $0.021, nghĩa là riêng chi phí sao chép dữ liệu bằng Kafka từ producer tới consumer đã đủ để lưu cùng dữ liệu đó trên S3 hơn hai tháng
- Với các cụm Kafka throughput lớn, phí băng thông giữa các AZ chứ không phải phần cứng mới là yếu tố chi phối chi phí, có thể chiếm 70–90% tổng chi phí workload
- Ngay cả khi throughput thấp, nếu thời gian lưu giữ dài thì dung lượng lưu trữ vẫn tăng lớn; cách dùng SSD cục bộ với sao chép 3 bản có thể đắt hơn khoảng 10–20 lần mỗi GiB so với object storage như S3, ngay cả khi giả định mức sử dụng đĩa đạt 100%
Gánh nặng vận hành cụm mà nhà phát triển phải gánh
- Nhà phát triển đưa Kafka vào để giải quyết bài toán kinh doanh, nhưng trước hết lại phải học Kafka cùng ZooKeeper hoặc KRaft, leader election, partition, consumer group, rebalancing, tuning broker và tuning client
- Broker là data plane của Kafka, còn controller và ZooKeeper là control plane dựa trên cơ chế đồng thuận; tất cả đều được vận hành trực tiếp trên SSD cục bộ
- Một cụm Kafka self-hosted cần đội ngũ chuyên môn và công cụ tùy chỉnh để có thể thực hiện an toàn cả những tác vụ cơ bản như thay node hay mở rộng cụm
- Công cụ gán lại partition tích hợp sẵn của Apache Kafka không thể tự tạo kế hoạch reassign khi loại bỏ broker; quản trị viên phải tự viết kế hoạch di chuyển replica partition
- Ngay cả dịch vụ hosted như AWS MSK cũng không thể xóa bỏ hoàn toàn gánh nặng vận hành
- Tài liệu rebalancing cluster của MSK dẫn sang tài liệu Apache Kafka
- Quy trình đó có cả bước chỉnh sửa thủ công JSON để chỉ định partition nào phải chuyển sang broker nào
- Cruise Control có thể giảm bớt gánh nặng, nhưng lại bổ sung thêm khái niệm phải học, dịch vụ phải triển khai/giám sát và nhiều điểm dễ phát sinh rủi ro trong vận hành
- Bản thân Cruise Control cũng là một ứng dụng JVM phụ thuộc vào Apache Kafka và ZooKeeper
Cách tiếp cận đưa streaming lên trên object storage
- Husky do Datadog xây dựng là một cơ sở dữ liệu dạng cột cho dữ liệu quan sát chạy trực tiếp trên S3, và phần lớn hoạt động như một data lake stateless có thể tự động mở rộng
- Sau khi xây dựng Husky, các cụm Kafka bắt đầu trông giống như một kiến trúc đã cũ trong đối chiếu
- Băng thông Kafka của Datadog đạt mức hàng chục GiB/s và lưu trữ broker ở quy mô NVMe tính bằng PiB
- Với workload lưu trữ quy mô lớn, rất khó để cạnh tranh với tính kinh tế, độ tin cậy, khả năng mở rộng và tính đàn hồi của object storage trong môi trường cloud
- Các công nghệ big data như Snowflake và Databricks cũng thiết kế hệ thống xoay quanh object storage phổ dụng
- Nếu xây dựng trực tiếp một hệ thống giống Kafka trên S3, có thể đồng thời giảm hai gánh nặng
- giảm chi phí
- giảm các vấn đề vận hành Kafka truyền thống
- Khó khăn cốt lõi là làm sao xây dựng hạ tầng streaming độ trễ thấp trên môi trường lưu trữ có độ trễ cao như S3, vẫn giữ nguyên ngữ nghĩa của giao thức Kafka mà không cần đĩa cục bộ
Kiến trúc WarpStream
- WarpStream là nền tảng streaming tương thích với giao thức Apache Kafka, chạy trực tiếp trên các object store phổ dụng như AWS S3, GCP GCS và Azure Blob Storage
- Nó không có chi phí băng thông giữa các AZ, không có đĩa cục bộ để quản lý và có thể chạy trong VPC của người dùng
- Thay vì Kafka broker, nó dùng Agent
- Agent là binary Go stateless
- không dùng JVM
- giao tiếp bằng giao thức Kafka
- bất kỳ Agent nào cũng có thể đóng vai trò topic leader, commit offset cho consumer group và cluster coordinator
- WarpStream thay cấu trúc stateful của Kafka bằng hai lớp tách biệt
- tách storage và compute, offload dữ liệu sang S3
- tách data và metadata, offload metadata sang một kho metadata tùy biến
- Khi đẩy toàn bộ lưu trữ sang object storage, việc tăng hoặc giảm số lượng Agent theo biến động tải không cần rebalancing dữ liệu
- Khi có sự cố, request có thể được retry ngay sang Agent khác nên thời gian phục hồi nhanh hơn
- Vấn đề hotspot khi một số broker Kafka bị quá tải do mất cân bằng dữ liệu giữa các partition cũng được giảm đi đáng kể
- Metadata của WarpStream Virtual Cluster được lưu trong một cơ sở dữ liệu metadata tùy biến
- Việc sao chép dữ liệu, độ bền và tính sẵn sàng do bucket object storage đảm nhiệm, còn dữ liệu của người dùng vẫn nằm trong tài khoản cloud của họ
- Thứ duy nhất rời khỏi tài khoản cloud là metadata workload cần cho cơ chế đồng thuận, như thứ tự batch trong partition
- Cấu trúc chi tiết được mô tả trong tài liệu kiến trúc của WarpStream
Ví dụ chi phí và trade-off về độ trễ
- Workload streaming liên tục trong môi trường thử nghiệm sản sinh đều đặn 140MiB/s dữ liệu, và 3 consumer chuyên dụng tiêu thụ lượng dữ liệu đó, tạo ra tổng lưu lượng truyền dữ liệu liên tục 560MiB/s
- Chi phí mạng giữa các AZ của toàn bộ tài khoản cloud được đo ở mức trung bình dưới $15 mỗi ngày
- Nếu chạy cùng workload đó trên cụm Kafka, chỉ riêng chi phí mạng giữa các AZ đã được tính là $641 mỗi ngày
- công thức tính là
0.14GiB * $0.053/GiB * 60 * 60 * 24
- Chi phí thao tác API S3 cho cùng workload cũng dưới $40 mỗi ngày
- Phần cứng cho Agent chỉ cần VM quy mô 27 vCPU
- Tổng chi phí sở hữu của phần lớn workload Kafka có thể thấp hơn 5–10 lần khi dùng WarpStream
- Nhược điểm lớn nhất là độ trễ
- request Produce hiện có P99 khoảng 400ms
- vì hệ thống chỉ xác nhận sau khi dữ liệu đã được lưu bền vững trên S3 và được commit vào cloud control plane
- độ trễ P99 end-to-end từ producer tới consumer vào khoảng 1 giây
- Nếu workload chấp nhận độ trễ producer-to-consumer P99 khoảng 1 giây, có thể giảm chi phí streaming trên mỗi GiB xuống 5–10 lần và gần như loại bỏ gánh nặng vận hành
- Giao diện không phải giao thức độc quyền mà là Kafka, và có thể chạy trong các môi trường sử dụng AWS S3, GCP GCS hoặc Azure Blob Storage
Trải nghiệm nhà phát triển và cách dùng
- WarpStream trước hết giải quyết hai vấn đề lớn của Kafka là tính kinh tế trên cloud và gánh nặng vận hành
- Kafka cũng có vấn đề về trải nghiệm nhà phát triển, và partition bị xem là mức trừu tượng quá thấp để viết các ứng dụng xử lý dòng phức tạp
- Trong tương lai, nhóm phát triển dự định nói thêm về cách đưa việc viết ứng dụng stream processing đến gần hơn với cách viết ứng dụng truyền thống
- Có thể chạy demo trong vòng chưa đến 30 giây
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
- WarpStream là phần giới thiệu sản phẩm của một công ty bán giải pháp thay thế dựa trên object storage cho Apache Kafka, vì vậy các số liệu và so sánh trong bài nên được đọc trong bối cảnh đó
1 bình luận
Các ý kiến trên Hacker News
Tôi nghĩ câu “gần như mọi công ty công nghệ đều dùng Kafka” là sai
Dù hai bên không đưa ra bằng chứng cho nhau, trong 6 công ty tôi làm gần đây thì số nơi dùng Kafka là 0; ở công ty trước đó nữa, tôi từng thúc đẩy việc đưa Kafka vào nhưng sau này cũng bỏ
LinkedIn tạo ra Kafka để giải quyết bài toán siêu quy mô mà 99% người khác không gặp phải; dù giới kỹ thuật có tiếng là dùng những công nghệ không cần thiết, tôi cho rằng phần lớn vẫn đang tránh dùng Kafka thành công
Nếu đó là tất cả những gì bạn cần, nó dễ dùng như một message broker đơn giản không cần thời hạn lưu giữ; còn nếu cần những tác vụ đặc biệt tận dụng tính bền vững dữ liệu, bạn có thể đi theo hướng đó
Nếu có cảm xúc tiêu cực với một công cụ mã nguồn mở vững chắc và được dùng rộng rãi ngay cả ở dạng cơ bản, thì thường chắc là do một số tính năng hay ca sử dụng đặc thù nào đó
Ngược lại, cách diễn đạt này khiến nhà cung cấp đó trông không hay. Có thể phê phán hay cạnh tranh với Kafka bằng ưu nhược điểm kỹ thuật, nhưng bóp méo vị thế của nó trên thị trường thì không ổn lắm
Tôi không nghi ngờ là có những ca sử dụng tốt, nhưng cho đến nay tôi chỉ thấy những người dùng quá nhiệt tình cố nhét nó vào mọi tình huống, nên để lại dư vị không tốt, và vì thế tôi thuộc “phe ghét”
Tôi đồng ý với phần “Accidental SRE”, nhưng Kafka là một công nghệ vững chắc, và vì vậy mới có đầy rẫy các công cụ kiểu “Kafka tốt hơn Kafka” như Redpanda
Đoạn cuối có vẻ lệch khỏi luận điểm. Ngay cả nếu nó không được dùng rộng rãi, điều đó cũng tách biệt với việc nó có phải là công nghệ gây phân cực hay không. Với những người đang giải bài toán mở rộng quy mô 1% được nhắc tới, nó vẫn có thể là thứ để thích hoặc ghét
Cũng giống như nói câu “Lamborghini gây chia rẽ yêu ghét” là sai vì đa số mọi người không sở hữu Lamborghini. Tác giả cũng đã giới hạn phạm vi rõ ràng là “trong lĩnh vực dữ liệu”
Tôi có vài câu hỏi
Vì vậy chi phí S3 PUT tỷ lệ với số Agent đang chạy và khoảng cách giữa các lần flush, chứ không phải số topic-partition. Produce request sẽ không được xác nhận trước khi dữ liệu được lưu bền vững trong S3 và cloud control plane
Tôi cho rằng không nên phải chọn một trong hai giữa độ tin cậy và chi phí. WarpStream cung cấp độ tin cậy và tính sẵn sàng ở mức chạy trên 3 availability zone với chi phí của một availability zone
Thứ tự được xử lý bởi cơ sở dữ liệu metadata tùy chỉnh chạy trong cloud control plane
Bản thân cách đặt Kafka cluster ở từng availability zone rồi chỉ replication cho đến khi hợp nhất về sau thì không có vấn đề gì. Tuy nhiên, khi có hệ thống phân tán và availability zone, các kỹ sư, cũng như yêu cầu kinh doanh, thường sẽ chọn cấu hình đa availability zone. Region cũng tương tự
Vì vậy phần lớn Kafka cluster là đa availability zone, nhưng thực ra nhiều trường hợp không cần như vậy, và hóa đơn chi phí đó lại bị quy cho Kafka
Kafka protocol thực ra không bảo toàn thứ tự thao tác trong một Kafka partition. Nó bảo toàn thứ tự thao tác trong một cặp producer-partition, và điều đó cũng chỉ khả thi khi được cấu hình theo một cách nhất định
Triển khai tiêu chuẩn là bảo toàn thứ tự broker nhận message từ producer, nhưng nhìn từ góc độ hệ thống bên ngoài, khi cấu hình đúng, nó gần với việc message của một key cụ thể và một producer cụ thể được giữ theo thứ tự nhận
Có phải Cloud Metadata Store về cơ bản đóng vai trò phân phối offset không?
Tôi là Ryan Worl, đồng sáng lập kiêm CTO của WarpStream. Rất vui được công bố bản preview dành cho nhà phát triển của hệ thống streaming tương thích giao thức Kafka được xây dựng trực tiếp trên S3.
Không có đĩa/node có trạng thái cần vận hành, không có rebalance dữ liệu, không có ZooKeeper, và không tốn chi phí băng thông giữa các vùng khả dụng, nên rẻ hơn 5–10 lần.
Nếu có câu hỏi về WarpStream, tôi sẽ cùng đồng sáng lập richieartoul trả lời.
Một trong những lý do tôi chưa làm là cảm giác có một nghịch lý: nếu quy mô không quan trọng, chẳng phải người dùng muốn dùng thẳng SQLite hơn là một phiên bản Kafka thu nhỏ sao?
Nhưng có thể có những người thích ngữ nghĩa của giao thức Kafka, hoặc đã dùng Kafka rồi mới nhận ra quy mô thực tế không như họ nghĩ nên không cần gánh độ phức tạp đó. Chúc may mắn.
Nếu hỗ trợ Cloudflare R2 thì có vẻ cũng tốt cho multi-cloud.
Nó có cung cấp đảm bảo thứ tự giống như Kafka cung cấp ở cấp partition không?
Nếu “rẻ hơn 5–10 lần” chủ yếu là nhờ giảm chi phí giữa các vùng khả dụng, AWS MSK cũng không cung cấp điều đó sao?
Có một điều chắc chắn: chạy Kafka “đúng bài” trên các VM riêng lẻ của nhà cung cấp cloud thì đắt vô lý.
Tôi nhớ đã có một cuộc trao đổi rất đơn giản với nhiều khách hàng về Kafka và Hadoop: khi đĩa đã được cung cấp như một hệ thống dư thừa hoàn chỉnh, tại sao lại sao chép dữ liệu thêm lần nữa ở cấp VM/đĩa?
Trường hợp này là Azure Storage, có lưu trữ dư thừa cục bộ, dư thừa theo vùng khả dụng và dư thừa toàn cầu; khá nhiều trong số đó có thể dùng để chạy managed disk.
Vì vậy, một dịch vụ Hadoop/Kafka managed trên cloud được thiết kế đúng sẽ dùng adapter lưu trữ để tận dụng cơ chế dư thừa tích hợp của nhà cung cấp. Đây cũng là lý do một số nhà cung cấp cloud có event broker tương thích Kafka.
Phần còn lại của WarpStream gần như là điểm cộng thêm, nhưng tôi tò mò về cấu trúc nội bộ và cách họ tránh chi phí giữa các vùng khả dụng.
Nhân tiện, tôi làm ở Microsoft, nhưng trước khi gia nhập gần 10 năm trước thì tôi từng xây dựng các cụm Hadoop/Spark/Kafka.
Một số triển khai Raft cho phép node có quyền bỏ phiếu nhưng không thể trở thành quorum leader. Ví dụ, một chi nhánh mà toàn bộ traffic đi qua đường hầm VPN bất đối xứng thì không nên được bầu làm leader, nhưng vẫn biết có thể nhìn thấy ứng viên nào.
Vì vậy chi phí cơ bản để vận hành cụm không phải gấp 3 lần phần cứng mà gần 2,2 lần hơn, và đó là khác biệt lớn với các giải pháp nhỏ hoặc sandbox cho developer. Nó cũng quan trọng trong trường hợp 3 shard hơi thiếu tải nhưng 5 shard lại quá nhiều, hoặc trong khác biệt giữa 6 và 7 shard.
Vấn đề là với nhân bản theo địa lý, nó không giải quyết được hai vấn đề là luận điểm chính của bài viết này. Về kinh tế cloud, chiến lược replication của Kafka về mặt thiết kế tạo ra chi phí băng thông rất lớn giữa các vùng khả dụng; về gánh nặng vận hành, tự vận hành cụm Kafka trên thực tế cần một đội chuyên trách và các công cụ tùy chỉnh tinh vi.
Dù vậy, cần lấy lại chức năng này trên cloud, đặc biệt khi mọi thứ lại bắt đầu dao động theo hướng tự host thêm, như trước đây vẫn luôn xảy ra.
Các giải pháp tương tự EBS đi kèm chi phí. Đặc biệt khi cần nhiều IOPS, chúng rất đắt. Dù có thể tiết kiệm chi phí traffic giữa các vùng khả dụng, bạn sẽ phải trả một khoản phi lý cho lưu trữ.
Nếu tự replication, bạn có thể dùng storage gắn trực tiếp rẻ hơn nhiều.
Gửi richieartoul, bài blog hơi nêm nếm quá tay.
Về bản chất Kafka không đòi hỏi một đội chuyên gia toàn thời gian và hàng triệu đô la cho tới khi bạn vận hành các cụm rất lớn.
Tuy nhiên tôi hoàn toàn đồng ý rằng một cụm trải rộng trên 3 vùng khả dụng sẽ hút tiền qua chi phí truyền tải giữa các vùng khả dụng. AWS cũng bán MSK theo cách đó. Họ nói truyền tải giữa các vùng khả dụng là “miễn phí”, nhưng thực ra nó đã được tính vào giá rồi.
Trông thú vị, nhưng sau khi đọc “Accidental SRE” tôi có hai câu hỏi.
Bare metal đã có từ lâu, nhưng việc tự quản lý bare metal có vẻ không hề dễ hơn nhiều. Nếu thật sự dễ, người dùng cuối đã tự quản lý những thứ này nhiều hơn rồi.
Vậy dịch vụ này được quản lý như thế nào? Trên cloud provider hay bare metal?
Cả hai người đều có nhiều kinh nghiệm với FoundationDB, vốn thường được tự quản lý trực tiếp. Vậy các bạn có lại chọn FoundationDB cho metadata store không? Nếu có hoặc không, tôi tò mò lý do.
Như vậy toàn bộ dữ liệu khách hàng vẫn nằm trong tài khoản cloud và bucket S3 của khách hàng, chúng tôi không thể xem hay động vào. Khách hàng đúng là phải tự chạy WarpStream Agent, nhưng đó chỉ là các container stateless dễ quản lý.
Chúng tôi đã cân nhắc FoundationDB cho metadata store nhưng cuối cùng không dùng. Để làm cho free tier hiệu quả về chi phí, chúng tôi phải tối ưu metadata store tối đa cho use case cụ thể này, và điều đó cần một thứ tùy chỉnh hơn.
Dù vậy FoundationDB là một công nghệ tuyệt vời. Trong số nhiều cơ sở dữ liệu phân tán tôi từng dùng, đó là cái tốt nhất.
Câu “Nên dùng bao nhiêu partition? Không rõ, nhưng một khi đã chọn thì tuyệt đối không thể đổi, nên phải chọn cho đúng” đơn giản là sai. Số lượng partition có thể thay đổi được
Và tôi cũng không thật sự hiểu lập luận được lặp đi lặp lại rằng “vận hành Kafka cần cả một đội kỹ sư”. Theo kinh nghiệm thì điều đó không đúng. Chi phí vận hành đúng là đắt, nhưng trong đội chúng tôi không cần nhiều thời gian kỹ thuật
Rất thú vị. Tôi cũng đã thiết kế một thứ tương tự và định triển khai bằng Zig https://github.com/fremantle-industries/transit
Một phần đáng kể sức mạnh của Kafka đến từ API, và cuối cùng tôi cũng đi đến kết luận tương tự rằng độ phức tạp trong quản lý cluster sẽ được trừu tượng hóa thông qua nhiều implementation khác nhau
Nếu có thể triển khai persistence của Kafka trên không gian key của S3, tôi nghĩ có thể bắt đầu bằng cách persist trực tiếp vào S3 như WarpStream, rồi sau đó bổ sung cơ chế phân tầng hot disk nhanh hơn và bộ nhớ để giảm độ trễ đầu cuối
Tôi thích hướng đi này. Nếu muốn trao đổi sâu hơn, cứ liên hệ với tôi qua Twitter https://twitter.com/rupurt
Ở công ty cũ, tôi đã xây một sản phẩm có lẽ rất giống sản phẩm này. Chúng tôi có lưu lượng machine learning ở mức hàng chục TB mỗi ngày, và vì không cần độ trễ thời gian thực nên đã chuyển toàn bộ sang S3, kết quả là tiết kiệm khoảng 90% chi phí
Nó được xây trên JVM, và để duy trì metadata chúng tôi vẫn dùng một cluster Kafka 6 broker. Khi mọi thứ ban đầu còn nằm hoàn toàn trên Kafka thì có lẽ phải là 300 broker
Mô hình compute/storage của Kafka không mở rộng tốt trong các use case cực đoan có thể chấp nhận độ trễ, còn mô hình của Apache Pulsar thì phù hợp hơn. Tuy vậy, vào thời điểm đó Pulsar chưa đủ ổn định để dùng trong production
Một điểm then chốt của hiệu quả chi phí là kích thước dữ liệu đủ lớn nên không phải chờ lâu để đạt đến kích thước file kinh tế. Khó tưởng tượng một pipeline dưới 10MB/giây có thể hoạt động hiệu quả theo cách này
Đây có phải là memq của Pinterest không, hay là thứ khác?
Tiêu đề bài viết lẽ ra nên là “Kafka is dead. Long live WarpStream.” Phần “long live” chỉ người kế vị
https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!