Amazon CloudWatchによるSLOエラーバジェットのバーンレート監視

ツール導入前の課題

以前は、CPUやメモリの使用率といったリソースのメトリクスを直接的に監視しており、サービスが問題なく提供できていてもアラートが飛ぶ状況でした。いわゆる「オオカミ少年アラート」の多い状況です。

どのような状態を目指していたか

提供中の主要サービスにSLOが策定され、エラーバジェットのバーンレートが監視されている状態を目指しました。

• New Relic
• Datadog

• Application Load Balancerのアクセスログをもとに、私の理想とする条件式でバーンレートが計算・監視できること
• 低コストで運用できること

導入検討時点で、上記2点を満たしていたのがAmazon CloudWatchのみでした。

改善したかった課題はどれくらい解決されたか

主要サービスについて、エラーバジェットのバーンレート監視が開始できました。

どのような成果が得られたか

オオカミ少年アラートが削減できた一方で、可用性やレイテンシの悪化にすぐ気づけるようになりました。また、それらの指標に対する開発チームの意識が高まりました。

CloudWatchはSLO監視に特化したツールではないため、集計処理やアラート処理を作り込む必要がありました。 たとえば、5分ごとに1時間の合計値を集計するといったローリングウィンドウ機能は、現在のCloudWatchメトリクスに備わっていません。そのため、AthenaやRDSで集計した値を、タイムウィンドウ（5分・30分・1時間・6時間・3日・28日）ごとのカスタムメトリクスに発行するよう実装しました。

今回のアーキテクチャのように自作する場合、実装コストはかかりますが、運用コストは抑えられます。実装もそれほど難しくないので、検討の際に選択肢に含めていただくことをお勧めします。

ローリングウィンドウ機能がCloudWatchに実装されれば作り込みが減らせるので、AWSに機能追加の要望を出そうと考えています。

一方で、New RelicやDatadogでも柔軟な実装が可能になれば、それらのツールに移行することもありえます。CloudWatchに比べ、サービスレベル低下の原因調査がしやすくなるためです。