SLOの正しい計測を求めて
適切なSLOを考えるにあたってのヒントをご紹介したところで、次は、SLOの正しい計測について考えてみましょう。
稼働率って何？
ここまでのご説明で、「稼働率」という言葉を何度も使用してきました。では、稼働率とは一体なんでしょうか。「基本情報技術者試験」の勉強をされた方は、稼働率は以下の計算式で求められると記憶されていることでしょう。
- 稼働率 = MTBF ÷ （MTBF + MTTR）
- MTBF（Mean Time Between Failure）：平均故障間隔、正常稼動している平均時間
- MTTR（Mean Time To Repair）：平均修理時間、復旧にかかる平均時間
式にするとややこしく見えますが、稼働率はシステムが正常動作している時間の割合です。では、正常動作とは一体どういう状態のことでしょうか？正常の反対である異常について考えてみましょう。先ほど、「The Four Golden Signals」を紹介する際に、エラーの定義について以下のようにご紹介しました。
エラーリクエストの割合のこと。エラーリクエストは、具体的にはHTTPステータスコードが5XX番のリクエスト、または、ポリシーとして失敗とみなすリクエスト（例えば、1秒以上のレイテンシを要するリクエストはエラーと見なす、など）です。
つまり、システムが正常動作している時間の割合である稼働率を求めるには、1からエラーリクエストの割合を引けばよいですね。エラーが1％であれば、1から1％を引いた99％が稼働率といった具合です。
集計期間を区切る
さて、ここで1つ問題があります。「エラーリクエストの割合」を求めるには、どこかで集計期間を区切る必要があります。ユーザからのリクエストはシステムの提供を終了するまで永遠に発生し続けます。集計期間を区切らない限りは、分母（総リクエスト数）も分子（エラーリクエスト数）も固定できないので、エラーの割合を計算することができません。
では、集計期間の区切り方について考えてみましょう。仮に、月間100万リクエストを処理するサイトが存在したとします。ある日、サイトが24時間ダウンし、10万リクエストに対しHTTPステータスコード500を返したとしましょう。また、問題を簡単にするため、この日以外のすべてのリクエストは正常に処理されていたとします。さて、このサイトの適切だと思われる月次の稼働率はいくつでしょうか？
おそらく、読者のみなさんの発想は2つに分かれたのではないでしょうか。
1つ目は、エラーリクエスト数を総リクエスト数で割り、エラー率を算出するアプローチ。この問題の場合は、エラーリクエスト数10万を、総リクエスト数100万で割り、エラー発生率を10％と考えます。このアプローチは、モニタリングの集計期間を月次で区切っています。
2つ目は、24時間（1日）ダウンしたのだから、エラー発生率は、1日÷30日（1か月）でしょ？ と考えるアプローチ。約3.3％のエラー発生率です。この発想は、無意識のうちに集計期間を1日以下に区切っています。
さて、みなさんにとって、どちらがより自然な集計期間でしょうか？ 多くの人は、後者が自然と感じる方が大半ではないでしょうか。24時間のダウンタイムで分かりにくければ、1秒のダウンタイムと仮定してもよいでしょう。たった1秒ダウンしただけで、稼働率が90％になってしまうことに違和感があると思います。
このように、集計期間をどのように区切り計測するかは、サービスの信頼性を大きく左右する重要なポイントです。みなさんの運営しているサービスにとって、より正しい計測方法を考えましょう。とはいえ、あまり難しく考えすぎずに、まずは計測できるものからはじめるとよいでしょう。前述したようなケースは、極端ですから。
サービスレベルの集計期間をどう考えるべきかについては、書籍『The Site Reliability Workbook』（『Site Reliability Engineering』の後継となる書籍）にも、より詳しく解説されていますので、ご興味ある方はご一読ください。
SLOの運用
さて、ここまで学んだ内容を整理しておきましょう。
- モニタリングは、ユーザ影響の逆算で考える
- 高すぎるSLOは何かを犠牲にする
- サービスレベルの計測には、集計期間を考慮する
これらの基本的な考え方を理解していれば、SLOを決定するための基本的な考え方はマスターしています。あわせて、書籍『The Site Reliability Workbook』のSLOドキュメント例（Example SLO Document）を参考にすれば、みなさんが管理するサービスにあわせたSLOを設定できるでしょう。
さて、最後に、SLOの運用について触れます。SLOは、定義し、実際に運用されてはじめて効果を発揮するため、実はここが最も重要であると言えます。
関係者とSLOの内容を合意する
まずは、設定したSLOについて、ぜひ社内の関係者に共有してください。そして、自分たちが運用しているシステムは、このSLOで適切かどうかを議論し、合意しましょう。
SLOを守れなかった時の運用をチームで合意する
SLAであれば、違反時に返金対応などを行うことは前述しましたが、SLOを守れない時は、どうすればよいのでしょうか。SLOは、チームで合意したシステムの信頼性に関する目標なので、守れなかった時にはシステムの信頼性を維持・向上するためにチームで協力することが重要です。例えば、SLOを違反しそうになったら、新規機能追加は中断し、バグを修正したりするとよいでしょう。
SLOを守るためにエラーバジェットを運用する
また、SLOを違反していないか？ を意識するために、エラーバジェットの考え方を利用するとよいでしょう。エラーバジェットは、エラーを予算のように扱う考え方で、（1-SLO）×SLOの計測期間で求められます。例えば、毎月のSLOを99.9％の稼働率とすると、エラーバジェットは43分です。43分のバーンダウンチャートを用意し、エラー発生時に減らしていくことで、今月はあとどれくらいのエラー発生時間が許容されるかをチームで共有することができます。
さいごに
本記事では、SREにとって欠かせないモニタリングやSLOの定義、運用について整理しました。みなさんの会社でSREをはじめるご参考になれば幸いです。
何か分からないことがあれば、ぜひ本記事の筆者（@katsuhisa__）にご相談ください。
次回記事では、サービス信頼性階層において、モニタリングの1つ上位層であるインシデントレスポンスや、ポストモーテムの詳細を深掘りします。お楽しみに。
