Site-to-Site VPN を使用すると、アプリケーションのレイテンシーとパフォーマンスの問題が発生するのはなぜですか？
AWS Site-to-Site VPN を使用して AWS のリソースにアクセスすると、オンプレミスアプリケーションでレイテンシーの問題が発生します。
解決方法
Site-to-Site VPN を使用してリソースにアクセスする際にパフォーマンスや遅延の問題が発生する場合は、以下のトラブルシューティング手順に従ってください。
- ソースシステムとデスティネーションシステムを 1 つずつ分離します。
- ネットワークパスに遅延の原因となっている問題がないか確認してください。
- レイテンシー問題の原因となる一般的なエラーがないか、アプリケーションを確認してください。
ソースシステムとデスティネーションシステムを分離
オンプレミスアプリケーションと AWS 間のパフォーマンスの問題を軽減するには、まずソースシステムとデスティネーションシステムを分離します。次に、ネットワークツールを使用して、パフォーマンスに直接影響している可能性のあるアプリケーション外で損失や遅延がないか確認します。
1. ソースとデスティネーションを変更します。別のソースを使用し、次に別のデスティネーションを使用し、変更するたびに問題が解決しないかどうかを確認します。次に、デバイスをチェックして、オペレーティングシステム (OS) の構成に問題がないか、それとも別の問題がないかを確認します。
2. UDP 帯域幅機能テストを実行します。パフォーマンスの問題はスループットの問題を示している可能性があるため、iperf3 ツールを使用してプロビジョニングされた帯域幅を確認してください。このテストは双方向で実行してください。次の UDP テストの例では、iperf3 ツールを使用しています。
注:****-i は間隔、-u は UDP、-b は帯域幅 (適宜調整)、-p は UDP ポート、-v は詳細度を表します。
Server: sudo iperf -s -u [-p 5001] client: sudo iperf3 -i 1 -u -p 33344 -b 1.2G -c <private IP> -V
**注:**使用している Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで帯域幅クレジットが利用可能かどうかを確認してください。または、大きいインスタンスサイズを使用してから、もう一度テストしてください。
3. iperf3 を使用して、Site-to-Site VPN で TCP スループットテストを実行します。このテストは双方向で実行してください。次の例を参照してください。
**注:**最適なパフォーマンスを得るには、インスタンスのサイズを増やすときに、異なる TCP 受信ウィンドウサイズを試して、ソースとデスティネーションのメモリバッファをテストしてください。
Server : iperf3 -s [-p 5001] Client: sudo iperf3 -c <Private IP> -P 10 -w 128K -V sudo iperf3 -c <Private IP> -P 10 -w 512K -V sudo iperf3 -c <Private IP> -P 10 -w 1024K -V
ネットワークパスに問題がないか確認する
ネットワークパッチをチェックして、ネットワークで問題の原因となっている特定のホップまたはデバイスを特定してください。
- Site-to-Site VPN ピア間のパスでパケット損失が発生していないか確認します。
- Site-to-Site VPN トンネルのスループットを確認します。
- カスタマーゲートウェイルーターの設定を確認します。
- パスの最低 MTU を確認します。
Site-to-Site VPN ピア間のパスでのパケット損失を確認
Site-to-Site VPN トンネルは、ピア間の暗号化された通信です。ただし、基盤となるネットワークで損失が発生し、暗号化された通信の品質に影響を及ぼしている場合があります。パケットロスはレイテンシーを増加させ、スループットに直接影響します。
次の式と例を参照してください。
Mathis Equation: Throughput = (MSS/RTT)*(1 / sqrt{p}):
Eg. 1375 MSS, 33ms latency, 0.001%= (1375B / 0.033 sec) * (1/𝑠𝑞𝑟𝑡{0.001})= (41,666.6 * 31.6227)*8 <<< To go from Bps to bps= 10,540,925.5 bps (10.5 Mbps)
スループットの測定値は [ビット単位の TCP ウィンドウサイズ] / [秒単位のレイテンシー (RTT)] です。次の例を参照してください。
Eg. 64K in receive Window, 33ms latency= 524288 bits / 0.033 = 15,887,515 = 15.8 Mbps MAX Possible Throughput
Site-to-Site VPN ピア間のパブリックパスでのパケット損失を確認するには、MTR などの ICMP テストを使用します。MTR のインストールと使用の詳細については、「VPC 内の EC2 Linux または Windows インスタンスとインターネットゲートウェイ経由のオンプレミスホスト間のネットワークパフォーマンスに関する問題のトラブルシューティング方法を教えてください」を参照してください。
次の例を参照してください。
**注:**この例の MTR 出力には、データがないか 100% の損失がある値が含まれています。これは、デバイスが TTL が 0 のパケットをドロップしたが、ICMP 時間超過（タイプ 11、コード 0）メッセージを返さなかったことを示しています。したがって、これらの値は問題を示すものではありません。
[ec2-user@ip-10-7-10-67 ~]$ sudo mtr --no-dns --report --report-cycles 20 18.189.121.166Start: 2023-04-07T16:28:28+0000HOST: ip-10-7-10-67.ec2.internalr Loss% Snt Last Avg Best Wrst StDev 1.|-- ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 2.|-- ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 3.|-- ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 4.|-- 241.0.12.14 0.0% 20 0.4 0.4 0.3 0.8 0.1 5.|-- 240.0.204.2 0.0% 20 0.4 0.4 0.3 0.5 0.0 6.|-- 240.0.204.17 0.0% 20 0.4 0.4 0.3 0.5 0.0 7.|-- 240.0.204.5 0.0% 20 0.4 0.4 0.4 0.5 0.0 8.|-- 242.2.74.145 0.0% 20 1.2 4.0 0.4 23.9 5.7 9.|-- 52.93.29.71 0.0% 20 0.8 2.3 0.7 9.2 2.8 10.|-- 100.100.8.66 0.0% 20 10.8 2.5 0.7 12.8 4.0 11.|-- 100.92.53.85 0.0% 20 26.0 13.3 11.0 26.0 4.4 12.|-- 52.93.239.5 0.0% 20 11.6 12.8 11.4 23.7 2.7 13.|-- 52.95.1.159 0.0% 20 11.0 12.0 11.0 18.3 1.7 14.|-- 52.95.1.186 0.0% 20 11.5 14.1 11.2 32.6 5.9 15.|-- 15.230.39.135 0.0% 20 11.6 11.9 11.1 15.5 1.1 16.|-- 15.230.39.124 0.0% 20 11.7 12.8 11.2 27.2 3.6 17.|-- 108.166.252.38 0.0% 20 11.2 11.2 11.1 11.3 0.0 18.|-- 242.0.102.17 0.0% 20 12.1 12.4 11.2 23.9 2.8 19.|-- 108.166.252.35 0.0% 20 11.3 11.3 11.2 12.3 0.2 20.|-- 241.0.12.207 0.0% 20 11.2 11.3 11.1 13.2 0.5 21.|-- ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 22.|-- ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 23.|-- ??? 100.0 20 0.0 0.0 0.0 0.0 0.0 24.|-- 100.65.30.129 0.0% 20 57.2 24.9 11.6 76.4 17.9 25.|-- 18.189.121.166 0.0% 20 11.3 11.8 11.2 17.6 1.6[ec2-user@ip-10-7-10-67 ~]$
Site-to-Site VPN トンネルのスループットの確認
スループットが 1.2 Gbps の制限を超えていないか確認してください。
1. Amazon CloudWatch コンソールを開いて、サイト間 VPN メトリックスを表示します。
2. TunnelDataIn と TunnelDataOut のメトリクスを選択します。
3. 統計で [合計] を選択し、次に期間で [5分] を選択します。
4. ピーク時のデータポイントに次の計算を適用します。この式では、m1 = TunnelDataIn、m2 = TunnelDataOutとなります。
**注:**スループットが持続的に 1.2 Gbps を超える場合は、ECMP とトランジットゲートウェイを使用して 2 つの BGP トンネルを実装します。
(((m1+m2)/300)*8)/1000000
**カスタマーゲートウェイルーターの設定を確認してください **
カスタマーゲートウェイデバイスに次の設定がないかどうかを確認してください。
- スループットを制限するポリシングポリシーやシェーピングポリシーがないかを確認してください。
- IP パケットの Don't Fragment (DF) フラグをリセットします。
- IPSec パケットを暗号化する前に、必ずフラグメント化してください。
- IP、TCP、UDP、または ESP ヘッダーとデータペイロードが 1500 を超えないように、カスタマーゲートウェイに MSS 設定があるかを確認します。使用している暗号化アルゴリズムの MTU ガイドラインに従ってください。詳細については、「カスタマーゲートウェイデバイスのベストプラクティス」を参照してください。
パスの最低 MTU を確認
パスをテストして、パスの最低 MTU が想定どおりになっているかを確認します。
そのためには、以下を ping してください。-s 1460 <DESTINATION> -M do
[ec2-user@ip-10-7-10-67 ~]$ ping -s 1460 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1460(1488) bytes of data.1468 bytes from 1.1.1.1: icmp_seq=1 ttl=51 time=1.06 ms1468 bytes from 1.1.1.1: icmp_seq=2 ttl=51 time=1.04 ms1468 bytes from 1.1.1.1: icmp_seq=3 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=4 ttl=51 time=1.07 ms1468 bytes from 1.1.1.1: icmp_seq=5 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=6 ttl=51 time=1.06 ms
パス上のデバイスがペイロードをトランスポートできない場合、ICMP path MTU 超過メッセージを返します。
[ec2-user@ip-10-7-10-67 ~]$ ping -s 1480 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1480(1508) bytes of data.From 10.7.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500
よくあるエラーがないか、アプリケーションを確認
オンプレミスアプリケーションで最も一般的な問題がないか確認してください。
- アプリケーション設定の問題。
- データ転送での並列スレッドの使用。Site-to-Site VPN のスループットが予想よりも遅いと思われる場合は、並列スレッドを使用してアプリケーションとは別のスループットを確認してください。
- エクスポネンシャルバックオフによる再試行アルゴリズムの実装。AWS サービスを呼び出すときにタイムアウトが発生した場合は、エクスポネンシャルバックオフによる再試行アルゴリズムを使用してください。
関連情報
関連するコンテンツ
- AWS公式更新しました 2年前
- AWS公式更新しました 2年前
