アムステルダムVPSで重視すべきこと

アムステルダムのVPSホスティングを選ぶ理由

アムステルダムのVPSホスティングは、何よりもまずネットワーク上の選択です。アムステルダムはヨーロッパの主要な相互接続拠点の1つで、多数の独立したネットワークが集まり、相互にトラフィックを直接交換しています。この都市圏にあるサーバーからは、英国、北欧、ドイツ、フランス、ベネルクス諸国へ、経由するネットワークが少ない短い経路で到達しやすくなります。

これが選択の根拠です。このガイドの残りでは、それが利用者に当てはまるかを確認します。すべての利用者に当てはまるわけではありません。顧客基盤が北西ヨーロッパ全域に分散している場合、アムステルダムは有力な標準選択です。一方、トラフィックの大半がワルシャワ、イスタンブール、サンパウロ、トロントから来る場合は適していません。オランダでの良好なピアリングによって、これらの地域までの距離が短くなるわけではないためです。

インターネットエクスチェンジの実態

インターネットエクスチェンジポイント（IXP）は、共有スイッチングファブリックです。独立したネットワークはIXP上のポートを借りて一度接続すれば、他の参加ネットワークとトラフィックを直接交換できます。Amsterdamで最もよく知られているのは、Amsterdam Internet ExchangeであるAMS-IXです。ただし、市内のエクスチェンジはAMS-IXだけではなく、その数自体は重要ではありません。

エクスチェンジによってレイテンシが変わる理由を理解するには、ネットワーク間をパケットが通過する2つの方法を知る必要があります。1つ目はtransitです。大規模なネットワークに料金を支払い、インターネットの他の部分までトラフィックを運んでもらいます。2つ目はpeeringです。2つのネットワークが合意し、通常はどちらからも料金を支払わずに、トラフィックを直接相互に渡します。ここでいう各ネットワークは、自身の番号とルーティングポリシーを持つネットワークであるautonomous system、つまりASです。

Transitの経路は、地理的な距離だけでなく、ビジネス上の関係によっても決まります。あるヨーロッパの都市にあるサーバーから、別の都市のブロードバンド利用者へ送るパケットが、正当に第3の都市まで移動し、そこでネットワークを切り替えて戻ってくることもあります。障害ではありません。料金とルーティングポリシーによって、その経路が選ばれただけです。エクスチェンジでは、2つのネットワークがその場でパケットを直接引き渡せます。そのため経路が短くなり、経由するネットワークが減り、輻輳が発生する箇所も少なくなります。

ここが見落とされがちな点です。都市内にエクスチェンジがあっても、VPSがそこに接続されるわけではありません。重要なのはプロバイダー自身のネットワークです。どのtransitプロバイダーから接続性を購入しているか、どのエクスチェンジに参加しているか、利用者が接続する消費者向けネットワークやモバイルネットワークとpeeringしているか、そして各ネットワークに対してどれだけの容量を確保しているかを確認します。同じ建物内にある2台のサーバーでも、外部へ出る経路は大きく異なる場合があります。プロバイダーにAS番号を尋ね、その番号をPeeringDBで検索してください。PeeringDBでは、各ネットワークが接続している施設やエクスチェンジを公開しています。稼働中の経路からAS番号を直接確認することもできます。その方法は、以下の測定のセクションで説明します。

Amsterdam と Frankfurt のどちらを選ぶかは、地図ではなくユーザーを基準に判断する

これは多くの読者が実際に直面する選択であり、どちらの都市も主要な相互接続拠点です。Frankfurt には DE-CIX があり、中央ヨーロッパ、東ヨーロッパ、南東ヨーロッパ向けや、Vienna、Warsaw、Prague、Middle East 方面へ向かう経路では通常こちらが選ばれます。Amsterdam は United Kingdom、Ireland、Scandinavia、Benelux 向けに適しており、北西ヨーロッパに陸揚げされる海底ケーブルを利用するトラフィックにも適しています。ただし、これらは測定結果ではなく、傾向として扱ってください。ルーティングは変わり、プロバイダーは上流接続を変更します。また、プロバイダーのピアリングは、都市単位の一般化よりも具体的です。

そのため、自分のデータで判断してください。

1. ユーザーが実際にどこにいるかを書き出します。Web サーバーのアクセスログ、分析データ、顧客リストに、この情報はすでに含まれています。
2. ボットによって水増しされる単純なアクセス数ではなく、売上やアクティブアカウントなど、重要な指標でその一覧に重み付けします。
3. 候補都市ごとに最小プランを1か月借り、実際のユーザー接続から双方への通信を測定します。
4. マーケティングページに掲載された数値ではなく、収集した数値を比較します。

この確認に1週間をかける前に、率直な注意点を1つ挙げます。西ヨーロッパ内にユーザーベースがある場合、十分に接続された2つのヨーロッパ大都市間の差は、自分のアプリケーションが追加する遅延より小さいことがよくあります。1つのページがデータベースクエリを10回、順番に実行すると、ラウンドトリップが10回発生します。そのため、クエリの実行方法によるコストが、都市の選択による差を上回ることがあります。アプリケーション自体も測定してください。同じ問いを反対側から扱った内容は、Frankfurt で VPS を選ぶためのガイドにあります。最終的な決め手は、必要なプランサイズとディスクを備えている場所はどこか、といった地味な条件になることもよくあります。

自分でAmsterdamまでのレイテンシを測定する方法

ユーザーが使う接続、またはできるだけ近い接続から実行します。Manchesterのモバイル接続を評価するのに、オフィスの光回線を代用することはできません。

DebianまたはUbuntuでは、先にツールをインストールします。

sudo apt update && sudo apt install -y mtr-tiny traceroute curl

まず、往復回数を指定して測定します。

ping -c 20 ams.example.com

末尾のサマリーにはrtt min/avg/max/mdevと表示されます。avgはミリ秒単位の通常の往復時間で、mdevはその変動幅、つまりジッターです。同じブロックに表示されるパケット損失率も確認します。宛先で損失が発生している場合は、実際の問題です。途中の1ホップだけで損失が報告され、その後のすべてのホップで正常な値が表示される場合は、通常は問題ありません。ルーターは、自身宛てのパケットに関する応答の優先度を下げるためです。

次に、経路そのものを確認します。

mtr --report --report-wide --show-ips --aslookup --report-cycles 100 ams.example.com

各行は1ホップを表し、--aslookupにはAS番号が表示されます。どのネットワークをパケットが通過し、どこでプロバイダーのネットワークを離れるかを確認できます。往復時間が上昇し、その後のすべてのホップで高いままになるホップを探します。そこから遅延が追加されています。mtrがraw socketを開けずに終了する場合は、sudoを付けて実行します。ネットワークによってはICMPの優先度を下げたり、ICMPを破棄したりします。そのため、ユーザーの接続方法も測定してください。つまり、サービスを提供しているポートにTCPで接続して測定します。

sudo mtr --tcp --port 443 --report --report-cycles 100 ams.example.com

次に、ネットワークとサーバーを分けて確認します。

curl -o /dev/null -s -w 'dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nttfb %{time_starttransfer}\ntotal %{time_total}\n' https://ams.example.com/

各値は、リクエスト開始からの経過秒数です。そのため、読むべきなのは値の間隔です。connectからdnsを引いた値は、おおよそ1往復分の時間、つまりTCPハンドシェイクの時間です。tlsからconnectを引いた値はTLS（transport layer security）ハンドシェイクの時間です。TLSハンドシェイクにはさらに複数回の往復が必要なため、距離が伸びると行内の他の時間より速く増加します。ttfbからtlsを引いた値は、主にサーバーの処理時間です。この分解が、購入判断ではpingよりcurlが適している理由です。合計時間が長く、ttfbの間隔が短い場合、サーバーが遠くにあります。ttfbの間隔が大きく、接続が速い場合、サーバーは近くにありますが、アプリケーションの処理が遅い状態です。

レイテンシは混雑状況によって時間帯でも変化します。1回の測定だけを信頼せず、1日を通してサンプルを取得してください。

while true; do date -Is; ping -c 10 -q ams.example.com | tail -2; sleep 300; done | tee latency.log

購入時に確認すべき要素は、ネットワークだけではありません。ディスクとCPUも重要です。高密度利用されているノード上の、適切な場所にあるサーバーでも動作は遅く感じられます。そのため、1年間の契約を確定する前に、試用プランで適切なVPSベンチマークを実行してください。

EU データレジデンシーの基本

データレジデンシーとは、データが保存および処理される物理的な場所です。オランダは欧州連合および欧州経済領域に属しているため、Amsterdam のサーバーを使用すると、データは EU のインフラ上に保管されます。これで場所に関する問題は解決します。ただし、場所はコンプライアンスに関する判断材料の1つにすぎません。

GDPR（一般データ保護規則）は、個人データが EU 外へ移転されること自体を禁止していません。移転に適用される条件を定めており、さらに、委託してデータを処理する他社にも適用されます。したがって、確認すべきなのは「サーバーが EU 内にあるか」ではありません。「このデータのすべてのコピーが最終的にどこへ行くのか」です。

ここで、データレジデンシーに関する主張は通常破綻します。VPS は Amsterdam にあり、データベースもそこにあります。しかし、バックアップは別リージョンのオブジェクトストレージへ送られ、アプリケーションログはホスト型検索サービスへストリーミングされ、エラーのトレースは監視ベンダーへ送られ、トランザクションメールは第三者経由で送信され、ユーザーのテキストは要約のために API へ投稿されます。これらはすべて、個人データを別の場所へ移転しています。場所に関する要件は、意図的に選んだマシンだけでなく、これらすべてに適用されます。

2つの目的は分けて考えてください。契約、規制当局、または顧客が EU のインフラを要求している場合、それはコンプライアンス要件です。要件は文書化されており、1つのリージョン内にとどまることを求められる場合があります。ユーザーの近くにサーバーを置いてページの読み込みを高速化したい場合、それはレイテンシ要件です。その場合は、リージョンの追加が必要になる可能性があります。性能上の判断を正当化するためにコンプライアンス用語を使うと、後でどちらの質問にも答えられなくなります。

プロバイダーに、誰がマシンへアクセスできるのか、サポート担当者がどこに所在するのか、その会社がどの法律に従うのか、EEA 外にサブプロセッサーが存在するのかを確認してください。回答はデータ処理契約に記載してもらってください。監査担当者が求めるのは署名済みの文書であり、サポートチケットではありません。詳しい方法については、カナダのデータ移転向けに作成されたデータレジデンシーの枠組みをそのまま適用できます。データを列挙し、それぞれに触れるすべての処理者を列挙し、満たすべきルールを書き出してから、最後に場所を選びます。これは確認すべき事項の説明であり、法的助言ではありません。

選定した都市が Amsterdam でも解決しないこと

• 他の地域との距離。信号は真空中の光速のおよそ 3 分の 2 で光ファイバーを伝わります。ケーブルの経路は常に直線距離より長いため、ヨーロッパのどの都市を選んでも、Singapore のユーザーは距離による遅延の影響を受けます。
• 通信回数の多いアプリケーション。前のリクエストの完了を待つ各リクエストでは、ラウンドトリップが再び発生します。
• 単一リージョンのリスク。1 つの都市にある 1 台の VPS は、1 つの障害ドメインです。ピアリングが良好でも、誤ったボリュームを削除した場合は防げません。
• 過負荷のハードウェア。接続性の高い都市にあるノードでも、負荷が高ければ同じく過負荷のノードです。

ユーザーが複数の大陸に分散している場合

原則は単純です。ユーザーに最も近いポイントオブプレゼンスにサーバーを配置します。ユーザーが複数の大陸に分かれている場合、中央の場所に配置すると、どちらのグループにとっても遅くなります。どちらのグループも近くにいないためです。

実際の選択肢は2つあります。キャッシュ可能なものを CDN（コンテンツ配信ネットワーク）の背後に配置します。そうすればオリジンは Amsterdam に置いたまま、画像、スタイルシート、スクリプト、キャッシュ済みページを各ユーザーに近いノードから配信できます。もう1つは、他の地域に2台目のサーバーを運用し、read replica または遅延を測定して記録した replication を使って、データの問題を意図的に解決する方法です。どちらも1台のサーバーよりコストがかかります。ユーザーが分散している場合に必要な、正直なコストです。

トラフィックの大部分が North America にある場合、Toronto の VPS のほうが、どの European city よりもそのユーザーに適した配信ができます。South America のユーザーには、Brazil にホストされた VPS を使うと、リクエストごとの大西洋横断の往復を避けられます。ユーザーが Europe、特に北部と西部に多い場合は、Amsterdam を選ぶのが適切です。これは具体的な判断です。上記のコマンドを使えば、自分のトラフィックに対してその判断を確認できます。

FAQ

アムステルダムの VPS はフランクフルトの VPS より高速ですか？

ユーザーによっては高速になる可能性があります。両都市は主要な相互接続拠点であるため、違いを生むのは都市名ではなく、ユーザーの所在地と各プロバイダーがどのネットワークとピアリングしているかです。アムステルダムは英国、アイルランド、北欧、ベネルクスのユーザーに適する傾向があります。一方、フランクフルトは中欧および東欧のユーザーに適する傾向があります。各地域で最小の月額プランを契約し、実際のユーザー接続から 1 週間、mtr --report --aslookup と curl -w の計測を実行してから決めてください。

アムステルダムでホスティングすれば、サービスは GDPR に準拠しますか？

いいえ。データを EU のインフラストラクチャに置くことで、1 つの要件には答えられます。しかし、コンプライアンスには、法的根拠、処理者、バックアップ、ログ、個人データを送信するすべてのサードパーティサービスも含まれます。アムステルダムのサーバーからエラートレースを EEA 外のベンダーに送信すれば、そのデータは域外へ移転されます。所在地の確認は簡単ですが、そこで確認を終えてはいけません。

AMS-IX とは何ですか？VPS に影響しますか？

AMS-IX は Amsterdam Internet Exchange です。独立したネットワークが接続し、トランジットプロバイダーにネットワーク間の転送を任せず、相互に直接トラフィックを交換する共有スイッチング基盤です。AMS-IX から VPS へ接続されるのは、プロバイダーが AMS-IX に接続している場合だけです。プロバイダーが AMS-IX に参加し、ユーザーが利用するネットワークとピアリングしていれば、市内のインターネットエクスチェンジが役立ちます。プロバイダーの AS 番号を確認し、PeeringDB でその番号がどこでピアリングしているかを調べてください。

料金を 1 年分支払う前に、VPS へのネットワークをテストするにはどうすればよいですか？

まず最小の月額プランを契約してください。往復時間とパケット損失を確認するために ping -c 20 を実行し、次に経路が通過するネットワークを確認するために mtr --report --report-wide --aslookup --report-cycles 100 を実行します。その後、実際のページに HTTPS でアクセスして curl -w を実行し、距離による遅延とサーバー速度を切り分けます。混雑状況は時間帯によって変わるため、異なる時間帯に繰り返してください。また、オフィスからだけでなく、ユーザーが利用する接続から実行してください。記録を保存し、印象ではなく記録した数値を比較できるようにします。