著者 Matt Connor
カナダのVPSは必要？PIPEDAと遅延を検証
カナダ国内サーバーが必要になる唯一の理由は法律や契約です。PIPEDAは国内保管を義務付けるのか、Torontoからの往復時間を測る方法とともに解説します。
VPSはカナダに設置する必要がありますか？
カナダのVPSホスティングを選ぶ価値があるのは、法律または契約によってデータをカナダ国内に保管する必要がある場合です。確実な理由はこれだけです。トロントの家庭用接続からニューヨークのデータセンターまでの往復時間は約18 msですが、トロントのデータセンターまではおよそ3 msです。ほとんどのWebアプリケーションでは、この差を判別できません。
カナダのサーバーを選ぶ主な理由は3つあります。データの所在地が法的義務である場合は、それだけで判断できます。レイテンシは測定可能で、通常は想定より小さい値です。カナダドルでの請求は、会計担当者にとって便利です。他の条件を検討する前に、まず1つ目の理由が自社に当てはまるか確認してください。
この記事では、規則の一般的な仕組みを説明します。法的助言ではありません。プライバシー法が組織に適用される場合は、顧問弁護士に確認してください。
データの所在地: 唯一の厳格な要件
PIPEDA (Personal Information Protection and Electronic Documents Act) はカナダの民間部門向け連邦プライバシー法です。個人情報を国内に保管することは要求していません。国外の処理業者にデータを送ることを、処理のための移転として扱います。組織はデータに対する責任を負い続けます。処理業者は同等の保護を提供する必要があります。また、その移転が行われることを本人に明示する必要があります。Office of the Privacy Commissioner は2019年にこの扱いの厳格化について意見を求めましたが、その後も従来の立場を維持しています。したがって、PIPEDA によりデータをカナダに保管しなければならないという一般的な説明は誤りです。多くのホスティング事業者の説明で繰り返されていても同じです。
実際にデータの所在地を定める規則は存在します。ただし、より限定された分野に適用されます。
- Quebec's Law 25 は、個人情報を州外に送信する前に評価を実施することを求めています。また、移転先で情報に十分な保護が提供されなければなりません。この規定は September 2023 から施行されています。これは文書化と、説明可能な判断を求める規定であり、禁止ではありません。
- 公的部門の規則は、公的機関とそれらにサービスを提供する企業を拘束します。Nova Scotia's PIIDPA は、個人情報をカナダ国外に保管することを制限しています。British Columbia's FIPPA にも同様の規定がありましたが、2021年の改正により、評価後の国外保管が認められました。
- 連邦政府の業務には Government of Canada's cloud direction が適用されます。この方針では、Protected B 以上のデータをカナダ国内に保持することが求められます。
- 州の医療プライバシー法は、医療記録を保管できる場所について独自の条件を定めています。条件は州ごとに異なります。
- 実務上、最も一般的な要因は顧客契約と公共調達です。「data at rest in Canada」と記載されたセキュリティ質問票に回答して署名した場合、その条件は法律と同じ程度に組織を拘束します。
実務上の確認方法は簡単です。その根拠となる条項を示せるか確認してください。組織内の誰も、カナダ国内での保管を定める法律または契約を特定できないなら、所在地は法的要件ではなく、遅延と価格に基づいて選択しています。
カナダのデータセンターは米国の法的管轄外ですか？
それだけでは判断できません。米国の CLOUD Act（Clarifying Lawful Overseas Use of Data Act）は、ハードウェアの設置場所にかかわらず、米国のプロバイダーが所有、保管、または管理するデータに適用されます。そのため、米国企業が運営する Toronto リージョンも適用対象です。要件が地理的な場所ではなく、外国の法的手続きに関するものであれば、重要なのはサービスの運営者と暗号化キーの保有者です。建物の所在地がカナダであるだけでは、これを判断できません。
ルーティングも見落としやすい点です。カナダの2つの都市間のトラフィックが米国を経由することは珍しくありません。歴史的に、安価なピアリングが米国に集中しているためです。研究者はこれをブーメランルーティングと呼びます。パケットが国外に出ないと説明する前に、traceroute を実行してください。
traceroute vps.example.comホップ名には、nyc、chi、ash などの都市コードが含まれます。これらの名前は手がかりにすぎず、古くなるため、証拠ではなくプロバイダーに確認するきっかけとして扱ってください。転送中のデータについて信頼できる対策は、地図ではなく、自分で管理する暗号化です。自分のマシン間にプライベートな経路が必要な場合は、自ホスト型 WireGuard VPN を使用できます。ファイバーがどの国を経由するかに左右されません。
レイテンシー: 推測せずに測定します
光ファイバー内の光は1ミリ秒あたり約200 km進みます。そのため、機器の影響を考慮する前でも、距離100 kmごとに往復でおよそ1 msかかります。TorontoからVancouverまでは直線距離で約3,400 kmあり、ケーブル経路ではさらに長くなります。そのため、下限は約40 msです。実際の経路では、これより高くなります。
The data behind this chart
[
{
"label": "Toronto",
"rtt_ms": 3
},
{
"label": "Montreal",
"rtt_ms": 12
},
{
"label": "New York",
"rtt_ms": 18
},
{
"label": "Chicago",
"rtt_ms": 24
},
{
"label": "Northern Virginia",
"rtt_ms": 26
},
{
"label": "Dallas",
"rtt_ms": 42
},
{
"label": "Vancouver",
"rtt_ms": 62
},
{
"label": "London",
"rtt_ms": 88
},
{
"label": "Frankfurt",
"rtt_ms": 98
}
]これは、Torontoで接続状態が良好な一般消費者向け回線について公開されている典型的な数値です。出発点にはなりますが、保証値ではありません。実際の数値は、利用するアクセスネットワークとプロバイダーのピアリングに依存し、時間帯によって変動します。
2つの行は、もう一度確認する価値があります。TorontoからMontrealまでは約 12 msです。これは十分に近いため、ほとんどの用途では2都市を1つのリージョンとして扱えます。TorontoからVancouverまでは約 62 msです。一方、TorontoからNorthern Virginiaまでは 26 msで、Vancouverより近くなります。カナダ国内にあることと、ユーザーの近くにあることは同じではありません。
それでも、通常はラストマイルが大きな要因になります。家庭向けの光回線では数ミリ秒が加わります。ケーブル回線では、回線が混雑するとさらに遅くなります。モバイル接続だけでも数十ミリ秒が加わります。Torontoの携帯電話ユーザーがTorontoのサーバーに接続すると50 msになる場合があります。そのサーバーをNew Yorkに移しても、体感は数パーセントしか変わりません。
ユーザーの所在地からレイテンシをテストする方法
まず、ユーザーが実際にどこにいるかを確認します。アクセス解析では、セッションを都市や地域別にすでに分類できます。オフィスの所在地から推測せず、そのデータを確認してください。
次に、その場所から測定します。Ottawa のデスクから Vancouver のレイテンシはテストできません。対象都市で時間単位の VPS を20分間借り、終了後に削除してください。同僚や顧客に1つのコマンドを実行してもらう方法もあります。または、無料の RIPE Atlas 測定ネットワーク（https://atlas.ripe.net）を使用してください。カナダの都市にプローブがあり、そこから ping を実行できます。
sudo apt update && sudo apt install -y mtr-tiny traceroute iperf3
ping -c 20 vps.example.com最後の2行を確認してください。
20 packets transmitted, 20 received, 0% packet loss, time 19031ms
rtt min/avg/max/mdev = 17.412/18.006/19.882/0.594 msavg は主要な数値です。mdev はジッターで、パケット間のばらつきを示します。短い経路でパケットロスが発生する場合は、調査すべき障害です。ジッターが大きいと、平均値が少し高い場合よりも音声やゲームに大きな影響があります。受信側は通常のパケットではなく、最も遅いパケットに合わせてバッファリングする必要があるためです。
mtr --report --report-cycles 50 vps.example.commtr は各ホップのパケットロスを表示します。権限エラーで終了する場合は、sudo を付けて実行してください。中間ホップでは、実際には発生していないロスが表示されることがよくあります。ルーターは、自身が生成する ICMP 応答の優先度を最も低くするためです。最終行まで継続するロスだけが、実際にネットワークトラフィックへ影響するロスです。まず最下行を確認し、その後で上へ向かって確認してください。
ICMP がブロックされているか、レート制限されている場合は、実際のプロトコルの時間を測定してください。
curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://vps.example.com/各フィールドは、リクエスト開始時点からの累積秒数です。connect から dns を引くと、TCP の1往復時間になります。tls から connect を引くと、ハンドシェイクの時間になります。ttfb から tls を引くと、もう1往復する時間に、アプリケーションが応答するまでの時間を加えた値になります。多くの低速なサイトでは、この最後の差分で大部分の時間を失っています。短い経路で ttfb が0.8 sになる場合はアプリケーションの問題です。サーバーを別の都市へ移動しても改善しません。
スループットを測定する場合は、VPS 上でサーバーを実行し、ユーザー側からクライアントを実行してください。iperf3 は TCP 5201 で待ち受けるため、テスト用に ufw でポートを開く、終了後に再び閉じてください。
iperf3 -siperf3 -c vps.example.com -t 20
iperf3 -c vps.example.com -t 20 -R
iperf3 -c vps.example.com -t 20 -P 8-R は方向を逆にするため、アップロードとダウンロードの両方を測定できます。-P 8 は8本の並列ストリームを開きます。8本のストリームが1本より大幅に高速な場合、制限は回線自体ではなく、長い経路上の TCP ウィンドウにあります。1本のストリームで1回の往復時間に送信できるのは、1つのウィンドウ分だけだからです。Vancouver 経路では、同じウィンドウで1秒あたりに転送できるデータ量が、New York 経路のおよそ3分の1になります。長距離バックアップも同じ動作をするため、高速な回線でも、遠隔の宛先に対する restic でのオフサイトバックアップは遅く感じられます。
iperf3 の実行中は、別のターミナルで ping を継続してください。転送中に往復時間が20 msから300 msへ増加する場合は、自分のアクセス機器でバッファブロートが発生しています。データセンターの場所を変更しても解決しません。
複数回測定し、夕方にも測定してください。9pm の混雑状況が、ユーザーが実際に経験する数値です。4am の数値は、販売ページが掲載したがる数値です。
ワークロードにおけるラウンドトリップ時間の意味
ページを初回ロードすると、ブラウザーが何かを描画できるようになるまでに4回のラウンドトリップが発生します。
The data behind this chart
[
{
"label": "DNS lookup",
"toronto_to_new_york_ms": 18,
"toronto_to_vancouver_ms": 62
},
{
"label": "TCP handshake",
"toronto_to_new_york_ms": 18,
"toronto_to_vancouver_ms": 62
},
{
"label": "TLS 1.3 handshake",
"toronto_to_new_york_ms": 18,
"toronto_to_vancouver_ms": 62
},
{
"label": "Request and first byte",
"toronto_to_new_york_ms": 18,
"toronto_to_vancouver_ms": 62
},
{
"label": "All four round trips",
"toronto_to_new_york_ms": 72,
"toronto_to_vancouver_ms": 248
}
]DNS lookupはサーバーではなくresolverに送信されます。通常はキャッシュされるため、再訪問時には省略されます。エンドツーエンドで数えると、初回ロードではNew York経路で 72 ms、Vancouver経路で 248 msの遅延が発生します。どちらも、単一の400 msのdatabase queryと比べれば無視できる値です。接続が確立されると、HTTP/2とHTTP/3は同じ接続上で多数のリクエストを同時に処理します。そのため、このコストはファイルごとではなく1回だけ発生します。静的アセットをCDN（content delivery network）に配置すれば、それらについてはoriginの都市はまったく影響しません。そのため、Torontoまで 98 msかかる欧州のユーザーでも、高速なページを取得できます。
リアルタイムのマルチプレイヤーゲームは正反対です。ラウンドトリップそのものが体験に影響するためです。高速なアクションゲームでは、おおむね50 ms未満なら即時に感じられます。80 ms前後からプレイヤーが遅延に気付き始め、120 msを超えるとサーバーの問題だと考えます。この場合、リージョンが製品の品質を実際に左右します。進行の遅いゲーム用サーバーは遅延に対してはるかに寛容です。そのため、VPSでMinecraftサーバーを実行する場合は、シューティングゲームなら致命的になる距離でも問題になりません。
リージョンの選択が大きな影響を与えるのはdatabaseです。アプリケーションを一方のリージョンに置き、databaseを別のリージョンに置いてはいけません。すべてのqueryでラウンドトリップが発生します。40個のqueryを実行するページでは、各 18 msの遅延が40回発生します。これはほぼ1秒です。各 62 msの場合は2秒を超えます。同じサーバー上にdatabaseを置いた場合、プロファイル結果が30 msだったページでも同様です。別のリージョンへの非同期レプリケーションは、read replicaやdisaster recoveryには適しています。長距離経路で同期commitを行うと、その経路の遅延がすべてのwriteに加わります。
インタラクティブなセッションはその中間です。SSHはおよそ100 msまでなら快適に使用できますが、それを超えると遅延を感じます。各キー入力のエコーが戻るまで待つ必要があるためです。moshはローカルで予測し、その遅延の大部分を隠します。Webhookと内部APIは、呼び出すサービスと常に同じリージョンに配置してください。
料金、通貨、税金
カナダドルで支払うと、カード発行会社が請求する外国為替手数料を避けられます。2026年8月時点では、通常約2.5%です。また、帳簿上の通貨を1つに統一できます。カナダのプロバイダーは GST または HST を含む請求書を発行します。登録事業者は、その税額を仕入税額控除として還付申請できます。これは財務上の問題であり、財務上の答えがあります。パケットの送信先を決める要因にしてはいけません。サーバーの実際の費用と、更新時の価格に惑わされずにプランを比較する方法については、VPSの月額費用の実態を参照してください。
小規模な市場で発生する制約
カナダのホスティング市場は米国と比べて小規模です。現実的な判断には、何を諦めることになるかも含まれます。
- あなたの予算をめぐって競争するプロバイダーが少ないため、同じクラスのマシンでは、RAMまたはディスクの1GBあたりの料金が通常高くなります。
- キャパシティはTorontoとMontrealに集中しており、VancouverとCalgaryは少なめです。フェイルオーバー用にカナダ国内の2番目のリージョンを用意すると、長い経路になるか、結局カナダ国外に出ることがよくあります。
- 小規模な地域ホストは、1つの建物を1社または2社の上流キャリア経由で運用している場合があります。キャリアが何社あるか、また、そのうち1社に障害が発生した場合にどうなるかを確認してください。
- ハードウェアの選択肢は限られます。大規模なインスタンスやGPUマシンは、米国のリージョンのほうが見つけやすいため、希望する都市で希望するサイズのGPU VPSを利用できない場合があります。
- 小規模ホストのサポート体制は、宣伝文句ではなく実際に確認すべき問題です。担当者が対応できる時間帯を確認してください。
料金面ではMontrealが例外です。Quebecの水力発電は安価で、冬季は冷却コストも下がるため、Montreal周辺には米国のリージョンと競争できる料金で多くのキャパシティがあります。特定の都市ではなくカナダ国内であることが要件なら、まずMontrealから検討してください。
カナダのVPSのプランがワークロードに対して小さすぎる場合は、その国が問題だと判断する前に、VPSと専用サーバーを比較することをおすすめします。
カナダでのVPSホスティングが適切な場合
- 法令、契約、または公的機関の方針でカナダが指定されている場合は、カナダでホスティングします。この投稿の他の内容は適用されません。プロバイダーからデータの所在に関する確約を書面でも取得してください。
- ユーザーがカナダ国内の1つの都市圏に集中しており、ワークロードがレイテンシーの影響を受ける場合です。対象には、マルチプレイヤーゲーム、音声通信、リモートデスクトップ、取引などがあります。最寄りの都市でホスティングし、契約する前に両方の選択肢を測定してください。
- ユーザーが国内各地に分散している場合です。TorontoまたはMontrealが人口の最大部分をカバーします。静的アセットの前段にCDNを配置するほうが、Vancouverの訪問者にとってはoriginを移動するより効果的です。
- その他のすべての場合です。これは大半のケースに当てはまります。価格と実際に提供されるハードウェアで選び、2amのサポート状況も確認してください。候補を先にベンチマークしてください。同じ仕様表の2つのプランでも、性能は同じとは限りません: VPSを適切にベンチマークする方法。
どの方法を選ぶ場合でも、その理由を決定事項の横に記録してください。次に、これをカナダに配置すべきか尋ねる人には、推測よりも確かな情報が必要です。回答が契約条項だった場合は、誰かが再びそれを見つけなければなりません。インスタンスが用意された後は、新しいVPSで最初の10分間に行うことのほうが、都市よりもセキュリティに大きく影響します。
FAQ
PIPEDAではデータをカナダ国内に保管する必要がありますか？
いいえ。PIPEDA（Personal Information Protection and Electronic Documents Act）には、民間部門に対するデータ所在地の規定はありません。別の国の processor に個人情報を処理目的で送信することは、処理のための移転に該当します。この場合も、データに対する責任は組織に残ります。processor は同等の水準でデータを保護する必要があり、そのような移転が行われることを本人に明示する必要があります。Office of the Privacy Commissioner は2019年にこの方針の変更について協議しましたが、その後も方針を維持しました。データ所在地の要件は、別の法令や契約から生じます。たとえば、Quebec's Law 25 に基づく評価、Nova Scotia's PIIDPA などの公共部門向け法令、Government of Canada の cloud 方針、または顧客との契約に含まれる条項です。
米国のサーバーを使用すると、カナダのユーザーは気付きますか？
通常の Web アプリケーションであれば、気付きません。Toronto から New York までの往復は約 18 ms、Northern Virginia までは約 26 ms です。いずれも、Toronto から Vancouver までの 62 ms より短時間です。ユーザーは、ネットワークの20 msの遅延に気付く前に、サーバーの応答時間やページのサイズに気付きます。ただし、リアルタイムゲーム、音声通話、または一方の人の反応に対して別の人が応答する処理では、遅延に気付くことがあります。
カナダの data centre は米国法の適用外ですか？
自動的に適用外になるわけではありません。US CLOUD Act は、サーバーの所在地に関係なく、US provider が保有、管理、または制御するデータに適用されます。そのため、American company が運用するカナダの region も対象です。外国の法的手続きが実際の懸念である場合は、建物の住所ではなく、サービスの運用者と encryption key の保有者を確認してください。自分で保有する key を使用して暗号化すると、provider が引き渡せるデータの範囲が変わります。
居住していない都市から latency を測定するにはどうすればよいですか？
その都市で hourly VPS を借り、ping -c 20 と mtr --report --report-cycles 50 を実行して自分のサーバーへの通信を測定し、その後 VPS を削除します。RIPE Atlas network も、カナダの都市に probe がある無料の代替手段です。ICMP がブロックされている場合は、代わりに curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ を使用して実際の request の時間を測定します。curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer}\n' https://your.server/ では、TCP の往復時間と最初の byte を受信するまでの合計時間を確認できます。