SREの基本原則
はじめに
ソフトウェアエンジニアリングと「子供を持つこと」の間には共通点があります。誕生の前の労苦も大変ですが、実際には誕生の後の労苦こそがその努力の大部分を占めるからです。 システムのトータルコストの 40-90% は、そのシステムの誕生後に生じるものと推定されています。
信頼性の改善へのきっかけを作る一つの方法は、公式にその仕事を認知してもらうことや、そういった人々が行っていることを促進する、すなわち報酬を与えることです。
開発チーム vs 運用チーム
開発チームと運用チームの間には、しばしば対立が生じます。
| チーム | 目的・動機 |
|---|---|
| 開発チーム | 新しい機能を、好きな時に、邪魔されずにローンチしたい。 |
| 運用チーム | いったん動いたシステムは、安定性のために一切変更したくない。 |
この対立は、二つのチームのバックグラウンド、スキルセット、動機付けが全く異なることから生じます。開発と運用の分断による間接的なコストは、多くの場合、組織にとって直接的なコストよりも大きくなります。
Googleが選択したのは、これまでと違うアプローチです。Googleのサイトリライアビリティエンジニアリング（SRE）チームは、ソフトウェアエンジニアを採用することに注力し、採用したエンジニアにサービスを運用させました。そして、従来であればシステム管理者によって手作業で行われたであろう作業を遂行するシステムを構築させました。
サービス管理へのGoogleのアプローチ
GoogleのSREチームは、手作業でタスクをこなすことにすぐに飽きてしまいます。その結果、それまで手作業で行っていたことを（たとえそれが複雑なものであっても）代替してくれるソフトウェアを書くのに必要なスキルセットを持つエンジニアたちのチームができあがりました。SREたちはまた、アカデミックで知的なバックグラウンドを開発組織と共有することにもなりました。
したがってSREは、以下の特徴を持ちます。
- これまで運用チームが行ってきたことを、ソフトウェアの専門性を持つエンジニアが行う。
- エンジニアが人手による管理を自動化するソフトウェアを設計・実装する能力を持ち、それをいとわない。
エンジニアリングへの注力
SREチームにとって、エンジニアリングに注力することは極めて重要です。
常にエンジニアリングを行っていなければ、運用にまつわる負荷が増大し続け、その負荷についていくためだけでもチームにはさらに多くの人数が必要になります。最終的に、運用に注力する旧来のグループは、サービスのサイズに比例して大きくなってしまいます。
これを避けるためのGoogleのルールは明確です。
サービスの管理タスクを受け持つチームは、コードを書かなければならない。
時間捻出のため、Googleではチケット対応、オンコール、手作業といった「運用」業務の合計を 50%以下 にするよう上限を設けました。Googleが求めるシステムは、単に自動化されたものではなく、自動的に動作するものです。
SREチームの時間の使い方
SREチームは残りの50%を、実際に開発を行うために使わなければなりません。これを行うには、SREチームがどのように時間を使っているかを計測する必要があります。場合によっては、負担の一部を開発チームに差し戻すこともあります。
運用と開発の作業バランスを維持することで、以下のメリットが生まれます。
- クリエイティブで自律的なエンジニアリングに携わる余裕をSREに確保できる。
- サービスを動作させる運用面から収集された知見を維持できる。
SREチームは素早いイノベーションと変更を広く受け入れるという特徴を持つことになります。同じサービスを運用指向のチームでサポートすれば極めて多くの人員が必要になりますが、SREのアプローチでは、システムの稼働、メンテナンス、改善に必要となる人数は、システムのサイズに対して比例しません。
SREの信条
1. エンジニアリングの継続的な注力の保証
- 運用に費やす時間は全体の 50%を上限 とします。
- 残りの時間はコーディングスキルを使うプロジェクトの作業にあてます。
- 上限を超過した運用業務は、プロダクト開発チームへ差し戻します。
2. サービスのSLOを下回ることなく、変更の速度の最大化を追求する
プロダクト開発チームとSREチームの間の構造的な対立（イノベーションの速度 vs プロダクトの安定性）を解消するために、エラーバジェット（Error Budget） を導入しました。
エラーバジェットは、「信頼性の目標を100%とすることは、基本的にいかなる場合にも間違っている」という所見に基づいています。
- 可用性100%と99.99%の間のわずかな違いは、ユーザー環境（Wi-Fiや端末）の不安定さに紛れてしまいます。
- 最後の0.01%を高めるための莫大な労力は、ユーザーにメリットをもたらしません。
したがって、正しい目標設定のために以下の問いを立てます。
- ユーザーが満足する可用性のレベルはどの程度か？
- プロダクトの可用性に満足できなかったユーザーにとって、どのような代替策があるか？
- 可用性のレベルを変更したとして、ユーザーの利用方法に何が起こるか？
エラーバジェットの活用:
エラーバジェットは 1 - 可用性ターゲット です。この予算は超過しない限り、何に使っても構いません。理想的には、開発チームはこの予算を新しい機能のローンチやリスクのある変更のために使います。これにより、SREの目標は「障害ゼロ」ではなくなり、開発と運用の利害が一致します。
3. モニタリング
人間がメールを読み、対応の必要性を判断しなければならないシステムは、根本的に欠陥があります。モニタリングにおいては、アラートの領域で人間の解釈が必要であってはなりません。ソフトウェアが解釈を行い、人間はアクションが必要な時のみ通知を受けるべきです。
| 種類 | 説明 |
|---|---|
| アラート | 人間が即座にアクションを行う必要があるもの。 |
| チケット | 人間の対応が必要だが、即座である必要はないもの。 |
| ロギング | 何かが起きない限り見る必要はない記録。 |
4. 緊急対応
人間が関わればレイテンシ（遅延）が生じます。人間の介入を必要とする緊急事態を避けることができるシステムは、高い可用性を持ちます。
人間が関わらなければならない場合のベストプラクティスは、手順書（Playbook） を事前に作成しておくことです。これにより、MTTR（平均修復時間）におよそ3倍の改善が見られました。
- 手順書の重要性: どんなに優秀なエンジニアでも、手順書がある方が早く問題を解決できます。
- 訓練: Google SREは「不運の輪（Wheel of Misfortune）」のような障害対応訓練を行い、エンジニアがオンコール中の出来事に対処できるよう準備します。
5. 変更管理
およそ70%のサービス障害は、動作中のシステムの変更によって生じています。ベストプラクティスは、自動化によって以下を実現することです。
- 漸進的なロールアウト: 段階的に適用範囲を広げる。
- 高速かつ正確な問題検出: 問題を素早く検知する。
- 安全なロールバック: 問題発生時に即座に切り戻す。
これらにより、疲労、慣れ、不注意といった人間特有の問題を回避します。
6. 需要予測とキャパシティプランニング
予想される未来の需要に対して、十分なキャパシティと冗長性を保証します。
- 自然な成長: 顧客増による自然な増加。
- 突発的な成長: 機能ローンチやマーケティングキャンペーンによる急増。
必要なステップ:
- 自然な需要の正確な予測（リソース確保のリードタイムも考慮）。
- 突発的な需要の発生源を予測に織り込む。
- 定期的な負荷テストを行い、リソースとサービスキャパシティの関連を把握する。
キャパシティは直接コストに影響します。SREチームは「可用性維持のための必要最低限のコスト」を定量的に示すことで、コスト最適化に貢献します。
7. プロビジョニング
プロビジョニングは、変更管理とキャパシティプランニングを組み合わせたものです。
現代のクラウド環境では、物理的なデータセンターの拡張よりも、クラウドリソースの適切な割り当てやスケーリング設定がこれに該当します。
8. 効率とパフォーマンス
SREはプロビジョニングをコントロールするため、システムの利用率に関係する仕事にも関わります。サービスのプロビジョニング方針や利用率に注意を払うことで、サービスのトータルコストに強い影響を及ぼすことができます。
SREとプロダクト開発者は、モニタリングと改修を通じてサービスのパフォーマンスを改善し、効率を高める努力を続ける必要があります。