低遅延のための VPS ロケーションの選び方

vCPU の数を何時間も比較したあげく、サーバーを別の大陸に置いてしまう人がいます。インタラクティブなもの（シェル、API、ゲーム、取引所と通信するボット）では、ハードウェアよりロケーションのほうが重要なことがよくあります。良い知らせは、遅延の大半は物理法則なので、支払う前に予測し測定できることです。

物理法則を一行で

光ファイバー中の光は 1 ミリ秒あたり約 200 km 進みます。ケーブルはまっすぐ敷かれておらず、ルーターごとに少しずつ遅延が加わるため、確かな目安は実際の距離 100 km あたり往復約 1 ms です。

どれだけ CPU を積んでも、往復 200 ms は解決できません。ユーザーが東京にいるなら、ドイツのサーバーはどれほど速くても遅く感じられます。

「近い」の意味は用途で変わる

Web サイトや API。 ユーザーの多数派の近く。CDN は静的ファイルの距離を隠してくれますが、最初の HTML レスポンス、ログイン、API 呼び出し、動的なものすべては結局オリジンまで届く必要があります。

トレーディングボット。 あなたではなく、取引所の API サーバーの近く。あなたがどこにいるかは関係なく、ボットは 1 日に何百回も取引所と通信します。アービトラージでは数ミリ秒ごとが効きますが、1 日に数件の注文しか出さないボットなら 30 ms は何の違いも生みません。詳しくはトレーディングボット向け低遅延 VPSをご覧ください。

モデル API を呼び出す AI エージェント。 ロケーションはほとんど関係ありません。モデルが答えるまで数秒かかり、30 ms のネットワークは誤差です。価格とプライバシーで選びましょう。

ゲームサーバー。 プレイヤーの近く。ほとんどのゲームは約 60 ms 未満なら快適ですが、競技系のシューターはずっと低い値を求めます。

リモートデスクトップと SSH。 あなたの近く。150 ms の遅延でタイピングするのは苦痛です。

自分で測る

自分のマシン、またはユーザーの近くのサーバーから、候補ロケーションまでの経路を確認します。

mtr -rwc 50 example.com

mtr は各ホップの損失と遅延を表示します。単発の ping よりはるかに有用で、どこで遅延が加わっているかがわかります。

VPS からは、実際に依存しているサービスをフェーズごとに分けて測ります。

curl -o /dev/null -s -w 'dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  total %{time_total}s\n' \
  https://api.example.com/health

connect はおおよそネットワーク往復 1 回分、tls はハンドシェイクを加えたもの、total にはサーバー自身の処理時間も含まれます。connect が 2 ms で total が 900 ms なら、問題は距離ではありません。

EQVPS が合うケース

当社のサーバーはドイツとフィンランドにあり、注文ごとにロケーションを選べます。ヨーロッパ全域のユーザーを十分にカバーし、中東もそこそこ、ヨーロッパの取引所や API エンドポイントは非常に良くカバーします。フィンランドは西ヨーロッパから数ミリ秒遠く、北欧やバルト諸国には少し近くなります。ほとんどの用途ではどちらでも問題ありません。

正直に言うと、アジアや南北アメリカにはロケーションがありません。ユーザーがそこにいるなら、ヨーロッパのサーバーは往復のたびに 80〜250 ms を上乗せするので、もっと近くでホストすべきです。

要点

1. サーバーが最も多く通信する相手を決める：ユーザー、取引所、API、あなた自身。
2. その相手の近くに置く。目安は 100 km あたり約 1 ms。
3. 地図を信じず、mtr と curl -w で測る。
4. 距離の問題を解決するために速い CPU にお金を払わない。

同じマシンで NAT プランと専用 IP プランのどちらにするか迷っているなら、それは別の問題です。質問一つでわかるテストはこちら。