SLO とは？ 個人開発者のための実践ガイド

· · Tech stack decisions
要約

SLOとは、測定可能な指標に対する社内の信頼性目標のことです。例として、30日間で99.9%のリクエストが成功する、といった形で定めます。目標と100%との差がエラーバジェットで、99.9%なら1か月に約43分です。個人開発は99%から99.5%から始め、単発のブレではなくバーンレートで通知し、バジェットを出荷か修正かの判断に使うのがおすすめです。

夜遅く、暗いデスクの上でサービスの稼働状況ダッシュボードを表示するノートパソコン

SLO とは、サービスがどれくらいの頻度で正しく動くべきかを、一定の期間で測って決める目標の数値です。「30日間で、リクエストの99.9%が成功する」がSLOの一例です。「なんとなく調子がいい」という感覚を、確認できる数字に変えてくれます。そして、いつ新機能の開発を止めて修正に集中すべきかも教えてくれます。

特別なプラットフォームチームは必要ありません。APIとPostgresが1つあるだけの個人開発でも、午後1つ分の時間で実用的なSLOを書けます。この記事では、用語の意味、目標値の決め方、よくある失敗を順に説明します。

深夜2時、アプリが壊れているか誰にも分からなかった

週400人が使う個人プロジェクトを想像してください。ある夜、チェックアウトのAPIが約20分間500エラーを返し続けます。誰もツイートもメールもしません。3日後、サポートへの1通の問い合わせで、ようやく気づきます。

それは深刻な障害だったのでしょうか。目標がなければ答えられません。目標があれば答えられます。SLOが月43分の失敗を許しているなら、20分を失った時点で許容量のほぼ半分を、1晩で使ったことになります。SLOが果たす役割は、感覚を予算に置き換えることです。

SLI、SLO、SLAの違い

SLI、SLO、SLAはよく混同されるので、簡単に整理します。

順番が大切です。まずSLIを決め、次にSLOを決めます。SLAを考えるのは、有料の顧客が書面で求めたときだけで十分です。詳しく知りたい場合は、Google SREワークブックのSLO実装の章が標準的な参考資料です。

ストップウォッチと、エラーバジェットを表す半分埋まったバーのノートスケッチ

エラーバジェットは働き方を変える

99.9%のSLOは、裏を返せばイベントの0.1%が失敗してもよいという意味です。その許容分がエラーバジェットで、この考え方の中で最も役に立つ部分です。

30日の1か月では、99.9%の可用性で約43分の停止が許されます。計算は、30日×24時間×60分=43,200分に0.001を掛けたものです。99%なら約7.2時間、99.99%なら約4.3分になります。

最後の2つの数字が、小規模なプロジェクトが高い目標を狙うべきでない理由です。月4.3分では、悪いデプロイを1回ロールバックしただけで目標を割ります。目標を高くするほど、時間は製品づくりではなく数字を守ることに使われていきます。

バジェットは、次に何を作るかの判断基準にもなります。バジェットがほぼ残っていれば、リスクのある機能をリリースします。使い切っていれば、まず不安定な部分を直します。会議は要りません。ダッシュボードに数字が1つあれば十分です。

測定できるSLIと、低めに始める目標値

まず、ユーザーが「壊れている」と感じる状態を考えます。Webアプリなら、結局2つの問いに行き着きます。リクエストは成功したか。十分に速かったか。

ほとんどの個人プロジェクトでは、2つのSLIで価値の9割をカバーできます。

レイテンシは平均ではなく、しきい値以内の割合として書いてください。平均は遅い部分を隠してしまい、ユーザーが離脱するのはまさにその遅い部分です。平均300msでも、p99が4秒ということは普通に起こります。

測定はシステムの端、つまりユーザーにできるだけ近い場所で行います。VPCの内側から/healthzを叩くヘルスチェックは、プロセスが生きていることは示しますが、ユーザーがログインできることは示しません。1つしか測れないなら、ログインやチェックアウトといった実際のユーザー経路を外側から測ってください。

新規プロジェクトの正直な答えは、99%か99.5%です。直近30日のデータから実際に出せていた値を確認し、その少し下にSLOを置きます。ユーザーから不満が出たら、そのとき締めれば十分です。目安は次のとおりです。

100%を達成し続けるSLOは、低すぎる数字です。毎月必ず外すSLOは、誰も信用しない数字です。たまに外すくらいがちょうどよく、そのときこそバジェットが仕事をします。

夕暮れのバンコクのカフェで、ノートパソコンに映る平らで安定したレイテンシのグラフ

アップタイム監視との違い、そして今日書ける小さなSLO

完全に同じではありませんが、重なる部分はあります。死活監視は、ある時点でサイトが応答したかを教えてくれます。SLOは、1か月の間に実際のユーザーのリクエストのうち何%が成功したかと、その結果次の判断をどうすべきかを教えてくれます。

たとえば2週間、死活監視が毎分グリーンを示していたとします。その間、遅いデータベースクエリが原因で、ログイン済みユーザーの3%でダッシュボードがタイムアウトしていました。死活監視は「問題なし」と言います。SLIは「レイテンシの目標を外した」と言います。月曜日に何をするかを変えるのは、後者だけです。

死活監視は捨てなくてかまいません。安価で、全停止を素早く検知できます。ただし「正常」の定義ではなく、判断材料の1つとして扱ってください。

ベンダーを使わなくても、今日からすぐ始められます。リポジトリにSLO.mdというファイルを作って、次のように書いてください。

service: checkout-api
window: 30d
slis:
  availability:
    good: http_status < 500
    total: all requests except /healthz
  latency:
    good: response_time < 500ms
    total: all requests except /healthz
objectives:
  availability: 99.5%
  latency: 95%
if_budget_burned:
  - freeze non-urgent features
  - fix the top error source first

Prometheus形式でリクエスト数を出しているなら、可用性のSLIは1行で書けます。

sum(rate(http_requests_total{status!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))

その比率を目標値と比べたものが、SLOダッシュボードのほぼすべてです。パネルは3つで十分です。現在のSLI、残りのバジェット、バーンレートの推移です。

バーンレートで通知する、そしてツールの選び方

ほとんどの人がやってしまう失敗は、エラー率がしきい値を超えたら通知することです。その結果、1か月のバジェットの0.2%しか使わなかった90秒のスパイクで、午前3時に叩き起こされます。

バーンレートは、この問題を解決します。バジェットを消費する速さが、ちょうど期間の終わりにゼロになるペースの何倍かを表します。バーンレートが1なら、月末に予算を残さず終えられます。バーンレートが10なら、3日で空になります。

一人で運用するなら、通知は2つで十分です。1時間で10倍を超えたら速報として起こしてもらう。1日で約2倍なら、翌朝対応するチケットにする。この考え方の根拠はGoogle SREの書籍のSLOの章にあります。複数ウィンドウの詳しい版はワークブックにあります。

夜間のアラートで光る、ベッドサイドテーブルの上のスマートフォン

数か月は、スプレッドシートとcronだけでSLOを試せます。何を大事にしたいかが分かってきたら、ツールを入れる価値が出てきます。候補は3つあります。ただし、機能の一覧よりも既存のスタックのほうが選択を大きく左右します。

Grafanaは、すでにPrometheusでメトリクスを出している人にとっての定番です。無料枠は個人プロジェクトには十分で、SLO機能は既存のデータの上に載ります。メトリクス基盤がまだなく、構築する意欲もないなら、選ばなくて構いません。

New Relicには無料枠があり、月100GBまでのデータ取り込みに対応しています。SLOのツールもプラットフォームに組み込まれています。設定をほとんどせずにエージェントで始めたい人に向いています。ただし、無料枠を超えると費用が読みにくくなります。

Datadogは最も機能が揃っていて、最も高価です。インフラ、APM、ログがそれぞれ別料金です。周りでチームが育っているなら検討の価値がありますが、他の誰かが払ってくれるのでなければ、一人のプロジェクトには向きません。

どのツールを選んでも、初日から15個のSLOを定義したくなる衝動には抵抗してください。ユーザーに見える各サービスにつき、可用性のSLOとレイテンシのSLOを1つずつ。それだけあれば、学ぶには十分です。

1か月分の計算で見るエラーバジェット

SLOが30日間で99.5%の可用性だとします。1か月に約600,000件のリクエストを処理しています。この目標は0.5%の失敗を許すので、バジェットが尽きるまでの失敗は3,000件です。

9日目、悪いマイグレーションで25分間500エラーが出て、失敗が1,100件増えました。たった1回の夜で、バジェットのおよそ37%を使ったことになります。17日目には、外部APIのタイムアウトでさらに900件を失いました。これで使用率は約67%、残り13日です。

ここでバジェットが役に立ちます。パニックになる必要はありませんが、20日目に予定していた危険なリファクタリングは出さないほうがいい。外部APIの呼び出しにタイムアウトとフォールバックを入れ、飛ばしていたマイグレーションのチェックを書き、リファクタリングは来月に回します。

要点は、失敗が悪いということではありません。失敗は想定内で、あらかじめ織り込まれています。この数字が与えてくれるのは、「今このリスクを取る余裕はあるか」への落ち着いた、共有できる答えです。部屋にいるのがあなた一人だけでも、その価値は変わりません。

数値を見直すタイミングと、SLOを無意味にする3つの失敗

SLOは四半期ごとに見直してください。バジェットを大きく外した月や、まったく使わなかった月の後にも見直します。2か月連続で外したなら、システムに本格的な手入れが必要か、目標がその段階には野心的すぎたかのどちらかです。どちらも有用な事実です。

有料の顧客が増えたら、その人たちにとって「壊れている」とはどういうことかを聞いてみてください。毎週のレポートを使う顧客が気にするのは、土曜の夜の数秒の揺らぎではなく、月曜の朝です。SLOをその顧客の利用時間帯だけ厳しくすることもできます。

測りやすいものを測ってしまうこと。 CPU使用率はSLIではありません。ユーザーは、CPUが40%かどうかを気にしていません。ページが開いたかどうかを気にしています。

野心から目標を決めること。 「5ナインを目指す」は立派に聞こえますが、データベースが小さなVMの1インスタンスなら、何の意味もありません。実際の状況から目標を決め、システムを改善し、そのあとで数字を締めてください。

バジェットを使わないこと。 毎月98%のバジェットを残して終えているなら、開発が遅すぎるか、目標が緩すぎます。使われないバジェットは、取れたはずのリスクを取らなかったことを意味します。

最初にSLOを置くのは、どのサービスでしょうか。ユーザーが壊れたとすぐ気づくものを1つ選び、SLIを平易な言葉で書き、目標値を先月実際に出せていた値の0.5ポイント下に置いて、30日後にもう一度確認してみてください。いま一番信用できないのは、どのサービスですか。

よくある質問

SLOとは、簡単に言うと何ですか？
SLOは、サービスの信頼性について一定期間で測る目標です。たとえば、30日間でリクエストの99.9%が成功することを目指す、といった形で決めます。顧客との契約ではなく、社内の目標です。
SLI、SLO、SLAの違いは何ですか？
SLIは測定値で、たとえば5xx以外を返したリクエストの割合です。SLOはそのSLIに対する目標です。SLAは、目標を守れなかったときに返金などの罰則を伴う契約です。
99.9%の目標では、1か月に何分まで停止が許されますか？
30日の1か月で約43分です。99%なら約7.2時間、99.99%なら約4.3分になります。
エラーバジェットとは何ですか？
SLOの下で失敗が許されるイベントの割合のことです。99.9%なら、リクエストの0.1%まで失敗してもかまいません。バジェットがほぼ尽きたら、リスクのあるリリースを止めて、まず信頼性を直します。
個人開発は、どのSLOから始めるべきですか？
99%から99.5%から始め、直近30日間で実際に出せていた値より少し低く設定します。顧客や収益の事情がはっきりするまで、締めすぎないようにしてください。
SLOの追跡には、有料ツールが必要ですか？
必要ありません。リポジトリ内のファイル、アプリのリクエスト数、簡単なクエリがあれば始められます。バーンレートの通知やダッシュボードが必要になったら、GrafanaやNew Relicが役立ちます。
バーンレートとは何ですか？
バジェットを消費する速さを、期間の終わりにゼロになるペースと比べた倍率です。バーンレートが10なら、30日の期間のうち約3日で予算を使い切ります。
~/build
アイデアを生成