SREとDevOpsの違いはなにか

nwiizo

2021.8.26

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

本記事ではSREとDevOpsの違いについて見ていきます。

関連記事:「SREとインフラエンジニアの違いについて」

SREとDevOpsの違い

SREとDevOpsの違いや関係性を知るには、Googleが提唱している「class SRE implements DevOps」の考えが最も明解でしょう。

「class SRE implements DevOps」は、「SREはDevOpsというinterfaceの実装である」という意味を表します。「DevOps = 思想」という定義に対し、それを具体化し実装したものがSREであるという考えです。

ここからはより詳しく、DevOpsとSREについて触れていきます。

DevOpsとは

DevOpsとは、開発担当(Dev)と運用担当(Op)が協力し合ってサービスを作り上げていく思想を指します。

開発者はスピード感のある開発で新機能を追加することを重視し、運用者は信頼性・安定性を重視した運用を行うのが、従来までのサービス開発・運用の構図でした。しかしお互いに良いサービスを作りたいというゴールは同じなのにも関わらず、開発者/運用者のように分断された関係では、お互いのチームが目指す方向性にズレが生じてしまうという問題がおこります。

このような問題を解決するために生まれたのが、DevOpsという考えです。以下の5つの方針が、DevOpsをスムーズに実行するために必要な要素とされています。

①組織のサイロの削減:

サイロとは「独立している」状態のことで、開発側・運用側のチーム同士がうまく連携できていない状態を指します。お互いの組織に溝があることで生じる弊害を無くすため、DevOpsでは組織のサイロ化の削減を大きな指針のひとつに掲げています。

②エラーが発生するのを前提とする:

いくら要件定義・詳細設計の段階で細かく設計したとしても、必ずシステムのエラーは発生してしまいます。完璧なシステムはなく、エラーが発生するのを前提としてシステムの開発・運用に取り組むべきであるという考えです。

③段階的に変更する:

システムを開発・運用していくうちに、必ずプログラムの変更は起こります。そのため変更によって起こりうるエラーを考慮して、段階的に変更を加えることを推奨する考えです。段階的な変更をすることにより、新規機能の追加対応、正常状態に戻すロールバッグ作業が迅速に行えるため、システムの安定稼働には欠かせない考えです。

④ツールと自動化を活用する:

開発および運用の効率化という面で、ツールや自動化を活用することは非常に重要であるという考えです。これはサービスが拡大し、継続すればするほど初期での導入効果は大きくなります。また人的なエラーを起こさないための取り組みとしても非常に有効な手段です。

⑤全てを計測する:

システムの運用ログやエラー検知、パフォーマンス含め、全てのデータを計測して数値化していくことが重要です。それにより新規機能の開発やプログラム修正の際に役立つという考えです。

しかしDevOpsは、あくま上記のような概念や思想にとどまり、具体的な実装までは明示されていません。これらの思想に対してより具体的に実装方法を明示したのがSREということになります。

SREとは

SREを日本語で表現すると「サイト信頼性エンジニアリング」となります。つまり信頼性のあるサイトを運用するための体制ないし実装方法を指しています。DevOpsが思想であるのに対し、SREは具体的な実装までも明示されているのが大きな特徴です。

SREは、「システム運用作業の効率化」および「エラーバジェットによる優先順位付け」が基本の考えとなります。それらを具体的に成果として確認するために、以下のような取り決めを行っています。

※あくまで代表的な取り決めの紹介にとどめます。

①トイル(苦労)の制限および自動化:

トイルは日本語で「苦労」の意味を表す言葉で、システム開発・運用上では「手作業による工数の消費」を表します。SREの取り組みとしては最大限、ツールの利用や自動化をすることで効率の向上を重要視しています。

SREの提唱元であるGooleでは、SREがトイルにかける時間は全体作業の50%までという制限をかけており、残りの50%をコーディングスキルを使うプロジェクトの作業にあてるということを定めています。

この取り決めを忠実に守ることにより、バランスとの取れた運用を担保しながら、リスクを伴う開発作業が行えるようになります。

②SLI・SLO・SLAによる目標定量化:

安定したサービスを運用するためには、SLI・SLO・SLAの指標で評価し、目標を定量化する必要があります。これらの数値状況によりサービスが正常な状態かを判断することで、開発・運用ともに共通の問題意識を持つことが可能になります。

以下の項目を使い、エラーバジェットの評価に役立て、サービスの開発・運用をより効率化してます。

SLI(Service Level Indicator):

「サービスレベルの指標」を指します。
サービスの可用性・性能・セキュリティなどの指標を指します。SLIはあくまで指標なので数値化する必要はありません。

SLO(Service Level Objective):

「サービスレベルの目標」を指します。
SLIの計測項目の具体的数値であり、ユーザーが満足するレベルのサービスを維持するために、サービスの可用性・性能・セキュリティなどの目標値を数値化したものを指します。

SLA(Service Level Agreement):

「サービスレベルの保証」を指します。
安定・信頼を担保するためにSLOをもとにお客さまとの取り決めを行います。

関連記事:SREとはなにか [サイト リライアビリティ エンジニアリング]

SREのことなら弊社にお任せください

DevOpsとSREの違いについて紹介してきましたが、やや概念的な面も多く「実際、どのようにSREを導入すれば良いのだろう?」「専任のSREチームなしでSRE原則を適用する方法がない」と思う担当者の方も多いかと思います。

弊社は、金融・医療・動画配信・AI・ゲームなど、特に技術力が求められる領域で豊富な経験を持つSREの専門家が集まったチームです。戦略策定から設計・構築・運用、SaaS提供までSREに必要な要素を統合的に提供可能です。

もし少しでもSREに興味があるという企業様がいらっしゃいましたら、気軽にお問い合わせください。