ハクソク

世界を動かす技術を、日本語で。

OpenFreeMapは1秒間に10万リクエストを処理しました

289日前原文(blog.hyperknot.com)

概要

OpenFreeMapは過去10ヶ月で高い安定性とパフォーマンスを実現。 CloudflareとHetznerの協力で大規模トラフィックにも耐えるインフラ構築。 突如発生したWplace.liveからの膨大なリクエストで一時障害発生。 今後はrefererごとの帯域制限やサーバ設定の改善を計画。 プロジェクト支援をGitHub Sponsorsで募集中。

OpenFreeMapの運用実績と突発的なトラフィック増加

  • OpenFreeMap の直近10ヶ月間の運用、安定稼働の実績
  • Cloudflare による帯域スポンサーシップ、 Hetzner サーバの高い安定性
  • Btrfs でのタイル配信と nginx の優れたパフォーマンス
  • 予期しないトラフィック急増、 Wplace.live からのアクセス集中
  • nginxログ で「Too many open files」エラー発生、サーバリソース逼迫
  • Cloudflareダッシュボード で24時間に30億リクエスト、215TB転送量を確認
  • サービス利用料換算で月額600万ドル超のコストインパクト
  • ピーク時に毎秒10万リクエスト、驚異的な負荷

問題の原因と対応

  • Wplace.live という新規コラボお絵かきサイトがOpenFreeMapを利用
  • サイト側で1ピクセル/30秒の制限、ユーザーがスクリプトで大量アクセス
  • Cloudflare のキャッシュが効いているため、サービス自体は大部分で稼働継続
  • 96%が200 OK、3.6%が206 Partial Content（壊れたタイル）
  • サーバ側のキャパシティを超えるアクセスに対し、 Cloudflareルール で一時的に遮断
  • 今後のためにrefererやカスタムヘッダによる自動帯域制限を模索

Cloudflareとの連携と今後の改善

  • Cloudflare が迅速に帯域スポンサー承認、技術サポートも提供
  • CDNキャッシュ率99.4%、自前サーバも毎秒1,000リクエストを処理
  • Wplace.live 開発者と連絡、2日で200万ユーザーの急成長を確認
  • 自己ホスト型OpenFreeMap導入を提案、負荷分散とコスト削減を両立
  • 3億リクエスト/200万ユーザー＝1人あたり1,500リクエスト、通常ユーザーの数十倍
  • サイト側の仕様がスクリプト乱用を助長している可能性

今後の課題と支援のお願い

  • refererごとの帯域制限 をCloudflareで実装予定

  • ネイティブアプリにはカスタムヘッダで識別を依頼

  • サーバ設定の見直しで空タイル問題を根本解決へ

  • OpenFreeMapのインフラ費用は月額約500ドル、全額寄付で運営

  • 開発リソースは限られており、 GitHub Sponsors での支援を呼びかけ

学びと今後の展望

  • 突発的な大規模アクセスにも耐えるアーキテクチャの重要性
  • 事前連絡や協力体制の有無がプロジェクト全体の安定運用に直結
  • サービスは引き続き無料・登録不要で提供、ただし健全な利用のための制限導入予定
  • 新たな課題や学びについては今後も発信予定

Hackerたちの意見

この詳細な説明と透明性をありがとう！StatusGatorの障害マップをMapTilerからOpenFreeMapに移行しようか考えてるんだ。

└

移行しても全然大丈夫だよ。高可用性が心配なら、セルフホスティングも選択肢としてあるしね。でも、公共インスタンスをできるだけ信頼性の高いものにするために頑張ってるよ。

何が起こっているかというと、その画像はスクリプトキディたちによって描かれていると思う。 絶対に違うよ。自閉症の人たちが本当に没頭して、wplaceで大きなアートを共同制作しているのをたくさん見てきたから。スクリプトキディだけじゃないよ。 30億リクエスト / 200万人のユーザーは、ユーザーあたり平均1,500リクエストだね。普通のユーザーは地図を読み込むときに10〜20リクエストくらいするから、これは非常に高い、スクリプトを使った使用例だと思う。 それについても分からないけど、ユーザーはただ地図を読み込むだけじゃなくて、周りを見回して他の人が作ったアートを探したり見ることもしてるよね。「何時間も地図を探索する」ためのリクエストがどれくらいかは分からないけど、そういうことをしてる人は多いと思う。自動化を完全に否定するつもりはないけど、これらの使用パターンは全然不可能じゃないと思う。特にwplaceは急に人気が出るとは思ってなかったから、トラフィックパターンを最適化できてなかったかもしれないしね。

└

地図にテンプレートを重ねたり、一緒に作業するためのユーザースクリプトはいくつかあるけど、それが負荷を大きく増やすとは思えないな。むしろ、wplaceが負荷に苦しんでいて、ピクセルを配置したり変更を確認するためにリフレッシュしなきゃいけないから、それが1時間あたりのリクエストを増やしてるかもしれないね。

└

ネットワークモニターを開いて2-3分ちょっとスクロールしただけで、もう500リクエスト、5MB転送されたよ（ベクタタイルデータでフィルタリングした後）。ブラウザが実際のリクエストなしでどれだけキャッシュしたのか、ヘッダーだけ交換してキャッシュされたのか、Cloudflareがキャッシュしたのかはわからないけど、典型的なユーザーは埋め込み地図フラグメントを使ってるから、リクエストは10-20件くらいだと思う。大体、連絡先ページにあるような地図で、ほとんどのユーザーは全然スクロールしないか、少しズームアウトするくらいだし。

リファラーで制限するのは変だね。普通のユーザーが1分あたり10〜20リクエストするって分かってるなら、IPごとに1分あたり100リクエストにレート制限すれば（平均負荷の5倍）、大半のケースをブロックできるんじゃない？それとも、悪質なユーザーが数人だけなら、JA4/JA3フィンガープリンティングでブロックすればいいんじゃない？

└

もし1人のユーザーが本当に世界をブラウズして地図を探索したい場合はどうなるの？Google Earthのデスクトップで面白い場所を探索してたら、30分も経ってたことを覚えてるよ。リファラーに基づく制限の方がいいと思う。そうすれば、利用頻度の高いユーザーには公共インスタンスじゃなくてセルフホスティングを選んでほしいってお願いできるし。

└

リファラーで制限するのは、たぶん最初の正しいステップだね。（それとフロントページのテキストを変えること）サイトごとの利用状況を追跡したいから、個人ではなくて。サイトのユーザーにお願いするのは難しいけど、サイトには利用パターンを変えるように頼めるから。IPごとの制限も意味があるかもしれないけど、あまり低く設定すると、こういうのには効果的じゃなくなっちゃうよね。

キャッシュヒット率がすごいね。これに特化して実装したことってあるの？

└

うん、キャッシングを考慮して全体のパス構造やロケーションブロックを設計したんだ。興味があれば、生成されたnginx.confをここに置いておくよ: https://github.com/hyperknot/openfreemap/blob/main/docs/asse...

wplace.liveみたいなサイトがキャッシュを実装してないのって、いつも「怠慢」ってことなの？（ちょっと失礼だよね）なんで彼らは、キャッシュサーバーがあればopenfreemapのトラフィックを全部保存できるのに、やらないんだろう？

└

これに関しては、優先順位が理由だよ。俺は結構人気のオークションサイトを運営してて、スタディアマップ経由で地図タイルを使ってる。月に約80ドルかかってるけど、タイルをキャッシュしてプロキシから提供すれば、もっとコストを下げられるはず。でも、他の優先度の高いタスクが常にあるから、まだ手をつけられてないんだ。

└

面白そうなサイトだね、営利目的じゃない感じ。楽しさを重視するサイトは、スケールを扱うよりも、まずは動かすことが大事だと思う。ユーザーベースが一晩で爆発的に増えて、14時間ごとに倍増してるみたいだし。運営の言葉からすると、個人開発者か少人数のグループっぽいね。

└

ここで話してるのは、ものすごいデータ量だよ。56 Gbit/s（56台の1 Gbitサーバーが100%稼働してる状態！）。これは「キャッシュサーバー」じゃ対応できないレベル。CDNネットワーク、例えばCloudflareみたいなのが必要だね。

└

なんで彼らがやる必要があるの？openfreemapがCDNの背後にあって、彼らのホームページにはこんなことが書いてあるから： 「私たちの公共インスタンスを使うのは完全に無料です：マップビューやリクエストの数に制限はありません。登録も不要、ユーザーデータベースもなし、APIキーもクッキーもありません。私たちは寄付で公共インスタンスの運営費を賄うことを目指しています。」 「商業利用は許可されていますか？」 「はい。」 これを読んでそのまま使うのは、すごく理にかなってると思う。彼らが「大丈夫、制限なし、無料だよ」って言ってるのに、なんでCDNの前にキャッシュを置く必要があるの？もし帯域幅がどれくらい使われてるか知ってたらちょっと気になるかもしれないけど、サイトが予想外にバイラルになったら、他のことに忙しいかもしれないし。

あなたが直面した制限がオープンファイルの数だったなら、その制限を上げることはできなかったの？スパムトラフィックをブロックするのは理解できるけど、理論的にはその制限を上げればもっと処理できたんじゃない？

└

さっき、nginxコミュニティフォーラムに質問を書いたところだよ。複数のLLMと長いデバッグセッションの後に。今のところ、multi_accept + open_file_cache > worker_rlimit_nofileの組み合わせが原因だと思ってる。https://community.nginx.org/t/too-many-open-files-at-1000-re... それに、サーバーは200 Mbpsの速度で動いてたから、制限に関係なく、あんまり長くは持たなかったと思う。

まだCloudflareを直接使ったことはないし、ウェブマップ技術にも詳しくないんだけど、もしサイトが静的ファイルをたくさん提供してるだけなら、なんでHetznerが関わってるの？Cloudflare Pagesに完全に移行するのは無理じゃないの？

└

タイルはレンダリングする必要があるよね。頻繁に使われるタイルはキャッシュできるけど、もうキャッシュはあるし…それがCloudflareだから。理論的にはタイルサーバーをCloudflare Pagesに移すこともできるけど、そのためには…移さなきゃいけないし、たぶん安くはならないと思う。

スクリーンショットを見て思ったんだけど、これって1台のVPSでできるんじゃない？ちょっと過剰設計に見えた。で、気づいたんだけど、あのピクセルが地球全体のマップの上に乗ってるんだ。すごい！ピークのリクエスト数がどれくらいか気になるな。たぶん、ベンチマークに優しいウェブサーバーがサポートできる範囲ギリギリだと思う。アプリケーションの性質によっては、何かしらのオーダーオブマグニチュードの遅延があるかもしれないけど。

私が思うに、あの画像はスクリプトキッズによって描かれているんだと思う。もし私の理解が正しければ、そのウェブサイトは誰でも30秒に1ピクセルに制限していたから、みんなPuppeteerやChromiumを使って新しいブラウザを立ち上げて、ピクセルをクリックして、ブラウザを閉じるということを繰り返していたんじゃないかな。IPアドレスを回転させていたかもしれないけど、もしかしたらそれは必要なかったかも。これが一晩でこんなに大きなことになったとは、あなたはちょっと過小評価してるかも。私が家の上の絵を数人に話したら、ウェブサイトの名前を言わなくてもみんなすぐに何を指しているか分かったよ。人々は数年ごとに/r/placeスタイルのものが大好きで、こんなに大きなキャンバスがあって世界地図に載ってるから、みんなが自分の住んでる場所に描くスペースがたくさんあるんだ。

すごい… 彼らを禁止するのは良い判断だったね。これはDDoS攻撃だし、帯域幅にお金を払わなくて済んでラッキーだね。財布を否定することになるから。