COLUMN

ChatOpsを活⽤したインシデント管理の⾃動化

セッション名：COP313-R3 | Automate incident management of modern workloads using ChatOps

※セッションタイプ：Builders' Session（9⼈ほどの参加者に対して1⼈SPEAKER（インストラクター）がついて、ハンズオンを進めていく形）

Slack∕Teamsへのアラート通知にとどまらず、そこからLambdaの実⾏やSSMコマンドの実⾏をするという内容でした。以前からあるテクニックのようなのですが知らなかった＆完全に⾒落としていました。

設定の仕⽅は⾮常にシンプルでした。AWS Chatbot経由でSlackに通知できるようにすれば、下記ボタンを押すことで

アクションをSlack上で設定できます。

Slackに通知が来てから、DynamoDBを変更するLambdaを実⾏する必要があるケースに有⽤だと感じてます。⼊⼒値などを可変にできるか等はこれから検証していきます！

適切なアラームと AIOps でインシデント管理を改善

セッション名：COP307-R1 | Improve incident management with the right alarms and AIOps

※セッションタイプ：Workshop（re:Play後の⾦曜⽇朝⼀のセッションでしたが参加者は結構いました。2⼈のSPEAKER（インストラクター）と6⼈ほどAWSスタッフがいて質問し放題でした。）

システム構成はこのような形です。監視しているシステム⾃体は⾮常にシンプル。

CloudWatch Application Insightsを活⽤したリソースの管理

リソースグループを作成し監視したいリソースなどを選択すると、各種アラームとメトリクスの監視が⾃動的に設定されました。

システムの拡張や同じデータベースを利⽤する別⽬的のシステムの導⼊があったので、さっそく導⼊したいと感じました。

ちなみに、Keynoteで発表された『Application Signals』との違いを聞いてみたところ、『Application Insight』は過去のメトリクス等の確認に利⽤、『Application Signals』はSLOを確認することができるとのこと。あとは、『Application Signals』はEKSの監視などにも強いようです。私の英語⼒で理解できたのはここまで。。。。的外れな質問だったかもしれませんが、丁寧に教えてくださいました。

そして、私たちも昨⽇知ったのよ、とおっしゃっていたのが印象的でした！

Amazon DevOps Guruを活⽤した問題解決の迅速化

こちらも前々からあった技術らしいのですが、私は初⾒だったAmazon DevOps Guru。。。Amazon DevOps Guruを利⽤するとどんな運⽤ができるかをご紹介します。

①メトリクスの確認

エラー内容に関係のあるメトリクスを確認できました。⼤量にリソースがあるシステム等特に有⽤だと感じました。

エラー内容に関係のあるメトリクスの確認

タイムラインではいつから始まったエラーなのかを確認可能

②エラーの原因として考えられそうなCloudTrailのログ表⽰

すごいと感じつつ、開発メンバーが多かったり、誰かの操作によるエラーがたびたび⽣じている場合に便利な機能という印象です。

③推奨事項が表⽰される

問題解決につながりそうな提案を複数してくれるようです。驚きでした！

Amazon DevOps Guruに関しては、料⾦の問題や⾃分のシステムに本当に必要なのかと思うところがあったので、もう少し知⾒を深めてから構築したシステムへの導⼊可否を判断しようと思います。

最後に

改めて、知らないって怖い、構築するときにここまで見ていなかった、と思う点が多くありました。総じてre:Inventは本当に貴重な学習の機会でした。⽇々更新されるAWSに置いていかれないように、よく使うリソースだけに視野が狭まらないようにしようと思いました！