こんにちは、MSPの田所です。
AWS re:Invent 2024 のレポートです。
現場のイベント模様をお届けします。
セッション情報
[NEW LAUNCH] Investigate operational issues faster with AI
生成AI の力で運用の障害調査をパワーアップしましょう！
Troubleshooting operational issues can be challenging, especially when you’re trying to focus on innovating. In this session, discover how to enhance your operational efficiency and extract valuable intelligence from your observability data by harnessing new and existing Amazon Q Developer, Amazon CloudWatch and AWS Systems Manager features to recapture your time. Learn how Amazon Q acts as another member of your operational team, analyzing your AWS configuration and observability data and presenting hypotheses about the cause of impact. Once you’ve diagnosed root cause, Amazon Q provides tailored suggestions for remediation using an AWS library of curated runbooks so you can quickly remediate the issue.
Amazon Q が蓄積データや設定情報から、障害の原因推測や修復方法を提案してくれます！
Session types: Breakout session
1時間の Breakout セッション
今回のまとめ
- AIOps で運用の問題解決が楽になる
- CloudWatch Investigations で原因推測と解決策の提案をしてくれる
- 修復作業自体も Investigations のコンソール上で完結できる
セッションの詳細
1. 受動的な監視 と AIOps
まずは典型的な監視とその対応の説明です。
アラームが発生して、何が起きているのか理解するのに時間がかかり、問題の原因調査を行い、復旧を試みるが上手くいかず、さらなる調査で遂に根本原因を特定し、最終的に解決に至る。
かなり身に覚えのある流れですね。
そこに AIOps を取り入れると大きな助けになると言います。
AIOps とは機械学習を利用して人力の作業を模倣したりサポートしたりするものです。
データ不足などにより人間がお手上げになるものを解決するような魔法ではない、と強調されていました。
2. AWS の AIOps
AWS で利用できる AIOps にはどのようなものがあるのでしょうか。
まずは機械学習や生成AI を労力少なく利用するためのサービスがあります。
- Amazon SageMaker で機械学習モデルを取り扱う
- Amazon Comprehend で自然言語処理用のデータを前処理する
- Amazon Bedrock で検索拡張生成を行う
それから AI が組み込まれた AWS サービスもあります。
- Amazon CloudWatch metric anomaly detection でメトリクスの異常検知を行う
- Amazon CloudWatch Logs anomaly and pattern analysis でログの異常検知やパターン分析を行う
- Amazon DevOps Guru でアプリケーションの異常動作を検出する
- Amazon Q Developer Investigations で運用の問題の原因調査と修復の提案を行う
そして人力、AI 問わず、運用において以下のベストプラクティスを守ることで、問題解決を早められると言います。
- ライブラリを統一する
- 情報に文脈をつける
- メトリクスを標準化する
- メトリクス、ログ、トレースなどテレメトリーを複数見られるようにする
3. CloudWatch Investigations
そして CloudWatch の新しい機能の紹介です。
まず、関連リソース、テレメトリーへの推移が簡単になりました。
従来はアラームから対象リソースのテレメトリーを見に行って、関係していそうな別のテレメトリーやサービスを探して、そこから原因を推測していく必要がありました。
それが、CloudWatch のコンソール上で関連するメトリクスやサービスが表示されるようになり、クリックだけで関連情報を集められるようになりました。
そして Investigations の機能が登場します。
CloudWatch で Amazon Q Developer が使えるようになったというものです。
アラームを起点に、その原因の推測や修復までのステップを提案してくれます。
自動で CloudWatch や AWS Health イベントの情報を収集してくれるというので驚きです。
AWS コンソールを横断しながら使える機能ということで、幅広い利用シーンがありそうですね。
Amazon Q Developer がアラートに対して、依存関係を調査し、テレメトリーや設定情報、デプロイ状況などを分析、要約します。
そして根本原因の仮説と、その解決策を提案します。
ここで人間がやる必要があるのは、提案されたいくつかの仮説から疑わしいものを確認し、提案された解決策を実施し、改善を確認することです。
アラートの状況把握から行う場合と比べて、問題解決が格段に楽になりますね。
例えば Lambda のコンソールからモニターを確認すると、他の関連サービスやテレメトリーに1クリックのみで遷移できます。
Investigations で考えられる原因をいくつか推測してくれます。
さらに修復方法を提案してくれます。
簡単なものであれば Investigations のコンソール上で修復作業が可能です。
遂にここまで来たのか、、！
と良くも悪くも衝撃のセッションでした。
MSPとして
レベルを一段引き上げる
技術が進歩するにつれてシステムは複雑になり、単純なインフラ監視だけでは太刀打ちできなくなってきている話はオブザーバビリティの文脈でよく聞きます。
今回、原因調査や修復が格段に楽になる CloudWatch の新機能が発表されました。
そうすると原因調査と復旧ができるだけではもはや価値にはならず、それらを前提としてその一歩先のサービス価値を提供する必要があります。
MSPも技術革新に合わせて姿を変えていかなければと強く感じました。
おわりに
追加の [NEW LAUNCH] セッションを見つけたため参加してきました。
こういったイベントは宝探しのようでワクワクしますね。
そして新機能が便利すぎて、自分の存在意義が問われるようなゾクゾクも感じました。
使いこなす側にならなければ、と気持ちを新たにするのでした。
おしまい
