What is the definition, role, and benefits of SRE, and how does it differ from DevOps?

近年、ソフトウェア開発には、スピードと柔軟性が求められています。このような状況において、IT部門にはエンドユーザーに提供するソフトウェアやサービスの品質を確保するための実践的な手法が必要になるため、Googleが提唱したSRE（サイト・リライアビリティ・エンジニアリング）が注目されています。

これまでIT部門では、システムアドミニストレーター（シスアド）が行うことと、アプリケーション開発者が行うことの間に明確な線引きが存在していました。しかし、ソフトウェア開発手法の一つであるDevOpsの採用により、セキュリティや安定性を重視するIT運用と、スピードやビジネスの変化への適応を重視する開発とのギャップが狭まりました。

SREの概念とその役割は、IT部門のシスアドと似ていますが、開発スキルや経験が多少加わります。アプリケーションやサービスがサービルレベル契約（SLA））の基準を満たしているか、自動拡張サービスのオートメーションが構築されているかに加え、SREの担当者は開発部門が主に担当するソフトウェアエンジニアリングを通じた運用上の問題に対処します。

従来の優れたシステム管理者は、システム上に存在するできるだけ多くの運用タスクを自動化するため、共有や修正をするシェルスクリプトのツールキットを常に所持していました。しかし、Kubernetesのような自動化およびオーケストレーションツールを実装するためのフレームワークは、SRE の役割に移行するにつれ、さらに多くの開発作業を必要とするようになりました。

以下、SREの定義を明らかにした上で、その役割について説明していきます。

SREの定義に必要な要素

SREは、従来のシスアドと開発者の役割を兼ね備えているため、SRE担当者がアプリケーション全体をゼロから書き上げることはないでしょう。SRE担当者は、bash シェルスクリプトや Pythonなどの言語を使用してタスクを自動化します。また、アプリケーションスタックに一元管理が可能なオブザーバビリティを組み込んで主要なメトリクスを測定し、環境全体の可観測性の向上に貢献します。

SREの一般的なコンセプトの一部として、定義したサービスレベル目標 (SLO) との整合性を確保するために、サービスレベル指標 (SLIs) を基準にしたレイテンシーなどのメトリックスを使用し、システムの信頼性を測定することが推奨されます。

SLOを定義する際は、レイテンシー、エラー率、全体的なスループットなど、主要なSLIsを指定して、到達可能な目標を設定する必要があります。また、ダウンタイムコストを定義し、アプリケーションのアーキテクチャを決定するのに役立てることができます。

このダウンタイムコストは、SREの重要な概念です。すべてのサービスが100％遅延なく稼働することは期待されていません。もし何かのサービスが利用できない場合は、他の提携サービスの持続が求められます。これは、マイクロサービス・アーキテクチャの重要な要素です。

例えば、検索サービスが利用できない場合、Webサイトやアプリケーションの残りの部分は通常通り機能する必要があります。このダウンタイムやエラーにまつわる予算は、SRE 担当者と開発チームの協同における新機能にも関連しています。

また、ある時間帯にダウンタイムコストのほとんどが消費されてしまったとします。この場合、開発チームは新機能の導入を、安定した環境におけるリスクを回避するため、予算をオーバーする心配がなくなるまで待つかもしれません。

つまり、ITシステムの恒久的なフル稼働を目指すのではなく、一定のサービスレベルを保証する（ダウンタイムを考慮した）SREを採用することで、システム管理者は開発と保守のバランスを取りながら運用することを目指すのです。

SREの役割と任務

SREの担当者は通常、時間の50％以上を運用に費やしません。SREのメソッドにおいて、この数字は、エンジニアの労苦や挫折を避けるためのポイントとなり得ます。残りの50％の時間は、新機能の作成、システムのスケーラビリティの向上、アプリケーションのアラートなどの手動タスクの自動化など、プロジェクト業務に充当されるでしょう。

サービスが停止している場合、それは開発チームが対処すべきです。特定のタスクのオーナーシップを明確にすることで、SRE担当者は、インシデント発生後のレビュー、オンコールローテーションの計画と最適化、他のエンジニアリングチームと共有するためのランブックの知識文書化など、他のタスクを実施することができるようになります。

また、この方法はエンジニアリングチーム内のサイロ化を回避し、より一貫したインシデント対応を促進するのに役立ちます。

SREとDevOpsの比較

SREは純粋に開発のためのものではありませんが、DevOps プロセスで重要な役割を担っており、組織がDevOpsのメリットを得ることをサポートします。SREの役割自体は、DevOpsのプラクティスを実装したものと考えられます。

DevOpsにおけるSREの役割は、DevOpsチームが使用するアプリとサービスが、必要なときにエンドユーザーとアプリケーションから利用できるようにすることです。SREとDevOpsの間には重複する部分が多く、この2つはよく一緒に議論されますが、明確な違いがあります。

DevOpsは、ソフトウェアの開発と実装のためのアジャイル手法とベストプラクティスに基づいた一連の原則と定義されています。その名が示すように、DevOpsはソフトウェアを作る側と、それらのソフトウェアを稼働・維持する側とのギャップを埋めるものです。SREと同様に、DevOpsはチームの文化と人間関係の上に築かれ、チームがより速い開発サイクルとバグ発生の防止を実現するのを支援します。

SRE担当者は、ソフトウェア開発およびインフラストラクチャの管理に関する知識を共有してベストプラクティスに関わる推奨を行い、DevOpsを支援します。コード管理やモニタリングで DevOpsソフトの改善を直接促すこともできます。また、開発チームと運用チーム間のコミュニケーションギャップをさらに縮小し、インフラ全体を改善します。

SREを実践するメリット

ソフトウェアの信頼性を高め、稼働時間を維持することは、多くの企業にとって尽きることのない課題となっています。クラウドプロバイダーは、ハードウェアの信頼性を向上させるのに役立ちますが、流動する様々な障害に耐え、信頼性を維持できるソフトウェアを設計することが不可欠です。

SREの原則を用いることで、ソフトウェア実装の信頼性を向上し、エラーが発生した際の平均修復時間 (MTTR) を短縮し、チーム間のコラボレーションを促進することができます。また、運用上の問題を解決することで、チームはソフトウェアにビジネス価値を生み出すための時間をより多く費やすことができます。

SREの2つの重要な特徴は、標準化と自動化です。この2つは連動しており、もし環境が高度に標準化されていなければ、自動化のコードを構築することは難しいでしょう。環境が標準化されているほど、タスクの自動化が容易になります。これらのタスクを自動化することで、2つの点が大きく改善されます。エンジニアが手作業に費やす時間が減り、ヒューマンエラーの可能性が低減します。SREの実践は、現在および将来のシステムの信頼性を向上させるのに役立つのです。