【AWS re:Invent 2024】CloudWatch でサービスレベルを向上しよう [COP355]

こんにちは、MSPの田所です。

AWS re:Invent 2024 が始まっていますね！
現場からイベント模様をお届けします。

セッション情報

Leveraging intelligent CloudOps to achieve service-level objectives

SLO 達成に役立つ CloudWatch の機能を紹介します！

As your workloads and infrastructure grow, monitoring thousands of metrics, millions of logs, and numerous errors can become overwhelming—even for dedicated experts. Artificial intelligence (Al) and machine learning (ML) can help you simplify cloud operations at scale. In this chalk talk, explore setting up an intelligent operations platform, combining observability and event-driven automation. Learn how to analyze observability data to understand issues and identify root causes using Amazon CloudWatch. Finally, see how to implement event-driven architectures to trigger automated actions, enabling proactive resolution and reducing manual effort.

CloudWatch にはサービスレベルに貢献する機能が備わっています！

Session types: Chalk talk

1時間のチョークトーク

今回のまとめ

• 機能は色々あるが、ビジネスに役立つ機能を使うことが大事
• CloudWatch は監視のみならず、調査に役立つ機能が充実している
• 生成AI を活用した機能のデモ

セッションの詳細

1. SLI, SLO, SLA について

企業としてビジネスで達成したいこととは何でしょう？
それは売上や利益かもしれません。はたまた理想の社会の実現かもしれません。

その中でアプリやインフラの担当ができることは何でしょう？
新機能の実装かもしれませんし、ダウンタイムの低減かもしれません。

いずれにしても大抵の場合、目標や KPI として表されます。
そしてその下に紐付くマイルストーンは常に目標を支えるための指標であるべきです。

企業が顧客にサービスを提供する際、しばしばサービスレベルの取り決めがなされます。
どのくらいのクオリティを前提としてサービス提供を行うか、期待値を合わせておくためのものです。

その文脈でよく SLI, SLO, SLA という言葉が出てきます。
これらはどんな意味なのでしょうか。

• SLI (Service Level Indicator)
  • サービスパフォーマンスの一部分を測る指標
  • 可用性、レイテンシ、エラー率など
• SLO (Service Level Objective)
  • サービスやアプリケーションのパフォーマンスや可用性の数値目標
• SLA (Service Level Agreement)
  • 提供するサービスの品質やパフォーマンスの期待値に関する契約

お客様との合意事項が SLA、社内で現実的に達成したい数字が SLO、そこに影響を及ぼす指標が SLI ですね。

2. COAA サイクル？

CloudWatch にはオブザーバビリティのための機能が多数備わっています。
メトリクス、ログ、アラームを使えば、リアルタイムの監視と通知が可能になります。
また Application Signals では、サービスの管理、外形監視、アプリ監視、SLO 管理など顧客視点の情報を扱えます。
さらに生成AI を活用してクエリの作成や原因推測を行う機能も登場しています。

ここでプレゼンターが、サービスレベル向上のためのサイクルを提唱します。
以下のように Collect → Observe → Analyze → Act の順で回して、サービスレベルを下げる要因を排除していくというものです。

会場からも意見を出し合い、それぞれどんなサービスが当てはまるか書き出していきます。

• Collect（データの収集）
  • メトリクス、ログ、トレース、X-Ray、OpenTelemetry
  • CI/CD で収集設定を自動化
• Observe（データの整理、可視化）
  • ダッシュボード（インフラとビジネス）
• Analyze（データの分析）
  • メトリクスとアラーム
  • ログとクエリ
• Act（修復活動）
  • SSM Automation で対応自動化
  • CloudWatch Application Signals からアクションをトリガー

各ステップを見ても、CloudWatch が大部分をカバーしていることが分かります。
優秀ですね。

そして改めて、アクションを起こす時には、それがビジネスに紐付いているかが重要、と念押しがありました。

 

3. 生成AI が原因を推測してくれる

今回、生成AI を利用した CloudWatch の機能のデモもありました。
CloudWatch Transaction Search という機能で、X-Ray で取得したトレースをクエリ検索可能です。

そして CloudWatch Investigations という新機能の紹介もありました。
Amazon Q Developer と統合されており、自然言語で状況把握、原因調査を行うことができます。

Webサイトのエラー率が高いのは、DynamoDBのスロットリングが原因で、書き込みキャパシティが不足している、というところまで突き止めてくれていました。

これは便利すぎる、、！

今後トラブルシューティングの世界は一体どうなっていくのでしょうか。

MSPとして

1. MSPにおける原因分析の難しさ

MSPはアラートの一次対応を担う部隊です。
そのため別チームが構築、二次運用を担当している案件が多くを占めます。
その中で障害が発生した際、構成を熟知していないシステムの原因分析は時に難しくなります。
ここに AI を活かした原因分析や、アラートの仕分けができたら、大きな助けになります。
今回取り上げた CloudWatch で Amazon Q Developer を活用できる機能は、MSPの対応を大きく広げることになるかもしれません。

2. 復旧作業の自動化レベルを引き上げる未来

現在 cloudpack では AMS と呼ばれる、一次対応自動化の社内ツールを活用しています。
これにより、アラートの種類に応じた自動アクションを実行することができ、迅速なチェック、復旧、連絡が可能となっています。

• cloudpack – 運用自動化ツールで効率的な運用を実現

非常に大きな工数削減に成功した AMS ですが、まだ全てのアラートに適用できている訳ではありません。
分岐の多い複雑なシナリオや、コンプライアンス要件の厳しいお客様には利用できないケースがあるためです。
これら分岐や、分岐に応じたアクション、その結果の判定などを簡単に設定できれば、また自動化のレベルも引き上がると感じました。
ここも AI が活躍する領域の予感です。

おわりに

弊社の強みの一つが 24/365 で有人対応していることなのですが、今回見てきたような生成AI を活用した機能の充実は大きな波を感じます。
「人がやらなくてもよいこと」と「人がやる方が望ましいこと」、その境界の動きは速くなってきており、MSPとして提供できる価値を追い続ける使命があると思うのでした。

おしまい