Amazon CloudWatch Application Signalsを使ってバーンレートアラームを設定しよう
はじめに
こんにちは、AWSでデベロッパーアドボケイトをしているものです。4/16にAWS Startup Loftで開催された「春のObservavility祭り 2025」というイベントで、オブザーバビリティが好きな同僚と一緒に登壇してきました。
私は Application Signals を使ってバーンレートアラームの設定が簡単にできます、という話をしました。また、そもそもバーンレートアラームがなぜ重要なのかというところから解説しました。録画がなかったのと、15分という短い時間での説明で咀嚼しづらいところもあったと思うので、この記事で登壇の内容をあらためて解説します。なお当日のスライドはこちらです。
バーンレート計測の重要性
サービスレベル指標 (SLI) とサービスレベル目標 (SLO)
バーンレートの解説をするためには、SLIとSLOの解説が必要です。SREはサービスの信頼性（ユーザーの満足度）を中心に据える開発運用手法ですが、別にSREに限らずサービスの信頼性をリアルタイムに知ることは良いことです。
SLIはサービスの特性を考えて「ユーザーの満足度に寄与していそうな指標」を擬似的に信頼性の指標として捉えるということをしています。たとえば、ECサイトであればチェックアウトにかかる時間（レイテンシー）であったり、バッチ処理のシステムであればレポートの鮮度であったり、とサービスによって変わります。
SLIは、次のような式で求められる百分率です。
たとえば、良いイベントは「500ms以下のレイテンシーのレスポンスの数」で、イベント全体が「過去28日間でのレスポンスの総数」です。で、その目標値がSLOです。たとえば「レイテンシーが500ms以下のレスポンスが全体の90%」という目標値を設定できます[1]（SLOはサービスの信頼性が保たれつつ、無理のない値を設定することが肝心です）
SLIとSLOに関しては以前に詳細に書いたので、こちらも参照してください。
SLIがSLOに沿っているかどうかを監視すれば、ユーザーが満足してサービスを使えてるかどうかがわかるから、これを追跡してしきい値でアラートを出せばいいじゃん！と思いますが、そう簡単にはいきません。
SLIが下のグラフのように推移していたら、しきい値をまたぐたびにアラートが鳴り、過剰に鳴ってしまう状況になることは容易に想像できるでしょう。
アラートは行動できる場合のみ発報
みなさんも経験があると思いますが、アラートが多くなりすぎると、そのうち発報されたアラートの中でも無意識に心のフィルターを作るようになり、何かいつもと違うと感じるときだけ対応するといったような状況になります。これではアラートの意味がありませんし、いくら心のフィルターを作ったとしても、アラートを都度確認することは精神的に良くありません。この状況は「アラーム疲れ（alarm fatigue）」として知られています。
「アラーム疲れ」はIT業界だけでなく、医療業界や航空業界でも長らく問題になっています[2][3][4]。
ベストプラクティスとして「アラームはアクションが可能な状況でのみ発報すべき」とされています。Well-architected Frameworkでは「OPS08-BP04 実践的なアラートを作成する」として解説されています。
W-Aではそのための対策としてAmazon CloudWatchの異常検出機能やAmazon DevOps Guru、またCloudWatchの複合アラームの設定を勧めています。しかし、ここに書かれていない対策として「エラーバジェットの追跡」、さらには「バーンレートによるアラーム」を紹介します。
エラーバジェット
エラーバジェットは名前の通り「予算」です。なんの予算かというと悪いイベントが発生したときに消費される予算です。
エラーバジェットは次のように定義されています。
つまりSLOの逆となる概念がエラーバジェットです。たとえば「可用性の目標値が90%」となっている場合、「10%は可用性がなかったとしても許容される」ということになります。この10%分のエラーが「予算」となるわけです。
SLOに対するSLIの現状を追跡するということは、必然的にエラーバジェットの残りを確認し続けるということになります。
しかしエラーバジェットに置き換えたからと言って、それが枯渇したとき（SLIがSLOを割り込んだとき）に都度アラームを鳴らしていたのでは先の場合と変わりません。また、ユーザーがシステムに不満を持つ前に早めに手を打ちたいものです。そこでバーンレートという考え方を導入します。
バーンレート
スタートアップ界隈では「バーンレート」と聞いて胃を痛める人もいるのではないかと思います。スタートアップ界隈で語られるバーンレートにはいくつかの種類がありますが、概ね「1ヶ月あたりにかかるコスト」を指します。手元資金をそのコストで割れば「ランウェイ」、つまり会社の生存期間が計算できます。
それと同じことをエラーバジェットを使って行うのがSREの文脈でのバーンレートです。エラーバジェットが減る速度がバーンレートとなります。エラーバジェットを計算するときに、そもそもその予算というのはSLIの計算をするウィンドウがあるので、ランウェイはすなわちそのウィンドウになります。最初のSLIの例で言えば28日です。28日でエラーバジェットを使い切る消費速度はバーンレート1となります。
このバーンレートの大きさで緊急度が変わってきます。バーンレート2の場合は、予想の半分の期間でエラーバジェットを使い切ってしまうということになります。このときもともと28日で計算していたのであれば、半分でも14日（2週間）あるので、状況としてはよくないですが、問題修正のほうを優先して対応すれば、業務時間に余裕を持って解決できる可能性が十分あります。
一方でバーンレート10の場合は2.8日しかありません。これは週末を挟んだ場合、月曜に出社してきてみたらもうエラーバジェットは枯渇寸前、ユーザーに影響がある問題が発生することが目に見えた状態になります。したがって、バーンレート10は緊急対応に備えた体制を敷く必要がある値となります。
肝心なのは、バーンレートを使うことでエラーバジェットが枯渇する前に状況の把握ができるということです。ここまで SLI → SLO → エラーバジェット → バーンレート と一本道でつながっていることがわかるかと思います。これが私がAIモデルを使ったり複雑な条件を組み合わせたアラートよりも、バーンレートを使ったアラートを好む理由です。
バーンレートの計算は少し手間
いますぐにバーンレートを使った計算をしたいところですが、ここで少し問題があるのは、バーンレートの計算までに2段階、ローリングウィンドウでの計算が必要になるということです。
1つめはSLIの計算で、計算式は本記事の最初の方ですでに書いています。
2つめのバーンレートの計算は、エラーバジェットとルックバックウィンドウで計算します[5]。
これを計算するのは手間ですが、多くのオブザーバビリティSaaSでは、SLIに使うメトリクスだけ入れていればバーンレートの計算まで全部自動で行ってくれるものが多いです。
Application Signalsでのバーンレートアラーム
Application Signals は名前の通りアプリケーションに関するテレメトリーシグナルを扱う多くの機能があって、その中にSLOモニタリングがあります。これはこれまで説明してきたようなSLOに対するSLIの状況、エラーバジェットの状況、バーンレートをひと目で確認できるダッシュボードを提供しています。
また、SLOを設定する際に、それに必要なバーンレートアラームの設定を同時にできるようになっています。（バーンレートアラーム自体はCloudWatchアラーム自体の機能です）
まずSLIを設定します。
次にSLOを設定します。
そしてバーンレートを設定します。
最後にそのアラーム条件となるバーンレート値を設定して完了です。
設定したアラームはCloudWatchアラームで確認できます。
まとめ
バーンレートアラームの意味について解説しました。まだまだバーンレートアラームの活用は一般的ではないと思うので、それが当たり前のものとして認識されるまで、これからもこういった記事を書き続けたいと思います。
Discussion