ITシステムの活用は企業や組織の存続にとって必須の施策です。DXの必要性が強く叫ばれている状況下では、ITシステムの内製化を行う企業も少なくありません。さらには、ビジネスモデルの変革とともに、Webサービスを自社で提供する企業も増加してきています。より良いサービスを提供し利用者に満足してもらうためにも、Webサービスの改修、改善と提供のサイクルは短くなってきています。しかし、ITシステムを安定的に稼働させながら機能の追加や改修などの開発を行っていくことの両立は簡単とは言い難く、課題となっているケースも少なくありません。

そこで、ITシステムやWebサービスを提供しながら継続的に開発も行っていく手法として登場したのがSREです。以前よりこの分野ではDevOpsが取り上げられていましたが、より具体的なSREにさらなる期待が高まっています。
本記事では、SREについて、概要や背景から、DevOpsとの違い、信頼性と実施における考え方などを解説します。

SREとは

SREはSite Reliability Engineeringの略で、直訳すれば「Webサイトの信頼性を重要視したエンジニアリング」といった意味合いとなります。Google社によって提唱された、Webサイト、サービスのシステム管理、サービス運用についての方法論です。

SREの実現により、Webサイトを運営しながら短いサイクルでリリースを行うことが可能となります。

SREではWebサイトの開発担当者と運用担当者間の壁をなくし、スムーズに両者が連携することを重要視しています。さらにこの考え方に基づいて、システムやサービスの運用や開発における状況を数値化して把握し、数値を判断基準として用いることが特徴です。

各種の状況を数値化できれば、判断基準が明確化します。これは、Webサイトの運用や開発における信頼性が高い状況であれば改修のリリースを行い、そうでなければ問題の修正に専念するという、サービス全体での方向性を定めることができるメリットに繋がっています。

元々Webサイト、サービスが対象でしたが、近年では対象範囲を広げて各種のITシステムにも取り入れられています。

⇒システム運用作業の効率化を目指す、「NoOps」とは？

SREが広まった背景

SREが必要とされ普及に至った背景には、WebサービスというITの提供形態の一般化が進んだことと、従来型のIT開発および運用の形態は継続的なサービス提供に向けた課題を持っていたことがあります。その詳細について、紹介します。

Webサービス形態の普及

インターネット、スマートフォン、モバイルなどの普及は著しく、これを背景に、クラウドの一種であるSaaSでのサービス提供を行うビジネスモデルが一般化してきました。SaaSではインターネットを介し、サービス提供者側でシステムやデータを受け持ち、ユーザーはブラウザからのアクセスで便利に利用することが可能です。

従来のIT企業以外の企業でも、SaaS型のWebサービスが普及したことにより間口が広がり、参入障壁が下がってきました。Webアプリケーションの利便性の高さは様々な用途での利用が可能で、今後も重要な形態と考えられます。

リリース速度の加速

Webサービスは参入の敷居が低いかわりに、競争も熾烈です。次々と湧き上がる顧客の要望に対応して、サービスのバージョンアップを継続的に提供することが求められます。新たな価値を提供し続けなければ、競合に顧客が奪われてしまうこともあるため、サービス提供者にとって必須の対応となります。

バージョンアップしたサービスを提供するためには、アプリケーションの継続的な開発とリリース作業が必要です。その頻度は従来より速いペースが常態化しています。

開発チームと運用チームの分断

従来、ITシステムにおいては、アプリケーション開発とサービス運用・管理はチームを分けて行われることが一般的でした。業務範囲の分担を行うことで、効率的なリソース配置を行うことを目的としています。

しかし、アプリケーション開発は運用管理のしやすさを考慮することで運用効率を高めることが可能です。また、運用管理チームはユーザーの声を耳にすることも多く、アプリケーション開発へのフィードバックを得ることもできるでしょう。

そして、先に上げたリリース速度の加速により開発とリリース（運用）のサイクルは小さくなってきています。しかし、従来型の運営では、そのたびに開発チームと運用チームの間で意思確認と調整が必要となってしまいます。

より連携速度を速め、品質を向上させる事を目的として、開発と運営の形が見直されるようになったことがSREが普及してきている大きな背景です。

SREとDevOpsの違い

SREとDevOpsは、「開発と運用の連携をスムーズにする」という大きな考え方においては同じです。

違いとしては、DevOpsは概念的でSREはDevOpsの考え方を実現する方法論といえるでしょう。DevOpsでは開発と運用の連携をスムーズにするための方策、体制などは実現者に委ねられ、様々でした。SREでは、運用、管理で発生する事象を数値化し、開発対応可能な量を決めるなど連携方法の具体化を行っています。

Google社はSREとDevOpsについて、「class SRE implements DevOps」という関係性を提唱しています。これはJavaなどのオブジェクト指向プログラミング言語の記述方法に沿っており、大枠をDevOpsが定め、その実装はSREによって行われるという意味合いとなります。

SREの信頼性を定義する3要素

SREの実現時には、信頼性を3つの要素で定義することが多々あります。この3要素について、以下に紹介します。

SLI

SLIは「Service Level Indicator」の略で「サービスレベル指標」です。サービスの品質を示す指標を意味しています。具体的には、サーバーの稼働率などがSLIにあげられます。

SLO

SLOは「Service Level Objective」の略で「サービスレベル目標値」です。SLIで計測される目標値をSLOと呼びます。

SLA

SLAは「Service Level Agreement」の略で「サービスレベル契約」です。提供するサービスのレベルについての合意であり、サービスの提供における契約において定めます。「ここまでのレベルのサービスは提供しますよ」という契約上のラインです。

SREを行う際の心がけ

SREはITシステムやサービスを運用しながら開発も進める有意な手法ですが、その利用の際に重要となる心がけについて紹介します。

品質維持

サービスの提供速度、低コスト化はSREで実現したいポイントです。しかし、提供速度と低コスト化にこだわるあまり、運用やサービス品質の低下が起こることは本末転倒なため注意が必要です。

ユーザーに求められるサービスを提供することが最も重要であり、そのためには品質の高いサービスが必要です。SRE導入の際には高い品質も確保する仕組みにする必要があります。

積極的な計測、ツールの活用、自動化

計測

SREを実現する上で重要視されるポイントの一つが数値の計測です。SLI、SLOを具体的な数値として計測します。運用や管理における状況判断のためには、状況を数値化することが必要です。

ツールの活用

計測値の取りまとめ、リリース作業、バージョン管理などは、ツールを利用して効率化することが可能です。ツールの選定、導入、利用方法の確立までを行います。

自動化

SREの最終的に目指すところでは、自動化可能な範囲は自動化します。基盤レベルでのオーケストレーション、インフラのコード化、リリース作業の自動化などがその対象です。人的作業が必須な部分と自動化可能な部分を整理し、自動化に取り組むことが大切です。

効率的な目的達成

近年、サービス提供者となる企業ではサービスの内製化が進んでいます。確かに自社で開発やリリースを行えればサービス提供のスピードアップが測れます。しかし、体制づくりやコストなどが必要となるため負担も大きいです。内製化することが目的とならないように気を付けなければなりません。

サービス提供において重要視すべきなのは、内製化ではなくSREを実現することです。必要に応じて、SREに取り組むベンダーと手を組むことも有効な選択肢となります。特に上記の計測、ツールや自動化の部分に関してノウハウを持つベンダーも多々あるため、適切なベンダーと協業することで効率的にSRE導入という目的が達成できます。

まとめ

ITシステムの運用や監視では、品質の向上と効率化を図っていくことが必要です。開発と合わせてSREなどの手法を取り込むと効果は高いでしょう。

SREに取り組むには各種の自動化のためのソリューションやツールの導入も有効な手段です。例えば、SMSデータテックの提供する「自動化ソリューション」はSREを実現するための強力な一歩となります。

SREや自動化ソリューションの導入にお悩みであれば、SMSデータテックが有効な実現方法をご提案いたします。

“ ”