今注目されているSREとは？
主な役割やDevOpsとの違いなどを解説！

システム管理やサービス運用の領域において、SRE（Site Reliability Engineering：サイト信頼性エンジニアリング）という概念が注目されています。以下ではまず、SREの概要や提唱された理由、その役割について解説します。

SREとは、2004年にGoogleが提唱した、Webサイトの安定運用を支えるために重要なシステム運用のアプローチ方法です。SREにより、アプリケーション開発者と運用者の隔たりを無くし、協調したシステム運用が行えるようになります。

SRE運用の際には、アプリケーションの適切な稼動のために可用性の確保やソフトウェア開発能力の他に以下のような日々の運用管理業務が必要です。

必要な運用管理業務の例

• パフォーマンス管理
• レイテンシの低減
• 作業の効率化
• 変更管理
• モニタリング
• セキュリティ管理
• 障害対応
• キャパシティ管理
• コスト管理

これまでのシステム運用業務は、手順書に沿ったアプリケーションのリリース、サーバーメンテナンス、ハードウェア障害に対する復旧作業などが主でした。これらは手作業による業務が中心であり、同じエンジニアでもアプリケーション開発担当と運用担当ではチームや機能が完全に分離しているケースが多くあります。
このような開発エンジニアと運用エンジニアの作業が分断されていることで、開発側がどんなに利便性が高いアプリケーションをリリースしても、運用側では負担が増大したり、問題が発生したりする可能性が高くなってしまいます。

そこで、Google社は利便性や安定性をシステムの総合的価値ととらえ、それらの向上を実現するSREを提唱しました。
※参照：Googleブログ “Site Reliability Engineering”

SRE自体はGoogleが2004年に提唱しましたが、なぜ近年になって注目されているのでしょうか。以下では、SREが注目される背景について解説します。

SREが昨今注目されている背景として、ソフトウェア開発現場におけるアジャイル型への転換が挙げられます。
近年は、事業環境の変化のスピードがますます速くなっており、DXを推進するうえでもソフトウェア開発におけるスピードと柔軟性は不可欠です。そのため、短いサイクルで「実装→テスト実行」を繰り返し、スピーディーで柔軟性のある開発が可能なアジャイル型が要請されています。

しかし、開発スピードを上げることだけを目的としてしまうと、ソフトウェアが利用者にとって使いづらくなり、安定性も低くなるなど、システムとしての価値が薄れてしまいます。

こうしたことから、システムの利便性や安定性を「価値」ととらえ、その向上を目指すSREに注目が集まっています。

先述したように、SREの大きなミッションはシステムの安定的な運用です。

運用時に発生する問題では、アプリケーションのプログラムミスやリリースの手順間違いなどが挙げられます。またプログラムのコーディングに問題があると、アプリケーションのパフォーマンスが低下することもあるため、問題が複雑な場合、プログラミングの知識に基づき調査する必要があります。

これらの問題を解決するために、SREでは従来の運用業務に加え、コーディングの改善を提案する開発エンジニアに近い仕事を行い、開発チームは運用エンジニア寄りの仕事を行うことが求められます。
そのため、SREを担当するエンジニアには開発と運用、双方のスキルが必要です。

SREの特長は、信頼性をシステムの重要な機能の1つと位置づけている点です。SREでは、サイトやサービスの信頼性を向上させるため、コードによって手作業や繰り返し行われる作業（トイル）の削減やエラーに対する予算（エラーバジェット）の設定が適度であるか費用対効果のバランスを取ることが挙げられます。また、システムを自動化して作業量の増大に対応することを重視しています。

近年では、インフラの主流がソフトウェアによって制御可能なクラウドになってきたことで「Infrastructure as Code」が進んでいます。こうした「インフラをコード化しやすくなってた背景」も自動化を重視するSREが注目されるようになってきた要因の1つと言えるでしょう。

なお、SREは従来の運用とは異なる役割であり、SREを担当するエンジニアには、システムの運用経験とソフトウェア開発のスキルの双方が求められます。

SREと似た考え方としてDevOpsがあります。次章では、そのDevOpsとSREの共通点と違いについて解説します。

DevOps（デブオプス）とは、開発 (Development) と運用 (Operations) を組み合わせたソフトウェアの開発手法の1つです。SREとDevOpsの違いは、役割なのか、マインド（考え方）なのかという点にあります。SREを提唱したGoogleが「class SRE implements DevOps（SREはDevOpsというinterfaceの実装である）」と提唱しているように、DevOpsというマインドを、具体的に役割・機能として実装したのがSREということです。ですが、SREとDevOpsではその目的に違いがあります。

SREは、サイトやサービスの信頼性を維持・向上し、価値を高めることが大きな目的です。この目的を達成するための、インフラ整備や自動化ツール開発といった具体的なアプローチを行う組織体制や機能を指します。

一方、DevOpsはリリースサイクルの短縮化が目的です。アプローチ方法としては、リリースサイクル短縮のために開発者と運用者が協力し合う文化や方針を考えることを指します。

目的には違いがありますが、開発と運用が協力してより良いソフトウェアを作るという点では同じと言えます。

SREを導入することで、スピードと柔軟性が求められる開発部門と、安定性や安全性に重きを置く運用部門の協調が実現し、両者の要求を満たしながらDXを推進できます。

SREを実践しDXを推進していくためには、次章で解説する3つの指標が重要になります。

SREを実践するために知っておくべき前提があります。それは「一切問題の生じない、信頼が100％のシステムは存在しない」と認めることです。
この前提を認めたうえで、どれだけのリスクがあり、どのような回復力が求められるのか、といった点を以下3つの指標で定義することが重要です。

SLI（Service Level Indicator）とは、「サービスレベル指標」と呼ばれるものです。
これはサーバーの稼働率やエラー率など、サービスの動作に関する数字を直接測定したもので、後述のSLOを定量的に計測し、目標値を満たしているかを判断するための指標です。

SLO（Service Level Objective）は、「サービスレベル目標」と呼ばれ、SLIで計測される値の目標値です。サーバー稼働率や性能、セキュリティなどの項目ごとに定められます。

SLA（Service Level Agreement）とは、「サービスレベル契約」と呼ばれるものです。
顧客とベンダーの間で交わされたサービスレベルに関する合意のことであり、SLOを達成できなかった場合の対応が定められます。具体的には達成できなかった場合、返金や減額といった対応が必要です。

企業は、この3つの指標を確認することで、SREサービスの信頼性を可視化でき、システムの安定運用に向けて取り組むことができます。

SRE運用の国内事例を紹介します。

フリマアプリ「メルカリ」の企画・開発・運用を行う株式会社メルカリでは、取り扱うデータの増加に伴い、データベースサーバの分散、頻繁なリリースにより機能追加の頻度を上げたいというニーズが生じていました。

そこで、2015年に社内のインフラチームをSREチームへと変更し、ChatOpsとGoogle カレンダーを連携したデプロイ環境の構築、ログ分析基盤の構築やPUSH配信サーバーなどのミドルウェアの開発と検証、サーバーの冗長化、APIサーバーのパフォーマンス向上といった取り組みを行いました。

具体的な取り組みとしては以下があり、チーム全体で信頼性の向上に取り組んでいます。

• APIサーバー、ミドルウェアの可用性の維持・向上
• APIサーバー、ミドルウェアのパフォーマンスの向上
• ログ収集・分析基盤の構築、運用
• 変更管理
• サーバプロビジョニング・デプロイの整備
• セキュリティの担保
• 開発環境などの整備

出典：「国内におけるSREの事例 (メルカリ)」

出典：開発チームとともに歩むSREチームが成し遂げたいこと

上記事例のように、SREを導入・運用することで、APIサーバーのパフォーマンス向上やログ収集・分析基盤の構築、運用につながります。次章では、SREの初期構築から保守監視運用、その後のシステム拡張や変更作業を定額で運営管理が可能なサービスについてご紹介します。

Sproutlyでは将来の更新と保守・運用にかかる負担やコスト軽減のために、システム基盤をオンプレミスからクラウドへ移行したい方向けに、クラウド移行計画・設計から運用までをトータルサポートする「SREサービス」を提供しています。

リーズナブルな月間定額料金内にて、アプリケーションの安定稼働と最適な状態を維持管理できるすべての運用監視機能を標準でご提供しているため、システム担当者の業務負荷を大幅に削減することが可能です。
また、最適なクラウドサービスを提供するだけでなく、ナレッジの共有によりサポートの属人性を排除し、アプリケーションの拡張に合わせたクラウドサービスの設計・構築もご支援します。

クラウド移行やSRE導入についてはSproutlyにお問い合わせください。