ログイン / 登録 アカウント

DevOps

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

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

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

SRE は、スケーラブルで信頼性の高いソフトウェアシステムを作成するときに効果を発揮する手法です。コードによって大規模システムの管理を支援するので、数千台や数万台に及ぶマシンを管理するシステム管理者にとってスケーラビリティと持続性が高くなっています。 

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

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

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

このようにして、SRE は現行のシステムの信頼性を向上し、さらには拡大するシステムの信頼性の向上も継続して支援します。 

SRE は、IT 運用への従来のアプローチからクラウドネイティブのアプローチへチームが移行するのをサポートします。

サイト信頼性エンジニアの役割

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

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

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

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

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

SRE では 100% の信頼性は期待されていません。失敗は予測済みで、許容されます。 

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

エラーバジェット内でサービスを実行できる場合、開発チームは任意のタイミングでリリースできます。システムにエラーが多すぎる場合やエラーバジェットで許容できるよりもダウンタイムが長い場合は、エラーバジェット内に収まるまで新機能のリリースは行われません。   

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

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

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

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

自動化は、サイト信頼性エンジニアの役割の重要な部分です。ある問題に繰り返し対処しているのなら、SRE はソリューションを自動化します。これは運用作業を作業負荷の半分に留めるという点でも役立ちます。 

運用と開発作業のバランスを維持するのは、SRE の重要な要素です。 

DevOps とSRE

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

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

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

SRE が異なるのは、開発チーム内のサイト信頼性エンジニアが運用業務のバックグラウンドも持っているので、コミュニケーションやワークフローの問題が除外されることです。

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

SRE は、DevOps チームの開発者が運用タスクに忙殺され、特化した運用スキルを持つ人物の助けを必要とする状況を救済します。 

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

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

 

SRE をサポートするテクノロジー

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

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

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

SRE に必要なツール

Red Hat Ansible Automation

シンプルでエージェントレスの IT 自動化テクノロジーで、現行の作業効率の向上や、さらなる最適化を目的としたアプリケーションの移行を可能にし、組織全体における DevOps プラクティスのための単一言語を提供します。

Red Hat OpenShift

エンタープライズ対応の Kubernetes コンテナプラットフォームで、ハイブリッドクラウドやマルチクラウドのデプロイメントを管理するフルスタックの自動運用機能を備えています。 

DevOps についてさらに詳しく