UIは翻訳済みですが、プロバイダー情報とレビュー本文は現在英語です。品質基準を満たす翻訳までは検索対象外です。
このガイドは全文翻訳済みです。プロバイダーの事実と価格は英語版が正本です。翻訳は人による編集レビュー待ちのため、このページは当面検索対象外です。
リージョンカタログは ping ではない
プロバイダーのリージョンページは、どこでサービスを提供しているかを示します。ユーザーからの往復遅延、特定の経路のパケットロス、あるいは希望するプランが在庫にあるかどうかは示しません。VPSTab はプロバイダーのロケーションカタログと、入手可能な場合はデータセンター固有の価格を記録しますが、どちらも遅延に関する主張に変換することはありません。
この区別が重要なのは、同じ都市の 2 つのプランが異なるネットワーク経路を通ることがあり、プロバイダーの最安リージョンが、サービスを提供したいユーザーから数千キロメートル離れていることもあるからです。ロケーションはパフォーマンススコアではなく、検証すべき制約として扱ってください。
ロケーションをユーザーと義務に合わせる
まず、接続する人とシステムから考えます。シンガポールのユーザー向けのサービスはシンガポールリージョンが有利です。大阪で働くチームは大阪か東京を好むかもしれません。ドイツのデータ所在に関する審査では、価格にかかわらずドイツのリージョンが求められることがあります。ワークロードがそれらに依存する場合、これらは希望ではなく必須要件です。
次に運用上の義務を検討します。プロバイダーはステータスページと SLA を公開しているでしょうか。そのリージョンは必要なサポート条件の対象でしょうか。後からサービスを移せるでしょうか。安価でも運用上孤立したリージョンは、価格が魅力的でも良い選択とは言えません。
価格と転送量はロケーションによって変わる
Hetzner は明快な例です。CPX02 はドイツとフィンランドでは月額 6.49 ユーロ(8.09 ドル)で EU 内転送量 20 TB ですが、シンガポールでは月額 7.99 ユーロ(9.59 ドル)で、転送量は 500 GB のみです。サーバーは同じクラスであり、ロケーションが価格と転送量の両方を変えています。EU の価格で組んだ予算は、シンガポールでは破綻し得ます。
AWS Lightsail も同様です。価格ページには一般的なバンドル価格が記載され、一部リージョンでは表示された転送許容量が半分になると警告しています。オレゴンで寛大に見えるバンドルも、別のリージョンではかなり厳しくなることがあります。表の見出しだけでなく、必ずリージョンごとの注記を確認してください。
シンガポールと日本の例
シンガポールについては、収集したデータセットに Hetzner SIN1、DigitalOcean SGP1、Linode ap-south、Vultr sgp、UpCloud SG-SIN1、Netcup SIN が含まれています。価格、転送量、バックアップ条件、根拠の質が異なります。このデータセットにはいずれの実測遅延結果もないため、順位付けは、述べられた制約とプロバイダーが明示した事実に対する適合度のみを反映できます。
日本については、Linode が大阪と東京を提供し、Vultr は plans API に大阪と東京のロケーションを掲載しています。このデータセットの日本向け開発プロファイルは、意図的に大阪と RAM 2 GB 以上を要求しており、候補は Linode 2 GB と複数の Vultr プランに絞られます。これはリソースとロケーションの結果であり、どちらが高速かという主張ではありません。
ドイツと正規化されたリージョンキー
ドイツは正規化リージョンを理解するのに有用な例です。Hetzner は Falkenstein と Nuremberg で販売し、DigitalOcean と Linode は Frankfurt を掲載し、UpCloud は Frankfurt を掲載し、IONOS は国レベルの可用性を公開しています。正規化リージョン「Frankfurt」のフィルターには、Falkenstein は自動的には含まれません。どちらもドイツにあるにもかかわらずです。プランページにはプロバイダーの正確なデータセンターが表示されるため、違いは可視化されます。
要件が本当に「ドイツ」であるなら、1 つの都市が国を代表すると仮定せず、すべてのドイツのロケーションを確認してください。要件が特定の都市や特定のデータセンターであるなら、プロバイダーの正確なロケーションを使ってください。どちらの選択も普遍的に正しいわけではなく、誤りはこの区別を隠すことです。
アーキテクチャ、可用性、退出
リージョンの選択はアーキテクチャの選択でもあります。サービスがデータセンターの障害を生き延びなければならないなら、1 リージョンの 1 サーバーは、ユーザーにどれほど近くても単一障害点です。マルチリージョン設計は、レプリケーション、フェイルオーバー、データ整合性のコストを追加し、それは単一 VPS の比較の範囲外です。単一ホストを買うのか、耐障害性のあるサービスを買うのかを明示的に決めてください。
必要になる前に退出を計画します。プロバイダーが標準イメージ、スナップショット、エクスポートをサポートしているか、IP アドレスを移せるか、移行にどれくらいかかりそうかを確認します。今日は安いが移行を高くつかせるプロバイダーには、隠れたロックインコストがあります。そのコストは、月額の数字に還元できなくても比較に含めるべきです。
遅延に敏感なサービスで、ユーザーが世界中に分散している場合は、VPS の前段に CDN や DNS ベースのルーティング層を置くことを検討します。これにより問題は「唯一の完璧なリージョンを選ぶ」から「オリジンリージョンと配信層を選ぶ」に変わります。VPSTab は CDN のパフォーマンスを測定しないため、これはアーキテクチャ上の選択肢であり、測定に基づく推奨ではありません。
ロケーションを検証する方法
プロバイダーの公式のリージョンページまたは価格ページを開き、希望するプランが、必要なロケーションで提供されていることを確認します。可能であればデータセンターコードとロケーション固有の価格を探します。観測日を記録します。リージョンカタログの項目は変わり得ますし、カタログは在庫の保証ではありません。
遅延が意思決定の要となる要件なら、候補を得た後に代表的なネットワークから測定するか、プロバイダーにテスト用エンドポイントを問い合わせてください。地理、マーケティング用の地図、他顧客のベンチマークを、自分の経路の証明として扱わないでください。
測定していないもの
現在の VPSTab データセットには、プロバイダーのカタログ根拠はありますが、ネットワーク測定はありません。これらのプランについて、往復遅延、ジッター、パケットロス、スループット、経路品質は公開していません。したがって、ロケーション適合度で並べた候補リストは遅延ベンチマークではなく、そのように説明するべきでもありません。
この制限は、ロケーションデータを無用にするものではありません。意思決定の仕方が変わるだけです。カタログを使ってワークロードに応えられないロケーションを除外し、遅延が重要なら残った候補を測定してください。カタログ根拠と実測を分けて扱うことが、正直な推奨と自信ありげな推測の違いです。
確認チェックリスト
- ユーザー、遅延、法的要件を満たすリージョンを列挙する。
- リージョンカタログの項目と、確認済みのプラン別在庫を区別する。
- 価格と転送許容量がロケーションによって変わるか確認する。
- 国だけでなく、プロバイダーの正確なデータセンターコードを記録する。
- 正規化リージョンのフィルターが、近隣の適格なロケーションを隠していないか確認する。
- 遅延は、実際のユーザーと経路に合致する方法でのみ測定する。
- 選択したリージョンのサポート、SLA、退出オプションを確認する。
- ロケーションに関する主張にはすべて観測日を添える。
出典
- Hetzner price API — CLOUD_136 + CLOUD_21 (CPX02 with IPv4)https://website-price-api.hetzner.com/api/v1/products/CLOUD_136%2BCLOUD_21
- Vultr API — List planshttps://api.vultr.com/v2/plans
- Vultr API — List regionshttps://api.vultr.com/v2/regions
- UpCloud data centershttps://upcloud.com/data-centers/
- Amazon Lightsail pricing — Linux/Unix general-purpose bundleshttps://aws.amazon.com/lightsail/pricing/
- Linode API — List regionshttps://api.linode.com/v4/regions