著者 ニューヨークVPSホスティングで何を重視するか
ニューヨークのVPSがニュージャージーに多い理由、東海岸VPSが米国中央部より有利な条件、実際の遅延や経路を測定して選ぶ方法を解説します。
ニューヨークの VPS で実際に得られるもの
ニューヨークの VPS は、米国東海岸にある2つの大規模な相互接続市場の一方に配置されます。もう一方はバージニア州アッシュバーンです。ニューヨークを選ぶことで、ボストンからワシントンまでの利用者に対する往復遅延を短くでき、北米からヨーロッパまでの光ファイバー経路も最短になります。利用者が大陸全体に均等に分散している場合は、通常、中央に近いロケーションのほうが適しています。この2つのケースを区別するには、推測ではなく測定が必要です。
ニューヨークのVPSホスティングの大半がニュージャージーにある理由
マンハッタンにはキャリアホテルが集まっています。代表例が60 Hudson Streetです。これはTribecaにある1930年完成のArt Deco建築で、300社を超えるキャリアやクラウドプロバイダーが入居しています。地域向けの交換設備もあり、DE-CIX New YorkやNYIIXなどが設置されています。数ブロック離れた32 Avenue of the Americasも同じ役割を担い、ニュージャージー側では165 Halsey Street in Newarkが相当します。
これらの建物は、ネットワーク同士が接続する場所です。電力と床面積が高価で拡張も難しいため、大量のコンピューティング設備を置く場所ではありません。大規模なデータホールは、ハドソン川の対岸にあるSecaucus、Weehawken、Carteret、Piscataway、Newarkなどにあります。「New York」VPSを販売するプロバイダーは、ほとんどの場合、Midtownから約40 km以内のこの周辺にあるラックを指しています。追加のファイバー遅延は1ミリ秒を大きく下回るため、Webワークロードで意識することはありません。特定のネットワークへのクロスコネクトが必要な場合に限り、どの建物にあるかを確認してください。
このメトロリージョンにキャパシティが集まった理由
4 つあります。それぞれが他の要因をさらに強めています。
- 大西洋横断ケーブルの陸揚げ地点がすぐ近くにあります。 ニュージャージー州沿岸の Wall Township と Manasquan は、米国で最も多くのケーブルが集まる地域です。Havfrue は AEC-2 として提供されており、Wall からデンマークの Blaabjerg まで延び、アイルランドとノルウェーにも分岐しています。Seabras-1 は同じステーションからブラジルまで延び、TGN Atlantic は欧州まで接続しています。Apollo は英国の Bude とフランスの Lannion から Manasquan に陸揚げされています。Google の Grace Hopper cable は Long Island の Bellport に陸揚げされ、2022 年 9 月以降、Bude との間でトラフィックを運んでいます。
- 取引所は Wall Street を離れました。 NYSE の matching engine は Mahwah、Nasdaq の matching engine は Carteret、Cboe の matching engine は Secaucus で稼働しています。トレーダーはこれらの拠点を equity triangle と呼びます。マイクロ秒単位で market data を必要とする企業は、いずれかの拠点の隣にスペースを確保する必要があります。その需要が、現在は他の利用者も共有する fiber の整備費を支えました。
- メディア企業と広告企業が集まっています。 real-time bidding のオークションは、ページの読み込みが完了する前に応答を返す必要があります。そのため、広告取引所は取引先である agency network の近くに構築されました。
- ネットワークは、すでにネットワークが存在する場所に集まります。 数百の carrier が 1 つの建物を共有するようになると、後から参入する carrier は、別の場所に構築するよりも、そこに参加したほうが安価な transit と良好な peering を得られます。
VPS の購入者にとって、これらは威信の問題ではありません。transit の競争があり、peering が密集しているということです。また、欧州への経路が短いのは、ケーブルが始まる場所から接続できるためです。
実際のラウンドトリップにかかる時間
光ファイバー内の光の速度は毎秒約 200,000 km で、真空中の光速のおよそ 3 分の 2 です。つまり、ルーターがパケットに触れる前でも、ファイバー 100 km ごとにラウンドトリップ時間が 1 ms かかります。実際の経路は地図上の距離より長くなります。光ファイバーは直線ではなく、通行権のある経路や海底ルートに沿って敷設されるためです。
必要な時間は、1 回のラウンドトリップだけで決まりません。プロトコルが必要とするラウンドトリップの回数で決まります。新しい HTTPS 接続では、TCP（transmission control protocol）ハンドシェイクに 1 回、TLS（transport layer security）1.3 ハンドシェイクにさらに 1 回、リクエストを送信して最初のバイトを受信するまでにさらに 1 回のラウンドトリップが必要です。ブラウザーが HTML を受け取るまでに、合計 3 回かかります。TLS 1.2 では 4 回目が追加されます。
The data behind this chart
[
{
"label": "Same metro",
"rtt_ms": 5,
"https_first_byte_ms": 15,
"six_call_chain_ms": 30
},
{
"label": "New York to Dallas",
"rtt_ms": 38,
"https_first_byte_ms": 114,
"six_call_chain_ms": 228
},
{
"label": "New York to London",
"rtt_ms": 78,
"https_first_byte_ms": 234,
"six_call_chain_ms": 468
},
{
"label": "New York to Singapore",
"rtt_ms": 230,
"https_first_byte_ms": 690,
"six_call_chain_ms": 1380
}
]これらの列は測定値ではなく、計算結果です。first byte は 3 回のラウンドトリップ、chain 列は依存関係のある API 呼び出し 6 回を順番に実行するページを表します。メトロエリア内の 5 ms では、接続の確立時間はほとんど問題になりません。大西洋を越えて 78 ms かかる場合、同じページでは HTML の最初のバイトが届くまで 234 ms 待ち、6 回の呼び出しによるチェーンでは、待機だけで 468 ms かかります。ニューヨークからシンガポールまで 230 ms かかる場合、そのチェーンの待機時間は 1380 ms です。
サーバーを移動する前に、chain 列を確認してください。接続の再利用と TLS セッション再開により、繰り返し発生していたラウンドトリップを削減できます。依存する 6 回の呼び出しを 2 回の並列呼び出しに変えるほうが、大陸単位でサーバーを近づけるより大きな時間短縮になります。ラウンドトリップを削減できない場合にサーバーを移動します。たとえば、ログイン処理や、クライアント側でまとめて送信できないデータベース書き込みが該当します。
ニューヨーク都市圏の VPS からの一般的なラウンドトリップ時間
The data behind this chart
[
{
"label": "Within the NY and NJ metro",
"rtt_ms": 2
},
{
"label": "Ashburn, Virginia",
"rtt_ms": 8
},
{
"label": "Toronto",
"rtt_ms": 14
},
{
"label": "Chicago",
"rtt_ms": 22
},
{
"label": "Dallas",
"rtt_ms": 38
},
{
"label": "Miami",
"rtt_ms": 40
},
{
"label": "Los Angeles",
"rtt_ms": 70
},
{
"label": "London",
"rtt_ms": 78
},
{
"label": "Frankfurt",
"rtt_ms": 88
},
{
"label": "Sao Paulo",
"rtt_ms": 120
}
]これらは、特定の 1 台のマシンで測定した値ではなく、一般的に公開されている代表値として扱ってください。通常のトランジットを利用する接続性の高いホストで、よく引用される範囲です。実際の経路によっては、この範囲を上回ることも下回ることもあります。Ashburn までは約 8 ms です。十分に近いため、ニューヨークの VPS から Virginia クラスターのサービスを呼び出しても、実質的な遅延はほとんどありません。Toronto までは約 14 ms です。London は約 78 ms、Frankfurt は約 88 ms です。そのため、東海岸の 1 台のサーバーなら欧州のユーザーにも許容できる応答を提供できますが、西海岸のサーバーではできません。
東海岸への配置が適しているケース
- ユーザーの大半がボストンからワシントンまでの回廊に集中しています。この地域には米国のインターネット需要の大部分が集まり、全域がこの都市圏から数ミリ秒の距離にあります。
- 1 台のマシンから米国東部とヨーロッパにサービスを提供します。大西洋横断区間がここから始まるため、ニューヨークが最も低コストな妥協点です。
- 都市圏内にあるサービスに依存しています。たとえば、マーケットデータフィード、広告取引所、Secaucus または Ashburn にあるパートナー API などです。
- カナダでホスティングせず、カナダへの短い経路が必要です。トロントまでは約 14 ms です。カナダのデータレジデンシーが必須要件であれば、判断は別になります。カナダの VPS ホスティングを選ぶ際に実際に重要なことで詳しく説明しています。
東海岸よりも米国中部のロケーションが有利な場合
平均ではなく、最悪のケースを基準に設計します。遠い沿岸部のユーザーは遅延を感じます。隣の州のユーザーは感じません。
The data behind this chart
[
{
"label": "New York metro",
"to_new_york_ms": 2,
"to_los_angeles_ms": 70
},
{
"label": "Dallas",
"to_new_york_ms": 38,
"to_los_angeles_ms": 35
},
{
"label": "Chicago",
"to_new_york_ms": 22,
"to_los_angeles_ms": 50
},
{
"label": "Los Angeles",
"to_new_york_ms": 70,
"to_los_angeles_ms": 2
}
]New York のサーバーから Los Angeles までは 70 ms です。Dallas のサーバーから New York までは 38 ms、Los Angeles までは 35 ms です。そのため、米国内での最悪ケースは New York のおよそ半分になります。トラフィックの分布が実際に全米規模であれば、Dallas のほうが有利です。Dallas に VPS を配置する根拠では、この市場について詳しく説明しています。もう1つの妥当な中間地点は Chicago で、東寄りの立地です。
New York を避けるべき状況は、さらに2つあります。ユーザーが Ontario または Quebec に集中している場合は、Toronto の VPSから直接サービスを提供できます。New York を経由する 14 ms の遅延を追加せずに済みます。また、トラフィックのほぼすべてが自分のサーバー間で発生する場合は、同じリージョンに配置して地理的な距離を考えないようにします。リージョン間の通信による遅延が、ユーザーの近くに配置することで得られる効果を上回るためです。
実測し、マーケティング用の地図を信用しない
カバレッジマップで分かるのは、建物がどこにあるかだけです。その建物までパケットがどのように到達するかは分かりません。経路は距離ではなく、トランジット契約とピアリング契約によって決まります。そのため、ユーザーがいる場所から測定します。自宅のブロードバンド回線に接続した laptop は、ネットワークの有利な側にある VPS 自体よりも適切な測定点です。
sudo apt update
sudo apt install -y mtr-tiny traceroute iperf3まずは単純な往復時間を測定し、4 回ではなく 20 回プローブを送信します。ホスト名は自分のサーバーに置き換えてください。
ping -c 20 your-server.example.com最後の行に rtt min/avg/max/mdev が表示されます。ここで平均値は最も役に立たない数値です。mdev はジッターです。平均値が正常に見えても、ジッターが大きいと音声通信や対話的なセッションに支障が出ます。有線経路では、パケットロスが 0 を超えていればノイズではなく障害です。
次に、時間がどこで消費されているかを確認します。
mtr -rwzbc 100 your-server.example.commtr は各ホップに 100 回プローブを送信し、ホップごとのロスと遅延を表示します。-z を使うと AS（自律システム）番号も追加されるため、各ホップを所有するネットワークを確認できます。途中のホップで報告されたロスが後続のホップで消える場合、それは実際のロスではありません。そのルーターが、自身で生成する必要がある ICMP 応答をレート制限しているだけであり、ユーザーのトラフィックには影響しないためです。あるホップで始まったロスが、その後のすべてのホップで続く場合は実際のロスです。
また、多くのネットワークでは ICMP の優先度が低いため、Web サービスの評価に ICMP を使うのは適切ではありません。実際に提供する処理の時間を測定します。
curl -o /dev/null -s -w 'dns %{time_namelookup}\ntcp %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://example.com/各値は開始時点からの累積秒数なので、差分を計算して読み取ります。time_connect から time_namelookup を引くと、1 回の往復時間になります。time_appconnect から time_connect を引くと、TLS ハンドシェイクの時間になります。time_starttransfer から time_appconnect を引くと、さらに 1 回の往復時間と、アプリケーションが応答するまでの時間が得られます。最後の差分が診断結果です。これが 1 回の往復時間に近ければ、制限要因はネットワークであり、より近いサーバーに移すと改善します。往復時間の数倍かかっている場合は、アプリケーションが遅いということです。移設しても何も変わりません。
再現可能な時間測定
1 回の測定結果はノイズです。ユーザーが実際に起きている時間帯に 20 回実行し、中央の値を確認します。
for i in $(seq 1 20); do
curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/
done | sort -n | awk 'NR==10 || NR==11'これにより、20 回の測定結果の中央にある 2 つのサンプルが表示されます。両者の差が数ミリ秒を超える場合、経路は不安定です。単一の数値だけでは誤った判断につながります。遅延ではなくスループットを測定するには、遠端に自分で管理する iperf3 サーバーが必要です。そのうえで iperf3 -c your-server.example.com -R を使うと、ユーザーが重視する方向であるサーバーからクライアントへの通信を測定できます。
契約する前に、候補となる各ロケーションのトライアルインスタンスに対して同じテストを実行します。VPS のベンチマークを行う完全な方法では、ネットワークだけでなくディスクと CPU も評価するため、遅延だけで選択せずに済みます。
ニューヨークの住所にすると何が変わるか
まず変わるのは価格です。ニューヨーク都市圏では、テキサス州や中西部より電力と床面積のコストが高くなります。そのコストをロケーションごとの追加料金として転嫁するプロバイダーもあれば、全体の運用コストに平均化するプロバイダーもあります。2026 年 8 月時点では統一されたルールはありません。そのため、追加料金があると判断する前に、プロバイダーの注文ページで同じ仕様を2つのロケーションについて見積もってください。VPS の実際の月額費用では、請求額の残りの内訳を説明しています。
法律はサーバーの所在地に従うわけではありません。ニューヨーク州の SHIELD Act は、データがどこに保存されているかにかかわらず、ニューヨーク州の居住者に関する個人情報を保有する事業者に、情報漏えいの通知義務と合理的な安全対策の義務を課しています。サーバーを Dallas に移しても、その義務はなくなりません。Manhattan に移しても、その義務が新たに発生するわけではありません。GDPR（一般データ保護規則）と欧州のユーザーについても同様です。契約や業界規則で国が指定されている場合は、所在地が重要になります。これは医療分野や一部の金融サービスでよくあります。
電力と洪水のリスクについても確認が必要です。2012 年 10 月に Hurricane Sandy が上陸した際、Lower Manhattan の複数の通信事業者用ビルでは、地下の燃料ポンプが浸水し、上階の発電機が燃料切れになったため、サービスが停止しました。どの都市圏でも、単一サイトは単一障害点です。バックアップは別の電力網に保存し、少なくとも1回は別の場所でリストアして、復元が正常に機能することを確認してください。
FAQ
欧州のユーザーにとって、New York の VPS は米国中央部の VPS より高速ですか？
はい。差は予測できます。London は New York の都市圏から約 78 ms です。大西洋横断ケーブルが New Jersey 州沿岸と Long Island に陸揚げされているためです。Dallas のサーバーから London へは、まず東海岸まで到達する必要があります。そのため、これにおよそ 38 ms の Dallas から New York までの遅延が加わります。東部米国と欧州の両方に 1 台のマシンでサービスを提供する場合、New York が最もコストの低い妥協案です。
「New York」の VPS が実際には New Jersey にあるのはなぜですか？
ラックを設置できる床面積と電力がそこにあるためです。60 Hudson Street など Manhattan の建物は、大規模な計算設備ではなく相互接続ハブです。そのため、ラックは Secaucus、Weehawken、Carteret、Piscataway、または Newark に設置されます。追加されるファイバー遅延は 1 ms を大きく下回るため、Web ワークロードでは認識できません。特定の建物内にある特定のネットワークへクロスコネクトする必要がある場合に限り、正確な施設を確認してください。
遅延が本当に問題かどうかを確認するにはどうすればよいですか？
curl の時間内訳を実行して差分を計算してください。time_appconnect と time_starttransfer の差は、ネットワークの 1 往復分に、サーバー自身の処理時間を加えたものです。その差が ping で測定した往復時間を大きく上回る場合、遅延はアプリケーション内部にあります。データセンターを近くに移しても解決しません。その差が 1 往復分に近いのにページの表示が遅い場合は、ページが順番に行うリクエスト数を数えてください。各リクエストで、再び往復時間が発生するためです。
New York でホスティングすると、適用されるプライバシー法は変わりますか？
ほとんどの場合、変わりません。New York 州の SHIELD Act や GDPR などの規則は、ディスクがどこにあるかではなく、誰のデータを保有するかに適用されます。契約または業界規則で特定の国が指定されている場合は、サーバーの所在地が決定要因になります。これは医療分野や金融サービスの一部でよくあります。要件を満たすために所在地を選ぶ前に、実際の要件を確認してください。
適切な場所に配置した VPS を CDN で置き換えられますか？
静的ファイルであれば可能です。CDN（コンテンツ配信ネットワーク）は、画像やスクリプトをユーザーの近くにキャッシュし、それらのリクエストで発生する距離の大部分をなくします。ログイン済みのダッシュボードやデータベースへの書き込みはキャッシュできません。そのため、それらは引き続きオリジンサーバーまで送信され、完全な往復時間が発生します。データを書き込むユーザーの近くにオリジンを配置し、それ以外を CDN に処理させてください。