re:Invent 2025: CloudWatchによる大規模オブザーバビリティ実装とAI駆動の根本原因分析
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Implementing observability at scale: A blueprint for success (COP328)
この動画では、Alex LivingstoneとJared NanceがAWSにおけるエンタープライズ規模のオブザーバビリティ実装について解説しています。企業の90%でダウンタイムが1時間あたり30万ドルのコストになることを示し、ビジネスアウトカムメトリクス(例:Amazon.comの1分あたりの注文数)の重要性を強調しています。CloudWatchが月間20兆個のメトリック観測値と13エクサバイトのログデータを処理する規模を紹介し、集中ログ管理、Metric Insightsによるマルチリソースアラーム、Transaction Searchによる100%トレース保持、Contributor Insightsによる高カーディナリティデータ分析などの機能を説明しています。Application SignalsによるOpenTelemetryベースの自動インストルメンテーション、CloudWatch InvestigationsによるAI駆動の根本原因分析、MCPサーバーを活用した自然言語でのクエリ実行など、最新の機能も紹介されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
エンタープライズオブザーバビリティの現実と課題：ダウンタイムのコストとその影響
はい、皆さんこんにちは。私の名前はAlex Livingstoneです。私はPrincipal Specialist Solutions Architectで、クラウドオペレーション、特にオブザーバビリティを専門としています。オペレーションの仕事を約25年間やってきていまして、今となっては年を取ったなと感じますが、AWSでこの仕事を始めてから約9年になります。
まず、今日のエンタープライズオブザーバビリティの現実についてお話ししたいと思います。これは従来の監視とは大きく異なります。複数のリージョンにまたがって数百、あるいは数千ものアカウントを管理しなければならない場合があります。数千、場合によっては数万、そしてケースによっては数十万ものマイクロサービスやサービスがあるかもしれません。皆さんの中には、毎日ペタバイト単位のテレメトリーデータを扱っている方もいらっしゃるでしょう。もちろん全員がそうではありませんし、今日お話しするのは一般的なベストプラクティスですので、必ずしも巨大なスケールである必要はありません。
こうした状況が引き起こす課題として、私がお客様とお話しする際によく聞くのは、たくさんの異なるツールを使っているということです。ログは1つのツールに、トレースは別のツール、メトリクスはまた別のツールといった具合で、これが課題になります。また、非常にコストがかかることもありますし、アラート疲れにつながることもあります。アラート疲れが問題になっている方はどれくらいいらっしゃいますか?ええ、かなり多くの方がいらっしゃいますね。そして明らかに、これはアラートの見逃しや重要な問題の発見漏れにつながる可能性があります。ですから、これらはおそらく皆さんの多くにとって、そしてエンタープライズチーム全般にとって日常的な現実だと思います。
オブザーバビリティがスケールしない場合、こういった問題が見られます。平均解決時間の増加です。 先ほど申し上げたように、アラートのノイズと疲労です。データサイロ、そしてこれは実際のデータサイロだけでなく、チームのサイロもあるかもしれません。そしてそれが物事をより困難にする可能性があります。データがサイロ化されていると、チームもサイロ化されることが強化されてしまいます。そして複数のツールを使っている場合、それらのツール間で手動で相関関係を調べなければなりません。
これはお客様のところでよく見かけます。メトリクスが1つのツールにあり、ログが別のツールにある場合、メトリクスを見るために1つのタブを開き、ログを見るために別のタブを開かなければなりません。これらの異なるタブ間で時間を確認し、行ったり来たりしなければならず、これはかなり悪夢のような状況になり得ます。そして、異なるツールを使っている場合、異なるチームが異なるツールや異なる基準を使っていると、カバレッジに一貫性がなくなり、それがさらに物事を困難にします。
では次にコストについてお話しします。クリッカーで次に進む前に、ここにいる皆さんの中で、自分のアプリケーションや組織のダウンタイムが1時間あたり何ドルになるか正確に把握している方はいらっしゃいますか？どなたか？はい。では、企業の90%では、 1時間あたり30万ドルです。これは皆さんを脅すために言っているわけではありませんが、 企業の41%では1時間あたり100万ドルから500万ドルになります。ですから、これは脅しではありません。これは、なぜオブザーバビリティがあなたのビジネス、あなたの会社にとって重要なのかを正当化するためのものです。そうすれば、なぜオブザーバビリティに投資すべきなのかを正当化できるようになります。
なぜなら、ダウンタイムが発生した時にそれだけのコストがかかるのであれば、このダウンタイムを防ぐためにオブザーバビリティに投資できる比較的少額の費用は、投資対効果が非常に明確になるはずだからです。 もちろん、コストだけでなく、 エンジニアの失われた時間もあります。顧客が問題を経験することで、実際の ダウンタイムのコストを超えて、評判の損失にもつながる可能性があります。そしてこれは機能のリリース遅延にもつながる可能性があります。他にも影響はありますが、機能提供の遅延は、まだ得られていない収益に問題を引き起こす可能性があります。
メトリクスの考え方を変える：ビジネスアウトカムメトリクスの重要性
さて、技術的なソリューションに入る前に、まず皆さんに、少なくとも一部の方には、モニタリングのやり方について根本的に違う考え方をしていただきたいと思います。このセクションはメトリクスについての考え方についてです。従来、モニタリングを見る時、私たちはインフラストラクチャメトリクスを見ます。ここではコンピュート、ネットワーク、コンテナ、ストレージのようなものが見られます。そしてもちろん、ほぼすべてのAWSサービスのメトリクスを提供しています。そしてその上に
アプリケーションメトリクスがあるかもしれません。パフォーマンス、API コール、IOPsなどです。個々の機能に関するメトリクスもあるかもしれません。そしてゴールデンシグナル、つまり レイテンシー、トラフィック、エラー、サチュレーションです。皆さんのほとんどはこれらについて聞いたことがあると思います。
では、どう表現しようかな。皆さんの中で、その最上位のレイヤーで止まっている方はどのくらいいますか？そのレイヤーより上にあるかもしれないメトリクスについて考えたことがある方はいますか？はい、何人か、そうですね、数名手が挙がりました。そしてこれが私が皆さんに考えていただきたいことです：ビジネスアウトカムです。ビジネスアウトカムメトリクスは本当に、本当に 重要です。これについて考えていただきたいのです。そしてその理由は2つの基本的なものがあり、これからそれについてお話しします。
しかし、お客様が何を気にしているかを考えてみてください。お客様はEC2インスタンスのCPUなんて気にしていません。コンテナの使用率も気にしていません。ストレージやCPU、メモリ、Lambda関数がどれだけ使われているかも気にしていないんです。お客様は自分たちにとって重要なことを気にしているのであり、皆さんもお客様にとって重要なことを気にかけるべきなんです。
例えばAmazon.comにアクセスした場合、私たちの最も重要なメトリクスは、お察しの通り、CPU使用率ではありません。パフォーマンス関連のメトリクスでさえありません。レイテンシーでもないんです。これらはすべて重要ですが、最も重要なメトリクスは1分あたりの注文数です。なぜなら、Amazon.comにアクセスする目的は何かを購入することだからです。何かを購入できなければ、それは問題なんです。
そして、こうしたビジネスアウトカムを測定すべき理由は、大きく2つあります。1つは、ビジネスアウトカムを測定していれば、技術的なメトリクスが問題を教えてくれなくても、ビジネスアウトカムのメトリクスは必ず問題を教えてくれるということです。もう1つの理由は、技術的なメトリクスが問題を教えてくれたとしても、ビジネスへの影響がどれほどなのかをどうやって知るのか、ということです。多くの場合、おそらく皆さんもこの問題を経験したことがあると思いますが、大まかな見積もりをすることはできます。良い見当がつくかもしれません。しかし、確実に知る唯一の方法は、ビジネスアウトカムを測定することなんです。
ですから、もしこれ以上のことを持ち帰っていただけるなら嬉しいですが、もし1つだけ持ち帰るとしたら、ぜひ皆さんのアプリケーションにおけるビジネスアウトカムのメトリクス、お客様にとって重要なことは何かを考えて、それを測定していただきたいんです。もう1つの利点としては、マネージャーの方々も、BIツールを待って週次や月次のレポートを受け取るのではなく、こうしたビジネスアウトカムのメトリクスをほぼリアルタイムで見られれば、きっと喜ばれるでしょう。
エンタープライズスケールでのオブザーバビリティ実装の青写真
それでは、このようなエンタープライズスケールでobservabilityを実装する方法について、青写真のようなものをご紹介していきます。集中ログ管理、メトリクスの収集方法についてお話しします。トレーシングについてもお話しします。そして、それにインテリジェンスを追加する方法についてお話しします。異常検知についてお話しします。Jaredがhigh cardinalityメトリクスの見方についてお話しします。そして、相関関係と、それを自動的に行う方法、タブ間を行ったり来たりしなくて済む方法についてもお話しします。
そしてそれに加えて、CloudWatch Investigations、APMのためのApplication Signals、そして特殊なインサイト統合についてお話しします。これについては後ほど詳しく説明します。それでは、Jaredに交代して、Amazonでどのようにこれを行っているかについて話してもらいます。
AmazonにおけるCloudWatchの活用：20兆個のメトリクスを処理する規模とインストルメンテーション
皆さん、こんにちは。私の名前はJared Nanceです。CloudWatchのprincipal engineerをしています。これから、私たちが自社のサービスを監視するために、内部でどのようにCloudWatchを使用しているかについて少しお話しします。ただ、その前に、CloudWatchの規模を理解していただくために、少し時間をいただきたいと思います。毎月、私たちは20兆個のメトリック観測値を処理し、13エクサバイトのログデータ、4550億のトレース、そして毎月8億6100万のcanariesを実行しています。
なぜこれが重要なのでしょうか？それは、私たち自身のサービスの規模についての洞察を与えてくれるからです。そして実際に、私たちはこれらのサービスを監視するためにCloudWatchを使用しています。Amazonでは、新しいワークロードに対してCloudWatchを大部分で標準化しています。もちろん、初期の頃からのCloudWatchを使用していない古いシステムもいくつかありますが、新しいものはほとんどすべてCloudWatchに依存しており、Amazon全体でこれを使用しています。そして、私たちが監視とオブザーバビリティにアプローチする方法は、実際にチームとサービスをどのように組織化するかから始まります。
多くの皆さんがご存知のように、AmazonはDevOpsモデルに従っており、システムの複雑さをサービスに分割し、それらのサービスは私たちがtwo pizza teamsと呼ぶものによって運用されています。まず、新しいサービスを作成するときに何が起こるかを見てみましょう。私たちは一般的なアーキテクチャ用のblueprintsのセットを持っており、チームはすべてがすでにセットアップされたblueprintのインスタンスを作成するだけです。
では、Lambda関数統合を使用したAmazon API Gateway上で実行されるAPIワークロードを考えてみましょう。それはこのような感じになるかもしれません。このシステムがCloudWatchで成功するように設定されていることをどのように保証するのでしょうか？それらすべてのvendedサービスについて、プロビジョニングに使用するinfrastructure as codeテンプレートは、Amazon API Gatewaysからの実行ログやgatewayとLambda関数からのアクティブトレーシングなどをすでに設定しています。もちろん、サービスからのすべてのvendedメトリックは無料で取得できます。そして、AWS Lambdaで実行している場合は、自動的にCloudWatch Logsと統合されます。
しかし、カスタムテレメトリについてはどうでしょうか？カスタムテレメトリについて話すとき、私が実際に指しているのは、サービスから必要となるワークロードやビジネス固有のインストルメンテーションのことです。このワークロードが何をしているのか、何と相互作用しているのか、バッチで何件のレコードを処理したのか、これらを知るために必要なすべてのデータは、テレメトリに追加できるカスタムデータなのです。これらのブループリントを作成する際には、インストルメンテーションフレームワークが事前に組み込まれています。このような基本的なLambdaハンドラーにも、必要な方法で事前設定されたインストルメンテーションフレームワークが付属しています。
この関数内でインストルメントを作成すると、キャッシングフレームワークやWebフレームワークなど、使用している他のすべてのフレームワークと相互運用されます。ここでインストルメントを作成すると、関数を呼び出しているIDなどが自動的に追加されます。ログにトレースIDがリンクされ、これらはすべて開発者として考える必要のないことです。そして、カスタムメトリクスと、テレメトリに含めたいラベルを追加できます。次に、インストルメントファクトリを子オペレーションに渡すことで、すべてのコンテキストを引き継ぎながら、さらにインストルメンテーションを継続できます。
そして、ここでの相互運用性は非常に重要です。Amazonでは、インストルメンテーションフレームワークを長い間標準化してきましたが、OpenTelemetryのようなツールを使用して、この種の相互運用性を得ることができます。これにより、キャッシングフレームワークやWebフレームワークなど、使用しているフレームワークがすべて一貫した方法でテレメトリを発行し、テレメトリに情報を追加する際にコンテキストを引き継ぐことができます。テレメトリを発行する際、メトリクスとラベル、そしてこのようなイベントデータを同じ場所に配置します。これにより、スパン内に高カーディナリティのコンテキストを保存しながら、アラームやダッシュボードなどの他の用途にメトリクスを使用できます。また、Logs InsightsクエリやContributor Insightsを実行することで、どのリクエストが失敗したか、どの顧客が影響を受けているかといった質問に素早く答えることができます。
高カーディナリティデータの取り扱い：Contributor InsightsによるトップN分析
今日のオブザーバビリティにおける最も困難なことの1つは、高カーディナリティデータの取り扱いです。従来の監視システムでは、これらの課題には、数百万の一意のメトリクスを発行する可能性があり、既存のシステムの制限に達する可能性があることなどが含まれます。また、インサイトはそのカーディナリティの爆発的増加の中に埋もれてしまいます。レイテンシというメトリクスを発行したいだけのサービスを考えてみてください。顧客、APIエンドポイント、リージョンといったディメンションがある場合、1,000の顧客と50のAPIエンドポイント、10のリージョンがあれば、1つのメトリクスが50万の一意のメトリクスディメンションに爆発的に増加します。
そこで、Contributor Insightsは異なるアプローチを取ります。自動的なトップN分析を使用し、これらの構造化ログを取得して、データ内のメトリクスのトップコントリビューターを特定します。リアルタイムのコントリビューターランキングが可能になり、メトリクスのディメンショナリティとカーディナリティの爆発的増加を引き起こさないため、コスト効率的です。Embedded Metric Formatと呼ばれるデータの構造化フォーマットを提供しており、これにより自動的に実現できます。そのスパンデータを発行すると、CloudWatch Logsに構造化データがあり、抽出したいメトリクスがメトリクスにあり、すべて単一のイベントを通じて実現されます。
また、アラーム統合機能もありますので、特定のメトリクスで閾値を超えている単一のコントリビューターがいる場合に、実際にアラームを発生させることができます。これにより、お客様の中のたった一人が問題を抱えている状況を特定することができます。
これは、Contributor Insightsを使用している場合に得られるグラフの一例です。社内では、すべての重要なメトリクスに対してこれを使用しています。可用性がわずかに低下しているケースがあり、それがすべて単一のお客様によって引き起こされていることに気づいたことがあります。そして、そのお客様と協力して、デプロイメントを通じて導入された可能性のある、お客様に影響を与えている可能性のある問題を特定することができました。実際に、Personal Health Dashboardsを動かすためにContributor Insightsを使用しており、大規模なイベントが発生した際に、短時間でどのお客様が影響を受けているかを特定し、迅速に通知することができます。これが、私たちがそれを行うために使用しているツールです。
集約メトリクスから個別トレースへ：クロスアカウント・クロスリージョンでのインシデント検出と対応
つまり、Contributor Insightsを使うことで、集約されたメトリクスから、そのメトリクスのトップコントリビューターを特定することができます。しかし、集約されたメトリクスから非常に小さなスライスに移動したい場合はどうでしょうか？おそらく、一つのエラー、一つの失敗しているリクエストがあるかもしれません。その一つの集約されたメトリクスの完全なトレースを見たいかもしれません。このようなサービス可用性のグラフがあるとします。これは集約されたメトリクスで、このデータの各サンプルには多くの異なる実際のリクエストが含まれている可能性があり、何が起こっているのかを理解するために、それらのリクエストの一つだけを取得したいのです。
メトリクスと構造化ログデータを同じイベント内に配置しているため、このようなLogs Insightsクエリを実行することができます。ここでは、まずAPIによってデータを分離し、エラーが発生したリクエストのみにフィルタリングしています。そして今、トレースIDや例外メッセージなどを取得できます。しかし、クロスアカウントやクロスリージョンについてはどうでしょうか？AWSでは、リージョンの分離のために、ワークロードをアカウント間で分割しています。つまり、新しいリージョンにサービスをデプロイするたびに、それは完全に異なるアカウントに分離されます。しかし、これらすべてにわたって可視性をどのように得るのでしょうか？オペレーターがページングされると、彼らはどのリージョンかを正確に把握しており、したがってどのアカウントに入るべきかを知っています。オペレーターグループが複数のサービスアカウントを所有している場合、アカウントとリージョンをまたいでCloudWatchデータを集約する中央監視アカウントを作成できます。
それでは次に、インシデントの検出と対応、そして実際にお客様に影響を与えている可能性のある問題をどのように発見するかについて、少しお話ししましょう。これらのブループリントを作成する際、infrastructure as codeを通じてCloudWatchにデプロイする事前定義されたダッシュボードも一緒に提供されます。これにより、毎週サービスチームがすべてのカスタマーエクスペリエンスメトリクスを確認し、このレイテンシーの増加を引き起こしているものは何かという質問をすることができます。これにより、問題を深掘りし、正しいものを監視しているかどうか、サービスでどのような種類のリグレッションが見られるか、そしてまだ設定していない自動検出が必要な可能性のあるものを特定するための、定期的なリズムが得られます。
しかし、私たちは一日中ダッシュボードを見つめているわけではないので、何か問題が発生したときに通知してくれるアラームを使用しています。大規模なイベントは実際に複数の問題をトリガーする可能性があるため、すべてのアラームが チケットを発行してオペレーターにページングするのは望ましくありません。そのため、私たちはコンポジットアラームを使用してチームとのインターフェースを実現しています。 子アラームが発火すると、コンポジットアラームがトリガーされ、そのコンポジットアラームがインシデント管理システムにチケットを作成します。 そのチケットが作成されると、自動的にCloudWatch Investigationがトリガーされます。CloudWatch InvestigationはAI駆動の調査を開始します。根本原因を特定しようとし、オペレーターがログオンして問題を調査する前に、それを実現できることを期待しています。
調査へのリンクをチケットに埋め込んでいるので、 オペレーターがログオンしたときに、チケットに直接アクセスし、問題が発生しているアカウントに直接フェデレーションできるようになっています。 AIサマリーを確認し、必要に応じてさらに手動で調査を行うことができます。それでは、これらの機能についてより詳しく、そしていくつかの他の機能についても話してもらうために、Alexに戻したいと思います。
集中ログ管理とマルチリソースアラーム：大規模環境での一元管理を実現する新機能
ありがとう、Jared。さて、最初にお話ししたいのは、 これらはすべて皆さんの役に立つものです。ここでは、これを大規模に実行するのに役立つ多くのことについてお話しします。最初にお話しするのは、集中ログ管理です。さて、数ヶ月前に新機能を導入しました。これは大きなギャップを埋めるものです。なぜなら、 私たちはすでにしばらくの間、すべてのモニタリング、つまりメトリクスとトレースをクロスアカウントおよびクロスリージョンで、単一のモニタリングアカウントまたは複数のモニタリングアカウントに集中化する機能を持っていました。そして欠けていたのは、これをログで行う機能でした。
これはお客様が長い間求めていたもので、今ではこれが可能になりました。もしご存じなければ、数ヶ月前にこれをリリースしました。そして今では、ログの無料コピーを1つの中央の場所、つまり1つのアカウント、1つのリージョンに持つことができるようになりました。つまり、1つの場所からすべてのログをクエリできるということです。
これは本当に大きなことだと思います。これは本当にエキサイティングです。なぜなら、これによってCloudWatchをメトリクス、ログ、トレースの中央の宛先として持つことができるようになったからです。これまでは、ログに関しては少し問題がありました。これはマルチアカウントおよびマルチリージョンです。 そして先ほど申し上げたように、これによってアカウントとリージョンをまたいだ統合されたLog Insightsクエリを実行できるようになりました。 また、コストを管理するための集中的な保持ポリシーを持つこともできます。
大規模に行うのが難しいもう一つのことは、アラームの作成です。これも数ヶ月前にリリースされたばかりのものです。まず、課題についてお話ししましょう。以前は、リソースごとにアラームを作成する必要がありました。何十万ものコンテナがあって、各コンテナにアラームを設定したいとします。これをインフラストラクチャ・アズ・コードで行うとしても、やはり面倒ですし、リソースごとにアラームを作成しなければなりませんでした。そしてそれは、一貫性のない閾値を生み出すことにもつながります。つまり、異なるチームが異なる閾値を設定するわけです。
そして明らかに、アラームの乱立を引き起こします。数万、数十万、場合によっては数百万ものアラームが発生する可能性があり、一元管理ができません。そして閾値のチューニングを見ると、それは事後対応的で、異なるチームが閾値に対して異なることをしています。つまり、これは何千ものアラームがあるのに、それらが実際に重要なことを測定しているという確信が持てないという悪夢のようなシナリオを生み出すわけです。
Metric Insightsでは、常にCloudWatchメトリクスに対するSQLライクなクエリを持っていました。しかし最近追加した2つのことがあります。1つは、提供されたメトリクスに対するタグベースのフィルタリングです。つまり、クエリでタグを使用できるということです。そして最も大きなことは、マルチリソースアラームだと思います。これが可能にすることは、例えば10万個のコンテナがあって、それらのコンテナのいずれかでCPUが80%を超えたらアラートを出したいという場合、10万個のアラームを作成する必要はなく、1つのアラームでそれができるということです。これは明らかに一元管理を提供し、また環境全体を見渡してトレンド分析を行うためのより良いビューを提供します。
これによって、アラーム管理の方法が変わり、これらすべての個別リソースを管理できるようになります。そしてこれがその見た目です。ここでは、実際に私が言った例があります。私が見ているのは、アカウント内にある可能性のあるすべてのコンテナにわたる最大メモリ使用率です。私はそれほど多くは持っていないので、そこには20個ほどですが、1つのクエリですぐに実行でき、それらすべてのコンテナにアラームを設定できます。
サンプリング不要のTransaction Searchと3つの柱での異常検知
ここにいる皆さんの中で、トレーシングを行っている方はどのくらいいますか?なるほど、かなりいますね、おそらく3分の1から半分くらいでしょうか。そしてコストのためにトレースをサンプリングしなければならない方はどのくらいいますか?ええ、かなりいますね。Transaction Searchでは、サンプリングの問題を解決します。つまり、おそらく1%から5%をサンプリングするのではなく、100%のトレースをキャプチャできます。これは、それらのトレースのリアルタイム検索も可能にするので、数秒で数百万のトレースを処理できます。トレースにカスタム属性を追加でき、それらはオプションでインデックス化されます。そしてこれにより、ギャップのない相関関係を持つことができます。
さて、サンプリングを行う場合、問題があります。
では、テールサンプリングを行う場合でも、つまり、テールサンプリングを設定したいとしましょう。これは設定可能なのですが、エラーは100%保持して、成功したリクエストは5%だけサンプリングするとします。しかし、それでもうまくいかないんです。なぜなら、成功したリクエストであっても、実際に見に行きたい場合があるからです。技術的には成功したかもしれませんが、実際には問題があって、それを確認する必要がある場合です。サンプリングの問題は、すべてがどのように見えるかの集約を得るか、または個々のトレースを見に行って、一部の人が抱えていた問題を確認できるかのどちらかなんです。しかし、特定の問題があって、それがサンプルに含まれていない場合、それを確認しに行く機会がないということです。
そこで、Transaction Searchが可能にするのは、すべてのトレースを保持し、数百万のトレースを数秒でクエリする能力です。ビジネスコンテキストでフィルタリングできます。これらは、例えば顧客ID、セッションID、そういったもの、さらにはフィーチャーフラグなどです。これらをトレーシングに追加できます。そして、ログやメトリクスと自動的に相関付けられます。また、このトレースデータを機械学習分析などのためにエクスポートすることもできます。
そして、この検索は最大10,000アカウントで実行できます。これはほとんどのシナリオで機能すると思います。 そして、これがその見た目です。ここでは、すべてのトレースを検索して、ステータスコードでグループ化しただけです。ステータスコード別のアカウント数が表示されています。そして、そこに「結果を要約」というボタンがあるのが見えると思いますが、これはAIを使ってクエリの結果を要約するものです。
これはLog InsightsでもTransaction Searchでも使用できます。そして、どのステータスコードがあって、それぞれいくつあるかについて少し教えてくれる要約が表示されます。異常検知については、 3つの柱すべてで異常検知を行っています。つまり、メトリクス、ログ、トレースです。
メトリクスでは、季節性を考慮したベースラインを取得できます。過去14日間のデータを使用します。モデルは継続的に調整されるので、より良い新しいモデルを作成すれば、そのモデルに置き換えます。もし良くなければ、古いモデルを保持します。カスタムメトリクスとベンダーメトリクスをサポートしています。そして、これが行うのは単に外れ値を特定することです。
これは、繰り返し可能なメトリクスがある場合に本当に便利です。例えば、日中は忙しいパターンがあって、夜は静かかもしれません。あるいは、上昇し続けるメトリクスや、下降し続けるメトリクスがあるかもしれません。または、初めて本番環境に移行する際に、そのメトリクスのベースラインがどうなるか全く分からない場合もあるでしょう。つまり、メトリクスのanomaly detectionを使用するユースケースは4種類あるということです。
そして、ログのanomaly detectionもあります。これは、確か昨年導入したpattern detection in logsというものをベースに構築されています。そのpattern detection in logsをベースに構築しました。そして、ログのanomalyを自動的に表面化できます。log groupに対してオンにするだけです。そして、5つの異なるanomalyタイプがあります。
1つは頻度です。これがより頻繁に発生しているか、あるいはより少なく発生しているか。または、新しいパターンが出現したか、あるいはパターンが完全に消失したかもしれません。そして、これをlog anomaly detectionでlog groupに対して継続的に実行することもできますし、log insightsクエリとして実行することもできます。
もう1つ、持ち帰っていただけるものがあります。もし1つだけlog insightsクエリを持ち帰るとしたら、残念ながらここには載せていませんが、pattern app message、pipe、anomalyと入力すれば、基本的に選択したlog group内のすべてのanomalyのサマリーが得られます。そして、すべてのlog groupを選択できます。つまり、すべてのログを1つのアカウントの1つのリージョンに集中化している場合、log insightsに入って、pattern app message、pipe、anomalyと書けば、その期間内のすべてのログのすべてのanomalyを教えてくれます。本当に、本当に便利です。
そして次にトレースです。トレースについては、X-ray analyticsと統合されていて、レイテンシーやエラー率、他のサービスへの依存関係などを見ることができます。
では、これらがどのように見えるかお見せしましょう。これは非常に安定していて繰り返し可能な典型的なメトリクスです。ここでご覧いただけるように、すべてがこのグレーのバンド内に収まっています。このグレーのバンドのサイズは調整可能で、このバンドの上または下、あるいは上だけ、または下だけを超えたものに対してアラートを設定できます。
そしてこれがログ異常検知です。ここでは、以前に発生していなかったエラー、または増加を検知しています。いえ、以前に発生していなかったものですね、たぶん。そしてここでご覧いただけるように、これらのログのパターンを検知する際に、基本的に行っているのはパターンを見て変数を取り出すことで、これをトークンと呼んでいます。ここにトークン値がありますが、私がこれらのトークン値を見ることにしたのは、トレースIDを表示してくれるからです。つまり、このログ異常を見て、よし、これをもう少し調査したいとなったら、実際にこれらのトレースIDを見て、それからそれらのトレースを見に行って何が起こったのかを確認できるわけです。
そしてトレースとログイベントは相関しているので、トレースビューを見ると、これらのトレースのいずれかのトレースビューを見れば、そのトレースに関連するすべてのログイベントも表示されます。そしてこれがトレースにおける異常検知、異常検知の見え方です。これはX-Rayコンソールでの表示です。これは少し付加価値も提供してくれます。問題の説明やルートコーズ、あるいはルートコーズとなるサービスも示そうとしてくれます。そしてこれをさらに深く掘り下げることができ、より多くの情報が得られます。
Application SignalsとInsights統合：自動インストルメンテーションによるフルスタック可視性
さて、Application Signalsです。より多くのインサイト、より少ない作業と言いましたが、ここでは少し作業が必要ですが、それほど多くはありません。Application SignalsとOpenTelemetryが登場する前は、手動でコードのインストルメンテーションを行う必要がありました。つまり、開発者がアプリケーションにコードを追加する必要があったわけです。リリースごとに手動で更新する必要がありました。Jaredが先ほど話していたように、データ収集に一貫性がなく、どのライブラリがカバーされるかという点でも選択的なカバレッジでした。
しかし今では、Application Signalsによって、少なくともPython、Java、.NET、そしてNode.jsについては、自動インストルメンテーションが可能になりました。そしてこれはOpenTelemetryを使用しています。つまり、オープンスタンダードを使っているということです。OpenTelemetryを使って自動インストルメンテーションを行い、そしてトレースをX-Rayに、メトリクスをCloudWatchに送信しています。そしてこれはエージェントベースのデプロイメントです。コードは不要で、ただドロップインしてプラグアンドプレイするだけなので、設定だけで済みます。これは特にEKSで簡単に実行できます。EKSにobservabilityアドオンを追加して、Application Signalsをオンにするだけで完了です。
ECSやEC2で実行する場合は少し作業が増えますが、基本的にはエージェントをデプロイして設定を追加するだけです。そしてLambdaにもオプションとして組み込まれています。そして明らかに、これによって実装が非常に速くなります。開発者の労力はほとんど必要ありません。メンテナンスも簡単です。エージェントは私たちが保守します。EKSでは、エージェントの更新も私たちが行うことができます。すべてのアプリケーションで標準化されたテレメトリが得られ、これによって何の労力もなくフルスタックの可視性が得られるのです。
ただし、これを使いたくない場合が一つあります。高頻度取引のような、非常にレイテンシに敏感なアプリケーションをお持ちの場合は、どのベンダーの自動インストルメンテーションも使わない方がいいでしょう。CloudWatchであろうと何であろうと関係なく、自動インストルメンテーションは使わないでください。わずかなオーバーヘッドがあるからです。自動インストルメンテーションの仕組み上、コードを見てその場で分析するため、わずかなレイテンシが追加されます。しかし、そういったケースでない限り、使わない手はないと言えるでしょう。
そしてApplication Signalsのすべてをお見せするスクリーンショットを撮るのは本当に難しいのですが、これが大まかな概要です。
Application Signalsはサービスディスカバリーを実行し、ゴールデンシグナルを自動的に作成します。これらのゴールデンシグナルに基づいてSLOを作成できるので、サービスの健全性を確認できます。これは天気アプリケーションで、私のSLOの設定がおそらく少し厳しすぎたようです。実際にはそれほど悪くないのですが、すべてが不健全と表示されています。障害率別のサービスが表示され、これらの個別のサービスに入ると、どのような依存関係があるか、どのサービスと相互作用しているか、そしてその個別サービスのSLOなどが表示されます。
これはより良いものです。より多くのインサイトが得られ、作業は全く必要ありません。有効にする必要はありますが、それだけです。Container InsightsはEKSとECSで使用でき、クラスターレベルからポッドレベルまでのリソース使用率を提供します。コンテナのパフォーマンス、クラスターのパフォーマンスに関するメトリクス、デプロイメントに関する情報を取得でき、Application Signalsとも統合されています。
次にDatabase Insightsがあります。これも有効にするだけです。実際には、デフォルトで有効になっていますが、2つのティアがあります。本番環境で本格的なものを実行している場合は、おそらく次のティアを有効にしたいでしょう。デフォルトでは基本ティアのみが提供されます。RDSのパフォーマンス監視、クエリの分析、コネクションプールのトラッキングなどの機能があり、パフォーマンスに関する推奨事項も提供できます。つまり、データベースで何をすべきかについて、プロアクティブに推奨事項を提供してくれます。
そしてLambda Insightsがあります。これも有効にするだけで、関数レベルのメトリクスが得られます。コールドスタート分析、メモリとCPU使用率、ネットワークなどで、これもトレーシングと統合されています。これがどのように見えるかお見せしましょう。これがContainer Insightsの見た目です。特定のサービスの1つのビューがあります。2つのポッドを実行しているだけで、その個別のサービスのすべてのメトリクスを確認できます。
Database Insightsには、たくさんの情報があります。この特定のデータベースはあまり忙しくありませんが、トップSQLを確認できます。Lambda Insightsでは、複数関数のビューまたは単一関数のビューを持つことができます。ここでは単一関数のビューがあります。これは現在の天気を取得する私のサービスの1つです。呼び出し、期間、メモリ使用率、CPU使用率などを確認できます。また、直近1000回の呼び出しのビューを取得でき、アプリケーションログに直接リンクできますし、Application Insightsへの直接リンクもあります。
AIによる根本原因分析：CloudWatch InvestigationsとMCPサーバーの活用
そして今、少しの作業から作業なしへと進んできましたが、今度はAIにあなたのために作業をさせます。お話ししたように、メトリクス、ログ、トレース全体にわたる異常検知があります。そして、CloudWatch Investigationsを使用して、これらすべてのリソースの相関関係を見ることができます。これがどのように見えるか簡単にお見せします。これはサービス間の因果関係の視覚的なマッピングを提供し、自然言語による根本原因分析を提供します。ランブックの推奨もできます。
これは複数のアカウントにまたがるスコープを持つことができるので、1つのアカウントだけで実行することを心配する必要はありません。まあ、1つのアカウントで実行しますが、複数のアカウントのスコープを取り込むことができます。変更イベントと相関させることができるので、明らかにメトリクス、ログ、トレースなどを見ますが、CloudTrailのようなものも見ます。先ほど言ったように、調査のスコープを視覚的に概観できます。調査結果をチームと共有することができます。もちろんプログラマティックアクセスもあります。
Jaredが言ったように、私たちは社内でこれを使っています。アラームがあれば、調査を作成します。CloudWatchアラームに基づいて調査をトリガーできますし、その後明らかにAPIを使ってその情報を好きな場所に送ることができます。つまり、インシデントワークフローと統合できるということです。そして、もしこれを使うなら、私たちと同じような方法で使うことをお勧めします。これをITSMプロセスと統合してください。例えばServiceNowを使っているなら、これをServiceNowチケットに入れてください。
では、これがCloudWatch investigationがどのように見えるかの例です。何が起こったかを教えてくれて、証拠と可能性の高い原因を示してくれて、視覚的な概観を与えてくれています。この下にいくつかの理由があります。心配しないでください、私が何をしたかを説明します。
基本的に私はこのメトリクスを見ていて、左側のimpact startと書かれているところで、Lambda関数の実行時間が少し増加していることに気づきました。私のLambda関数は、だいたい4秒弱ではなく、ほぼ6秒間実行されていました。そこで調査を依頼しました。そしてこれが根本原因のサマリーです。基本的に、Bedrockが私をスロットリングしていました。なぜなら、レート制限に達していたからです。そして、Bedrockへの繰り返し失敗した呼び出しのために、私のリトライロジックが失敗していました。関数の実行時間が4秒から6秒になったと教えてくれています。つまり、根本原因を教えてくれて、明らかにBedrockの制限を増やすように言ってくれるわけです。
また、CloudWatch用のMCPサーバーもあります。実際には2つあります。CloudWatch MCPサーバーがあり、これは自然言語を使ってメトリクス、ログ、トレースなどを見に行くことができます。また、Application Signalsもあるので、Application Signals内のすべてのデータを見ることができます。この2つを一緒に使うのが、おそらく最良の方法です。これらがここの上部で尋ねるかもしれない自然言語の種類です。そして、これは私が実際に尋ねたことの1つです。ここでは、Quiroを使っています。
Quiroでは、これらのMCPサーバーをセットアップしていて、私のアプリケーションがEU West Oneにデプロイされていると伝えました。コードベースに基づいて、Quiroはハッシュコードベースを入力すると、コードベースのコンテキストを持つようになります。私は過去1時間の本番環境でのCPUスパイクを表示するように依頼しました。コードベースがあり、MCPサーバーがあるので、どのリソースを探せばいいかわかっています。このアプリケーションに関係のない、私が気にしないものを探しに行くことはありません。ここにログ情報などが表示されていますが、今のところそれはあまり重要ではありません。お見せしたいのは出力結果です。
ここでの出力は、EC2インスタンスのCPU使用率にいくつかのスパイクがあったことを示しているだけです。クリティカルなスパイクが検出されたと言っていますが、おそらくクリティカルではないと私は思います。私のEC2インスタンスは最大で30パーセント程度までスパイクしただけです。それからEKSポッド、ECSサービスがいくつかあり、それらのサマリーを提供してくれています。最後に、良いニュースとして、アプリケーションとその他の重要なサービスは全期間を通じて安定していたと言っています。しかし、これらすべてを、たった一つの小さなプロンプトだけで実行してくれました。ですから、MCPサーバーを使用できるなら、これは本当に素晴らしいです。CloudWatch MCPサーバーとApplication Signals MCPサーバーを見てみてください。CloudWatch Investigationsを使用するだけでなく、物事を掘り下げていくのに本当に役立ちます。
オブザーバビリティ基盤の構築ステップ：基礎からインテリジェンス追加、そして最適化へ
私たちはログ、メトリクス、トレースといった様々なことについて話してきました。 これらは、AIツールを意味のある方法で使用するために構築する前の基礎となるものです。基盤を設定する必要があります。すべてを一箇所に集めるために監視アカウントを設定してください。同じく、すべてを一箇所に集めるためにログの一元化を設定してください。コンプライアンス要件などを含む、組織の要件を反映した保持ポリシーがあることを確認してください。
アラートフレームワークをデプロイしてください。つまり、Jaredが話していたようなものです。アラートを出すとき、またはCloudWatchアラームがあるときは、標準的なパターンに従ってください。そして、CloudWatch Investigationをトリガーし、Jaredが説明した方法でシステムにチケットを開くことが含まれるかもしれません。そして、リソースにタグ付けがされていることを確認してください。特に、Metric Insightsの機能により、少なくとも今のところベンダーメトリクスについては、タグに基づいてクエリを実行できるので、これは非常に便利です。
ここで触れていないもう一つのこと、おそらく言及すべきだったのは、標準を作成することです。ログの標準を作成し、メトリクスの標準を作成してください。すべてのチームに対して、JSON形式でログを記録すべきだと伝えてください。これらは、すべてのアプリケーションやサービスに必要な種類のフィールドです。誰が所有しているか、どのアプリケーションの一部か、どの環境にあるかといったことです。これらすべてが非常に重要です。
そして次にインサイトについてお話しします。左側には基本的なものがあります。インサイトは、デプロイが本当に簡単です。もちろんコストはかかりますが、デプロイの容易さという点では、これらを導入しない理由はありません。Container Insightsは、チェックを入れるだけです。Database Insightsも同じです。Lambda Insightsも同じです。もちろん、コンソールを使うだけでなく、infrastructure as codeでもこれを行うことができます。EC2にはCloudWatchエージェントを入れましょう。EC2にエージェントを入れていない方はいますか?どんな種類のエージェントでも構いません。良いですね、それは良いニュースです。時々お客様とお話しすると、EC2に何も入れていないことがあるんです。
EC2にCloudWatchエージェントを入れる利点は、明らかにすべてを一箇所で管理できることです。また、Compute Optimizerを使ってEC2インスタンスを適切なサイズにすることもできます。Compute Optimizerを使っていてCloudWatchエージェントを使っていない場合、CPUとネットワークのメトリクスしか取得できません。メモリを考慮せずにEC2インスタンスを適切なサイズにしたい人なんていませんよね。ネットワークモニタリングを有効にしましょう。CloudWatchにはネットワークを監視する本当に素晴らしいツールがあります。つい最近、EKSのモニタリングに関する何かがCloudWatchに組み込まれて発表されたと思います。
この短い時間では、これについて詳しくお話しする時間がありませんでした。Internet Monitorを見てみてください。これは本当に素晴らしいもので、どんなことができるのか見てみる価値があります。そして、アプリケーションパフォーマンスを見始めましょう。 Python、Java、Node、または.NETで書かれたアプリケーションをお持ちの場合は、applicationsとsignalsを見てみてください。開発環境のワークロードの一つで試してみて、何が得られるか見てください。ほとんど労力をかけずに、たくさんの情報が得られますから。
サンプリングをしたくない場合や、すべてをトレースするコストが心配な場合は、Transaction Searchを有効にしてください。これも非常に便利で、データを失うことがなくなります。SLOにはApplication Signalsを活用しましょう。ただし、Application Signalsを使っていない場合でも、これはすぐには明らかではないのですが、CloudWatchコンソールに行ってapplication performance monitoringの下にあるSLOsを見ると、実際にはどんなCloudWatchメトリクスでもSLOを作成できます。Application Signalsに関連している必要はありません。
ウェブアプリケーションにはReal User Monitoringを有効にできます。そして、synthetic canariesを作成できます。Synthetic canariesは本当に、本当に便利です。最短で1分ごとに実行できます。単純なheartbeatチェックのようなものもできますし、複雑なワークフローを実行することもできます。スケジュールで実行することも、オンデマンドで実行することもできます。ですから、スモークテストのようなものにも役立つかもしれません。synthetic canariesを使ってスモークテストを一式作成して、パイプラインの最後にオンデマンドで実行するのです。そして、インテリジェンスを追加しましょう。
では、Contributor Insightsを使いましょう。ここでContributor Insightsを使っている人は？誰もいない、これは本当に悲しいですね。Contributor Insightsは私たちが持っている最も強力なツールの一つだと思います。つまり、もう一度詳しくは説明しませんが、Jaredが話していましたので、Contributor Insightsをぜひ見てみてください。本当に、本当に強力ですから。アラームにはMetric Insightsを使ってください。metric anomaly detectionを見てください、log anomaly detectionも見てください、それから、Log Insightsでクエリを実行するときに、パターン分析をどのように使えるかも見てください。
これらすべてを揃えたら、そこで初めてCloudWatch Investigations を本当に適切に活用できるようになります。
これらすべてを実施していなくてもCloudWatch Investigationsは使えますが、CloudWatch Investigationsから最大限の効果を得るには、明らかに、AI駆動型のものすべてと同様に、より多くの情報があればあるほど、正しい答えにたどり着くのが上手くなります。Systems Managerでランブックを作成できます。Systems Managerでランブックを作成している人はどれくらいいますか？ええ、何人かいますね。
アラームがトリガーされたときに、繰り返し可能で自動化で修正できるものがあれば、Systems Managerのオートメーションドキュメントを実行することを選択できます。これの本当にシンプルな例は、EC2インスタンスがある場合、ディスクがいっぱいになっただけで午前2時に起こされたくないですよね？Systems Managerには、ディスク容量がいっぱいになったというアラームがあれば、このドキュメントをトリガーするだけで済む、すでにSystems Managerに組み込まれているオートメーションドキュメントがあります。それがEBSボリュームを拡張し、その後OSボリュームをEBSボリュームに拡張してくれるので、午前2時に起こされる必要はなく、朝出勤してから調査できます。
AWS Chatbotもありますので、それを使ってSlackやTeamsとの間で情報を送受信できます。これらのインシデントワークフローを設定することは本当に重要です。アラームを直接SlackやTeamsに送信するだけで、適切なインシデント管理ワークフローを持たないという状況にならないようにしてください。
そして、これらすべてを完了した後、その時点で初めてコストとパフォーマンスの最適化を始めることができます。その段階で、composite alarmsの使用を検討するのも良いでしょう。Composite alarmsを使うと、ブール論理を使用してアラームのツリーを作成できます。Embedded Metric Formatのようなものを使用することもできますし、ログ保持期間のような項目の最適化を始めることもできます。また、メトリクスを最適化することもできますし、トレーシングに関しても、特にTransaction Searchを使用している場合は、サンプリングを最適化することができます。
それでは以上です。ご参加いただき誠にありがとうございました。楽しんでいただけたことを願っています。アプリでアンケートにご記入ください。本当にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion