📈

バーンレートアラートについて整理

に公開
Google Cloud
Datadog
SRE
SLO
tech

概要

この記事は、SLI/SLOやエラーバジェットの文脈において、バーンレートアラートを設定するための情報を整理することを目的とした記事となります。

なお、本記事では、SREのプラクティスなど、詳細には触れないのでご了承ください。

バーンレート

バーンレートとは、SLOと比較して、サービスがエラーバジェットをどれだけ速く消費するかを表したものと言えるでしょう。
BurnRate=1で決められた期間のエラーバジェットをピッタリ消費し、BurnRate=2だと、決められた期間の半分でエラーバジェットを消費します。

Googleが提供している資料のChapter 5 - Alerting on SLOsに記載されている以下の図がわかりやすいと思います。

https://sre.google/workbook/alerting-on-slos/

では、どのようにバーンレートを算出するのでしょうか？

Datadogの記事に記載されているように、バーンレートの算出は、以下のように行うことが可能です。
どの時間間隔でバーンレートを算出するかがアラートの鍵となりそうです。

Burn Rate = \frac{Error Rate}{Error Budget}

https://www.datadoghq.com/blog/burn-rate-is-better-error-rate/

バーンレートアラート

バーンレートに対して、アラートを設定したものが、バーンレートアラートとなります。

イメージとしては、「川が増水してしまった（エラーバジェットが消費し切った）あとに避難しても逃げ遅れる（ユーザーへのサービスの信頼を毀損する）かもしれないから、川が増水していくスピードもウォッチして早めに避難（バーンレートアラートに対応）しよう！」みたいなイメージで良いと思います。

Google Cloudのドキュメントでは、バーンレートアラートにFast（急速）とSlow（低速）の2種類のアラートが紹介されています。
これらの2種類を扱うことで、急激な信頼性の低下や緩やかな信頼性の低下の両方に対応できることになります。

  • Fast Burn (急速バーン)

    • 目的: 短期間での 急激な エラーバジェット消費を検知する。
    • 緊急性: 高い。「このままでは、エラーバジェットが数日で尽きてしまう！」という状況。
    • 監視期間: 短い (例: 1〜2時間)。直近の問題を素早く捉えるため。
    • しきい値: 高い。 短期間で通常ではありえないほど高い消費率になった場合にのみ警告する。

  • Slow Burn (低速バーン)

    • 目的: 長期間にわたる 緩やかな エラーバジェット消費を検知する。
    • 緊急性: 低い。「このペースだと、期間の終わりにはエラーバジェットが足りなくなりそうだ」という状況。
    • 監視期間: 長い。 短期的な消費のブレをならし、長期的な傾向を見るため。
    • しきい値: 低い。 理想的な消費ペースを少し超えた状態が続いた場合に警告する。

https://cloud.google.com/stackdriver/docs/solutions/slo-monitoring/alerting-on-budget-burn-rate?hl=ja#burn-rates

マルチウィンドウなバーンレートアラート

Datadogの場合、長いウィンドウと短いウィンドウを組みわせた、マルチウィンドウなバーンレートアラートになっています。
バーンレート14.4がFast Burn、バーンレート3がSlow Burnに該当するイメージです。
長いウィンドウと短いウィンドウの双方で閾値のバーンレートを超えた場合にアラートが上がる仕組みとなっています。

では、なぜ長いウィンドウと短いウィンドウが存在するのでしょうか？

長いウィンドウと短いウィンドウを組み合わせる利点としては、以下が挙げられます。

長いアラートウィンドウは時間単位で指定し、重大な問題に対応するのに十分な長さの期間にわたってバーンレートを測定するようにモニターを設定します。これにより、軽微な問題によってモニターが薄っぺらなアラートを発するのを防ぐことができます。短いアラートウィンドウは、分単位で指定されます。これは、最近のバーンレートがまだ閾値を上回っているかどうかを確認することで、実際の問題が終わった後、モニターが迅速に回復することを保証します。

  • 長いウィンドウ
    • 誤検知の削減
    • 重大な問題の正確な特定
  • 短いウィンドウ
    • 迅速な回復検知（バーンレートが閾値以下になったことを検知）

つまり、2つを組み合わせることで、ノイズの多いアラートを減らしつつ、問題発生時には確実な通知を受け取り、問題解決後には迅速にアラートが解除される、バランスの取れたモニタリングが可能になるのではないかと思います。

https://docs.datadoghq.com/ja/service_management/service_level_objectives/burn_rate/

とはいえ簡単ではないバーンレートアラート

Chapter 5 - Alerting on SLOsに記載されているように、夜間帯でユーザー数が少なくなりリクエスト数も減ってしまう場合、ノイズとなるアラートが上がってしまう可能性もあります。

リクエストのレートが低いシステムでは問題を引き起こす可能性があります。システムのユーザー数が少ない場合、またはトラフィックが自然に低くなる時間帯（夜間や週末など）がある場合は、アプローチを変更する必要があるかもしれません。
トラフィックの少ないサービスでは、重要でないイベントを自動的に区別することがより困難です。例えば、システムが1時間あたり10件のリクエストを受信する場合、1件のリクエストが失敗すると、1時間あたりのエラー率は10%になります。99.9%のSLOの場合、このリクエストは1,000倍のバーンレートとなり、30日間のエラーバジェットの13.9%を消費するため、すぐにページングされます。このシナリオでは、30日間で7件のリクエストの失敗しか許容されません。単一のリクエストが失敗する理由は、一時的なものや重要でないものが多数ある可能性があり、大規模なシステム障害と同じように解決しても必ずしも費用対効果が高いとは限りません。

※ 日本語に翻訳済み

これらの問題に対するアプローチとして、以下が挙げられています。
プロダクトの状況に応じて、適切なものを選択する必要がありそうです。

  • 人工的なトラフィックを生成する
    • 実際のユーザーがいなくても、システムの問題を早期に検知するために合成されたリクエストを作成します。
  • サービスの組み合わせ
    • 複数の低トラフィックサービスを統合して、より正確かつ少ない誤検知で重要なイベントを検出します。
  • サービスとインフラストラクチャの変更
    • クライアントの再試行やフォールバックパスを実装して、一時的な障害によるユーザーへの影響を軽減します。
  • SLOを下げるかウィンドウを増やす
    • 少数のエラーでアラートが鳴らないように、サービスレベル目標のしきい値を下げるか、アラートの時間ウィンドウを長くします。

まとめ

  • 本記事ではバーンレートアラートについての情報を整理しました。
  • 概念的にはシンプルだと思っていましたが、改めて整理すると奥が深いと感じました。特に、夜間帯などにリクエスト数が少なくなり、バーンレートアラートがノイズのなってしまう問題については、SLI/SLOのプラクティスでもあるイテレーションを繰り返す中で改善していくのが重要だと感じました。

Discussion