Cloudflare K2: Dòng sự kiện serverless trên nền tảng Developer Platform

Cloudflare vừa công bố ra mắt K2 ở giai đoạn beta công khai, một giải pháp truyền phát sự kiện bền vững (durable event streaming) hoạt động hoàn toàn theo mô hình serverless trên nền tảng Developer Platform. Đây được xem là bước tiến quan trọng giúp các nhà phát triển xử lý luồng dữ liệu lớn mà không cần phải tự vận hành những hệ thống phức tạp như Apache Kafka.

Sơ đồ kiến trúc K2 trên Cloudflare

Vấn đề mà K2 giải quyết

Trong kiến trúc RPC (Remote Procedure Call) truyền thống, nhà sản xuất (producer) và người tiêu thụ (consumer) buộc phải đồng bộ cả về quy mô lẫn thời gian. Nếu producer gửi dữ liệu quá nhanh so với khả năng xử lý của consumer, hoặc consumer cùng các dịch vụ hạ nguồn gặp sự cố, dữ liệu sẽ bị mất. Vấn đề càng nghiêm trọng khi có nhiều consumer cần xử lý độc lập cùng một nguồn dữ liệu.

Ví dụ điển hình: một hệ thống thương mại điện tử phát ra sự kiện mỗi khi giao dịch hoàn tất, và những sự kiện này cần được đọc bởi cả hệ thống phân tích lẫn dịch vụ phát hiện gian lận.

Giải pháp nằm ở việc tách rời producer và consumer bằng cách chèn một dịch vụ trung gian có khả năng hấp thụ ghi dữ liệu, đồng thời cho phép các reader độc lập tiêu thụ theo tốc độ riêng của chúng. Đó chính là vai trò của K2.

K2 hoạt động như thế nào?

K2 là một primitive truyền phát sự kiện bền vững. Bạn gửi sự kiện vào một K2 stream, hệ thống lưu trữ chúng dưới dạng log có thứ tự. Consumer có thể đọc theo nhiều cách khác nhau: chia nhỏ việc đọc across nhiều consumer, hoặc gửi toàn bộ thông điệp đến tất cả consumer.

K2 hoàn toàn serverless, mở rộng đến khối lượng dữ liệu khổng lồ và hỗ trợ lưu trữ dài hạn, nhờ đó ngay cả khi consumer ngừng hoạt động trong thời gian dài cũng không làm mất dữ liệu.

Về bản chất, K2 triển khai một log bền vững dạng phân vùng (partitioned durable log) trên nền R2 object storage, cho phép nó mở rộng đến dung lượng lưu trữ cực lớn.

Lý do Cloudflare xây dựng K2

Cloudflare bắt đầu xây dựng K2 vì cần một bộ đệm bền vững ở edge, ban đầu nhằm phục vụ vai trò lớp ingestion cho Basin Pipelines. Pipelines vận hành trên mô hình pull-based, nghĩa là cần một hệ thống khác lưu trữ sự kiện trước khi chúng được đọc, biến đổi và ghi vào R2.

Phần lớn các công ty sẽ triển khai Apache Kafka cho tác vụ này. Tuy nhiên, Pipelines chạy trên hạ tầng edge của Cloudflare trải rộng khắp hơn 335 thành phố. Kiến trúc đặc thù này khiến việc chạy các phần mềm hệ phân tán truyền thống như Kafka trở nên bất khả thi.

Cloudflare phải đối mặt với những thách thức cụ thể: các máy chủ được cấp phát theo phân đoạn nhỏ, khá tạm thời (ephemeral), và mạng thường đi qua Internet công cộng. Bù lại, hạ tầng của họ có lợi thế lớn là ở gần người dùng toàn cầu và có khả năng mở rộng ngang vượt trội.

Xây dựng log trên object storage

Ý tưởng cốt lõi là tận dụng R2 — một primitive trạng thái mạnh mẽ sẵn có. Các hệ thống object storage như R2 kết hợp khả năng lưu trữ cực bền vững (độ bền 11 số 9) với API nhất quán mạnh. Việc đẩy replication và consensus xuống tầng lưu trữ giúp tầng ứng dụng (ở đây là K2) trở nên đơn giản hơn, rẻ hơn và hiệu năng cao hơn.

Một lợi ích phụ quan trọng là tách biệt compute và storage, cho phép mỗi phần mở rộng độc lập. Nhờ đó Cloudflare có thể lưu trữ khối lượng dữ liệu lịch sử khổng lồ với chi phí thấp.

Vấn đề kỹ thuật đặt ra: R2 — giống các object store khác — không hỗ trợ thao tác append, vốn là thao tác chuẩn trên một log. Thay vào đó, hệ thống phải ghi các file hoàn chỉnh (gọi là segment) đủ lớn để bù đắp chi phí đọc/ghi.

Cách K2 giải quyết là tích lũy các ghi trong bộ nhớ tại một dịch vụ edge, chờ một khoảng ngắn để dữ liệu đến, sau đó ghi tất cả sự kiện thành một file segment. Việc đảm bảo thứ tự và offset tăng nghiêm ngặt được thực hiện nhờ các thao tác atomic của R2 mà không cần dịch vụ điều phối riêng.

Đánh đổi duy nhất là độ trễ produce cao hơn: ghi vào object storage chậm hơn ghi vào ổ đĩa cục bộ, cộng thêm việc phải chờ batch tích lũy. Trong phiên bản đầu tiên, điều này khiến độ trễ produce ở phân vị 99 lên tới khoảng 1 giây.

K2, Queues hay Pipelines?

Cloudflare đã có sẵn nhiều primitive phân phối bất đồng bộ như Queues và Basin Pipelines. Khi nào nên dùng K2?

Queues được thiết kế xoay quanh việc theo dõi từng mục công việc đắt đỏ hoặc tốn thời gian cần hoàn thành bất đồng bộ. Chúng hỗ trợ logic phức tạp ở cấp từng work item như retry, delay và dead-letter queue cho các lần thất bại.

K2 thì hướng đến di chuyển dữ liệu quy mô lớn, lưu trữ dài hạn và tiêu thụ dạng fan-out. Thông điệp được sản xuất và tiêu thụ theo batch — cho phép xử lý hiệu quả nhưng đánh đổi bằng việc không hỗ trợ retry ở cấp từng thông điệp. Chính việc gom batch này cũng làm độ trễ producer cao hơn so với Queues.

Basin Pipelines là dịch vụ ingestion serverless. Bạn gửi sự kiện JSON vào Pipeline, chúng được biến đổi và ghi vào R2 hoặc Basin Catalog. Cloudflare khuyến nghị dùng Pipelines khi kết quả cuối là ghi sự kiện vào object storage hoặc bảng Iceberg, và dùng K2 khi cần xử lý tùy chỉnh hoặc ghi đến các đích khác.

Bắt đầu sử dụng

Sử dụng K2 bắt đầu bằng việc tạo một stream. Bạn có thể có nhiều stream trong tài khoản cho các use case hoặc loại sự kiện khác nhau, tạo qua cf, Wrangler, dashboard hoặc API.

Ví dụ tạo stream để thu thập và xử lý dữ liệu phân tích sản phẩm:

$ cf k2 streams create --name app_events --http-enabled

Sau khi có stream, bạn có thể bắt đầu produce dữ liệu qua HTTP API hoặc Worker binding:

const result = await env.EVENTS.send([
  {
    content: new TextEncoder().encode(
      JSON.stringify({
        event: "page_view",
        path: new URL(request.url).pathname,
        timestamp: Date.now(),
      }),
    ),
    headers: { "content-type": "application/json" },
  },
]);

if (!result.success) {
  console.error(`Produce failed: ${result.error.message}`);
  return new Response("Failed to record event", {
    status: result.error.retryable ? 503 : 500,
  });
}

K2 biểu diễn dữ liệu dưới dạng byte, nên bạn có thể dùng bất kỳ định dạng hay encoding nào phù hợp với ứng dụng của mình.

Subscription và cơ chế lease

Subscription chia nhỏ công việc giữa các consumer, cho phép đọc song song — mở rộng ra nhiều reader để xử lý tải lớn hơn khả năng của một server đơn lẻ.

Khi client gọi consume, nó nhận được một lease cho batch sự kiện đó trong 5 phút. Client có thể làm một trong ba việc:

• ack: đánh dấu batch đã xử lý và đảm bảo không bị gửi lại
• nack (negative ack): báo hiệu xử lý thất bại và muốn được gửi lại
• extend: gia hạn lease khi cần thêm thời gian xử lý

Đây là một cách tiêu thụ từ K2: chia việc giữa nhiều consumer sao cho mỗi consumer nhận một phần dữ liệu. Cách khác là dùng một subscription riêng cho mỗi consumer — mô hình pub/sub — khi đó mỗi consumer thấy toàn bộ thông điệp. Bạn cũng có thể kết hợp cả hai cách với nhiều pool consumer độc lập.

Giá cả và tính khả dụng

K2 hiện khả dụng ở dạng beta công khai cho các tài khoản có Workers Paid, với giới hạn:

• Tối đa 10 GB dung lượng lưu trữ
• 30 MB/s throughput produce mỗi stream

Nếu cần giới hạn cao hơn, bạn có thể liên hệ đội ngũ Cloudflare qua Discord hoặc điền form yêu cầu tăng hạn mức.

Trong giai đoạn beta, việc sử dụng K2 không bị tính phí. Khi bắt đầu thu phí, mức giá dự kiến như sau:

• Dữ liệu sản xuất: 0,04 USD/GB
• Dữ liệu tiêu thụ: 0,04 USD/GB
• Dữ liệu lưu trữ: 0,02 USD/GB/tháng

Lộ trình sắp tới

Cloudflare công bố lộ trình phát triển K2 trong những tháng tới, bao gồm:

• Tăng khả năng ghi song song, lên tới stream đa GB/s
• Hỗ trợ message key và đảm bảo thứ tự theo key
• Consumer dạng push-based cho Worker
• Express tier với độ trễ produce và end-to-end thấp hơn
• Hỗ trợ drop-in cho client Apache Kafka

Đối với các nhà phát triển tại Việt Nam đang xây dựng ứng dụng trên nền tảng Cloudflare Workers, K2 mở ra một lựa chọn mới đáng cân nhắc cho các bài toán xử lý sự kiện quy mô lớn mà không cần tự vận hành hạ tầng Kafka phức tạp. Đây là một hướng đi đáng chú ý trong xu hướng đưa các primitive hạ tầng phân tán lên mô hình serverless.