「SLO サービスレベル目標」読書メモ③

Azukaritaiの小松です。引き続き、O'reillyの「SLOサービスレベル目標」について、AzukaritaiのSREチームで読んで学んだことについての読書メモをまとめていきます。この記事では第2部の「SLOの実装」について扱います。

6章 同意の獲得

この章では、SLOの考え方を実際の現場に導入する上で、どう関係者に賛同してもらうか、という話です。この話が、第2部の最初の章になるのには違和感があったのですが、それぐらい、SLOの考え方を導入する際に、色々な人がいろいろな理由で難色を示したり、協力してくれなかったり、反対したりするということがありがちで、それをどう解決し突破するかが、SLOを導入する上で重要なポイントになるということかと思います。

以前読んだ、「オブザーバビリティエンジニアリング」にも、同じような、導入する上でどうステークホルダーを説得していくか、という話に一つの章が割り当てられていました。オブザーバビリティも、SLOも、導入することで、既存の仕組みを置き換えたり、広範囲のステークホルダーに新しい考え方を要求するものだったりするので、どう理解してもらい、賛同してもらうか、というのを丁寧にやっていく必要があるのだろうと理解しました。

7章 SLIとSLOの計測

この章が、本丸というか、SLIとSLOをどう決めて、実際に計測して運用し始められるようにするために具体的にすることが書かれているメインの章、という感じです。通常のアプリケーションコードの開発と同様にまず、要件というか設計目標を設定して、それを満たすにはどういう実現方法をとるか、という考え方をしていきましょう、ということが、7.1に書かれていました。
キーワードとしては、柔軟性、テスト可能、鮮度、コスト、信頼性、組織の制約というところで、それぞれこのような観点を意識して、必要な水準を満たすSLI・SLOを設定し実現しましょう、ということと理解しました。この辺りを満たしていくテクニックとして、過去のメトリクスを集計値としてではなく、根源的なイベント単位の計測値として持っておいて、後に閾値を変更しても評価できるようにする、ということであったり、変更するときに、バックテストをできるようにしたり、ということが書かれています。また、いくら理想的な指標を組み立てたとしても、取得するのにコストがかかりすぎたり、組織の制約を満たさない方法では取れない、などの要件も考慮に入れる必要があるということです。

SLI・SLOの計装の実現方法の典型として紹介されているものとしては、時系列データベース（TSDB）と構造化ログによる構造化イベントデータベースの話がでてきます。以前読んだオブザーバビリティ本では、TSDBを使うと必要な情報が欠落し、オブザーバビリティの観点では不足が生じるという話が書かれていたのですが、この本では、逆にコストの面で、大量のデータを構造化イベントデータベースに保存しようとすると、コストが合わなくなるリスクがあるので注意して、TSDBをうまく使う話に焦点を当てられていたのが印象的でした。

8章 SLOの監視とアラート

いわゆるSLOアラートについての章でした。まず、なぜ既存のSLOアラート以外のアラートがなぜうまく機能しないのか、という話をかなり細かく具体的に、10ページほど割いて丁寧に解説していました。ざっくりというと、不必要な（実際には何もアクションを起こす必要のない）アラートが大量にとび、いわゆる「アラート疲れ」がおき、本当に必要な時に対応できなかったり、人がやめたり、いろいろな悪いことが起きますよ、というお話。

なので、SLOアラートの導入にあたっては、SLOアラートを、既存のアラートに追加するという話ではなく、既存のアラートを破棄して、SLOアラートだけにするべき、という話になってきます。なかなか極端な話だな、と聞こえてえしまったり、実際に、組織の中でこれをやろうとして、既存の監視やアラートを止めることに不安を覚える状況についても、本文中で触れられています。

また、SLOアラートのより高度な運用方法として、バーンレートという、一定期間におけるエラーバジェットの消費傾向をもとに、エラーバジェットが枯渇するリスクがありそうな時にアラートをあげるというテクニックが紹介されています。このバーンレートベースのアラートも、どれぐらいの期間でバーンレートを見るか、によって、状況変化に対する即応性が変わってくるなど、かなり奥が深そうです。

9章 SLIとSLOの確率と統計

SLI・SLOを考えるときに必要な統計の話の章。正直なところ、苦手ジャンルで、こういう書籍で数式が見えると流し読みになってしまうのですが、SLI・SLOで安易に平均値を使ったりすると、信頼性の観点から重要な情報が欠落してしまったりするので、ちゃんと理解して、対象とする指標の性質にあった処理をしましょう、という話と理解しました。詳細は割愛します。。

10章 信頼性を得るためのアーキテクチャ

設定したSLOを達成するために、システムのアーキテクチャ設計でどういうことを考慮する必要があるか、という話。SRE NEXT 2023 で山口さんが最後に話していたトピックとも重なります。
SLOで、可用性の目標が設定されていたり、レスポンスタイムの目標が設定されていたりすれば、アーキテクチャはそれに従い、可用性の目標を満たすために必要な、発生しうる障害及びそこからの復旧時間の短縮のための対策をアーキテクチャレベルで盛り込むことになります。逆に、SLOが最もユーザーの要求を代表する指標であれば、SLOで設定した以上の信頼性のためのアーキテクチャは不要という割り切りが可能になり、不必要な水準の信頼性のためのアーキテクチャの実現にコストを払う必要がなくなるということになります。

11章 データの信頼性

データの信頼性の計測やは、他の信頼性指標とは違う要素についての考慮が必要で、それはシステムの可用性や性能の指標よりも難しそうです。
また、ユーザーのデータを保管するサービスにおいては、一般的にデータが保管されていることを期待されるわけで、保管しているデータが一時的に取り出せないとか、取り出したデータの内容が別のものに書き換わっているとか、保管したデータが失われたりというのは、それがごく一部であっても許されないもので、それが起こったら、そのユーザーは2度とそのサービスを使わないレベルで、期待を裏切られたと感じることになるわけで、そういう意味で、可用性の9の数と、データの信頼性についての9の数は違ってきますよね、ということがまず書かれています。

データサービスの信頼性を検討する上で候補になりそうな属性もいろいろあり、データ自体の属性として「鮮度」、「完全性」、「一貫性」、「厳密性」、「妥当性」、「整合性」、「耐久性」があり、データアプリケーションの属性として「セキュリティ」、「可用性」、「スケーラビリティ」、「パフォーマンス」、「回復力」、「堅牢性」がこの本の中で挙げられていました。

データサービスについては、一言で信頼性と言っても、いろいろな要素があることがわかり興味深いなと思いました。

12章 適切に機能した例

第二部の最後の章では、具体的な例をベースに、SLI/SLOがどう設定され、チームの中で使われるようになるのか、というのをかなり詳細に説明しています。

このケーススタディの中では、マイクロサービスアーキテクチャを採用しているプロダクトにおいて、それぞれのマイクロサービスのコンポーネントや、システム内の各要素が絡むアクターごとの複数のクリティカルユーザージャーニーについてSLI/SLOを設定しています。SLI/SLOは複数設定されて良い、というのはありつつ、それをいくつ設定するべきか、というところについて、考え方の良い参考になるなと思いました。

また、具体的なストーリーの中で、SLI/SLOがどのように設定され、使われるかという流れも見え、実際に導入する時のイメージが掴みやすくなりました。

まとめ

第1部に続いて、SREのプラクティスの中でも中心的なSLOについてしっかりと深く、色々な面からそれについて説明をする内容になっていて、だいぶSLOについての理解が深まってきたなという感触が得られました。まだ、実際に試し始められていないのですが、実際のプロダクトの中で実践していきたいなと思うようになっています。引き続き第3部も読んでまとめていきたいと思います。