アプリケーションの自動インストルメンテーションのための Amazon CloudWatch アプリケーションシグナル (プレビュー)

分散システムの課題の 1 つは、相互に依存する多数のサービスで構成されているため、パフォーマンスを監視しようとすると複雑さが増すことです。レイテンシーが高かったり、可用性が低下しているサービスや API を特定するには、テレメトリ信号を手動でまとめる必要があります。その結果、メトリクス、トレース、ログ、リアルユーザーモニタリング、シンセティックモニタリングのエクスペリエンスが一貫していないため、システムの問題の根本原因を突き止めるのに時間と労力がかかる可能性があります。

継続的に利用可能で高性能なアプリケーションを顧客に提供したいと考えています。同時に、これを保証するモニタリングは、効率的で費用対効果が高く、手間のかかる作業を必要としないものでなければなりません。

Amazon CloudWatch アプリケーションシグナルは、アプリケーションパフォーマンスのベストプラクティスに基づいてアプリケーションを自動的にインストゥルメントするのに役立ちます。手動による作業、カスタムコード、カスタムダッシュボードはありません。標準化されたダッシュボードがあらかじめ用意されており、リクエストの量、可用性、レイテンシーなど、アプリケーションのパフォーマンスに関する最も重要な指標が表示されます。さらに、アプリケーションにサービスレベル目標 (SLO) を定義して、ビジネスにとって最も重要な特定の運用を監視できます。SLO の例としては、Web ページが 28 日間隔で、99.9% の時間で 2000 ミリ秒以内にレンダリングする必要があるという目標を設定することが挙げられます。

Application Signals は、メトリック、トレース、ログ、リアルユーザーモニタリング、シンセティックモニタリングにわたってテレメトリを自動的に相関させることで、トラブルシューティングをスピードアップし、アプリケーションの中断を軽減します。Application Signals は、アプリケーションのコンテキストでパフォーマンスを分析するための統合エクスペリエンスを提供することで、最も重要なビジネス機能をサポートするアプリケーションに焦点を当てて生産性を向上させます。

私の個人的なお気に入りは、Application Signals によって可能になったチーム間のコラボレーションです。この記事の始めに、分散システムは相互に依存する多くのサービスで構成されていることを述べました。この記事の後半で説明するサービスマップでは、サービスオーナーが別のサービスによって引き起こされた問題を特定した場合、他のサービスの所有者にリンクを送信して、トリアージタスクを効率的に共同で進めることができます。

アプリケーションシグナル入門
新しい Amazon CloudWatch オブザーバビリティ EKS アドオンを有効にすることで、Amazon EKS コンソールで新しい Amazon EKS クラスターを作成するときに、アプリケーションとコンテナのテレメトリを簡単に収集できます。もう 1 つのオプションは、既存の Amazon EKS クラスターまたは他のコンピューティングタイプを Amazon CloudWatch コンソールで直接有効にすることです。

Amazon EKS アドオンまたは他のコンピューティングタイプのカスタムオプションを使用して Application Signals を有効にすると、Application Signals は自動的にサービスを検出し、API や依存関係のリクエスト量、レイテンシーの急上昇、可用性の低下など、標準的なアプリケーションメトリックスセットを生成します。

検出されたすべてのサービスとそのゴールデンメトリック（リクエストの量、レイテンシー、障害、エラー) が、サービスページとサービスマップに自動的に表示されます。サービスマップでは、サービスの状態、オペレーション、依存関係、オペレーションと依存関係の間のすべてのコールパスを視覚的に詳細に評価できます。

アプリケーションシグナルで有効になっているサービスのリストは、すべてのサービスと依存関係の運用指標とともにサービスダッシュボードにも表示され、異常を簡単に見つけることができます。EKS クラスターが AppRegistry でタグ付けされたアプリケーションに属している場合、アプリケーション列は自動的に入力されます。Hosted In 列は、サービスリクエストが実行されている EKS ポッド、クラスター、または名前空間の組み合わせを自動的に検出します。いくつか例を挙げると、いずれかを選択して Container Insights に直接移動し、CPU やメモリ使用率などの詳細なコンテナメトリクスを確認できます。

アプリケーションシグナルとのチームコラボレーション
さて、この記事の冒頭で述べたチームコラボレーションをさらに発展させたいと思います。サービスダッシュボードを調べて健全性チェックを行ったところ、pet-clinic-frontend という名前のサービスの 1 つで SLO の問題が 2 つあることに気付いたとします。会社には一連の SLO があり、このビューを使用してアプリケーションが目標に対してどのように機能しているかを把握できます。AppRegistry でタグ付けされたサービスについては、すべてのチームがアプリケーションの定義と所有権を一元的に把握できます。さらにサービスマップに移動すると、このサービスの状態に関する詳細が表示されます。

この時点で、pet-clinic-frontend サービスへのリンクを、AppRegistry で詳細を確認した Sarah に送信することを決定します。このサービスの担当者は Sarah です。このリンクは、問題の発見に基づいてコンテキスト化されたトリアージビューに直接アクセスするようにキュレーションされているため、Sarah とのコラボレーションを効率的に行うことができます。Sarah は、多くのリクエストで POST /api/customer/owner のレイテンシーが 2,000 ミリ秒に増加していることに気づき、サービスオーナーとして根本原因を突き止めるために深く掘り下げています。

レイテンシーグラフをクリックすると、オペレーション、メトリックス、および時点に直接対応するトレースの相関リストが表示されます。これにより、Sarah は、レイテンシーの増加につながった可能性のある正確なトレースを見つけることができます。

Sarah は Amazon CloudWatch Synthetics と Amazon CloudWatch RUM を使用しており、X-Ray アクティブトレーシング統合を有効にして、関連するカナリアとサービスに関連するページのリストを自動的に表示できるようにしています。この統合ビューにより、Sarah はアプリケーションのパフォーマンスについて複数の視点を得ることができ、1 つのビューで異常をすばやくトラブルシューティングできるようになりました。

今すぐご利用いただけます
Amazon CloudWatch Application Signals はプレビュー版として提供されており、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (シドニー)、アジアパシフィック (東京) の AWS リージョンで今すぐ使用を開始できます。

詳細については、Amazon CloudWatch ユーザーガイドをご覧ください。ご質問は AWS re:Post for Amazon CloudWatch、または通常の AWS サポート窓口までお送りください。

– Veliswa

原文はこちらです。