SRE、DevOps、インフラエンジニアの違いを徹底解説

WebサイトやWebサービスの信頼性向上に向けた取り組みを行い、価値の向上を進めるアプローチ方法としてSREというものがあります。
システム開発側と運用側の溝を埋めるために生まれたこの手法ですが、従来のDevOpsとはどのような違いがあるのでしょうか。

この記事では、SREとDevOps、インフラエンジニアとの違いについて解説しながら、SREのアプローチ方法などを解説していきます。

SREの定義とは？

SRE（Site Reliability Engineering）は、グーグル社が開発した運用エンジニアリングの手法です。導入によりシステムの信頼性と可用性を高め、ユーザーエクスペリエンスの向上やビジネスの成長につながることが期待されています。

SREの主な目的は、大規模なシステムやアプリケーションの信頼性と可用性を向上させることです。そのため、自動化されたプロセス、監視、トラブルシューティング、システムの改善、およびサイトの耐障害性を構築し、コードによって手作業や繰り返し行われる作業の削減や、作業量の増大にシステムの自動化で対応することを重視しています。

SREが求められる背景

SREが求められる背景には、上流工程から下流工程へと順番に進めていく従来のウォーターフォール型ではなくアジャイル型の開発手法が求められていることが挙げられます。

アジャイル型の開発ではスピードと柔軟性の両立を目指す一方で、「ビジネスの変化に適応可能なスピードを重視する開発部門」と「安全性・安定性を重視する運用部門」におけるギャップが生まれる場合があります。

その溝を埋めるために、プロセスを自動化しながら、ツールなどを活用し、運用を安定させることを目的にSREやDevOpsといった方法論を取り入れられるようになりました。

DevOpsとは？その定義について解説

DevOpsは、開発（Development）と運用（Operations）を統合し、システム開発から運用までの一連の業務プロセスを自動化することで、迅速かつ効率的なソフトウェア開発とデプロイメントを可能にする文化や方法論です。

開発者は新機能の開発スピードを重視し、運用者は信頼性・安定性のある運用を重視するのが、従来までのサービス開発・運用の構図でした。しかし、これでは良いサービスを作るというゴールが同じであっても、お互いのチームが目指す方向性にズレが生じてしまいます。
この分断を解決するためにDevOpsという考え方が生まれました。

SREはDevOpsの実装？

DevOpsは、あくまで概念でしかありません。これらの思想を基盤として、より具体的に実装方法を明示したのがSREです。
どちらも開発チームと運用チームのコラボレーションを重視しているという共通点があります。ここでは、SREがDevOpsの実装としてどのような働きがあるのかを解説します。

自動化の重視

DevOpsと同様に、SREでも自動化が非常に重要な役割を担っています。自動化により、システムの信頼性を高めるために必要なタスクを、より迅速かつ正確に実行することができます。

例えば、SREではシステムの監視やアラートの設定、ログの収集、トレーシング、容量管理などを自動化することが重要とされています。
これにより、人的ミスを減らし、リソースを効率的に活用することができます。また、変更管理やインシデント管理のプロセスをスムーズにすることも可能です。

CI/CDの実践

SREは、DevOpsの理念に基づいた運用方法であるため、CI/CD（Continuous Integration/Continuous Delivery）の実践も非常に重要です。
CI/CDは、開発者がより迅速かつ正確にコードをリリースし、システムの安定性と信頼性を向上させるために使用される方法論です。

SREでは、自動化されたCI/CDプロセスにより、開発者と運用チームの間の壁を取り除くことができます。開発者はコードを自由にリリースでき、SREではそれらのテスト・実行が可能です。
これにより、開発者と運用チームの協力関係が強化され、システムの信頼性が向上することが期待されます。また、CI/CDの実践により、システムへの変更がより迅速かつ頻繁に行われるため、問題が発生した場合もスピード感を落とさず対応できます。

サイトリライアビリティ

サイトリライアビリティは、システムやサービスの信頼性を担保するために、アプリケーション層からインフラストラクチャー層まで、システム全体を俯瞰することを目的としたSREの重要な概念のひとつです。

具体的には、システムの可用性、スケーラビリティ、パフォーマンス、耐障害性などを考慮して、システムを設計・構築・運用することで、サイトリライアビリティの向上を求められます。

SREでは、サイトリライアビリティを確保するために、監視・アラート・自動化・改善などのプロセスを導入し、システムやサービスを常に最適な状態に保つよう取り組みます。

チーム間のコラボレーション

DevOpsの実践において、SREが開発チームと運用チームのコラボレーションを促進することで、開発サイクルが短縮され、リリースのスピードが向上し、より高品質で信頼性の高いシステムを提供できます。

具体的には、SREは開発チームと協力して、システム設計・開発・リリースに関するガイドラインや規約を策定し、品質や信頼性に関する指標を設定します。
また、運用チームとは監視やアラート、トラブルシューティングにおいて協力し、障害や問題が発生した場合には、迅速に対応することが求められます。

監視の重要性

SREは、監視対象のシステムやサービスに関する指標を定め、監視ツールやシステムを設定して、24時間体制で監視を行います。監視対象には、サーバーの稼働状況やトラフィックの状況、アプリケーションのパフォーマンスなどが含まれます。

監視を適切に行うことで、システムのトラブルを早期に発見し、迅速かつ正確な対応につなげることが可能です。また、監視によってシステムのパフォーマンスを可視化すれば、システムやサービスの改善に役立ちます。

監視は、システムやサービスの信頼性を担保するために欠かせないプロセスであり、SREにとっては非常に重要な役割といえるでしょう。
システム監視、サーバー監視については、以下のブログ記事においても少し紹介しておりますので、そちらもご参考になれば幸いです。

▼クラウド監視とは？オンプレミスとの違いやメリット、運用負荷を軽減するポイントを解説
 ▼サーバー監視ツールとは？導入のメリット・デメリットを解説
 ▼システム監視とは？必要性や監視項目をわかりやすく解説

SRE、DevOps、インフラエンジニアの違い

SREはDevOpsを具体化したものでありますが、どの点に違いはあるのでしょうか？インフラエンジニアとの違いについても触れながら解説していきます。

SREとDevOpsの違いとは？

SREを生み出したグーグル社は、DevOpsを思想とするなら、SREはその思想に基づく役割であると捉えています。

簡単にいえば両者の違いは、SREはサービスの信頼性の向上に重点を置いたものであり、DevOpsは開発と運用のプロセスを自動化に重点を置いた文化や方法論であるということです。

インフラエンジニアとの違いとは？

SREとインフラエンジニアは、両方ともITインフラストラクチャーの設計・構築・運用に関わる多くの役割がありますが、そのアプローチや責任の範囲に違いがあります。

SREは、サービスレベル目標（SLO）の策定、監視、メトリクスの収集、問題解決、および自動化による運用プロセスの改善に焦点を当てています。そのためスケーラビリティ、セキュリティ、その他パフォーマンスの問題を特定し、解決するためにエンジニアリングのスキルを活用します。

一方、インフラエンジニアは、ITインフラ全体を設計・構築・運用する責任があります。
そのため、サーバー・ネットワーク・ストレージ・クラウドなどの物理的かつ仮想的なコンポーネントを管理し、アプリケーションのデプロイメントやセキュリティ、パフォーマンス、可用性を保証する責任を負います。

SREは、インフラエンジニアの一部であるといえますが、より専門的な役割であるとわかります。

SREに必要な指標

ここまでSREにおいて重要なのは、サービスの信頼性を担保するための指標を決め、それを継続してモニタリングすることであると説明してきました。その信頼性を担保するための指標として、下記の項目を使用しています。

これらの指標を適切に設定し測定することで、SREチームはシステムの信頼性を向上させるために必要な情報を得ることができます。また、SREチームはこれらの指標を基に、プロアクティブなアプローチを取り、サービスの改善や障害の予防に取り組むことができます。

それぞれを簡単に解説します。

SLI

SLIは、「Service Level Indicator」の略称です。サービスの信頼性を測定するための定量的な指標となります。
例えば、HTTPレスポンスの平均応答時間や、サービスの正常終了率などがSLIになります。サービスの可用性・性能・セキュリティなどの指標を指します。

SLO

SLOは「Service Level Objective」の略称です。サービスの信頼性に対する目標値であり、SLOはSLIに基づいて計測されます。サービスがどの程度信頼性を保持すべきかを示しもので、例えば、「99.99％の正常稼働率を目指す」といったことがSLOに該当します。

SLA

SLAは「Service Level Agreement」の略称です。顧客との契約に基づく、サービスの信頼性に関する取り決めです。SLAは、SLOをベースに、顧客に対して提供するサービスの信頼性に関する約束事を明示します。
例えば、「正常稼働率が99.99％を下回った場合には、顧客に対してクレジットを付与する」といったことがSLAに該当します。

SREのアプローチ方法

ここまでSREの概念やDevOpsとの違いを解説してきました。
最後に、SREの具体的なアプローチの方法について簡単に紹介します。大きくは以下の流れになります。

SREチームを編成する

SREチームを編成する場合で参考にすべきはグーグル社です。
彼らはSREチームの編成を行う際に、チームの50%から60%までは正規のエンジニアとし、残り40%から50%は他のスキルを持つエンジニアを充てています。つまり、エンジニアの垣根を越えて、様々な視点からアプローチができるチームビルディングを心がけることが求められるのだと理解できます。

SREに必要な指標を設定

どんなシステムでも、信頼性は100%であることがベストですが、信頼性という言葉ほどあいまいな表現はありません。そこでSREチームはシステムの信頼性を向上させるために、必要な情報を得るSLI・SLO・SLAをそれぞれ適切に設定します。

自動化や省力化を図る

SREは自らアプリケーションに関与したり、自動化プログラムを書いたりなど、運用する開発システムの増大に比例して、保守運用工数が増えることがないよう、主体的に自動化や省力化を行います。これにより、スピードを持った開発を実現することができます。

運用の改善を行う

SREは、システム運用におけるモニタリングや障害対応マニュアルの作成、セキュリティの確保、システムの変更管理、キャパシティプラニング、プロビジョニング（リソース管理）、ポストモーテム（事後検証）といった運用業務の問題点の発見・抽出を行います。
その上で、それらに対し改善までを詳細かつ広範囲にアプローチを施すのです。