re:Invent 2024: AWSのApplication Signalsで実現する包括的モニタリング
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Unlock the power of application monitoring (COP359)
この動画では、アプリケーションモニタリングの重要性とAWSのObservability機能について解説しています。現代のMicroservicesアプリケーションの複雑さに対応するため、AWSが提供するApplication Signalsを中心に、CloudWatch、OpenTelemetry、X-Rayなどを統合的に活用する方法を紹介しています。特に、2023年にリリースされたUnified CloudWatch Agentにより、Metrics、Logs、Tracesを1つのAgentで管理できるようになった点や、REDメトリクス（Recorders、Errors and Faults、Duration）に基づくモニタリング手法、SLO（Service Level Objectives）の具体的な設定方法などが詳しく説明されています。また、Container InsightsやReal User Monitoringなど、インフラストラクチャからユーザー体験まで、包括的なモニタリングを実現する方法についても実際のデモを交えながら解説しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
アプリケーションモニタリングの重要性と課題
みなさん、こんばんは。re:Inventへようこそ。本日は、アプリケーションモニタリングの可能性について解説していきます。私はObservabilityを専門とするSenior Specialist Architectのsiva Guruvareddiarです。
まず、ある逸話からお話を始めたいと思います。「すべてのものは、常に故障する」これは、Amazon CTOのDr. Werner Vogels氏の有名な言葉です。なぜすべてのものが常に故障するのか、と疑問に思われるかもしれません。それは、現代のアプリケーションが本質的に複雑だからです。私たちは皆、Microservicesを開発しています。ここで伺いたいのですが、まだMonolithを使っていて、Microservicesを使っていない方は手を挙げてください - いませんよね？Microservicesを開発する際、私たちは多くのプログラミング言語、フレームワーク、そしてSQLやNoSQLを含む様々なタイプのデータベースを使用します。さらに、Kafkaやその他のサードパーティベンダー、サードパーティAPIなど、多くのコンポーネントも使用します。
このような複雑なアプリケーション環境では、ある難しい状況に直面します。一方では、開発者やプロダクトチームが、より多くの製品をより速くリリースし、顧客にすばやく届けたいと考えています。同時に、本番環境で何か問題が発生した場合、できるだけ早く検知して対処したいと考えています。さらに理想を言えば、顧客が問題を経験する前に、エラーを特定して修正できれば最高ですよね。
ここで重要になってくるのが、アプリケーションのObservabilityつまりApplication Monitoringです。私はいつも「なぜ？」という質問を大切にしているので、なぜApplication Observabilityが必要なのか、それによって何が得られるのかについてお話ししましょう。まず、アプリケーションの観測を始めると、アプリケーションの健全性を理解できるようになります。エンドカスタマーにとって、パフォーマンスと可用性が向上します。これは間接的に運用コストの削減にもつながります。なぜなら、アプリケーションをブラックボックスとして扱うのではなく、すべての接続関係を把握できるからです。そして最後に、エンドユーザー体験の向上につながります。エンドユーザーが問題に遭遇する前に、問題を特定して修正できるからです。これにより、顧客満足度が高まります。幸せな顧客を望まない人はいませんよね。
AWSのApplication Signalsによる包括的なObservabilityソリューション
AWSでは、オープンソースソリューションとAWSネイティブな方法の両方を含む、幅広い製品を提供しています。AWSネイティブな方法でのObservabilityの実装について、下から順に説明させていただきます。今年、私たちはUnified CloudWatch Agentをリリースしました。以前は、Metrics、Logs、Tracesのために別々のAgentが必要でした - Agentだらけの状態でした。しかし、今年リリースしたUnified CloudWatch Agentでは、1つのAgentですべての作業を処理できます。1つのAgentだけで、Metrics、Logs、TracesをCloudWatchに送信できます。CloudWatchを使用してカスタムダッシュボードを作成したり、Metric Explorerを使用したり、1つのアカウントをモニタリングアカウントとして指定してクロスアカウントObservabilityを実現したりできます。さらに、環境で多くのContainerやLambda関数を実行している場合、Container Insights、Lambda Insights、Logs Insightsなど、様々なInsightsが利用可能です。これらはそれぞれ特定の目的を果たします。そしてこれらすべての上に、Application Signalsがあります。Application Signalsとは何かと思われるかもしれませんが、これはAWSが提唱するAPM（Application Performance Monitoring）の方法なのです。
このApplication Performance Monitoringは、Synthetic CanaryやReal User Monitoringなどの既存機能と統合されており、問題の診断のために複数の場所やタブを行き来する必要がありません。さらに、メトリクスやログをサードパーティやオンプレミスのシステムに送信できるMetric Streamsも備えています。これらの機能はすべてOpenTelemetryを通じたオープンスタンダードに基づいています。
APMにおける主要なアプリケーションメトリクスについてお話ししましょう。これらはAPMのGolden Signals（ゴールデンシグナル）として知られるREDメトリクスです。Rは「Recorders」（リクエスト量）、Eは「Errors and Faults」（エラーと障害）、Dは「Duration」（所要時間）または「レイテンシー」を表します。私たちのアプリケーションシグナルはすべてこれらのREDメトリクスを中心に構成されており、1か所からアクセスできます。
内部の仕組みを見てみましょう。まず左側から、OpenTelemetryを使用したアプリケーションシグナルがあります。ベンダーロックインを心配する必要はありません。これはKubernetesやGrafanaなどのプロジェクトを監督しているのと同じCloud Native Computing Foundation（CNCF）によるオープンスタンダードに基づいているからです。現在、Java、Python、.NET、Node.jsの4つのプログラミング言語をサポートしています。これらの言語では、OpenTelemetryの自動計装が自動的に処理してくれるため、アプリケーションの計装のためのコードを書く必要はありません。
コンピューティングの観点からは、Amazon EKSやオンプレミス環境など、さまざまな環境をサポートしています。例えば、Amazon EKS上でJavaアプリケーションを実行している場合、統合CloudWatch Agentを使用してアドオンを有効にするだけです。この単一のエージェントが、メトリクス、ログ、トレースをそれぞれの送信先に届けるための手段となります。メトリクスとログはCloudWatchへ、トレースはAWS X-Rayへ送られます。
テレメトリーシグナルの収集に関しては、すべてがOpenTelemetryスタンダードに基づいており、AWS X-Rayとの下位互換性も維持されています。すでにX-Rayを使用している場合、トレースを自動的にSpanに変換します。統合CloudWatch Agentとの下位互換性も確保されているため、コードを変更することなく、より少ないエージェントで運用できます。
マイクロサービスの文脈では、サービス間の接続を手動で指定する必要はありません。 デフォルトで、送信されるシグナルを使用して、これらのシグナルがどのように相関しているかを識別し、Service Mapを動的に作成できます。Services Viewでは、これらのコンポーネントが内部でどのように動作しているかを確認できます。
本番環境でのメトリクスとトレースを使用したトラブルシューティングについては、とてもシンプルです。後ほどデモをお見せしますが、UIにアクセスし、グラフで異常が見られる箇所をクリックし、トレースとSpanを使用してトランザクションに移動するだけです。これにより、どの行番号で障害が発生しているかを正確に特定できます。また、Service Level Objectives（SLO）の管理も可能です。
Service Level Objectives（SLO）は、サービス管理における基本的な概念です。サービスから送信されるメトリクスは、Service Level Indicators（SLI）と呼ばれます。これらのSLIがSLOを導き出し、そしてSLOからService Level Agreements（SLA）が作成されます。これらのコンポーネントは、異なる役割の人々によって使用されます - SLIは開発チームとエンジニアリングチームが扱い、SLOはサービスの可用性に関して製品マネージャーが議論し、SLAは営業チームが顧客との約束（違反時の金銭的なペナルティを含むことが多い）を伝えるために使用します。
SLO計算の具体例を見てみましょう。1ヶ月の可用性目標が99%のサービスを考えてみます。1ヶ月は約43,800分です。99%の可用性の場合、残りの1%は438分、つまり約7時間18分となります。これがError Budgetと呼ばれるものです。サービスが7時間18分1秒ダウンした場合、SLOに違反したことになります。SREチームが適切な対応を取れるよう、PagerアラームやCloudWatchアラームを設定できます。
従来、人々はスプレッドシートや複雑なアルゴリズムを使用してSLOを決定していましたが、Application Signalsを使用すれば、数回のクリックでSLIとSLOを設定できます。さらに、Syntheticsとクライアントインテグレーションが1つの集中管理された場所にあります。Webサイトの場合、Canaryを実行して常に運用可能な状態を確認でき、Canaryテストが失敗した場合は開発者に通知して問題に対処できます。Real User Monitoringについては、静的ファイルに埋め込むことができるJavaScriptコードスニペットを提供しています。これにより、お客様のブラウザから直接CloudWatchにメトリクスを送信でき、パフォーマンスの問題やJavaScriptエラー、地理的な分布など、ユーザーエクスペリエンスを監視することができます。
アプリケーション層だけでなく、インフラストラクチャ層にも焦点を当てています。このギャップを埋めるため、 Application SignalsはContainer Insightsと緊密に連携しています。Amazon EKS、Amazon ECS、その他のコンテナ環境を使用している場合、Application SignalsとContainer Insightsの間をシームレスに行き来できます。 特にAmazon EKSの場合、アドオンを有効にするだけで簡単に設定できます。CloudWatchアドオンを有効にするだけで準備完了です。
Application Signalsのデモンストレーションと実践的な活用方法
実際の機能をデモンストレーションしましょう。 CloudWatchに最初にアクセスすると、Application Signalsの下にさまざまなオプションが表示されます。 初めてご利用の方は、Application Signalsを有効にして、プラットフォームを選択できます。Amazon EKS、Amazon ECS、AWS Lambda、 さらにはオンプレミスシステムなどから選べます。現在、実装方法は2つあります：今行っているようなコンソールを通じた方法と、マニフェストファイルを使用してCI/CDパイプラインを通じた方法です。Amazon EKS環境の場合、この2行をCI/CDパイプラインにコピー＆ペーストするだけで、 サービスのApplication Signalsを有効にできます。メトリクスがCloudWatchに流れ始めると、すぐに使えるダッシュボードが表示されます。これが標準ダッシュボードの表示例です。
このダッシュボードでは、SLIのステータスとその動作が確認できます。先ほど説明したように、すべてがメトリクス、エラー、所要時間に基づいています。障害率の高いサービスのランキングや、障害率の高い依存関係パスのランキングが表示されます。なぜ依存関係かと疑問に思われるかもしれませんが、これはマイクロサービスの世界だからです。アプリケーションの障害は、必ずしもそのアプリケーション自体の問題だけではありません。依存関係のいずれかに問題があり、それが連鎖的に影響を及ぼしている可能性もあります。そのため、これらを表示しているのです。また、サービスがAmazon EKSやAmazon EC2などのどこで実行されているかや、主要な操作の依存関係も確認できます。
これらのさまざまなグラフで動作状況を確認できます。CloudWatchのアラーム機能がお好みの方は、ベルアイコンをクリックするだけでアラーム作成ページに移動できます。次はサービスマップです。このマップは動的に生成されます。特別なシグナルを送る必要はありません。一見するとX-Rayのトレースマップのように見えるかもしれませんが、これは強化版のトレースマップです。ノードをクリックすると、レイテンシーなど多くの情報が表示されます。エッジをクリックすると、その動作状況、平均レイテンシー、その他のメトリクスが表示されます。
この画面に戻りましょう - ここまではマクロレベルの話でした。次はミクロレベルの詳細を見ていきましょう。例えば、Pythonで書かれたBillingサービスがあります。初めてアクセスすると、さまざまな操作、依存関係、Canary、クライアントページが1つの場所に表示されます。また、p99、平均、p50、p90などのレイテンシーメトリクスも表示されます。サービス操作に移動すると、これらすべてが表示されます。ここで重要なのは、レイテンシーにいくつかの異常が見られることです。このレイテンシーのスパイクの原因を調査してみましょう。関連するSpanをクリックすると、そこからトレースページに移動できます。
ここからは、トレースの詳細だけでなく、トレースの詳細から始まる複数の情報を表示します。 また、各ホップにかかる時間を示すSpanタイムラインも表示されます。例えば、Pet Clinicフロントエンドだけを担当するJava開発者であれば、その特定のホップで1.65秒かかっている理由を確認できます。ログを送信している場合は、ここで確認することができます。依存関係については、それらをクリックすることができます。例えば、このコールには4つの異なる依存関係があります。それらを確認すると、 DynamoDBの依存関係やPostgreSQLなどがあることがわかります。ここで、これを有効にしたい場合は、 これをクリックすると、さまざまなレイテンシーやスパイクなどが表示されます。同じ操作を行うことができます。
もう1つ興味深いのはSLOです。これについては先ほど話しました。 現在、SLOを作成する場合、2つのオプションを提供しています。1つ目のオプションは、サービスオペレーションSLIを使用する方法です。これらのApplication Signalsを有効にすると、サービスオペレーションに基づいてSLOを作成できます。もう1つのオプションは、CloudWatch Metricを使用する方法です。Application Signalsを使用したくない場合は、 CloudWatch Metricに基づいてSLOを作成することもできます。例えば、サービスオペレーションを選択し、Customer Serviceのような サービスを選び、POSTオペレーションなどの操作を選択できます。そして、リクエストベースか期間ベースかを指定し、レイテンシーがどうあるべきかを選択します。 100ミリ秒未満であるべきだと指定できます。
これがSLIを作成するために必要なすべてです。その後、SLOに移動できます。1ヶ月の時間枠、30日間のローリングウィンドウでどのように見えるのか気になるかもしれません。99%のアップタイムを達成したいとします。すると、 SLIとSLOがどうなっているかが表示されます。アラームを作成することもできます。現在、アラームをサポートしており、 SLIやSLOに対してアラームを作成したり、警告しきい値を設定したりできます。SLOがトリガーされるのを待つ必要はないからです。ここで30%などのしきい値を設定できます。30%のマークに達すると、アラームが作成されます。最後に、Synthetic Canaryについては、 Synthetic Canaryを作成し、さまざまなCloudWatch Synthetics Canaryの実行を確認できます。
例えば、特定のCanaryが複数回実行された様子を、すべての異なるステップやスクリーンショットとともに確認できます。 これにより、ユーザーがリアルタイムでアプリケーションをどのように見るかがわかります。 ログやHTTP Archiveファイルを含め、これらすべての要素をこの場所から収集します。Real User Monitoringについても同様で、コードスニペットを提供しますので、それを配置するだけで、 データが自動的に送り返されてくるようになります。これが全体的な流れです。
プレゼンテーションに戻りましょう。要するに、CloudWatch Application Signalsは、アプリケーションパフォーマンスモニタリングを実装するための推奨される方法だということを強調したいと思います。これらすべての機能、メトリクスの相関関係、特にOpenTelemetryをベースにしているため、ベンダーロックインなどの心配をする必要がありません。
ご清聴ありがとうございます。こちらが皆様のお役に立つかもしれない各種リソースのご紹介です。私たちは独自のObservabilityワークショップを用意しています。 これらのリソースはすべて無料でご利用いただけます。複数のお客様から集めたベストプラクティスも含まれています。また、現在TerraformやCDKベースのアクセラレーターもご利用いただけます。Observabilityの取り組みを始める際に、ゼロからスタートする必要はありません。すでに準備された各種スクリプトをご用意していますので、それらを確認してアクセラレーターから始めることができます。さらに、AWS Observabilityに特化したSkill Builderコースもご用意しており、こちらも完全無料でご利用いただけます。
ご質問がございましたらお気軽にお声がけください。また、アンケートへのご回答もお願いいたします。本セッションはCO359ですが、より詳しく学びたい方は、木曜日の15:30からApplication Performance Monitoringについて深く掘り下げるCO409セッションにご参加ください。木曜日のCO409でお会いできることを楽しみにしています。 本日は誠にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion