自分用メモです。
DevOpsとSREの違い
DevOpsとは開発(Development)と運用(Operations)を組み合わせた言葉であり、開発担当者と運用担当者が連携して協力し、さらには両担当者の境目も曖昧にする開発手法を指します。 厳密な定義は存在しておらず、抽象的な概念にとどまっています。 その目的から、DevOpsは組織(より具体的には任意のプロダクトに関わる全ての人達)の課題解決にフォーカスしています。 しかしながら、解決するための具体的な方法について定めるようなものではなく、大きな方針や文化を大切にしています。
SREとはGoogleのVPoEであるBen Taylor Slossが作成した言葉であり、Googleが実践しているシステム管理とサービス運用の方法論です。 事業責任者とService Level Objective(SLOs)を定め、それを守ることに責任を持ちます。 その他にもトイルに対する対処方法であったり、ポストモーテム、自動化などなど様々な内容に関して基準や、具体的な解決の手順を定めています。 DevOpsと親しい概念であり、class SREは interface DevOpsをimplementsしているとも言えます。
SREもDevOpsもサービスをより良くするという目的については一致しています。しかしながら、そのアプローチ方法が異なります。 DevOpsは組織的な課題解決にフォーカスすることによってその目的を達成しようとするのに対して、 SREは様々なオペレーションをソフトウェアで解決できる形に置き換え、ソフトウェアエンジニアリングのアプローチでもって課題に対処していくことでその目的を達成しようとします。
DevOpsは幅広い文化や哲学を指すのに対して、SREは厳密に定義された手法を持っていると言えます。
SLO/SLI/SLA/Error Budget
サービスを管理するためには、継続的に計測可能で具体的な指標が必要です。 その指標は、ユーザーにとって価値のあるサービスの振る舞いになります。 Googleではこのサービスレベルを管理するために、SLI(Service Level Indicators)、SLO (Service Level Objectives )、SLA (Service Level Agreements) の３つの概念を用いています。
SLO
SLOsとは、Service Level Objectivesの略称で、サービスの信頼性の目標のことを指します。 SLOを定める際は、ユーザーがそのサービスを利用する上で何が大切なのかを考え、それを数値化して指標とすることが大切です。 なお指標は平均を利用するのではなく、パーセンタイルを利用することが望ましいです。具体的には下記２つのような例があります。
- eg1. gRPCのリクエストレイテンシの99%が100 ms以下であること
- eg2. 可用率 99.9%
サービスには適切な信頼性というものがあります。過度な信頼性はコストとしてサービスに跳ね返ります。 また、明示的にSLOを定めなければ、ユーザーはサービスに対して過度な信頼を寄せることもあります。 障害の大部分はサービスの更新時において発生します。 なので、サービスの成長・拡大と信頼性のトレードオフから適正な値を定める必要があります。
サービスのSLOは最初から完璧に決められるものではありません。 最も大切なことは、計測することによって得たものでサービスとそのユーザーに対する理解を深め、よりよいSLOを模索し続けることです。 そのため、一度決めて終わりではなく、継続的に見直していく必要性があります。
SLO Document: https://landing.google.com/sre/workbook/chapters/slo-document/
SLI
SLIとはサービスの品質を決める計測可能な指標です。 サービスの品質を決める指標なので、ユーザーの視点に最も近い指標を利用することをおすすめします。 良いイベント数 / 全体のイベント数という形で定義することをおすすめします。 一般的によく使われる例は下記のようになります。
こちらは、Google Workbookに記載される指標の一覧です。
このように定義すると、SLIは必ず 0 ~ 100 %の値を取ります。 SLIを一貫したスタイルで設定することによって、アラートツールを作るとき、エラーバジェットを計算するとき、レポートを作成するときに、同じようなINPUTを望むことができるようになります。 最初のSLIは、最小の工数でできる物を選びましょう。 調査に1週間かかってJSの搭載に数ヶ月かかるぐらいなら、すでにWebサーバのログがあるのであれば、ログを使いましょう。
Error Budget
Error Budgetの概念は、下記の数式で表されます。
SLIの計測値 - SLO = Error Budget
具体的な例を使って説明します。
例えば、とあるサービスのSLI を HTTP Responseを返したリクエスト数/ Load Balancerに到達したリクエスト数 としたとして、SLOを99%と置いたとします。
ここで SLIの計測値が 10000/10000 であった場合、100リクエスト分追加で失ってしまったとしても、SLOを満たしていると言えます。
この失うことのできる100リクエストをError Budget(予算)と言います。
エラーバジェットが残る限り、システムのリリースは継続が可能です。 逆に言えば、エラーバジェットが尽きそうになったら、リリースの頻度を下げる or ロールバックする必要があります。 エラーバジェットが多ければプロダクト開発者はリスクを取ることが出来ますし、エラーバジェットが少なければプロダクト開発者はリスクを下げる仕組みづくりに取り組むことになります。 例え外部要因によって障害が起きたとしても、エラーバジェットは消費されます。 プロダクトマネージャーは、イノベーションを取るならSLOを下げ、安定性を取るならSLOを上げることになります。
Error Budgetがなくなったときの取り決めをしなければ、SLOは何の実効性も持ちません。 そのためこの取り決めはとても重要です。全てのステークホルダーが合意するまで、SLI、SLOは調整する必要があります。
Error Budget: https://landing.google.com/sre/workbook/chapters/error-budget-policy/
SLOのTime Window
SLOsは様々時間幅で定義されます。代表的なものは Rolling windowと Calendar Windowの２つです。 ウィンドウを選択するとき、考慮するべき要素がいくつかあります。
Rolling Windowsは移動平均でSLOを導出します。そのためSLOはユーザー体験とより近しい指標になります。 Calendar Windowsは期間を決めてSLOを導出します。そのため、ビジネス上の戦略を立てやすくなります。
時間窓の期間によって、プロジェクトが取る戦略は変わります。 短い時間窓は迅速な意思決定を可能にし、長い時間窓は戦略的な意思決定を可能にします。 Googleでは4週間のローリングウィンドウを採用しています。
