Application Real-Time Monitoring Service:リアルタイムのトレース分析

問題 1：トラフィックの不均衡な分散

負荷分散の構成ミスにより大量のリクエストが少数のマシンにルーティングされ、サービスの可用性に影響を与える「ホットスポット」が作成された場合、どのように対処しますか？

トラフィックの不均衡な分散によって引き起こされる「ホットスポット」は、容易にサービスの可用性低下につながる可能性があります。このようなケースの多くは、負荷分散の構成ミス、再起動したノードがオンラインになるのを妨げるサービスレジストリの異常、または異常な DHT ハッシュ係数などの要因により、本番環境で発生します。

トラフィックの不均衡における最大のリスクは、「ホットスポット」を時間内に検出できないことです。その症状は、多くの場合、応答の遅延やエラーとして現れ、従来のモニタリングではトラフィックの不均衡を直接示さない場合があります。その結果、運用担当者はそれを主要な原因とは考えず、貴重なインシデント対応時間を無駄にし、問題を悪化させてしまいます。

Trace Explorer を使用すると、IP アドレスでトレースデータをグループ化して、リクエストがマシン間でどのように分散しているか、特にインシデント発生前後のトラフィック分散の変化を可視化できます。もし多数のリクエストが突然 1 台または少数のマシンに集中した場合、それはトラフィックの不均衡によるホットスポットである可能性が高いです。その後、これをインシデント発生時の変更イベントと関連付けることで、問題のある変更を迅速に特定し、ロールバックを実行できます。

問題 2：インスタンス障害

ネットワークカードの損傷、CPU の過剰コミットメント、ディスクのフル状態などのインスタンス障害により、一部のリクエストが失敗またはタイムアウトした場合、どのように調査しますか？

インスタンス障害は頻繁に発生し、特に大規模なコアクラスターでは統計的にほぼ避けられません。インスタンス障害は大規模なサービス停止を引き起こすとは限りませんが、少数のユーザーリクエストが失敗したりタイムアウトしたりする原因となることがあります。これは継続的にユーザーエクスペリエンスを低下させ、サポートコストを増加させるため、迅速に対処する必要があります。

インスタンス障害は、ホスト障害とコンテナ障害 (Kubernetes 環境ではノード障害と Pod 障害) に分類できます。例えば、CPU の過剰コミットメントやハードウェア障害はホストレベルの問題であり、ホスト上のすべてのコンテナに影響します。対照的に、ディスクのフル状態やメモリ不足エラーなどの問題は、通常、単一のコンテナにのみ影響します。したがって、インスタンス障害のトラブルシューティングを行う際には、ホスト IP とコンテナ IP の両方のディメンションからデータを分析できます。

この問題に対処するには、Trace Explorer を使用して、まず異常またはタイムアウトしたリクエストをフィルターします。次に、結果をホスト IP またはコンテナ IP アドレスで集約して、インスタンス障害が原因であるかどうかを迅速に判断します。異常なリクエストが単一のマシンに集中している場合は、マシンを交換して迅速な回復を試みるか、ディスクがフル状態であるか、CPU スティールタイムが高すぎないかなどのシステムメトリックを検査できます。エラーが複数のマシンに分散している場合は、インスタンス障害を除外できる可能性が高く、ダウンストリームの依存関係やアプリケーションロジックの問題分析に集中すべきです。

問題 3：低速なエンドポイントの管理

新しいアプリケーションのローンチや大規模な販売促進の前に、どのようにして低速なエンドポイントを迅速に特定し、パフォーマンスボトルネックを解決しますか？

新しいアプリケーションをローンチしたり、大規模なプロモーションに備えたりする際には、体系的なパフォーマンスチューニングが必要になることがよくあります。最初のステップは、低速なエンドポイントのリストとそれらの発生頻度を特定することによって、現在のシステムのパフォーマンスボトルネックを分析することです。

Trace Explorer を使用して、持続時間が特定のしきい値を超える呼び出しをフィルターし、それらをエンドポイント名でグループ化できます。これにより、低速なエンドポイントのリストとそのパターンを迅速に特定できます。その後、最も頻繁に発生する低速なエンドポイントに 1 つずつ対処できます。

問題 4：ビジネストラフィック分析

主要な顧客やチャネルのトラフィック変更とサービス品質をどのように分析しますか？

本番環境では、サービスはしばしば標準化されていますが、ビジネスセグメントは階層化され、分類されています。同じ注文サービスでも、カテゴリ、チャネル、ユーザーなどのディメンションで統計を分類・集約し、詳細な運用を行う必要があります。例えば、オフラインの小売チャネルでは、すべての注文とすべての POS 端末の安定性が広報問題になる可能性があります。オフラインチャネルの SLA 要件は、オンラインチャネルよりもはるかに高くなります。では、一般的な e コマースサービスシステム内で、オフライン小売トレースのトラフィック状況とサービス品質をどのように正確にモニタリングできるでしょうか？

Trace Explorer のカスタム属性に対するフィルタリングと統計機能を使用すると、低コストでビジネス指向のトレース分析を実行できます。例えば、エントリポイントサービスでオフライン注文のトレースに {"attributes.channel": "offline"} のようなタグを追加し、その後、異なる店舗、顧客グループ、製品カテゴリに個別のタグを追加できます。最後に、attributes.channel = offline でフィルターし、group by を使用して異なるビジネスタグでリクエスト数、持続時間、エラー率などのメトリックを集約することで、各ビジネスシナリオのトラフィックトレンドとサービス品質を迅速に分析できます。

問題 5：カナリアリリースのモニタリング

10 バッチで 500 台のマシンにデプロイしています。最初のカナリアリリースバッチが稼働した後、問題があるかどうかをどのように迅速に判断しますか？

変更管理の 3 つの柱である「カナリア、モニター、ロールバック」は、オンラインの安定性にとって不可欠です。段階的なカナリアリリースは、オンラインリスクを低減し、影響範囲を制御するための重要な手法です。カナリアバッチで異常が検出された場合は、デプロイを続行するのではなく、直ちにロールバックする必要があります。しかし、多くの本番障害は、効果的なカナリアリリースのモニタリングが欠如しているために発生します。

例えば、マイクロサービスのサービスレジストリが利用できない場合、再起動されたマシンは登録できず、オンラインになりません。カナリアリリースのモニタリングがなければ、再起動された最初の数バッチのマシンはすべて登録に失敗する可能性があります。すべてのトラフィックは残りのアクティブなマシンにルーティングされます。最後のバッチのマシンも登録に失敗するまで、アプリケーション全体のトラフィックと持続時間は大幅に変わらないかもしれません。その時点でアプリケーション全体が利用できなくなり、大規模な本番インシデントにつながります。

上記のシナリオで、異なるマシンバージョンのトラフィックに {"attributes.version": "v1.0.x"} のようなタグを付けると、Trace Explorer を使用して attributes.version で統計をグループ化できます。これにより、異なるバージョン間、またはリリース前後でのトラフィックの変更とサービス品質を明確に区別でき、カナリアバッチの異常がグローバルな監視メトリックによってマスクされるのを防ぐことができます。

Trace Explorer の制限事項

関連ドキュメント

問題をプロアクティブに診断するために、Application Real-Time Monitoring Service (ARMS) のアラート機能を使用して、特定のエンドポイントまたはすべてのエンドポイントに対してアラートを作成できます。問題が発生すると、サービスは運用チームに通知を送信します。アラートの作成方法については、「アプリケーションモニタリングのアラートルール」をご参照ください。