その運用、まだ人が抱えますか？ AWS DevOps Agentの価値 -

Transcript

1. その運⽤、まだ⼈が抱えますか？ - AWS DevOps Agentの価値 クラスメソッド株式会社 クラウド事業本部運⽤イノベーション部 ⼤野育海∕礒松和佳奈
2. 運用監視現場のリアル 2 あなたの現場でも起きていませんか？ 大量のアラート地獄 夜間対応 慢性化した人手不足 本当に拾うべき1件が 深夜のモニタールームで 度重なる人員交代による ノイズアラートの中に埋もれていく 鳴り響くアラート通知音 ナレッジ不足と属人化
3. アジェンダ 1. AWS DevOps Agentとは 2. AWS DevOps Agentの活用 3. AWS DevOps Agent ユースケース 4. まとめ 5. 事例紹介 3
4. AWS DevOps Agentとは
5. AWS DevOps Agent インシデントを 調査(根本原因特定)・解決策を提示・予防する フロンティアエージェント 特徴 1 インシデント内容と解決策を提示 インシデントを調査し、根本原因の特定を支援。 「常時稼働の自律的オンコールエンジニア」として 24×365で稼働。 特徴 2 将来のインシデント予防 過去のインシデントのパターンを学習し、"次に同じ障害を起こさないためにどうすべきか"を提案。 監視の強化・インフラの改善・デプロイの安全性向上・障害からの復旧力強化の4つの観点で、具体的な改善策 を示してくれる 4
6. AWS DevOps Agent 5 既存ツールと 統合 オブザーバビリティ ツールと統合 デプロイ履歴を活用した 原因調査 チャットツールと連携 Amazon CloudWatch、 GitHub や GitLab のコードリ ServiceNow / PagerDuty / Dynatrace、Datadog、New ポジトリ、CI/CD パイプライ Slackに調査結果・根本原因・ Relic、Splunkと標準で統合。 ンと統合。コード変更やデプ 推奨アクションを共有。 画面キャプチャを貼り付けず ロイ履歴をテレメトリと関連 独自MCP サーバも接続でき、 に、各ツールの監視データや 付けて、障害やパフォーマン 社内ツールなどにまで拡張可 アラートを直接読み取ること ス低下の原因調査に活用でき 能。 ができる。 る。
7. AWS DevOps Agentの活用
8. 費用対効 果 6 Webアプリの[API Error]をAWS DevOps Agentに調査させてみた結果・・・ DevOps Agent が裏でやっていたこと CloudTrail から 5回 のデプロイ履歴を時系列で取得 CloudTrail：3 min 51 sec Lambda関数のログを横断クエリ・エラー突合 Logs Insights：8 min 17 sec Lambda Errors / API Gateway 4XX・5XX を 期間比較 CloudWatch Metrics：7 min 21 sec DynamoDB 2 テーブル の PutItem 失敗を特定 DynamoDB：2 sec 関係する API エンドポイント 4 本 を逆引き API Gateway：10 sec CloudFormation ChangeSet と 原因コミット を関連付け CloudFormation：6 min 26 sec 調査時間合計：約 12 min 並列実行
9. 費用対効 果 7 Webアプリの[API Error]をAWS DevOps Agentに調査させてみた結果・・・ これを人力でやるとしたら、どれくらいかかりますか？ DevOps Agent が裏でやっていたこと CloudTrail から 5回 のデプロイ履歴を時系列で取得 CloudTrail：3 min 51 sec Lambda関数のログを横断クエリ・エラー突合 Logs Insights：8 min 17 sec Lambda Errors / API Gateway 4XX・5XX を 期間比較 CloudWatch Metrics：7 min 21 sec DynamoDB 2 テーブル の PutItem 失敗を特定 DynamoDB：2 sec 関係する API エンドポイント 4 本 を逆引き API Gateway：10 sec CloudFormation ChangeSet と 原因コミット を関連付け CloudFormation：6 min 26 sec 調査時間合計：約 12 min 並列実行
10. ベストプラクティス 8 STEP 1 本番環境と非本番環境を分ける Agent Spaceを Agent Spaceはエージェントが調査できる範囲。 まずは運用監視チームの責任範囲に合わせてスコープを設計し、本番環境とステージング／開発環境を 分けて管理する。 攻略しよう ポイント 調査に必要な情報を含めつつ、対象を広げすぎない STEP 2 IaCで設定を標準化する * Agent Space IAMロール・外部統合、タグをCDK / Terraformでテンプレート化。 ・AWS DevOps Agentが調査できる範囲を決める 複数アカウントの場合でも一貫した設定で展開できる。 単位 ポイント ・対象となる AWS アカウント、外部ツール連携、 手作業(GUI操作)ではなく、同じ品質で横展開できる状態を作る 調査参加メンバーをまとめて管理 ・AWS DevOps Agentの運用において、 核 となるリソース STEP 3 調査データを繋ぐ CloudWatch／Datadog／New Relic／GitHub／Slackなどを繋ぎ、対象環境の調査範囲 を拡げることで、原因調査の精度を向上させる。 ポイント エージェントが見られる情報を増やすことで、調査の精度が上がる
11. 9 アラート重要度で 線を引く 運用が AWS DevOps Agent のコストを正当化する High アラート重要度 Amazon CloudWatch チケット管理ツール (ex. PagerDuty) Midium Low
12. AWS DevOps Agent ユースケース
13. ユースケースと動作フロー 1. Lambda実行時にエラーが発生！ 2. CloudWatch Alarmで検知、SNSに配信 3. SNSからPagerDutyにAPI経由で連携 4. PagerDutyでイベント整形/フィルタリングを実施の上で、インシデント起票 5. DevOpsAgentがキックされ、インシデントの内容をもとに調査を開始 6. エラーログおよび、連携しているGitHubリポジトリを含め包括的に調査実施 7. GitHubのコミット履歴から、最終更新時のコードソースにバグがあることを発見 8. 調査結果をPagerDutyのインシデント（メモ）に追記 10
14. 全体図 - Lambdaのエラー調査
15. マルチアカウント対応 • セカンダリアカウント側でIAMロールを作成し、信頼関係を設定するこ とで、プライマリアカウントの調査対象にできる • メンバーアカウントで発⽣するリソースやセキュリティの問題を、管理 アカウント側で横断的に調査することが可能 • 前提条件 ◦ プライマリアカウントの AWS DevOps エージェントコンソールへの アクセスが可能 ◦ セカンダリ AWS アカウントへの管理アクセスが可能 ◦ セカンダリアカウントでロールを作成するIAMアクセス許可がある 13
16. 全体図 -マルチアカウント-
17. まとめ
18. まとめ（ベストプラクティス） 15 • スコープとパフォーマンスのトレードオフを理解する ◦ 自組織において最適な、Agent Spaceの分割範囲を考える ◦ アプリ単位、環境単位（本番/環境）、チーム単位etc… • 適切なアクセス制御を設定する ◦ 調査の閲覧、サポートケースの起票、Agent Spaceなど、誰がどこまで操作して良 いのかを明確にして、ポリシーによる制御を実施する • 接続する機能を増やす ◦ 各種監視ツールやコードリポジトリなどデータソースが多いほど、根本原因分析の 精度向上が期待できる • 調査結果に基づいて設定値を調整する ◦ 調査結果に応じてAgent Spaceのスコープ見直しを実施する
19. まとめ（機能⾯） • DevOpsAgentの強み（＝価値） ◦ 周辺ツールとの豊富なネイティブ連携 ◦ 第一歩の敷居が低い （GUIで導入可能） ◦ CDK、Terraformを利用したIaCでのデプロイも可能 ◦ マルチアカウント設定 による、組織内アカウントの横断的な調査 16
20. まとめ（機能⾯） 強みを引き出すためのオススメの使い方 • 渡すデータ（イベント）の前処理をしてあげる ◦ 必要なイベントやアラートだけ調査させる ◦ 監視設定や、ノイズ削減について見直す ◦ 重要インシデントの見逃し軽減、利用料金の削減、Agentの学習の効率 化、など効果が期待できる 上記は一例です 環境に応じたベストな使い方を模索しましょう！ 17
21. 事例紹介 (運用支援について )
22. 事例紹介（株式会社ミラクル経理 様） 18 クラスメソッドマネージドサービス ご⽀援ポイント ⼈員不⾜、ノウハウ不⾜により課題となって いたインフラ運 ⽤ 監 視に対して、24/365の MSPをご提供。 インシデント発⽣時の確認や対応をオフロー ドいただくことで、インフラ運⽤の負荷を⼤ 幅に低減。 豊富なナレッジに基づき、弊社からの改善提 案を適宜実施。 before after • ⾃社開発のSaaSを⽴ち上げたいが、AWS基盤の運⽤ノウハウが不⾜ • ローンチまでにインフラ運⽤までを内製するのは現実的でない • 継続的な監視‧運⽤による負荷を軽減したい • • • • 解決策として「クラスメソッドマネージドサービス」をご提供 AWSインフラ基盤に対する24/365のインシデント監視 インシデント発⽣時の⾃動通知、対応状況の可視化 インシデントの内容に基づき、プロアクティブな改善のご提案 お客様の声 「軽微なアラートが⾃動でクローズされ、そ の内容が共有される仕組みは⼤きな助けに なっています。状況の把握や対応⽅針につい て整理された情報を受け取れる点は、⼤きな 安⼼材料になっています。すべてを⾃分たち で追い続ける必要がなくなりました。」
23. 事例紹介（某⼤⼿⼩売事業会社 様） [Before] ・CCoEチームを立ち上げたものの、 将来像や活動範囲の定義が無く、 活動が個人の場当たり的な対応に。 19 [After] ・クラスメソッドの知見を元にした ガイドラインやサービスカタログを整備。 ・運用の属人化により、スキルの標準化が 図れておらず、運用品質がバラバラ。 セキュリティ運用の穴も不安な状態。 CCoEチーム ・お客様業務を理解の上で、組織目標や役割等 を提案・再定義。業務が回るまで伴走支援。 → スキル平準化による運用品質向上と、 ガバナンス/セキュリティの強化を実現。 CCoEチーム コスト 削減 クラウド 利用促進 サーバー運用 セキュリティ 運用 クラスメソッド オペレーション成熟化支援 チーム 組織目標 ガイドライン サービスカタログ SLA/KPI の検討・定義 中長期目標・計画策定 etc.. ルールひな型・標準化