SREとは何か、ソフトウェア開発の手法やノウハウをIT運用に適用 - DevOpsとの違いから、最新事情まで解説 -

SREの重要なプラクティス

すべてのSREプラクティスはシステムの信頼性を向上させることを目的としており、次の5つの主要なカテゴリに分類されます。

可用性

SREチームは、システムやサービスの本番稼働後の可用性を維持する責任を負っています。まずは、基盤となるサービスのサービスレベル目標(SLO)、サービスレベル契約(SLA)、サービスレベル指標(SLI)を設定することから始めます。SLIは、稼働時間やリクエスト遅延などのメトリクスの概要を示すもので、企業が顧客に提供するサービスレベルを測定するために使用されます。これらのSLIに基づいて、サイトまたはサービスのパフォーマンス(たとえば、99.99%の可用性)を測定する手段がSLOに定義されます。最後に、これら両方に基づき、サービスの信頼性目標とその目標が達成されなかった場合の対応が明記されたSLAを作成します。

パフォーマンス

可用性が安定したら、SREチームはサービスパフォーマンスの改善に目を向けることができます。遅延、ページの読み込み速度、その他のパフォーマンスメトリクスは、必ずしも全体的な可用性に影響を与えるわけではありません。しかし、時間の経過とともに悪化し、頻繁に発生するようになると、サービスの顧客離れにつながる可能性があります。SREチームは、開発チームやアプリケーションサポートの支援、バグの修正を行うほか、システム全体のパフォーマンスの問題も未然に察知します。こうしてパフォーマンスに関する軽微な問題を少しずつ特定して修正していくことで、サービス全体の信頼性が向上します。

監視

SREチームは、監視対象を決定し、それぞれのサービスの稼働時間とパフォーマンスをどのように測定するかに基づいて、適切な監視ソリューションを導入する責任があります。最終的には、エンジニアリングチームやITチームがシステムの健全性を包括的に把握できるソリューションを実装する必要がありますが、これはSREの最大の課題の1つといえます。

インシデント対応

SREチームは、インシデント対応(つまりインシデントに対する動員)において重要な役割を担います(記録および監査証跡の仕組みであるインシデント管理とは異なります)。SREチームのメンバーは、システム内で発生したインシデントへの対応と説明、そしてレビューができなければなりません。これには、本番ワークフロー、プロセス、アラート基準、およびデプロイに関するその他の要因の監査が含まれる場合があります。通常、SREチームは、イベントに対応する際のガイドとしてオンコールプレイブックを使用します。また、誰も責めることのない事後分析を実施して、特定の問題の原因および再発防止策について理解し、必要な改善点を文書化します。

環境の整備

SREチームは最終的に、開発チームとITチームの環境を整え、サービスの健全性やインシデントへの迅速かつ効果的な対応方法についての理解を深められるようにします。SREエンジニアが開発チームやITチームと連携することで、開発者は本番環境について詳しく知ることができます。また、IT運用チームは開発ライフサイクルに早い段階から関与できるようになります。

この取り組みの大きな部分を占めるのがデプロイ環境の整備です。これは、エンジニアと協力しながら新しいサービスのオブザーバビリティを確保するための活動です。これによって信頼性に関わる問題に対してよりプロアクティブかつ迅速なアプローチをとることができます。

SREの「4つのゴールデンシグナル」

SREを語る際に、よく取り上げられるのが「4つのゴールデンシグナル」です。これは、分散システムを効果的に監視するためのフレームワークの1つで、システムが健全であることを示すベンチマークです。それぞれについて見ていきましょう。

レイテンシー

リクエストの処理にかかる時間のことです。「健全」と判断できるレイテンシー率のベンチマークを定め、成功したリクエストと失敗したリクエストを区別してレイテンシーを監視し、システムの健全性を追跡します。システム全体でレイテンシーを監視することで、パフォーマンスが悪いサービスを特定し、インシデントをより早い段階で検出できます。

トラフィック

サービスで処理されるユーザーまたはトランザクションが一定時間にシステムに与える負荷を示す指標です。アプリケーションやサービスで発生する実際のユーザーとの通信とトラフィックを監視することにより、ユーザー視点でエクスペリエンスを把握し、需要の変化がシステムにどのような影響を与えるかを確認できます。

エラー

リクエストの失敗率を表します。システム全体で発生するエラーの割合を監視し、エラーバジェットを作成して、どのエラーが最も重大であるかを定義する必要があります。これにより、サービスについてユーザー視点で健全性を把握し、頻発するエラーにすばやく対応して修正できます。

サチュレーション

システムの全体的なキャパシティと利用可能なリソースを表し、特定のサービスのキャパシティを可視化できます。大半のシステムでは、使用率が100%に達する前にパフォーマンスが低下し始めるため、SREチームは「健全」な使用率(サービスのパフォーマンスと可用性が確保される値)についてのベンチマークを設定する必要があります。

SREでは、これらを継続的に監視します。基準を下回ったサービスを改善し続けることで、サービスの信頼性を維持し、パフォーマンスを一定のレベルに保つことを目指します。

SREを始める前に知っておくべきこと

SREはDevOpsの活動と密接に連携しており、開発チームと運用チーム間には緊密なコミュニケーションが必要です。そのためこれらのチームが成功するには、信頼、連携、継続的改善の文化が不可欠です。

また、SREエンジニアは、開発と運用のスキルを兼ね備えていることはもちろん、従来のソフトウェアエンジニアリングのツールとプラクティスを理解している必要があります。システムを包括的に把握することに加え、信頼性を高めるための新しい方法を取り入れる柔軟性も必要とされます。

さらに、SREには積極的なコミットメントが求められます。これは、単にツールやパッチを適用してシステムの欠陥を修正する作業ではありません。SREに求められているのは、文化を変えることや、運用に関する新しいプロセスや考え方を導入することです。他の取り組みと同様に、SREも最初は1人の推進者から始まるかもしれませんが、SREのプラクティスを成熟させていくためには、最終的に上層部からの賛同が必要となります。

SREとDevOpsとの相違点

SREとDevOpsは、どちらも開発スピードを高めながらソフトウェア品質を向上させるための開発手法です。しかし、それぞれが最も大切だとしている点には、違いがあります。SREは大規模かつ複雑なシステムの信頼性を高めることが第一の目標であるのに対し、DevOpsは開発と運用の連携を促進するカルチャーの確立を主な目的としています。

両者には数多くの共通点もあります。たとえば、KPIの設定によるシステムパフォーマンスの可視化、信頼性と可用性の向上への取り組み、システムの継続的な改善などが当てはまるでしょう。ただし、それらを実現するためのアプローチには微妙な違いがあります。

SREのアプローチは、システムの自動監視、問題の自動検出、アラートの自動発信など、システムを自動化することで、問題解決能力を高めることに注力します。インフラ改善や自動化ツールの開発・活用を通じて、システムの信頼性向上を目指すことになります。

一方、DevOpsでは、開発と運用のギャップを埋めることで、迅速かつ柔軟なソフトウェアリリースを実現しようとします。そして、そのために、CI/CD(継続的インテグレーション／継続的デリバリー)をうまく使いこなすことが重要になります。

つまり、システムの信頼性向上を最優先するSREに対し、DevOpsは開発のスピードアップを第一に考えるわけです。とはいえ、両者は決して対立するものではありません。前述したようにSREはDevOpsの活動と密接に連携することで目標を達成しやすくなることを理解しておいてください。

DevOpsについての解説はこちら

DevOpsにおけるSREの役割

DevOpsにおけるSREの役割は、DevOpsチームが開発したアプリやサービスをエンドユーザーが必要なときにいつでも使用できるようにしておくことです。SREとDevOpsは一括りに語られることが多いですが、これらは2つの異なる分野です。

DevOpsは、プラクティスとして、また一連の原則としての両側面から認識されています。プラクティスとしてのDevOpsは、ITデリバリーのためのアプローチであり、人、手法、ツールを連携させることで、開発チームと運用チームのサイロ化を解消します。

DevOpsは、その名前が示すように、アプリケーションのコードを作成するソフトウェア開発(Dev)と、それらのアプリケーションを本番稼働させてエンドユーザーに提供し、信頼性の維持を図るIT運用(Ops)との間を隔てるギャップを埋めることを目的としています。

原則としてのDevOps(DevOps文化)は、アジャイルの普及により生まれたものです。アジャイルは、段階的なデリバリー、チームコラボレーション、継続的な計画と学習に焦点を当て、より優れたソフトウェア開発プラクティスを導くための原則を確立しました。ソフトウェア開発とIT運用を連携させることで、DevOpsはソフトウェア開発ライフサイクル(SDLC)全体にわたってアジャイルの原則を拡張し、継続的な改善を目標としてワークフロー全体を最適化します。DevOpsがうまく機能すると、コーディングの反復と導入が迅速化するだけでなく、新しいアイデアを市場に投入するまでの時間が短縮され、バグが減少し、インフラの安定性が向上します。

SREは、DevOpsの原則において重要な機能を果たしており、プラクティスとしてのDevOpsとも重なる部分が多いものの、責任範囲はより限定的です。DevOpsでは、開発者が実際に製品のオーナーシップを持って運用することが求められます。しかし、開発者は絶えずアプリの新機能を開発しなければならないため、そういった取り組みが現実的ではない場合がほとんどです。 

SREエンジニアは、ソフトウェア開発とIT運用の両方の知識を活かして、デプロイ、設定、監視などのコードの管理を監督できます。大まかに言うと、SREは新しいソフトウェアや機能の迅速なデプロイ、およびITインフラの安定性を確保することで、開発と運用間の関係を強化します。

SREに欠かせない自動化

自動化による反復的な手作業の削減は、SREが重点的に取り組むべき課題です。そのために、SREエンジニアは、ログ分析やパフォーマンス調整などの多くの自動化された運用タスクを活用しています。また、自動化は、MTTR (平均修復時間)の短縮、ダウンタイムやシステム停止による影響の軽減、さらには監視やアラート、パッチ適用などのインシデント対応アクティビティのための詳細なコンテキストを提供するためにも欠かせません。

自動化は、スピード、一貫性、効率、適応性が重要視される最新の開発環境では必須といえます。そして、最も重要なポイントは、日常業務の反復的な運用タスクの数が減り、SREチームのメンバーが新しいツールの作成、インフラの変更の監視、信頼性向上のためのその他のタスクの実行に集中できるようになることでしょう。

SREを適切に実践するために必要な理念とスキルセット

SREを効果的に実践するには、システムについて、またそれらがどのように連携しているかについて包括的な視点を持つことが必要です。SREエンジニアは、システムを全体的に捉え、個々のコンポーネントだけでなく、それらの相互接続も重視しなければなりません。これを踏まえ、『The Site Reliability Workbook』に記載されている以下の7つの原則に従うことで、効果的にSREを実践することができます。

運用をソフトウェアの問題として捉える

SREの主な考え方として、ソフトウェアエンジニアリングのアプローチがソフトウェアの問題に対する解決策であるとしています。

サービスレベル目標で管理する

SREが目指すのは100%の可用性ではありません。障害の発生は想定の範囲内です。SREはプロダクトチームと協力して可用性の合意目標を設定し、そのSLOに基づいてサービスを管理します。

手間を最小限に抑えるように努める

反復的で手間のかかる手作業をデフォルトの方法にすべきではありません。自動化できるタスクやオペレーションはすべて自動化すべきです。

今年の仕事を自動化する

どのようなタスクやオペレーションを自動化するかを決定し、実装のための戦略を立てます。

失敗のコストを抑えて迅速な行動を促す

ライフサイクルの早い段階で問題を特定して修正し、顧客への影響を最小限に抑えます。

開発者とオーナーシップを共有する

開発チームとSREチームが可視性とオーナーシップを共有できるように、サイロを解消して境界をなくします。

職務や役職にかかわらず、同じツールを使用する

各チームが別々のツールを使用していては、1つのSREチームで複数の開発チームを効果的にサポートすることはできません。ツールセットの標準化が、SREプラクティスを成功させるための鍵となります。

SREエンジニアの役割と責任

SREエンジニアは、さまざまな責任を担っています。SREの一般的な役割には次のものがあります。

運用およびサポートチームを支援するソフトウェアの構築

SREエンジニアは、その開発スキルを活かして、ITスタッフやサポートスタッフの業務の効率化に役立つソフトウェアを構築し、実装します。その範囲は、新しいツールの構築から、ソフトウェアデリバリーの弱点の補強、既存の監視ツールの調整、本番環境のコードの変更まで多岐にわたります。

サポートエスカレーションの問題の修正

SREエンジニアは、初期の段階ではサポートエスカレーションの問題の修正に時間を費やすことになります。ただし、システムの信頼性が向上するにつれて、これに費やす時間は減少します。多様なスキルセットと経験に基づき、問題を適切な担当者やチームに転送するために必要な専門知識を備えているのがSREエンジニアです。

オンコールのローテーションとプロセスの最適化

通常、SREエンジニアにはインシデントの発生に対応できることが求められるため、システムの信頼性を向上させるためのオンコールプロセスを最適化する方法について多くの提言を行います。SREチームは、アラートに自動化とコンテキストを追加してインシデント対応の連携を改善し、ランブックやドキュメントを更新してオンコールチームが今後のインシデントに備えられるよう支援します。

知識の文書化

SREチームは、ソフトウェア開発ライフサイクルのほぼすべての側面に関与しているため、サービスやプロセスについて長年蓄積された豊富な知識を有しています。SREエンジニアは、定期的に学習を繰り返しながらランブックを整備するため、エンジニアリングチームは必要なときに必要な情報を得ることができます。これにより、スチュワードシップが強化され、チーム間の信頼が促進されます。

インシデント後のレビューの実施

SREチームは、ソフトウェア開発者とIT運用の専門家が誰も責めることのない分析を実施し、調査結果を文書化し、学んだことを行動に活かせるようにする役割を担っています。SREエンジニアは、インシデント後のアクションアイテムについても責任を負います。これには、SDLCやインシデントライフサイクルの一部を構築したり最適化したりすることが含まれます。

SREとLLM

ここ数年、生成AIが大きな注目を集める中、SREとLLMを組み合わせることで、より高度な成果が期待できるのではないかという議論が深まってきています。

まずは、ナレッジの管理について。過去のインシデント情報や障害対応履歴などをLLMに学習させることができそうです。エンジニアに、これらの情報を網羅的につかんでいる生成AIと対話しながら仕事を進めてもらうことで、業務のスピードと確実性を向上させることが期待できます。

ログやイベント、アラートなどのデータを学習させると、障害管理の自動化が進むかもしれません。この部分は、自社のシステム／ネットワーク環境に特化した情報が必要になる領域が広いため、過去の情報をどのように学習させるべきかという議論も行われています。

最終的には、LLMを使ってSRE分野における予測分析をできるようになることが理想とされており、多くの議論はその方向で進められているようです。

SREとは：まとめ

稼働時間を長くして維持することは、あらゆる組織が取り組み続けている課題です。しかし、効果的なSREプロセスを有する企業はシステムの回復力が高く、その結果としてリリースの成功率も向上するため、競合他社よりも優位に立つことができます。インシデントが発生した場合でも、短い平均確認時間と平均修復時間(MTTA/MTTR)で対応できます。本番環境の問題の修正に要する時間が減ることで、開発、SRE、運用のすべてのチームは、それぞれの分野でビジネス価値の提供に注力できるようになります。その結果、信頼性はソフトウェア開発を滞らせる要因ではなく、ソフトウェア開発における機能の1つとなるのです。

Splunkは、SREに対して、高い付加価値を提供できるソリューションを提供しています。Splunkを使えば、オンプレミス環境、クラウド環境、ハイブリッド環境を問わず、あらゆるシステムから生のデータをリアルタイムに収集できます。データは、直感的に理解しやすいビジュアルなダッシュボード上でリアルタイムに分析・可視化することが可能。大規模かつ複雑なシステム環境における実績も十分です。

Splunkを活用することで、システム全体を可視化し、高い信頼性を担保できます。そして、Splunkは効率的な開発・運用を実現することにも役立ちます。システムの規模や複雑さ、Splunkは、SREというアプローチを取り入れるすべてのプロジェクトを強力にサポートすることができます。

関連コラム

• DevSecOpsの時代：開発者とSREがSOCチームに合流
• SRE、DevOps、プラットフォームエンジニアリングの違い