著者 Matt Connor
フランクフルトVPSはドイツ・EU向けに適していますか？
DE-CIXのピアリングでドイツやEUユーザーへの経路はどう変わるか、実測レイテンシの目安と、EU内ホスティングだけでは解決しないGDPRの範囲を解説します。
フランクフルトのVPSホスティングが適している用途
フランクフルトのVPSホスティングは、ユーザーがドイツ、ドイツ語圏の広域市場、または欧州連合全域に分布するプロジェクトに適しています。フランクフルトは、欧州のネットワークが相互接続し、トラフィックを直接受け渡す拠点の1つです。そのため、ここにサーバーを置くと、大陸の大部分に数十ミリ秒で到達できます。ユーザーの大半が北米にいる場合、マシンがどれだけ高速でも、欧州のサーバーはユーザーにとって遅く感じられます。距離による下限の遅延は、チューニングではなくせないためです。
ロケーションを決めるには、2つの別々の問題を検討します。これらを混同すると、誤った選択につながります。1つ目はユーザーがどこにいるかです。これは距離とラウンドトリップ時間に関する問題です。2つ目はデータをどこに保存できるかです。これは法的および契約上の問題です。フランクフルトは、欧州のユーザーに対する1つ目の問題には有力な解決策となります。2つ目については、特定の問題を1つ取り除くだけで、それ以外の問題を解決するわけではありません。
フランクフルトはなぜこれほどネットワーク接続に恵まれているのですか？
フランクフルトには DE-CIX（Deutsche Commercial Internet Exchange）があります。これは IXP（internet exchange point）の1つで、ピークトラフィックと接続ネットワーク数の両方で世界最大級です。IXP は、データセンター内に設置された共有スイッチング基盤です。独立したネットワーク同士が接続し、より大規模なネットワークにトラフィックの中継を依頼せずに済みます。DE-CIX は公式サイトで現在のトラフィック統計を公開しています。数値は変動するため、記事に転載された数値ではなく、公式サイトで確認してください。
実際の効果は、総量ではなく経路に現れます。プロバイダーのネットワークと訪問者の ISP（internet service provider）が同じ交換所に接続している場合、両者間のトラフィックは、その交換所で1つのルーティングホップを通過します。ローカルでピアリングしていない場合、トラフィックは両方のネットワークを収容する別のネットワークまで到達する必要があります。そのネットワークの最寄りの受け渡し地点が、別の国にあることもあります。ドイツ国内の2つのネットワークが Amsterdam や London 経由でトラフィックを交換すると、余分な距離を往復で2回分通過します。ネットワークエンジニアはこの現象をトロンボーン現象と呼び、近くのサーバーへの接続で遠回りが発生する一般的な理由になっています。
推測せず、実際に確認できます。対象ネットワークからサーバーに対して mtr を実行し、逆引き DNS に表示されるホップ名を確認してください。ルーターのホスト名には通常 IATA 空港コードが含まれています。そのため、ホップ名の fra は Frankfurt、ams は Amsterdam、lhr は London を示します。ドイツのコンシューマー回線からドイツのサーバーへの経路の途中に lhr が表示される場合、余分なミリ秒がどこで発生したかを正確に把握できます。
ユーザーから Frankfurt までの距離はどの程度ですか？
光ファイバー内の光は、真空中の速度のおよそ 3 分の 2、毎秒約 200,000 km で伝わります。往復では経路を 2 回通るため、距離 d km に対する最短の往復時間は d/100 ミリ秒です。これは下限値であり、これを下回ることはできないため、重要な指標になります。
The data behind this chart
[
{
"label": "Zurich",
"distance_km": 304,
"min_rtt_ms": 3.0
},
{
"label": "Amsterdam",
"distance_km": 365,
"min_rtt_ms": 3.7
},
{
"label": "Berlin",
"distance_km": 424,
"min_rtt_ms": 4.2
},
{
"label": "Paris",
"distance_km": 479,
"min_rtt_ms": 4.8
},
{
"label": "Milan",
"distance_km": 519,
"min_rtt_ms": 5.2
},
{
"label": "Vienna",
"distance_km": 600,
"min_rtt_ms": 6.0
},
{
"label": "London",
"distance_km": 640,
"min_rtt_ms": 6.4
},
{
"label": "Warsaw",
"distance_km": 903,
"min_rtt_ms": 9.0
},
{
"label": "Stockholm",
"distance_km": "1,197",
"min_rtt_ms": 12.0
},
{
"label": "Madrid",
"distance_km": "1,419",
"min_rtt_ms": 14.2
},
{
"label": "New York",
"distance_km": "6,206",
"min_rtt_ms": 62.1
}
]これらは実測値ではなく、直線距離から算出した値です。最後の列は、物理法則上可能な最良値として見てください。実測値は通常、この下限値の 1.5 ～ 2 倍になります。光ファイバーは大圏航路ではなく、道路や河川の谷に沿って敷設されるためです。また、経路上の各ルーターで転送処理とキューイングによる小さな遅延が加わります。
Berlin は Frankfurt から 424 km 離れており、下限値は 4.2 ms です。Madrid は 1,419 km 離れており、下限値は 14.2 ms です。ここから見て EU 内で最も遠い地点でもあります。New York は 6,206 km 離れており、下限値は 62.1 ms です。そのため、大西洋をまたぐユーザーを対象にする場合、これはチューニングの問題ではなく、ロケーションの選択に関わる判断になります。
低速なラウンドトリップはページの読み込み時間にどれだけ影響するか
ラウンドトリップは、通常 1 回だけではありません。HTTPS 接続の確立には、TCP（transmission control protocol）ハンドシェイクで 1 回、TLS（transport layer security）1.3 ハンドシェイクでさらに 1 回のラウンドトリップが必要です。その後、レスポンスの最初のバイトが返るまでに、リクエストで 3 回目が必要です。TLS 1.2 では 4 回目も加わります。DNS（domain name system）検索の結果がキャッシュされていなければ、少なくとももう 1 回、しかも別のサーバーへのラウンドトリップが必要です。
The data behind this chart
[
{
"label": "User in Frankfurt",
"rtt_ms": 5,
"first_byte_ms": 15
},
{
"label": "User in Warsaw",
"rtt_ms": 20,
"first_byte_ms": 60
},
{
"label": "User in Madrid",
"rtt_ms": 30,
"first_byte_ms": 90
},
{
"label": "User in New York",
"rtt_ms": 90,
"first_byte_ms": 270
},
{
"label": "User in Singapore",
"rtt_ms": 170,
"first_byte_ms": 510
}
]ここでのラウンドトリップ列は、フランクフルトのサーバーまでの現実的な経路を想定したものです。2 列目はその計算結果で、最初のバイトを受信するまでに 3 回のラウンドトリップが必要になります。フランクフルトのユーザーは 15 ms 待ちます。シンガポールのユーザーは、ラウンドトリップ時間が 170 ms の場合、同じレスポンスを受け取るまでに 510 ms 待ちます。この間、ブラウザーにはまだ何も表示されません。
重要なのは、この倍率です。RTT（round-trip time）が 1 ms 増えるごとに、最初のバイトを受信するまでの時間は約 3 ms 増え、その後も影響が続きます。HTML がスタイルシートを指定し、スタイルシートがフォントを指定すると、それぞれの検出で同じ接続上のラウンドトリップがさらに 1 回必要になります。距離によって数百 ms が加わるだけで、瞬時に感じていたページが遅く感じられるようになります。サーバーが行う処理とその所要時間は、まったく変わっていません。
このことから、CDN（content delivery network）で解決できる範囲も分かります。ユーザーの近くにあるキャッシュから静的ファイルを配信すれば、長い経路を省略できます。しかし、ログイン済みのダッシュボードがデータベースに問い合わせる必要がある場合は別です。そのリクエストは、依然として距離全体を 2 回通過します。ログインするユーザーの近くに origin を配置することは、キャッシュでは代替できません。
ユーザーがいる場所から、どのように測定すればよいですか？
対象とするネットワーク上のマシンから実行してください。サービスを提供する国の家庭やオフィスの接続から測定するのが理想です。別のデータセンターにあるサーバーから測定すると、ユーザーではなくデータセンターまでの経路が分かります。以下のコマンドは自分で実行する例です。対策の判断に使う価値があるのは、自分で測定した遅延値だけです。
ping -c 20 your-server.example.comサマリー行には rtt min/avg/max/mdev = ... と表示されます。通常時の値は avg、パケット間の変動であるジッターは mdev で確認します。通常の avg で mdev が大きい場合、経路が不安定です。平均値がやや高い場合よりも、SSH や音声通信などの対話的な処理に大きな影響があります。
sudo apt update && sudo apt install -y mtr-tiny
mtr -rwzc 50 your-server.example.com-r はリアルタイム表示ではなくレポートを出力します。-w は長いホスト名をそのまま表示します。-z は各ホップの AS（自律システム）番号を表示します。-c 50 は 50 回測定します。途中の 1 ホップで損失が表示されても、最終ホップで損失がなければ正常であり、障害ではありません。多くのルーターは、自身が生成する ICMP 応答にレート制限を適用しますが、その他のパケットは正常に転送するためです。あるホップから始まり、その後のすべてのホップで継続する損失は、実際のパケット損失です。
curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://your-server.example.com/各フィールドは、リクエスト開始からの累積秒数です。そのため、差分を計算して読み取ります。time_namelookup は DNS です。time_connect からそれを引いた値が TCP ハンドシェイクで、ほぼ 1 往復分です。time_appconnect から time_connect を引いた値が TLS ハンドシェイクです。time_starttransfer から time_appconnect を引いた値は、アプリケーション自体の処理時間と、追加の 1 往復分です。各差分が小さいにもかかわらず total が大きい場合、問題は都市ではなくコードにあります。
遅延ではなくスループットを測定する場合は、VPS 上で iperf3 -s を実行し、ファイアウォールでそのポートを開き、クライアントから iperf3 -c your-server.example.com -R を実行してダウンロード方向を測定します。マシンを用意できない場所から測定するには、RIPE Atlas を使用できます。ヨーロッパ各地にプローブがあります。2 つのネットワークではなく 2 つのサーバーを比較する場合は、単発の数値ではなく、固定した方法を使用してください。再現可能な VPS ベンチマークは、そのためのものです。
フランクフルトにあるサーバーを使えば、プロジェクトはGDPRに準拠しますか？
いいえ。その理由は正確に説明する必要があります。GDPR（一般データ保護規則）は、処理する個人データの対象者と、組織が設立されている場所に基づいて適用されます。ハードウェアが置かれている国は基準ではありません。サーバーをフランクフルトへ移しても、コンプライアンスが確立されるわけではありません。EU域外でサーバーを運用しても、自動的にGDPR違反になるわけではありません。所在地は、複数ある判断要素の1つです。
EU域内、またはより広いEEA（欧州経済領域）内でホスティングすると解消できるのは、国際的なデータ移転に関する問題です。GDPRには、個人データをEEA域外へ移転する場合について、1つの章全体が設けられています。この場合、十分性認定や標準契約条項などの法的根拠が必要です。データがフランクフルトにとどまる場合、その移転は発生しないため、その区間にはこの章が適用されません。これは実際の簡素化ですが、得られるメリットはその範囲に限られます。
それ以外は、すべて自分で対応する必要があります。目的ごとに適法な処理根拠を用意し、データベースに登録された人がアクセス権と削除権を行使できる状態にし、実際に適用する保存期間の上限を定め、リスクに応じたセキュリティ対策を講じる必要があります。また、個人データ侵害を認識してから72時間以内に、監督機関へ報告する必要があります。さらに、ホスティングプロバイダーとの間で、ドイツではAuftragsverarbeitungsvertrag、またはAVVと呼ばれる処理者契約を締結する必要があります。フランクフルトのサーバーでも、EEA域外のサポート担当者がアクセスできる場合は、データ移転に該当する可能性があります。誰が暗号鍵を管理しているかも確認してください。
ドイツでは、さらに国内法が加わります。連邦BDSG（連邦データ保護法）はGDPRを国内規則で補完しており、特に従業員データの扱いが見落とされやすい分野です。このセクションは一般的な背景説明であり、法的助言ではありません。欧州データ保護会議は公式ガイドラインをedpb.europa.euで公開しています。実際に重大な影響が生じる事項については、チュートリアルではなく、適切な資格を持つ専門家に相談してください。
サーバー自体では何を変更すべきですか？
システムクロックは UTC（協定世界時）に保ち、タイムスタンプはアプリケーションで整形します。ドイツでは夏時間を採用しているため、現地時刻は年に 2 回、1 時間移動します。また、10 月下旬には 1 時間が繰り返されます。その夜に現地時刻で書き込まれたログには 02:30 のエントリが 2 つ含まれるため、地域をまたいだログの相関分析が推測に頼ることになります。それでもサーバー上で現地時刻を使用する場合は、明示的に設定して確認します。
sudo timedatectl set-timezone Europe/Berlin
timedatectl出力には、夏には Time zone: Europe/Berlin (CEST, +0200)、冬には +0100 と表示されます。
デフォルトの C ロケールでは、C のソートが生のバイト列を比較するため、ドイツ語のテキストが正しく並びません。ロケールを生成し、違いを確認します。
sudo locale-gen de_DE.UTF-8
sudo update-locale
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=C sort
printf 'Zebra\nÄpfel\nApfel\n' | LC_ALL=de_DE.UTF-8 sort最初の sort では、最初の UTF-8 バイトが ASCII のどの文字よりも大きいため、Äpfel が Zebra の後に並びます。2 回目の sort では、ドイツ語話者が期待する位置である Apfel の隣に並びます。これは見た目以上に重要です。PostgreSQL と MySQL はデータベース作成時に照合順序を確定し、後から変更するにはインデックスの再構築が必要になるためです。データを投入する前に決めてください。
ドイツ国内のパッケージミラーを使用すると、apt の実行時間を短縮できます。Ubuntu 24.04 では、ソースは deb822 形式の /etc/apt/sources.list.d/ubuntu.sources にあります。そのため、2 つ目のファイルを追加するのではなく、URIs: 行を http://de.archive.ubuntu.com/ubuntu/ に変更します。ファイルを追加すると Target Packages ... is configured multiple times になり、deb822 の重複ソースエラー が発生して、解決するまで更新が停止します。
AAAA レコードを公開します。ドイツの一部の ISP は、DS-Lite（デュアルスタックライト）構成のコンシューマー接続を提供します。この構成では、顧客にパブリック IPv4 アドレスが割り当てられず、IPv4 トラフィックは通信事業者の変換ゲートウェイを経由します。このゲートウェイによって遅延が増加し、ピーク時間帯には混雑します。一方、IPv6 トラフィックは直接外部へ出ます。レコードを設定した後、両方の経路を確認します。
dig AAAA your-server.example.com +short
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://your-server.example.com/2 つ目のコマンドで 200 が表示される場合、IPv6 はエンドツーエンドで機能しています。Could not resolve host または接続エラーが表示される場合は、レコードまたはリスナーが不足しています。その場合、DS-Lite を使用する訪問者は低速な経路を利用することになります。
フランクフルトが適さない場合
- ユーザーが米国にいる場合は、米国から配信します。ダラスの VPS は国内の中心に近く、ニューヨークの VPS ホスティング は東海岸や、いずれにしても大西洋を横断するトラフィックに対して経路が短くなります。
- ユーザーがラテンアメリカにいる場合は、フランクフルトはニューヨークよりもサンパウロから遠くなります。そのため、このユーザー層には ブラジルの VPS が適切です。
- データを EU 外の特定の国に保持する必要がある場合です。カナダの公共部門に関する用途が典型例で、カナダの VPS ホスティングで実際に重要な点 では、同国内でのデータ所在地について説明しています。
- ゲームサーバーを運用する場合です。プレイヤーはラウンドトリップ時間の 1 ミリ秒ごとの差を感じるため、他の仕様よりもプレイヤーとの距離を優先します。ゲームサーバー向け VPS の選び方 では、その点を踏まえて選定します。
複数の国にユーザーが分散している欧州向けのサービスでは、フランクフルトが無難な単一拠点です。規模を拡大しても無難な選択であり続けます。必要なネットワークはすでにインターネットエクスチェンジに接続されているためです。移行前と移行後に、ユーザーの所在地から測定し、両方の測定結果を保存してください。
FAQ
欧州全域に対応するには、Frankfurt の VPS 1 台で十分ですか？
ほとんどのプロジェクトでは十分です。直線距離から算出した下限は Stockholm まで 12.0 ms、Madrid まで 14.2 ms です。実際の経路は通常、その下限の 1.5〜2 倍になるため、EU のほぼ全域が Frankfurt の 1 台のサーバーから数十 ms 程度の低遅延に収まります。特定の国から実際の苦情があり、その原因を測定で確認した場合や、速度ではなくフェイルオーバーが必要な場合に、2 つ目のロケーションを追加してください。
Frankfurt でホスティングすれば、プロジェクトは GDPR に準拠しますか？
いいえ。GDPR の適用は、どの個人データを処理するか、またどこに事業所を置いているかによって決まり、サーバーの場所では決まりません。EU 内でホスティングすれば、その通信区間における国際データ移転の問題はなくなります。これは実際の簡略化ですが、得られる利点はそこまでです。引き続き、適法な処理の根拠、データ主体の権利に対応する仕組み、保存期間の制限、セキュリティ対策、72 時間以内のデータ侵害報告、そしてプロバイダーとの処理者契約が必要です。ドイツでは、この契約を AVV と呼びます。これは一般的な情報であり、法的助言ではありません。
Frankfurt と Berlin の間では、どの程度の遅延が予想されますか？
両都市は 424 km 離れているため、往復遅延の理論上の下限は 4.2 ms です。ピアリングが適切な経路では、通常、その下限の 1.5〜2 倍になります。Berlin の接続から ping -c 20 your-server.example.com で確認し、rtt min/avg/max/mdev 行の avg の値を読み取ってください。その範囲を大きく上回る場合、ネットワークトラフィックがドイツ国外へ出てから戻っている可能性があります。この経路は、ホップ名により mtr -rwzc 50 で確認できます。
Frankfurt のサーバーのタイムゾーンを Europe/Berlin に設定すべきですか？
通常は必要ありません。ログを比較できる状態にし、タイムスタンプが曖昧にならないよう、システムは UTC のままにしてください。ドイツでは春に CEST へ切り替え、秋に CET へ戻します。秋の切り替えが行われる夜には、現地時間の同じ 1 時間が 2 回発生するため、異なるイベントに同じ現地時刻が付く可能性があります。時刻を正しく扱うためのコンテキストがあるアプリケーション側で、現地タイムゾーンに変換して表示してください。サーバー全体を現地時刻に変更する場合は、sudo timedatectl set-timezone Europe/Berlin を実行し、timedatectl で確認してください。
IPv4 専用のサーバーは、ドイツの訪問者にとって問題になりますか？
接続はできますが、一部の利用者では遅くなります。ドイツの複数の ISP は、コンシューマー向け接続にパブリック IPv4 アドレスを持たない DS-Lite 構成を採用しています。そのため、これらの利用者が IPv4 専用サーバーへ接続する際は、通信事業者の変換ゲートウェイを経由し、遅延が増加します。混雑時には、そのゲートウェイが輻輳することもあります。AAAA レコードを公開し、IPv6 で待ち受ければ、利用者は直接経路で接続できます。dig AAAA your-server.example.com +short と curl -6 のリクエストで確認し、どちらのアドレスファミリーからも HTTP 200 が返ることを確認してください。