はてなの「Mackerel」から始まったSLO運用の実践例
では、どのようにしてSLOを決めていくのか。古川氏のおすすめは「簡易的なものでいいので決めて、まずはさっさと仮運用を始めること」という。
「SLOは定期的に何度も見直すことになるので、ウォーターフォール的に行う必要はない。簡単かつ小さなことからアジャイル的に始めて、見直し、足りなければ追加するという方法だ。ただし、チーム内のライフサイクルの中にSLOの見直しを組み込むのは必須であり重要だ。スクラムをやっているなら、スプリント会などマネージャーを含めたステークホルダーが参加する会で見直すとよいだろう。まずは興味を持ってもらい、やってみようと思わせることが大切だ」
そして、SLOの仮運用の流れを次のように説明した。
（1）SLOを決める
競合サービスや明確な理由があれば、その数値を用いる。不明なら1カ月のエラーバジェットで99～99.9％で始めるのが妥当。
（2）SLIを決める
SLIは「サービスレベル指標（Service Level Indicator）」であり、500系のエラー率やレスポンスタイム、レイテンシなどが一般的。
（3）SLOの見直しをする期間と会を決める
スプリント会などで、プロダクトマネージャーと開発者、SREを含めた場で見直す。最初は1週間に1回、慣れてきたら1カ月に1回くらいの頻度が良い。
（4）上記の内容を明文化しておく
決めた理由は記載しておく必要がある（根拠がない場合は「根拠なし」と記載しておく）。また仮運用中はエラーバジェットポリシーでデプロイの禁止などはしなくてもよい。
なお、はてなのプロダクトであるサーバー監視サービスの「Mackerel」では、レスポンスタイムなどを取得し、500系エラー率を出して可視化・アラートで知らせてくれるため、気軽にSLOの仮運用ができる。そうしたツールを活用するのも良いだろう。その後SLOの運用については、改善や調整が必要になる。
「SLOを改善していくには、SLIの改善・調整が必要になる。その調整によって現実とのすり合わせができたら、エラーバジェットポリシーにデプロイの凍結なども盛り込み、実際の本運用を行っていくとよい」と古川氏は語った。
開発パフォーマンスと信頼性のベストバランスとは
SLOは、まずユーザーの満足度を満たす数値を定め、その上で、細かい調整が必要になる。その時、「開発パフォーマンス」と「信頼性」のトレードオフのバランスが重要なカギになる。たとえば、SLOを99.9％から99.8％に下げたら、どれだけ開発パフォーマンスが上がるのか。逆にエラーバジェットが大量に余っている場合、SLOが低すぎるのではないか。そうした問いに対し、定量的に測定し判断する方法があるという。
SLOの判断をする上で指標になるのが、「開発パフォーマンス指標」だ。エンジニアリングリーダー必読の書『LeanとDevOpsの科学』ではソフトウェアデリバリーのパフォーマンスとして記されており、「リードタイム」「デプロイ頻度」「平均修復時間」「変更失敗率」の4項目が挙げられている。これらの指標からは、変更した際に起こりうる障害の時間が予想できる。
そして、予測された障害時間を定量的に比較し、それを判断の材料としようというわけだ。古川氏は、開発パフォーマンス指標から変更起因障害予想時間（＝デプロイ頻度×変更失敗率×平均修復時間）について仮の数字を入れて計算してみせた。
たとえば、変更失敗が20回のうち1回で5％、1回の障害で30分かかるというパフォーマンスのチームだとする。その場合、稼働日30日として20回デプロイしたとすれば、失敗は1回、障害復旧に30分かかる。つまり、そのチームの変更起因障害予想時間は30日で30分ということになる。
では、SLO側から変更起因障害許容時間（＝（1－SLO）×ウィンドウサイズ×変更起因障害の割合）を計算すると、可用性が99.9％の場合、エラーバジェットが0.1％なので、稼働を30日とすると障害時間が43分。このうち変更起因障害の割合が60％とすると（「SRE Workbook」の障害原因の例を参考に仮定）、変更起因障害許容時間は30日で26分ということになる。これを古川氏らは「はてなSLOモデル」と呼んでいる。
つまり、このチームのパフォーマンス指標から算出される「変更起因障害予想時間」は30分、SLO側から算出される「変更起因障害許容時間」は26分となり、予想時間が許容時間を超えてしまうため、このチームではSLO違反する可能性があると判断される。
それでは、SLOに違反しないようにするためにはどうしたらいいのか。1つ目は変更起因障害予想時間を減らす方法だ。掛け算の数字の中で最も減らしやすいのが「デプロイ頻度」だろう。失敗率を減らす、修復時間を短くするのも限度があるが、デプロイ頻度を下げるにはデプロイしないだけでいい。つまり、エラーバジェットポリシーでデプロイを凍結するのがプラクティスになる。
逆に変更起因障害許容時間を増やす方法もある。その場合は、エラーバジェットや変更起因障害の割合を増やすことになる。というのも、ネットワークやハードウェアの障害はコントロールが難しいため、ある程度の割合は確保する必要がある。そこで、基本的にはユーザーの満足度を毀損しない範囲でSLOを下げることが一番楽な選択肢になり、この場合は、99.8％にすればデプロイの回数も変えずにクリアできる。むしろ、毎日デプロイしても大丈夫というわけだ。
古川氏は「注目してほしいのは、SLOを0.1％下げただけでもエラーバジェットが2倍になっているということだ。変更失敗率を下げるためにバグの発生を2分の1にする、平均修復時間を半分にするというのに比べて、デプロイ回数を2倍確保するバジェットを得られるというのはかなり大きい。こうした感覚をプロダクトマネージャーに理解してもらえるよう、こうした計算を行って協議をしている」と語った。
もちろんこうした数字はあくまで参考値で、予測に過ぎない。しかし、プロダクトマネージャーの目標がイメージしやすくなるのは重要であり、とりわけSLOよりも、「毎日機能をデプロイしたい」という方が伝わりやすい。そして、それを達成するために何をどうすべきなのか、ユーザーの満足度を下げないのか、開発チームのパフォーマンスと信頼性が矛盾した目標になっていないかなどを、具体的に確認できる。
ただし、こうしたことができるのは、あくまで開発パフォーマンス指標が計測できている場合に限られる。それについては、はてなのデベロッパーブログにも掲載されているので参考にするとよいだろう。
古川氏は「チーム構成については、インセンティブ設計や組織論など、ネットワークやシステム構成を考えるようで面白かった。また、アプリケーションエンジニア出身者にとっては、モジュール設計やクリーンアーキテクチャ、DDDのように感じられるだろう。SLOについても信頼性を定量化してモデルとして扱えるようにするのは、まさにソフトウェアエンジニアリングを感じた」と振り返り、「これによりDevチームに歩み寄れた気がした。議論ができたことも良かった。当然インフラ構築、運用、監視の面白さもあり、総合して、システムを扱う面白さがSREの面白さだと感じた」と語った。
さらに古川氏は、「人のシステムと機械のシステムの直列系が、Webサービス全体のシステムであり、両者の信頼性があって全体の信頼性が担保される。両方を見て、コントロールして信頼性を実現し、ビジネスに貢献していくことがSREの働き方ではないか」と続け、機械と人を結ぶ「ソフトウェアエンジニアリング」が必須であることを強調した。そして、人と人とを結ぶための「コミュニケーション」、さらに機械と機械を結ぶ「システムエンジニアリング」、その3つをうまく活用していくことがSREには大切だという。
「自分の得意な領域を発揮しながら、SREを組織に導入することは、大変チャレンジングで面白いこと。ぜひとも挑戦してほしい」と熱く語り、セッションのまとめとした。
本セッションの動画をMackerel Webサイトで無料公開中！
「Mackerel開発チームのリードSREが考える働き方と組織作り」と題し行われたセッションの模様を動画にし、一般公開中です。Developers Summit 2021 Summerに参加された方も、ご覧いただけなかった方も、ぜひご覧ください。
