SREとは？改めて原義を振り返ってみたい
概要
SRE（Site Reliability Engineering、サイト信頼性エンジニアリング）は、Googleが提唱したシステム運用の手法です。ソフトウェアエンジニアリングの原則を適用して、信頼性の高い大規模システムを構築・運用することを目的としています。
本記事では、SREの原義を確認し、初学者がSREの背景、目的を理解し、実践するために自社ではどのように進めていけば良いかを順序立てて確認していきます。
背景・課題
現代のシステム運用では、以下のような課題に直面しています。
- システムの規模と複雑さの増大により、手動運用では対応が困難
- 開発チームと運用チームの間で目標や価値観が異なり、対立が生じやすい
- システムの可用性を100%に近づけようとすると、コストが指数関数的に増加
- 繰り返し発生する手作業（Toil）により、エンジニアが価値の高い作業に集中できない
- インシデント対応が属人化し、迅速な復旧が困難
これらの課題を解決するために、Googleは2003年にSREという新しいアプローチを導入しました。
前提条件
- システム運用の基本的な理解
- ソフトウェア開発の基礎知識
- クラウドコンピューティングの概念（推奨）
SREとは
原義の確認
SREは「Site Reliability Engineering」の略で、直訳すると「サイト信頼性エンジニアリング」となります。GoogleのSRE創設者であるBenjamin Treynor Slossは、SREを以下のように定義しています。
SREは、ソフトウェアエンジニアに運用チームを設計するよう依頼したときに起こることである
つまり、SREは従来のシステム管理者（Sysadmin）による運用ではなく、ソフトウェアエンジニアリングの手法を運用に適用するアプローチです。
SREの本質
SREの本質は以下の3つの要素に集約されます。
-
ソフトウェアエンジニアリングの原則を運用に適用
- 手作業を自動化し、コードで管理する
- 繰り返し可能なプロセスを構築する
-
信頼性と開発速度のバランスを取る
- 100%の可用性を目指すのではなく、ビジネス目標に応じた適切な信頼性を設定
- エラーバジェットの概念により、開発と運用の対立を解消
-
エンジニアが価値の高い作業に集中できる環境を作る
- Toil（繰り返し作業）を排除
- 自動化とモニタリングにより、人間の介入を最小化
SREの背景と目的
従来の運用アプローチ（Sysadminモデル）の問題点
従来のシステム運用では、システム管理者（Sysadmin）が以下のような方法でシステムを運用していました。
特徴
- 既存のソフトウェアコンポーネントを組み合わせてサービスを構築
- イベントや更新が発生した際に手動で対応
- システムの規模が大きくなるにつれて、チームサイズも線形的に増加
問題点
-
直接コスト
- 手動介入に依存するため、システム規模に比例してチームサイズが増加
- 運用コストが線形的に増加
-
間接コスト（より深刻）
- 開発チームと運用チームの間で、背景、スキルセット、インセンティブが異なる
- 異なる専門用語、リスクに対する異なる前提、目標レベルの不一致
- 最終的に、コミュニケーション、目標、信頼と尊重の分裂が発生
-
開発と運用の対立
- 開発チーム：新機能を迅速にリリースしたい
- 運用チーム：システムが壊れないようにしたい
- ほとんどの障害は何らかの変更によって引き起こされるため、両者の目標は根本的に矛盾
GoogleのSREアプローチ
Googleは、この問題を解決するためにSREという新しいアプローチを導入しました。
SREチームの構成
- 50-60%: Google Software Engineer（標準的なソフトウェアエンジニア採用プロセスで採用）
-
40-50%: ソフトウェアエンジニアの資格に近い（85-99%）が、追加の技術スキルを持つ
- UNIXシステム内部の専門知識
- ネットワーク（レイヤ1からレイヤ3）の専門知識
SREの特徴
- すべてのSREは、複雑な問題を解決するためのソフトウェアシステムを開発する能力と適性を持つ
- 手作業でタスクを実行することにすぐに退屈し、以前の手作業を置き換えるソフトウェアを書くスキルセットを持つ
- 開発組織と学術的・知的背景を共有
SREの目的
- 従来の運用チームが行ってきた作業を、ソフトウェアの専門知識を持つエンジニアが行う
- これらのエンジニアが本質的に、人間の労働を置き換える自動化とソフトウェアを設計・実装する傾向と能力を持っていることを前提とする
SREの主要な原則
SREは、以下の主要な原則に基づいて実践されます。
1. リスクの受容（Embracing Risk）
完全な可用性は間違った目標
100%の可用性を目指すことは、技術的にも経済的にも非現実的です。可用性を99.9%から99.99%に上げることは可能ですが、99.99%から99.999%に上げることは非常に困難で、コストが指数関数的に増加します。
エラーバジェットの概念
適切な信頼性目標は、技術的な問題ではなく、製品の問題として決定すべきです。
考慮すべき要素：
- ユーザーが製品の使用方法を考慮して、どのレベルの可用性で満足するか
- 製品の可用性に不満を持つユーザーが利用できる代替手段は何か
- 異なる可用性レベルで、ユーザーの製品使用にどのような影響があるか
エラーバジェットの活用
- エラーバジェット = 1 - 可用性目標
- 例：99.99%の可用性目標 → 0.01%のエラーバジェット
- エラーバジェットは、リリースのリスクを取るために使用できる
- エラーバジェットを解放する（フェーズドロールアウト、1%実験など）ことで、より迅速なリリースが可能
開発とSREの対立の解消
- SREの目標は「ゼロ障害」ではなく、エラーバジェットを最大限の機能速度を得るために使用すること
- 障害は「悪いこと」ではなく、イノベーションプロセスの予想される部分
- 開発とSREの両チームが管理するもの
2. サービスレベル目標（SLO）の設定
SLOとは
SLO（Service Level Objective）は、サービスの可用性やパフォーマンスに関する具体的な目標です。
SLOの重要性
- ビジネス目標に基づいて設定される
- エラーバジェットの計算の基礎となる
- 開発と運用の間の共通の目標を提供
SLO設定の考慮事項
- ユーザーの期待値
- 競合サービスの可用性
- ビジネスへの影響
3. Toilの排除（Eliminating Toil）
Toilとは
Toilは、以下の特徴を持つ作業です：
- 手動で行われる
- 繰り返し発生する
- 自動化可能
- 長期的な価値を生み出さない
- サービスの成長に比例して線形的に増加
Toilの例
- 手動でのサーバー設定
- 手動でのログ確認
- 手動でのキャパシティプロビジョニング
- 手動でのインシデント対応
Toilの排除方法
- 自動化ツールの開発
- スクリプトの作成
- 設定管理ツールの活用
- 継続的な改善
Toil排除の効果
- エンジニアが価値の高い作業に集中できる
- エラーの削減
- 一貫性の向上
- スケーラビリティの向上
4. モニタリング（Monitoring）
モニタリングの原則
モニタリングは、サービス所有者がシステムの健全性と可用性を追跡する主要な手段です。
効果的なモニタリングの要件
- 人間がアラートドメインの一部を解釈する必要がない
- ソフトウェアが解釈を行い、人間は行動が必要な場合にのみ通知される
3種類の有効なモニタリング出力
-
アラート（Alerts）
- 人間が即座に行動を取る必要がある
- 何かが発生している、または発生しようとしている
- 状況を改善するために行動が必要
-
チケット（Tickets）
- 人間が行動を取る必要があるが、即座ではない
- システムが自動的に状況を処理できない
- 人間が数日以内に行動すれば、損害は発生しない
-
ログ（Logging）
- 誰もこの情報を見る必要はない
- 診断または法医学的目的のために記録される
- 何か他のものが誰かにログを見るよう促すまで、誰もログを読まないことが期待される
5. 緊急対応（Emergency Response）
信頼性の公式
信頼性 = f(MTTF, MTTR)
- MTTF（Mean Time To Failure）：平均故障時間
- MTTR（Mean Time To Repair）：平均修復時間
緊急対応の効果性
最も関連性の高い指標は、応答チームがシステムを健全な状態に戻すのにどれだけ迅速か、つまりMTTRです。
人間の介入を最小化
- 人間はレイテンシを追加する
- 実際の障害が多くても、人間の介入を必要としない緊急事態を回避できるシステムの方が、手動介入を必要とするシステムよりも可用性が高い
プレイブックの重要性
- 事前に考え抜き、記録されたベストプラクティスを含む「プレイブック」は、「その場で対応する」戦略と比較して、MTTRを約3倍改善
- オールラウンドなヒーローエンジニアも機能するが、プレイブックを装備した実践的なオンコールエンジニアの方がはるかに効果的
6. 変更管理（Change Management）
障害の原因
SREは、障害の約70%がライブシステムへの変更によって引き起こされることを発見しました。
ベストプラクティス
自動化を使用して以下を実現：
-
プログレッシブロールアウトの実装
- 段階的に変更を展開
- 問題を早期に検出
-
迅速かつ正確な問題検出
- 自動化されたモニタリング
- 異常の早期検出
-
問題発生時の安全なロールバック
- 自動ロールバック機能
- 迅速な復旧
効果
- 悪い変更にさらされるユーザーと運用の総数を最小化
- 人間をループから外すことで、疲労、慣れ/軽蔑、高度に反復的なタスクへの不注意という通常の問題を回避
- リリース速度と安全性の両方が向上
7. 需要予測とキャパシティプランニング（Demand Forecasting and Capacity Planning）
目的
必要な可用性で予測される将来の需要にサービスを提供するのに十分なキャパシティと冗長性を確保すること。
考慮事項
- 有機的成長：自然な製品の採用と顧客による使用から生じる成長
- 無機的成長：機能リリース、マーケティングキャンペーン、その他のビジネス主導の変更から生じる成長
必須ステップ
- キャパシティを取得するのに必要なリードタイムを超える正確な有機的需要予測
- 需要予測への無機的需要源の正確な組み込み
- 生のキャパシティ（サーバー、ディスクなど）をサービスキャパシティに相関させる定期的な負荷テスト
SREの責任
- キャパシティが可用性にとって重要であるため、SREチームがキャパシティプランニングを担当する必要がある
- したがって、SREはプロビジョニングも担当する必要がある
8. プロビジョニング（Provisioning）
プロビジョニングの特徴
プロビジョニングは、変更管理とキャパシティプランニングの両方を組み合わせたものです。
要件
- 迅速性：必要に応じて迅速に実行
- 正確性：正しく実行されないと、必要なときにキャパシティが機能しない
- 慎重さ：新しいインスタンスやロケーションのスピンアップ、既存システムへの重要な変更（設定ファイル、ロードバランサー、ネットワーキング）、新しいキャパシティが正しく機能し、正しい結果を提供することを検証する必要がある
リスク
- ロードシフト（1時間に複数回実行されることが多い）よりもリスクが高い
- 対応する程度の追加の注意が必要
9. 効率とパフォーマンス（Efficiency and Performance）
効率の重要性
サービスがお金を気にする場合、リソースの効率的な使用が重要です。
SREの役割
- SREは最終的にプロビジョニングを制御するため、利用に関連する作業にも関与する必要がある
- 利用は、特定のサービスの動作方法とプロビジョニング方法の関数である
- プロビジョニング戦略に注意を払い、したがってその利用に注意を払うことは、サービスの総コストに対する非常に大きなレバーを提供する
リソース使用の要素
リソース使用 = f(需要、キャパシティ、ソフトウェア効率)
- SREは需要を予測し、キャパシティをプロビジョニングし、ソフトウェアを変更できる
- これら3つの要因は、サービスの効率の大部分（全体ではない）を構成する
パフォーマンスの重要性
- ソフトウェアシステムは、負荷が追加されると遅くなる
- サービスの遅延は、キャパシティの損失に相当する
- ある時点で、遅延するシステムはサービスを停止し、これは無限の遅延に対応する
- SREは、特定の応答速度でキャパシティターゲットを満たすようにプロビジョニングする
- したがって、SREはサービスのパフォーマンスに強い関心を持っている
- SREと製品開発者は、パフォーマンスを改善するためにサービスを監視および変更し、キャパシティを追加し、効率を向上させる（そしてそうすべきである）
従来の運用との違い
従来のSysadminモデル
特徴
- 開発と運用が分離
- 手動プロセスが多い
- 目標が対立しやすい
- スケーラビリティが低い
SREモデル
特徴
- 開発と運用が協力
- 自動化が中心
- 共通の目標（エラーバジェット）
- スケーラビリティが高い
SREとDevOpsの関係
SREとDevOpsは、どちらも開発と運用の間の壁を取り払い、協力的な文化を築くことを目的としていますが、アプローチに違いがあります。
DevOps
特徴
- 文化とプラクティスの集合体
- 開発と運用の連携を強化
- 継続的なデリバリーと統合を重視
- 幅広い実践方法を含む
SRE
特徴
- DevOpsの原則を具体的な実践方法として具現化
- ソフトウェアエンジニアリングの手法を運用に適用
- 信頼性の向上に焦点
- 測定可能な指標（SLO、SLI、エラーバジェット）を使用
関係性
DevOps（文化・哲学）
↓
SRE（具体的な実践方法）
SREは、DevOpsの原則を実現するための具体的な方法論の一つと考えることができます。
自社でSREを導入する方法
SREの導入は一朝一夕には進みませんが、以下のステップを順序立てて実施することで、組織全体の信頼性と効率性を向上させることができます。
ステップ1: 現状の評価と課題の明確化
実施内容
- 現在の運用プロセスを文書化
- 課題を特定（Toil、手動プロセス、インシデント対応時間など）
- 開発と運用の間の対立点を明確化
- 現在の可用性とパフォーマンス指標を測定
成果物
- 現状評価レポート
- 課題リスト
- ベースライン指標
ステップ2: SREの原則と文化の理解
実施内容
- チーム全体でSREの原則を学習
- SREの書籍やドキュメントを読む
- 外部のSREコミュニティに参加
- 社内でSREの勉強会を開催
推奨リソース
ステップ3: SLO/SLIの設定
実施内容
- ビジネス目標に基づいてSLOを設定
- SLI（Service Level Indicator）を定義
- エラーバジェットを計算
- ステークホルダーと合意形成
SLO設定の例
サービス: Webアプリケーション
SLO: 99.9%の可用性（月間）
SLI: HTTPリクエストの成功率
エラーバジェット: 0.1%（月間約43分）
注意点
- SLOは技術的な目標ではなく、ビジネス目標に基づく
- ユーザーの期待値を考慮
- 達成可能で測定可能な目標を設定
ステップ4: Toilの特定と排除
実施内容
- Toilを特定（手動プロセス、繰り返し作業）
- 優先順位を付ける（影響度と頻度）
- 自動化ツールを開発
- 段階的にToilを排除
Toil排除の例
| Toil | 自動化方法 |
|---|---|
| 手動デプロイ | CI/CDパイプライン |
| 手動ログ確認 | ログ集約ツールとアラート |
| 手動キャパシティ追加 | 自動スケーリング |
| 手動バックアップ | 自動バックアップスクリプト |
ステップ5: モニタリングとアラートの整備
実施内容
- モニタリングツールの導入
- SLIを測定するためのメトリクスを設定
- アラートルールの定義（3種類の出力を明確に）
- ダッシュボードの作成
モニタリングの3原則
- アラート: 即座に行動が必要
- チケット: 数日以内に行動が必要
- ログ: 診断目的で記録
推奨ツール
- Prometheus + Grafana
- Datadog
- New Relic
- CloudWatch（AWS）
- Cloud Monitoring（GCP）
ステップ6: 自動化の推進
実施内容
- デプロイメントの自動化
- プログレッシブロールアウトの実装
- 自動ロールバック機能の実装
- インフラストラクチャのコード化（IaC）
自動化の優先順位
- 頻繁に実行されるタスク
- エラーが発生しやすいタスク
- 時間がかかるタスク
- 人的リソースを消費するタスク
推奨ツール
- Terraform（IaC）
- Ansible（設定管理）
- Kubernetes（コンテナオーケストレーション）
- CI/CDツール（GitHub Actions、GitLab CI、Jenkins）
ステップ7: インシデント管理プロセスの確立
実施内容
- インシデント対応プロセスの定義
- オンコール体制の構築
- プレイブックの作成
- ポストモーテム文化の確立
インシデント対応のベストプラクティス
- 明確な役割分担
- エスカレーションパス
- コミュニケーションチャネル
- インシデント後の振り返り
プレイブックの重要性
- よくある問題に対する手順を文書化
- MTTRを約3倍改善
- 新人でも対応可能
ステップ8: キャパシティプランニングとプロビジョニング
実施内容
- 需要予測の実施
- キャパシティ計画の作成
- 自動スケーリングの設定
- 負荷テストの実施
考慮事項
- 有機的成長（自然な成長）
- 無機的成長（機能リリース、マーケティングキャンペーン）
- リードタイムを考慮した計画
ステップ9: 継続的な改善
実施内容
- 定期的なレビュー（SLO達成状況、Toil削減状況）
- ポストモーテムからの学習
- プロセスの改善
- ツールの改善
改善サイクル
ステップ10: 組織文化の醸成
実施内容
- 開発と運用の協力関係を構築
- 学習と改善を重視する文化
- 失敗から学ぶ文化（Blameless Postmortem）
- 知識共有の促進
文化の特徴
- 透明性
- 協力
- 継続的な学習
- 失敗を責めない
導入の段階的アプローチ
SREの導入は、以下の3つのフェーズに分けて進めることを推奨します。
フェーズ1: 基盤構築（3-6ヶ月）
目標: SREの基礎を理解し、小さな改善から始める
実施内容
- SREの原則を学習
- 現状評価と課題の明確化
- 簡単なToilの自動化
- 基本的なモニタリングの導入
成果物
- SLO/SLIの設定（1-2サービス）
- 基本的な自動化ツール
- モニタリングダッシュボード
フェーズ2: 拡張（6-12ヶ月）
目標: SREの実践を複数のサービスに拡張
実施内容
- より多くのサービスにSLOを設定
- 高度な自動化の実装
- インシデント管理プロセスの確立
- キャパシティプランニングの開始
成果物
- 複数サービスのSLO
- 自動デプロイメントパイプライン
- インシデント対応プレイブック
- キャパシティ計画
フェーズ3: 成熟（12ヶ月以降）
目標: SREの文化と実践を組織全体に浸透
実施内容
- すべてのサービスにSLOを設定
- 高度な自動化と最適化
- 継続的な改善プロセス
- 組織文化の確立
成果物
- 組織全体のSRE実践
- 成熟した自動化インフラ
- 確立されたインシデント管理プロセス
- SRE文化の定着
よくある質問
Q1: SREチームは必要ですか？
A: 必ずしも専任のSREチームが必要なわけではありません。小規模な組織では、開発チームがSREの原則を実践することも可能です。重要なのは、SREの原則と実践を組織に導入することです。
Q2: SREとDevOpsはどちらを選ぶべきですか？
A: どちらかを選ぶ必要はありません。SREはDevOpsの原則を具体的な実践方法として具現化したものです。DevOpsの文化を築きながら、SREの実践を導入することが推奨されます。
Q3: SLOはどのように設定すべきですか？
A: SLOはビジネス目標に基づいて設定すべきです。ユーザーの期待値、競合サービスの可用性、ビジネスへの影響を考慮して決定します。最初は緩めに設定し、経験を積みながら調整していくことが推奨されます。
Q4: Toilをすべて排除する必要がありますか？
A: すべてのToilを排除する必要はありません。Toilの排除には時間とリソースがかかるため、優先順位を付けて段階的に排除していくことが現実的です。影響度と頻度が高いToilから優先的に取り組みます。
Q5: 小規模な組織でもSREを導入できますか？
A: はい、可能です。SREは組織の規模に関係なく適用できる原則と実践の集合です。小規模な組織では、専任のSREチームではなく、開発チームがSREの原則を実践することが一般的です。
まとめ
SRE（Site Reliability Engineering）は、Googleが提唱したシステム運用の手法で、ソフトウェアエンジニアリングの原則を運用に適用することで、信頼性の高い大規模システムを構築・運用することを目的としています。
SREの本質
- ソフトウェアエンジニアリングの原則を運用に適用
- 信頼性と開発速度のバランスを取る（エラーバジェット）
- エンジニアが価値の高い作業に集中できる環境を作る（Toilの排除）
主要な原則
- リスクの受容（100%の可用性は間違った目標）
- SLO/SLIの設定
- Toilの排除
- 効果的なモニタリング
- 緊急対応の最適化
- 変更管理の自動化
- キャパシティプランニング
- 効率とパフォーマンスの向上
自社での導入方法
- 現状の評価と課題の明確化
- SREの原則と文化の理解
- SLO/SLIの設定
- Toilの特定と排除
- モニタリングとアラートの整備
- 自動化の推進
- インシデント管理プロセスの確立
- キャパシティプランニングとプロビジョニング
- 継続的な改善
- 組織文化の醸成
SREの導入は段階的に進めることが重要です。まずは小さな改善から始め、経験を積みながら組織全体に拡張していくことで、システムの信頼性と運用効率を向上させることができます。
参考資料
公式ドキュメント
- Google SRE Book - Introduction
- Google SRE Book - Production Environment
- Google SRE Book - Conclusion
- SRE Workbook - How SRE Relates to DevOps
書籍
- Site Reliability Engineering: How Google Runs Production Systems
- The Site Reliability Workbook: Practical Ways to Implement SRE
Discussion