![[アップデート] Amazon CloudWatch Application Signalsに推奨SLO / サービスレベルSLO / パフォーマンスレポート機能が追加されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-d6a3bc85cad6419960fbda152152cd8c/ba5841cea06b96f4933878762028b090/amazon-cloudwatch?w=3840&fm=webp)
[アップデート] Amazon CloudWatch Application Signalsに推奨SLO / サービスレベルSLO / パフォーマンスレポート機能が追加されました
推奨されるSLOを提案して欲しい
こんにちは、のんピ(@non____97)です。
皆さんは推奨されるSLOを提案して欲しいと思ったことはありますか? 私はあります。
SLOの設定は厳しすぎるとエラーバジェットがすぐに枯渇し、緩すぎるとサービスの状態悪化を見落としてしまいます。
今回アップデートにより、以下3つの機能が追加されました。
- 推奨SLO
- サービスレベルのSLO
- SLOパフォーマンスレポート
推奨SLOは過去30日間のメトリクス(P99レイテンシーとエラーレート)を分析して、適切なSLOを提示してくれます。
サービスレベルのSLOは従来依存関係やオペレーション単位でSLOを設定していたところ、すべてのオペレーションひっくるめたSLOを定義することが可能です。要するにサービス全体の健全性を評価することが可能です。
SLOパフォーマンスレポートはローリングウィンドウやカレンダーウィンドウでSLOの達成状況を振り返れる機能です。
実際に確認してみました。
やってみた
検証環境
検証環境は以下のとおりです。
以下記事のものをベースにしています。
ログはAWS FireLens (AWS for Fluent Bit)を使用して、エラーログはCloudWatch Logs、全てのログをData Firehose経由でS3バケットに出力させています。
推奨SLO
まず、推奨SLOで作成をしようとしてみます。
サービスオペレーションで、GET /latency-testを選択して、SLOを作成をクリックします。
Based on your service historical performance, we recommend setting an attainment goal of 99.99% over a 28 day ローリング interval, with a warning threshold of 50%. These recommendations are based on analysing your service recent performance patterns.とRecommendationが表示されていますね。
レイテンシーに切り替えます。
自動でレイテンシーが600msで設定されました。
オペレーションをGET /に変更します。
今度は297.65msになりました。
過去実績から自動で調整されてくれていますね。
Nextをクリックすると、一気に確認画面になりました。
SLOゴールやバーンレートの設定、SLO時間枠除外は割愛されています。
SLOを作成をクリックすると、そのままSLOの作成がされました。
バーンレートの設定は後から変更可能なので、もし調整したい場合は調整しましょう。
ただし、以下記事で紹介しているようなバーンレートアラームやSLOアラームはSLOの編集画面から設定することはできません。CloudWatch Alarmとして自身で作成することになるため一手間かかってしまいます。
サービスオペレーションに対してではなく、サービスの依存関係に対しても推奨SLOでのSLOは作成可能です。
試しにAurora PostgreSQLのレイテンシーを選択すると、以下のように200msが提案されました。
期間とすると以下のようになります。
また、メトリクスタイプを可用性に変更すると以下のようになります。
サービスSLO
続いて、サービスレベルSLOです。
要するに該当サービスの全てのオペレーションを選択する形のSLOです。
指定すると以下のようになります。
Recommendation and Createをクリックすると、以下のようになります。
SLOの作成をすると以下のようになります。
サービスからこれらのSLOの確認も可能です。
SLOパフォーマンスレポート
SLO一覧は以下のとおりです。
Performance reportとトグルがありますね。
こちらをクリックすると、以下のようにローリングウィンドウやカレンダーウィンドウ単位の結果を確認可能です。
当日分の情報は見れませんが、翌日確認すると、前日の結果を表示できました。
Export to CSVで表示されている内容をエクスポートすることも可能です。
エクスポートした結果は以下のとおりです。
Type,SLO Name,Goal (%),Mar 16 - Attainment (%),Mar 17 - Attainment (%),Mar 16 - Error Budget (%),Mar 17 - Error Budget (%)
Service,ecs-express-app--all-operations--LATENCY-c19391dd,90.00,96.75,,67.50,
サービスオペレーション,ecs-express-app-GET -latency-test-LATENCY-c4f244de,99.80,,,,
推奨SLOをベースに考えるのもあり
Amazon CloudWatch Application Signalsに追加された推奨SLO / サービスレベルSLO / パフォーマンスレポートを紹介しました。
SLOは基本的にビジネス要件から導き出すものだと思います。推奨SLOは過去の計測結果に基づく提案であり、ビジネス要件を反映したものではありません。
とはいえ、何も設定しなかったり、最初から厳しめ目の設定をすることは避けるべきです。まずは推奨SLOをベースに考えるのもありかなと思います。
You can always refine SLO definitions and targets over time as you learn about a system’s behavior. It’s better to start with a loose target that you tighten than to choose an overly strict target that has to be relaxed when you discover it’s unattainable.
その際は以下情報も読み込んだ上で、適切なものを設定しましょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
