コインチェックでSLI/SLOを策定したときの話 - coincheck tech blog
はじめまして、SRE G の渡邉です。今回のブログでは、以前の弊社 VP of Engineering佐藤によるコインチェックでの DX Criteria の活用 https://tech.coincheck.blog/entry/2021/12/13/115048 にあった「SLI/SLO/エラーバジェットの決定」の話をします。 コインチェックでは、策定にあたってこんなことを考えて、こんな 感じのものを策定した、を紹介しますので、皆様のSLO策定・改善の役に立てていただけると幸いです SREとしてトイル削減やアラート整理などは進めていたのですが、それがある程度落ち着いてきてからは、SLOの策定はやらないといけないとは思いつつもその必要性から説明をしてつくっていくのは相当なパワーを使うのでなかなか手を付けられていませんでした。 それが、2020年の末あたりになんとDX Criteria の活用で、SLOを策定せよ、という指示がVPoEより来ました。これはまさになんという僥倖！というやつです。必要性とかそういったものをすっ飛ばしてできるのですからこんな嬉しいことはないですね。 というわけで実際の策定を進めました まずは、原典ともいえる を改めて読み直して、自分の中で整理を行いました。 また材料集めとして以下を集めました 現在測定できている指標 会社の規程での可用性等に関する記載 Amazon Web Services(以下AWS)のSLA（CoincheckのシステムはAWSで動いています） SLI測定に使えるツール（Coincheckではインフラ等の監視にDatadogを使っています） 実装方針として、以下を定めました。 「正しさよりも、まず計測〜改善のフィードバックループを始めることが最も重要である」を満たすために、以下の方針とする 上記の方針を実現するために、実装の方針は以下とする DatadogのSLO機能で簡単に取り扱えるものとする その上で以下をまとめました（一部省略しています） これらの、7days, 30days のローリングウィンドウ （Datadog SLOの仕様） 計画外に限定するか、計画している停止も含めるか？？？ Datadogで現状計測できていて、簡単に計算できて、有意そうなものが他にあるか？？ AWS上で動いている以上、AWSのサービスレベルを考慮する必要がある AWSの利用主要サービスのSLAは https://aws.amazon.com/jp/legal/service-level-agreements/ これを元に計算すると、、 Datadogは1分間隔での集計となるので、 7day : 100 - 2/(7*24*60)*100 = 99.9801587302 % 30day : 100 - 2/(30*24*60)*100 = 99.9953703704% より小さいSLOは有意ではない 検討の段階でほぼほぼ対象は決まってきていたので、SLOの値をどうするか？が一番の課題になりました。 これも「正しさよりも、まず計測〜改善のフィードバックループを始めることが最も重要である」を満たすために、最初は実績ベースで設定することとしました。 期間については、 https://sre.google/books/ のおすすめ通り、30日間のローリングウィンドウを採用（DatadogのSLO機能で対応しているのが、7, 30日のローリングウィンドウのみだった、というのも理由です） また計画停止（メンテナンス）についても、いれると考えることが増えてしますのでまずは対象外とすることにしました 作ったSLO案はこれ（一部省略しています） 〇〇が定め、その運用に責任をもつものとする。 適宜見直しを行い、必要に応じて変更をすることとする。 Coincheckサービスの全体を対象とする 30日間のローリングウィンドウを使う 2020/01/15 - 2021-01-14 の期間に対する実績に基づいている。 上記期間ではサービスがこれらのレベル以上で概ね動作していたことを確認している。 サービスがシステムアーキテクチャ上、このレベルで動作することの検証は行っていないが、AWSのSLAとサービスのシステムアーキテクチャ上からは、この可用性は 保証されていないことを確認している。 機能リリースや効率的な運用とのバランスをとりつつこのレベルを維持できるかの検証は行っていない。 これらの数字がユーザー体験と強い関係があるかの検証は行っていない。 ...
