Cloudflare giảm áp lực hạ tầng dữ liệu bằng cách nào khi lưu lượng tăng theo cấp số nhân?
Cloudflare mô tả các thay đổi trong data pipeline dùng để đưa dữ liệu từ mạng toàn cầu tới hệ thống analytics, Logs, SQL API và các dịch vụ nội bộ. Điểm đáng chú ý không phải một tính năng Cloudflare mới cho người dùng cuối, mà là cách đội kỹ thuật giảm lưu lượng, dung lượng lưu trữ và nhu cầu phần cứng mà vẫn giữ chất lượng dữ liệu phục vụ phân tích.
Bài nguồn nói về bài toán gì?
Cloudflare cho biết hơn 20% web nằm sau mạng của họ và pipeline phải xử lý khoảng hai tỷ sự kiện mỗi giây vào tháng 5. Bài toán là lưu lượng thường tăng theo cấp số nhân, trong khi phần cứng chỉ có thể tăng gần tuyến tính nếu muốn kiểm soát chi phí.
Theo công ty, các cải tiến trong năm năm tương đương với việc lùi nhu cầu mở rộng phần cứng khoảng hai năm rưỡi. Con số là ước tính do Cloudflare công bố, nhưng các kỹ thuật mô tả bên dưới là bài học hữu ích cho mọi đội vận hành hệ thống dữ liệu lớn.
1. Chia nhỏ schema thay vì mang cả “xe tải” dữ liệu
Năm 2022, Cloudflare bỏ một schema đơn chứa trường của nhiều sản phẩm. Consumer trước đây phải nhận tất cả rồi tự lọc hoặc bỏ dữ liệu không liên quan. Schema theo sản phẩm có thể lặp lại vài trường, nhưng giảm lượng băng thông backbone 35–40% theo báo cáo.
Bài học là không nên mặc định một event khổng lồ phù hợp với mọi downstream consumer. Hãy đo trường nào thực sự cần, version hóa contract, và cân nhắc topic hoặc schema hẹp hơn. Việc này phải đi kèm quản trị tương thích để không tạo ra quá nhiều luồng khó vận hành.
2. Nén tốt hơn, rollout thận trọng
Đến năm 2024, Cloudflare chuyển từ LZ4 sang zstd sau khi thử trên ít máy và theo dõi CPU. Công ty nói CPU không tăng đáng kể và compressed throughput giảm gần 40%, cho phép cùng đường truyền phục vụ hơn 1,5 lần lưu lượng.
Không có thuật toán nén nào luôn tốt nhất. Đội vận hành cần benchmark trên dữ liệu thật, đo CPU, độ trễ, tỷ lệ nén, chi phí giải nén và hành vi lúc cao điểm. Triển khai theo canary, có dashboard và đường rollback rõ ràng an toàn hơn thay đổi đồng loạt.
3. Di chuyển replication xuống cuối pipeline
Trước đây, Logfwdr gửi hai bản sao raw event đến hai khu vực để chịu lỗi. Kiến trúc mới gửi mỗi event một lần tới pool receiver, lấy mẫu sớm hơn rồi sao chép downstream từ buffer Buftee sang cụm còn lại. Cloudflare nói các dataset đã chuyển loại bỏ khoảng 43 GB/s transit nén, thêm khoảng 7 GB/s replication liên vùng, tức giảm ròng 36 GB/s.
Ý tưởng cốt lõi là tách tính sẵn sàng của database khỏi việc nhân đôi raw traffic ngay tại nguồn. Tuy nhiên, nó chỉ đáng làm nếu buffer, retention, replay và xử lý mất kết nối liên vùng được kiểm thử kỹ.
4. Sampling và aggregation từ sớm
Cloudflare mở rộng sampling sang Logfwdr, trước cả receiver. Với khóa dữ liệu đã chọn, họ xáo record để giảm bias, lấy mẫu theo quy tắc căn bậc hai và scale kết quả khi ước lượng. Ba dataset đầu tiên được áp dụng đều giảm ít nhất một nửa compressed data gửi tới receiver, tổng cộng 25 GB/s theo bài viết.
Aggregation là lựa chọn khác: thay vì trả lời mọi câu hỏi xấp xỉ, hệ thống trả lời chính xác một tập câu hỏi đã chọn trước. Cloudflare đưa aggregation tiến dần về các bước gần nguồn để gộp partial aggregate nhiều lần. Điều này giảm dữ liệu tập trung nhưng đòi hỏi định nghĩa metric, dimension và độ trễ chốt cửa sổ thật rõ.
Kết luận
Bài viết cho thấy tiết kiệm hạ tầng không chỉ đến từ mua thêm máy. Schema đúng kích thước, nén có đo lường, replication muộn, sampling có kiểm chứng và aggregation phù hợp có thể kéo nhu cầu phần cứng lùi lại đáng kể. Điều quan trọng là bảo toàn chất lượng dữ liệu, khả năng khôi phục và quan sát được trade-off ở từng bước.
Checklist thực tế
- Lập baseline event rate, bytes, CPU, latency và chi phí.
- Kiểm tra field usage trước khi tách schema.
- Canary mọi thay đổi nén hoặc sampling.
- Diễn tập replay, failover và mất liên kết liên vùng.
- Gắn mỗi số liệu ước lượng với sample rate và sai số.
Kết luận
Bài viết cho thấy tiết kiệm hạ tầng không chỉ đến từ mua thêm máy. Schema đúng kích thước, nén có đo lường, replication muộn, sampling có kiểm chứng và aggregation phù hợp có thể kéo nhu cầu phần cứng lùi lại đáng kể. Điều quan trọng là bảo toàn chất lượng dữ liệu, khả năng khôi phục và quan sát được trade-off ở từng bước.