Introduction
はじめまして、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を使っています)
実装方針として、以下を定めました。
「正しさよりも、まず計測〜改善のフィードバックループを始めることが最も重要である」を満たすために、以下の方針とする
- SLIは現状で簡単に測定できるものとする
- SLI/SLOの計算・可視化が現状で簡単にできるものとする
上記の方針を実現するために、実装の方針は以下とする
DatadogのSLO機能で簡単に取り扱えるものとする
その上で以下をまとめました(一部省略しています)
SLIの案
候補
- https://coincheck.com/ の可動率
- 正常な時間(min間隔) / 対象期間(min)
- Datadog Synthetic Monitoring (AWS Tokyo Region) より
- ALBのレスポンスタイム
- 95%タイルの値が ? sec未満な時間(min間隔) / 対象期間(min)
- CloudWatch Metricsより(Datadogで集計)
- ※閾値時間も要検討
- ※99%タイル, 50%タイル, 平均も計測可能
- ALBのエラーレート
- (リクエスト数 - (Target 5xxエラー数 + ELB 5xx エラー数)) / リクエスト数
- CloudWatch Metricsより(Datadogで集計)
これらの、7days, 30days のローリングウィンドウ (Datadog SLOの仕様)
計画外に限定するか、計画している停止も含めるか???
↑以外の候補
Datadogで現状計測できていて、簡単に計算できて、有意そうなものが他にあるか??
- <略>
SLO設定の参考情報
直近1年の実績
- https://coincheck.com/ の可動率
- XX%
- ALBのレスポンスタイム
- XX%
- ALBのエラーレート
- XX%
AWSのSLA(主要サービス)
AWS上で動いている以上、AWSのサービスレベルを考慮する必要がある
AWSの利用主要サービスのSLAは
https://aws.amazon.com/jp/legal/service-level-agreements/
これを元に計算すると、、
- <略>
SLI測定の分解能
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案はこれ(一部省略しています)
本SLOについて
- 〇〇が定め、その運用に責任をもつものとする。
- 適宜見直しを行い、必要に応じて変更をすることとする。
- Coincheckサービスの全体を対象とする
SLIとSLO
30日間のローリングウィンドウを使う
分類
SLI
SLO
WEBサーバー
可用性
外形監視サービス(Datadog)で測定した、成功した時間の比率
計測は Datadog SyntheticsTest にて https://coincheck.com に対して、Tokyo(AWS) Location から、〇分毎に行い、〇〇秒未満にstatus code 200が返ってきたときに成功とする。
〇〇% の成功
※計画停止は対象外
可用性
ロードバランサーのメトリクスから計測した、成功したリクエストの比率
計測は、ALBに対して、Datadog の、aws.applicationelb.request_count, aws.applicationelb.httpcode_elb_5xx, applicationelb.httpcode_target_5xx にて行う。
ELBでのエラーと、ターゲットでのエラー、両方をエラーとする。
5xx以外のすべてのHTTPステータスは成功とする。
〇〇% の成功
※計画停止は対象外
レイテンシ
ロードバランサーのメトリクスから計測した、十分に高速なレスポンスタイムとなっている時間比率
「十分に高速」の定義は、「レスポンスタイムの95%タイルが〇〇ms以下」とする
計測は、ALBに対して、 Datadog の、applicationelb.target_response_time.p95 を 1分毎に計測し、十分に高速なときに成功とする。
〇〇% の成功
※計画停止は対象外
SLOの根拠
- 2020/01/15 - 2021-01-14 の期間に対する実績に基づいている。
- 上記期間ではサービスがこれらのレベル以上で概ね動作していたことを確認している。
- サービスがシステムアーキテクチャ上、このレベルで動作することの検証は行っていないが、AWSのSLAとサービスのシステムアーキテクチャ上からは、この可用性は保証されていないことを確認している。
- 機能リリースや効率的な運用とのバランスをとりつつこのレベルを維持できるかの検証は行っていない。
- これらの数字がユーザー体験と強い関係があるかの検証は行っていない。
エラーバジェット
各SLOには、個別のエラーバジェットがあり、100%からそのSLOを引いたものとして定義される。
目標のいずれかのエラーバジェットを超過した場合、エラーバジェットポリシーを適用する。
補足・留意点
- リクエストのメトリクスはロードバランサー (AWS ALB)で計測される。この計測はユーザーのリクエストがロードバランサーに到達しない場合は計測対象にならない
- 測定は全て、Datadogにて行う
エラーバジェットポリシーの案も作成
本ポリシーについて
- 〇〇が定め、その運用に責任をもつものとする。
- 適宜見直しを行い、必要に応じて変更をすることとする。
- Coincheckサービスの全体を対象とする
目標
本ポリシーの目標
- SLO違反から、ユーザーを保護する
- 信頼性と、機能開発のスピードとのバランスをとるための動機づけを提供する
- SLO違反に対する処罰として働くことは意図していない
- 信頼性がプロダクトの他の機能より重要になっている状態となっている場合に、チームが信頼性に集中する権限を与えるものである
SLO違反のポリシー
サービスが直近30日のウィンドウでエラーバジェットを超過したら、一部の除く全ての変更・リリースを、サービスがSLO内に回復するまで停止する。
以下の変更・リリースについては、行っても構わない
- 信頼性改善のための対応
- 影響度の大きいバグ
- 法規制対応のために必須のもの
- 顧客保護のために必須のもの
- セキュリティ対応
- <略>
SLO違反の原因によっては、チームは機能開発の代わりに、信頼性に関する作業にリソースを割くこととする。
以下の場合、チームは信頼性に関する作業を優先して行わなければならない
- コードのバグ、あるいは手続き的なエラーが、エラーバジェット超過を引き起こした場合
調整・説明
この案をもって、VPoEや関係各所と調整を行いますが、そのためにかんたんな説明資料も作りました
この資料を使って、VPoEや、https://tech.coincheck.blog/entry/2021/12/13/115048 にもあるDX Creiteria検討の会議、全社のシステムリスク委員会、またエンジニア希望者への説明を行いながら調整を行いました。
説明資料
前提
- Google SREのSLO の定義・考え方を前提とする
- SLOは機能リリースのスピードと、信頼性のバランス、サービス運用の効率を取るためのツールである
- 意思決定のためのツールであり、事業KPIとは異なるものである
- 運用部門だけが負うものではない。プロダクトに関わる全部門が共同で負うものである
- 正しさよりも、まず計測〜改善のフィードバックループを始めることが最も重要である
定義と説明
SLI
ユーザーにとってのサービスレベルの指標
ユーザー体験を捉えられる、かつ、システムで重要かつ計測しやすいものを選ぶ
正しい/全体 で割合(%)で出せるものが望ましい
SLO
SLIの目標値
値はステークホルダーが以下について同意するものである必要がある
- 値がユーザーにとって良いこと
- SLO違反になったら(エラーバジェットを使い果たしたら)回復するまで、
- 最優先度の問題修正と、セキュリティ対応を除くリリースをとめる
- エンジニアの時間は、信頼性の回復を優先(新規機能の開発等より優先)とする
- 多大な労力を伴わずに守れること
その他の留意事項
- SLOを常に満たし続けることは、現実的でも望ましいことでもない
- SLO違反は処罰するようなものではない。また人事評価等に用いてはいけない。
- SLOは高ければ良いというものでもない。また超過達成がより望ましいというものでもない
- 状況に応じて機能リリースのスピードを優先して緩めたり、信頼性を優先して厳しくしたり、コスト削減のために緩めたり、と適宜調整をしていくものである。(前期 +n% 毎期改善する、といった性格のものではない)
エラーバジェット
100%からSLO を引いたものをエラーバジェットという
サービス開発のスピードや運用の効率性のために、このバジェットを積極的に使っていく、と考えることが重要
つまり、消費をできる限り少なくすることが良いことである、とは考えない。
エラーバジェットを使い切った際には、エラーバジェットポリシーに従う
エラーバジェットポリシー
エラーバジェットを使い切った際に従うポリシー
主に以下の目的のために
- 反復的なSLO違反から、ユーザーを保護する
- 信頼性と、機能開発のスピードとのバランスをとるための動機づけを提供する
変更・リリースの停止や、信頼性のためにエンジニアのリソースを割くことなどを決める。
SLO違反に対する処罰として働くことは意図しないものである。
実装にあたっての方針
「正しさよりも、まず計測〜改善のフィードバックループを始めることが最も重要である」を満たすために、以下の方針とする
- SLIは現状で簡単に測定できるものとする
- SLI/SLOの計算・可視化が、現状で簡単にできるものとする
上記の方針を実現するために、実装の方針は以下とする
- DatadogのSLO機能で簡単に取り扱えるものとする
SLOの値は、最初は実績ベースで設定することも受容する(最適なものを検討し続けて、始めるのが遅くなるのは望ましくないので)
運用にあたっての留意事項
- 定期的に見直しをしていくことが重要である
- 特に最初は、SLOの値を最適なものに設定するのは難しいので、検討を続けることが大事である
参考情報
- Google SRE
- Datadog SLO
説明・調整の結果、基本的に案から大きく変えることなく、運用を開始することになりました。
ただし、「外形監視サービス(Datadog)で測定した、成功した時間の比率」については、他のものと冗長であるとの意見があり、対象から外すこととしました。
実装
Datadogで実現できるものに限ったので、DatadogのSLO機能を使って実装しました。
また、毎日Slackに通知をさせる&記録を残したかったので、毎日APIで取得して記録と通知を行うようにAirflowのDAGも作成しました。
運用してみて
効果については https://tech.coincheck.blog/entry/2021/12/13/115048 にある通りなのですが、運用してみて気づいたのは期間が30日だとなかなか違反にならない&違反になったらバジェットポリシーを適用しなくて良い理由をどうしても考えてしまう(30日間も拘束されたくないので)、ということでした。
この改善のために、現在は期間を7日のローリングウィンドウに変更して運用をしています。
今後は?
今回は、まず始める、ということを優先して、実装が簡単にできるものをSLIとしたのですが、よりユーザ体験に近い指標をSLIにしていきたいと考えています。
例えば、注文の成功率や処理時間などになります。
これらは、現在、簡単に計測できる仕組みがないので、計測できる仕組みの構築から進めていくことを現在計画しています。
終わりに
ぶっちゃけていうと、今回はVPoEからの指示で始まりましたし、社内での理解もあったので導入自体は他社に比べて相当に楽だっただろうな、と思っています。
それでも色々と考えて整理したことはあったので、今回は思い切ってそれを公開してみることにしてみました。
これが皆さんのお役に立てれば幸いです
最後に、コインチェックではSRE Gで一緒に働くメンバーを募集しています。当社は、暗号資産交換業としての金融レベルのセキュリティ/統制とネットサービスとしての高いアジリティの両立にチャレンジすることができる稀有なフィールドです。また個人に与えられる裁量が大きく、さらに今回の記事の通りシステム運用に対する理解も深いことから、より成長できる場所だと思っています。少しでも気になった方は応募していただけると嬉しいです。
https://hrmos.co/pages/coincheck/jobs/0000172
出典
本文・資料については以下の文献からの引用を含みます
- 『SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム』 Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy 編、澤田 武男、関根 達夫、細川 一茂、矢吹 大輔 監訳、Sky株式会社 玉川 竜司 訳、オライリー・ジャパン、ISBN978-4-87311-791-1
- 『サイトリライアビリティワークブック ――SREの実践方法』 Betsy Beyer、Niall Richard Murphy、David K. Rensin、Kent Kawahara、Stephen Thorne 編、澤田 武男、関根 達夫、細川 一茂、矢吹 大輔 監訳、玉川 竜司 訳、オライリー・ジャパン、ISBN978-4-87311-913-7
- Google SRE
参考情報
- Datadog SLO
- https://www.datadoghq.com/ja/blog/establishing-service-level-objectives/
- https://docs.datadoghq.com/ja/monitors/service_level_objectives/monitor/
- AWS SLA