ネットワーク パフォーマンスのトラブルシューティング
概要
Azure では、オンプレミスのネットワークから Azure に接続するための高速で安定した方法を提供します。 大小を問わずすべての企業のお客様が、サイト間 VPN や ExpressRoute などの方法を上手に利用して Azure でビジネスを運営しています。 一方で、パフォーマンスが期待通りではなかったり、これまでのエクスペリエンスを下回った場合にはどうなるでしょうか。 この記事は、特定の環境をテストしてベースラインを作成する方法を標準化するのに役立ちます。
一貫性を保ちつつ簡単に、2 つのホスト間のネットワーク待機時間と帯域幅をテストする方法を説明します。 また、問題点を特定するのに役立つ Azure ネットワークの検査方法に関するアドバイスも提供します。 ここで取り上げる PowerShell スクリプトとツールでは、ネットワーク上 (テストするリンクの両端) に 2 つのホストが必要です。 一方のホストは Windows Server または Windows デスクトップの必要があります。もう一方のホストには Windows または Linux のいずれかを使用できます。
ネットワーク コンポーネント
トラブルシューティングの詳細を説明する前に、一般的な用語とコンポーネントについて見ていきましょう。 これにより、Azure の接続性を実現するエンドツーエンド チェーン内の各コンポーネントについて考えていくことができます。
最上位のレベルには、主要なネットワーク ルーティング ドメインが 3 つあります。
- Azure ネットワーク (青色のクラウド)
- インターネットまたは WAN (緑色のクラウド)
- 企業ネットワーク (オレンジ色のクラウド)
図を右から左へ見ていきながら、各コンポーネントについて簡単に説明します。
仮想マシン - サーバーには複数の NIC がある場合があります。 すべての静的ルート、既定ルート、およびオペレーティング システムの設定で、想定どおりにトラフィックの送受信が行われていることを確認します。 また、各 VM の SKU には、帯域幅制限があります。 SKU のサイズが小さい VM を使用している場合、NIC で使用可能な帯域幅によってトラフィックが制限されます。 VM に十分な帯域幅を確保するために、テストには DS5v2 を使うことをお勧めします。
NIC - 問題の NIC に割り当てられているプライベート IP を把握していることを確認します。
NIC の NSG - NIC レベルで適用されている特定の NSG がある場合、渡そうとしているトラフィックに対して NSG のルール セットが適切であることを確認します。 たとえば、iPerf 用のポート 5201、RDP 用のポート 3389、または SSH 用のポート 22 が開いていて、テスト トラフィックを渡すことが許可されていることを確認します。
VNet のサブネット - NIC は特定のサブネットに割り当てられます。NIC がどのサブネットに割り当てられているか、およびそのサブネットに関連付けられているルールについて把握していることを確認します。
サブネットの NSG - NIC と同様に、サブネットにも NSG を適用できます。 渡そうとしているトラフィックに対して NSG のルール セットが適切であることを確認します NIC への受信トラフィックについては、最初にサブネットの NSG、次に NIC の NSG が適用されます。 トラフィックが VM から外部に送信されるときは、最初に NIC の NSG、次にサブネットの NSG が適用されます。
サブネットの UDR - ユーザー定義ルートでは、中間のホップ (ファイアウォールやロードバランサーなど) にトラフィックを向けることができます。 トラフィックに UDR が設定されているかどうかを必ず確認してください。 その場合は、その宛先と、トラフィックに対して次ホップで行われる処理を把握しておいてください。 たとえば、同じ 2 つのホスト間でも、ファイアウォールで許可されるトラフィックもあれば、拒否されるトラフィックもあります。
ゲートウェイ サブネット、NSG、UDR - VM サブネットと同様に、ゲートウェイ サブネットも NSG と UDR を持つことができます。 それらがあるかどうか、およびトラフィックに対してどのような影響があるかを確認してください。
VNet ゲートウェイ (ExpressRoute) - ピアリング (ExpressRoute) または VPN を有効にすると、トラフィックのルーティングの有無や方法に影響を与える設定はあまりありません。 複数の ExpressRoute 回線または VPN トンネルに接続されている仮想ネットワーク ゲートウェイがある場合は、接続の重み設定に注意する必要があります。 接続の重みは接続の優先順位に影響し、トラフィックのパスを決定します。
ルート フィルター (表示されません) - ExpressRoute 経由で Microsoft ピアリングを使用する場合は、ルート フィルターが必要です。 ルートを受信していない場合は、ルート フィルターが構成され、回線に正しく適用されているかどうかを確認してください。
ここで、リンクの WAN の部分に来ました。 このルーティング ドメインは、サービス プロバイダー、会社の WAN、またはインターネットの場合があります。 これらのリンクには多くのホップ、デバイス、および企業が関係しているため、トラブルシューティングが困難になる場合があります。 間にあるホップを調査する前に、まず Azure と企業ネットワークの両方を除外する必要があります。
上の図の一番左にあるのが企業ネットワークです。 会社の規模によって、このルーティング ドメインはユーザーと WAN との間のいくつかのネットワーク デバイスである場合もあれば、キャンパスまたは企業ネットワーク内の複数レイヤーのデバイスである場合もあります。
これら 3 つの異なる上位ネットワーク環境の複雑さを考慮すると、 通常は端から開始して、パフォーマンスが良好な部分とパフォーマンスの低下がみられる部分を明らかにしていくことが最適と言えます。 この方法は、この 3 つの中で問題があるルーティング ドメインを特定するのに役立ちます。 その後、その特定の環境にトラブルシューティングを集中できます。
ツール
ネットワークのほとんどの問題は、ping や traceroute などの基本的なツールを使用して分析し、特定できます。 Wireshark などのツールを使用したパケット分析にまで進む必要があることはほとんどありません。
トラブルシューティングに役立つように、Azure Connectivity Toolkit (AzureCT) が開発されて、これらのツールの一部が使いやすいパッケージにまとめられました。 パフォーマンス テストでは、iPerf や PSPing などのツールによって、ネットワークに関する情報が提供されます。 iPerf は、基本的なパフォーマンス テストでよく使用される、非常に使いやすいツールです。 PSPing は、SysInternals によって開発された ping ツールです。 PSPing では、リモート ホストに到達するために ICMP と TCP の両方の ping を実行できます。 これらのツールはどちらも軽量で、ホスト上のディレクトリにファイルをコピーするだけで "インストール" できます。
これらのツールとメソッドは、インストールして使用できる PowerShell モジュール (AzureCT) にラップされています。
AzureCT - Azure Connectivity Toolkit
AzureCT の PowerShell モジュールには、可用性テストとパフォーマンス テストの 2 つのコンポーネントが含まれています。 このドキュメントで取り上げるのはパフォーマンス テストのみのため、この PowerShell モジュールの 2 つの LinkPerformance コマンドに注目しましょう。
このツールキットをパフォーマンス テストに使用する基本的な手順は次の 3 つです。
PowerShell モジュールのインストール。
(new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expressionこのコマンドは、PowerShell モジュールをダウンロードしてローカルにインストールします。
関連アプリケーションをインストールします。
Install-LinkPerformanceAzureCT のこのコマンドにより、iPerf と PSPing が新しいディレクトリ
C:\ACTToolsにインストールされます。また、これによって Windows ファイアウォールのポートが開き、ICMP とポート 5201 (iPerf) のトラフィックが許可されます。パフォーマンス テストを実行します。
まず、リモート ホストに iPerf をインストールし、サーバー モードで実行する必要があります。 また、リモート ホストはポート 3389 (Windows の RDP) またはポート 22 (Linux の SSH) のいずれかでリッスンし、iPerf 用のポート 5201 でトラフィックが許可されていることを確認します。 リモート ホストが Windows の場合は、AzureCT をインストールし、Install LinkPerformance コマンドを実行します。 このコマンドを実行すると、iPerf と、サーバー モードで iPerf を正常に起動するために必要なファイアウォール規則が設定されます。
リモート マシンの準備ができたら、ローカル コンピューターで PowerShell を開き、テストを開始します。
Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10このコマンドにより、負荷と待機時間に関する一連のテストが同時に実行されます。これらのテストは、ネットワーク リンクの帯域幅容量と待機時間の評価に役立ちます。
テストの出力を確認します。
PowerShell の出力形式は次のようになります。
iPerf と PSPing のすべてのテストの詳細な結果は、AzureCT ツールのディレクトリ (C:\ACTTools) 内の、個々のテキスト ファイルで確認できます。
トラブルシューティング
パフォーマンス テストで期待した結果が得られない場合、その理由を明らかにするには手順を踏んだ段階的なプロセスが必要です。 パス内のコンポーネントの数を考慮すると、あれこれ試してみるよりも、体系的なアプローチを取った方が解決への早道となります。 体系的にトラブルシューティングを行うことで、不要なテストを複数回実行せずに済みます。
Note
ここで紹介するシナリオはパフォーマンスの問題であり、接続の問題ではありません。 Azure ネットワークへの接続の問題を特定するには、ExpressRotue 接続の確認に関する記事に従ってください。
まず、想定を見直します。 期待は妥当でしょうか。 たとえば、1 Gbps の ExpressRoute 回線と 100 ミリ秒の待機時間があるとします。 待機時間の長いリンクでの TCP のパフォーマンス特性を考慮すると、1 Gbps の完全なトラフィックを期待することは妥当ではありません。 パフォーマンスの想定については、「参照」をご覧ください。
次に、ルーティング ドメイン間の端の部分から始めて、1 つの主要なルーティング ドメインに問題を絞り込むことをお勧めします。 企業ネットワーク、WAN、または Azure ネットワークから開始できます。 パス内の "ブラック ボックス" が非難されることがよくあります。 ブラック ボックスを非難することは簡単ですが、それによって解決が大幅に遅れる可能性があります。 問題が、問題を修正するために自分で変更を行える領域にある場合は、特にそうです。 サービス プロバイダーや ISP に任せる前に、しかるべき努力を払うようにしましょう。
問題が含まれるとみられる主要なルーティング ドメインを特定したら、問題の領域を表す図を作成する必要があります。 図を描くと、問題に体系的に対処し、切り分けることができます。 テスト ポイントを計画し、テストが進むにつれて、問題がないことが明らかになった領域や詳細なテスト結果をもとに作戦図を更新できます。
図を作成したら、まずネットワークをセグメントに分けて、問題を絞り込みます。 機能している箇所と機能していない箇所を調べます。 テスト ポイントを移動させて、問題となっているコンポーネントを特定します。
また、OSI モデルの他の層も忘れずに確認します。 ネットワークと 1 - 3 層 (物理、データ、およびネットワーク層) に的を絞りがちですが、アプリケーション レイヤーの 7 層にも問題が見つかる場合があります。 先入観を抱かずに、想定を確認します。
ExpressRoute の高度なトラブルシューティング
クラウドの端の部分が具体的にどこなのかわからないと、Azure コンポーネントの特定が難しくなります。 ExpressRoute を使用している場合は、Microsoft Enterprise Edge (MSEE) と呼ばれるネットワーク コンポーネントが端になります。 ExpressRoute を使用している場合、MSEE は Microsoft ネットワークに入るための最初のコンタクト ポイントであり、また Microsoft ネットワークから出るときの最後のホップです。 仮想ネットワーク ゲートウェイと ExpressRoute 回線の間に接続オブジェクトを作成すると、実際には MSEE への接続を作成することになります。 トラフィックの方向に応じて MSEE を最初または最後のホップとして認識することは、Azure ネットワークの問題を特定するために不可欠です。 どちらの方向かを認識することで、問題のある場所が Azure 内か、または WAN または企業ネットワークのさらに下流であるかが分かります。
Note
MSEE は Azure クラウド内にないことに注意してください。 ExpressRoute は実際には Microsoft ネットワークの端に位置し、Azure 内にはありません。 ExpressRoute を使用して MSEE に接続すると、Microsoft のネットワークに接続されます。そこから Microsoft 365 (Microsoft ピアリング経由) や Azure (プライベート ピアリングや Microsoft ピアリング経由) などのクラウド サービスのどれにでも移動できます。
2 つの VNet が同じ ExpressRoute 回線に接続されている場合は、一連のテストを実行して Azure 内の問題を特定できます。
テスト計画
VM1 と VM2 の間で Get-LinkPerformance テストを実行します。 このテストは、問題がローカルかそうでないかについての分析情報を提供します。 このテストで待機時間と帯域幅について許容できる結果が得られた場合、ローカルの仮想ネットワークの状態は良好であると見なすことができます。
ローカルの仮想ネットワーク トラフィックの状態は良好であると想定し、VM1 と VM3 の間で Get-LinkPerformance テストを実行します。 このテストでは、Microsoft ネットワークから MSEE を経由し Azure に戻るまでの接続が実行されます。 このテストで待機時間と帯域幅について許容できる結果が得られた場合、Azure ネットワークの状態は良好だと見なすことができます。
Azure が除外されたら、企業ネットワークで同様の一連のテストを実行できます。 このテストでも問題がない場合には、サービス プロバイダーや ISP と連携して WAN の接続を診断します。 例:2 つのブランチ オフィス間、またはデスクとデータ センター サーバーの間でこのテストを実行します。 テスト内容に応じて、そのパスを実行できるサーバーやクライアント PC などのエンドポイントを見つけます。
重要
テストごとにそのテストを実行した日時を記録し、結果を共通の場所に保存しておくことが重要です。 各テストの実行の出力形式を統一することで、テストの実行間の結果データを比較でき、データに "漏れ" がないようにする必要があります。 複数のテスト間で一貫性を維持できることが、トラブルシューティングに AzureCT を使用する主な理由です。 実行する負荷シナリオそのものにマジックがあるわけではありませんが、どのテストからも "一貫したテストおよびデータの出力" が得られるという事実こそが "マジック" なのです。 毎回日時が記録されて一貫したデータが得られることは、後になって問題が散発的であることが明らかになった場合に特に役立ちます。 前もってきちんとデータを収集しておくと、何時間もかけて同じシナリオをテストし直す手間を省けます。
問題特定後の手順
問題を特定する回数が増えるほど、より迅速にソリューションを見つけられるようになります。 トラブルシューティングでこれ以上先に進めない事態になることがあります。 たとえば、サービス プロバイダーのリンクでヨーロッパを経由するホップが使用されているが、パスはすべてアジア内にとどまると予期される場合です。 この時点で、他のユーザーに支援を要請する必要があります。 誰に依頼するかは、問題が特定されたルーティング ドメインによって決まります。 特定のコンポーネントまで絞り込めれば、さらに良いです。
企業ネットワークの問題の場合は、社内の IT 部門またはサービス プロバイダーが、デバイスの構成やハードウェアの修理を助けてくれます。
WAN のトラブルシューティングを行う場合は、サービス プロバイダーや ISP の作業に役立てることができるように、彼らとテスト結果を共有することをお勧めします。 テスト結果があることで、既に実行したのと同じタスクを再度実行することも回避できます。 ただし、彼らが自分で結果を確認したい場合もあります。 これは "信頼せよ、されど検証せよ" の原則に基づいています。
Azure では、可能な限り詳しく問題を特定したら、Azure ネットワークのドキュメントをご覧ください。その上でなおサポートが必要な場合はサポート チケットを開いてください。
References
待機時間と帯域幅の期待値
ヒント
待機時間の最大の要素は、テストするエンドポイント間の地理的要因による待機時間 (マイルまたはキロメートル) です。 機器的要因による待機時間 (物理および仮想コンポーネント、ホップ数など) も関係するものの、WAN 接続の処理では、地理的要因が待機時間全体における最大の要素であることが明らかになっています。 また、ここでいう距離とは、直線距離や道路地図上の距離ではなく、設置されるファイバーの距離であることに注意する必要があります。 この距離を正確に取得することは極めて困難です。 そのため、通常、筆者たちはインターネットで都市間の距離計算機を使用しています。この方法では測定精度が非常に低くなりますが、大まかな期待値を設定するには十分です。
たとえば、筆者たちは米国ワシントン州シアトルで ExpressRoute をセットアップしました。 次の表は、Azure のさまざまな場所に対するテストで確認された待機時間と帯域幅を示しています。 テストする各エンドポイント間の地理的距離は、筆者たちが推定したものです。
テストの設定
Windows Server 2016 を稼働している物理サーバーには、10 Gbps の NIC が 1 枚搭載され、ExpressRoute 回線に接続されています。
特定された場所の ExpressRoute 回線は 10Gbps の Premium で、プライベート ピアリングが有効になっています。
指定されたリージョンには、UltraPerformance ゲートウェイを備えた Azure 仮想ネットワークがあります。
仮想ネットワークでは、DS5v2 の VM で Windows Server 2016 が稼働しています。 この VM はドメインに参加しておらず、最適化もカスタマイズもされていない既定の Azure イメージから作成され、AzureCT がインストールされています。
すべてのテストでは AzureCT の Get-LinkPerformance コマンドが使用され、6 回のテスト実行のそれぞれで、5 分間のロード テストが行われます。 次に例を示します。
Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300各テストのデータ フローには、オンプレミスの物理サーバー (シアトルの iPerf クライアント) から Azure VM (一覧表示されている Azure リージョンの iPerf サーバー) までフローする負荷がありました。
"待機時間" 列のデータは、ロードなしテスト (iPerf を実行しない TCP の待機時間テスト) から得られたデータです。
"最大帯域幅" 列のデータは、ウィンドウ サイズが 1 MB の、16 の TCP フローのロード テストから得られたデータです。
待機時間と帯域幅の結果
重要
これらの数値は一般的な参照用です。 待機時間には多くの要因が影響を与えます。これらの値は時間が経過しても概ね一貫しているものの、Azure やサービス プロバイダーのネットワーク内の条件ではいつでも別のパスを使用してトラフィックを送信できるため、待機時間と帯域幅が影響を受ける可能性があります。 一般に、このような変更による影響では大きな違いは生じません。
| ExpressRoute 場所 |
Azure リージョン |
推定 距離 (km) |
Latency | 1 セッションの 帯域幅 |
最大値 帯域幅 |
|---|---|---|---|---|---|
| Seattle | 米国西部 2 | 191 km | 5 ミリ秒 | 262.0 メガビット/秒 | 3.74 ギガビット/秒 |
| Seattle | 米国西部 | 1,094 km | 18 ミリ秒 | 82.3 メガビット/秒 | 3.70 ギガビット/秒 |
| Seattle | 米国中部 | 2,357 km | 40 ミリ秒 | 38.8 メガビット/秒 | 2.55 ギガビット/秒 |
| Seattle | 米国中南部 | 2,877 km | 51 ミリ秒 | 30.6 メガビット/秒 | 2.49 ギガビット/秒 |
| Seattle | 米国中北部 | 2,792 km | 55 ミリ秒 | 27.7 メガビット/秒 | 2.19 ギガビット/秒 |
| Seattle | 米国東部 2 | 3,769 km | 73 ミリ秒 | 21.3 メガビット/秒 | 1.79 ギガビット/秒 |
| Seattle | 米国東部 | 3,699 km | 74 ミリ秒 | 21.1 メガビット/秒 | 1.78 ギガビット/秒 |
| Seattle | 東日本 | 7,705 km | 106 ミリ秒 | 14.6 メガビット/秒 | 1.22 ギガビット/秒 |
| Seattle | 英国南部 | 7,708 km | 146 ミリ秒 | 10.6 メガビット/秒 | 896 メガビット/秒 |
| Seattle | 西ヨーロッパ | 7,834 km | 153 ミリ秒 | 10.2 メガビット/秒 | 761 メガビット/秒 |
| Seattle | オーストラリア東部 | 12,484 km | 165 ミリ秒 | 9.4 メガビット/秒 | 794 メガビット/秒 |
| Seattle | 東南アジア | 12,989 km | 170 ミリ秒 | 9.2 メガビット/秒 | 756 メガビット/秒 |
| Seattle | ブラジル南部* | 10,930 km | 189 ミリ秒 | 8.2 メガビット/秒 | 699 メガビット/秒 |
| Seattle | インド南部 | 12,918 km | 202 ミリ秒 | 7.7 メガビット/秒 | 634 メガビット/秒 |
* ブラジルの待機時間は、直線距離と設置されたファイバーの距離が大きく異なることを表す好例です。 予想された待機時間は 160 ミリ秒前後ですが、実際には 189 ミリ秒でした。 この待機時間の違いは、どこかにネットワークの問題があることを示しているように見えます。 しかし、実際には、ファイバー線はまっすぐブラジルにつながっているわけではありません。 したがって、シアトルからブラジルに到達するには 1,000 km 前後が追加されると考える必要があります。
Note
これらの数値は考慮する必要がありますが、PowerShell 経由で Windows の IPERF に基づく AzureCT を使用してテストされました。 このシナリオでは、IPERF はスケーリング ファクターのデフォルトの Windows TCP オプションを無視して、TCP ウィンドウ サイズに対してはるかに低いシフト数を使用します。 ここで表される数値は、デフォルトの IPERF 値を使用して実行されたものであり、一般的な参照専用です。 -w スイッチと大きな TCP ウィンドウ サイズを使用して IPERF コマンドをチューニングすることで、遠距離でも良好なスループットを実現できるため、スループットの値が大幅に向上します。 また、ExpressRoute が完全な帯域幅を使用できるようにするために、複数のマシンからマルチスレッド オプションで IPERF を同時に実行し、コンピューティング容量が最大リンク パフォーマンスに到達できるようにして、単一の VM の処理能力によって制限されないようにすることが理想的です。 Windows で最適な Iperf の結果を取得するには、"Set-NetTCPSetting -AutoTuningLevelLocal Experimental" を使用します。 変更を加える前に、組織のポリシーをチェックしてください。
次のステップ
- Azure Connectivity Toolkit をダウンロードする
- リンクのパフォーマンス テストの手順に従います