re:Invent 2025: Application SignalsでMTTR50%削減を実現したAI可視化事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Observability for AI Agents and Traditional Workloads (COP335)
この動画では、AWSのApplication Signalsを活用したアプリケーション監視とトラブルシューティングの実践が紹介されています。IgorとSivaがOpenTelemetryベースの自動インストルメンテーション、アプリケーションマップ、AI operations investigationsなどの新機能をデモで解説し、generative AIエージェントの可視化やモバイルReal User Monitoring、クロスアカウント対応などの最新機能を紹介しています。CCC Intelligent SolutionsのMuthuは、年間1700万件の自動車保険請求を処理するシステムでApplication Signalsを導入し、MTTRを50%削減、コストを40%削減した実例を共有しています。特にハリケーン時の急激なトラフィック増加への対応や、AI operationsによる複雑なトランザクション分析が数分で完了する効果が強調されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AIの時代における変革：トイレットペーパーからAIへの比喩
皆さん、おはようございます。良い朝をお過ごしのことと思います。ようこそお越しくださいました。この朝を皆さんにとってさらに良いものにできるよう努めます。まず最初に、Jeff Bezosが2005年にビジネスリーダーたちに講演を行った際に挙げた例をご紹介したいと思います。彼は、1857年に商業的に生産されたトイレットペーパーが導入されて以来、それがない状態に戻ることを想像するのは本当に難しくなった、という例を挙げました。それほどまでに大きな変革をもたらしたのです。
私はAIもそれと同じだと思います。一度手に入れたら、それなしでやっていた頃に戻ることを想像するのが本当に難しくなるツールなのです。私自身も確実にその一人です。今ではAIなしで物事を行うことは想像できません。ですので、今日はそれについて多くお話しします。私の名前はIgorです。AWSでApplication Observabilityを担当しています。そして本日私と共同でプレゼンテーションを行うのは、AWSのSenior Solution ArchitectであるSiva、そしてCCC Intelligent SolutionsのSenior DirectorであるMutuです。私たちは、アプリケーションにAIを組み込むこと、そしてAIがビジネスに組み込まれた状態でビジネスを運営できること、さらには自分たち自身の運用生産性のためにAIを使用することというトピックについて深く掘り下げていきます。これらのトピックをカバーしていきます。
アプリケーション運用における4つの共通課題とAI時代のエントロピー増加
こちらが、私たちが継続的に耳にしてきた共通の課題です。 以前から多く耳にしてきましたし、今も皆さんのようなお客様から継続的に聞いています。アプリケーションは複雑さを増しています。マイクロサービスが増えていますし、最近ではagentsを使うことで、開発者が存在すら想像していなかったデータベースへのSQLクエリをagentsが作成するようになります。ですから、開発者が設計もプログラミングもしていないのにAIがアプリケーションに新しいものを導入している場合、エンドユーザーと顧客への影響を理解することがこれまで以上に重要になっています。
2つ目は標準化です。すべてが異なる場合、複数のサービスや組織を運用することは本当に難しいと一般的に聞いています。誰もが独自のメトリクス、独自のログライン、独自のトランザクション表現方法を発明します。そのため、生産性が低下するだけでなく、チーム間でのエンジニアの異動にも影響します。新しいチームに参加したときにすべてが新しく、すべてが異なっていると、オンコール対応で何が起こっているのかを理解しようとするときに生産性が低下します。
3つ目は優先順位付けの能力です。すべての異常がエンドユーザーに影響を与えるわけではありませんので、それらが発生したときに実際に何が重要で何がそうでないかを理解することが本当に重要です。AIはかなり役立ちますが、通常は、何が本当に重要なのか、つまり顧客に影響を与えるインシデントとそうでないものを理解するために、自分自身やAIに対して少しガイダンスを与える必要があります。
4つ目は、単に分断された体験です。複数のツール、ログ用のツール、トレース用のツール、メトリクス用の別のツール、そしてすべてが分断されています。そのため、レイテンシのスパイクが発生したとき、何が原因なのかを理解するのが本当に難しく、別のツールに移動したり、コンテキストを共有して相関関係を理解する方法を考えたりするのに多くの時間を費やすことになります。
これらが一般的な課題です。これらの課題は、アプリケーションにAIを適用したり導入したりし始めても消えることはありません。さらに、今日、システムにおけるエントロピーは、通常、人間がミスをする能力によって制限されています。時にはバグがチェックインされたりすることもありますし、あるいは人間がウェブサイトやデジタルビジネスに対してトラフィックを生成する能力によって制限されています。そして今、AIによって、そのエントロピーの速度は増加していくだけなんです。先ほど申し上げたように、AIは単に新しいツールを使うことを決定したり、エンドユーザーが尋ねた質問に基づいて、これまで持っていなかった新しい依存関係を作成したりすることができます。ですから、これらの課題に対処することがますます重要になっているのです。
CloudWatch Application Signalsの仕組み：OpenTelemetryによる統合オブザーバビリティ
そこで数年前、私たちはこれらの課題に対処し、アプリケーションを管理し、ビジネストランザクションを管理できるようにするために、CloudWatchにApplication Signalsを導入しました。これが行うことは、サービスの検出、アプリケーションの検出、依存関係の検出を提供することです。
これは、サービスの日次監査をどのように見るか、何が重要で何が重要でないかについて、運用プラクティスを標準化します。これらは実際に私たちがAWSで自分たちのサービスのために行っていることです。Service Level Objectivesを使用すると、モバイルユーザーのログインや支払いなどのデジタルジャーニーを優先順位付けして宣言でき、それが自分にとって重要であることを示すことができます。また、メトリクス、ログ、トレースを1つの統一された体験で相関させる機能もあるため、ツール間を行き来することなく、すぐに根本原因分析を行うことができます。
どのように機能するのでしょうか？私たちはOpenTelemetryを使用してテレメトリを収集します。LambdaやEKSのようなマネージドサービスの場合、それをランタイムやマネージドサービスに組み込んでいます。それ以外の場合は、単にエージェントを取得して、これが機能するために必要なテレメトリを収集することができます。LangChainやStrandsなどに実装されているオープンソースのエージェントからテレメトリを収集するのと同じ方法で収集します。私たちはOpenTelemetryをお客様に提供しており、セキュリティスキャンされ、AWSサービスに対して非常に簡単に認証できるすべてのセキュリティ要素を含むパッケージになっています。
そしてテレメトリは、CloudWatch Agentを通じて収集されます。これはOpenTelemetryエージェントですが、私たちはテレメトリを圧縮したり、アダプティブサンプリングを機能させたり、テレメトリのコストを削減するための多くの改善を加えています。または、私たちが提供しているOpenTelemetryエンドポイントに直接送信することもできます。どちらの方法でも、テレメトリを送信できます。それが処理され、CloudWatchとX-Rayに収集されます。これを1つの製品として考えてください。そこで私たちはトポロジーを導出し、メトリクスを計算するなどの処理を行います。そしてApplication Signalsは、トランザクションを確認したり、アプリケーションマップを確認したり、エージェントを含む異常を確認したりできるエクスペリエンスです。
Application Signalsの4つの重要機能：自動検出から生産性ツール連携まで
では、3つのこととは何でしょうか？ 今年のApplication Signalsについて重要な4つのことです。まず、多くの場合、アプリケーションをインストルメント化しなくても、アプリケーションの完全な全体像を見ることができます。これはデモでお見せします。依存関係を理解するために必要な手作業を大幅に削減しました。トラフィックが流れていない場合でも、メタデータと設定に基づいてそれを把握できます。
2つ目は、皆さんの働き方に合わせてオブザーバビリティを整理できることです。つまり、私たちは自動的にアプリケーションを検出し、接続性によってグループ化し、名前の類似性や属性の類似性によってグループ化します。しかし同時に、ビジネスユニットやチームなど、皆さんがどのように見たいかを私たちに伝えることもできます。皆さんの働き方に合わせてアプリケーションを整理できるのです。これもデモでお見せします。
3つ目は、自動オペレーショナル監査を使用して、数分で非常に迅速に問題を解決できることです。開発者が日々行っていることを、私たちがバックエンドで代わりに行います。皆さんが持つすべての依存関係を監査し、すべてのレイテンシー、すべてのAPIを監査し、自分で掘り下げて調べることなく、重要なことに迅速に対処するために必要なインサイトを導出します。また、変更オーダーも行います。アプリケーションの変更、新しいデプロイメントを検出し、その影響を受ける部分を理解し、例えばこのデプロイメントによって新しい依存関係が生じたことを把握します。これもデモでお見せします。
そして4つ目、これは非常に重要ですが、このツールを皆さん自身のAI生産性ツールに接続できることです。皆さん自身のAI、どれを選んでも、皆さんのエージェント、これらのオペレーショナルツールに接続できます。そして私たちのMCPなどは、AIが生産的になるように設計されています。同じ質問に対してテレメトリを50回スキャンすることなく、トークンを節約できます。私たちはこれらのオペレーショナル監査や変更監査のようなツールをエージェントに提供するので、生産的になれるのです。
2024年の新機能総覧：AIエージェント計装からSyntheticsまで
それでは、今年の新機能をご紹介します。まず1つ目は、Application Signalsにおいて、OpenTelemetryを使ってAIエージェントを計装します。それをシステムに流し込むことで、アプリ内のエージェント、それらがどのように相互作用するか、何をするか、どのデータベースを使用するか、どのユーザーに応答するかを確認できるようにします。
2つ目は、自動アプリ検出です。以前はサービスのフラットなリストだけでしたが、今では自動的に理解できる意味のある単位にグループ化します。また、先ほどお話ししたように、どのように表示したいかを指定することもできます。属性を宣言して、その属性が自分のビジネスユニット名だと伝えれば、毎回ビジネスユニットごとに表示してくれます。そういったことができるようになります。
ECSやLambda、API Gatewayなど、アプリケーションを構成する多くの異なるサービスについて、計装やエージェントなしで、非計装サービスをサポートします。マップを描画し、依存関係を理解します。運用ヘルス監査、変更影響監査を提供します。クロスアカウントアプリケーションマップも提供するようになったので、例えば複数のアカウント間で共有されているアプリケーションやその一部、複数のアカウントをまたいで呼び出しているものを確認できます。EKSクラスターでの自動アプリケーション検出と計装をサポートしており、実際に何もインストールする必要がありません。安全な方法で、適切な場所にコードを配置し、EKSクラスターで実行されているサービスを計装できるようにします。
アダプティブサンプリングもサポートするようになりました。以前は固定サンプリングのみで、コスト効率の良いオブザーバビリティを実現していました。異常が発生して知る必要がある場合、サンプリングレートが増加します。また、依存関係などでexemplarもサポートしているので、サンプリングする際に、実際に重要なものを取り出して、後で検査できるように脇に置いておきます。
AI Opsについては、MCPサーバーをリリースしました。先ほど申し上げたように、人間に提供しているすべてのツールをエージェントにも提供することで、エージェントがアプリケーションの運用とオブザーバビリティで生産的に作業できるようにします。また、開発者がすべての本番環境のテレメトリーを活用してコードを改善できるGitHub actionもローンチしました。これについてはデモをお見せします。
Real User Monitoringについては、モバイル、iOS、Androidをカバーするように拡張しました。現在、ソースマップをサポートしており、これによりWebのJavaScriptコードがminifyされていても、正確なコード行を理解できるようになります。そして、すべてのモバイルテレメトリーに対してOpenTelemetryのインジェストをサポートしています。
Syntheticsでは、マルチブラウザテストをサポートしており、1つのタスクで一度にすべてのブラウザをテストできます。Javaをサポートしています。Syntheticsでは、以前からすべての言語とPlaywright、Selenium、Puppeteerをサポートしていましたが、今回Javaのサポートを追加しました。ドライランができるようになり、カナリアを本番環境に投入する前にドライランを実行して、どのように動作するかを確認できます。現在、小規模で軽量なAPIチェックや単純なpingチェックを効率的な方法でサポートしています。そして今では、すべての商用リージョンでリージョンパリティを実現し、GovCloudもサポートしています。
これらが今年導入した新機能です。基本的に、皆さんからいただいたフィードバックやリクエストに基づいています。では、実際に動作しているところをご覧いただくために、Sivaをステージにお招きして、これらすべてが動作しているところをお見せします。ありがとう、Siva。
デモ開始：PET Clinicアプリケーションで見るOperational AuditとGenerative AIエージェントのトラブルシューティング
ありがとうございます、Igor。皆さん、こんにちは。私の名前はSiva Guruvareddiarです。re:Inventに改めてようこそ。それでは、Application Signalsの最新かつ最高の機能について、いくつかデモをお見せします。しかし、少し振り返ってみましょう。お客様は、アプリケーションがエンドユーザーにとってパフォーマンスが高く、利用可能であることを望んでいます。そのために、エンドユーザーに最大の影響を与えるために、チームの働き方を中心としたオブザーバビリティを求めています。私たちはこれらすべてのフィードバックに耳を傾けました。そこで、この1年間でApplication Signalsにおいて私たちがアプローチしてきたことをお見せします。
私たちは、アプリケーションのAPIや依存関係に対して、リアルタイムで自動的にオペレーショナル監査を実行し、根本原因を特定します。これにより、オンコールエンジニアの時間を節約できます。すべてのトレースについて、トレースはより技術的なものなのに、それをどのようにビジネスインサイトと結びつけるのか疑問に思われるかもしれません。トレースを送信するたびに、それをビジネスインサイトに変換したい場合、GenAIエージェントの例を取り上げてみましょう。
Generative AIエージェントは独自の思考を持っており、これらのエージェントの思考がどのように機能しているかを理解したいと思うでしょう。このケースでは、この Application Mapという新機能を追加しました。カスタムグルーピングが可能になっています。現在、アプリケーションレベルのグルーピングを行っており、SLI違反を検索すると、たくさんのタイルが表示されます。同じデモを続けて、PET Clinicアプリケーションを使っていきます。
このケースでは、いくつかのPET Clinicエージェントを実行しており、現在SLI違反が発生しているのが確認できます。ログ、メトリクス、トレースといった細かいところに入り込む代わりに、view modeをクリックして、Operational Audit機能を使うことで、依存関係の可用性の問題があることが簡単にわかります。そして、こちらでfault rateの増加が確認できます。しかし、ここで何が起こっているのかを理解したいと思います。そこにサンプルトレースのリンクがありますので、それをクリックすると、X-rayページに移動し、すべての情報が表示されます。
お客様が私のPET Clinicフロントエンドに来て、PET Clinicエージェントを呼び出しています。spansタイムラインを見ると、いくつかの例外が確認できます。これが最初の例外で、ここでUIに表示されている例外が確認できます。しかし、もう一度立ち止まって考えてみましょう。なぜなら、私たちはgenerative AIエージェントについて話しているからです。PET Clinicエージェントで何が起こっているのかを確認して理解したいと思います。再度view exceptionをクリックすると、これが正確に例外が何であるか、どこから来ているのか、どの行番号か、どのファイルかを教えてくれます。
これらは開発チームに渡して修正してもらうための貴重な情報ですが、繰り返しになりますが、generative AIエージェントは異なります。コンテキストも送りたいのです。ここで見ている例外メッセージに加えて、コンテキストも送ることができれば、開発者の作業が楽になります。それが皆さんから聞いたフィードバックで、そこでこのLLM eventタブを用意しました。これはgenerative AIエージェント専用で、ここからすべてのコンテキストを送信しています。これらがエージェントに送信しているすべてのコンテキストです。それだけでなく、その例外が発生したとき、お客様が尋ねた正確な質問は何だったのか、その情報もキャプチャしています。これらすべての情報を使えば、簡単です。現在、これらすべての情報を取得して、generative AIチームに送り、修正を依頼することができます。
モバイルReal User Monitoring：AndroidアプリのクラッシュをApplication Signalsで特定・修正
では、次に進みましょう。私たちが持っているPET Clinicアプリケーションは非常に人気があるため、iOSとAndroidの両方でモバイルアプリケーションをローンチしました。しかし、モバイルアプリケーションからのユーザー行動を、ユーザーがどのように認識しているかを理解したいと思います。最近、2週間ほど前にモバイルReal User Monitoring機能を追加したことをご紹介できることを嬉しく思います。現在、PET Clinic Javaに移動すると、3つの異なるアプリモニターが表示されます。1つはweb用、1つはAndroid用、そして1つはiOS用です。
見ての通り、私のAndroidはあまり良い状態ではありません。詳細を見てみると、右側のドロワーが表示されて、300件以上のクラッシュが発生しているのが分かります。ここで何が起こっているのか、もう一度理解したいと思います。私のPET Clinic Android appのモニターを見ると、これらのクラッシュの多くは、Owner Detailsという1つの画面だけから発生していることが分かります。モバイルユーザーにがっかりしてほしくないので、できるだけ早くこれを修正したいと思います。
実際にこの特定の場所に行って、ここからランダムにセッションを選択すると、ここから例外が明確に表示されます。行レベルの詳細も含まれています。この例外をコピーしました。後で使いましょう。でも技術的な部分に入る前に、ユーザーへの影響がどうなっているのか見たいと思います。影響分析に移動します。ここから、過去3時間だけで240人以上のユーザーが影響を受けていることが分かります。これはかなり深刻な問題です。すぐに修正したいと思います。
Android Studioを開きましょう。Application Signalsページから取得したスレッドダンプを修正します。それだけです。正確にどこで失敗しているのかを特定できます。ここから見ると、1つの属性しか受け取っていないのに、3つの属性を処理しようとしているようです。それが例外が示していることです。今のところ、これが正確に根本原因であることを確認したいので、必要のない2つの属性を削除します。編集したくないものをすべて削除して、ローカル環境で実行します。
エミュレーターでアプリケーションが起動し、以前クラッシュしていたまさにその画面、Owner Details画面に移動します。もうクラッシュしていません。この機能を使えば、モバイルアプリケーションとWebアプリケーションの両方を実行している場合、Application Signals機能、Real User Monitoring機能を使って、何が起こっているのかを簡単に把握できます。
ワンクリックインストルメンテーション：非計装アプリケーションの可視化を数分で実現
そして問題が発生したときに、簡単に修正できますよね。では、次に進みましょう。アプリケーションを実行していて、その中にインストルメント化されていないものとインストルメント化されているものがあり、インストルメンテーションフローを有効にする簡単なボタンが欲しいという方、手を挙げてください。それは素晴らしいことですよね。そう考えている方はどのくらいいますか。ええ。
インストルメント化されたフローに加えて、アプリケーションマップでインストルメント化されたフローと非インストルメント化されたフローの両方を表示できるようになったことをご紹介できることを嬉しく思います。これを証明するために、2つの異なるけれども似たようなアプリケーションを用意しました。1つはTicketing Liteと呼ばれるもので、もう1つはTicketingです。Ticketing Liteはインストルメント化されていません。それが点線で表示されているものです。私はなぜSLI違反が発生しているのかを理解したいと思いました。非インストルメント化されたアプリケーションを表示するだけでなく、その上にいくつかのSLIを作成することもできます。そのため、SLI違反が表示されているのです。
見た感じでは、まったく相互作用のない複数のサービスを呼び出しており、何が起こっているのかわかりません。多くの可用性の問題があります。ここでは多くの障害が発生しています。サービスの1つ、SubmitTicketLite Lambdaに入ってみると、誰かがデプロイしたことがわかります。つまり、多くの混乱があるわけです。何が起こっているのかを理解したいと思いました。しかし残念ながら、これらのどれもインストルメント化していないんですよね。これを理解したいのであれば、開発者にインストルメント化を依頼し、再度デプロイしてから、根本原因を特定する必要があります。
そこで私たちはフィードバックに耳を傾け、Application Signalsを有効にしています。今では、ボタンをワンクリックするだけで、そこに行くことができます。このアプリケーションのグルーピングで、3つの点のボタンをクリックして、Application Signalsを有効にすると言います。すると有効化フローに移動します。ここから、この特定のグループにまとめられているすべてのサービスが、私たちの理解に基づいて、さまざまなサービスを表示します。どのサービスを有効にするかは、あなた次第です。
有効にすると、おそらく5分ほど経った後、このTicketingサービスが内部でどのように動作しているかを表示するようになります。今ではずっと理にかなっていますよね。なぜなら、ListTickets Lambdaが呼び出されているのが見えますし、CreateTickets Lambdaがあり、これは以前は表示されていませんでした。これは見たことがありませんでした。また、データベース操作やSQSメッセージなども実行しています。さて、View Moreをクリックして、Operational Auditから何が起こっているのかを理解したい場合、明らかにSQSにメッセージを送信していることがわかります。これはかなり長いものですが、SQSは特定のバイト数しか受け付けることができません。
この機能により、IDEを開く必要もなく、開発者にコードのインストルメント化を依頼する必要もありません。簡単です。ボタンをワンクリックするだけで有効にできます。デモではLambdaを使って見せましたが、EKSを含む他のサービスもサポートしています。では、次に進みましょう。
変更追跡とクロスアカウントオブザーバビリティ：デプロイメント影響の即座の把握
それでは、もう一度手を挙げてください。あなたがDevOpsオペレーターで、本番環境で問題なく動いていたのに、突然誰かが変更をデプロイして、システムが壊れてしまい、何が起こっているのかを把握するために右往左往している、という経験はありますか?こういったことに直面したことがある方はどれくらいいますか?これはDevOpsオペレーターの日常ですよね?お客様に影響が出る前にアプリケーションを修正する方法をお見せしたいと思います。
そのために、audit serviceがあります。SLA違反が発生しているaudit serviceがあります。ここでも、25分前に最後のデプロイメントが行われたことをお見せしています。DevOpsオペレーターとして、誰かがデプロイしたので私は知らないわけですが、なぜデプロイしたのか、どんな変更を行ったのか、そういったことを理解したいわけです。View Detailsをクリックすると、CloudTrailのページに移動します。ここにすべての情報が表示されます。誰がデプロイしたのか、いつデプロイしたのか、どんな設定変更を行ったのか、すべての情報です。これでヒューリスティックな情報は得られましたが、これが根本原因かどうかはわかりません。それを確認したいと思います。
次にred metricsを見ると、デプロイメント直後に可用性の問題とfaultが発生していることがわかります。これが原因だと確信したので、ロールバックしたいと思います。そこに行って、最新のデプロイメントを削除します。これがすべての問題を引き起こしているからです。削除すると、ロールバックが実行されます。5分ほど経ってから画面に戻ると、SLAが回復しています。しかし、これが本当に問題を解決しているのかを確認したいと思います。もう一度View Moreをクリックします。今回は32分前のデプロイメントが表示されていますが、これがまさに私たちのロールバックです。そして今、red
metricsから、2回目のデプロイメント、つまりロールバック直後に、可用性が100%に上がり、500エラーが0になったことがわかります。これはまさに期待していた通りです。このようなことが簡単に確認できます。デプロイメントを追跡するだけでなく、設定変更もキャプチャしています。誰かがtime parameterなど、どんな設定を変更しても、すべての情報をキャプチャするので、必要なすべての情報がダッシュボード自体で確認できます。
次に進んで、クロスアカウントについてお話ししましょう。環境全体で複数のアカウントにまたがって複数のアプリケーションを実行している方は手を挙げてください。すでにそうしている方はどれくらいいますか?これは典型的な問題です。お客様と話をすると、皆さん独自のアカウントで実行しています。フロントエンドが独自のアカウントを持ち、バックエンドチームが独自のアカウントを持っていることもあります。金融サービスのお客様と話をすると、lendingが1つのアカウントにあり、loanが別のアカウントにある、といった具合です。しかし、すべてのアプリケーションは常に互いに通信しています。サービスオペレーターとして、すべてを1か所から確認できたら便利ではないでしょうか?それをお見せしたいと思います。
それでは簡単なデモでお見せしましょう。現在、私はアポイントメントサービスゲートウェイを持っていて、これがクロスアカウントで実行されていることを証明するためのものです。タイルに入って、このview moreオプションをクリックすると、my accountsタブから2つの異なるアカウントで実行されていることが確認できます。beatsに入ると、複数のサービスを呼び出していることがわかります。ここから、アカウントIDでグループ化することができます。アカウントID 2341のすべてのサービスを表示してくださいと言うと、対応するサービスが表示されます。他のアカウントでも同じことを繰り返すことができます。もう一つのアカウント、アカウントID 4084でも同じことをやってみます。この場合、対応するアカウントが表示されます。それだけでなく、先ほどお話しした運用監査や変更インジケーターなど、クロスアカウントで実行されていても、すべて利用可能です。
どうやって繋がっているのか疑問に思われるかもしれませんね。ここでの接続組織はデータベースです。これも確認できます。依存関係のタイプはDynamoDBと指定できます。これが私たちがここで使用しているデータベースです。ここから、DynamoDBで、異なるアカウントからの両方のサービスがここに表示されているのが確認できます。このように、何百ものアプリケーション、何百ものサービス、何百ものアカウントで実行していても、すべてが一箇所から利用できるので簡単です。
AI時代のトラブルシューティング：MCP統合とGitHub Actionによる自動修正フロー
ここまでオペレーターの従来の業務を見てきましたが、これはAIの時代だと言われるかもしれません。どんなものを用意しているのでしょうか。ストーリーを見てみましょう、シンプルなストーリーです。これもまた、私たちのPet Clinicアプリケーションです。PetPal AIというチャットボットを導入しました。PetPal AIでは、どんな質問でもできます。ユーザーが来て、アポイントメントをスケジュールしたり、栄養情報について質問したりできます。さて、私は顧客で、ReInvent Pet Care、私たちのペットクリニックアプリケーションに来て、ペットのウサギの栄養情報が欲しいと思っています。質問すると、チャットボットが3つの異なるオプションを提示してくれます。私は顧客なので、どのオプションでも好きなものを選べます。3番目のオプションを選びます。この特定のものを注文したいと思います。私が探しているペットのウサギ用のこのサプリメントを注文してくださいと言います。
これで成功すると期待していますが、残念ながらチャットボットは在庫がないと言っています。私はユーザーです。少しがっかりしますが、他のオプションがあります。2番目のオプションに進んで、3番目のオプションは在庫がないと言ったので、2番目のオプションで注文してくださいと言います。しかし残念ながら、また同じことが起こります。製品を推奨してくれるのですが、注文しようとすると在庫がないと言われます。少しイライラしてきて、人間がするように同じようなことをします。在庫がある正確なペットフードを教えてくださいと言います。そうすれば確実に注文できますから。また、チャットボットが3つの別のオプションを提示してくれて、最初のものを選びます。そして、これは在庫があると言ったので、注文を進めてくださいと言います。しかしまた、残念ながら同じ問題です。技術的な問題があって注文できないと言われます。イライラします。
ペットクリニックのサポートシステムに行って、フィードバックチケットを作成します。あなたのチャットボットは製品を推奨してくれるのに、注文しようとすると動作しません。どうなっているんですか？と言います。エージェントとその動作に満足していない多くのユーザーや顧客がいるかもしれません。
さて、私はペットクリニックアプリケーションのサポートエンジニアです。ダッシュボードを開くと、多くのお客様が同じことを言っています。皆さん、チャットボットが製品を推奨しているのに、注文しようとすると動作しないと言っているんです。従来のやり方であれば、サポートエンジニアとして、ログ、メトリクス、トレースを確認しに行くべきでした。しかし、これは生成AIの時代ですので、Application SignalsとMCP統合されているKiro IDEを開きます。
ここから質問をします。ご覧のように、人間がやるのと同じように、たくさんの操作を実行します。MCPツーリング、それも複数のMCPツーリングと対話し、レスポンスを取得しながら、どのような質問をする必要があるかを理解していきます。最終的に、仮説を導き出します。これらがすべての主要な発見事項で、これらがすべての次のステップだと言っています。サポートエンジニアとして、情報を得ることができ、ログ、メトリクス、トレースを調べて、コードに飛び込んで、といったことをするのに比べて、これは簡単です。
さて、この情報を持って開発チームに行きたいと思います。この場合、Slackチャネルを使っているだけです。これが唯一の手段である必要はありません。あくまで例です。ここで私は言います、ねえ、お客様全員がこの件について文句を言っているよ。チャットボットが壊れているみたいだ。誰か修正してくれないか？まとめると、サポートエンジニアとして、従来のやり方で手動で作業する代わりに、MCPや他の生成AIツーリングからの支援を活用できるということです。
では、最後のものに移りましょう。最近、GitHub action統合を導入しました。ストーリーを続けましょう。まとめると、サポートエンジニアが、ユーザーがチャットボットが製品を推奨しているにもかかわらず注文できないと言っていると訴えています。さて、これが私のところに来ました。私は開発者です。ここでも、従来のやり方で作業する代わりに、AWS GitHub actionを使います。AWS APM、これが私のシナリオです、修正してください、と言います。
すると、GitHub actionがGitHubからコードを取得し、アプリケーションがどこで実行されているかを把握します。基本的にMCPが行ったのと同じ相関関係を行い、独自の仮説を導き出します。これがどう違うのか疑問に思われるかもしれません。ご覧のように、これは少し異なります。なぜなら、ファイルレベルの詳細と、何が起こっているかについての行レベルの詳細が表示されているからです。この場合、AWS APMエージェントは、ねえ、これらがすべて私の推奨事項で、これらがすべての問題です。何をしてほしいですか？と言っています。
私は開発者で、運転席に座っています。つまり、この問題をどう修正できるか考えるのは私次第なんです。では、よし、AWS APMよ、この特定の行に行って、この特定のファイルに行って、これを修正してくれ、と言います。私が言っているのは、このnutrition information Pythonファイルに行って、76行目から88行目に行って、システムプロンプトを変更してくれ、ということです。また、エージェントはvalidation layerが低優先度の項目だと言っていますが、開発者として、私はこれが自分にとって高優先度の項目だとわかっているので、このvalidation layerも修正してくれと言っています。それだけではなく、ガードレールも設定していて、データベースの変更は一切行わないでくれと言っています。なぜなら、エージェントにおかしなデータベース操作をしてほしくないからです。
それが終わったら、AWS APMにすべての変更を組み込んだpull requestを作成するよう依頼します。それがAWS APM GitHubエージェントがやっていることです。しばらくすると、この特定の結果が返ってきます。ここから、pull requestに入っていきます。エージェントが理解した問題文は何か、実行しようとしているソリューションは何か、そしてどのような変更とテストを行ったかを理解します。ファイルの変更を見に行きます。なぜなら、行われた変更をレビューしたいからです。ここで、よし、validation layerについて、エージェントに変更を依頼したら、その通りにやってくれた、と確認します。エージェントに依頼したことを、その通りにやってくれたと納得したので、承認したいと思います。
タブに行って、LGTM、つまりlooks good to meと言って、それから承認します。承認すると、誰かがコードをマージして、CI/CDフローが始動します。その後、変更がstagingに行くので、同じフローを再度テストしたいと思います。では、同じフローに戻ってきて、ここで顧客が尋ねているのとまったく同じ質問をします。
今回は、ねえ、私のペットのウサギに利用可能なペットフードのオプションは何ですか、と尋ねています。しかし今回は答えが違います。詳細は持っていないと言いつつも、あなたのペットについては何も知りませんが、予約を取ることができます、と言っています。そこで、土曜日なら空いているので予約を取ってくれと言うと、土曜日の11時30分に予約を取ってくれました。
このように、まとめるのは簡単です。ご覧いただいたもの、operational audits、uninstrumentedフロー、MCP統合、そしてGitHubフローなど、これらすべてのものについて、Application Signalsで提供しているこれらすべての最新かつ最高の機能により、Application Signalsを使えばobservabilityの旅がより簡単になることを確実にできます。しかし、私の言葉を鵜呑みにしないでください。私と一緒に、CCC Intelligent SolutionsのMuthuさんがいらっしゃいます。彼がここに来て、Application SignalsとCloudWatch全体が彼らのobservabilityの旅をどのように支援しているかについて話してくれます。それでは、これ以上遅らせることなく、Muthuさんをステージにお招きして、彼らの旅について話していただきたいと思います。ありがとうございます。
CCC Intelligent Solutionsの事例：年間2000万件の自動車事故処理を支えるオブザーバビリティ
Sivaさん、Igorさん、情報満載でパワフルなデモンストレーションをありがとうございました。本当にたくさんの新機能がありましたね。さて、皆さん、おはようございます。私の目標は、私の経験を共有し、皆さんが自分の環境で適用できるいくつかのことを持ち帰っていただくことです。25分しかありませんので、早速始めましょう。アメリカで年間何台の車が事故に巻き込まれているか、誰か推測できますか?どなたか推測してみませんか?500万台だと思う方は手を挙げてください。1000万台。2000万台。
アメリカには約3億台の登録車両があり、毎年7%の車が事故に巻き込まれています。つまり、毎年2000万台以上の車が事故に巻き込まれているということです。CloudWatchのミーティングでなぜ私が自動車事故の話をしているのか、不思議に思われているでしょう。私はCCC Intelligent SolutionsのMuthu、Muthukumaran Ardhanaryと申します。CCCは自動車保険金請求と衝突修理業界のリーダーです。人生に予期せぬことが起きたとき、CCCが動き出します。私たちは業界全体、自動車保険会社、修理工場、自動車メーカー、部品サプライヤーを結びつけます。私たちは彼らを一つにまとめ、人々が自分の旅に、自分の人生に、軌道に戻れるよう支援します。
これを実現するために、CCCは毎日何十億もの決定を下しています。そして私たちは300社以上の自動車保険会社、30,000社以上の衝突修理業者、5,000社以上の部品サプライヤーと協力し、年間1700万件の保険金請求を処理しています。これをサポートするために、私たちは数千のAPIを持ち、数千台のサーバーと数百のデータベース上で複数のポータルを運用しています。そして、すべての自動車保険金請求は、車が完全に修理されて車の所有者である顧客に引き渡されるまでに、数百とは言わないまでも数千のトランザクションを経ます。私たちのシステムは通常の営業日に50億件のトランザクションを処理します。そして、システムのスムーズな運用を確保するために、何十億ものトランザクションを処理する洗練されたシステムを持っています。私たちにはSREチームがあり、私はCCCでSREチームを管理しています。
さて、私たちは事故が起こる世界に住んでいます、たとえ自動運転車に乗っていてもです。事故に遭う可能性はあります。おそらくあなたのせいではないかもしれませんし、自動運転車のせいではないかもしれませんが、それでも事故に遭う可能性はあります。可能性はあるのです。同様に、たとえ最高クラスのシステムを持っていても、システムは障害や問題に遭遇する可能性があります。時には、システムのいくつかの問題に対処しなければならないこともあるでしょう。
ですから、今日の私のテーマは事故についてです、つまりシステム障害やシステムの問題についてであり、CloudWatch Application Signalsを使用してそれにどう対処するかということです。本日は、CCCがCloudWatch Application Signalsを使用して問題をトラブルシューティングしている方法と、過去数年間Application Signalsを使用して学んだことをお見せします。そして、主要なメリット、私たちが見ているビジネスメトリクス、どのように測定しているか、そしてメリットの観点から何が見えているかについてです。
それでは、APMジャーニーから始めましょう。CCCはApplication Signalsを使って2023年、2023年後半か2024年初頭あたりにAPMジャーニーを開始しました。そしてCCCは全てのワークロードをAWSに移行していました。同時に、モダナイゼーションも行っていました。全てのワークロードを従来のEC2からEKSプラットフォームに移行しました。そこで、そのオブザーバビリティをサポートできるクラウドネイティブなソリューションを探していました。そしてちょうどその時、AWSがre:Inventで、2023年後半あたりにそれをリリースしたんです。
そして私たちはPOCを始めました。POC中に際立っていたことが4つあります。1つは自動インストルメンテーションです。もう1つは統一されたワークフローと事前構築されたダッシュボード、そしてクロスアカウントオブザーバビリティです。クロスアカウントオブザーバビリティは私が大好きな機能です。基本的には、シングルペインオブグラスのようなものです。複数のアカウントでアプリケーションが動いている場合、SREにトラブルシューティングのために複数のアカウントにログインしてほしくないですよね。オブザーバビリティアカウントとして1つのアカウントを設定するだけでいいんです。1つの場所に行くだけで、インフラストラクチャやワークロード、環境内の全てを管理できます。それがクロスアカウントオブザーバビリティの全てです。
では、いくつかのシナリオを見てみましょう。どのように問題をトラブルシューティングするかです。このチャートでわかるように、このスクリーンショットはいくつかのスパイクを示しています。これはレイテンシースパイクです。ベースラインが約1,000ミリ秒くらいで、そしてレイテンシースパイクが2,000ミリ秒以上に上がっているのがわかります。適切なAPMツールがない場合、またはこのような問題をトラブルシューティングするための適切なプロセスがない場合、アラートが出たら何をするかというと、アラームを見に行きます。明らかに、最初に見るのは、メトリクスやシンセティックモニター、ログやダッシュボードです。これら全ては何かを教えてくれますが、根本原因は教えてくれません。これら全ては問題についての情報を与えてくれますが、根本原因を見つける助けにはなりません。
私たちがやっているのは、このようなレイテンシースパイクのアラートがあった時、トランザクション検索に行きます。トランザクション検索から、左側を見ると、より高いレイテンシーを持つスパンを検索します。スパンで高いレイテンシーを検索すると、対応するトレース、より高いレイテンシーを持つトレースが表示されます。トレースをクリックすると、スパンタイムが表示されます。この場合、post、実行しているSQLクエリが実際に長くかかっていることを示しています。この場合、1.23分かかっていることを示しています。その行をクリックすると、実際に実行された実際のselectクエリが表示されます。明らかに、見ることはできません。セキュリティ上の理由でマスクしています。これからselectクエリを見ることができます。クエリを取得したら、実際に、AWSでパフォーマンスインサイトとCloudWatchを使ってデータベースを実行している場合、そこに行って、なぜそのクエリが時間がかかっているのかを理解することもできます。おそらくインデックスが欠けているか、その他の理由があるかもしれませんが、すぐに理解できるでしょう。これが問題がある時に素早くトラブルシューティングする1つの方法です。
問題をトラブルシューティングする他の方法を見てみましょう。アプリケーションマップは最近ローンチされたもので、私たちはベータカスタマーとして製品チームと密接に協力し、全てのフィードバックを共有していました。これは私が最も気に入っているものです。なぜなら、環境内の全てのワークロードの視覚的な表現を提供してくれるからです。基本的に、ここに複数のタイルが見えますが、各タイルは私の環境内のサービスを表しています。各タイルはワークロードで、各タイルは実際にそのサービスと環境内の他の全てのサービスとのインタラクションを理解しています。それぞれをクリックすると、環境内のそのシステムのインタラクティブマップが表示されます。それは次のスライドで見ることができます。
これはシステムのリアルタイムヘルスも表示されており、上部で確認できます。赤い円があり、中央の一部は黄色、そしてほとんどが青色になっているのが見えますね。これは全て正常であることを意味しています。何かトラブルシューティングをしたい場合、興味のあるものに基づいて簡単にフィルタリングできます。この場合、私はサーバーフォルトを探しています。サーバーフォルトでフィルタリングすると、エラーやサーバーフォルトを持つ4つのサービスまたはワークロードがあることが表示され、その中の1つをクリックしてズームインして理解することができます。
その1つをクリックすると、インタラクティブなマップが開き、私のサービスがデータベースと通信していて、他にも複数のリモートサービスと通信していることが理解できます。その情報により、サービスの全体像を把握することができます。根本原因を理解したい場合、サービスを再度クリックすると、実際に関連するメトリクスとインサイトを含むコンテキストに応じたトラブルシューティングドロワーが開きます。ここでは、そのすべてのヘルス情報と、なぜ遅いのかまで表示されます。ここからさらに、対応する期間のトレースを表示する相関spanに進むことができ、なぜ実際に遅かったのかを確認できます。
相関spanに移動してトレースを取得できます。トランザクション検索に行く必要はありません。ここから直接トレースを取得できます。トレースをクリックすると、根本原因にたどり着き、特定することができます。しかし、そのダッシュボードに行きたい、それを見たいという場合は、view dashboardボタンをクリックできます。これによりApplication Signalsダッシュボードに移動します。もしあなたが視覚的な人で、全体像を理解していないL1リソースがいて、彼らがトラブルシューティングプロセスをナビゲートするために視覚的な表現が必要な場合、Applicationマップは本当に役立ちます。また、環境内のすべてのワークロードの全体像を探している場合にも使用でき、私たちはすべてのトラブルシューティングにこれを使い始めました。
では、他のシナリオと保険業界がどのように影響を受けるかを見てみましょう。例えば、ハリケーンのような予期しないイベントと、それが保険業界と私たちのシステムにどのような影響を与えるかです。
そこに行く前に、昨年2024年のハリケーンで何台の車が損傷したか、誰か推測できますか？数字をお伝えしましょう。昨年は2つの大きなハリケーンがありました。1つはHurricane Helene、もう1つはHurricane Miltonです。Heleneは南東部の州で140,000台の車に影響を与え、MiltonはFlorida州だけで約120,000台の車に影響を与えました。全体として昨年、ハリケーンだけで約350,000台の車が損傷しました。
ハリケーンが発生すると、人々は屋内に留まります。安全な場所にいたいと思うわけですが、車は道路上にあります。たとえ車が私道に停めてあったとしても、ハリケーンで何が起こるかはご存知ですよね。車が損傷してしまうんです。雨が止むと、人々は日常生活に戻りたいと思います。そして最初に必要になるのが車なんです。雨が止んだ瞬間、みんなが電話を取って保険会社に電話をかけ、車の修理を依頼します。
100万人もの人々がほぼ同時に保険会社に電話をかける様子を想像してみてください。クレームの量が文字通り5倍から7倍に跳ね上がります。私たちの通常の日は、5万件から6万件のクレームを受け付けています。つまり1日に6万件の事故を処理しているわけです。しかし短期間のうちに、その量が5倍から6倍に増加します。幸いなことに、私たちには自動的にスケールできるシステムがあります。最先端のシステムを持っているため、自動的にスケールして量を処理できるんです。ただし、時には小さなパフォーマンスの問題や、対処しなければならない細かい問題が発生することがあります。このような状況をAI operationsのinvestigationsを使ってどのように処理するかをお見せします。
複雑なトランザクションのトラブルシューティング：AI Operations InvestigationとGen AIオブザーバビリティ
このトレースマップを少し見てみましょう。このトレースマップは、1つのトランザクションに複数のサービスが関与していることを示しています。複数のサービスとデータベースがあることがわかります。トランザクションは行ったり来たりしています。これは、私たちの環境におけるクレーム処理の複雑なトランザクションの1つです。このような複雑なトランザクションがある場合、1つのデータポイントだけを見て結論や問題の根本原因を導き出すことはできません。複数のデータポイントを見る必要があります。
複数のデータポイントを見なければならない場合、実際にはより多くの時間がかかることを意味します。MTTRが上昇してしまうんです。MTTRが上昇すると、顧客に影響を与えることになり、顧客は満足しません。そこで私たちが使用するのがAI operationsのinvestigationです。AI operationsのinvestigationはエージェントベースです。裏側では、エージェントが実行されています。CloudWatch自体の一部なんです。裏側でエージェントが実行され、短時間のうちに複数のデータポイントを調べます。
これによりMTTRが大幅に削減されます。MTTRを95%から98%削減します。すべてのデータ分析が完了するまでにかかる時間はわずか3分、最大でも4分です。次の画面でお見せします。このAI operationsのinvestigationは、Application Signalsのページ自体から起動できます。あるいは、アプリケーションマップ自体から起動することもできます。アプリケーションマップから起動すると、自動的にコンテキストを理解します。時間を取得し、実際にinvestigationsを開始している時間枠のすべてのメトリクスを使用します。
調査を開始すると、そこにアクセスできます。バックグラウンドでは、エージェントが実行されています。AI operations investigationからアクセスできます。 エージェントは、どのような異なるデータポイントのテレメトリーデータを見ているかを表示します。すべてのテレメトリーデータ分析がここで利用可能です。このケースでは、42のタスクを実行しています。データベースと、トランザクションが関与するすべてのコンポーネントサービスを分析し、仮説のサマリーを提供してくれます。
問題が発生した場合、3つのものが必要です。 1つ目は、データポイントです。分析しなければならないデータポイントは何か。次に、データポイントに基づいて仮説を立てる必要があり、そしてアクションプランを考え出します。エージェントはすでにすべてのデータポイントを見てくれていて、仮説と発見事項を導き出してくれます。ここで見ていただけるように、仮説があります。ここにはデータベース関連の仮説がいくつかあり、すべての発見事項を提供してくれます。
この情報に基づいて、結論を導き出すことができます。 これが注目すべきポイントです。この時点で、あなたのアクションアイテムは非常に明確です。これらすべてが数分以内に完了します。しかし、もし人間のSREにこれをやってもらうとしたら、1時間、あるいは2時間かかるかもしれません。まだデータポイントを見ているかもしれませんし、何も結論を出せないかもしれません。しかし、すべてがエージェントによるAI operations investigationを通じて行われます。これはあなたのSREを強化するものであり、複雑なトラブルシューティングを行う際に本当に役立ちます。
では、Gen AI observabilityを見ていきましょう。 CCCはお客様にAIを活用したツールとテクノロジーを提供しており、私たちはモデルを使用しています。SageMaker上で動作する独自のモデルを持っており、Bedrockのモデルも使用しています。ユースケースの1つとして、Bedrockのいくつかのモデルを使おうとしていました。それはBedrockの最初のユースケースの1つでした。そして、私たちは製品開発チームと一緒に座って、オブザーバビリティについて理解しようとしました。
製品開発チームは、画面に表示されているように、サマリーを作成しようとしていました。私たちのウェブサイトには、衝突修理工場のレビューがあります。1つの工場に対して何百ものレビューがあります。彼らはAIモデルを使ってそれを要約したかったのです。そうすれば、何百ものレビューを読む必要がなく、1つのサマリーを見るだけで済みます。そして、これについて概念実証を行いたかったのです。モデルの観点からすべてを理解しようとしていました。しかし、重要なことは、呼び出しレイテンシーをどのように理解するかということでした。アプリケーションがモデルを呼び出す場合、使用しているトークン数をどのように理解するか。入力トークン、出力トークンは何か。
当時、私たちはオブザーバビリティを探していて、それでAWSに連絡を取りました。AWSはGen AIオブザーバビリティに取り組んでいて、すべてがすぐに使える状態で提供されていたので、私たちは何もする必要がありませんでした。このGen AIオブザーバビリティも、最近リリースされた新しい機能です。Gen AIオブザーバビリティには、私たちが探していたすべての情報が含まれています。呼び出しのレイテンシーがあり、モデル別のトークン数があります。また、入力と出力のトークンもあります。私たちが探していたすべてのものが、すぐに使える状態で利用できます。そして、モデル別に見ることもできます。基本的に、各モデルをクリックすると、複数のモデルを使用している場合は、モデル別にそれを見ることができます。すべての情報が得られます。これは、Bedrockの観点から私たちが使用しているものをサポートする上で、本当に役立ちました。
実践から学んだベストプラクティスとビジネス成果：MTTR50%削減、コスト40%削減の実現
さて、では過去2年以上Application Signalsを使って学んだことを見ていきましょう。これらは私たちが学んだことで、皆さんの環境でも役立つことを願っています。もしかしたら、すでにご存知のものもあるかもしれません。もしかしたら、今日何か役立つことを学べるかもしれません。トランザクション検索については、トラブルシューティングにどのように使ったかをご覧いただきましたが、多くの場合、コストを心配される方がいます。そこで私は、100%のスパン可視性を得るためにトランザクション検索を使用することをお勧めします。より低コストでスパン可視性を求めている場合は、トランザクション検索の使用をお勧めします。
例えば、本番環境以外や重要度の低いアプリケーションでは低いサンプリングレートを設定しているとしましょう。しかし、アラートが発生したとき、エラーが発生したとき、高いレイテンシーが発生したときには、100%の可視性が欲しいですよね。そういう場合には、アダプティブサンプリングを使用できます。基本的に、アダプティブサンプリングは、定義したより高い数値までサンプリングレートを上げます。100%まで上がるかもしれません。アラームが発生すると、基本的にアラームがトリガーされた瞬間に、サンプリングレートが上がります。アラームがOK状態に戻った瞬間に、サンプリングレートが下がります。これは、本番環境以外や重要度の低いアプリケーションで100%の可視性を得たい場合に、本当に役立ちます。これを使って、サンプリングレートを簡単に上げることができます。
そしてAIオペレーションですが、SREチームを強化するためにAIオペレーションを使用することをお勧めします。これは本当に役立ちます。彼らはトラブルシューティングに時間を費やす必要がなくなり、MTTRを大幅に削減できます。そして、アプリケーションマップは視覚的な人向けです。初心者でも、シニアリソースであっても。全体像を把握したい場合、アプリケーションマップは視覚的な方法でワークロードの可視性を得るのに本当に役立ちます。
事前構築されたダッシュボードについては、すべてのREDメトリクスやアラームの設定にも、事前構築されたダッシュボードを使用することをお勧めします。ダッシュボード自体からアラームを設定できます。とても簡単で、数回のクリックで必要なアラームを設定できます。そして、ランタイムメトリクスです。ランタイムメトリクスは、最初からApplication Signalsチームと密接に協力して取り組んできたものです。私たちは、メモリ、ヒープ、そしてすべてのガベージコレクションを理解するために、ランタイムメトリクスを本当に求めていました。これは、メモリ集約型のアプリケーションがある場合に役立ちます。ランタイムでアプリケーションがどのように動作しているかを理解したい場合に役立ちます。
そしてSLOアラームについてですが、もしSLIを定義していて、本当にSLOアラームのセットアップを検討しているのであれば、オペレーションレベルでSLOアラームを使用することをお勧めします。これは、アプリケーションの詳細なレベルの情報を取得するのに非常に役立ちます。サービスレベルで設定する必要はありません。複数のオペレーションがある場合は、オペレーションレベル、依存関係レベルでアラームを使用して定義することをお勧めします。そうすることで、より多くの情報が得られます。そしてContainer Insightsは、エージェントをインストールした瞬間から箱から出してすぐに使えます。これにより、コンテナの観点から必要なすべてのメトリクスと全体像を理解するのに役立ちます。
では、私たちが測定しているビジネスメトリクスと、Application Signalsで得られる主な利点を見ていきましょう。全体として、MTTRが50%削減されています。
これらがCloudWatch Application Signalsで得られる主な利点です。コストを40%削減でき、開発者だけでなくSREチームやテストチームの生産性も向上しています。全体として、システムパフォーマンスが大幅に改善されています。一方では生産性が向上し、もう一方ではシステムパフォーマンスも向上しています。なぜなら、お客様が何か問題があることに気づく前に、私たちが積極的に問題を特定できるからです。MTTRを削減しているため、迅速に対処することができ、それがシステムのパフォーマンス向上に大きく貢献しています。
CloudWatch Application Signalsは、MTTRやコスト、その他の面で削減するために多くの方法で役立ちます。今日、ぜひ試してみることをお勧めします。わずか数クリックで済みます。まだ試していない方は、今日すぐに試してみてください。数クリックでエージェントをインストールすれば、効率が向上するのがわかります。オブザーバビリティスタックの可視性が一晩で向上するのがわかるでしょう。
それでは、まとめに入りたいと思います。皆さんに一つのメッセージを残したいと思います。CloudWatchはオブザーバビリティの観点から多くの方法で役立ちます。そしてCCCは修復プロセスを高速化し、効率を向上させることができますが、実際に事故を防ぐことができるのは皆さんだけです。車の事故であれ、システムの事故であれ、それを防げるのは皆さんだけです。ですから、常におばあちゃんが見ているかのように運転することを忘れないでください。
それでは、これで締めくくりたいと思います。改めて、ご清聴ありがとうございました。皆さんの集中力は、この建物内での私の携帯電話の電波よりも強いですね。ありがとうございます。それでは、IgorとShivaを呼び戻したいと思います。ありがとう、Mutu。ありがとう、Shiva。さて、皆さん、もし請求がある場合は、Mutuが対応してくれます。AWSとAIがそれを支援しますが、まずは安全運転を心がけてください。それが第一です。
お時間を共有していただき、ありがとうございました。もしこのセッションを気に入っていただけたら、高評価のレビューをお願いします。ステージを降りたところで質問をお受けしますので、改めて、ご参加いただきありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion