CloudWatch Application Signals の SLO 時間枠除外 (SLO Time window exclusions) を試してみる
2025.07.14こんにちは。クラウド事業本部の枡川です。
CloudWatch Application Signals の SLO 時間枠除外 (SLO Time window exclusions) の管理を試してみます。
2025 年 3 月に新たに追加された機能です。
SLO の時間枠除外 (SLO Time window exclusions) とは？
Application Signals の SLO 計算から、特定の時間帯を省くことができる機能です。
例えば、DB のメンテナンスウィンドウなど計画されたダウンタイムを SLO 計算の対象外にすることが可能です。
あらかじめユーザーへの周知を済ませていれば、いわゆる「障害」とは分けて考えたいですよね。
環境構築
本機能は EC2/ECS/EKS/Lambda といったアプリケーション実行環境に依らず利用可能です。
今回は ECS 環境で試してみます。
環境構築に利用したソースコードは下記リポジトリに格納しています。
Application Signals の SLO は可用性目標とレイテンシー目標で一つずつ作成しました。
| SLO 名 | 条件 | 目標 |
|---|---|---|
| getTaskAvailability | 可用性 | 99.9% |
| getTaskLatency | レイテンシー (200ms) | 99.9% |
可用性は (1 - 障害率)*100 で計算できます。
この際 5xx エラーを「障害」と見なし、4xx エラーは成功扱いとなります。
標準アプリケーションメトリクスとして SLI に使用できるのは、Latency と Availability です。Availability は、成功の応答をリクエストの合計で割った数値で表し、(1 - 障害率)*100 のように計算します。ここでの Fault 応答数は 5xx エラーの件数を意味し、成功の応答とは 5XX エラーのない応答を指します。4XX 応答は成功の応答と見なされます。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html
例えば 9 リクエストで 1 回 200 番のレスポンスがあり、それ以外が 500 番だった場合、可用性は (1 - 8/9)*100 = 11.1 % と計算できます。
SLO の時間枠除外 (SLO Time window exclusions) を設定する
では、SLO Time window exclusions を設定していきます。
設定は「SLO の編集」から行います。
「Set SLO time window exclusion」という欄があるので、日時を指定します。
除外する時間枠を設定する場合は、単発のスケジュールも指定できますし、繰り返しのスケジュールも設定可能です。
ローカル時間でも設定できるのは良いですね。
今回は単発で 22:00 からの 1 時間としました。
この際、それぞれの SLO で設定する必要があります。
SLO の時間枠除外 (SLO Time window exclusions) を試す
22:00 になった後、Aurora を停止します。
これでしばらくシステムは正常なレスポンスを返さなくなります。
Application Signals のサービスページを見に行くと 22:00 からの時間帯はグレーアウトされていました。
当該時間帯は SLA を 100% 達成しているとみなすようです。
この状態で ALB にリクエストを投げると 500 エラーになります。
% curl http://spring-alb16-q5r25wcidu5g-1735319732.ap-northeast-1.elb.amazonaws.com/task
{"timestamp":"2025-07-14T13:10:08.000+00:00","status":500,"error":"Internal Server Error","path":"/task"}
Fault メトリクスには「障害」として計上されました。
40 リクエストくらい Fault 扱いのリクエストを送って、メトリクス上の可用性は 99% を下回る所まできました。
その状態でも SLO は「正常」扱いです。
良い感じですね！
SLO Time window exclusions が終わった後に再度確認すると、メンテナンスウィンドウ前の数値で SLO 計算が開始されました。
最後に
CloudWatch Application Signals の SLO 時間枠除外の管理を試してみました。
SLI/SLO を管理しようと思った際、計画的メンテナンスを上手く扱えるかどうかでかなり使い勝手が変わりますが、簡単に設定できて非常に良かったです。
各 SLO の設定ではなく、複数パスに関連付けられる独立したリソースになった方が嬉しい気もしますが、ここはスクリプト作成などでカバーできそうです。
CloudWatch Application Signals は組み込みダッシュボードも含めて使い勝手をかなり意識して作られているように感じます。
ECS/EKS だと Container Insights の組み込みダッシュボードから SLI ステータスを見れるというのもかなり嬉しいです。
まだまだ新しいサービスで利用例も少なく感じますが、引き続き CloudWatch Application Signals に期待してきたいなと思いました！！
![[アップデート] CloudWatch Application Signals MCP サーバーが公開されました](https://images.ctfassets.net/ct0aopd36mqt/4AJd3M26yescaNaY21CYmQ/9730e95c53a7b3049c6da6d4c0b1dec9/mcp.png)
