OpenFreeMap、毎秒10万リクエストを耐えた経験を共有

 (blog.hyperknot.com)
5 ポイント 投稿者 GN⁺ 2025-08-10 | 1件のコメント | WhatsAppで共有
  • OpenFreeMapは毎秒10万リクエストと日次3億件のトラフィックを成功裏に処理
  • Wplace.liveの急激な人気と自動化された大量リクエストがトラフィック急増の原因
  • CloudflareのCDNキャッシュ率99.4%、サーバーはさらに1,000 rpsも無理なくさばいた
  • そのためタイル欠落などの軽微な障害のみが発生し、サービスはほとんど正常運用
  • 今後はリファラー（Referer）ベースの帯域幅制限など自動トラフィック管理の改善を計画

OpenFreeMap の過去10か月と超大規模トラフィック対応の経験

OpenFreeMapは過去10か月間、非常に安定した運用経験を積んできた。Cloudflareの帯域幅支援、Hetznerサーバーの安定性、Btrfsでのタイルサービス、nginxの効率性のおかげでシステムの信頼性が実証された。しかしある日、突然一部のタイルがロードされないという報告があった。これは普段はアルゴリズムバグが原因だが、今回は**open() "Too many open files"**のエラーがnginxログで見つかった。

トラフィック監視ツールで確認した結果、24時間で30億リクエストが発生し、小さなタイルファイルだけで215TBのトラフィックを記録した。最近の5分間で3,000万件のリクエスト、つまり毎秒10万リクエストに達する急増があった。このトラフィックは、商用の地図サービスでは月600万ドル以上のコストになる。

Cloudflareダッシュボードでは96%が200 OKで応答し、3.6%のみが異常（206 Partial Content）だった。大半のリクエストは正常にサービスされ、欠損タイルを除けば全体システムはよく動作していることを確認した。

トラフィック急増の原因: Wplace.live

この急増の原因はWplace.liveという新しいコラボレーション描画Webサイトだ。公開直後に多数のユーザーが殺到し、これらがOpenFreeMapベースの地図を使うよう設計された。ユーザーは1ピクセル/30秒制限を回避するため、Puppeteer/Chromium、IPローテーションなどの自動化ツールを用いて大量リクエストを発生させた。

運営者は、以前にNeal.funと協業した経験を引き合いに、トラフィック発生前の事前コミュニケーションの重要性を強調している。今回はサービス運営に支障が出たため、初めてCloudflareルールを適用してブロックした。今後は referer または custom header ベースの自動トラフィック制御（Cloudflare APIの活用を含む）を検討中だ。

CloudflareのサポートとOpenFreeMapアーキテクチャの成果

Cloudflareは帯域幅支援を非常に迅速に（週末を含め48時間以内）承認し、エンジニアとアーキテクチャ適合性の検討まで進めた。大規模企業でありながら、柔軟な対応力を示した。

運営者は99.4%のCDNキャッシュ率を達成し、サーバーが1,000 rpsの負荷も耐えられたことを誇りにしている。週次データ更新を提供するサービスとしてはかなり高い成果である。

Wplace.live開発者との連携と解決提案

その後、Wplace.live開発者と連絡が取れ、200万人の急増で準備不足になったことを理解してもらえた。このサービスにはOpenFreeMapのセルフホスティングインスタンス提供を提案し、トラフィック集中を抑えて効率化を図る方針で協議した。

また、実際の200万人のユーザー数に対して30億リクエストが発生したことは、スクリプトベースの大量リクエストが圧倒的だったことを示している。一般ユーザーは10〜20回程度のリクエストで止まるため、サービスポリシーを変更して不要な自動リクエストを防ぐことを推奨している。

今後の改善と学び

運営者は2つの問題改善を予告している。

  1. リファラー（Referer）ベースの帯域幅制限

    • Cloudflareでリファラー別のリクエストを24時間あたり1億〜2億回などに制限する方法を導入予定
    • ネイティブアプリにはcustom headerを使うように誘導予定

  2. タイル欠損処理とサーバー構成の改善

    • 誤ったサーバー設定で空のタイルが生成されないよう対応予定

OpenFreeMapは現在、月額500ドルの寄付で運営している。インフラ費用は十分に賄えるが、新規開発は限られた個人時間に依存している。追加支援により開発速度とサービス安定性を拡大できる。

GitHub支援を通じてプロジェクトをサポートすることができる: https://github.com/sponsors/hyperknot

関連記事

1件のコメント

 
GN⁺ 2025-08-10
Hacker News の意見

  • 一部の画像は、スクリプトキディが描いたものではないかと推測している。このサイトは全ユーザーに対し30秒あたり1ピクセルしか許可していないため、皆がPuppeteerやChromiumで新しいブラウザーを開き、ピクセルをクリックしてからブラウザーを閉じるという形で自動化を回していたと考えている。IPアドレスのローテーションまで行っていた可能性もあるが、もしかしたらそこまでは必要ではなかったかもしれない。この現象が一晩のうちに非常に大きな規模へと拡大したことを、過小評価しないでほしい。私が自宅付近に描かれた絵を数人に言及しただけで、サイト名を挙げなかったにもかかわらず、すぐ内容を理解していた。人々はこの種の /r/place 系プロジェクトを数年ごとにかなり好んでいて、今回は世界地図の上に描けるため、自宅の近くに直接描ける点が大きな反響を呼んだようだ

  • これは、maplibre で直接 static pmtiles ファイルを読む方式だったらどう違ったかが気になる。Bunnycdn で pmtiles を range request で取得したとき、実際のタイルサーバーから受け取るのとほぼ同じ応答速度だった

    • wplace はカスタムの static pmtile1枚で全要件を満たせると思う。150GB の OSM データを処理する必要が全くないケースだ

    • 関連リンク を共有した

  • このような詳細な説明と透明性に感謝する。StatusGator の障害マップを MapTiler の代わりに OpenFreeMap 導入を検討している

    • いつでも切り替えて構わない。もし高可用性が心配なら、自分でホスティングすればよい。パブリックインスタンスをできるだけ安定させるよう、引き続き努力している

  • スクリーンショットだけ見た時は、VPS1台で十分そうに見え、設計も複雑すぎるようだった。だがピクセルが全地球の地図上に載っていることに気づいた。最大リクエスト処理量はどの程度になるだろうか。ベンチマー クしやすいWebサーバーでかろうじて捌けるレベルかもしれない。もちろん、アプリの特性上、大幅な性能低下があり得る。1kmあたり64ピクセルなら、非圧縮カラーで全地球をカバーするのに8TBが必要（長期的に見るべき問題！）。Hetznerの10TBボックスが月20ユーロなので、キャッシュは必須だと思う。wplace は描画レイヤーに1000x1000ピクセルPNGを使っていて、絵はすぐに表示されるが、地図自体はかなり遅く、場所によっては全く表示されない区間もある

    • Hetznerが月20ユーロだといいようには見えるが、実際に必要なときに常にちゃんと動くかは別の話

  • 開いたファイル数の上限が問題だったようで、その上限だけを上げればなんとかなるのではないか気になる。スパムトラフィックをブロックするのは理解できるが、理論的には上限を上げるだけでより処理できたのではないか、という疑問だ

    • 複数の LLM と長いデバッグの末に nginx コミュニティフォーラムへ質問投稿を残した。現在は multi_accept、open_file_cache、worker_rlimit_nofile の組み合わせが原因だと推定している。詳しくはこちらを参照。サーバーが200Mbpsまで使われていたため、上限を上げても長く耐えられなかっただろう

  • キャッシュが実装されていないサイトは、なぜか「めんどうだから」なのかどうか気になる。なぜ wplace.live は openfreemap にあれほど多くのトラフィックを流し、自分のサーバーにキャッシュサーバー1台置くだけで openfreemap より速いか同等にサービスできるように見えるのだろうか？

    • openfreemap はCDNの後ろにあり、ホームページにも次のように書かれている。「パブリックインスタンスは無料、閲覧回数/リクエスト数制限なし、サインアップ/クッキー/APIキー不要。費用は寄付で賄う。商用利用も許可。」とある。読むとそのまま使えそうに思える。CDNの前段にキャッシュサーバーを置く必要はなさそうだ。帯域幅を確認して検討するのはあり得るが、想定外のバイラル状況では別の作業で追われることになるかもしれない

    • この問いに答えるなら、優先順位の問題だ。私はかなり人気のあるオークションサイトを運営していて、地図タイルはstadia mapsから受け取っている。月80ドルを払っているが、タイルをキャッシュしてプロキシで提供すればもっと安くできることは分かっているが、もっと緊急のことが常にあるため、まだキャッシング作業をしていない

    • ここで扱うデータ量は膨大だ。瞬間的に56Gbps（サーバー56台が100%トラフィック消費！）が立った。単純なキャッシュサーバー1台でカバーできないレベルだ。これはCloudflareなどのCDNネットワーク級でなければ捌けない

    • 面白いサイトのように見え、営利目的ではないようだ。こうしたサイトの焦点は大体「うまく動くようにすること」にあり、大規模トラフィック対応が第一優先ではない。ユーザー数も一晩で2倍に増え、保守している人も一人か少数に見える

  • Cloudflareを直接使ったこともなく、Webマップ技術にも慣れていない。サイトがほとんど静的ファイルだけを提供しているのであれば、なぜずっとHetznerを使い続ける必要があるのか疑問だ。Cloudflare Pagesへ完全に移行できないだろうか

    • タイルはレンダリングが必要だ。よく使うタイルはすでにキャッシュされ、そのキャッシュはCloudflareが担っている。理論上、tileserverをCloudflare Pagesへ移植することは可能だが、最終的にはポーティング作業も必要で、費用がさらに安くなるとは思えない

  • リファラー（Referrer）ベースの制限は変な選択のように思える。正常利用者が1分に10〜20回リクエストするなら、IPごとに1分あたり100件（平均の5倍）制限をかければ、たいていはブロック可能じゃないだろうか？あるいは悪意ある少数ユーザーならJA4/JA3パターンでブロックできないだろうか？

    • 1人が地球のあちこちを探検したいときもある。昔、Google Earthを半日見て回ったことがある。リファラーベースの制限を置くほうがよいと思う。トラフィックを大量に使うユーザーには、パブリックインスタンスの代わりにセルフホスティングを案内できる

    • リファラーで制限するのは良い第一歩だ（メイン画面の案内メッセージも変える必要がありそう）。サイト単位で使用量を追跡する方が効果的だ。サイト側には使用パターンの変更をお願いできるが、個別ユーザーには難しい。IP単位制限を追加するのもいいが、低く設定しすぎるとこの場合は効果がないだろう

  • かなりうまくブロックできたと思う。これはDDoS攻撃だ。帯域幅料金を別途払っていなかったのでよかった。そうでなければ本当に「財布を凍結」攻撃だっただろう

  • キャッシュヒット率が非常に高い。何か特別な技術を実装しているのか気になる

    • 全体のパス構造と location block をキャッシュを前提にして設計している。気になるならnginx.conf例を見るとよい