re:Invent 2024: AWSのAI駆動オペレーション効率化 - CloudWatchとAmazon Q活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Accelerate innovation with AI-powered operations (COP315)
この動画では、AWSのAI駆動のオペレーション効率化について、AWS ObservabilityとAIOpsサービスのGeneral ManagerのMihir Patelらが解説しています。CloudWatchの既存機能であるPattern Analytics、Compare Mode、Always-on Logs Anomaly Detectionの活用方法から、新たに発表されたAmazon Q Developer Operations Investigationの詳細まで、具体的な事例を交えて紹介しています。特に、動物病院の予約システムを例にした実践的なデモでは、DynamoDBのスロットリング問題の検出から解決までの流れを示し、Amazon Qが自動的に問題を分析し、解決策を提案する様子を実演しています。これらの機能は追加費用なしで利用可能で、AWSの運用効率を大幅に向上させる可能性を持っています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのAI駆動オペレーションとサービス進化：登壇者紹介
皆様、こんにちは。本日は多くの方々にご参加いただき、誠にありがとうございます。これまでのre:Inventを楽しんでいただけていることを願っています。本日は、AWSがAI駆動のオペレーションでイノベーションを加速する方法と、私たちのサービスの進化についてお話しさせていただきます。私はMihir Patelで、AWS ObservabilityとAIOpsサービスのGeneral Managerを務めています。今回で10回目のre:Inventとなりますが、約15年前にAmazonでインターンとしてキャリアをスタートし、深夜や繁忙期の緊急対応から、チームと共に多くのAWSサービスの構築やリードまで、Amazonのスケールでのオペレーションについて学ぶ素晴らしい機会に恵まれました。私のチームは、何百万ものAWSカスタマーに価値を提供するため、日々熱心に取り組んでいます。
私はNikhil Dewanで、CloudWatchとAIOpsのプロダクトリードを務めています。エンジニアとしてキャリアをスタートし、様々な業界でオペレーション関連の役割を担ってきました。面白いことに、私のクラウドモニタリングとの出会いは、3大陸で活動する地質学者、掘削作業員、そして経営陣の複雑なニーズに対応するエネルギー系スタートアップ向けにプライベートクラウドを構築する任務から始まりました。AWSでの私の旅は7年前、まさにこのCloudWatchから始まりました。私は日々、皆様のような先見性のあるお客様や優秀なチームと協力しながら、クラウドオペレーションの可能性の限界を押し広げる仕事に携わる特権を享受しています。
私はJared Nanceで、CloudWatchのPrincipal Engineerを務めています。私は製造業やヘルスケア業界向けの特定領域のモニタリングソリューションを構築する仕事を、複数のスタートアップや大企業で経験してきました。面白いことに、私もNikhilと同じく約7年前にCloudWatchに参画し、彼と同様に、AWSのお客様やAmazon社内チームが前例のないスケールで活用できる機能の構築に、チームと密接に協力しながら取り組んでいます。ありがとう、JaredとNikhil。
AIの実用的応用：運用トラブルシューティングへの活用
本日は、AIが運用上の課題解決にどのように役立つかをご紹介します。でも、それだけではありませんよね？AIは車の運転や朝食作り、洗濯物たたみまでしてくれるんじゃないでしょうか？冗談です。誇張されたAIの話には皆さんもうんざりしているでしょう。AIは魔法ではありませんが、確かに制限はあるものの非常に強力なツールです。今日は、運用のトラブルシューティングにおいてAIがどのように役立つかを探っていきます。まだ朝食は作ってくれないかもしれませんが、運用におけるAIの実用的な応用は非常に有望だとお約束できます。それでは、AWSで構築している運用の簡素化と効率化を支援する実用的な機能について詳しく見ていきましょう。
本日の議論を始めるにあたり、今朝のMattのキーノートで発表した機能について簡単にご紹介したいと思います。次のようなシナリオを想像してください：深夜、実際のエンドユーザーへの影響を知らせるアラームで呼び出されました。ログインした時には、 Amazon Q Developerがすでに可用性低下の潜在的な根本原因を特定しています。さらに素晴らしいことに、 AWSの長年の運用経験を活用して、お客様への影響を軽減するための即時対応だけでなく、根本原因に対処するための有用な提案も受けられるとしたらどうでしょう？ このシナリオでは、お客様の環境に合わせてカスタマイズされたAWS管理のRunbookを迅速に実行し、アプリケーションを素早く正常な状態に復旧することができます。
より詳しく学んでいただけることを楽しみにしています。 これから1時間かけて、3つのトピックについてご説明させていただきます。まず、AWSにおけるAI運用サービスの進化についてお話しします。次に、新しくローンチされたAmazon Q Developerの運用調査機能について詳しく見ていきます。そして最後に、これらのAIを活用した機能を使って運用を効率化する方法の概要をご紹介します。
AIOpsの進化と顧客が直面する課題
ありがとうございます、Mihir。AIOpsという言葉は以前からありますが、お客様との会話を通じて、人によって異なる意味を持つことに気づきました。そこで、AIOpsの想定される進化について説明し、業界の現状を率直にお話しすることから始めたいと思います。すべては、ルールベースのシステムから始まりました。これらのシステムは通常、エラー率が低く、非常に正確です。例えば、AWS ConfigやTrusted Advisorには、自動化をトリガーするルールベースのシステムがあります。その後、異常検知技術に機械学習を取り入れ始めました。 機械学習モデルは確実性ではなく、確率を提供します。
これらは、計算機というよりも気象予報士のようなものだと考えてください。これらの技術は長年存在し、お客様から大きな支持を得ています。 現在、業界はインシデント管理にAIを活用する初期段階にあります。これには、ルールベース、機械学習、AI、生成AIを組み合わせて、動的なインシデント相関、根本原因分析、修復提案を行うことが含まれます。
次のフェーズとして、業界は予測的なインサイトへと向かうと予想しています。これにより、お客様は将来の障害や容量ニーズを予測できるようになります。メモリやディスクのリークを検出し、対策を取らなければ問題が発生することを事前に通知する機能などが良い例です。 また、完全に自己修復可能な自動化システムという究極の目標もありますが、それに到達するまでには時間がかかるでしょう。
この背景を踏まえて、お客様がCloudWatchデータを分析する際に直面している課題についてお話ししましょう。データ量が増え続ける中、お客様は調査をどこから始めればよいのか、そして「アプリケーションで何が変化したのか」という基本的な質問に答えることが難しいと感じています。お客様は、問題が重大化する前に、潜在的な問題の早期警告サインを事前に通知してほしいと考えています。特に、想定外の問題、つまり認識すらしていなかった未知の問題を予測し特定することは非常に困難です。
CloudWatchのAI搭載機能：データ分析の革新
この概念を説明するために、LEGOブロックを例に考えてみましょう。私には2人の息子がいて、彼らはLEGOが大好きです。妻と私は遊んだ後の片付けをさせるようにしていますが、残念ながら、翌日にはこのような状態になってしまいます。息子たちが特定の色や形のブロックを探すのを手伝ってほしいと頼んでくると、私たちは頭を抱えてしまいます。そんなとき、魔法の杖があって、すぐにブロックを色ごとに分類できたらいいのにと思います。
実は、CloudWatchログではすでにそれが可能なんです。前回のre:Inventで、Pattern Analyticsという機能をリリースし、何十万ものお客様がこの機能を使用して、ログとの関わり方が変わったと言っています。クエリを実行するたびに、ログのクエリ結果から重要なパターンを自動的に抽出します。ブロックを色ごとに整理するのと同じように、この機能は何千ものログエントリを、調査の出発点となる重要なパターンに集約するのに役立ちます。このクエリでは、ログにいくつかの重要なパターンがあることがわかり、それらがどのくらいの頻度で発生しているかも示されます。「error」という単語を含むパターンは、調査の良い出発点となるでしょう。
さて、何か変化があった時に通知が来たら素晴らしいと思いませんか？例えば、私が1時間部屋を離れている間に、子供たちが新しいブロックセットを手に入れたとします。理想的な世界では、Marie Kondoが突然訪れたかのように、それらのブロックが整然とバスケットに収納されているはずです。残念ながら、私の子供たちは片付けの魔法についての理解が全くありません。でも朗報があります：子供のおもちゃの散らかり具合をMarie Kondo式に整理することはできませんが、私たちCloudWatchはクラウドデータの整理と理解を支援することが得意なんです。
これが、CloudWatchですでに利用可能な2つ目の素晴らしいML搭載機能につながります。Compare Modeと呼ばれるものです。このスナップショットを見ると、ログに新しいパターンが出現し、それがどのくらいの頻度で発生しているかがわかります。これは何が変化したのかを調査する際の優れた出発点となるでしょう。画面下部には、2つの期間で特定のパターンの傾向を視覚的に比較できる便利なヒストグラムがあります。
これら2つの機能を開発する中で、こんな考えが浮かびました：これらの機能を組み合わせて、プロセスを自動化できないだろうか？手動入力なしで異常なアイテムを選別する果物の選別機を想像してみてください。同じことをログデータでもできるのではないか？そこで登場するのが、CloudWatchの3つ目のML搭載機能、Always-on Logs Anomaly Detectionです。始めるのは本当に簡単です。ロググループでこの機能を有効にするだけで、その後はCloudWatchが常に入力されるログを評価し、過去のベースラインと比較して、異常な傾向を通知してくれます。
スナップショットを見ると、ログの異常を示すビューが表示されており、主要なトレンドやパターン、さらに優先度レベルや最新の検出時刻など、詳細な分析に必要な重要な情報を確認することができます。
まとめますと、現在のCloudWatchには既にいくつかの印象的なAIOps機能が組み込まれています。まず、Pattern Modeは調査をサポートするため、ログを重要なパターンごとにクラスター化します。次に、Compare Modeは、昨日は正常だったアプリケーションが今日はおかしい、というような状況で何が変化したのかという重要な問いに答えるのに役立ちます。そして最後に、常時稼働の異常検知機能は、受信するログを自動的に分析し、発生しつつある問題を事前に通知します。今回はログの例を中心に説明しましたが、メトリクスなど他のテレメトリタイプについても同様の異常検知機能が利用可能です。もしこれらのAIOps機能や、これまでに追加してきた機能強化をまだ確認されていない方は、このセッションの直後が、チームと一緒に、あるいは実際に自分で確認するのに最適なタイミングです。
Amazon Q Developer：AIによる運用調査の新時代
CloudWatchが提供するもう一つのAIOps機能は、LogsとMetric Insightsのクエリに対する自然言語クエリ生成です。この機能は今年初めにリリースされ、多くのお客様に広く採用されています。私たちは、テレメトリへの高速なインタラクティブドリルダウンをサポートするクエリツールの価値を理解していますが、クエリ構文の習得には時間とドメイン知識が必要であることも認識しています。このローンチにより、ログとメトリクスの分析機能を非常に簡単に使い始めることができるようになりました。自然言語で質問を入力するだけで、実行可能なクエリを生成します。また、構文の学習を支援するため、生成されたクエリの行ごとの説明も提供しています。自然言語プロンプトを使用することで、既存のクエリを簡単に修正し、反復的な詳細分析を行うことができます。これらの機能の素晴らしい点は、追加コストなしで利用できることです。
ここまでで、過去12ヶ月間で人気を集めたCloudWatchのコアとなるAIOps機能について説明してきました。ここからは、この分野でさらに深く掘り下げ、より困難なお客様の課題に取り組むための私たちの動機について説明させていただきます。まずは、大規模なアプリケーションと運用を持つお客様から寄せられた課題を簡単に見ていきましょう。多くの場合、問題のトリアージに必要な適切なデータが不足しており、たとえ適切なデータがあったとしても、すべてのシグナルを組み合わせて理解し、根本原因にたどり着くことは困難です。また、お客様はアラームやツールの疲れを感じることが多く、相互に関連している可能性のあるアラームが発生しても、どれが関連しているのかを把握するのが難しい状況にあります。
現在、お客様は多くのツールを使用しており、理想的には根本原因に素早くたどり着けるよう、インサイトとデータを一箇所で確認したいと考えています。メトリクス、ログ、トレース、AWS Health通知、さらにデプロイメントなどの各種イベントを含む、異なるシグナルの相関関係を見出すことは困難だとお客様から伺っています。根本原因にたどり着いた後でも、最適な修正方法を見つけ出し、理想的には同じ問題が再発することを防ぎたいと考えています。深夜2時に呼び出されたとき、冷静さを保つのは困難です。このスライドは、運用上の問題の根本原因にたどり着くまでに、オペレーターが今日取らなければならない多くのステップを示しています。このワークフローは見覚えがありませんか？多くの場合、オペレーターは試行錯誤のアプローチを取り、問題を特定して解決するために、多くの異なるシグナルを一緒に調べる必要があります。
Amazonでは、コードを1行も書く前に、プロダクトの要件を完全に理解するように努めています。これを私たちはWorking Backwardsプロセスと呼んでいます。LLMテクノロジーが注目を集めるようになった12〜18ヶ月前、私たちはWorking Backwardsの取り組みを開始し、AIOpsの体験における理想的なカスタマーエクスペリエンスと要件を定義することにしました。このスライドでは、自動的なインストルメンテーションとデータ収集から、アラートの検出と優先順位付け、ガイド付きのRoot Cause分析と運用トラブルシューティングの体験、推奨アクションの提供、そして継続的な学習と進化まで、大規模なアプリケーション運用に関するいくつかのテーマについて簡単に説明しています。
私たちのチームは、これらのコア要件を実現するために懸命に取り組んできました。本日、Amazon Q Developer Operations Investigationのプレビュー版のローンチを発表できることを大変嬉しく思います。この機能は、問題の検出からトリアージ、そして解決までの一連のガイド付き運用トラブルシューティング体験を提供します。CloudWatchテレメトリ、CloudTrailログ、デプロイメント情報、リソース設定の変更、AWSヘルスイベントなど、さまざまなテレメトリシグナルを自動的に分析します。アラームに応答して自動的に調査を開始することができ、AWS Qチャット体験や80以上のAWSコンソールからも利用できます。さらに、AWSコンソールやAmazon CloudWatchで協力して調査を行うための共同作業環境も提供します。
Amazon Q Developerのライブデモ：インシデント対応の実践
一枚の写真は千の言葉に値すると言いますが、うまくいけばライブデモは千枚の写真に値します。それでは、この機能のライブデモをご覧いただくために、Jaredをお迎えしましょう。始める前に、会場にオペレーターの方はいらっしゃいますか？運用イベントで給料をもらっている方？はい、素晴らしいですね。私は約10年間オンコール対応をしており、アプリケーションのデバッグやインシデントのリアルタイムトラブルシューティング、そしてサービスの実行時のパフォーマンスについてより深く理解するための探索的データ分析のために、毎日CloudWatchを使用しています。私は日々Observabilityを実践しており、私たち全員をより効率的にするためのツールの改善に情熱を注いでいます。
このデモを3つのパートでご紹介します。まず、サンプルアプリケーションとインシデントについての背景を説明します。次に、Amazon Qを使用してそのインシデントをトラブルシューティングし解決する方法をお見せします。最後に、皆さんが自身で始める方法についてお話しします。このインシデントの話を、DevOpsエンジニアの視点からお伝えします。まず、このストーリーで対応しているサービスと状況について少しお話しさせてください。私は、動物病院が予約、ペットの履歴、そして病院が必要とする一般的な機能を管理できるようにするサービスプラットフォームを管理しています。これはマルチテナントアプリケーションで、つまり私のサービスは常に複数の動物病院からのリクエストを処理しています。画面に表示されているのはクリニックポータルです。これは、私のお客様である病院が日常的に使用するUIです。サインインして、顧客のリスト、ペットの管理、予約の作成などができます。
予約の管理は病院のビジネスにとって中核的な業務であり、サービスプロバイダーとして、私はこの機能を常に利用可能な状態に保つ必要があります。それでは、このサービスの舞台裏と、私が対応しようとしているインシデントを見てみましょう。顧客が動物病院のサイトを訪れると、そのリクエストはALBに送られ、Amazon EKSで実行されている私のフロントエンドサービスにルーティングされます。このサービスは認証、認可の検証を処理し、必要な特定の操作を担当するバックエンドマイクロサービスにリクエストをルーティングします。これらはすべてEKS上で実行されているJava Spring Webアプリケーションサービスで、それぞれのサービスには、ストレージ、メッセージング、決済処理システムなどのサードパーティサービスといった独自の依存関係があります。
これらのサービスはすべて連携して、先ほど説明したユーザー体験を実現しています。そして、これはマルチテナントサービスであることを覚えておいてください。各テナントは個別のクリニックを表し、これらのサービスはすべて、常に複数のクリニックからのリクエストを処理しています。この分散アーキテクチャには、いくつかの利点があります。複雑さを分割して管理でき、各コンポーネントを独立してデプロイやスケーリングできます。しかし、サービス指向アーキテクチャがもたらすメリットの一方で、モニタリングに関する新たな課題も生じます。Observable（観測可能な）データやテレメトリーが散在し、あるコンポーネントの問題が多くのコンポーネントに影響を与え、システムに多くのノイズを生み出すため、問題の特定が困難になります。 顧客が診察予約をする際のデータフローを詳しく見て、インシデントにつながる一連の出来事を見ていきましょう。顧客が診察を予約すると、そのリクエストはフロントエンドサービスに送られます。このサービスは、DynamoDBテーブルに予約を記録する役割を持つVisitサービスにリクエストをルーティングします。今日は、普通ではない事態が起こります。あるクリニックが大量の予約リクエストを送信し始めるのです。おそらく、クリニック側に何らかの技術的な問題があるのでしょう。
この状況が発生すると、DynamoDBテーブルはテーブルに割り当てられた容量を超過したため、Visitサービスのリクエストの制限を開始し、スロットリングを行います。具体的には、読み取り操作は成功し続ける一方で、書き込みトラフィックが制限されます。このバックプレッシャーによってフロントエンドサービスのレイテンシーが増加し、最終的にこれらのリクエストは失敗し始めます。複数のクリニックで、オーナーたちは医療ケアを必要とするペットの緊急予約を取ろうとして苦労しています。
土曜の朝、ペットのオーナーが自分の犬が食事をしていないことに気づいたと想像してください。 彼らはペットの緊急診察を予約しようとしていますが、リクエストは失敗し続け、最終的にタイムアウトしてしまいます。これが私たちのシステムの可用性が及ぼす実際の影響であり、オーナーたちは他の医療機関を探すことになるかもしれません。クリニックは予約できなかった診察からの直接的な収益を失うことになります。これらすべてが私たちのビジネスに影響を与え、サービスを提供する能力に対する顧客の信頼を損なうことになります。
おそらく、この状況や似たような状況は皆さんにも馴染みがあるかもしれません。私自身、過去に何度も経験した問題と共通する要素があります。バックプレッシャーが複数のコンポーネントに影響を与える分散システムがあり、単一の顧客やデバイスが原因となるトップコントリビューター問題があります。 では、オペレーターの立場になって、フロントエンドサービスのアラームで呼び出されたと想定してみましょう。この時点で分かっているのは、Book Visit Availabilityが影響を受けていることだけで、この操作の重要性とサービスを復旧させることの重要性を理解しています。
ダッシュボードや他のアラームを確認したり、ログを調べたり、Runbookに従ったりするかもしれませんが、これらのデータはすべて散在しています。この問題を本当に診断するためには、少なくとも4つのことを理解する必要があります。まず、フロントエンドがVisitサービスへのリクエスト失敗によってエラーを起こしていることを理解する必要があります。 また、VisitサービスがDynamoDBテーブルのスロットリングによって影響を受けていることを理解する必要があります。 さらに、DynamoDBがどのように容量を管理しているか、リソースの設定、そしてプロビジョニングしたIOPS以上を消費しているためにリクエストがスロットリングされていることを理解する必要があります。 最後に、負荷の増加が単一のクリニックから来ていることを理解する必要があります。
必要な情報がさまざまな場所に散在していて、どこに行って、どのツールを使えばいいのかを覚えておく必要があります。これには多くの時間がかかり、時間がかかれば長くなるほど、サービスを復旧させるプレッシャーも大きくなります。でも大丈夫です。なぜなら、すでにAmazon Q Developerを設定して、自動的にトラブルシューティングを行えるようにしているからです。では、私の体験がどのようなものになるか見てみましょう。 今画面に表示されているのは、可用性メトリクスの低下によって発報したCloudWatchアラームです。 アラーム履歴を確認すると、すでに調査が作成されているアクションがあることがわかります。 Amazon Qがすでにこの問題に取り組んでいます。
その調査を見てみましょう。今お見せしているのは、Amazon Q Developerの調査画面です。中央のパネルには、調査に追加されたすべての発見事項が表示されています。これらの発見事項は、調査を進めながら証拠として収集できる事実だと考えてください。AWS Consoleを移動しながら、80以上のAWSサービスコンソールからメトリクス、ログ、その他の観察結果を調査に収集できます。現時点では、調査対象のアラームという1つの発見事項しかありません。上部には、Amazon Qが現在行っていることを示すステータスが表示されています。実は私がログインする前に、すでに分析を完了していました。 Suggestionsをクリックすると、サイドパネルが開き、確認できるAmazon Qからの保留中の提案が表示されます。Amazon Qは、並行してデータを見ている相方のオペレーターのように考えることができ、興味深い可能性のあることを提案してくれます。Amazon Qが観察を行うと、提案フィードを通じてそれを共有します。インシデントについてより多くの観察を行うにつれて、これらのシグナルを組み合わせてRoot Causeに関する仮説を導き出します。
中間的な観察結果に焦点を当てるために、ここでフィルターを適用してみましょう。 すると、いくつかのメトリクスが表示されます。SNSのメトリクス、 インスタンスでの書き込みバイト数の増加、そして失敗しているCanariesもあることがわかります。本当に興味深くて素晴らしいのは、私が何十ものダッシュボードを探し回る代わりに、Amazon Qがその重労働を担ってくれていることです。インシデントの状況を把握しようとする際に、並列処理と自動化の恩恵を受けることで、自分でデータを探す手間が大幅に減ります。単一のフィードで、調査に関連する可能性のあるメトリクス、ログ、トレース、変更イベントを確認できます。提案が良いと思えば、それを承認してフィードに追加できます。 提案が気に入らない場合は、破棄してフィードから削除することもできます。
これらのメトリクスの意味がわからない場合はどうすればいいでしょうか？実際、提供されているメトリクスのツールチップをクリックして、それらの意味をインラインでAmazon Qに尋ねることができます。これにより、ドキュメントを探して、これらのシグナルが何を意味するのかを理解する必要がなく、インラインで説明を得ることができます。2番目のタイプの提案は仮説なので、それを見るためにフィルターを適用してみましょう。ここで、Amazon Qが生成した仮説を見ることができます。 DynamoDBテーブルで書き込みリクエストが増加し、それによってスロットリングとレイテンシーの増加が発生したことが説明されています。Visitsサービスとフロントエンドサービスに影響を与えたシステムへの影響も説明されています。さらに、負荷増加の主な要因となった特定の顧客を特定し、ホットパーティションやホットキーの問題の可能性も示唆しています。また、トラブルシューティングを続けるための次のステップも提供されています。
この調査に不慣れなので、この仮説に至った具体的な証拠を見てみたいと思います。そのためには、Show Reasoning リンクをクリックすると、Amazon Qがこの仮説のために選択した具体的な証拠が表示されます。 ここでは、DynamoDBからのスロットリングされたリクエストを確認できます。また、個々の顧客を特定するContributor Insightsルールも確認できます。 先に進む前に、Contributor Insightsをご存知の方はいらっしゃいますか？あまり多くないようですが、それで問題ありません。Amazon Qは、皆さんがそれらを意識したり、いつ使うべきかを知っている必要なく、CloudWatchのこれらの機能を活用できます。これは良い仮説だと思うので、この仮説を承認して、記録のために調査に追加することにします。
仮説を受け入れ、問題を診断した後も、問題を緩和するために適切なアクションを検討する必要があります。緩和策には複数のオプションがあるのが一般的です。この場合、いくつかの選択肢を考えることができます：テーブルのプロビジョニングスループットを増やすことで、ベースラインコストは上がりますが、テーブルへの負荷を増やすことができます；オンデマンドに切り替えることでテーブルを動的にスケールできますが、コストが変動的になります；Auto Scalingを有効にすることもできますが、適切なAuto Scaling設定を考える時間を取りたくない場合は、この選択肢は避けたいかもしれません。また、顧客側のスロットリングが可能であれば、それも検討したいところです。
この特定のケースでは、実際にどこから負荷がかかっているのかわかりません。クリニック側の問題なのか、それとも正当なトラフィックなのかわからないため、できるだけ早くこの状況から抜け出したいと考えています。ここで、Amazon Qがこの仮説に対していくつかのアクションを特定し、 このコンソールから直接実行できるAWS管理のRunbookを推奨してくれています。また、DynamoDBについて とこのケースにおけるキャパシティ管理についてより理解を深めるためのドキュメントも提供されています。この例では、問題を緩和し、他の顧客への影響を制限するために、テーブルのプロビジョニングスループットを増やすことにします。
Runbookを表示すると、具体的な手順 と、このRunbookを実行するために必要な権限が説明されています。このRunbookを実行する際は、 他の権限や昇格された権限ではなく、私自身が持っている権限が使用されます。そのため、私自身が許可されていないアクションは実行できません。
では、このRunbookのパラメータを入力していきましょう。読み取りキャパシティは影響を受けていないことがわかっており、このインシデントについて少し知識があるので、書き込みキャパシティを20に増やすことにします。 Runbookを実行するアクションが調査に記録され、その結果をモニタリングできるリンクが提供されます。これには数分かかりますので、ここでお待ちいただくことはしませんが、実行されるとテーブルのキャパシティが増加し、アラート状態が解消されます。
次のステップとしては、カスタマーケアチームと協力して、このトラフィックを発生させているクリニックに連絡し、真の根本原因に対処することになるでしょう。最後に、調査を終了し、 最終的なメモを残すことができます。これにより、次回このアラームが発生した際には新しい調査が作成され、Amazon Qがその問題の調査を開始します 。
とても素晴らしい例でしたね。私のサービスのAPIの可用性低下によって発生したアラームに対応しましたが、Amazon Qからの提案をすぐに確認することができました。これらの提案には、単純な観察結果だけでなく、根本原因を正確に特定し、主要な要因まで突き止めた、明確な証拠に基づく仮説も含まれていました。クエリを実行したりデータを探したりすることなく、問題を緩和するための短期的なアクションを特定することができ、無事に復旧することができました。
AWSコンソールの使用に加えて、多くのお客様は社内でSlackのようなツールを使用しており、私の所属チームも特にSlackをほとんどのコミュニケーションに使用しています。そこで、Amazon Qもこれらのオペレーションチャンネルに参加できるようにすることは素晴らしいアイデアだと考えました。その様子をお見せしましょう。こちらが私のオペレーションチームのSlackチャンネルです。Amazon QをSlackと連携させ、オペレーションチャンネルに参加するように設定しました。ここでQからの最初のメッセージは、Book Visit Availabilityの調査を開始したことを示しており、スレッドが作成されています。調査対象のメトリクスをSlack上で直接確認することができます。
ここでの2番目のメッセージは、先ほどの提案フィードと同様のものです。Amazon Qが投稿するすべての提案は、このフィードでSlack上で直接確認することができます。そして最後に、根本原因に関する仮説を含むスレッドがあり、AWSコンソールにログインすることなくここで確認できます。 このように、サービスのAPIの可用性低下によって発生したアラームに対応し、Amazon Qからの提案をすぐに確認してインシデントを解決することができました。
Amazon Q Developerの導入方法とセッションまとめ
では、セッションの最後のパートに移りましょう。実際に始めるために必要なことは何でしょうか？Amazon Q investigationsを使い始めるために必要なことには、2つのカテゴリーがあります。必須事項として、Investigation Groupの作成があります。このグループは、調査のためのコンテナのようなもので、Amazon Qがリソースやテレメトリにアクセスする際に使用する権限や、暗号化の設定、保持期間、Slackなどのサードパーティ統合といった共通の設定を適用できます。これを設定すれば、サンプルの調査を使用したり、過去に発生した問題を遡って調査する実験を始めたりすることができます。
2つ目のカテゴリーは、ベストプラクティスと呼んでいるものです。これらは、運用インシデントの調査においてAmazon Qの価値とパフォーマンスを最大限に引き出すために実施できることです。Amazon Qが環境を適切に分析するためには、ワークロード間の関係、その依存関係、および発生するテレメトリを理解する必要があります。環境の最も正確なビューを構築するために、Application Signals、AWS X-Rayを有効にし、CloudWatchやFluent Bitのエージェントをアップグレードして、最新の機能を活用することをお勧めします。
これらの接続を設定していない場合、システムが推測を試みますが、その推測には確率的な誤差が伴います。CloudTrail logsを有効にすることをお勧めしています。実際、多くのお客様がすでにCloudTrail logsをCloudWatchに送信しています。これにより、Amazon Qはインシデントのトリガーとなった可能性のあるリソース設定の変更をCloudTrailを使用して検出できるようになります。最後に、アラームを設定して自動的に調査を作成することができます。1つのコンポーネントに対して異なる機能のための複数のアラームが設定されているのは珍しくありませんが、チケットシステムと同様に、関連する問題で同時に発生する可能性のあるこれらのアラームのそれぞれに対して調査を作成したくないかもしれません。これを避けたい場合は、調査アクションを紐付ける複合アラームを作成することをお勧めします。
Amazon Q operational investigationsには、あなたがどこにいても利用できる多くのエントリーポイントがあります。先ほど説明した例は、CloudWatchアラームのアクションとして事前に設定された自動トリガーの調査でした。また、「なぜページングを受けたのか」というような質問をQ Chatに投げかけることもでき、次のステップについてのガイドを受けることができます。さらに、ダッシュボード上のスパイクから調査を開始することもできます。80以上のAWSサービスコンソール全体に組み込まれたテレメトリーから調査を開始できます。これを今からお見せしたいと思います。
ここでフロントエンドサービスのサンプルダッシュボードをお見せしています。Book Visit Availabilityの問題を少し変更して続けていきます。ここで、他とは少し異なる可用性の低下が見られます。これを調査したいので、調査したい領域にズームインすることができます。このツールチップをクリックし、調査を選択して新しい調査を開始できます。調査にタイトルを付けて開始できます。この分析には数分かかるので、すでに実行したものをお見せしたいと思います。
この例では、負荷の増加が原因だったインシデントを修正し、代わりにDynamoDBテーブルに対して誰かが行った変更が問題の原因となっています。実は私がテーブルのリソースポリシーを変更し、すべてのトラフィックを拒否するようにしてしまったのです。これはあまり良いアイデアではなく、もっと良い変更管理ポリシーを実装する必要があるかもしれませんが、こういうことは起こり得ます。Amazon Qが提供した提案を見てみましょう。ここでVisitRegistrationsテーブルでPutItem操作を実行しようとした際に認証エラーが発生し、これがVisitsサービスとフロントエンドサービスに影響を与えたことがわかります。
ここで非常に興味深い部分をお見せしたいと思います。「Show Reasoning」をクリックすると、ユーザーのアクセスが拒否されたことを示すログを確認できます。また、キャプチャーされて記録されたCloudTrailの変更イベントも確認できます。そのリンクをクリックしてCloudTrailイベントを自分で確認し、具体的にどのような変更が行われたのかを見ることができます。すべてのトラフィックを拒否したポリシーを確認でき、さらに誰が実際にその変更を行ったのかを特定し、これが再び起こらないようにするために何をすべきかを把握することができます。
このケースでは、AWSのサービスコンソールの各種埋め込みダッシュボードから、Amazon Qをどのように起動できるかをご紹介しました。また、リソース設定の変更によって問題が発生した場合に、CloudTrailを使用して根本原因を特定する方法もお見せしました。先ほど申し上げたように、この新しいQ機能を使えば、アラームからでも、Qチャットからでも、そしてAWSサービスコンソールの埋め込みダッシュボードからでも、調査を開始することができます。
これによって、皆様の次回のオンコール対応が少しでも楽になれば幸いです。それでは、本日のセッションの重要なポイントをまとめるために、Nikhilにバトンをお渡しします。
Jaredさん、素晴らしいデモをありがとうございました。セッションのまとめとして、本日の内容の要点を振り返ってみましょう。まず、AIOpsの進化について説明し、業界がインシデント管理とRoot Cause対応において、純粋なルールベースやMLベースの統合から、複数の手法を組み合わせたアプローチへと移行していることをお話ししました。AIOpsは確かに一つの旅路であり、私たちは一歩一歩前進しています。また、過去12ヶ月間にリリースしたCloudWatchの機能、特にログパターンや異常検知、自然言語クエリ生成など、データとの対話をよりスムーズにする機能についても簡単に触れました。
次に、本日Matt Garmanのキーノートで発表した新機能について説明しました。この機能は、AWSクラウド環境とリソースへの深い理解に基づいて、AWS環境全体での運用調査を加速させるものです。Amazon Q Developerは、環境内の異常を検出し、調査すべき関連シグナルを表示し、潜在的な根本原因を特定し、問題をより迅速に解決するための次のステップを提案します。最後に、この機能を使い始めるために必要な手順として、Investigation Groupの作成やQ Developerの権限設定について説明し、さらにこの新機能からより質の高い提案を得るためのベストプラクティスもご紹介しました。その中には、X-Rayを使用したアプリケーションシグナルや、最新のエージェントの使用などが含まれています。繰り返しになりますが、これらは必須要件ではありませんが、より良い体験を得るために役立ちます。
そして最も素晴らしいことは、本日ご紹介したすべての機能（運用調査に関する最新機能を含む）が、追加費用なしで今すぐにご利用いただけるということです。これまでは、これらの作業を行う際に、新しいダッシュボードの作成やアラームの設定、メトリクスやログの大量のデータスキャンが必要でしたが、私たちの調査機能がそれらを担ってくれるため、もはやそのためのコストを支払う必要はありません。私たちは、AIOpsを活用することで、今日では専門知識と試行錯誤の両方を必要とするデータ間の本質的なつながりを浮き彫りにし、運用を効率化できると確信しています。このAIによるアシストと人間主導の体験の組み合わせは、責任を持って使用することで非常に強力なツールになると私たちは固く信じています。現在の機能と、この分野への継続的な投資がもたらす将来の可能性の両方に、大きな期待を寄せています。
本日のセッションをお楽しみいただけたことを心より願っております。この機能をぜひ近いうちにお試しください。スタートするにあたってサポートが必要な場合は、私たちのどなたにでもお気軽にご連絡ください。最後に、モバイルアプリでセッションのアンケートにご協力いただければ幸いです。皆様からのフィードバックは私たちにとって非常に重要で、今後のセッションを皆様にとって最も価値のある内容にするために役立てさせていただきます。誠にありがとうございました。ここでMihirとJaredに戻ってきていただき、改めて皆様のご参加に感謝申し上げます。これらの機能やCloudWatch全般についてご質問がございましたら、この後15分間、この場に残っておりますので、お気軽にお声がけください。誠にありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion