技術解説
SREとは？ DevOpsとの違い
SREが求められる背景
昨今のソフトウェア開発は、以前にも増してスピードと柔軟性が求められるようになってきています。しかし、従来のウォーターフォール型開発では実現が難しいこともあり、開発手法そのものをアジャイル型へ転換することが急務となっています。経済産業省が企業のDX推進の方向性を示すために作成している「DXレポート」において、再三「アジャイル型の開発などによって、事業環境の変化への即応を追求」といった表現が出てくることからも、DX推進とアジャイル開発は不可分なものになりつつあることが実感できるのではないでしょうか。
しかし、単に「開発スピードを上げてコストを下げる」ことだけを目的にアジャイル開発を導入すると、成果物であるソフトウェア・サービスが利用者にとって使いづらいもの、あるいは価値の低いものになってしまうケースも珍しくありません。
そこで、注目されているのがSite Reliability Engineering（以下SRE）やDevOpsといった方法論です。SREとDevOpsは、いずれも開発スピードだけではなく、ソフトウェア・サービスの品質を向上するための開発手法です。これらを導入することで、「ビジネスの変化に適応可能なスピードを重視する開発部門」と「安全性・安定性を重視する運用部門」の間のギャップの解消が期待できます。
なお、SREとDevOpsは異なる概念ですが、開発部門と運用部門が協調して開発・リリースのスピードを上げるなどの共通点も多く、利用するツールも重なる部分が多数存在しています。本記事では、SREとは何か？その特長や指標をDevOpsとの違いを交えて解説します。
SREとは？
SRE（Site Reliability Engineering）とは、元々Googleが提唱したシステム管理とサービス運用に対するアプローチです。SREの特長は、信頼性をシステムの重要な機能の1つと位置づけている点です。SREでは、サイトやサービスの信頼性を向上させるため、コードによって手作業や繰り返し行われる作業（トイル）を減らしたり、システムを自動化して作業量の増大に対応することを重視しています。
近年では、インフラの主流がソフトウェアによって制御可能なクラウドになってきたことで「Infrastructure as Code」が進んでいます。こうした「インフラをコード化しやすくなってた背景」も自動化を重視するSREが注目されるようになってきた要因の1つと言えるでしょう。
なお、SREは従来の運用とは異なる役割であり、SREを担当するエンジニアには、システムの運用経験とソフトウェア開発のスキルの双方が求められます。
SREに必要な指標
SREにおいて重要なのは、サービスの信頼性を担保するための指標を決め、それを継続してモニタリングすることです。SREでは、信頼性を担保するための指標として下記の項目を使用しています。
SLI
SLIとは、Service Level Indicatorの略で日本語では「サービスレベル指標」と呼ばれるサービスの品質を測る指標です。具体的には、サーバーの稼働率などがSLIに該当します。
SLO
SLOとは、Service Level Objectiveの略で日本語では「サービスレベル目標」と呼ばれるSLIで計測される値の目標値です。仮にサーバーの稼働率をSLIとした場合は、「月間の稼働率99.99%以上」といった値がSLOに該当します。
SLA
SLAとは、Service Level Agreementの略で日本語では「サービスレベル契約」と呼ばれます。これはベンダーと顧客との間で交わされる、提供されるサービスレベルについての合意のことです。
サイト・サービスの信頼性を担保することは、言い換えれば高い可用性を維持することです。システムの可用性の指標としては、多くのケースで「稼働率」が使われています。稼働率の詳細については、 クラウド選択時の重要な指標。サービス品質保証（SLA）とは？をご確認ください。また、SREチームが活動しているサービスでは、SLOやSLAを公開しているケースも多いため、利用にあたって参考にするとよいでしょう。
SREとDevOpsの違い
冒頭で述べたようにSREとDevOpsは、いずれもシステム開発側と運用側が協調してリリースサイクルの高速化と開発・運用の自動化と監視を推奨するという点で共通項も多い方法論です。しかし、厳密に言えばSREとDevOpsは、その目的が異なっています。
DevOpsの主目的は「開発者と運用者が協力し合うことにより、リリースサイクルの短縮化を図る」ことです。対して、SREの主目的は「インフラの整備や自動化ツールの開発などを通じて、サイト・サービスの信頼性を高める（維持する）」ことです。
SREとDevOpsの違いは、SREを提唱したGoogle自身が発信している「class SRE implements DevOps（SREはDevOpsというinterfaceの実装である）」というメッセージが端的に表わしています。平易な表現にすると「DevOpsという概念を実現するための方法がSREである」ということです。
DevOpsの詳細については、「「DevOps」とは？「開発担当者」と「運用担当者」が連携してビジネス価値を高める開発手法」もあわせてご確認ください。
まとめ
冒頭で述べた通り、企業がDXを推進していく際にウォーターフォール開発からアジャイル開発への転換は、非常に重要となっています。当然、この転換の過程ではさまざまな問題が生じることが予想されます。しかし、そうした問題はSREやDevOpsを導入することで解決できるかもしれません。
とはいえ、SREやDevOpsはあくまで手段でしかありません。仮にSREやDevOpsを実施したからといって、それがDXを実現することに直接繋がるわけではありません。いずれにせよ、DXの実現には従来の開発手法やITインフラの運用とは、異なるスキルとマインドが求められるでしょう。組織・開発者・運用者のいずれもがスキル・マインドセットの変革を行い、従来のやり方に固執せず、異なる概念・文化を受け入れる姿勢が重要です。
DevOpsという概念をDXを推進したい経営者に説明し、理解してもらうのには困難を伴うかもしれません。しかし、SREという信頼性を指標とする開発手法であれば、比較的理解を得やすいのではないでしょうか。まずは、「Infrastructure as Code」によるインフラ管理の自動化や監視の自動化といった部分からスタートして、システムの信頼性を高めることを指標に徐々にSREの活動を広げて行くことをお勧めします。そして、CI/CDやバージョン管理ツール（Gitなど）も活用し、迅速かつ頻繁なソフトウェアの更新が可能な「Kubernetes」によるコンテナの活用など、より可用性や拡張性の高いクラウドネイティブな開発環境へと進めることができれば、Googleのメッセージ「class SRE implements DevOps」を実践する段階に到達したと言えるでしょう。
