Tối ưu hóa hiệu năng: Cách Cloudflare tăng gấp 10 lần công suất quét bảo mật toàn cầu

Tính năng Security Insights của Cloudflare cung cấp các khuyến nghị bảo mật hữu ích cho mọi tài khoản. Để làm được điều này, Cloudflare thực hiện các đợt quét định kỳ trên tất cả tài khoản, zone và bản ghi DNS. Tuy nhiên, khi quy mô người dùng tăng lên, hệ thống cũ đã bộc lộ những hạn chế nghiêm trọng.

Thách thức: Khi hệ thống cũ chạm ngưỡng giới hạn

Cloudflare đối mặt với hai vấn đề lớn:

1. Tần suất quét quá thấp: Các đợt quét chỉ diễn ra mỗi 1-2 tuần, khiến các lỗ hổng mới xuất hiện có thể tồn tại mà không bị phát hiện trong thời gian dài.
2. Giới hạn phạm vi: Việc quét tự động chỉ là tùy chọn (opt-in) cho các gói miễn phí, dẫn đến nhiều tài khoản không được bảo vệ.

Để khắc phục, Cloudflare cần tăng thông lượng quét từ 10 lên 100 yêu cầu mỗi giây (RPS). Hệ thống cũ đã quá tải: hàng triệu sự kiện tồn đọng, API thường xuyên timeout và các tiến trình liên tục bị crash.

Kiến trúc quét bảo mật của Cloudflare

Hệ thống dựa trên sự kết hợp giữa:

• Scheduler: Kích hoạt các đợt quét.
• Apache Kafka: Nền tảng truyền tải sự kiện phân tán, nơi các thông điệp quét được đẩy vào.
• Checkers: Các microservice viết bằng Go thực hiện quét các tài sản cụ thể.
• Postgres Database: Lưu trữ kết quả thông qua một API nội bộ.

Chiến lược tối ưu hóa kỹ thuật

1. Xử lý song song (Parallel Processing)

Kafka yêu cầu xử lý theo thứ tự trong mỗi partition, điều này thường gây nghẽn. Cloudflare đã thay đổi cách các Checker hoạt động: thay vì xử lý tuần tự, họ chuyển sang xử lý theo batch và thực thi mỗi thông điệp trong một goroutine riêng biệt. Mặc dù tốn bộ nhớ hơn một chút, nhưng nó giúp tăng tốc độ xử lý đáng kể.

2. Loại bỏ Head-of-Line Blocking

Một số tài khoản có lượng dữ liệu khổng lồ khiến việc quét mất hàng giờ, làm nghẽn các tài khoản nhỏ hơn. Cloudflare đã chia các nhóm consumer thành hai làn: 'slow lane' và 'fast lane'. Nếu một checker phát hiện tác vụ quá nặng, nó sẽ chuyển sang làn chậm, giúp các tác vụ nhanh không bị chặn lại.

3. Tối ưu hóa truy vấn Database

Việc thực hiện hàng nghìn câu lệnh INSERT riêng lẻ gây ra hàng triệu lượt round-trip tới cơ sở dữ liệu. Cloudflare đã áp dụng chiến lược lai:

• Sử dụng UNNEST cho các tập dữ liệu nhỏ.
• Sử dụng lệnh COPY cho các tập dữ liệu lớn để tối ưu hóa tốc độ ghi.

4. Giải quyết độ trễ API (Latency)

Cloudflare phát hiện ra rằng API được triển khai ở cả Portland và Amsterdam, trong khi database chính nằm ở Portland. Độ trễ 50ms giữa hai khu vực khiến kết nối bị giữ quá lâu, dẫn đến cạn kiệt pool kết nối. Giải pháp là chuyển API sang mô hình active-passive, đảm bảo API luôn kết nối với database gần nhất.

5. Lập lịch thông minh (Adaptive Rate Limiting)

Scheduler cũ gây ra các đợt quét dồn dập (spiky). Cloudflare đã thực hiện:

• Lập lịch độc lập: Zone và tài khoản được quét riêng biệt.
• Ngẫu nhiên hóa thời gian: Tránh việc hàng triệu tài khoản cùng quét một lúc.
• Adaptive Rate Limiting: Tự động tính toán giới hạn quét dựa trên tổng số tài khoản và zone hiện có bằng hàm:

func computeRate(free, pro, biz, ent int64) rate.Limit {
   r := float64(free)/freeScanInterval.Seconds() + 
      float64(pro)/proScanInterval.Seconds() + 
      float64(biz)/bizScanInterval.Seconds() + 
      float64(ent)/entScanInterval.Seconds()

   if r < 1 { r = 1 }
   r *= rateLimitBufferFactor
   return rate.Limit(r)
}

Kết quả đạt được

Nhờ những cải tiến trên, thông lượng trung bình đã tăng hơn 10 lần, đạt đỉnh trên 120 lượt quét/giây. Hiện nay, Cloudflare đã có thể:

• Gói Free: Quét mỗi 7 ngày.
• Gói Pro & Business: Quét mỗi 3 ngày.
• Gói Enterprise: Quét hàng ngày.

Bài học rút ra là: Thay vì vội vàng thêm tài nguyên, hãy đào sâu vào số liệu, tối ưu hóa mã nguồn và cấu trúc dữ liệu để xây dựng một hệ thống bền vững hơn.