HOMEkeyboard_arrow_rightブログkeyboard_arrow_right

SREとは?注目の背景やDevOpsとの違いもわかりやすく解説 

srest - スレスト -

2024.4.1

SREとは?注目の背景やDevOpsとの違いもわかりやすく解説 

企業においてシステム運用の効率化や障害の削減が重要視されています。

その中でも特に、「SRE(Site Reliability Engineering)」という言葉が注目を浴びていますが、具体的に何を指すのかを理解している人は多くないかもしれません。

そこで、本記事はSREの概要についてわかりやすく説明し、システム運用を効率化するための一助になればと考えています。

1、SREとは

2003年頃にGoogle が提唱したSREとは、システムの安定稼働と新機能の追加や改善を両立させるための、システム運用の新しい考え方です。

ざっくりと、以下のような取り組みを行います。

・システムの信頼性の定義
・手作業による運用の自動化
・信頼性向上のための活動

これらの取り組みにより、システムの信頼性を向上させ、ユーザーに価値のあるサービスを提供し続けることが可能となります。

(1)SREの目的

SRE(Site Reliability Engineering)の主な目的は、システムの安定稼働を保証しつつ、新機能の追加やシステムの改善を継続的に行うことです。

SREでは、システムの信頼性をエンジニアリングの対象として捉え、ソフトウェア開発の考え方や技術を活用し、システム運用の自動化や効率化を図ります。

具体的には、以下のような取り組みを行うことで、システムの信頼性を向上させます。

・システムの信頼性の定義
・信頼性向上のための活動
・システムの信頼性向上における自動化の役割

①システムの信頼性の定義

システムの信頼性は、そのシステムが計画された条件下で、期待された性能を維持する能力のことを指します。これには、可用性、パフォーマンス、およびセキュリティが含まれます。各要素は、システムがいかに信頼できるかを示す重要な指標です。

<可用性>

システムが稼働してユーザーの要求に応答できる状態をどれだけ維持できるか、特に障害からの迅速な復旧が可能かどうかなど。

<パフォーマンス>

システムがどれだけ迅速に応答し、要求された作業を処理できるかを示す。

<セキュリティ>

不正アクセスやデータ漏洩のリスクを最小限に抑え、システムとそのデータを保護する能力。

②信頼性向上のための活動

エラー許容の定義や障害発生時の事後検証などを行い、システムの信頼性を向上させるための取り組みを行います。

②システムの信頼性向上における自動化の役割

システムの運用において、人的ミスを防ぎ、運用担当者の負担を軽減するため、監視や障害対応などの作業を自動化することがSREの目的・責務として重要です。

自動化することで、人的ミスを防ぎ、システムが持続的に高いパフォーマンスを発揮し、ユーザーに安定したサービスを提供できるようになります。

(2)SREが注目される背景

SREが注目される背景には、以下の2つの要因が挙げられます。

・クラウドサービスの普及
・DevOpsの普及

①クラウドの普及

近年のクラウドサービスの普及により、インフラの運用がソフトウェア化され、自動化が容易になりました。SREは、このクラウド環境での運用に適したアプローチとして注目されています。

②DevOpsの普及

DevOpsは、開発と運用の連携を強化するアプローチです。SREは、DevOpsの考え方をシステム運用にも適用するものとして、注目されています。

クラウドの普及やDevOpsのトレンドにより、システムの信頼性を向上させることを目的としたSREへの注目は今後も高まっていくと考えられます。

(3)SREとDevOpsの違い

SREとDevOpsは、どちらも開発と運用の連携を強化するアプローチとして注目されていますが、以下のような違いがあります。

SRE

DevOps

目的

システムの信頼性を向上させること

開発と運用の連携を強化し、ソフトウェアのリリースサイクルを短縮すること

アプローチ

主にシステム運用の観点からアプローチする

開発と運用の両方の観点からアプローチする

スキル

ソフトウェア開発のスキルも求められる

開発と運用の両方のスキルが求められる

SREとDevOpsは、どちらも開発と運用の連携を強化するという共通の目的を持っていますが、その目的を達成するためのアプローチや求められるスキルには、それぞれ違いがあります。

SREは、システムの信頼性を向上させることを目的として、主にシステム運用の観点からアプローチします。そのため、システム運用のスキルに加えて、ソフトウェア開発のスキルも求められます。

DevOpsは、開発と運用の連携を強化し、ソフトウェアのリリースサイクルを短縮することを目的として、開発と運用の両方の観点からアプローチします。そのため、開発と運用の両方のスキルが求められます。

2、SREに必須な指標

SREエンジニアチームでは「信頼性」を定義し、共通認識を合わせることで、チーム内が同じ方向に向かって信頼性を改善できるような指標が必要になります。

そのため、SREでは信頼性を、SLI、SLO、SLAという具体的な数値に落とし込み設定することで、共通で認識するための、わかりやすい指標を定義します。

(1)SLI

サービスレベルの指標(SLI)とは、サービスレベルを測るための定量的な指標です。

例えば、「サイトの応答時間を短くする」という目標だけでは、人によって「短い」の基準が異なるため、目標を達成したかどうかを判断することができません。

そこで、「理想的なリクエストの応答時間は0.3秒」のように、定量的な指標を定義することで、目標を達成したかどうかを客観的に判断することができます。

また、SLIは、サービスレベル目標(SLO)を測るために用いられます。

(2)SLO

サービスレベルの目標(SLO)は、SLIを達成するための目標として定義されます。

一例を挙げると、SLIが「理想的なリクエストの応答時間は0.3秒」であれば、SLOは「99.9%の確率で、リクエストの応答時間は0.3秒以内である」のように定義されます。

目標が高すぎると、目標を達成するための原因を調査することにリソースが割かれてしまいます。

逆に目標が低すぎると、ユーザーエクスペリエンスが低下し、ユーザーからのクレーム等に繋がる可能性があります。

したがって、SLOを定義する際には、ビジネス目標を踏まえて、適切な目標を定めることと、達成可能な目標を定めることが重要になります。

(3)SLA

サービスレベルの合意(SLA)は、サービス提供者と利用者との間で結ばれる、サービスのレベルに関する取決めです。

SLAは、サービス提供者と利用者双方にとって重要な取決めとなり、サービス提供者は、SLAを達成するために必要な対策(SLOの達成等)を講じることで、サービスの品質を保証し、利用者の満足度を向上させることができます。

利用者は、SLAの内容を理解することで、サービスの品質やサービス提供者の責任範囲を把握することができます。

3、SREエンジニアの役割

SREの考え方が広まるにつれて、エンジニアは、システムの安定稼働と新機能の開発や改善を両立させる役割を担うようになりました。

従来の運用エンジニアは、システムの安定稼働を主な目的としていましたが、SREエンジニアは、システムの安定稼働を保つだけでなく、新機能の開発や改善にも関与します。

これにより、新機能のリリースとシステムの安定稼働を同時に実現できるようになり、システム運用の効率化が図られます。

(1)システムの信頼性向上

システムの信頼性向上のために、SREは運用課題の解決にも取り組みます。

具体的には、開発と運用の連携を強化するため「エラーバジェット」を活用したり、障害の原因を分析して再発を防止するため「ポストモーテム」を実施したりします。

①エラーバジェット

エラーバジェットとは、サービスレベル目標(SLO)に基づいて、一定の範囲内でエラーを許容することができるかの指標です。

例えば、SLOが「99.9%の可用性」と定義されている場合、エラーバジェットは「0.1%のエラーは許容する」ということになります。

エラーバジェットを活用することで、開発と運用のバランスを取ることができます。開発者は、エラーバジェット内で新機能をリリースすることができます。

運用者は、エラーバジェットをオーバーした場合、開発者に新機能のリリースを差し控えるように依頼することができます。

これにより、開発と運用のバランスをとり、新機能のリリースと安定稼働の両立を図ることができ、システムの信頼性を向上させることができます。

②ポストモーテム

ポストモーテムとは、障害やインシデントの原因を分析し、再発防止策や改善策を検討する手法です。

SREが行うポストモーテムは、一般的な障害報告と大きく異なる点があり、それは、非難を排除するということです。

ポストモーテムでは、障害やインシデントの原因を正確に把握することが重要です。

そのためには、関係者全員が、事実に基づいて、冷静に議論を行う必要がありますが、非難があると、関係者が萎縮してしまい、本質的な原因を隠してしまう可能性があります。

また、非難を排除することで、本質的な改善の議論にフォーカスすることができます。障害やインシデントの原因は、単純に個人のミスとは限りません。

システムの設計や運用方法に問題がある場合もあるため、非難を排除することで、関係者全員がシステムの改善に集中することができます。

SREが行うポストモーテムは、非難を排除することで、障害やインシデントの再発防止に集中するため、システムの信頼性を高める重要な取り組みです。

(2)自動化/省略可

SREは、システムの信頼性を向上させるため、自動化を推進しています。
その目的は、以下の2つです。

・ヒューマンエラーの低減
・コストの削減

①ヒューマンエラーの低減

手作業が多いと、それだけヒューマンエラーのリスクが高まります。自動化することで、ヒューマンエラーを排除し、障害の発生を防止することができます。

②コストの削減

サービス規模が大きくなるにつれて、運用作業の量も増加します。自動化することで、人手や時間といったコストを削減し、不具合の改修やサービス向上にリソースを割り当てることができます。

また、SREは、自動化の対象を「トイル」と定義しています。
トイルとは、自動化できるのに、自動化を実施していない繰り返しの手作業のことです。

SREは、トイルを見つけ出し、ソフトウェアエンジニアリングの知見を活用して自動化することで、運用作業の効率化を図ります。

SREの自動化の取り組みは、以下のような流れで行われます。

<1>トイルの洗い出し

まずは、自動化の対象となるトイルを洗い出します。具体的には、運用作業を洗い出し、自動化できる可能性のある作業を抽出します。

<2>自動化の検討

トイルを洗い出した後は、自動化の検討を行います。自動化の難易度や効果などを考慮して、自動化の優先順位を決めます。

<3>自動化の実行

自動化の優先順位が決まったら、自動化を実行します。自動化ツールやスクリプトなどを活用して、トイルを自動化します。

(3)インシデント対応と改善

SREのインシデント対応は、単純な問題解決ではなく、システム改善の機会と捉えます。

そのため、インシデントの原因を分析し、再発防止策を検討しますが、この分析では、技術的な問題だけでなく、組織や人の行動も改善の対象として考慮します。

例えば、上記の「ポストモーテム」に記載の通り、非難を排除することや、原因を個人の責任として処理するのではなく、チーム全体の課題として捉えることで、組織全体としての改善を行うことができます。

また、上記の「自動化/省略可」に記載の通り、インシデント対応の自動化も検討することで、手作業を減らし、ヒューマンエラーのリスク軽減や、迅速なエラー対応が可能になります。

この仕組みによって、運用担当者はその他の重要なタスクに専念することができます。

4、SREエンジニアの現状

本章ではSREエンジニアの現状について、弊社の調査をもとに解説いたします。

(1)SREが正社員として在籍する企業は、わずか3割

弊社が実施した調査によると、SREが正社員として専任で在籍している企業は、全体のわずか3割にとどまることが明らかになりました。

SREの専任ポジションを持つ企業はまだ限られており、SREの導入が進んでいるとは言い難い状況です。

さらに、SREではないシステム担当者がSRE業務を兼務している企業が6割にも上りました。これは、SREの役割や重要性が認識されつつあるものの、まだまだ多くの企業が専任のSREを雇用していない現実を示しています。

この調査結果から明らかなように、SREの専任配置は多くの企業にとっていまだに課題と言えるでしょう。システム運用の信頼性向上に向けた取り組みは重要ですが、その実現にはさまざまな障壁が存在しているようです。

(2)SREの必要性は感じているが採用が難しい

上記の調査に加えて、技術責任者のうち6割がSREの採用を検討していることが判明しました。

SREの導入に関心を寄せる技術責任者が多い一方で、実際にSREを導入し、課題に対処するにはいくつかのハードルが存在しています。

以下、調査結果から得た主な原因になります。

<1> SRE人材の希少性

SREの専門知識とスキルを持つ人材はまだ稀であり、転職市場においても求人に対する適切な応募者が不足しています。

企業がSREエンジニアを採用しようとする際、適切な候補者を見つける難しさが課題となっています。

希少なSRE人材を獲得することが現実的でない場合、企業は他の方法でSREの原則を取り入れる必要があります。

<2> 採用コストの高騰

SRE人材の希少性に加え、高い専門知識と経験に応じて、SREを採用するコストが高騰しています。

高い給与や魅力的な福利厚生等、SREを企業に引き寄せるためには多くのリソースが必要です。これにより、採用コストが上昇し、多くの企業にとって課題となっています。

以上の課題から明らかなように、SREの導入は多くの企業にとって検討すべき重要な課題ですが、その実現には多くの障壁が存在しています。

(3)SREの採用に困っているなら支援サービスがおすすめ

上記の調査結果から見えてきた課題に対して、弊社ではSREの導入を検討している企業様へ、SREのリソース支援サービス「srestTEAM」を提供しております。

20を超えるプロダクトのインフラ構築・運用の実績がある、srestのSREチームが人月ではなくチーム型でSRE業務を支援しています。

サービス規模に合わせた価格プランを設定しているため、適切な費用で利用することができるため、採用よりも安価なコストでサービスを利用することが可能です。

インフラ運用の効率化、インフラ構築・運用コストの削減、セキュリティレベルの向上の実現をsrestメンバーがお手伝いさせて頂きますので、お気軽にお問合せください。

まとめ

GoogleがSREを提唱してから約20年程経過し、SREの概念を導入する企業が増加してきました。

安定稼働を保証し、新規機能追加等のリリースサイクルを早めることができる効率的なシステム運用は、信頼性向上やコスト削減のみならず、結果的に企業としての競争力が上がることにも繋がります。












イベントログ一元監視ダッシュボード

AWSのコスト削減、可視化から始めませんか?
お気軽にお問い合わせください

お問い合わせ・資料ダウンロード

FTR認証取得

srestはAWS ファンデーショナルテクニカルレビュー(FTR)の認証を取得しています

FTRは、AWS上で稼働しているソフトウェアやSaaSがAWSのベストプラクティスに基づいて実装・運用されているかを「セキュリティ」「信頼性」「運用優位性」という3つの観点で評価する技術レビューです。