対象読者
この記事は、SREを初めて学ぶ方や、SREの導入を検討している方に向けて書かれています。
弊社も同様にSREの導入を予定しており、その過程で必要な知識を整理するためにこの記事を作成しました。
同じような状況にある方々の手助けになれば幸いです。
SREとは
SRE（Site Reliability Engineering、サイト信頼性エンジニアリング）は、Googleが発展させた運用手法であり、その結果、広く知られるようになりました。
Googleでは、開発チームと運用チームの間に次のような対立がありました。
- 開発チーム：迅速なリリースを目指し、新しい機能や改善を迅速に展開したい。
- 運用チーム：システムの安定性を重視し、リスクを最小限に抑えたい。
これらの対立により、迅速なリリースと安定した運用を両立させることが難しいという課題が生まれました。
この課題を解決するために、SREチームが作成されました。
※ 背景を知ると、開発チームと運用チームが分かれていない場合には効果がなさそうに感じるかもしれませんが、SREはこのような環境でも非常に有効です。
DevOpsとの違い
SREは実装、DevOpsは抽象である。
class SRE implements interface DevOps
引用元: How SRE Relates to DevOps
DevOpsとは、開発（Development）と運用（Operations）を連携させる文化や手法です。
一方、SREは、システムの信頼性を確保するための手法です。
DevOpsの理念を基にして、「開発と運用のチームが協力して、ソフトウェアを迅速かつ安全に運用する」ことを実現します。
SREの役割
特定のプロジェクトに依存するのではなく、組織全体で横断的に活動します。
役割には以下のようなものがあります。
- サービスレベル指標（SLI）、サービスレベル目標（SLO）、サービスレベル合意（SLA）の設定と管理
- エラーバジェットの管理
- インシデント対応とポストモーテム
- CI/CD（継続的インテグレーション/継続的デリバリー）の実施
- セキュリティ対策
…etc
重要な概念と手法
サービスレベル指標（SLI）
特定のサービスのパフォーマンスや可用性を測定するための指標です。
これはパフォーマンス指標の定義とその実測値を含みます。
具体例
| 指標 | 説明 | 具体例 |
|---|---|---|
| 応答時間 | ウェブページがリクエストされてから表示されるまでの時間 | 100ミリ秒 |
| エラー率 | リクエストのうち失敗した割合 | 0.5% |
| システムの稼働時間 | サービス提供時間のうち、システムが正常に動作している時間の割合 | 99.95% |
サービスレベル目標（SLO）
SLIを基に設定される目標値です。
これはサービス提供者が達成したいと考える具体的な数値目標です。
具体例
| 指標 | 説明 | 具体例 |
|---|---|---|
| 応答時間 | ウェブページがリクエストされてから表示されるまでの時間 | 150ミリ秒以内（95%） |
| エラー率 | リクエストのうち失敗した割合 | 0.95%未満 |
| システムの稼働時間 | サービス提供時間のうち、システムが正常に動作している時間の割合 | 99.6% |
サービスレベル合意（SLA）
SLOを基に、顧客に対して保証するサービスレベルを設定します。
サービス提供者は顧客に対して一定額の返金やクレジットを提供することが一般的です。
AWSのサービスは、SLAが公開されているので、実際に見てみると良いでしょう。
具体例
| 指標 | 説明 | 具体例 |
|---|---|---|
| 可用性 | システムが正常に稼働している時間割合 | 99%以上の可用性を保証（これを下回る場合、料金の1割を返金） |
エラーバジェット
エラーバジェットはSLOを基に設定される許容されるエラー範囲を指します。
例えば、SLOでエラー率を0.95%未満とする場合、10000回のリクエストに対して95回までのエラーが許容されます。
リクエスト数は変動があるため、月の平均値を取得し、エラーバジェットを予測します。
エラーバジェットは、エラー予算とも言い換えることができます。
- エラー予算が一定の範囲内: 新機能のリリースを優先します。
- エラー予算が枯渇した場合: 新機能のリリースを抑え、システムの安定性を確保することに注力します。
カオスエンジニアリング
カオスエンジニアリングは、本番環境（または検証環境）でシステムの回復力と安定性を向上させるために、意図的に障害を発生させてシステムの弱点を特定する手法です。
本番環境で意図的に障害を発生させるのは、とんでもないことだと感じるかもしれません。
しかし、意図的に起こす障害であれば、事前に影響範囲を予測できるため、意図せず発生する障害よりもリスクが低いことは確かです。
定期的にカオスエンジニアリングを実施することで、システムの脆弱性を発見でき、作業者の対応力も向上します。
もし、本番環境での実施が難しい場合は、検証環境（ステージング環境）で行うことでも十分な効果が得られると思います。
実施時には、AWS FISやGremlinなどのツールを利用し、実施することが一般的なようです。
SREを導入する
準備
導入するには、以下が必要です。
- 開発、運用チームに共有し、SRE導入の理解を得る
- システムの評価を行い、SLIを確立させる
- SLIを基にSLOを設定する
SLOを設定したら、SLIがその目標を達成できるように取り組みます。
継続的な改善
準備が完了したら、改善活動を実施します。
- CI/CDの整備とツールの導入
- インシデント対応フローの確立
- カオスエンジニアリングの導入
これらの取り組みにより、サイト信頼度を徐々に向上させていきます。
SREサイクルの図解
以下の図は、SREサイクルを視覚的に示したものです。
これらのステップを繰り返すことで、システムの信頼性を向上させることができます。
採用情報
e-dashエンジニアチームは現在一緒にはたらく仲間を募集中です！
同じ夢について語り合える仲間と一緒に、環境問題を解決するプロダクトを作りませんか？
Discussion