ネットワーク パフォーマンスのトラブルシューティング

概要

Azure では、オンプレミスのネットワークから Azure に接続するための高速で安定した方法を提供します。 大小を問わずすべての企業のお客様が、サイト間 VPN や ExpressRoute などの方法を上手に利用して Azure でビジネスを運営しています。 一方で、パフォーマンスが期待通りではなかったり、これまでのエクスペリエンスを下回った場合にはどうなるでしょうか。 この記事は、特定の環境をテストしてベースラインを作成する方法を標準化するのに役立ちます。

一貫性を保ちつつ簡単に、2 つのホスト間のネットワーク待機時間と帯域幅をテストする方法を説明します。 また、問題点を特定するのに役立つ Azure ネットワークの検査方法に関するアドバイスも提供します。 ここで取り上げる PowerShell スクリプトとツールでは、ネットワーク上 (テストするリンクの両端) に 2 つのホストが必要です。 一方のホストは Windows Server または Windows デスクトップの必要があります。もう一方のホストには Windows または Linux のいずれかを使用できます。

Note

ここで使用するトラブルシューティングのアプローチ、ツール、および方法は、個人的な好みです。 このドキュメントでは、筆者が通常使用しているアプローチとツールについて説明します。 お読みいただいている方の中には別のアプローチをとる方もいらっしゃるでしょうが、問題解決のアプローチが違っていても問題はありません。 ただし、確立されたアプローチをお持ちでない場合は、このドキュメントを読んでネットワークの問題をトラブルシューティングする独自の方法、ツール、および好みを確立させていくことができます。

ネットワーク コンポーネント

トラブルシューティングの詳細を説明する前に、一般的な用語とコンポーネントについて見ていきましょう。 これにより、Azure の接続性を実現するエンドツーエンド チェーン内の各コンポーネントについて考えていくことができます。 1

最上位のレベルでは、次のネットワークの 3 つの主要なルーティング ドメインについて説明します。

  • Azure ネットワーク (右の青色の雲)
  • インターネットまたは WAN (中央の緑色の雲)
  • 企業ネットワーク (左のピンク色の雲)

図を右から左へ見ていきながら、各コンポーネントについて簡単に説明します。

  • 仮想マシン - サーバーには複数の NIC がある場合があります。 すべての静的ルート、既定ルート、およびオペレーティング システムの設定で、想定どおりにトラフィックの送受信が行われていることを確認します。 また、各 VM の SKU には、帯域幅制限があります。 SKU のサイズが小さい VM を使用している場合、NIC で使用可能な帯域幅によってトラフィックが制限されます。 筆者の場合、テストには通常 DS5v2 を使用して VM に必要な帯域幅を確保し、テストが完了したら削除してコストを節約しています。
  • 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 トンネルに接続されている VNet ゲートウェイがある場合は、接続の重み設定に注意する必要があります。 接続の重みは接続の優先順位に影響し、トラフィックのパスを決定します。
  • ルート フィルター (表示されません) - 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 つです。 1) PowerShell モジュールのインストール、2) iPerf と PSPing の関連アプリケーションのインストール、3) パフォーマンス テストの実行です。

  1. PowerShell モジュールのインストール

     (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
    
    

    このコマンドは、PowerShell モジュールをダウンロードしてローカルにインストールします。

  2. 関連アプリケーションのインストール

     Install-LinkPerformance
    

    AzureCT のこのコマンドにより、iPerf と PSPing が新しいディレクトリ "C:\ACTTools" にインストールされます。また、Windows ファイアウォールのポートが開き、ICMP とポート 5201 (iPerf) のトラフィックが許可されます。

  3. パフォーマンス テストの実行

    まず、リモート ホストに 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
    

    このコマンドにより、負荷と待機時間に関する一連のテストが同時に実行されます。これらのテストは、ネットワーク リンクの帯域幅容量と待機時間の評価に役立ちます。

  4. テストの出力の確認

    PowerShell の出力形式は次のようになります。

    4

    iPerf と PSPing のすべてのテストの詳細な結果は、AzureCT ツールのディレクトリ (C:\ACTTools) 内の、個々のテキスト ファイルで確認できます。

トラブルシューティング

パフォーマンス テストで期待した結果が得られない場合、その理由を明らかにするには手順を踏んだ段階的なプロセスが必要です。 パス内のコンポーネントの数を考慮すると、あれこれ試してみるよりも、体系的なアプローチを取った方が解決への早道となります。 体系的にトラブルシューティングを行うことで、不要なテストを複数回実行せずに済みます。

Note

ここで紹介するシナリオはパフォーマンスの問題であり、接続の問題ではありません。 トラフィックがまったく流れない場合は手順が異なります。

まず、想定を見直します。 期待は妥当でしょうか。 たとえば、1 Gbps の ExpressRoute 回線と 100 ミリ秒の待機時間があるとします。 待機時間の長いリンクでの TCP のパフォーマンス特性を考慮すると、1 Gbps の完全なトラフィックを期待することは妥当ではありません。 パフォーマンスの想定については、「参照」をご覧ください。

次に、ルーティング ドメイン間の端の部分から始めて、1 つの主要なルーティング ドメインに問題を絞り込むことをお勧めします。 企業ネットワーク、WAN、または Azure ネットワークから開始できます。 パス内の "ブラック ボックス" が非難されることがよくあります。 ブラック ボックスを非難することは簡単ですが、それによって解決が大幅に遅れる可能性があります。 問題が、問題を修正するために自分で変更を行える領域にある場合は、特にそうです。 サービス プロバイダーや ISP に任せる前に、しかるべき努力を払うようにしましょう。

問題が含まれるとみられる主要なルーティング ドメインを特定したら、問題の領域を表す図を作成する必要があります。 ホワイトボード、メモ帳、または Visio で図を描画することで、問題を系統的に処理して特定できます。 テスト ポイントを計画し、テストが進むにつれて、問題がないことが明らかになった領域や詳細なテスト結果をもとに作戦図を更新できます。

図を作成したら、まずネットワークをセグメントに分けて、問題を絞り込みます。 機能している箇所と機能していない箇所を調べます。 テスト ポイントを移動させて、問題となっているコンポーネントを特定します。

また、OSI モデルの他の層も忘れずに確認します。 ネットワークと 1 - 3 層 (物理、データ、およびネットワーク層) に的を絞りがちですが、アプリケーション レイヤーの 7 層にも問題が見つかる場合があります。 先入観を抱かずに、想定を確認します。

ExpressRoute の高度なトラブルシューティング

クラウドの端の部分が具体的にどこなのかわからないと、Azure コンポーネントの特定が難しくなります。 ExpressRoute を使用している場合は、Microsoft Enterprise Edge (MSEE) と呼ばれるネットワーク コンポーネントが端になります。 ExpressRoute を使用している場合、MSEE は Microsoft ネットワークに入るための最初のコンタクト ポイントであり、また Microsoft ネットワークから出るときの最後のホップです。 VNet ゲートウェイと ExpressRoute 回線の間に接続オブジェクトを作成すると、実際には MSEE への接続を作成することになります。 トラフィックの方向に応じて MSEE を最初または最後のホップとして認識することは、Azure ネットワークの問題を特定するために不可欠です。 どちらの方向かを認識することで、問題のある場所が Azure 内か、または WAN のさらに下流か、または企業ネットワーク内かが分かります。

2

Note

MSEE は Azure クラウド内にないことに注意してください。 ExpressRoute は実際には Microsoft ネットワークの端に位置し、Azure 内にはありません。 ExpressRoute を使用して MSEE に接続すると、Microsoft のネットワークに接続されます。そこから Microsoft 365 (Microsoft ピアリング経由) や Azure (プライベート ピアリングや Microsoft ピアリング経由) などのクラウド サービスのどれにでも移動できます。

2 つの VNet が同じ ExpressRoute 回線に接続されている場合は、一連のテストを実行して Azure 内の問題を特定できます。

テスト計画

  1. VM1 と VM2 の間で Get-LinkPerformance テストを実行します。 このテストは、問題がローカルかそうでないかについての分析情報を提供します。 このテストで待機時間と帯域幅について許容できる結果が得られた場合、ローカルの VNet ネットワークの状態は良好だと見なすことができます。
  2. ローカルの VNet トラフィックの状態は良好だと想定し、VM1 と VM3 の間で Get-LinkPerformance テストを実行します。 このテストでは、Microsoft ネットワークから MSEE を経由し Azure に戻るまでの接続が実行されます。 このテストで待機時間と帯域幅について許容できる結果が得られた場合、Azure ネットワークの状態は良好だと見なすことができます。
  3. Azure が除外されたら、企業ネットワークで同様の一連のテストを実行できます。 このテストでも問題がない場合には、サービス プロバイダーや ISP と連携して WAN の接続を診断します。 例:2 つのブランチ オフィス間、またはデスクとデータ センター サーバーの間でこのテストを実行します。 テスト内容に応じて、そのパスを実行できるサーバーやクライアント PC などのエンドポイントを見つけます。

重要

テストごとにそのテストを実行した日時を記録し、結果を共通の場所 (OneNote や Excel がお勧めです) に保存しておくことが重要です。 各テストの実行の出力形式を統一することで、テストの実行間の結果データを比較でき、データに "漏れ" がないようにする必要があります。 複数のテスト間で一貫性を維持できることが、トラブルシューティングに AzureCT を使用する主な理由です。 実行する負荷シナリオそのものにマジックがあるわけではありませんが、どのテストからも一貫したテストおよびデータの出力が得られるという事実こそがマジックなのです。 毎回日時が記録されて一貫したデータが得られることは、後になって問題が散発的であることが明らかになった場合に特に役立ちます。 前もってきちんとデータを収集しておくと、何時間もかけて同じシナリオをテストし直す手間を省けます (筆者は何年も前にこの苦労を味わいました)。

問題特定後の手順

問題を特定する回数が増えるほど、より迅速にソリューションを見つけられるようになります。 トラブルシューティングでこれ以上先に進めない事態になることがあります。 たとえば、サービス プロバイダーのリンクでヨーロッパを経由するホップが使用されているが、パスはすべてアジア内にとどまると予期される場合です。 この時点で、他のユーザーに支援を要請する必要があります。 誰に依頼するかは、問題が特定されたルーティング ドメインによって決まります。 特定のコンポーネントまで絞り込めれば、さらに良いです。

企業ネットワークの問題の場合は、社内の IT 部門またはサービス プロバイダーが、デバイスの構成やハードウェアの修理を助けてくれます。

WAN の場合は、テスト結果をサービス プロバイダーまたは ISP と共有すると、彼らが作業を開始するのに役立ちます。 これにより、既に実行したものと同じ作業が繰り返されるのを回避できます。 彼らが自分たちで結果を確認しようとしても気を悪くしないでください。 他の人の報告結果をもとにトラブルシューティングを行う場合、"信頼しても確認する" ことが優れた方法です。

Azure では、可能な限り詳しく問題を特定したら、Azure ネットワークのドキュメントをご覧ください。その上でなおサポートが必要な場合はサポート チケットを開いてください。

References

待機時間と帯域幅の期待値

ヒント

待機時間の最大の要素は、テストするエンドポイント間の地理的要因による待機時間 (マイルまたはキロメートル) です。 機器的要因による待機時間 (物理および仮想コンポーネント、ホップ数など) も関係するものの、WAN 接続の処理では、地理的要因が待機時間全体における最大の要素であることが明らかになっています。 また、ここでいう距離とは、直線距離や道路地図上の距離ではなく、設置されるファイバーの距離であることに注意する必要があります。 この距離を正確に取得することは極めて困難です。 そのため、筆者は通常インターネットで都市間の距離計算機を使用しています。この方法では測定精度が非常に低くなりますが、大まかな期待値を設定するには十分です。

筆者は米国ワシントン州シアトルで ExpressRoute をセットアップしました。 次の表は、Azure のさまざまな場所に対するテストで確認された待機時間と帯域幅を示しています。 テストする各エンドポイント間の地理的距離は、筆者が推定したものです。

テストの設定

  • Windows Server 2016 を稼働している物理サーバーには、10 Gbps の NIC が 1 枚搭載され、ExpressRoute 回線に接続されています。

  • 特定された場所の ExpressRoute 回線は 10Gbps の Premium で、プライベート ピアリングが有効になっています。

  • 指定されたリージョンには、UltraPerformance ゲートウェイを備えた Azure VNet があります。

  • VNet では、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 フローのロード テストから得られたデータです。

3

待機時間と帯域幅の結果

重要

これらの数値は一般的な参照用です。 待機時間には多くの要因が影響を与えます。これらの値は時間が経過しても概ね一貫しているものの、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 前後が追加されると考える必要があります。

次のステップ

  1. Azure Connectivity Toolkit を GitHub (https://aka.ms/AzCT) からダウンロードします
  2. リンクのパフォーマンス テストの手順に従います