こんにちは。Mackerel プロデューサーの 
id:wtatsuru です。最近、世界的にSLOが流行していますね。『SLO サービスレベル目標』 という本がもうすぐオライリー・ジャパン社から刊行されるようなので、私も楽しみにしています。そんなSLOに寄せての記事です。
SLO（Service Level Objective）とは、可用性やエラー率などのサービスレベル指標（SLI, Service Level Indicator）について定める目標で、SREの考え方に基づいた運用で使う考え方の1つです。最近では、SLOに基づいた運用の事例も増えてきました。Mackerelチームでも実際にSLOを定めて運用し、Mackerel自体の開発にも活かしています。Mackerelを使った実装や、実際の運用状況については以下の記事をご覧ください。 mackerel.io mackerel.io
私は2023年1月までMackerelのプロダクトオーナーとして開発方針の策定をしていました。Mackerelは運用に組み込まれるサービスであり、その信頼性には気を遣いますが、一方でMackerel自体が進化し続けることも重要であり、バランスを取る必要があります。この記事では、「プロダクトオーナーとしてSLOとどう向き合ってきたか」という観点での事例を3つ、紹介します。
初期設定はスモールスタートで
自然界にSLOはないため、まず最初に設定する必要があります。前述のとおりMackerelも信頼性は重視しますが、一方で日々開発する中でエラーや性能低下が発生することも多いため、それに対応するための方針を決めたいというモチベーションで始めました*1。
システムの重要性、可観測性も考慮して最初に選んだのが、WebコンソールとAPIでした。元々チームの目標などで値を設定していたのを、SLOとして改めて置き直した形です。
最初の設定にあたっては、観測のみの仮運用として始めています。例えば「応答速度が100ミリ秒改善されたらどれくらい体験が変わるのか決めてくれ」とある日突然言われても困りますし、「開発を止める基準」のような強い基準も決めるのは難しいでしょう。まず実績ベースで提案をもらい、違反ポリシーも「調査を検討する」などから始めました。SLOを割るのはどういう状況で起きるのか、そのポリシーによりチームでどういった判断がなされる想定なのかを見つつ、チームに合ったラインを探っていきました。
策定の様子や実際の内容については、以前にMackerelチームのSREが発表したスライドがありますので、気になる方はご覧ください。 speakerdeck.com
判断の瞬発力から改善のサイクルへ
SLOを設定して嬉しいことといえば、信頼性を都度判断の瞬発力で解決するのではなく、計測をもとにした改善のサイクルに載せられることです。
システムを運用していると、障害やエラーは当然発生します。ただでさえ普段から考えることが多いのに、今発生していそうなパフォーマンス対策と今週進めたい開発どちらを選ぶか、のような瞬発力と判断を迫られるケースは多いのではないかと思います。こんなことが続くのは結構大変だし疲れますよね。そんなとき、「このペースではSLOを割りそうだから調査しよう」「これくらいならSLO割らないから大丈夫」とSLOをもとにチームで自主的に動いてもらえる状態は、かなり助かるものです*2。
代わりに、SLO自体についての試行錯誤、つまり基準の見直しが必要となります。これはSLIとして定量的に観測されており、チームとして改善のサイクルを回すことができます。最初は見直し周期を短めにしておくと、比較的早く試行錯誤できるのでおすすめです。また、信頼性は高すぎるケースも多いので、見直しにおいては「この水準は下げてもいいんじゃないか」という目線で見るのもよいでしょう。
ちなみにMackerelのエラーバジェットポリシーは機能開発を止めることもある記述となっているのですが、実際に止めたことはほとんどありません。基本的には「急ぎ調査する」というアクションをとっています。エラーバジェットを使い切っているから一部のリリースを遅らせる、のようにチームでの判断基準としてSLOが浸透しています。
曖昧さと難しさはそのまま残る
長く運用しているプロダクトだと特に、システムの隅々まで把握するのは難しいでしょう。認識の曖昧さ、難しさのようなものはSLOを設定したからといって解決はしません。
例えば、機械学習の仕組みはよくある例でしょう。学習が止まっても直ちに影響があるわけではないのですが、モデルの更新が遅れると徐々にサービスレベルが低下します。どの程度落ちたらサービスに影響があるとみなすのかという基準設定は非常に難しいですし、SLOを設定しようとしても難しさは変わりません。機械学習については事例も出つつあるので、世のセオリーが定まるとこの辺りの負担は減るかもしれません。
Mackerel でも、難易度とシステムの重要度を鑑みて設定していない部分もあります。可用性100%が現実的でないのと同じく、システムの全てをSLOでカバーしようというのもおそらく現実的ではないとは思うので、この辺りもいいバランスを見極めてやる必要があると感じています。
まとめ
SLOを使った運用について、プロダクトオーナーの観点でのポイントを紹介していきました。導入の最初は結構大変ですが、SLOがあることで嬉しいことも多いので、まだSLOの運用をされていない皆様もぜひ取り入れてみてはいかがでしょうか。 MackerelチームではSLOを日々の開発・運用に活かしつつ、ユーザーの方にもこういった運用を簡単に実現していただけるようプロダクトの改善も続けています。
[PR] Mackerel Meetup #14 Tokyo を開催します
Mackerel Meetup #14 Tokyoを2023年7月11日（火）に開催します。Mackerelの開発状況の共有や情報交換を行うオフラインイベントが4年ぶりに帰ってきました！ Mackerelユーザーによるご講演もあります。ぜひご参加ください。
*1:ある程度成熟したプロダクトにおいて、可用性が低すぎるということはそこまで多くないのではないかと思います。2022年のState of DevOps Report においても、初期段階以外は信頼性は「たいてい期待にかなう」となっているようです。
*2:もちろん、重大な影響が起きるものについてはSLOを割っていなくても割り込みでの対応を入れることはあります。
