バックプレッシャは、特に分散環境のマイクロサービスおよびサービス指向のアプリケーションでよく発生します。2 つのサービスが通信し、1 つのサービスが過負荷になると、バックプレッシャが発生します。次の図は、イベントのシーケンスを示しています。

TCP window bottlenecks

  1. 受信側には、着信パケット用の TCP 受信バッファがあります。使用可能なバッファ領域を送信側にアドバタイズします。
  2. 送信側は、アドバタイズされたウィンドウサイズに基づいてデータのチャンクを送信します。
  3. 受信側のアプリケーションはバッファ内のパケットを処理し、バッファ内の領域を解放します。 
  4. 受信側は新しいウィンドウサイズをアドバタイズします。 

受信側ノードが着信パケットを迅速に処理できなくなるまで、このプロセスはスムーズに機能します。この場合、受信側は TCP 制限メッセージまたは TCP ゼロメッセージを送信側に送信します。これにより転送速度が低下します。

アプリケーションの症状

ある開発運用エンジニアが、ミッションクリティカルなアプリケーションのモニタリングを担当します。開発運用エンジニアは、アプリケーション ダッシュボードを詳しく調べて、リンクと階層が黄色に変化していること、および別のリンクが赤色に変化していることに気付きます。開発運用エンジニアは調査することを決定します。

Application Flow Map

ネットワークの診断

  1. 開発運用エンジニアはネットワークダッシュボードに切り替え、Order-Tier と Payment-Tier の間でパフォーマンスに影響を与えるイベント（PIE）が大幅に増加していることに気付きます。アプリケーション ダッシュボードで、アップストリームの Order-Tier にパフォーマンスの問題があることが示され、一方ネットワークダッシュボードで、問題がさらに Order-Tier と Payment-Tier の間のダウンストリームにあることが示されます。
     Network Dashboard
  2. 開発運用エンジニアは、詳細なトラブルシューティングを行うために、[Transaction Snapshots] リストに移動し、停止したトランザクションをフィルタ処理で抽出し、そのトランザクションをダブルクリックしてドリルダウンします。
    Transaction Snapshots list 
  3. Order-Tier でほとんどすべてのトランザクション時間（99.7%）が発生しているため、開発運用エンジニアはこの階層にドリルダウンします。  
    Drill down 
  4. 開発運用エンジニアは、[Transaction Drilldown] ページで [Network] ビューに切り替えます。開発運用エンジニアは、ダッシュボードを詳しく調べて、次のことにただちに気付きます。
    1. トランザクションが、停止コールの急増とパフォーマンスに影響を与えるイベントに関連している。 
    2. これらのイベント（Client Limited と Client Zero Window）がすべてクライアント（Order-Tier）ノードで発生している。
      Network view 
  5. 開発運用エンジニアは、ネットワークダッシュボードに戻り、Order-Tier を右クリックし、[View Metrics] を選択します。開発運用エンジニアは、Client Limited イベントと Client Zero Window イベントが階層全体で急増していること、およびそれらが停止コールの急増に関連していることにただちに気付きます。
    Network Dashboard