アカウント ログイン
セクションを選択

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

URL をコピー

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

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

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

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

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

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

SRE は、このようにして現行システムの信頼性を強化するのと同時に、今後拡張するシステムの信頼性の強化も支援します。 

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

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

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

SRE (サイト信頼性エンジニアリング) はサービスレベル契約 (SLA) を使用してどの新機能をいつリリースするかというチームの判断をサポートし、サービスレベル指標 (SLI) とサービスレベル目標 (SLO) を使用してシステムに必要とされる信頼性を定義できるよう支援します。 

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

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

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

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

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

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

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

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

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

自動化は、SRE エンジニアの役割の重要な部分です。SRE エンジニアは、繰り返し対応している問題があると、ソリューションの自動化に取り組みます。これは、運用作業を全体作業の半分に留めるという点でも役立ちます。 

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

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

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

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

SRE のユニークな点としては、開発チーム内の SRE エンジニアには運用業務の経験があるため、コミュニケーションやワークフローの問題を排除できます。

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

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

コードと新機能の面では、DevOps は開発パイプラインを効率的に進めることを重視していますが、SRE はサイト信頼性の確保と新機能の作成とのバランスを取ることに重点を置きます。 

DevOps 手法において、コンテナ・テクノロジー、Kubernetes および マイクロサービスをベースとする最新のアプリケーション・プラットフォームは不可欠です。これらによって、安全で革新的なソフトウェアサービスの提供が可能となります。

日本の通信事業者による DevOps とコンテナの活用事例

SRE は、アプリケーションのライフサイクル全体での日常的な運用タスクの自動化と標準化に不可欠です。Linux® コンテナは、クラウドネイティブの開発に必要な基礎となるテクノロジーを各チームに提供します。コンテナは、開発、提供、統合、および自動化のための統一された環境を支援するツールを提供します。

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

適切なプラットフォームを導入することで、導入する DevOps の文化やプロセスの変化を最大限に活用できます。Red Hat® OpenShift® は、このような SRE 業務をサポートするエンタープライズ対応 Kubernetes プラットフォームです。

関連資料

記事

DevSecOps とは

DevOps によるアジリティと応答性を存分に利用するのであれば、IT セキュリティはアプリケーションのライフサイクル全体を通じて、重要な役目を果たす必要があります。

記事

CI/CD とは

CI/CD によって、統合およびテストのフェーズからデリバリー、デプロイメントに至る、アプリケーションのライフサイクル全体を通じて、継続的な自動化と継続的な監視が導入されます。

記事

DevOps エンジニアとは

DevOps エンジニアは、組織内でのコラボレーション、イノベーション、文化的変革を可能にする特有のスキルと専門知識を持ち合わせています。  

DevOps の詳細はこちら

製品

Red Hat Open Innovation Labs

Red Hat のエキスパートによる徹底的かつ集中的な研修。アジャイルの方法論とオープンソースツールを使用して、社内業務の課題に対処する方法について学びます。

Red Hat Consulting

Red Hat の戦略的アドバイザーが、企業組織の全体像を把握しながら課題を分析し、包括的かつコスト効率に優れたソリューションで課題を解決できるようお手伝いします。

リソース

ホワイトペーパー

Red Hat Ansible Automation Platform を使用して CI/CD パイプラインを最適化する

Illustration - mail

その他の関連コンテンツ

無料のニュースレター「Red Hat Shares」(英語) では、注目の IT トピックスに関するコンテンツをお届けしています。