OpenFreeMap chia sẻ kinh nghiệm chịu được 100.000 yêu cầu mỗi giây

• OpenFreeMap đã thành công xử lý 100.000 yêu cầu mỗi giây và 300 triệu lượt truy cập mỗi ngày.
• Sự bùng nổ đột ngột của Wplace.live và các yêu cầu hàng loạt tự động hóa là nguyên nhân gây tăng vọt lưu lượng.
• Tỷ lệ cache CDN của Cloudflare đạt 99,4%, máy chủ còn xử lý trơn tru thêm 1.000 rps.
• Vì vậy chỉ phát sinh vài sự cố nhỏ như hiện tượng thiếu tile, trong khi dịch vụ phần lớn vẫn vận hành bình thường.
• Sắp tới sẽ có kế hoạch cải thiện quản lý lưu lượng tự động, bao gồm giới hạn băng thông theo tham chiếu (referer).

---

Kinh nghiệm 10 tháng của OpenFreeMap và việc ứng phó lưu lượng khổng lồ

OpenFreeMap đã có trải nghiệm vận hành rất ổn định trong 10 tháng qua. Độ tin cậy hệ thống đã được xác lập nhờ sự hỗ trợ băng thông của Cloudflare, độ ổn định của máy chủ Hetzner, dịch vụ tile trên Btrfs và hiệu suất của nginx. Tuy nhiên, một hôm nhóm nhận được báo cáo rằng một số tile không tải được. Thông thường nguyên nhân thường là lỗi thuật toán, nhưng lần này log nginx cho thấy lỗi open() "Too many open files".

Qua công cụ giám sát lưu lượng, xác nhận là trong 24 giờ có 3 tỷ yêu cầu, và ngay cả các file tile nhỏ đã tạo ra 215TB lưu lượng. Trong 5 phút gần nhất đã có 30 triệu yêu cầu, tương đương mức bùng nổ lên tới 100.000 request mỗi giây. Lưu lượng này, nếu là một dịch vụ bản đồ thương mại, sẽ tốn hơn 6 triệu USD mỗi tháng.

Trong dashboard của Cloudflare, 96% phản hồi là 200 OK, chỉ có 3,6% là bất thường (206 Partial Content). Hầu hết yêu cầu được phục vụ bình thường, và ngoài một số tile bị thiếu thì toàn bộ hệ thống vận hành tốt.

Nguyên nhân bùng nổ lưu lượng: Wplace.live

Nguyên nhân của đợt bùng nổ lần này là một trang vẽ cộng tác mới tên Wplace.live. Ngay sau khi ra mắt, rất nhiều người dùng đổ đến và hệ thống này được thiết kế để sử dụng bản đồ dựa trên OpenFreeMap. Để vượt qua giới hạn 1 pixel/30 giây, người dùng đã tạo ra lượng yêu cầu lớn bằng công cụ tự động hóa (ví dụ Puppeteer/Chromium, xoay IP, v.v.).

Nhà vận hành nhấn mạnh tầm quan trọng của việc trao đổi trước khi lượng truy cập tăng đột biến, nhắc tới kinh nghiệm hợp tác với Neal.fun trước đây. Vì lần này đã làm gián đoạn vận hành dịch vụ nên đã áp dụng quy tắc của Cloudflare lần đầu tiên để chặn. Sắp tới nhóm sẽ tìm giải pháp kiểm soát lưu lượng tự động dựa trên referer hoặc custom header (kể cả việc tận dụng Cloudflare API).

Hỗ trợ của Cloudflare và thành quả kiến trúc của OpenFreeMap

Cloudflare đã phê duyệt hỗ trợ băng thông rất nhanh trong thời gian ngắn (bao gồm cả cuối tuần, trong vòng 48 giờ), và còn thảo luận cùng kỹ sư về sự phù hợp kiến trúc. Dù là doanh nghiệp lớn, họ vẫn thể hiện phản ứng linh hoạt.

Người vận hành tự hào đã đạt được tỷ lệ cache CDN 99,4% và cho biết máy chủ đã chịu tải 1.000 rps một cách vững chắc. Đây là một kết quả ấn tượng cho dịch vụ cập nhật dữ liệu theo tuần.

Liên hệ với nhà phát triển Wplace.live và đề xuất giải pháp

Sau đó có liên lạc được với nhà phát triển Wplace.live; họ hiểu việc tăng đột biến lên 2 triệu người dùng khiến chưa chuẩn bị đầy đủ. Hai bên đã bàn cách hỗ trợ phiên bản OpenFreeMap tự lưu trú (self-hosting) để giảm tình trạng tập trung lưu lượng và nâng cao hiệu quả.

Ngoài ra, việc xuất hiện 3 tỷ yêu cầu trong khi chỉ có 2 triệu người dùng thực tế cho thấy phần lớn đến từ các yêu cầu hàng loạt dựa trên script. Vì người dùng thường chỉ làm 10-20 yêu cầu, nhóm khuyến nghị thay đổi chính sách dịch vụ để ngăn các yêu cầu tự động không cần thiết.

Cải tiến trong tương lai và bài học rút ra

Người vận hành thông báo sẽ cải tiến hai vấn đề:

1. Giới hạn băng thông theo Referer

   • Sẽ triển khai cơ chế giới hạn theo từng Referer trong Cloudflare, ví dụ giới hạn 100-200 triệu request mỗi ngày (24 giờ).
   • Sẽ khuyến khích ứng dụng native sử dụng custom header.

2. Cải thiện xử lý tile thiếu và cấu hình máy chủ

   • Sẽ xử lý để tránh việc tạo tile rỗng do cấu hình máy chủ sai.

OpenFreeMap hiện được vận hành bằng 500 USD quyên góp mỗi tháng. Chi phí hạ tầng đã được bù đắp đầy đủ, nhưng phát triển mới vẫn phụ thuộc vào thời gian cá nhân có hạn. Với sự hỗ trợ thêm, nhóm có thể đẩy nhanh tốc độ phát triển và mở rộng tính ổn định của dịch vụ.

Bạn có thể tham gia hỗ trợ dự án qua tài trợ GitHub: https://github.com/sponsors/hyperknot