CloudWatch Application Signalsの紹介LT資料
2024年1月19日に開催されたAWS re:Invent 2023 re:cap LT大会に参加してきました。1分LTというチャレンジングな試みに対して新しいベスプラが確立したりと、とても楽しいイベントでした。「待ち人来る？CloudWatch Application Signals」というタイトルで発表してきたので、その資料とざっくりまとめです。
資料
内容
公式アナウンスです。色々書かれていますが、色をつけた部分、特にハイライトした部分がポイントだと思います。アプリケーションを運用する目的はビジネス目標の達成であり、その達成に寄与・影響する性能指標を管理できるようになりました。いわゆるサービスレベル管理というやつですね。
ビジネスKPIと連動したSLI定義・SLO監視、さらにSLO違反が発生した場合の根本原因箇所の特定も可能になりました。これまでも3rdパーティーのソリューションを使えばやれたわけですが、AWS内で完結するサービスを待っていた方も多いのではないでしょうか？3rdパーティーを使おうとするとその必要性の説明はもちろん、調達やら予算確保やら色々大変なので。
正直このアップデートは予想外でした。というのも2020年のre:InventでWernerが「Observabilityに関して、CloudWatchやその他のAWSサービスの話をたくさんしたが、Observabilityサービスを作っている会社はAWSだけではない」と述べた後、続けて3rdパーティーの説明をしているんですよね。なので、色々やりたいなら3rdパーティーを使ってくれというメッセージだと思ってました。
それから3年。なんか出ました！（ただし、プレビュー）
ということで触ってみました。SpringBootのサンプルアプリをベースにしたデモアプリが用意されているので簡単に試せます。今回はEKSでトライ。安くて愛用してるオレゴンは未サポートでした。One Observability Workshopにもコンテンツがあります。Workshopについては別記事書いてるので、そちらも見ていただけるとうれしいです。
Topのダッシュボードです。EKSのCloudWatch Observabilityアドオンによってサービスが自動的に検出されます。
SLOのダッシュボードです。SLOが複数あると、それぞれ何がいくらだっけ？ってなることが多いのですが、達成条件が文章で書かれていてわかりやすい。エラーバジェットの推移もグラフで表示されています。こういうグラフを見るとアラームを設定したくなりますね。
SLOとアラームの設定画面です。SLOの計測ウィンドウはローリングとカレンダーベースから選択できます。従来はCloudWatch職人でもいない限り、ローリングウィンドウでのSLO監視は難しかったのではないでしょうか？エラーバジェットの残量が所定の値を下回った場合にアラームを設定できるようですが、バーンレートにもとづいたアラームはできないようです。残量ベースだと時すでに遅し、ってこともあるのでバーンレートをサポートしてほしいですね。できればマルチバーンレートも。
SLIの設定画面です。自動的に検出されたサービスとそのエンドポイントについて、可用性とレイテンシーに関するSLIを簡単に定義できます。またCloudWatchに集めたメトリクスを用いてSLIを定義することもできます。ビジネスKPIとの連動性を詰めていくと可用性やレイテンシー以外のSLIを使用したくなることもあると思うのでよいですね。Metric Mathも使えます。
Service Mapの画面です。CloudWatch Syntheticsのカナリーや自動計装で収集されたトレースをベースに俯瞰的にアプリケーションを見ることができます。試しにサービスを1つ壊して見ましたが、バッチリ異常箇所が分かりますね。MapからもSLOの設定ができるようになっていました。
Application Signalsはまだプレビューですが、バーンレートにもとづくアラートさえサポートされれば、基本的な管理はAWSで完結できる待望のアップデートでした。今年のおみくじによると、待ち人は遅れるが来るそうなので、re:Invent 2024くらいだと思って気長に待とうと思います。
Discussion