SRE (サイト信頼性エンジニアリング) とは

SRE (Site Reliability Engineering：サイト信頼性エンジニアリング) は、IT 運用におけるソフトウェア・エンジニアリング・アプローチです。SRE チームはソフトウェアツールを使用してシステムの管理、問題解決、および運用タスクの自動化を行います。

SRE は、運用チームが多くの場合手作業で行ってきたタスクを、ソフトウェアと自動化を活用するエンジニアと運用チームに担当させ、ソフトウェアと自動化によって問題を解決し、本番システムを管理します。 

SRE は、スケーラブルで信頼性の高いソフトウェアシステムを構築する際に効果を発揮します。コードを使用して大規模システムの管理を支援するため、数千台や数万台に及ぶマシンを管理するシステム管理者により多くのスケーラビリティと持続性をもたらします。 

サイト信頼性エンジニアリングのコンセプトは Google エンジニアリングチームから生まれたもので、Ben Treynor Sloss 氏の功績です。 

SRE は、新機能のリリースと、ユーザーに対する機能の信頼性の確保とのバランスを取るのに役立ちます。

その中で、標準化と自動化は、SRE モデルの重要な 2 大要素です。サイト信頼性エンジニアは、運用タスクを向上させて自動化する方法を求めています。

このように、SREは現在、そして将来にわたってシステムの信頼性を向上させるために役立ちます。 

さらに SRE は、IT 運用の従来のアプローチからクラウドネイティブのアプローチへとチームが移行する支援を行います。

サイト信頼性エンジニアは、システム管理者、運用経験があるソフトウェア開発者、またはソフトウェア開発スキルも持つ IT 運用担当者としての経験を必要とする、独特の役割です。 

SRE チームは、コードのデプロイ、設定、監視のほか、プロダクション環境におけるサービスの可用性、遅延対応、変更管理、緊急対応、容量管理を担当します。

SRE チームは、サービスレベル契約 (SLA) を使用して、サービスレベル指標 (SLI) とサービスレベル目標 (SLO) によってシステムに求められる信頼性を定義し、新機能のリリースについて決定します。 

SLI は、提供されるサービスレベルの特定の側面を測定するものです。主要な SLI には、要求のレイテンシー、可用性、エラーレート、システムスループットなどが含まれます。SLO は、SLI に基づいて指定されたサービスレベルのターゲット値または範囲に基づくものです。

必要とされるシステムの信頼性についての SLO は、許容範囲であるとされるダウンタイムに基づいて決定されます。このダウンタイムレベルはエラーバジェット (エラーとサービス停止の最大許容しきい値) と呼ばれています。 

SRE では 100% の信頼性は期待されておらず、失敗も見込まれ、想定されています。

一度設定すれば、開発チームは、新機能をリリースするときにエラーバジェットを「使用」することができます。開発チームは SLO とエラーバジェットを参照し、使用できるエラーバジェットに基づいて製品またはサービスをリリースできるかどうかを判断できます。

サービスがエラーバジェット内で実行されている場合、開発チームは任意のタイミングでリリースできます。しかし、システムのエラーが多すぎる場合やエラーバジェットを上回るダウンタイムが発生する場合は、エラーがエラーバジェット内に収まるまで新機能をリリースすることはできません。   

開発チームについては、自動化された運用テストを実施し、信頼性を実証します。 

サイト信頼性エンジニアは、運用タスクとプロジェクト作業の時間を切り分けています。Google の SRE ベストプラクティスによると、SRE エンジニアは自らの時間の最大 50% しか運用に割り当てることができず、それ以上超過しないようにモニターする必要があります。  

残りの時間は、新機能の作成やシステムのスケーリング、自動化の実装などの開発タスクに割り当てます。

必要以上の運用作業やパフォーマンスの低いサービスについては、サイト信頼性エンジニアがアプリケーションやサービスの操作に時間を掛けすぎないように開発チームに割り当て直すことができます。  

自動化は、サイト信頼性エンジニアの役割の重要な部分です。SRE エンジニアは、繰り返し対応している問題があると、その解決手順の自動化に取り組みます。 

運用と開発作業のバランスを維持することが、SRE の重要な要素になります。 

DevOps とは、高品質かつ迅速なサービス提供によりビジネス価値や対応スピードを向上することを目的とした、企業文化、自動化、およびプラットフォームの設計に対するアプローチです。SRE は DevOps を具体化したものと考えられます。

DevOps と同様、SRE ではチームの文化と関係が重視されます。SRE も DevOps も、開発チームと運用チームの溝をなくしてサービスを迅速に提供する働きをします。 

アプリケーション開発ライフサイクルの短縮、サービス品質と信頼性の向上、開発された各アプリケーションに IT 部門が費やす時間の削減といったメリットは、DevOps と SRE の両方を実践することで達成できます。

しかし、SRE は DevOps と異なり、開発チーム内のサイト信頼性エンジニアには運用業務の経験があるため、コミュニケーションやワークフローの問題を排除できます。

SRE エンジニアの役割自体は、開発チームと運用チームのスキルを組み合わせたもので、それぞれの業務の重複部分を担います。 

SRE は、DevOps チームの開発者が運用タスクに追われ、より専門的な運用スキルを持つ人材を必要としている場合などに支援します。 

新機能のコーディングや構築を行う場合、DevOps は開発パイプラインを効率的に進めることを重視していますが、SRE はサイト信頼性の確保と新機能の作成とのバランスを取ることに重点を置きます。 

DevOps のプラクティスにおいて鍵となるのは、コンテナ・テクノロジー、Kubernetes、マイクロサービスに基づく最新のアプリケーション・プラットフォームです。これにより、セキュリティと革新的なソフトウェアサービスを提供することが可能となります。

プラットフォームエンジニアリングとサイト信頼性エンジニアリングはいずれも、システムの作成と保守に関するものです。2 つの概念の違いは、それぞれの手法の焦点にあります。SRE は IT 運用チームに焦点を当て、ソフトウェアをツールとして使用してシステムの管理、問題解決、および運用タスクの自動化を行えるよう支援します。

プラットフォームエンジニアは開発チームに焦点を当て、システムの管理、問題解決、および開発タスクの自動化のためのプラットフォームの作成を支援します。 

SRE には、アプリケーションのライフサイクル全体での日常的な運用タスクの自動化と標準化が不可欠です。Red Hat® Ansible® Automation Platform は、SRE チームが速度、コラボレーション、成長を促すために自動化を行い、企業の技術、運用、財務の各機能にわたってセキュリティとサポートを提供できるようにする、包括的な統合プラットフォームです。 

Ansible Automation Platform は、具体的には以下のような機能を提供します。 

• インスタンス、ルーティング、ロードバランシング、ファイアウォールなど、クラウドとオンプレミスにおけるインフラストラクチャ・オーケストレーション。 
• クラウドリソースの適正化、中央処理装置 (CPU) やランダムアクセスメモリー (RAM) などのリソースの追加または削除など、インフラストラクチャの最適化。 
• 継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインによるアプリケーションのデプロイメント、オペレーティングシステムのパッチ適用、メンテナンスなどのクラウド運用。
• クラウドからのリソースの移動とコピー、バックアップのポリシー作成と管理、障害の管理などのビジネス継続性。

また、SRE は、クラウドネイティブ開発のスタイルに合わせて設計された基盤に依存しています。Linux® コンテナは、開発、提供、統合、および自動化のための統一された環境を支援するツールを提供します。

また Kubernetes は、Linux コンテナ操作を自動化する先進的な方法です。Kubernetes によって、Linux コンテナをパブリッククラウド、プライベートクラウド、ハイブリッドクラウドで実行するクラスタを、より効率的に管理できます。

Red Hat® OpenShift® は、SRE の取り組みを支援するエンタープライズ対応の Kubernetes プラットフォームであり、IT インフラストラクチャをモダナイズし、組織が顧客により良いサービスを提供し、ビジネス目標を達成できるような文化やプロセスの変革を実施できるようチームを支援します。