SRE という言葉は聞くものの、自分たちのような小さなチームに関係があるのか、何から始めればよいのか分からない、という人に向けた記事です。SRE の考え方を Google が公開している『Site Reliability Engineering』(以下、SRE 本) と『The Site Reliability Workbook』(以下、ワークブック) をもとに説明し、SLO とエラーバジェットを実際に計算します。後半では、専任の SRE がいない 2〜5 人のチームが 4 週間で始める手順を紹介します。
SRE とは
SRE (Site Reliability Engineering、サイト信頼性エンジニアリング) は、サービスの信頼性を、ソフトウェア開発の方法で管理する考え方と、その仕事をする職種のことです。Google で生まれ、SRE 本で広く知られるようになりました。
SRE 本は SRE を「ソフトウェアエンジニアに運用チームを設計させたら生まれるもの」と説明しています。手作業で回していた運用を、測定、目標、自動化に置き換えていく、という意味です。
SRE の中心にある考え方は次の 3 つです。
- 信頼性を数字で決める。どこまで失敗してよいかを数字 (SLO) で決め、その範囲で新機能のリリースと安定のバランスをとる
- 繰り返しの手作業 (トイル) を測り、自動化で減らす
- 障害を個人のせいにせず、仕組みを直して学ぶ (ポストモーテム)
DevOps との違い
DevOps は開発と運用の壁をなくし、一緒に速く安全にリリースしようという考え方や文化を指します。SRE はその考え方を「SLO」「エラーバジェット」「トイルの上限」のような具体的な決まりと数字に落としたものと捉えると分かりやすいでしょう。どちらか一方を選ぶものではなく、DevOps を進めるための具体的なやり方の 1 つが SRE です。
100% の信頼性を目指さない
SRE の考え方でまず驚かれるのが、信頼性 100% を目指さないことです。SRE 本は「100% は、ほぼすべてのものにとって間違った信頼性の目標だ」と書いています。
理由は 2 つあります。1 つは、利用者の側のスマートフォンや回線のほうが、サービスよりずっと頻繁に失敗することです。サービスを 99.99% から 99.999% にしても、利用者はその差に気づきません。もう 1 つは、信頼性を上げるほど、費用と開発の速さの犠牲が急に大きくなることです。変更はすべて障害の元になりうるので、100% を目指すなら何も変えないのが一番になってしまいます。
そこで SRE では「ここまでは失敗してよい」という量を先に決めます。これがエラーバジェットです。
SLI・SLO・SLA とは
SRE 本の定義をもとに、3 つの言葉を整理します。
| 言葉 | 意味 | 例 |
|---|---|---|
| SLI (Service Level Indicator、サービスレベル指標) | サービスの水準を表す、慎重に定義した測定値 | 注文 API のリクエストのうち、エラーにならなかった割合 |
| SLO (Service Level Objective、サービスレベル目標) | SLI の目標値 | 4 週間で 99.5% 以上 |
| SLA (Service Level Agreement、サービスレベル合意) | 利用者との約束。守れなかったときの結果 (返金など) を含む | 月間の稼働率 99.0% を下回ったら利用料の 10% を返金 |
SLA は契約の話で、守れなかったときに何が起きるかが決まっているのが特徴です。結果が決まっていないなら、それは SLO です。
社内で使う SLO は顧客と約束した SLA より厳しくしておきます。SRE 本はこれを「安全のための余裕」と呼んでいます。社内の SLO を割った時点で手を打てば、SLA を割る前に間に合います。
SLI は「良いイベント ÷ 全イベント」で決める
ワークブックは SLI を「良いイベントの数 ÷ 全イベントの数」という割合で表すことを勧めています。0〜100% の値になり、どの SLI でも同じように扱えるからです。Web サービスでよく使う SLI は次の 2 つです。
- 可用性: 全リクエストのうち、成功した (HTTP 5xx にならなかった) リクエストの割合
- レイテンシ: 全リクエストのうち、決めた時間より速く返せたリクエストの割合
レイテンシは平均ではなく、割合やパーセンタイル (遅い方から数えて何% 目かの値) で見ます。平均では、一部の利用者だけがとても遅い状態が隠れてしまうからです。ワークブックの例では「90% のリクエストが 450 ミリ秒未満」「99% が 900 ミリ秒未満」のように、しきい値を 2 つ置いています。
どこで測るか
ワークブックは SLI の測り方としてアプリのサーバーのログ、ロードバランサーの監視、外からの死活監視、利用者の端末での計測を挙げています。その例では、すでに手元にあり、利用者の体験により近いという理由で、ロードバランサーのデータを使っています。アプリのログでは、アプリまで届かなかったリクエストを数えられないからです。
小さなチームなら、まずはすでにあるデータで測れるものを選びます。クラウドのロードバランサーのメトリクス、アプリのアクセスログ、そしてデータベースの業務データです。
たとえば「決済が成功したか」は、利用者にとって大事な結果そのものなので、そのまま SLI にできます。決済のテーブルがあれば、直近 4 週間の成功率は次のように数えられます。テーブル名、列名、状態の値は自社のものに置き換えてください。
-- PostgreSQL: 直近 28 日の決済の成功率
SELECT count(*) FILTER (WHERE status = 'succeeded')::numeric
/ nullif(count(*), 0) AS success_ratio,
count(*) AS total
FROM payments
WHERE created_at >= now() - interval '28 days';
-- MySQL: 同じ集計
SELECT SUM(status = 'succeeded') / NULLIF(COUNT(*), 0) AS success_ratio,
COUNT(*) AS total
FROM payments
WHERE created_at >= NOW() - INTERVAL 28 DAY;
カード会社の審査で断られた決済のように、サービスの不具合ではない失敗は、分母から外すか、良いイベントとして数えます。何を「良い」とするかを最初に文章で決めておくのが、SLI を作るときの一番の仕事です。
エラーバジェットの計算
エラーバジェットは「1 − SLO」です。SLO が 99.9% なら、エラーバジェットは 0.1% です。
ワークブックは集計の期間として 4 週間 (28 日) のローリングウィンドウ (毎日、直近 28 日を見る方法) を勧めています。30 日にすると週末が 4 回の期間と 5 回の期間ができてしまうので、週の倍数にするのがよいとしています。
28 日は 40,320 分です。SLO ごとに、28 日のうち止まってよい時間と、100 万リクエストのうち失敗してよい件数を計算すると次のようになります。
| SLO | エラーバジェット | 28 日で止まってよい時間 | 100 万リクエストで失敗してよい件数 |
|---|---|---|---|
| 99% | 1% | 約 6 時間 43 分 | 10,000 件 |
| 99.5% | 0.5% | 約 3 時間 22 分 | 5,000 件 |
| 99.9% | 0.1% | 約 40 分 | 1,000 件 |
| 99.95% | 0.05% | 約 20 分 | 500 件 |
| 99.99% | 0.01% | 約 4 分 | 100 件 |
99.99% のバジェットは 28 日で約 4 分です。人が呼び出されてから PC を開くだけで使い切ってしまいます。小さなチームが 99.99% を掲げても、守る手段がありません。最初は 99.5% や 99.9% あたりから考えるのが現実的です。
エラーバジェットの消費率は「(1 − 実績) ÷ (1 − SLO)」で計算できます。SLO が 99.5% で、直近 28 日の実績が 99.7% なら、(1 − 0.997) ÷ (1 − 0.995) = 0.003 ÷ 0.005 で、バジェットの 60% を使ったことになります。
エラーバジェットの使い方
エラーバジェットは残っていれば使ってよいものです。残っているうちは、新機能のリリースや大きな変更を積極的に進めます。使い切りそうなら、リリースを控えて安定のための作業を優先します。
この判断を、障害のたびに話し合わずに済むよう、事前に文書にしたものを「エラーバジェットポリシー」と呼びます。ワークブックはポリシーにバジェットを使い切ったときにとる行動や、計算について意見が割れたときの判断の経路を書くよう勧めています。使い切ったときの行動の例として、信頼性に関わるバグを優先する、SLO に戻るまで信頼性の作業に集中する、本番への変更を止める、を挙げています。
小さなチームなら、次の程度で十分です。
# エラーバジェットポリシー (注文 API)
- SLO: 注文 API の成功率 99.5% (直近 28 日)
- 確認: 毎週月曜の定例で、消費率を見る
- 消費率 50% 未満: 通常どおりリリースする
- 消費率 50〜100%: リリースは続けるが、障害の原因になった箇所の修正を次のスプリントに入れる
- 消費率 100% 超: 緊急の修正とセキュリティ対応以外のリリースを止め、SLO に戻るまで信頼性の作業を優先する
- 例外の判断: CTO (いなければ代表)
- 見直し: 3 か月ごと
ポリシーで大事なのは、開発を止める権限を持つ人と事前に合意しておくことです。合意がないと、バジェットを使い切ったときに「でも、この機能は来週出さないと」と押し切られて終わります。
トイルとは
トイル (toil) は SRE 本で使われる言葉で、本番のサービスを動かすための作業のうち、次の性質を持つものを指します。
- 手作業である
- 繰り返し発生する
- 自動化できる
- その場しのぎで、割り込みで発生する
- やっても長く残る価値がない
- サービスが大きくなるにつれて比例して増える
例としては、ディスクがいっぱいになるたびに手で古いログを消す、毎月手でアカウントを作る、決まった問い合わせのたびに SQL を手で打ってデータを確かめる、などがあります。会議や計画のような作業は、面倒でもトイルではありません。
Google の SRE は運用の作業 (トイル) を一人ひとりの時間の 50% 未満に抑えることを目標にしています。SRE 本によると、Google の SRE への調査では、トイルに使っている時間は平均で約 33% でした。
トイルの測り方と減らし方
少人数のチームでは、トイルの割合を厳密に測る必要はありません。まず 1〜2 週間、運用の作業をしたら簡単に記録します。
| 日付 | 作業 | かかった時間 | きっかけ |
|---|---|---|---|
| 11/4 | 失敗した CSV 取り込みを手で再実行 | 20 分 | 顧客からの連絡 |
| 11/5 | ディスク使用率のアラートで古いログを削除 | 15 分 | アラート |
| 11/6 | 失敗した CSV 取り込みを手で再実行 | 25 分 | 顧客からの連絡 |
記録がたまったら、「1 回あたりの時間 × 月の回数」が大きいものから自動化を検討します。上の例なら、CSV 取り込みの自動の再実行と、失敗したときの通知が候補です。自動化にかかる時間が、数か月で取り戻せるかも見積もります。
トイルの記録には、もう 1 つの効果があります。「運用が大変」という感覚を数字にできるので、経営者や上司に、改善の作業に時間をとる理由を説明しやすくなります。
監視と障害対応
SRE 本は、監視が出力するものを 3 種類に分けています。すぐに人が対応すべき「アラート」、急がないが人が対応すべき「チケット」、あとで調べるために残す「ログ」です。夜中に人を起こすのはアラートだけにし、朝に見れば済むものはチケットにします。
何を監視するかについて、SRE 本は利用者に面したシステムで 4 つしか測れないなら次の 4 つに絞るよう勧めています。
| シグナル | 意味 |
|---|---|
| レイテンシ | リクエストの処理にかかる時間。成功と失敗を分けて見る |
| トラフィック | システムへの需要の量。Web なら 1 秒あたりのリクエスト数など |
| エラー | 失敗したリクエストの割合。HTTP 200 でも中身が誤っているものを含む |
| サチュレーション | どれだけ「いっぱい」か。最も制約の厳しい資源 (メモリ、ディスク、DB の接続数など) の使用率 |
呼び出しのアラートは原因 (CPU が高い) ではなく、症状 (利用者のリクエストが失敗している) に対してかけるのが基本です。SLO を決めると、「エラーバジェットを速いペースで使っている」ことをアラートの条件にできるので、利用者に影響のない CPU の上昇で夜中に起こされることが減ります。アラートが多すぎる問題は アラート疲れの原因と対策 で扱っています。
障害が起きたときの役割分担と連絡は 障害対応のフロー、障害のあとの振り返りは ポストモーテムとは で説明しています。
少人数のチームはどこから始めるか
SRE を始めるのに、SRE チームを作る必要はありません。ワークブックが示す始め方は、1 つのアプリを選び、少数の SLI を決め、作るのが安い方法で測り、関係者と合意し、ポリシーを書き、繰り返し直す、という流れです。最初から正しくなくてよい、とも書いています。これを 2〜5 人のチームに当てはめると、次の 4 週間の手順になります。
1 週目: 利用者にとって大事な操作を 1 つ選び、SLI を決める
サービスの中で、止まったら一番困る利用者の操作を 1 つ選びます。EC なら注文、SaaS ならログインとデータの保存、予約サービスなら予約の確定です。その操作について、SLI を 1〜2 個決めます。迷ったら「成功の割合」から始めます。
決めたら、「何を良いイベントとし、何を分母から外すか」を文章で書きます。
2 週目: 過去 4 週間を測り、SLO を仮に決める
過去 4 週間の実績を、ロードバランサーのメトリクス、ログ、データベースから数えます。SRE 本は今の実績をそのまま目標にしないよう注意しています。今たまたま 99.98% だったからといってそれを SLO にすると、守るために無理を続けることになるからです。ワークブックは測った値を扱いやすい数字に丸めて最初の SLO にすることを勧めています。
たとえば実績が 99.93% なら、まずは 99.5% や 99.9% を仮の SLO にします。SRE 本も、緩い目標から始めて徐々に厳しくする方が、その逆より楽だとしています。
3 週目: エラーバジェットポリシーを書き、関係者と合意する
上の例のような 1 ページのポリシーを書き、リリースを決める人 (経営者やプロダクトの責任者) と合意します。消費率を週に一度見られるよう、ダッシュボードかスプレッドシートを用意します。最初は SQL の結果を毎週手で貼るだけでも構いません。
4 週目: トイルを記録し始める
運用の作業を記録する表を作り、全員で 2 週間記録します。記録が集まったら、一番時間を食っている作業を 1 つ選んで自動化します。
その後は月に一度、SLO の実績とトイルの記録を見る時間をとります。SLO が厳しすぎて毎月使い切るなら緩め、余裕がありすぎるなら利用者の声と照らして厳しくします。
SRE についてのよくある誤解
SRE チームを作らないと始められない
SLO の設定、エラーバジェットの運用、トイルの記録、ポストモーテムは、どれも既存の開発チームで始められます。必要なのは SRE という役職より、信頼性を数字で決めてその数字で判断する習慣です。
SLO は高いほどよい
SLO を必要以上に高くすると、リリースが遅くなり、守るための費用がかさみます。利用者が不満を感じない水準を目安に決めます。
レイテンシは平均で見ればよい
平均は一部の利用者が受けている遅さを隠します。割合かパーセンタイルで見ます。
SLO を決めたら終わり
サービスも利用者も変わるので、定期的に見直します。SRE 本も、SLO はなるべく少なくし、優先順位の議論で守る価値があるものだけにするよう勧めています。
SLI を測り続けるには
この記事で紹介した成功率の SQL は、cron で毎日実行して結果を表に残せば、エラーバジェットの消費率をいつでも確かめられます。監視ツールに SLI を送り、消費のペースにアラートをかける方法もあります。
決済の成否やジョブの滞留のような業務の数字を見る部分は、AI に任せる方法もあります。Scandock は、データベースの接続文字列を登録すると、AI がテーブルの構成と実データを読み、注文数や決済の成否、バッチ・ジョブの滞留のような事業の中心にある数字を監視項目にします。固定の閾値ではなく値の推移を踏まえて異常を判断し、異常と判断したら読み取り専用のクエリで原因を調べて、Slack やメールなどに通知します。
参考
- Introduction (Site Reliability Engineering, Google)
- Service Level Objectives (Site Reliability Engineering, Google)
- Eliminating Toil (Site Reliability Engineering, Google)
- Monitoring Distributed Systems (Site Reliability Engineering, Google)
- Implementing SLOs (The Site Reliability Workbook, Google)
- Alerting on SLOs (The Site Reliability Workbook, Google)
- PostgreSQL: Aggregate Expressions (FILTER 句)