DMM.com Inside レガシーなアプリケーションの監視を改善するため最初にやったこと
SLO、SLI の策定の仕方について書かれている。
私自身も、サービスの発足当初に SLO,SLI を制定していなくて、必要になったタイミングで今から考えるという場面に何度か遭遇した（なお、担当は私ではなくて別の人）。
そのような場合に、実際にどのような過程を経て SLO,SLI を決めていくかの実情が現実的に書かれていて面白かった。
DMM.com Inside レガシーなアプリケーションの監視を改善するため最初にやったこと https://inside.dmm.com/entry/2022/12/16/improve-legacy-app-mon
これより以下は、上記内容の焼き直し。私自身の理解のために、雑にまとめなおしたものである。
監視改善までのロードマップ
既存のレガシーなアプリケーションの監視を改善するために、以下のロードマップを作成した。
- SLO の制定
- 監視ルールの整理
- 監視の実装
- 監視の運用と継続的な改善
SLO を制定する時の方法論
- 「お使いの WebAPI について、どういった品質を期待していますか」「レイテンシは何 ms 以内を期待していますか」「エラーレートは」などとヒアリングし、その中で得られた最も厳しい目標を採用する
- 現状のアプリケーションのユースケース、パフォーマンスに関する各種メトリクスを精査し、自らで SLO の叩き台を作る。事業責任者にレビューしてもらい、お墨付きをもらう。
SLO 制定までのアプローチの実情
すでにリリースから 8 年以上稼働しているサービス。品質に関する何らかの合意や取り決めがあってもよいと思われるが、有識者ヒアリングの結果、特にないことが多々ある。
よって、一から SLO を定義することから始まる。
正攻法で行くのであれば、アプリケーションを利用するクライアントすべてにヒアリングして、どんな品質を期待しているかを知る。可用性、パフォーマンス、データの整合性。
公開されている WEB サービスであれば、クライアントが多数おり、社内にもステークホルダーがたくさんいるため、登場人物を整理して細かくヒアリングしていることは非現実的。
代替として、現状のアプリケーションのユースケースや、パフォーマンスに関係する各種メトリクスを自分で精査し、SLO の叩き台を作る。-> 事業責任者にレビューをしてもらいお墨付きをもらう方法が、スムーズ。
レイテンシ目標の設定において、つまづきがあった。
事業責任者から「〇〇 ms 以内にしてほしい」明確な要求があった。
当時の WebAPI のレイテンシはすでにその基準を超過してしまっていた。
- パフォーマンスを改善するか
- 要求レベルを引き下げてもらえないか交渉する
幸い、パフォーマンス改善の見通しを立てることができ、結果的に要求をクリアできた。
求められる品質
- 可用性
- パフォーマンス
- データの整合性
可用性とパフォーマンスに着目した場合、SLI は以下の通り
- エラーレート WebAPI のエラーレートが５分以上 X％を上回り続けることのないようにする
- レイテンシ WebAPI のレイテンシが５分以上 Xms を上回り続けることのないようにする
５分以上とする理由は、瞬間的に上下することがあるため。
上記の目標を月間稼動時間のうち、99.95％満たすことを SLO とする。すなわち、
- ダウンタイム (目標を満たせていない期間) を月あたり 21 分 35 秒以内に納める
実装
エラーレート監視の実装、レイテンシ監視の実装
Datadog で実装。HTTP のステータスを監視する。
- エラーステータスの全量 / リクエストの全量 * 100 で算出
「いかなるレスポンスも 200 OK ステータスを返却、レスポンスに独自エラーコードを含む」という仕様の場合、ログベースメトリクスを利用して、ログに含まれる数値や文字列をカスタムメトリクスとして収集し、監視する。