ネットワークの輻輳は、次の原因で発生する可能性があります。

  • ユーザが、ネットワーク利用のピーク時に「帯域幅を占有する」バックアップジョブを開始する。
  • TCP の設定ミスが原因で、サーバがランダムな間隔でパケットをドロップする。

SNMP などの従来のモニタリングツールは、永続的なネットワークのボトルネックを検出するのに適していますが、断続的なボトルネックを見逃してしまうことがよくあります。ネットワークの可視性を使用すると、アプリケーションのパフォーマンスに影響を与える断続的なネットワークのボトルネックを簡単に特定して診断できます。

アプリケーションの症状

ある開発運用エンジニアが、ミッションクリティカルなアプリケーションのモニタリングを担当します。ある日、開発運用エンジニアがアプリケーション ダッシュボードを開くと、Ecom-Tier1 の一部が突然赤色になっています。これは、この階層のノードの 1 つでパフォーマンスが低下していることを示します。また、開発運用エンジニアは、アプリケーション全体の応答時間がわずかに増えていることに気付きます。開発運用エンジニアは調査することを決定します。

Application symptoms

ネットワークの診断

  1. ネットワークの問題があるかどうかを判断するために、開発運用エンジニアは次のことを行います。
    1. [Transaction Snapshots] ページに移動し、リストをフィルタ処理して停止したコールのみを表示します。
    2. 特定のコールをダブルクリックして、トランザクション フロー マップを表示します。コールは停止したコールであるため、フローマップ全体は表示されません。
    3. [Drill Down] をクリックしてトランザクション ダッシュボードを開き、[Network] タブに切り替えて、このコール中のネットワークのパフォーマンスを分析します。 
      Drill Down 
  2. [Network Impact on Transactions] グラフ（左上）により、トランザクション スナップショットの時間帯にパフォーマンスに影響を与えるイベント（PIE）が急増していることが示されます。開発運用エンジニアは、PIE と停止のみを表示することで、同じ時間枠内に停止コールと PIE の急増が発生したことを確認できます。
    Network impact on transactions 
  3. 開発運用エンジニアは、[Network Pie - Contributors] グラフで、パフォーマンスに影響を与えるイベントがすべて再送信タイムアウト（RTO）であることを確認できます。これは、2 つの階層間のネットワークパスでパケットが損失していることを示します。これは、同じ時間枠内に発生する TCP 損失の急増によって確認できます。
    Network Pie - Contributors chart
    TCP loss
  4. 開発運用エンジニアは、停止したコールと再送信の間に相関関係があると判断し、このイベントについて詳しく把握したいと考えます。[Retransmissions Per Min] グラフにより、これらのすべてがデータの再送信であることがわかります。これは、2 つのノード間のネットワークパスに問題があることを示します。（SACK の再送信は、1 つまたは 2 つのノードで TCP 接続をセットアップする際に問題が発生していることを示します。）
    Retransmissions per minute 
  5. 開発運用エンジニアは、一連の相関、つまり、停止したコール > PIE > 再送信 > ネットワークパスでのデータの再送信を数秒で認識します。次の手順は、ネットワーク内でこれらの再送信が発生している場所を特定することです。開発運用エンジニアは、ネットワークダッシュボードに切り替え、PIE スコアが高いネットワークリンクを探します。開発運用エンジニアは、2 つのリンクの PIE スコアが 59 であることに気付きます。これは、他のリンクよりも大幅に高いスコアです。これらのリンクはどちらも、ECom-Tier1 と Ecom-Tier2 がロードバランサを介して Order-Tier と接続するために使用されます。
    Network Flow Map

  6. この情報をふまえ、開発運用エンジニアはこれらの階層の 1 つを調査することにします。Ecom-Tier1 を右クリックして [View Metrics] を選択します。この階層の動的ダッシュボードが表示されます。このダッシュボードには、個々のトランザクションについて開発運用エンジニアが確認した、階層全体の同じメトリック相関が表示されます。 
    Dynamic Dashboard 
    TCP loss
    Retransmissions per minute
  7. ここで、開発運用エンジニアは、データの再送信が階層全体で急増していることを確認し、これらのイベントが発生している TCP 接続を特定したいと考えます。開発運用エンジニアは、Ecom-Tier とロードバランサの間のネットワークリンクをクリックします。開発運用エンジニアは、PIE が次の両方の接続で発生していることを確認できます。
    ECOM_T1N1:8080 < – > Load_Balancer_10.0.11.77:8080
    ECOM_T1N2:8080 < – > Load_Balancer_10.0.11.77:8080
  8. この情報をふまえ、開発運用エンジニアは、組織内のネットワーク管理チームに連絡し、「次の TCP 接続で午前 9:07 から 9:10 に断続的な損失が発生しています。これらの損失は、停止したコールの急増に関連しています。」と伝えます。これで、ネットワークチームは、これらの接続で使用されているネットワークパスを調査して、問題がロードバランサで発生しているか、またはその他の場所で発生しているか確認できます。