OpenFreeMap chia sẻ kinh nghiệm chịu được 100.000 yêu cầu mỗi giây
(blog.hyperknot.com)- 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 đề:
-
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.
-
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
1 bình luận
Ý kiến trên Hacker News
Mình đoán là một số hình ảnh được vẽ bởi các kẻ script kiddie. Vì website này chỉ cho phép mỗi người dùng 1 pixel mỗi 30 giây, nên mình nghĩ họ đã tự động hóa bằng cách mở trình duyệt mới bằng Puppeteer hoặc Chromium, click pixel rồi đóng trình duyệt. Có thể họ đã xoay cả địa chỉ IP nữa, nhưng có lẽ mức đó có thể đã không cần thiết. Mình mong không đánh giá thấp việc sự kiện này tăng vọt quy mô khủng khiếp chỉ sau một đêm. Khi mình nhắc tới một bức tranh vẽ gần nhà mình với vài người, dù không nói tên website, họ đều nhận ra ngay đang nói về gì. Có vẻ mọi người thật sự thích những dự án kiểu /r/place mỗi vài năm một lần, và lần này họ rất phấn khích vì có thể vẽ trực tiếp gần vị trí nhà mình trên bản đồ toàn cầu.
Mình tò mò nếu cách đọc trực tiếp tệp pmtiles tĩnh bằng MapLibre thì sẽ khác gì. Khi lấy pmtiles từ Bunnycdn bằng range request, mình thấy tốc độ phản hồi gần như tương đương với việc nhận trực tiếp từ tile server thực sự.
Mình nghĩ wplace có thể giải quyết toàn bộ nhu cầu chỉ bằng một tệp pmtile tĩnh tùy chỉnh. Đây là trường hợp không cần xử lý dữ liệu OSM 150GB.
Đã chia sẻ liên kết liên quan
Cảm ơn về phần giải thích chi tiết và tính minh bạch. Mình đang cân nhắc triển khai OpenFreeMap cho bản đồ sự cố của StatusGator thay cho MapTiler.
Khi chỉ nhìn ảnh chụp màn hình, mình thấy có vẻ dùng 1 VPS là đủ và thiết kế có vẻ quá phức tạp. Nhưng rồi nhận ra các pixel đang được phủ lên bản đồ toàn cầu. Mình tò mò throughput xử lý request tối đa khoảng bao nhiêu; có thể chỉ ở mức mà một web server dễ benchmark có thể cầm cự. Tất nhiên, do tính chất ứng dụng nên có thể sẽ có sụt giảm hiệu năng đáng kể. Với 64 pixel mỗi km, để phủ toàn cầu không nén màu thì cần 8TB (một vấn đề phải nhìn xa hơn!). Với Hetzner, máy 10TB giá 20 euro/tháng, nên dường như caching là bắt buộc. wplace dùng png 1000x1000 pixel cho lớp vẽ, hình vẽ hiển thị ngay nhưng bản thân bản đồ lại rất chậm và có cả khu vực không hiển thị gì cả.
Mình đoán đây có thể là vấn đề giới hạn số file mở; nếu chỉ tăng giới hạn này thì có chịu nổi không nhỉ? Việc chặn spam traffic là dễ hiểu, nhưng về lý thuyết có lẽ chỉ cần tăng giới hạn là xử lý được nhiều hơn.
Mình tò mò các site chưa cài caching có phải cứ mặc định là vì 'lười làm' không. Sao wplace.live phải gửi lượng traffic lớn như vậy cho openfreemap, trong khi đặt một caching server trên server của họ có vẻ có thể chạy nhanh hơn hoặc tương đương OpenFreeMap?
openfreemap đang nằm sau CDN và homepage cũng ghi như sau: "Public instance miễn phí, không giới hạn lượt xem/request, không cần đăng ký/ cookie/API key. Chi phí được hỗ trợ bằng đóng góp. Sử dụng thương mại cũng được." Đọc kỹ thì cảm giác có thể dùng ngay thôi. Không thấy lý do phải đặt cache server phía trước CDN. Dù vẫn có thể sẽ cân nhắc băng thông, nhưng khi có tình huống viral bất ngờ, có thể sẽ bận bịu với việc khác.
Có thể trả lời thẳng câu này: vì thứ tự ưu tiên. Mình đang vận hành một website đấu giá khá nổi tiếng và lấy tiles từ stadia maps. Mình đang trả 80 USD/tháng, biết là có thể rẻ hơn nếu cache tiles rồi phục vụ qua proxy nhưng vẫn chưa làm cache vì luôn có việc cấp bách hơn.
Lượng dữ liệu ở đây khổng lồ. Đã ghi nhận đỉnh điểm 56Gbps (56 server đã tiêu thụ 100% traffic!). Mức này không thể được bao phủ bởi một server caching duy nhất. Cần một mạng CDN cấp như Cloudflare mới gánh nổi loại case này.
Site này trông như một trò chơi và có vẻ không vì mục đích lợi nhuận. Với những site kiểu này, mục tiêu thường là 'làm cho nó chạy tốt', còn đáp ứng traffic lớn không phải ưu tiên hàng đầu. Người dùng cũng tăng gấp đôi chỉ trong một đêm, và người bảo trì có vẻ là một mình hoặc rất ít người.
Mình chưa từng dùng trực tiếp Cloudflare, và cũng không quá quen với công nghệ web map. Nếu site chủ yếu chỉ phục vụ file tĩnh, mình tò mò tại sao vẫn phải tiếp tục dùng Hetzner. Không biết liệu có thể chuyển hẳn sang Cloudflare Pages không.
Hạn chế theo Referrer (referrer) có vẻ là lựa chọn kỳ cục. Nếu người dùng bình thường 10-20 request/phút, giới hạn 100 request/phút/IP (gấp 5 lần trung bình) thì hầu như đã chặn được phần lớn rồi đúng không? Hoặc với một nhóm nhỏ kẻ xấu thì có thể chặn bằng pattern JA4/JA3 chứ?
Có khi nào người dùng thực sự muốn khám phá khắp hành tinh thôi. Mình từng nhớ mình ngồi ngắm Google Earth nửa ngày. Mình nghĩ giới hạn theo Referrer là tốt hơn; với người dùng sử dụng nhiều băng thông có thể hướng dẫn họ tự host thay vì dùng public instance.
Giới hạn theo Referrer là bước đầu tốt (có vẻ cần đổi luôn thông điệp nhắc trên trang chủ). Theo dõi mức sử dụng theo website có hiệu quả hơn. Bên phía site có thể đề nghị họ đổi pattern sử dụng, nhưng với từng người dùng cá nhân thì khó. Thêm giới hạn theo IP cũng hay, nhưng nếu đặt quá thấp thì với trường hợp này cũng sẽ không có hiệu quả.
Mình nghĩ anh đã chặn khá đẹp. Đây là cuộc tấn công DDoS. May là không phải trả thêm phí bandwidth; không thì đã thành một cuộc tấn công 'đánh nổ ví' thực sự.
Tỷ lệ cache hit rất cao. Mình tò mò liệu có kỹ thuật nào đặc biệt đang được triển khai không.