この記事は Alibaba Cloud の日本サイト の環境（ドキュメントやアカウント、そのアカウントでの検証結果）に基づいて記載しています。 日本サイトと国際サイトでは各プロダクトごとに提供機能が一部異なることがあります（そのほとんどは国際サイトの方が日本サイトよりも多機能になっている）。記事の内容は適宜最新化する予定です。
今回はAlibaba Cloudのリージョン間をAlibaba CloudのVPN GatewayでIPsec接続し、東京リージョンと上海リージョン間の通信品質（Latencyとスループット）を確認します。
目次
テスト結果のサマリ
最初にテスト結果を紹介します。 以下、東京リージョンのECSと上海リージョンのECS間の測定結果です。
- IPsec構成時、Latency(Ping)は平均35ms、最小35ms、最大36ms
- 1ファイル（247MB)のコピーのスループットは平均57Mbps
- 小さいファイルの大量コピー（445MB,340ファイル ） のスループットは平均17Mbps
Express ConnectやCENが不要ではと思わせる結果でした。 もちろん、インターネット経由ですので途中の経路の混雑やその他要因により通信が行えない事態も考えられます。 常時安定した通信品質を確保したい場合はExpress ConnectやCENの出番となると思います。
環境構築とテストの実施手順
手順の流れは以下の通り。
- VPC作成
- VPN Gatewayの購入
- Customer Gatewayの作成
- IPsec Connectionsの設定
- Static routeの設定
- Latencyのテスト
- スループットのテスト
- まとめ
なお、VPN Gatewayの設定手順はAlibaba Cloudの公開ドキュメントを参考にしました。記載の内容をほぼそのまま実施しています。
VPC作成
まず、日本リージョンと上海リージョンのそれぞれにVPCを作成します。既にあるVPCを利用しても問題ありません。 その際にはVSwitchのCIDRに重複がないよう注意してください。 VPCのCIDRについては重複していてもVPN接続は可能です。
日本側のVPCを作成します。 日本と上海でVPCのCIDRの重複を避けるために、CIDRを既定のビットから変更します。 コンソールではなくAPIによる設定が必要ですので今回はOpenAPI ExplorerからVPCを作成します。
- RegionID : Japan(Tokyo)
- CidrBlock : 10.10.10.0/24
- VpcName : testVPN_JP
次に上海リージョンのVPCを作成します。
- RegionID : China (Shanghai)
- CidrBlock : 10.10.20.0/24
- VpcName : testVPN_JP
手順は省略しますが東京リージョンと上海リージョンのVPCにVSwitchを作成しておきます。
VPN Gatewayの購入
東京リージョンと上海リージョンにVPN Gatewayのインスタンスを購入します。 VPN Gatewayは従量課金となり、帯域やSSL-VPN接続数で時間当たりの課金が変わります。
まず、東京リージョンでVPN Gatewayを購入します。 ”VPN Gatewayの作成”をクリックします。
パラメータを指定し、購入します。
- VPCには上の手順で作成したものを指定
- トラフィックのテストのために100 Mbpsを指定
- SSL-VPNを有効化（別のテストのため。今回のIPsec接続では不要）
VPN Gatewayのインスタンスが作成されました。
次に上海リージョン側のVPN Gatewayを購入します。
上海側のVPN Gatewayインスタンスも作成されました。
Customer Gatewayの作成
Customer Gateway（カスタマーゲートウェイ）は一言でいえば”対向のGW”です。 接続先のIPsecルータを定義するということです。
日本側のCustomer Gatewayを作成します。VPN設定から”Custmer Gateways”をクリックします。 右側に表示される”カスタマーゲートウェイの作成”をクリックします。
カスタマーゲートウェイは対向のGW（上海リージョンのVPN Gateway）を定義します。
作成できました。
次に上海側のCustomer Gatewayを作成します。
上海側には 対向のGWとして東京リージョンのVPN Gatewayを定義します。
上海側も設定が出来ました。
IPsec Connectionsの設定
次にIPsecの定義を行います。こちらも日本リージョン側と上海リージョン側のそれぞれで必要な設定となります。
それでは日本側から設定します。 日本（東京）を選び、IPsec Connectionsから”VPN 接続の作成”をクリックします。
以下を設定します。
- 名前 : 任意の定義名
- VPN Gateway : リストボックスから日本のVPN Gatwayを選択
- カスタマーゲートウェイ : リストボックスから対向のGWを選択
- ローカルネットワーク : 日本側のVPCのCIDR
- リモートネットワーク : 対向（上海）のVPCのCIDR
まだ設定は終わりません。”高度な構成”を有効にします。
今回はAlibaba Cloud VPN Gateway同士の接続となるためバージョンや暗号および認証アルゴリズムは特に変更しません。事前共有鍵のみ設定します（画面上は入力していませんが、実際の設定時には入力してください）。
出来上がりました。 対向側を設定していないので接続ステータスは失敗です。
次に上海側を設定します。 中国東部（上海）を選び、IPsec Connectionsから”VPN 接続の作成”をクリックします。
以下を設定します。
- 名前 : 任意の定義名
- VPN Gateway : リストボックスから上海のVPN Gatwayを選択
- カスタマーゲートウェイ : リストボックスから対向のGWを選択
- ローカルネットワーク : 上海側のVPCのCIDR
- リモートネットワーク : 対向（日本）のVPCのCIDR
- 事前共有鍵 : 日本側と上海側で同じ文字列を入力
上海側の設定が出来上がりました。 設定直後は接続ステータスも失敗のままです。ちょっと待ちましょう。
接続が正常に完了すると以下の表示になります。
日本側
上海側
Static routeの設定
日本と上海のVPCにStatic routeを追加します。
日本側から設定します。 VPCの画面から日本（東京）を選び、Route Tablesをクリックします。 今回利用しているVPCの”管理”をクリックします。
”ルートエントリの追加”をクリックします。
以下を設定します。
- ターゲット CIDR: DestinationのCIDRを指定（日本側では上海のVPCのCIDRを指定。32ビットで特定のホストだけに限定も可能）
- Next Hop :”VPN Gateway”を指定
カスタムルールが追加されました。
同じ様に上海側にも定義を追加します。
”ルートエントリの追加”をクリックします。
以下を設定します。
- ターゲット CIDR: DestinationのCIDRを指定（上海側では日本のVPCのCIDRを指定。32ビットで特定のホストだけに限定も可能）
- Next Hop :”VPN Gateway”を指定
上海側にもStatic routeが設定出来ました。
Latencyのテスト
これまでの作業で以下の環境が出来上がりました。ECSの作成は省略しています。
それでは疎通確認を行います。 テスト用のECSはパブリックIPアドレスを持っていないため、コンソールから標準提供されるVNC機能でWindows Serverを操作していきます。
わかりやすいようにデスクトップの背景が青色が日本側のECSです。
まずはネットワーク設定を確認します。 日本側のVPC（CIDR:10.10.10.0/24)のVSwitch（CIDR:10.10.10.0/25）のIPアドレス（10.10.10.82)を持っています。 デフォルトゲートウェイは10.10.10.125です。
同様に上海側も確認します。上海側のECSのWindows Serverのデスクトップは赤色にしています。
上海側のVPC（CIDR:10.10.20.0/24)のVSwitch（CIDR:10.10.20.0/25）のIPアドレス（10.10.20.78)を持っています。 デフォルトゲートウェイは10.10.20.125です。
まずは日本側から上海のGW(10.10.20.125)にpingします。
60回のPingの結果は以下の通りです。 平均35msです。最小35ms、最大36msと非常に安定しています。
次は上海側から日本のGW(10.10.10.125)にpingします。
60回のPingの結果は以下の通りです。 日本側からと同じ結果となりました。平均35msです。最小35ms、最大36msと非常に安定しています。
次に、ECSインスタンスのWindows ServerへPingをテストします。
日本のECSから上海のECSへのPing結果です。 平均35msでした。
上海のECSから日本のECSへのPing結果です。 平均35msでした。
次はtracerouteします。
日本のECSから上海のECSへの結果は以下の通りです。
上海のECSから日本のECSへの結果は以下の通りです。
スループットのテスト
次にスループットのテストをしてみます。 本当は測定ツールを使うのですが、今回は簡易なテストとして、エクスプローラからのコピーを行い、その際のスループットを確認します。
以下環境で東京のECSから上海のECSのコピー、一部のテストで東京のリージョン内の2台のECS間でコピーを実施しています。
テストデータにはC:\Windows\fontsフォルダのデータを使います。合計445MBもあり、ファイル数も340個、1ファイル平均1.3MBとまあサンプルとしては悪くはないでしょう。
コピーテストは以下の3パターン実施します。
- スループットの確認
- Latencyの影響の確認（同一リージョン内コピー）
- Latencyの影響の確認 （リージョン間コピー）
テスト#1 スループットの確認
C:\windows\fontsフォルダをZIPで固めて1つのファイルにします。 1つのファイルとすることでシーケンシャルなコピー処理となり、ネットワークのスループットの測定が可能になります。
事前に上海側のECSにtempという共有フォルダを作成し、セキュリティグループの設定でSMBの通信を許可しておきます。 UNCパスで上海のECSにアクセスします。
共有フォルダ\\10.10.20.78\tempにアクセス出来ました。
それでは1つ目のテストとして1つのZIPファイル （247MB）をコピーしてみます。
コピー完了時間は34秒でした。ファイルサイズは247MBですので平均で約58Mbpsのスループットです。リソースモニタで見る限り、Peakは100Mbps近くまで速度が出ており東京-上海間の結果としては優秀な結果だったのではないでしょうか。
テスト#2 Latencyの影響の確認 （同一リージョン内コピー）
続いて2番目のテストとしてc:\windows\fontsフォルダ（445MB,340ファイル ）をそのままコピーしてみます。 小さなファイルを大量にコピーすることになります。
まず、Latencyの影響が小さい東京リージョン内の2台のECSでコピーを実行し、スループットを確認します。
結果は約10秒で平均約356Mbpsのスループットです。 Peakでは400Mbps超のスループットを確認出来ました。
このテストで分かったことはECSの性能がボトルネックとなる可能性は低いことです。次のテスト#3のリージョン間コピーでもLatencyの影響がなければ100Mbpsに近いスループットが理論上出ると思われます。
しかし、予想される結果として日本と上海間の平均35msのLatencyにより100Mbpsのスループットは出ないはずです。
テスト#3 Latencyの影響の確認 （リージョン間コピー）
続いて、東京のECSから上海のECSへコピーします。 35msのLatencyの影響はどれくらいあるか楽しみですね。
コピー完了時間は210秒でした。平均で約17Mbpsのスループットです。 パフォーマンスモニタで見ている限りPeakでは100Mbps近くまでスループットが出ている時もありますが、実施前の予想通り、サイズが小さいファイルが多いことによりパケットのやり取りが増え、結果、コピー完了の時間が長くなったと推測されます。
まとめ
以下の記事でも紹介していたように、Alibaba Cloudのリージョン間の通信はインターネット経由の場合でも高速で、VPN Gatewayを利用しても同様の結果と傾向を確認出来ました。
また、東京と上海間の35msの遅延は、大量のファイルのコピーを行う場合には影響があることも確認出来ました。 それでも通常のインターネット経由のLatency（上記の記事では平均119ms、最小と最大の幅も大きい）よりは短時間でコピーが完了しているはずです。Alibaba Cloudを利用するメリットと言えるでしょう。
今後の追試するべきこととしては以下でしょうか。
- VPN Gatewayがボトルネックとなっていないか？ 100Mbpsが性能上限ですが、ソフトウェア処理と仮定して100Mbpsのスループットを安定して出せるものなのか未知数です。 例えば、ハイスペックなECS上にOpenSwanなどでVPNサーバを構築し、比べてみるとよいかもです
- 同じリージョン・ゾーン内でのコピーでは400Mbpsのスループットでしたが、本来はQoSで100MbpsでLimitをかけてテストするべきでした（実はWindows Server標準のQoS機能で制限かけてみたのですが期待したように動作せずで今回は断念。。。）
- 通常のインターネット経由のコピーテストと比較することでよりAlibaba Cloudのリージョン間のインターネット経路の品質の良さが確認できるはず
- 日本と上海間のインターネット経由で平均35msのLatencyも試行回数や時間帯（平日の日中帯の混雑時）にも計測するべきでしょう
新たな課題（やりたいこと、試したいこと）が生まれているということで有意義なテストだったかなと思います。
以上
