[！] この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
クラウド間の通信において、インターネットルーティングに悩まされた話を紹介します。なお、アイキャッチ画像は美味しそうなポテトですが、あくまでネットワークの話題になります。
Azure東日本とOCI東京のインターネット通信だけが遅かった
Microsoft Azureの東日本リージョンとOCI（Oracle Cloud Infrastructure）の東京リージョンでIPsec VPN接続を試したところ、通信が遅い症状を経験しました。試したパターンは以下のとおりで、いずれもスループットが10～20Mbps、RTT（Round Trip Time）が50～60msという水準でした。
Azure VPNゲートウェイ～OCI DRG（Dynamic Routing Gateway）※ マネージドVPNサービスで相互接続Azure VNet上の仮想ファイアウォールアプライアンス（S社製）～OCI DRGAzure VNet上のオープンソースVPNサーバー～OCI DRG
この他にも様々な接続パターンを試し、以下の場合は100Mbps以上のスループットと数msのRTTを確認できました。
Azure VNet上のオープンソースVPNサーバー～AWS VPG（Virtual Private Gateway）首都圏データセンターのファイアウォールアプライアンス（F社製）～OCI DRG当社首都圏事業所のファイアウォールアプライアンス（S社製）～OCI DRGAzure ExpressRoute～OCI FastConnect※ 閉域接続サービスで相互接続
以下は、構成の似ている3と4におけるRTT比較結果です。その差はなんと約25倍です。
| 通信 | RTT（Min） | RTT（Avg） | RTT（Max） |
|---|---|---|---|
| 3：Azure 東日本 → OCI 東京 | 53.559 ms | 53.655 ms | 53.729 ms |
| 4：Azure 東日本 → AWS 東京 | 2.101 ms | 2.310 ms | 2.686 ms |
全体を通して、速いケースと遅いケースでVPN装置に共通点や傾向はありません。AzureとOCIのパブリックIPアドレス同士でインターネットVPN接続した場合だけが遅いのです。IPsec周りのパラメーターを変更してみても、改善は見られません。
さらに調べてみたところ、Azure VMからOCI東京リージョンのグローバルIPアドレスに対して、IPsec VPNを使わずインターネット経由でpingを打っても、RTTが同様の数値となりました。
一般的に、太平洋を往復した通信のRTTが100msを超えるのは珍しくないようです。今回のRTTでは、米国よりは近い場所を経由している可能性が高そうです。Azureの管理画面でネットワーク転送料金を確認したところ、検証したVMについてAzureのオーストラリア東部リージョン（au east）からの課金が発生していました。どうやら、VPN設定よりもインターネットルーティングのほうが怪しそうな気配です。
ルーティングの種類
インターネット上では、ISP（Internet Service Provider）をまたいでデータパケットが転送されます。ルーティングの方式として、「ホットポテトルーティング」と「コールドポテトルーティング」があります。
ホットポテトルーティング
ホットポテトルーティングは、所属するネットワーク上での通信を可能な限り少なくして、できるだけ早く隣接するISPに渡す方式です。茹でたてのポテトは手に持つと熱く、すぐ他の人に渡してしまうことから、この呼び方になったようです。
Azureでは「パブリックインターネット経由のルーティング」と表現されます。Azureからの通信は、Microsoftグローバルネットワークを経由せず、すぐISPに転送されます。例えばAzure大阪リージョンから東京の顧客に向けた通信の場合、大阪の時点でMicrosoftネットワークから次のISPに転送され、大阪から顧客間の通信は他のISPを経由して通信します。
コールドポテトルーティング
コールドポテトルーティングは、所属するネットワーク上で可能な限り目的地に近づけてから次のISPに渡す方式です。冷めたポテトは手に持っていられるので、できるだけ遠くまで自分で運んでから他の人に渡す、という考え方です。
Azureでは「Microsoftグローバルネットワーク経由のルーティング」と表現されます。Azureからの通信は、Microsoftネットワーク内を転送された後、顧客に最も近い場所からISPに転送されます。Azure大阪リージョンから東京の顧客に向けた通信の場合、東京までMicrosoftのネットワークを通り、東京から顧客間の通信は他のISPを経由して通信します。
「パブリックIPアドレス」のルーティングオプションを調整する
Azureの「パブリックIPアドレス」には、Basic SKUとStandard SKUの2種類があります。前述の検証で利用していたBasic SKUの場合、ルーティングオプションが「Microsoftネットワーク」（コールドポテトルーティング）に固定されています。
おそらく、コールドポテトルーティングによって、VPN接続先であるOCI東京リージョンを海外と誤認してしまい、Microsoftグローバルネットワークで海外リージョンに転送されてからISPに渡されていた可能性が高いです。つまり、Azure (東日本) – Microsoft Network – Azure（オーストラリア東部） – インターネット – OCI (東京) という経路で通信していたと考えられます。太平洋を横断ではなく縦断していたのであれば、RTTが50～60msなのもありえそうな水準です。
Standard SKUの「パブリックIPアドレス」を作成して、ルーティングオプションを「インターネット」（ホットポテトルーティング）にしたところ、前述の1～3のケースで大幅な改善（スループット140～160Mbps, RTT2～3ms）を確認できました。
ちなみにwhois情報によると、AWS東京リージョン（前述の4のケース）で利用しているグローバルIPアドレスが日本国内扱いであるのに対して、OCI東京リージョンで利用しているグローバルIPアドレスは米国扱いでした。IPアドレスの管理ポリシーは事業者次第ではありますが、Microsoftグローバルネットワーク内で経路が最適化されず海外を経由してしまったのは、このような事情が影響しているのでしょうか。
まとめ
異なるクラウドの首都圏リージョン同士のはずの通信があまりに遅くて、調べてみたら実は海外を経由してたらしい、という話の紹介でした。一般的には、ISPネットワークに依存するホットポテトルーティングよりも、少ないホップ数で送信先に到達できるコールドポテトルーティングのほうが通信品質の面で有利とされますが、今回は冷たいポテトに手を焼く結果となりました。
公開情報だけでは不明な点もあり推測が混ざっていますが、VPN設定よりもインターネットルーティングを疑ってみるほうがいい時もあるということで、参考になれば幸いです。
参考サイト
