※本記事は、AWS re:Invent 2024のセッション「Accelerate innovation with AI-powered operations (COP315)」の内容を基に作成されています。セッションの詳細情報は https://www.youtube.com/watch?v=bqVdwhgOsVM でご覧いただけます。本記事では、Mihir Patel氏、Nikhil Dewan氏、Jared Nance氏による講演内容を要約・構造化しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。また、より多くのAWSイベント情報は https://go.aws/3kss9CP で、AWSの動画は http://bit.ly/2O3zS75 でご覧いただけます。
1. はじめに
1.1. 登壇者紹介（Mihir Patel、Nikhil Dewan、Jared Nance）
- Mihir Patel: AWS Observability と AIOps サービスのゼネラルマネージャーです。Amazon に15年前にインターンとして入社し、これが10回目のre:Inventへの参加になります。夜中のページング対応やピークイベント中の対応など、Amazonの大規模な運用について学ぶ貴重な機会を得てきました。長年にわたり彼のチームと共に多くのAWSサービスの構築とリードを行い、何百万ものAWSカスタマーに価値を提供することに日々取り組んでいます。
- Nikhil Dewan: CloudWatch と AIOps のプロダクトリードを務めています。エンジニアバックグラウンドを持ち、様々な業界で運用重視の役割を経験してきました。クラウド監視の経験は、3大陸にわたる地質学者、掘削者、役員のニーズに対応するためのプライベートクラウドをエネルギースタートアップ向けに構築した際に始まりました。7年前にAWSに参加し、CloudWatchチームに在籍しています。日々、先見性のあるお客様や優れたチームと協力して、クラウド運用の可能性の境界を押し広げる特権を持っています。
- Jared Nance: CloudWatch のプリンシパルエンジニアです。製造業やヘルスケア業界など複数のスタートアップや企業規模の組織でドメイン固有の監視ソリューションを構築した経験があります。彼もNikhilと同じ7年前にCloudWatchに参加しました。チームと密接に協力して、AWSのお客様と内部のAmazonチームが前例のない規模で使用できる機能を構築することを楽しんでいます。
1.2. AWSにおける運用経験と背景
私たちはAWSにおいて長年にわたり運用の経験を積んできました。私、Mihir Patelは、Amazonに約15年前にインターンとして入社し、Amazonのスケールでの運用について学ぶ素晴らしい機会を得ました。夜中にページングを受けたり、ピークイベント中に対応したりといった経験から、長年にわたって私のチームと共に多くのAWSサービスを構築・リードしてきました。私たちのチームは、何百万ものAWSカスタマーに価値を提供するために日々熱心に取り組んでいます。
Nikhil Dewanは、様々な業界での運用重視の役割から始まり、エネルギースタートアップのために3大陸にわたる地質学者、掘削者、役員のニーズに対応するプライベートクラウドを構築する任務を与えられた際に、クラウド監視への取り組みが始まりました。
Jared Nanceもまた、製造業やヘルスケア業界などの企業でドメイン固有の監視ソリューションを構築した経験があります。Nikhilと同じ日に約7年前にCloudWatchチームに加わりました。彼もNikhilと同様に、AWSのお客様や内部のAmazonチームと密接に協力して、前例のない規模で使用できる機能を構築することを楽しんでいます。
私たちの運用経験は、今日お話しするAIを活用した運用について、実践的で価値のある視点を提供しています。AIについての過大な約束ではなく、実際の運用課題を解決する実用的な機能に焦点を当てています。
2. AIOpsの進化
2.1. 運用における課題
今日は、AIが運用上の課題にどのように役立つかをお見せします。しかし、それだけではありません。AIは車の運転や朝食の準備、洗濯物のたたみ方など、なんでも手伝ってくれるのではないでしょうか？冗談です。このような大げさなAIの宣伝には、皆さんもうんざりしていることでしょう。
AIは魔法ではありませんが、いくつかの限界はあるものの、非常に強力なツールです。今日は、AIが運用のトラブルシューティング体験をどのように助けるかを探っていきます。まだ朝食は作ってくれないかもしれませんが、運用におけるAIの実際のアプリケーションは非常に有望であることをお約束します。AWSで構築している実用的な機能をご紹介し、運用を簡素化し合理化する方法を見ていきましょう。
運用チームが日々直面している課題は、数え切れないほどあります。数多くの運用問題に対応するために無数の時間を費やしていませんか？もっと革新に時間を割きたいと思いませんか？特に、夜中の2時にアラームでページングを受けると、冷静さを保ち、適切な判断をすることが本当に難しくなります。
大規模なアプリケーションを運用する顧客からは、問題をトリアージするための適切なデータがないことや、すべてのシグナルを組み合わせて根本原因を特定することの難しさについて頻繁に聞いています。アラームやツールの疲労も一般的な問題で、関連するアラームを見分けるのが困難なケースが多いのです。
2.2. AIOpsの定義と進化段階
AIOpsという用語はしばらく前から存在していました。お客様との会話の中で、私は異なる人々にとって異なる意味を持つことに気づきました。そのため、この議論を始めるにあたり、AIOpsの予想される進化について説明し、業界が現在どこにいるのかを正直に伝えることが非常に重要だと思います。
AIOpsの概念は、確かな進化の過程を経ています。お客様と話すと、AIOpsという言葉が人によって異なる解釈をされていることがわかります。そのため、業界の現状について正直に説明し、AIOpsの進化の予想される道筋を共有することが重要です。
現在、業界はAIをインシデント管理に活用する初期段階にあります。ルールベース、機械学習、AI、そして現在は生成AIなど、さまざまな技術を組み合わせて、動的なインシデント相関、根本原因分析、修復提案を行っています。
これからの段階として、業界が向かうと予想されるのは予測的インサイトです。これにより、お客様は将来の障害やキャパシティのニーズを予測できるようになります。例えば、メモリやディスクのリークを検出し、対策を講じなければ数時間後に問題が発生することを事前に通知することができます。
自己修復を行う完全自動化システムという聖杯のような約束もありますが、もしそこに至るとしても、それは旅であり時間がかかるでしょう。
2.3. ルールベースシステムから機械学習へ
すべてはルールベースのシステムから始まりました。これらのシステムは通常、エラー率が低く、非常に正確です。例えば、AWS ConfigやTrusted Advisorには、自動化をトリガーするルールベースシステムがあります。
その後、異常検出技術に機械学習を統合し始めました。機械学習モデルは確実性を与えるわけではありません。確率を与えるのです。計算機というよりは天気予報士のように考えてください。これらの技術はどちらもしばらく前から存在し、お客様から大きな支持を得ています。
ルールベースシステムは、その正確性と低いエラー率で知られています。AWS ConfigやTrusted Advisorなどのサービスでは、ルールベースシステムが自動化をトリガーする仕組みを提供しています。このようなシステムは特定の条件に基づいて動作し、非常に明確な結果を生み出します。
一方、機械学習を取り入れた異常検出手法は、違った特性を持っています。機械学習モデルは確実な答えではなく、確率を提供します。これは計算機よりも天気予報士に近い性質を持っていると考えてください。完全な確実性はないものの、可能性の高い予測を提供できるのです。
これらの両方のアプローチは長年にわたり開発され、多くのお客様から採用されてきました。ルールベースシステムの明確さと機械学習の柔軟性は、それぞれ異なる状況で価値を発揮します。私たちの目標は、これらの技術を効果的に組み合わせ、お客様の運用をより効率的にサポートすることです。
2.4. AIを活用したインシデント管理
私たちの業界は現在、インシデント管理にAIを活用する初期段階にあります。これには、ルールベース、機械学習、AI、そして今では生成AIなど、様々な技術のアンサンブルを使用して、動的なインシデント相関、根本原因分析、修復提案を行うことが含まれています。
この段階では、複数の技術アプローチを組み合わせることで、より強力なインシデント管理が可能になります。ルールベースシステムの確実性、機械学習の確率的洞察、そしてAIと生成AIの適応性と文脈理解を組み合わせることで、以前は不可能だった方法でインシデントを処理できるようになります。
例えば、AIは複数のデータソースからのシグナルを相関付け、パターンを識別し、根本原因をより迅速に特定することができます。また、過去の同様のインシデントや業界のベストプラクティスに基づいて修復提案を生成することもできます。これにより、運用チームはより迅速かつ効果的に問題を解決できるようになります。
インシデント管理におけるAIの活用は、単なる自動化以上のものです。それは運用チームに対して、より高度な洞察、コンテキスト認識、そして最終的にはより効果的な解決策を提供する、より知的なアプローチなのです。
2.5. 予測的インサイトと自己修復システムの展望
私たちが業界として次に向かうと予想される段階は、予測的インサイトです。これはお客様が将来の障害やキャパシティのニーズを予測するのに役立ちます。良い例としては、メモリやディスクのリークを検出し、対策を講じなければ数時間後に問題が発生することを事前に通知する能力があります。
この予測的アプローチにより、運用チームは問題が実際にサービスに影響を与える前に対処することができます。これは単に問題に反応するのではなく、潜在的な問題を予測し防止するという大きなパラダイムシフトを表しています。例えば、メモリリークやディスクの使用率の増加パターンを検出し、それが重大な障害につながる前に警告することができます。
また、聖杯とも言える完全に自動化された自己修復システムの約束もあります。しかし、そこに到達するまでには長い道のりがあり、そこに到達できるとしても時間がかかるでしょう。これは単なる技術的な課題ではなく、信頼性、ガバナンス、コンプライアンスに関する複雑な問題も含んでいます。
自己修復システムは魅力的な目標ですが、私たちはまず予測的能力の向上に焦点を当て、運用チームがより効率的かつ効果的に働けるようにすることが重要です。AIは魔法ではありませんが、適切に適用することで、運用の未来を形作る強力なツールとなるのです。
3. 既存のCloudWatch AIOps機能
3.1. パターン分析機能（Pattern Analytics）
このコンセプトをさらに説明するために、レゴブロックのメタファーを考えてみましょう。私は二人の男の子の誇り高い親で、彼らは本当にレゴが大好きです。妻と私は彼らが遊んだ後に片付けるよう最善を尽くしていますが、残念ながら、翌日には散らかった状態から始まることになります。
息子たちが特定の色や形のブロックを見つけるのを手伝ってほしいと頼んできたとき、私たちは途方に暮れてしまいます。このような時、魔法の杖があって、ブロックを色ごとに素早く仕分けて並べられたらいいのにと思います。
実は、CloudWatchのログではすでにそれができるのです。昨年のre:Inventで、パターン分析と呼ばれるこの機能をローンチしました。何十万ものお客様がこれを使用しており、ログとのやり取り方法が変わったと言っています。
現在、クエリを実行するたびに、ログクエリ結果内の主要なパターンを自動的に表示します。ブロックを色ごとに整理するのと同様に、この機能は何千ものログエントリを、調査を開始するのに役立ついくつかの重要なパターンに集約するのに役立ちます。
例えば、このクエリでは、ログにいくつかの主要なパターンがあることがわかります。また、それらがどのくらいの頻度で発生するかも示しています。「エラー」という単語が含まれるパターンは、調査を始めるのに最適な出発点となるでしょう。
これは素晴らしいことです。今や、簡単に区別できるいくつかのパターンに基づいて、ブロックが整然と整理されています。この機能により、大量のログデータを迅速に理解し、重要なパターンを識別することが可能になり、トラブルシューティングプロセスが大幅に効率化されました。
3.2. 比較モード（Compare Mode）
何かが変わったときに通知されたら素晴らしいと思いませんか？部屋を1時間ほど離れて、戻ってきたら子供たちがなんとか新しいブロックのセットを手に入れていたとします。理想的な世界では、まるでMarie Kondo自身が突然訪問したかのように、それらのブロックが自分のバスケットにきちんと整理されているでしょう。残念ながら、私の子供たちは「片付けの魔法」のメモを完全に見逃しています。
しかし良いニュースがあります。子供のおもちゃの爆発をMarie Kondoのように整理することはできませんが、CloudWatchではクラウドデータの整理と理解の手助けが得意なのです。
これは、CloudWatchですでに利用可能な2つ目の素晴らしいML機能である比較モードについてです。このスナップショットを見ると、ログに新しいパターンが現れ、それがどのくらいの頻度で発生しているかがわかります。これもまた、何が変わったのかを判断するための調査を始めるのに最適な場所になるでしょう。
画面の下部には、2つの期間にわたって特定のパターンの傾向を視覚的に比較できる非常に優れたヒストグラムがあります。このように、CloudWatchの比較モードを使用すると、「何が変わったのか？」という重要な質問に答えるのに役立ちます。アプリケーションが昨日は正常だったのに、今日は何かがおかしいとき、比較モードを使用して変更点を特定できます。
これらの2つの機能を構築する中で、機能を組み合わせてプロセスを自動化できないかと考えるようになりました。手動入力なしに異常なアイテムをフィルタリングする果物の選別機のようなものを想像してみてください。ログデータにも同じことができないかと考えました。
3.3. 常時オンのログ異常検出
これで、CloudWatchで利用できる3つ目のML機能、常時オンのログ異常検出に話を進めます。始めるのは本当に簡単です。このロググループでこの機能を有効にするだけです。その後、CloudWatchは常に入ってくるログを評価し、履歴ベースラインと比較して、アプリケーションで発生している問題を示す異常な傾向が通知されます。
このスナップショットを見ると、主要な傾向、主要なパターン、優先レベルや最後の検出時間など、より深く掘り下げるための他の重要な詳細を含むログ異常ビューが表示されています。
これは、前述した2つの機能を組み合わせて自動化したものです。果物の選別機が手動入力なしに異常なアイテムをフィルタリングするように、常時オンのログ異常検出はログデータに対して同じことを行います。
ロググループでこの機能を有効にすると、CloudWatchは常にあなたの受信ログを評価し、履歴ベースラインと比較して、アプリケーションで発生している問題を指摘する異常な傾向について通知を受けることができます。
要約すると、今日のCloudWatchには既にいくつかの非常に優れたコアAIOps機能が組み込まれています。第一に、調査を支援するために重要なパターンにログをクラスター化するパターンモード。第二に、「何が変わったのか？」という重要な質問に答えるのに役立つ比較モード。アプリケーションは昨日は正常だったのに、今日は何かがおかしい。何が変わったのか？そして最後に、常時オンの異常検出は、受信ログを自動的に分析し、発生している問題について事前に通知します。
これらの例はすべてログに焦点を当てていますが、メトリクスなどの他のテレメトリタイプでも同様の異常検出機能が利用可能です。これらのAIOps機能や長年にわたって構築してきた機能強化をまだチェックしていない場合は、このセッションの直後が試してみるのに最適な時間です。
3.4. 自然言語クエリ生成
CloudWatchで提供しているもう一つのAIOps機能は、ログとメトリクスインサイトクエリ用の自然言語クエリ生成です。この機能は今年初めにリリースし、お客様に広く採用されています。
私たちは、クエリツールがテレメトリへの高速でインタラクティブなドリルダウンをサポートする能力を皆さんが評価していることを知っていますが、クエリ構文に慣れるには時間とドメイン知識が必要であることも認識しています。
このリリースにより、ログとメトリクス分析機能の使用を非常に簡単に始められるようになりました。自然言語で質問するだけで、実行するクエリを生成します。さらに、生成されたクエリの行ごとの説明も提供しているので、構文の学習に役立ちます。
最後に、自然言語プロンプトを使用して、反復的な詳細分析のために既存のクエリを簡単に修正することができます。そして、今説明したこれらの機能セットの素晴らしい点は、追加コストなしで使用できることです。
この自然言語クエリ機能は、CloudWatchの学習曲線を大幅に短縮し、技術的な専門知識に関係なく、より多くのチームメンバーがデータから洞察を得られるようにします。単に質問を入力するだけで、適切なクエリが生成され、そのクエリの構造と目的を理解するための説明も提供されます。
このように、CloudWatchのコアAIOps機能は過去12ヶ月で大きな人気を得ており、お客様の運用をより効率的かつ効果的にするのに役立っています。追加コストなしでこれらの機能を活用できることは、すべてのCloudWatchユーザーにとって大きな利点です。
4. 大規模運用の課題
4.1. データ収集と分析の複雑さ
大規模なアプリケーションや運用を持つお客様から聞いた課題について簡単にご説明します。彼らは問題をトリアージするための適切なデータがしばしば不足しています。そして、適切なデータがあったとしても、すべてのシグナルを一緒に集めて理解し、根本原因にたどり着くことは難しいことがよくあります。
例えば、アプリケーションに問題が発生したとき、適切な診断データを収集することは非常に困難です。ログ、メトリクス、トレース、構成変更など、様々なデータソースが存在し、それらを適切に集めて関連付けることは容易ではありません。さらに、データ量が膨大であるため、どの情報が実際に重要なのかを特定することも困難です。
また、データがあっても、根本原因を特定するために必要なすべての情報を一か所に集めることは複雑な作業です。異なるサービスやコンポーネントからのデータを相関付け、時系列で整理し、パターンを識別する必要があります。これらのデータを意味のある形で表示し、迅速な分析を可能にすることは、大規模な環境では特に難しい課題です。
お客様は、問題が発生したときにデータをすばやく収集し分析できるツールを求めていますが、多くの場合、データの断片化や不完全なテレメトリにより、初期の調査が遅れたり、誤った方向に進んだりすることがあります。これは特に大規模で複雑なシステムにおいて顕著な問題です。
4.2. アラームと監視ツールの疲労
お客様はしばしばアラームとツールの疲労を感じています。多くの場合、互いに関連している可能性のあるアラームが発生しますが、どのアラームがお互いに接続されているかを把握するのは困難です。
例えば、一つのコンポーネントに問題が発生すると、依存関係のある複数のサービスやシステムでもアラームが発生することがあります。これにより、実際には同じ根本原因に起因する多数のアラートが生成され、運用チームはそれらの関連性を理解するのに苦労します。
アラーム疲労は、過剰なアラートにより運用者が重要なシグナルを見逃したり、アラートへの対応に時間がかかりすぎたりする状況を引き起こす可能性があります。特に大規模なシステムでは、何百、何千もの監視対象がある場合、どのアラームが重要であり、どれが相互に関連しているかを判断することは困難です。
また、お客様は今日、多くのツールを使用しており、理想的には洞察とデータを一か所で得て、根本原因に迅速にたどり着けるようにしたいと考えています。複数のダッシュボード、ログ分析ツール、メトリクスプラットフォーム間を行き来することで、問題解決の時間が長くなり、運用チームのフラストレーションが高まります。
これらの課題により、運用チームは効率的にアラートを処理し、真の問題に集中することが難しくなっています。アラームの統合、相関関係の自動識別、単一のビューでの関連データの提示など、これらの課題に対処するソリューションが必要とされています。
4.3. 異なるシグナルの相関付け
お客様からは、メトリクス、ログ、トレース、AWS健全性通知など、さまざまなシグナルを相関付けることが困難であるという声も聞かれます。また、デプロイなどの異なるイベントとの相関付けも課題となっています。
例えば、あるサービスで可用性の低下が観測された場合、その根本原因を特定するためには、そのサービスのメトリクスだけでなく、関連するログエントリ、分散トレースデータ、依存するサービスの状態、AWS健全性通知、最近のデプロイや構成変更などのイベントなど、多様なシグナルを分析する必要があります。
これらの異なるデータタイプは、多くの場合、異なるツールやダッシュボードに分散しており、それらを手動で相関付けるのは時間がかかり、エラーが発生しやすいプロセスです。特に、大規模な分散システムでは、問題がどこで発生しているかを正確に特定するために、これらすべてのシグナルを時系列で整理して理解する必要があります。
また、デプロイや構成変更などのイベントは、システムの動作に大きな影響を与えることがありますが、これらのイベントを自動的に監視データと関連付ける機能がないと、問題の原因が最近の変更にあるのかどうかを判断するのが難しくなります。
お客様は、すべてのシグナルを単一の場所で表示し、それらの関係を自動的に識別して分析できるツールを必要としています。これにより、問題の診断と根本原因の特定のプロセスが大幅に効率化され、解決までの時間が短縮されます。
4.4. 根本原因特定と最適な修正方法の決定
お客様は根本原因にたどり着いた後でも、根本原因を修正するための最善または最適な方法を見つけたいと考えており、理想的には将来再び発生することを防ぎたいと思っています。
例えば、DynamoDBテーブルでスロットリングが発生しているという根本原因を特定した後、いくつかの異なる解決策を検討することができます。プロビジョニングされたスループットを増やすのか、オンデマンドモードに切り替えるのか、あるいは自動スケーリングを有効にするのか。それぞれのアプローチには長所と短所があり、状況に応じて最適な選択は異なります。
また、同様の問題が将来再発しないようにするには、一時的な修正だけでなく、より永続的な解決策が必要かもしれません。これには、アプリケーションのアーキテクチャの変更、より効果的な監視メカニズムの実装、あるいは運用プロセスの改善などが含まれる可能性があります。
そして、冗談ではありませんが、深夜2時にページングを受けたときに冷静さと冷静さを保つことは難しいものです。私のことはわかりませんが、深夜2時にページングを受けると、私はこのようになります（スライドを指して）。このスライドは、運用担当者が今日、運用上の問題の根本原因を突き止めるために取らなければならない多くのステップを示しています。
このワークフローは見覚えがありますか？はい、操作者が試行錯誤のアプローチを取り、多くの異なるシグナルを通して問題を識別し、その後修正するためにふるいにかける必要があることが多いのです。この複雑なプロセスを簡素化し、運用者により明確なガイダンスと推奨事項を提供することで、問題解決の時間を短縮し、より効果的な解決策を実装することができます。
5. Amazon Q Developer運用調査機能の紹介
5.1. 自動分析と調査機能
Amazonでは、コードを1行も書く前に、製品の完全な要件を理解しようとしています。私たちはこれをバックワードワーキングプロセスと呼んでいます。そのため、LLM技術が約12〜18ヶ月前に前面に出てきたとき、私たちはバックワードワーキングを行うための旅に出発し、AIOps体験からの理想的なカスタマーエクスペリエンスと要件を決定しました。
このスライドでは、自動インストルメンテーションとデータ収集から、アラートの検出と優先順位付け、ガイド付き根本原因分析と運用トラブルシューティング体験の提供、推奨アクションの提供、そして継続的な学習と進化、サービスの運用方法の改善まで、大規模なアプリケーションの運用に関するいくつかのテーマについて簡単に説明しています。
この1年間、私たちのチームはこれらのコア要件を提供するために懸命に取り組んできました。そして本日、Amazon Q Developer運用調査のプレビュー版のローンチを発表できることを非常に嬉しく思います。この機能は、問題検出からトリアージ、修復まで、ガイド付きの運用トラブルシューティング体験を提供します。
Amazon Q Developerは、運用トラブルシューティングプロセスを加速し、問題を迅速に診断して解決するための強力なAIアシスタントとして機能します。それは様々なテレメトリシグナルを自動的に分析し、問題の根本原因を特定し、それを修正するための推奨事項を提供します。
アラームに応答して自動的に調査を開始することもできますし、AWS Qチャットエクスペリエンスやその他80以上のAWSコンソールから関与することもできます。また、AWSコンソールのAmazon CloudWatchで調査するための共同作業体験も提供します。これにより、運用チームは複数のツールやダッシュボードを行き来することなく、根本原因にすばやくたどり着くことができます。
5.2. テレメトリシグナルの統合
Amazon Q Developer運用調査機能は、様々なテレメトリシグナルを自動的に分析します。これには、CloudWatchテレメトリ、CloudTrailログ、デプロイ情報、リソース構成への変更、さまざまなAWS健全性イベントなどが含まれます。
この機能の重要な点は、これらの異なるデータソースを統合し、それらの間の相関関係を自動的に識別する能力です。例えば、CloudWatchのメトリクスに異常が検出された場合、システムはそのタイミングに関連するデプロイイベント、構成変更、関連するログエントリを調べ、潜在的な根本原因を特定することができます。
CloudWatchテレメトリには、メトリクス、ログ、トレースなどのデータが含まれており、これらは問題の診断に不可欠です。CloudTrailログは、AWS環境内のAPI呼び出しと管理イベントの記録を提供し、誰が何をいつ変更したかを理解するのに役立ちます。デプロイ情報は、コード変更がいつ実装されたかを示し、問題が最近のデプロイに関連しているかどうかを特定するのに役立ちます。
リソース構成の変更は、インフラストラクチャやアプリケーション設定の変更を追跡し、これらが障害の原因となっているかどうかを判断するのに役立ちます。AWS健全性イベントは、AWSサービス自体に影響する問題に関する情報を提供します。
これらのすべてのシグナルを統合することで、Amazon Q Developerは問題の全体像を構築し、根本原因を正確に特定しやすくなります。以前は、これらのデータポイントをすべて手動で関連付ける必要があり、時間がかかり、重要な関係を見逃す可能性がありました。Amazon Qのテレメトリシグナル統合により、このプロセスが自動化され、運用チームが問題をより迅速かつ正確に診断できるようになります。
5.3. アラーム連携と調査開始の仕組み
Amazon Q Developer運用調査機能は、アラームに応答して自動的に調査を開始することができます。これは、重要な運用アラートが発生した瞬間から、調査プロセスが自動的に開始されることを意味します。
アラームが発生すると、Amazon Qはそれを調査アクションのトリガーとして使用し、自動的に調査を作成します。例えば、アプリケーションの可用性が低下したことを示すアラームが発生した場合、Amazon Qはその情報を使用して新しい調査を開始し、関連するテレメトリデータの分析を始めます。
これはアラームの履歴に表示され、Amazon Qが既にその問題に取り組んでいることを確認できます。このように、運用チームがアラートに対応してログインする前に、AIは既に問題の分析を始めており、貴重な時間を節約します。
この自動調査開始機能に加えて、AWS Qチャット体験からも調査を開始することができます。例えば、「なぜページングされたのか？」と尋ねると、調査プロセスが開始され、次のステップについてガイドされます。これにより、チャットインターフェースを通じて問題を調査する柔軟性が提供されます。
さらに、Amazon Qは80以上のAWSサービスコンソール全体に統合されており、どこからでも調査を開始できます。例えば、ダッシュボード上のメトリクスの異常なスパイクを見つけた場合、そこから直接調査を開始することができます。
そして最も重要なのは、AWSコンソール内のAmazon CloudWatchでの調査のための協調的な体験を提供することです。これにより、チームメンバーが同じ調査に協力し、発見事項や洞察を共有することができます。この共同作業的なアプローチにより、問題解決がより効率的になり、根本原因にたどり着く時間が短縮されます。
6. デモ：ペットクリニックアプリケーションの障害対応
6.1. サンプルアプリケーションのアーキテクチャ説明
デモの前に、まず私が管理しているサンプルアプリケーションとその状況についてお話ししましょう。このストーリーでは、獣医クリニックが予約、ペット履歴、およびこれらのオフィスが必要とする一般的な機能を管理できるようにするサービスプラットフォームを管理しています。
これはマルチテナントアプリケーションで、私のサービスがいつでも複数の獣医クリニックのリクエストを処理していることを意味します。画面には、クリニックポータルが表示されています。これは私の顧客であるクリニックが日常的に使用するUIです。彼らはサインインして、顧客のリスト、ペット情報を閲覧し、予約を作成することができます。
予約訪問は、クリニックビジネスの中核的な操作であり、サービスプロバイダーとして、私が利用可能に保つ必要がある不可欠な操作です。
このサービスの舞台裏と、対応することになるインシデントを見てみましょう。顧客がペットクリニックサイトを訪問すると、そのリクエストはALBに行き、そこからフロントエンドサービスを実行しているEKSにルーティングされます。
そのサービスは認証、認可、検証を処理し、特定の操作を処理する責任を持つバックエンドマイクロサービスにリクエストをルーティングします。これらはすべてEKS上で実行されるJava Springウェブアプリケーションサービスであり、それぞれに独自の依存関係（ストレージ、メッセージング、または決済処理システムなどのサードパーティサービス）があります。
これらのサービスがすべて連携して、先ほど説明したユーザー体験を提供しています。そして、これはマルチテナントサービスであることを忘れないでください。各テナントは個々のクリニックであり、これらのサービスはすべていつでも複数のクリニックからのリクエストを処理しています。
この分散アーキテクチャは、複雑さを区画化し、各コンポーネントが独立してデプロイおよびスケーリングできるなど、いくつかの理由で優れています。しかし、サービス指向アーキテクチャがもたらすすべての利点がある一方で、監視と可観測性に関して追加の課題もあります。可観測性データまたはテレメトリが散らばっていたり、1つのコンポーネントの問題が多くのコンポーネントに影響を与えたりして、システム内に多くのノイズを生成し、問題の局所化を困難にする可能性があります。
6.2. 多テナント環境でのトラブルシューティング
私たちの顧客の予約訪問のデータフローをより詳しく見て、インシデントにつながるイベントのシーケンスを確認していきましょう。顧客が訪問を予約するたびに、そのリクエストは私たちのフロントエンドサービスに行きます。そのサービスは訪問サービスにリクエストをルーティングし、訪問サービスはDynamoDBテーブルに訪問を記録する責任があります。
今日は、何か異常なことが起こります。私たちのクリニックの1つが予約訪問のリクエストを大量に送信し始めるのです。おそらく彼らの側に技術的な問題があるか、多くの動物に影響を与える流行病があるのかもしれません。それが起こると、私のDynamoテーブルは訪問サービスのスロットリングを開始し、テーブルに割り当てられた容量を超えたため、リクエストを積極的に制限しています。
具体的には、この場合、書き込みトラフィックをスロットリングするため、読み取り操作は引き続き成功します。このバックプレッシャーによって、フロントエンドサービスのレイテンシーが増加し、最終的にこれらのリクエストは失敗し始めます。そして今、複数のクリニックにわたって、飼い主たちは医療ケアを必要とするペットのために緊急の訪問をスケジュールするのに苦労しています。
例えば、土曜の朝、ペットの飼い主が自分の犬が食べていないことに気づいたとします。彼らはペットのために緊急の訪問を予約しようとしていますが、リクエストは失敗し続けています。リクエストはただ停滞し、最終的に失敗します。これが私たちのシステムの可用性の実際の影響であり、飼い主は他のプロバイダーからケアを求める可能性があります。
クリニックは、予約できなかった特定の訪問から直接収益を失います。これはすべて私のビジネスに影響を与え、顧客が私たちのサービス提供能力に対して持つ信頼を浸食します。
おそらくこの状況やその一部は皆さんにも馴染みがあるでしょう。これには私が個人的に過去に何度も直面した問題と共通の要素があります。バックプレッシャーが複数のコンポーネントに影響を与える分散システムがあります。1つの顧客やデバイスが障害の原因となるトップコントリビューター問題があります。言うまでもなく、これは自分が見つける楽しい状況ではありません。
それでは、私の運用担当者の帽子をかぶって、フロントエンドサービスのアラームにページングされたと想定してみましょう。この時点で、私が知っているのは、予約訪問の可用性に影響があることと、その操作の重要性とサービスをオンラインに戻すことがいかに重要かを理解しているということだけです。
6.3. DynamoDBのスロットリング問題シナリオ
この問題を診断するには、少なくとも4つのことを理解する必要があります。まず、フロントエンドが訪問サービスへのリクエスト失敗のためにエラーを経験していることを理解する必要があります。また、訪問サービスがDynamoテーブルのリクエストスロットリングのために影響を受けていることも理解する必要があります。
さらに、DynamoDBがどのように容量を管理しているのか、リソースの構成、そして実際にテーブルに対してプロビジョニングしたよりも多くのIOPSを消費しているためにリクエストをスロットリングしていることについても理解が必要です。最後に、負荷の増加が単一のクリニックからきていることを理解する必要があります。
必要なすべての情報は散らばっています。異なる場所にあり、どこに行き、どのツールを使用するかを覚えておく必要があります。これにはすべて多くの時間がかかる可能性があり、時間がかかればかかるほど、サービスをオンラインに戻すプレッシャーが高まります。
しかし、大丈夫です。私はすでにAmazon Q Developerがこれを自動的にトラブルシューティングするように設定しています。では、代わりにどのような体験ができるか見てみましょう。
現在表示している画面は、私のサービスのAPIの一つの可用性低下によってトリガーされたCloudWatchアラームです。アラーム履歴に行くと、Amazon Qがすでにこの問題の調査を作成するアクションがあることがわかります。
その調査を見てみましょう。今表示しているのはAmazon Q Developer調査体験です。中央に、調査に追加されたすべての発見事項を示すパネルがあります。これらの発見事項は、調査を進めながら収集し、証拠を構築できる調査に関する事実と考えることができます。
AWSコンソール全体を移動して、メトリクス、ログ、その他の観察結果を80以上のAWSサービスコンソールから調査に収集することができます。現在、調査中のアラームである1つの発見事項しかないことがわかります。
上部には、Amazon Qが現在何をしているかを示すステータスがあります。実際には、ログインする前に分析が完了していました。本当に面白い部分がここにあります。「提案」をクリックすると、サイドパネルが開き、レビューできるAmazon Qからの保留中の提案が表示されます。
Amazon Qは、並行してデータを見ているペア操作者のように考えることができ、興味深いかもしれないことを提案します。Amazon Qが観察を行うと、提案フィードを通じてそれを共有します。インシデントについてより多くの観察を行うにつれて、これらのシグナルを組み合わせて根本原因の仮説を生成します。
6.4. Amazon Qによる自動調査と根本原因分析
ここでフィルターを適用して、中間的な観察結果だけを表示してみましょう。ここでは、いくつかのメトリクスが見えます。SNSメトリクス、EC2メトリクス、インスタンスでの書き込みバイト増加などがあります。また、いくつかのカナリアテストが失敗していることも分かります。これの本当に興味深くて優れている点は、私が数十のダッシュボードを探す代わりに、Amazon Qがその重労働を私のために行っていることです。
インシデントに対して自分を方向付けようとしているとき、私はデータを自分で探す必要がなく、増加した並列処理と自動化の恩恵を受けています。単一のフィードで、調査に関連するかもしれないメトリクス、ログ、トレース、変更イベントが表示されます。
提案が気に入れば、それを受け入れてフィードに追加できます。提案が気に入らなければ、フィードから削除するために破棄することもできます。しかし、これらのメトリクスが何を意味するのかわからない場合はどうでしょうか？実際、提供されるメトリクスのツールチップをクリックして、既にこれらのメトリクスが何を意味するのか知らない場合に、Amazon Qにインラインで尋ねることができます。これにより、ドキュメントを探して、これらのシグナルが何を意味するのかを理解する必要なく、インラインでの説明が得られます。
2番目のタイプの提案は仮説です。ここでフィルターを適用して、それを見てみましょう。ここでは、Amazon Qが、Dynamoテーブルが書き込みリクエストの増加を経験し、それがスロットリングと増加したレイテンシーにつながったという仮説を生成したことがわかります。それはシステムへの影響を説明しており、訪問サービスとフロントエンドサービスへの影響を述べています。
さらに、特定の顧客が増加した負荷の主要な貢献者として特定されており、ホットパーティションまたはホットキーの問題がある可能性も示唆しています。また、他に取るべきステップがある場合のために、さらなるトラブルシューティングのための次のステップも提供しています。
私はこの調査に新しく加わったところですので、この仮説につながった具体的な証拠を見たいと思います。そのためには、「推論を表示」リンクをクリックすると、Amazon Qがこの仮説に選択した具体的な証拠が表示されます。
ここでは、Dynamoからのスロットリングされたリクエストが見えます。また、個々の顧客を識別するContributor Insightsルールも見ることができます。実は、Contributor Insightsをご存知の方はいらっしゃいますか？それほど多くないですね。でも大丈夫です。Amazon Qは、あなたがそれらを知らなくても、または使用するタイミングを知らなくても、CloudWatchの持つこれらの機能を活用することができます。
これはかなり良い仮説だと思いますので、この仮説を受け入れて調査に追加しましょう。仮説を受け入れ、問題を正常に診断したところで、まだ問題を緩和し、取るべき正しいアクションについて考える必要があります。
緩和策としては複数の選択肢が考えられることは珍しくありません。この場合、いくつかの選択肢を検討できます。テーブルのプロビジョニングされたスループットを増やすことを考えるか、オンデマンドに切り替えるか、または自動スケーリングを有効にするか。しかし、右の自動スケーリング設定について考える時間を取りたくないため、この状況ではそうしたくないかもしれません。
顧客をスロットリングする方法があれば、それも検討するかもしれません。この特定のケースでは、何が負荷を引き起こしているのかわかりません。彼らの側の問題なのか、トラフィックが正当なものなのかわかりません。そのため、この状況からできるだけ早く抜け出したいと思っています。
ここで、Amazon Qがこの仮説に対して既にいくつかのアクションを特定し、この問題に対応するためにAWS管理ランブックを推奨していることがわかります。また、この場合のDynamoDBと容量管理方法に関するドキュメント記事も紹介されています。
7. Amazon Q Developerの調査フロー
7.1. 調査グループと調査フィードの使い方
現在表示しているのはAmazon Q Developer調査体験です。中央には、調査に追加されたすべての発見事項を示すパネルがあります。これらの発見事項は、調査を進めながら収集し、証拠を構築できる事実と考えることができます。AWSコンソール全体を移動して、メトリクス、ログ、その他の観察結果を80以上のAWSサービスコンソールから調査に収集することができます。
現在、調査中のアラームである1つの発見事項しか表示されていないことがわかります。上部には、Amazon Qが現在何をしているかを示すステータスがあります。実際には、私がログインする前に分析が完了していました。
最も重要な機能は「提案」ボタンです。これをクリックすると、サイドパネルが開き、レビューできるAmazon Qからの保留中の提案が表示されます。Amazon Qは、並行してデータを見ているペア操作者のように考えることができ、あなたに興味深いかもしれないことを提案します。
Amazon Qが観察を行うと、それを提案フィードを通じて共有します。インシデントについてより多くの観察を行うにつれて、これらのシグナルを組み合わせて根本原因の仮説を作成します。これにより、問題の調査に取り組む際、複数のダッシュボードやコンソールを行ったり来たりする必要がなくなります。
調査を開始すると、調査グループに関連付けられます。調査グループは、権限、暗号化設定、保持期間、Slackなどのサードパーティ統合など、共通の構成を持つ調査のコンテナとして機能します。この構造により、チームメンバーは共同で調査に参加し、発見事項を共有し、洞察を共同で開発することができます。
調査フィードは、時系列で整理された調査に関するすべてのアクティビティの記録として機能します。これには、検出されたアラーム、Amazon Qからの提案と観察結果、チームメンバーが追加した発見事項、実行されたアクション、およびその結果が含まれます。このフィードは、問題の診断と解決のための共有コンテキストを提供し、調査中および将来のインシデントの両方で知識共有を促進します。
7.2. Amazon Qによる提案と観察の活用
ここでフィルターを適用して、中間的な観察結果だけを表示してみましょう。いくつかのメトリクスが見えます。SNSメトリクス、いくつかのEC2メトリクス、インスタンスでの書き込みバイトの増加などがあります。また、いくつかのカナリアテストが失敗していることも分かります。これの本当に興味深くて素晴らしい点は、私が数十のダッシュボードを探す代わりに、Amazon Qがその重労働を私のために行っていることです。
インシデントに自分を方向付けようとしている際に、私はデータを自分で探す必要がなく、増加した並列処理と自動化の恩恵を受けています。単一のフィードで、調査に関連するかもしれないメトリクス、ログ、トレース、変更イベントが表示されます。
提案が気に入れば、それを受け入れてフィードに追加できます。提案が気に入らなければ、フィードから削除するために破棄することもできます。しかし、これらのメトリクスが何を意味するのかわからない場合はどうでしょうか？実際、提供されるメトリクスのツールチップをクリックして、既にこれらのメトリクスが何を意味するのか知らない場合に、Amazon Qにインラインで尋ねることができます。これにより、ドキュメントを探して、これらのシグナルが何を意味するのかを理解する必要なく、インラインでの説明が得られます。
Amazon Qの提案と観察結果は、運用担当者の生産性を大幅に向上させます。数十のダッシュボード、ログクエリ、サービスコンソールを手動で探索する代わりに、Amazon Qが並行して分析を実行し、関連する観察結果をすぐに利用できるようにします。これにより、問題の診断と解決に費やす時間が大幅に短縮されます。
さらに、提案を評価し、関連するものを保持して関連性の低いものを破棄する機能により、調査プロセスがよりきめ細かく、コンテキストに応じたものになります。インラインでメトリクスの意味を説明する機能は特に貴重で、特にオンコール担当者が普段使い慣れていないシステムやメトリクスを扱う場合に役立ちます。
Amazon Qの提案システムは、単にシグナルを表示するだけでなく、それらを文脈化し、意味を説明し、関連性を強調することで、運用担当者がより迅速かつ効果的に問題を理解して対応できるようにします。
7.3. 仮説の検証と受け入れプロセス
2番目のタイプの提案は仮説です。フィルターを適用して、それを見てみましょう。ここでは、Amazon Qが生成した仮説が表示されています。この仮説によると、Dynamoテーブルが書き込みリクエストの増加を経験し、それがスロットリングと増加したレイテンシーにつながったとされています。システムへの影響が説明されており、訪問サービスとフロントエンドサービスが影響を受けていることが述べられています。
さらに、特定の顧客が増加した負荷の主要な貢献者として特定されており、ホットパーティションまたはホットキーの問題がある可能性も示唆しています。また、他に取るべきステップがある場合のために、さらなるトラブルシューティングのための次のステップも提供されています。
私はこの調査に新しく加わったところなので、この仮説につながった具体的な証拠を見たいと思います。そのためには、「推論を表示」リンクをクリックします。すると、Amazon Qがこの仮説のために選択した具体的な証拠が表示されます。
ここでは、Dynamoからのスロットリングされたリクエストが見えます。また、個々の顧客を識別するContributor Insightsルールも見ることができます。実は、Contributor Insightsをご存知の方はいらっしゃいますか？それほど多くないですね。でも大丈夫です。Amazon Qは、あなたがそれらを認識していなくても、または使用するタイミングを知らなくても、CloudWatchの持つこれらの機能を活用することができます。
この仮説は十分に納得できるものだと思います。そこで、この仮説を受け入れて、調査に記録として追加しましょう。仮説を受け入れ、問題を正常に診断したので、Amazon Qは次のステップとして実行できるアクションを提案します。
Amazon Qの仮説検証機能の強みは、単に問題の可能性のある原因を提案するだけでなく、その仮説を裏付ける具体的な証拠へのリンクも提供することです。「推論を表示」機能により、仮説の基礎となっている具体的なデータポイントを確認でき、運用担当者は十分な情報に基づいた決定を下すことができます。
また、Amazon Qは一般的には認識されていないかもしれないツールやサービス（Contributor Insightsなど）を活用して、問題の根本原因を特定するのに役立つ独自の洞察を提供します。これにより、専門知識のギャップが埋められ、すべての運用担当者がより効果的に問題を診断できるようになります。
7.4. AWS管理ランブックによる修復
仮説を受け入れ、問題を正常に診断したところで、まだ問題を緩和し、取るべき正しいアクションについて考える必要があります。緩和策としては複数の選択肢が考えられることは珍しくありません。この場合、いくつかの選択肢を検討できます。
テーブルのプロビジョニングされたスループットを増やすことを考えられます。これにより基本的なコストは増加しますが、テーブルへのより多くの負荷を許可することになります。オンデマンドに切り替えることも考えられます。これによりテーブルは動的にスケールできるようになりますが、コストはより変動的になります。自動スケーリングを有効にすることも検討できますが、この状況では適切な自動スケーリング構成について考える時間を取りたくないかもしれません。
顧客をスロットリングする方法があれば、それも検討するかもしれません。この特定のケースでは、何が負荷を引き起こしているのかわかりません。彼らの側の問題なのか、トラフィックが正当なものなのかわかりません。そのため、この状況からできるだけ早く抜け出したいと思っています。
ここで、Amazon Qがこの仮説に対して既にいくつかのアクションを特定し、このコンソールから直接実行できるAWS管理ランブックを推奨していることがわかります。また、DynamoDBとその容量管理方法についてより理解を深めるためのドキュメント記事も紹介されています。
この例では、テーブルのプロビジョニングされたスループットを増やして問題を緩和し、他の顧客への影響を制限します。ランブックを表示すると、ランブックが実行する具体的なステップと、ランブックの実行に必要な権限が説明されています。
このランブックを実行する際、使用される権限は私自身が持つ権限です。他の権限や昇格された権限が使用されるわけではないので、私自身が既に許可されていないアクションを取ることはできません。では、このランブックのパラメータを入力しましょう。
読み取り容量は影響を受けていないことがわかっていますし、この問題について少し知識があるので、書き込み容量を20に増やすことができます。これでランブックを実行できます。
ランブックを実行するアクションが調査に記録され、その結果を監視するためのリンクが提供されます。これは完了するまで数分かかりますので、ここで皆さんを待たせることはしませんが、これによりテーブルの容量が増加し、アラームが解消されます。
次のステップとしては、カスタマーケアチームと協力して、このトラフィックを発生させているクリニックに連絡し、実際の根本原因に対処することかもしれません。
最後に、調査を閉じて、最終的なメモを残すことができます。これにより、このアラームが次にトリガーされたときには、新しい調査が作成され、Amazon Qがその問題の調査も開始します。
8. Slack連携デモ
8.1. 運用チャンネルでのAmazon Q統合
AWS コンソールを使用することに加えて、多くのお客様は Slack のようなツールを使用しています。Amazon 内部では、私が所属するチームも含め、ほとんどのコミュニケーションに Slack を使用しています。そのため、Amazon Q が運用チャンネルにも参加できれば素晴らしいと考えました。
それがどのように見えるか、お見せしましょう。ここで表示しているのは、私の運用チームの Slack チャンネルです。Amazon Q が Slack と接続するように設定し、運用チャンネルに参加していることがわかります。Amazon Q からの最初のメッセージは、予約訪問の可用性調査の開始を示しており、スレッドを開始します。そして、調査対象のメトリクスを Slack 内で直接見ることができます。
Slack と Amazon Q の統合により、運用チームは AWS コンソールにログインしなくても、重要なアラートや調査情報を受け取ることができます。これは特に、分散したチームや、移動中にアラートに対応する必要がある場合に非常に便利です。
Slack チャンネルに Amazon Q を統合することで、運用上の問題に関するコミュニケーションが一元化され、チーム全体が状況を把握しやすくなります。また、オンコール対応中のチームメンバーが迅速に情報を共有し、協力して問題を解決するための効果的な方法も提供されます。
この統合は、Amazon 内部のチームが日常的に使用している実際のワークフローを反映しており、運用チームの既存のコミュニケーションパターンに自然に適合するように設計されています。
8.2. アラート通知とスレッド管理
私の運用チームのSlackチャンネルを見ると、Amazon Qを設定してSlackと連携させ、運用チャンネルに参加させていることがわかります。Amazon Qからの最初のメッセージは、予約訪問の可用性調査が開始されたことを示しており、これによってスレッドが始まります。ここではSlack内で直接、調査中のメトリックを見ることができます。
Amazon Qからの2番目のメッセージは、AWSコンソールで見られる提案フィードと同様です。Amazon Qが作成するすべての提案は、Slackのこのフィードで直接見つけることができます。
最後に、根本原因の仮説を含むスレッドもあり、AWSコンソールにログインしなくても確認できます。これにより、チーム全体が同じ情報にアクセスでき、どこにいても調査の進行状況を追跡できます。
Slackでの通知は、スレッド形式で整理されているため、関連するすべての情報が一つの会話の流れの中にまとめられています。これにより、複数のアラートや通知があっても、それぞれのインシデントの文脈が明確に保たれます。
また、スレッド形式により、チームメンバーは特定のインシデントに関するディスカッションを集中して行うことができ、他のインシデントや一般的な運用の会話と混同することなく対応できます。さらに、この構造化された通知方法は、あとで参照する際にも、特定のインシデントに関連するすべての情報を簡単に見つけることができます。
このアラート通知とスレッド管理の仕組みは、特に複数のインシデントが同時に発生する可能性がある大規模な運用環境において、混乱を減らし、効率的な問題解決をサポートします。
8.3. 調査結果の共有方法
Amazon Qの調査結果は、Slackで効果的に共有されています。私の運用チームのSlackチャンネルでは、調査に関連するすべての重要な情報がスレッド形式で整理されています。
最初のメッセージでは、予約訪問の可用性調査の開始が通知され、スレッドが始まります。このスレッド内では、調査対象のメトリックが直接表示されており、Slack内で即座に状況を把握することができます。
2番目のメッセージは、AWSコンソールの提案フィードと同様の内容です。Amazon Qが生成するすべての提案は、このSlackフィードで直接確認できます。これにより、チームメンバーはAWSコンソールに切り替えることなく、重要な観察結果と提案にアクセスできます。
最も重要なのは、根本原因の仮説を含むスレッドもSlack内で直接アクセスできることです。AWSコンソールにログインしなくても、Amazon Qが特定した問題の根本原因と、それを裏付ける証拠を確認できます。
この共有方法の利点は、チーム全体が同じ情報に簡単にアクセスでき、物理的な場所に関係なく協力して問題を解決できることです。また、調査結果は時系列で整理されているため、インシデントの進行状況を追跡しやすくなっています。
Slack統合により、オンコールエンジニアは移動中でもスマートフォンから重要な通知を受け取り、必要に応じて対応したり、追加のチームメンバーを招集したりすることができます。これにより、対応時間が短縮され、問題解決が加速します。
この調査結果の共有方法は、チームコラボレーションを強化し、知識共有を促進し、最終的にはインシデント解決時間の短縮に貢献します。
9. 機能の利用開始方法
9.1. 必須設定：調査グループの作成とアクセス権限
Amazon Q調査を使い始めるために必要なことには、2つのカテゴリがあります。まず必須となるのは、調査グループの作成です。この調査グループは、共通の設定を持つ調査のコンテナと考えることができます。例えば、Amazon Qがリソースやテレメトリにアクセスする際に使用する権限や、暗号化設定、保持期間、Slackなどのサードパーティとの統合などです。
調査グループを作成することで、Amazon Qに対して、どのリソースにアクセスして分析を行う権限があるかを定義します。これにより、セキュリティを維持しながら、必要な情報へのアクセスを提供することができます。権限は最小特権の原則に従って設定することができ、Amazon Qが必要とする操作のみを許可することができます。
暗号化設定では、調査データの保護方法を指定することができます。これにより、センシティブな情報が適切に保護されることを確認できます。保持期間の設定では、調査データをどれだけの期間保存するかを制御することができ、組織のデータ管理ポリシーに合わせることができます。
調査グループを設定すると、サンプル調査の使用や、過去に発生した問題を遡及的に調査する実験を開始することができます。これにより、実際のインシデント対応前に機能を試し、チームが使い方に慣れることができます。
また、調査グループはチームメンバー間で共有することができるため、協力して調査を行うことができます。これは特に複雑なインシデントや、複数のチームが関わる問題を解決する際に有用です。
調査グループの適切な設定は、Amazon Q調査機能を最大限に活用するための基盤となります。適切な権限、暗号化、保持設定を行うことで、セキュリティを維持しながら効果的な運用分析を実現することができます。
9.2. ベストプラクティス：アプリケーションシグナル、X-Ray、エージェント
2番目のカテゴリは、ベストプラクティスと呼んでいるものです。これらは、運用インシデントを調査する際のAmazon Qの価値とパフォーマンスを最大化するために行うことができることです。
Amazon Qが環境を適切に分析するためには、ワークロード間の関係、その依存関係、およびそれらが発するテレメトリを理解する必要があります。環境の最も正確なビューを構築するために、アプリケーションシグナル、AWS X-Ray、そしてCloudWatchまたはFluent Bitエージェントをアップグレードして最新の機能を活用することをお勧めします。
これらを有効にしていない場合でも、それらの接続を推測しようとします。この推測には確率的な誤差率があります。特に、アプリケーションシグナルを有効にすることで、Amazon Qはサービス間の依存関係や接続を把握し、より正確な分析を提供することができます。
AWS X-Rayを使用すると、分散アプリケーション内でのリクエストの流れを追跡し、パフォーマンスのボトルネックや障害点を特定するのに役立ちます。これにより、Amazon Qはシステム内のどのコンポーネントが問題を引き起こしているかをより正確に特定できます。
最新のCloudWatchエージェントやFluent Bitエージェントを使用することも重要です。これらの最新バージョンでは、より詳細なメトリクスやログデータを収集でき、Amazon Qがより正確な分析を行うのに役立ちます。
これらのベストプラクティスは必須ではありませんが、Amazon Qの調査能力を最大限に活用するための重要な要素です。これらを実装することで、より詳細で正確な分析と、より有用な推奨事項を得ることができます。環境についての情報が多ければ多いほど、Amazon Qはより効果的に問題を診断し解決することができます。
9.3. CloudTrailログの有効化とアラーム設定
私たちは、CloudTrailログを有効にすることをお勧めします。私たちの多くのお客様は既にCloudTrailログをCloudWatchに送信しています。これにより、Amazon Qはインシデントを引き起こした可能性のあるリソース構成の変更を検出するためにCloudTrailを使用することができます。
CloudTrailログを有効にすることで、誰がいつ何を変更したかという重要な情報をAmazon Qが分析できるようになります。例えば、DynamoDBテーブルのポリシーが変更され、それがサービスの可用性に影響を与えた場合、CloudTrailログを通じてその変更を検出し、根本原因として特定することができます。
最後に、先ほど示したように、アラームが自動的に調査を作成するように設定することができます。単一のコンポーネントが複数の機能に対して複数のアラームを持つことは珍しくありませんが、チケットシステムと同様に、これらのアラームがすべて相関する問題によって発生する可能性があるため、それぞれに対して調査を作成したくないかもしれません。
もしこれを避けたい場合は、調査アクションを接続する複合アラームを作成することをお勧めします。複合アラームを使用することで、単一の調査で複数の関連アラームを処理でき、ノイズを減らし、関連する問題を一緒に調査することができます。
例えば、サービスの可用性、レイテンシー、エラー率に関する複数のアラームがある場合、これらすべてが同じ根本原因によって同時にトリガーされる可能性があります。複合アラームを使用することで、これらのアラームを論理的に組み合わせ、単一の調査アクションをトリガーすることができます。
CloudTrailログとアラーム設定の適切な組み合わせにより、Amazon Qは環境で発生する問題をより効果的に検出し分析することができ、運用チームはより迅速に根本原因を特定して解決することができます。
10. 調査開始の様々な方法
10.1. アラームからの自動トリガー
これは確かに楽しそうですね。では、どのようにして自分自身で調査を開始できるのでしょうか？Amazon Q運用調査には、どこにいても多くの異なるエントリポイントがあります。
先ほど紹介したデモは、CloudWatchアラームに対してアクションとして事前に設定された、自動的にトリガーされる調査でした。これは特に効果的なアプローチです。アラームがトリガーされると同時に、Amazon Qが自動的に調査を開始し、根本原因の分析を始めるからです。
この設定により、運用チームがアラートに対応してログインする前に、既に分析が進行中または完了していることを意味します。これにより、問題への対応時間が大幅に短縮されます。特に夜間や週末など、通常の営業時間外にアラートが発生した場合に貴重です。
アラームアクションとして設定する際は、最も重要なメトリクスやサービスヘルスに関連するアラームを選択することをお勧めします。すべてのアラームに対して調査を自動的に開始する必要はなく、ビジネスクリティカルなサービスやコンポーネントに焦点を当てることで、最も価値のある洞察を得ることができます。
また、先ほど説明した複合アラームを使用すると、関連する複数のアラームを一つの調査トリガーにまとめることができます。これにより、関連する問題に対して複数の調査が作成されることを防ぎ、より統合された分析が可能になります。
アラームからの自動トリガーは、特に大規模な環境や、24時間365日の可用性が求められるミッションクリティカルなアプリケーションにとって、非常に価値のある機能です。これにより、チームが問題に気づく前に、Amazon Qが既に調査を開始しており、チームが対応を始める時点で価値ある洞察を提供できる状態になっています。
10.2. Q Chatからの質問ベース調査
Amazon Q運用調査を開始するもう一つの方法は、Q Chatを使用する方法です。このアプローチでは、自然言語を使用して調査を開始し、運用上の問題について質問することができます。
例えば、「なぜページングされたのか？」というシンプルな質問をQ Chatに投げかけることができます。すると、チャットインターフェースを通じて次のステップについてガイダンスが提供されます。これは特に、移動中や、AWSコンソールにすぐにアクセスできない状況で有用です。
Q Chatは会話形式の対話を提供するため、問題の文脈や詳細を自然な会話の流れの中で提供することができます。例えば、「昨日と比較して今日はウェブサイトのレイテンシーが高くなっているようだが、原因は何か？」といった具体的な質問を投げかけることもできます。
質問ベースの調査では、Amazon Qは関連するテレメトリデータを自動的に分析し、潜在的な根本原因や調査を深めるための提案を提供します。また、チャット形式であるため、追加の質問や詳細の要求など、対話的に調査を進めることができます。
この方法は、非技術的なチームメンバーや、システムの詳細に精通していないユーザーにとっても使いやすい入り口となります。技術的な専門用語やクエリ言語を知らなくても、自然言語で問題を説明するだけで調査を開始できるからです。
Q Chatからの質問ベース調査は、Amazon Q運用調査機能へのアクセスを民主化し、より広範なチームメンバーが運用上の問題を理解し対応できるようにする強力な方法です。
10.3. ダッシュボードからの直接調査
ダッシュボード上のスパイクから調査を開始したい場合はどうでしょうか？80以上のAWSサービスコンソール全体に組み込まれているテレメトリから調査を開始することもできます。これを今からお見せします。
ここで表示しているのは、フロントエンドサービスのサンプルダッシュボードです。予約訪問の可用性の問題に少し変更を加えたものを引き続き使用します。ここで、他の低下とは少し異なる可用性の低下が見られます。これを調査したいと思います。調査したい領域にズームインして、このツールチップをクリックし、「調査」を選択して新しい調査を開始することができます。
調査にタイトルを付け、開始することができます。この分析には数分かかりますので、ここでお待たせすることはしません。すでに実行したものをお見せします。この場合、負荷の増加ではなく、Dynamoテーブルに対して誰かが行った変更が問題の原因であるように、インシデントを変更しました。
実は私自身がやったことです。テーブルのリソースポリシーを変更して、すべてのトラフィックを拒否するようにしました。これはあまり良いアイデアではありませんね。おそらく、より良い変更管理ポリシーを実装する必要があります。でもこういうことは起こりますよね。
Amazon Qが提供した提案を見てみましょう。ここでは、訪問登録テーブルにputItem操作を実行しようとした際に認証エラーが発生し、訪問サービスとフロントエンドサービスに影響を与えたことをAmazon Qが特定したことがわかります。
ここで、本当に素晴らしい部分をお見せしたいと思います。「推論を表示」をクリックすると、ユーザーのアクセスが拒否されたことを示すログが表示されます。また、キャプチャされて記録されたCloudTrailの変更イベントも確認できます。そのリンクをクリックして、自分でCloudTrailイベントを確認し、どのような特定の変更が行われたのかを確認することができます。
ここでは、すべてのトラフィックを拒否したポリシーを確認でき、実際に誰が変更を行ったのかも確認できます。これにより、このような問題が再発しないようにするために何をすべきかを把握することができます。
この例では、Amazon Qが任意のAWSサービスコンソールの埋め込みダッシュボードから有効化できることを示しました。また、リソース構成の変更によって引き起こされた問題の根本原因を特定する際に、CloudTrailを使用する方法も示しました。
このように、ダッシュボードからの直接調査は、メトリクスの異常な動きに気づいた際に、即座に調査を開始できる便利な方法です。視覚的なダッシュボードから直接調査を開始できるため、問題の文脈を失うことなく、シームレスに分析プロセスに移行できます。
11. まとめと主要なポイント
11.1. AIOpsの進化と今後の展望
私たちの旅をまとめると、AIOpsの進化と業界がルールベースとMLベースの統合から、インシデント管理と根本原因修復のための技術のアンサンブルを使用することへの移行について議論しました。AIOpsは真に一つの旅であり、私たちは一歩ずつ進歩しています。
AIOpsは明確な進化の過程を辿っています。最初は正確なルールベースのシステムから始まり、AWS ConfigやTrusted Advisorのような単純だが効果的なツールでした。次に、確率に基づく予測を提供する機械学習モデルが導入されました。これらの基盤の上に、現在の業界は様々な技術を組み合わせたインシデント管理アプローチへと移行しています。
ルールベース、機械学習、AI、そして生成AIを組み合わせることで、より包括的で動的なインシデントの相関付け、より正確な根本原因分析、そしてより適切な修復提案が可能になっています。この統合アプローチは単一の技術に依存するよりも強力で、より複雑な運用課題に対応できます。
今後の展望としては、予測的インサイトの段階に向かっています。これは単なる反応的なトラブルシューティングではなく、問題が発生する前にそれを予測し防止するという大きな飛躍です。例えば、メモリリークやディスク使用量のパターンを検出して、それらが重大な障害になる前に警告することが可能になります。
さらに将来的には、完全に自動化された自己修復システムという「聖杯」も視野に入れていますが、そこに到達するまでには長い道のりがあります。重要なのは、AIが魔法ではなく、適切に適用された場合に運用を変革できる強力なツールだということです。
私たちはこの進化の過程において、実用的なソリューションを開発し続け、お客様にとって真に価値のあるAIOps機能を提供することに注力しています。今日ご紹介したAmazon Q Developer運用調査はその重要な一歩であり、お客様の運用効率を向上させる多くの機能の一つに過ぎません。
11.2. 追加コストなしで利用可能な機能
最高の部分は、今日お話ししたこれらの機能すべて（運用調査機能を含む最新のもの）が、追加コストなしで今日からご利用いただけることです。ちょっと考えてみてください。以前なら、これらのことをすべて行う際には、新しいダッシュボードを作成したり、新しいアラームを設定したり、メトリクスやログにわたって多くのデータをスキャンしたりしていたでしょう。今ではもうそのための費用を支払う必要はありません。なぜなら、私たちの調査機能がそれを行い、あなたを助けるからです。
これは重要なポイントです。Amazon Q Developer運用調査機能を使用することで、運用チームは従来必要だった多くの手動プロセスを自動化できます。これには数十のダッシュボードの作成や、大量のログデータのスキャン、複数のサービスコンソール間の移動などが含まれます。これらの作業はすべて時間がかかるだけでなく、CloudWatchなどのサービスの使用量にも影響していました。
Amazon Qがこれらの作業を代行することで、ログの検索やメトリクスの分析に関連するコストが削減されます。さらに、運用チームは問題の解決により多くの時間を費やし、データの収集や相関付けに費やす時間を減らすことができます。
この機能は、CloudWatchログやメトリクスの使用量に基づいた従来の課金モデルとは別に、追加料金なしで提供されています。つまり、現在CloudWatchを使用しているすべてのお客様は、追加投資なしでこれらの高度なAIOps機能を活用できるのです。
最終的に、これによりお客様は運用コストを削減しながら、サービスの信頼性と応答性を向上させることができます。問題の診断と解決が速くなるほど、ダウンタイムが減少し、ビジネスへの影響も少なくなります。お客様はこれらの高度なAI機能を活用して、運用効率を大幅に向上させることができるのです。
11.3. AIを活用した人間主導の運用改善
私たちは、AIOpsがデータ間の固有のつながりを表面化することで、運用を合理化するのに役立つと本当に信じています。これは今日、ドメインの専門知識と試行錯誤の技術による実験の両方を必要とするものです。このAIによる支援、しかし人間主導の体験は、責任を持って使用した場合、非常に強力なツールであると確信しており、それが今日できることと、この分野への投資を続ける中で未来が持つものの両方に興奮しています。
私たちは、このAI支援型の人間主導アプローチが、単独で動作するAIシステムよりも効果的であると考えています。AIは強力なツールですが、最終的な判断と決定は人間によって行われるべきであると信じています。Amazon Qは運用担当者のパートナーとして機能し、データの分析、パターンの特定、根本原因の仮説の生成を通じて彼らをサポートしますが、最終的な決定と対応方法の選択は人間の専門家に委ねられます。
このアプローチの美しさは、時間の経過とともに双方が学習し改善できることです。AIシステムはより多くの運用データにさらされるにつれて改善し、運用担当者はAIツールとの相互作用を通じて新しい洞察と問題解決アプローチを学びます。これは協調的な進化であり、両者の強みを活かしています。
このビジョンは、単に今日の問題を解決するだけでなく、運用のあり方を根本的に再考することです。AIが単調で反復的な分析作業を担当し、人間の専門家がその洞察を用いて戦略的な意思決定を行い、より効果的に問題を解決できる未来を想像しています。
今日ご紹介したAmazon Q Developer運用調査機能は、このビジョンに向けた重要な一歩です。これは私たちのAIOps機能の進化の始まりに過ぎません。私たちは、お客様のフィードバックを取り入れ、この技術をさらに発展させ、運用監視と問題解決の分野で新しい可能性を開拓し続けることを楽しみにしています。