OpenFreeMap、毎秒10万リクエストの猛攻を耐え抜いた！
引用元：https://news.ycombinator.com/item?id=44846318
\u003eスクリプトキッズが画像描いてるって信じてるよ。ウェブサイトは1ピクセル/30秒の制限だけど、みんなPuppeteer/Chromium使って新しいブラウザ立ち上げてピクセル打って閉じてるんだろ。IPアドレスも要らないかもな。お前はこの現象を舐めてるよ。みんな/r/placeみたいに、自分の住んでるとこ描きたがるんだよな。
1ピクセル/30秒どころか、20ピクセル/30秒くらいだよ。それに“タンク”があって、いくらでも大きくできるんだ。ピクセル置くとポイントもらえて、それをピクセルやタンク拡張に使える。4000ピクセル持ってる人も見たことあるぜ。
\u003eお前はこの現象を舐めてるよ。記事でサイトに直接聞いて、トラフィック数知ってるんだから、見積もる必要ないだろ。推定200万ユーザーだってよ。ユーザーあたり1500リクエストってことは、相当なスクリプトが動いてるってことだよな。
\u003eお前はこの現象を舐めてるよ。みんな instantly knew って言ってるけど、こっちは初めて聞いたぜ。
こういうピクセル描画は知ってたけど、それは空のキャンバスの上だったんだよね。
開発者から聞いたユーザー数は200万人だろ。毎日200万ユーザーが、一部がbotじゃなきゃ何十億ものリクエストを生み出すはずないよな。
なんで？これタイルリクエストだろ？ログインじゃない。ユーザーは地図見て動き回るから、数千リクエスト消費するの普通じゃないか？ボットはいるだろうけど、半分近くが“正当”なトラフィックでも驚かないね。ボットはマップタイルを読み込む必要もないしさ。
\u003eスクリプトキッズが描いてる？いや、絶対違うよ。ノライフででっかいアート作ってるアスペルガーの人たちをたくさん見たし。\u003e1500リクエスト/ユーザー。これも違うと思うな。みんなアート見にマップ中を動き回るからね。自動化を否定はしないけど、この使い方は不可能じゃない。wplaceは人気を予想してなかったから、最適化も足りなかったかもな。
ネットワークモニター開いて2～3分スクロールしただけで500リクエスト、5MB転送されたよ（ベクタータイルデータでフィルタ後）。ブラウザやCloudflareのキャッシュでどれくらい減るかは不明だけどね。たぶん一般的な10～20リクエスト/ユーザーってのは、ほとんどスクロールしないような埋め込みマップの場合だろ。
ユーザーがマップにテンプレートを重ねるスクリプトを使ってるけど、それが負荷を増やしてるとは思えないんだよな。それよりwplaceが重くて、ピクセルを置いたり変更を見るのにリフレッシュが必要だから、それが毎時間の呼び出しを増やしてるのかもしれないね。
この詳細な分析と透明性、ありがとう！StatusGatorの障害マップで、MapTilerからOpenFreeMapへの移行を考えてるんだ。
自由に移行していいよ。もしHigh Availabilityが心配なら、セルフホスティングも常に選択肢だよ。でも、僕はパブリックインスタンスをできるだけ信頼性高くするために頑張ってるからね。
スクショ見て、これ単一VPSでいけるんじゃ？って思ったけど、地球全体の地図にピクセルがあるって気づいてやられたわ！ピーク時のreq/sがどうなってるか気になるなー。ベンチマーク向きのWebサーバーならギリギリいける範囲かも？アプリの性質上、桁違いに遅くなる可能性もあるけど。
追記: 1kmあたり64ピクセルらしいね。地球全体をフルカラー非圧縮で覆うと8TBくらいになりそう（長期的には！）。Hetznerなら10TBの箱が月20ユーロだって。キャッシュは絶対必要だろうね ;)
追記2: wplaceは描画レイヤーに1000x1000pxのPNGを使ってる。描画はすぐだけど、マップ自体は今すごく遅いし、一部のチャンクは永久に表示されないんだ。
「Hetznerで月20ユーロ」ってのは、本当に必要な時にちゃんと動いてくれてる間は最高だよね。
＞「Hetznerで月20ユーロ」ってのは、本当に必要な時にちゃんと動いてくれてる間は最高だよね。僕はいくつかのHetzner Cloudインスタンスを管理してるけど、中には1年以上完璧な稼働時間を報告してるものもあるよ。動かないやつは、僕が原因だったな。なんでそんなこと言えるの？なんかデータでもあるの？それともただ適当に言ってるだけ？
＞なんでそんなこと言えるの？
https://news.ycombinator.com/item?id=29651993
https://news.ycombinator.com/item?id=42365295
https://news.ycombinator.com/item?id=44038591
＞それともただ適当に言ってるだけ？
皮肉はやめなよ。攻撃的な言葉は削除して。
https://news.ycombinator.com/newsguidelines.html
今、3つのリンク全部チェックしたけど、君が言うよりもっとニュアンスが複雑みたいだね。
これって全部Hetzner Cloudの提供サービスみたいだね？
僕の経験だと、Hetznerは信頼できないってわけじゃないよ。ただ、単一VPSで毎秒10万リクエストは無理だと思うな。（あと、専用サーバーだと、冗長性は自分で管理する責任があるけど、これは他の専用サーバーでも同じだよね。）
サポートの技術力がゼロだから、彼らは信用できない。ドイツ側の部署と取引するとなると、返答に2週間もかかるし、それでも間違った情報が来る。彼らは単純に手間がかかりすぎるんだ。まともなホストを使えよ。
理想を言えば、みんな優秀なホスティング会社を使いたいけど、無料や低収益のプロジェクトには向かないんだよ。サービスを停止するより、多少のダウンタイムがある方がマシだ。OpenFreeMapとwplace、両方ともHetzner、OVH、Scalewayが良いんじゃないか。コストが抑えられるから、万が一のために別の安いプロバイダーで冗長化もできるぞ。
サポートの技術力がゼロだって？俺はサポートに頼る必要ないから完璧じゃん。Hetznerでサポートが必要ってことは、お前がホストを選ぶのを間違ってるだけだろ。
“ipfs daemon”を動かしただけで、Hetznerがサービス停止をちらつかせてきたんだ。PCAPダンプ付きで「ハッキング」って警告文が来るし、こっちが正しくても関係ないんだよ。
そんなことないだろ。俺はipfs daemonを動かしたけど、変な手紙なんて来なかったぞ。Tor relaysへのletterbombing攻撃の時は手紙が来たけど、Hetznerに攻撃のページを見せたら止まったしな。
お前、本番環境に移行して2日後に、トラフィック全部ブラックホールにされたことないのか？運がいいな。
俺はどこかに移行する時、心配だから前のサービスは1ヶ月は動かしたままにする。本番のトラフィックがブラックホールになるってことはないけど、似たようなことだろ。
良いアイデアで面白いプロジェクトだな。次は事前に連絡してくれよ。俺の人気サービスでお前の人気ないやつが止まるかもだけど、そっちでAPIの性能がわかるようにしとけ。レートリミットなしのAPIなんてホストしないし、利用制限もちゃんと書いておけよ。
無料のオープンサービス使うくせに、ずいぶん傲慢な期待だな。リクエストは分散クライアントから来てたんだから、レートリミットに応答できるAPIゲートウェイからじゃない。お前は「APIにレートリミットをかけろ」「利用制限を明確に書け」って言うけど、あれは中央のAPIキーからじゃない。OpenFreeMapはボットやスクリプトが原因で、wlive.placeのユーザー1人につき1500リクエストって計算が出てる。実質DDoS並みの負荷だったんだよ。
URL originでブロックされてるんだから、レートリミットも同じようにできるはずだろ。サイト利用者からのAPIならそれで問題ないはずだ。ボットはOpenFreeMapのタイルに興味ないから、サイトを介さないボットは来ないって。
うーん、それなら同意するよ。だってこれじゃDDoS攻撃と見分けがつかないじゃん。
もっとコメントを表示（1）
無料サービスが秒間10万リクエストとかの「ハグ・オブ・デス」にgracefully対応できるって思うのは無理があるよね。実際耐えたのはマジ例外だし。一時的にでも秒間10リクエスト以上無料サービスに当てるのは、正直「つけこんでる」って言われても仕方ないと思うな。
＞事前に連絡してって言われても、プロジェクトがバズるなんて予測できないじゃん。
＞お前がサービスを壊したって言うけど、それって高すぎる fd limit のせいじゃない？無制限って宣伝しといて、使いすぎたユーザーを責めるのはマジないわ。ユーザーが悪意を持ってAPIを叩いたわけじゃないんだし。
お前、マジで図々しいな…。お前みたいな奴がいるから、せっかくの素晴らしいものに「無制限だけど…」みたいな但し書きがついちゃうんだよ。人のインフラをストレステストするなんてありえない。マジで良くない。この記事の作者はすごく理解があって、ブロックした後でも解決策を提示しようとしてくれたんだぜ。無料サービスなのに。お前がやったこと、見せてみろよ。
＞図々しいって言うけど、それが契約ってもんだろ。ハンバーガーを5ドルで売ると言ったら、5ドル払った客はハンバーガーをもらう権利があるだろ？
＞無料サービスなのにって言うけど、サービスの値段を決めるのは所有者だろ。制限なしでトラフィックが多すぎてパンクするのは、無料サービスに限った問題じゃないんだよ。
＞SLA保証や個別サポートを提供してますか？
＞今のところ、SLA保証や個別のサポートは提供していません。
これ、ウェブサイトに書いてあったことだよ。
確かに、ハンバーガーの例は完璧だね。5000個もまとめて注文するなら、店は値段通り売ってくれるだろうけど、「それだけの量を捌くには事前連絡が必要だよ」って言うだろ。マジで完璧なアナロジーだよ。この作者は状況に完璧に対応したと思う。
でもこの場合、レストランは、もし自分たちで勝手に店員の手を縛って邪魔してなかったら、5000個の注文を処理できたはずなんだよ。そして、店員の手を解いて、偶発的にボトルネックになってたことに気づいたのを評価する代わりに、彼らは客足の増加を引き起こした近くのイベントを非難したんだ。
ユーザーを公に攻撃するんじゃなくて、彼らの成功と自分の新しい学びを祝うべきだよ。俺は、人々が目標達成にどうプラットフォームを使ってるかを祝う「ハロー効果」戦略の方が、その価値を理解して採用したり財政的に支援したいと思わせるのに役立つと思うな。一方で、プラットフォームを使ってる人を公に攻撃したら、自分も批判されるんじゃないかって使いたくなくなるだろ。
ハンバーガーの状況は比較にならないね。あれは商売だろ。これはただ、誰かが自分のPCにあるテキストファイルに、あんまり詳しくないことを書いただけなんだから。俺もそういうメモたくさん持ってるし、中には公開してるやつもあるよ。
彼にサービスを壊れたままにさせるか、それともこのボランティアプロジェクトのために自己負担で無限にスケールアップするのを期待するのか？彼は、文字通り何の義務もないのに、プロジェクトの作者と協力して、両方にとって機能して、他の全ユーザーのサービスを悪化させない解決策を見つけたんだ。
これは、月に何百ドルも払ってるユーザーをスロットリングするAnthropicの決定とは違う。建設的な批判はいいけど、個人ボランティアが無料で運営してるものに権利を主張するのはありえないだろ。
このプロジェクトページは無限のコストになる可能性を示唆してるみたい。財政的には、帯域をカバーするまでサーバーを借り続ける計画だって。サポートプランに十分な人が加入すれば自己持続可能になるって信じてるよ。CloudflareがCDNを無料で提供してるから特にね。オリジンサーバーの運用は金がかかるけど、fd制限は通常低いから、もっと高く設定できる。いつかI/O制限にぶつかるだろうけど、俺のざっくり計算だとオリジンでのI/Oはかなり管理しやすいように見えるな。もしファイルが全部小さくて、fd制限が本当のボトルネックなら、それもうまくやる方法はあるよ。俺の意見だと、ファイルを読み込むためのfdが確保できないなら、そもそもインバウンド接続を受け入れる意味がない。だから、同時接続を制限して、接続をlistenキューで待たせ、短いkeepaliveタイムアウトでアイドル接続にfdを無駄にしないようにするのがいい。他の知識がないなら、オリジンサーバーがこれ専用で静的ファイルだけを扱うとして、接続制限はFD制限の半分にするね。でも、正直に言って、こんなの立ち上げたらFD制限については、ぶつかるまで考えなかっただろうな。大したことないよ…願わくば、監視ツールがデフォルトで利用可能なfdを含んでいて、気づいてくれるといいんだけど、どこでもデフォルト出力ってわけじゃないからな。
俺たちが話してるのは、固定された静的ファイルをホスティングすることだぜ。これは解決済みの問題だろ。大規模なAIモデルを人々のために動かすのとは全然違うんだよ。
無制限のサービスを無料で運営するのは、1リクエストをさばく限界コストにかかってるよ。
面白いことに、彼のサービスは壊れてないんだぜ。Cloudflareのキャッシュが99%のリクエストを処理したからね。ただ、力を示したかっただけで、最新のバズトレンドを壊したかっただけだろ。
遭遇した制限がオープンファイルの数だったなら、その制限を上げればいいんじゃない？スパムトラフィックをブロックするのはわかるけど、理論的にはその制限を上げたらもっと捌けたんじゃないの？
複数のLLMと長いデバッグセッションの後、Nginxコミュニティフォーラムに質問を書いてみたんだ。今のところ、multi_accept + open_file_cache ＞ worker_rlimit_nofileの組み合わせが原因だったと思ってる。
https://community.nginx.org/t/too-many-open-files-at-1000-re…
それに、サーバーは200 Mbps出てたから、制限がどうあれ、これ以上は長くは持たなかっただろうね。
お前のopen file cacheはデカすぎると思うよ。1k/秒で60分キャッシュするなら、全部ユニークだと仮定して300万FDのキャッシュを要求してることになる。利用可能は100万しかないのに。俺はNginxもopen_file_cacheも使ったことないけど、設定を大幅に下げて、通常の運用でパフォーマンスに違いが出るか試してみたら？例えば、1万ファイル、60秒タイムアウトとかね。200 Mbpsでシステム過負荷かコストか？ストレージの種類は？ディスクI/Oは監視してる？CPUは何使ってる？俺はデュアルE5-2690でHTTPSで10GBps近く出したことがあるけど、ファイルはもっとデカかった。2690sはハイエンドだったけど、もっと新しいのはAESアクセラレーションがずっと良くて、何にせよ200 Mbpsよりははるかに良いはずだぜ。正直言うと、open_file_cacheの意図がよく分からないんだ…ファイルを開くのは通常そんなにコストがかからないしね。何十万rpsとか、非常に複雑なファイルシステムとかでない限りは。PS: 何万ものファイルを1つのディレクトリに入れるなよ。100個のディレクトリにそれぞれ100個のファイルを入れるみたいに、ファイルを分割すると何でもうまくいく。負荷に合わせて実験してみるといいけど、N層のMディレクトリがあって、最後の層にM個のファイルがあるツリー構造が良い計画だ。64 ＜= M ＜= 256で。ディレクトリをコンパクトに保って、検索や編集が効率的になるのが目標だぜ。
https://www.intel.com/content/www/us/en/products/sku/64596/i…
俺、ちょっとヒントがあるかも—Nginxがダイヤルアップ時代に作られたこと、覚えてる？Pentium 3のサーバーが標準だった頃だ（俺もその頃のRambler DCでwwwXXXマシンを見た覚えがあるよ）。だから、俺のちょっとした educated guessだけど、あらゆるシステムコールを節約するのが究極の目標だったんじゃないかな。当時は少なくともレイテンシの面で効率的だったんだよ。NginxがHTTPメソッド（GET/POST）をどう解析してオペレーションを節約してるか、見てみてもいいかもね。俺自身はopen_file_cacheを使って大きなメリットを感じたことはないけど、ちゃんとしたパフォーマンステストをしたことはないんだ。例えば、sendfileやbuffers、TLS terminationの使用を確実にする方が、現代の（10～15年前の）ハードウェアではずっと大きな影響があったね。
Cloudflareのキャッシュ後で200Mbpsだと、Hetznerのトラフィックにすぐ達しちゃうよ。月20TBが上限だから、およそ9日で到達する計算だね。
VMの話をしてるんだろ？VMにはトラフィック制限があるよ。でも、物理サーバーは普通1Gbit NICがついてるから制限はないはずだ（何ヶ月も帯域の80%以上使うまでは、だけどね）。引用するとね、
＞トラフィック
＞すべてのルートサーバーはデフォルトで専用の1Gbitアップリンクを持ってて、トラフィックは無制限。10Gアップリンクのサーバーだと月間20TBが含まれてる。帯域制限はないけど、20TB超えたら1TBあたり1ユーロ（1.20ドル）かかるよ。
へぇ、俺が契約終えた数年前とは変わったんだな。archive.orgで見たら、少なくとも5年前から無制限だったみたいだ。誰かが20TBって言ってたのを聞いて、妥当な制限だと思っちゃったんだろうな。
OpenFreeMapみたいなサービスって、外部のオンラインサービスに頼るんじゃなくて、自前のサーバーラックを持つべきじゃないのか？最近はそういうのってあり得ないのかな？
ちょっと補足だけど、その制限はHetzner Cloudサーバーの話ね。専用サーバーはトラフィック無制限だよ。
接続によるんじゃないかな。俺のは1Gbit＼secだけど20TB制限がある。100Mbitのは無制限だったな（最後に確認した時だけど）。
そうそう。1Gbit＼sの専用サーバーはトラフィック無制限で、10Gbit＼sは20TBのトラフィックが含まれてるんだ。100Mbit＼sのオファーは知らないな。どのオファーを使ってるか分からないけど、Hetzner Cloudサーバーじゃなくて専用サーバーの話に聞こえるね。
空のタイルファイルを実際に作って、必要な場所全部にハードリンクするっていうのがいいかもね。そうすれば実行時に特別な処理は要らなくて、生成時に済む。NVMeディスクはめちゃくちゃ速いし、1k rpsなんて大したことないよ（俺のn100でも1Gbit NICがボトルネックにならなきゃ40kくらいはいけたはず）。チューニングオプションなしでベンチマーク試してみたら？Cloudflareから実際に40k同時接続来てるのか？
ああ、それは良いアイデアだね。でも、タイルの90%以上が空（もしかしたら間違ってるかも）って話だから、ものすごい数のハードリンクになるよ。nginxの設定を直す必要があると思う。フォーラムで助けが得られるといいんだけど。
ファイルディスクリプタキャッシュをオフにするのも試してみたら？NVMe SSDは並列処理なしでも毎秒30〜50kのランダムリードができるし、並列処理があれば数十万だって可能だよ。だから、リクエストごとにディスクを10回叩いたとしても大丈夫なはず。カーネルキャッシュもあるしね、nginxのメタデータキャッシュの一部はそれで賄われるんじゃないかな？
”いくら制限があっても、これ以上長くは持ちこたえられなかった”って引用だけど、なぜそのレートだと時間が経つと問題になるの？
へー、OpenStreetMapを見るシンプルな方法がやっとできたんだね！ ずっと待ってたから嬉しいよ！
本家のサイトに何か問題あったの？ 純粋な疑問なんだけど https://www.openstreetmap.org
もっとコメントを表示（2）
えーと…俺が最後に見た時はそれ無かったけど？
OSM Foundationは何年も前からラスタタイルを提供してるよ（www.openstreetmap.orgのマップでデフォルトで見えるやつね）： https://wiki.openstreetmap.org/wiki/OpenStreetMap_Carto
いろいろなコントリビューターが試行錯誤した結果、OSMFはついにベクタータイルもリリースしたんだ： https://operations.osmfoundation.org/policies/vector/
ありがとう、俺が情弱だったわ
…そしてその後、毎秒100万リクエストになったと！
それって、毎秒1,000リクエストを彼らが耐えて、残りの毎秒99,000リクエストはCloudflare CDNが耐えたって感じだね
リファラーでの制限は変じゃない？ 普通のユーザーが毎分10～20リクエストするとして、IPアドレスごとに毎分100リクエスト（平均の5倍）に制限すれば、大半のケースをブロックできるんじゃない？ 少数の悪質な利用者ならJA4/JA3フィンガープリントでブロックするとか？
もし一人のユーザーが世界中を巡ってマップを探検したい場合はどうなるの？ Google Earthのデスクトップ版で30分も面白い場所を探索したの覚えてるよ。リファラーベースの制限の方が良いと思うな。そうすれば、たくさん使うユーザーにパブリックインスタンスじゃなくてセルフホスティングを選んでって頼めるし
リファラーによる制限は最初の適切なステップだろうね。（フロントページのテキスト変更も）ユーザーじゃなくてサイトごとの利用状況を追跡したいんだろ？ だって、サイトには利用パターンを変えてって頼めるけど、ユーザーには無理だからね。IPアドレスごとの制限もアリだけど、これに効果的なほど低くはしたくないだろうし
wplace.liveみたいなサイトがキャッシュしないのって、いつも「怠慢」なのかな？なんで自分たちでキャッシュサーバー使って、OpenFreeMapのトラフィックを減らさないんだろう？OpenFreeMapより速くタイルを提供できるのにさ。
OpenFreeMapがCDN使ってて、「完全に無料、リクエスト数無制限。商用利用OK」って言ってるのに、なんで彼らがキャッシュする必要あるの？彼らが「ぜんぜんOK、無制限、無料」って言ってるんだから、そのまま使うのが理にかなってるでしょ。トラフィック量が気にならないわけじゃないけど、もしサイトが急にバズったら、他のことで忙しくなるだろうしね。
礼儀と速度の問題？でもプロジェクトのアーキテクチャ次第だよ。タイルがクライアント側でしか使われないなら、自分のサーバーでキャッシュする理由なんてほとんどないね。それは自分がOpenStreetMapよりキャッシュが上手いってことになっちゃう。それにシステムを needlessly に複雑にするだけだ。OpenStreetMapも怒る理由なんてないよ。だって俺が200万リクエストしてるわけじゃなくて、200万人の別々のユーザーが使ってるんだから。これはOSMとその派生作品をもっと多くの人に使ってもらうという彼らの動機と一致してるし、問題ないよ。
それを読んだら、「突然金を払えって言われることはないな」って安心するべきだよ。それで「みんなのために無料提供を守るために、こっちでキャッシュを実装しよう」って思うのが普通じゃない？本気で、「よし、これを悪用できるぞ」って最初に考えるやついる？
「悪用できない」って考え続ける必要はないよ。ただ考えるのをやめればいいだけさ。
これには直接の答えがあるよ。それは「優先順位」だね。
俺は結構人気のあるオークションサイトを運営してるんだけど、Stadia Maps経由で地図タイルを使ってる。このサービスには月80ドルくらい払ってるんだ。タイルをキャッシュしてプロキシから提供すれば、もっとコストを下げられるのは確かだけど、まだこれに取り組む時間が取れてないんだ。いつももっと優先度の高いタスクがあるからね。
ここではとんでもない量のデータが問題になってるんだ。56Gbit/sだよ（1Gbitサーバー56台が100%フル稼働してる計算だね！）。
これは普通の「キャッシュサーバー」が扱えるレベルじゃない。CloudflareみたいなCDNネットワークの規模じゃないと無理な話さ。
＞ここではとんでもない量のデータが問題になってるんだ。56Gbit/sだよ。これは普通の「キャッシュサーバー」が扱えるレベルじゃない。
56Gbit/sなら、とんでもないデータ量ってわけじゃないよ。もちろんキャッシュサーバーで処理できるさ。情報源：古いクアッドコアで40Gbit/s（TLS付き）を飽和させたサーバーを書いた経験がある。
OK、技術的にはそういうサーバーも存在するのかもしれないね、Netflixとかが使ってるやつかな。でも、ここで話してるのはコミュニティに支えられた無料サービスだよ。Hetznerサーバーしか選択肢がないんだ、無制限の帯域幅だからね。
アクティブなデータがRAMに収まるなら、市販のハードウェアとソフトウェアで全く問題ないよ。40ギガのNICを2枚ぶっ刺してVarnishとか入れればOKさ（もちろん、ユーザーへの帯域幅にお金を払う人がいる前提だけどね！）。
データの大部分をディスクから提供する必要があるなら話は別だけど、Netflixは3年前から800ギガを（大部分がディスクから）やってたし、OSの選択で自分たちでスケーリング作業をかなりやる必要があって不利な状況だったのにね。
サーバーのハードウェアは問題ないと思うよ。全データが150GBでサーバーには64GBのRAMがあるけど、ほとんどはリクエストされないだろうから、使われるタイルはOSキャッシュから提供されるはず。もしダメでもRAID 0のNVME SSDにローカルで接続されてるしね。
俺が言ってたのは、無制限の1Gbps接続でさえ結構高いのに、2x40ギガの接続なんてリーズナブルな値段で見つけるのが難しいってことだよ。あのユーザーは24時間で200TBも生成したんだって！帯域幅の料金は全然知らないけど、それを賄うのは絶対安くないはずだ。
うーん、「帯域幅は高い」ってのはその通りなんだけど、「普通のキャッシュサーバーが56Gbit/秒を処理できない」ってのは、全く別の話じゃない？
君の言う通りだよ。俺は「そっち側のキャッシュサーバー」ってのを、VPSで動いてる個人のホビープロジェクトが週末に急にトラフィック爆増したって文脈で考えてたんだ。そういうサーバーが存在するし、いくつかの会社は通常のオペレーションの一部としてその帯域幅にちゃんとお金を払ってるってのは同意するよ。
Hetznerでさえ、56Gbit/秒は1日あたり約590ユーロかかるんだぜ。
「ぶっ飛んでる」ってのが主観的な判断だってのは分かってるんだけど、でも、うーん…56Gbpsは間違いなくぶっ飛んでるって言うね。それを扱えるハードウェアが存在しないって言ってるわけじゃないし、特にぶっ飛んだハードウェアじゃなくてもいいかもしれないけど、俺の基準ではかなりぶっ飛んだデータレートだよ。
＞または56台の1Gbitサーバーが100%飽和
おそらくキャッシュサーバーは10GbE、40GbE、または100GbEだろうね。
56Gbit/秒の事前生成データは、各リクエストが大量のランダムディスク読み込みを生成しない限り、1台か2台の良いサーバーで確実に処理できるよ。
NginxがN150で静的ファイルを配信して10Gbitリンクを使い切れないのはちょっと驚きだね。だから、200ドルのミニPCが6台あれば処理できると思うよ。一番お金がかかるのはホスティング／接続だろうけどね。
楽しそうなウェブサイトだね、営利目的じゃないみたいだし。楽しいウェブサイトの期待や焦点は、規模を捌くことより、とにかく動かすことにあるもんね。ユーザーベースが夜中に爆発的に増えて、約14時間ごとに倍増してるみたいだし。それに、メンテナの言葉遣いからすると、一人でやってるか少人数のグループって感じだね。
CDNとかクラウドストレージプロバイダーが、PMTilesファイルを共有ライブラリとして顧客に提供しないのは本当に驚きだよ。きっと彼らは、顧客それぞれに120GBのファイルをアップロードさせて、個別に料金を請求する方が好きなんだろうね。
もし賢ければ、ストレージの設定で基盤インフラには実際のコピーが1つしかなくて、他のシャドウコピーは全部純粋な利益になるようにしてるはずだけどね。
