SREはオブザーバビリティからはじめる - そのサービスレベル目標、高すぎませんか？

近年、デジタルサービスが企業の競争力を左右する重要な要素となる一方で、システムの複雑化・高度化が進み、サービス品質の維持は年々難しくなっています。前回までは、オブザーバビリティが「システムを理解し、問題の原因特定と改善を迅速に行うために欠かせない考え方」であることをお伝えしました。「いまさら聞けないオブザーバビリティ」の過去回はこちらを参照。

今回は、そのオブザーバビリティがどのようにSRE(Site Reliability Engineering:サイト信頼性エンジニアリング)と関係し、なぜ「100%の信頼性を目指すのは得策ではない」のかを解説します。

• 

SREとは？ - 「信頼性を最適化しながら変化スピードを落とさない」考え方

SREは、Googleが大規模サービスを運用する中で確立した手法で、文字通り「サイト(サービス)の信頼性をエンジニアリングする」というアプローチです。日本ではここ10年ほどで徐々に注目され、大企業からスタートアップまで、その考え方が広がりつつあります。

従来、運用チームは「障害を減らすこと」に専念し、開発チームは「新機能を出すスピード」を重視する構図がありました。SREの真髄は、両者の対立をいたずらに先鋭化させず、両立へと導く考え方にあります。

よく混同されがちなDevOpsには明確な定義こそありませんが、そちらは一般的には「文化やツール、プラクティスを通じて、開発と運用の壁を取り払う」ことをゴールとする手法とされています。

一方、SREでは、それをさらに具体化し、SLO(Service Level Objective:サービスレベル目標)やエラーバジェットなどの定量的な仕組みを通じて、高い信頼性と迅速なリリースの両立を図ります。

• 

  SREはサービスの信頼性と開発速度のバランスを取ること

そのサービスレベル目標、高すぎませんか？ - SLOとエラーバジェットの考え方

サービスレベルとSLOの本質

SLI(Service Level Indicator:サービスレベル指標)は、サービスの信頼性を数値で測定したものです。たとえばECサイトにおける「決済処理の完了率」といった、ユーザーが実際に体感する品質を具体的な数値として計測します。以下の図2では、現在の実測値は95%となっています。

SLOは、このSLIに対する目標値を定めたものです。例えば「APIの応答時間はその99%が1秒以内であること」というように具体的な数値目標として設定します。

この目標は、ユーザーの期待、ビジネスへの影響、技術的な実現可能性、運用コストのバランスを考慮し、ユーザーが不満を感じないギリギリの水準(図2の例では80%)に設定します。SLOを定めることで、チームは明確な行動指針を得られます。実測値(SLI)が目標値(SLO)を下回った場合は即座に回復に注力します。

一方、実測値が目標値を上回っている場合、その差分(図2の例では95%-80%=15%)は「残エラーバジェット」として、新機能のリリースや実験的な改善施策に活用できます。また、目標値(SLO)から100%までの差分(図の例では100%-80%=20%)は「エラーバジェット」として、計画的な施策や改善に割り当てることができます。

• 

  SLI/SLO/エラーバジェットとは？

100%の信頼性追求がもたらす弊害、現実的なアプローチ

「すべての機能が常に完璧に動作する」といった目標は魅力的に感じられますが、現実的ではありません。ユーザーが本当に求めているのは「必要な時に必要な機能が適切に動作する」ことであり、たとえばECサイトであれば「商品を探して購入できること」が本質的な価値です。

過度な品質追求は、むしろサービスの成長を妨げます。すでに十分な水準にある機能を完璧にしようとして工数を投じすぎると、新機能の開発や本質的な改善が後回しになり、競合に対して致命的な遅れを取りかねません。

重要なのは「100%」という完璧な数値ではなく、「ユーザーが許容できる最小限の信頼性ライン」を見極めることです。これにより、適切なリソース配分が可能となり、イノベーションと信頼性のバランスを保ちながら持続可能な成長を実現できます。

オブザーバビリティはSREの第一歩

まずは「何を測るべきか」を定める

SREを実践する際の最初のステップは、いきなりSLOを設定することではありません。まず「ユーザーにとって大切な体験は何か」を見極め、その体験を的確に表すSLIを定義することから始めます。たとえばページの表示速度やエラー率、処理の成功率など、ユーザー体験を数値化できる指標を特定し、それを正確に測定できる状態を整えることが重要です。

この計測の仕組み(オブザーバビリティ)がなければ、後続のすべての活動が勘や推測に頼ることになってしまいます。ログやメトリクスがバラバラに管理されていて、サービスの状態を正確に把握できず原因特定もできない状況では、どんなに素晴らしい目標を掲げても意味がありません。

実際のサービスレベルを継続的に測定・把握できる状態になって初めて、ビジネス部門を含む関係者と「どこまで改善するべきか」というSLOの議論が可能になります。こうした段階を踏むことで、実効性のある改善活動を展開できます。

具体例:ECサイトの応答速度をSLOにしたケース

たとえばECサイトにおいて「ユーザーの購入完了までの導線で、95%以上が問題なく完了できる」というSLOを設定したとしましょう。もし障害が起きて顧客が離脱するような事態が発生しても「どの購入プロセスで問題が発生しているのか」「特定の機能だけで問題が起きているのか」が把握できないと、対応が遅れるばかりです。

そこでオブザーバビリティを整備しておけば、「商品の在庫確認プロセスで失敗が集中している」「特定キャンペーンの購入処理で完了率が95%を下回っている」といった問題を素早く特定できます。

さらにイベントデータ(第1回参照)を確認すれば、どのユーザーがいつどんな商品でエラーに遭遇したのかも、追跡可能です。その結果、エラーバジェット内で計画的な改善が進められるだけでなく、新機能のリリースや実験的な施策の実施判断も、データに基づいて適切に行えるようになります。

組織全体で取り組むのがSRE - インフラチームだけの話ではない

「SRE＝インフラのチーム名が変わっただけ」「オブザーバビリティ＝運用部門の取り組み」といった誤解は根強いものの、実際にはビジネス部門や開発チームを含めた全社的な協力が欠かせません。

たとえばSLOの値を設定する際には、「顧客の期待値」「企業ブランド」「コストとのバランス」など、ビジネス視点が不可欠です。

「ユーザーがストレスを感じる応答速度はどの程度か？」「そのSLOを達成するために必要な対応は何か？」「障害を検知した後、どのように対応し、どのようにエスカレーションするか？」といった意思決定を1つの“共通言語”で行うためにも、オブザーバビリティの仕組みが土台となります。全社的にサービスの状態を可視化しておくことで、的確かつ迅速な判断が可能になります。

「Jカーブ現象」に注意、導入初期こそ苦しいが、諦めないで

なぜ一時的に悪化するのか

SREやオブザーバビリティを導入して間もない頃は、ツールの整備や新たなプロセス定義に手間取るため、一時的に障害件数や対応工数が増加しているように見えることがあります。これを「Jカーブ」と呼ぶこともあります。

組織内で「どこまで自動化するか」「どのデータを可視化するか」が定まらず混乱が生じやすい時期であり、新たなツールの導入や学習が追いつかず、現場がストレスを感じやすい段階でもあります。

• 

  出典:Jカーブ、2022年の「State of DevOps Report」より(ソフトウェア開発組織の動向を毎年調査しているレポート)

それでも続ける意義

しかし、ここで諦めてしまうと、SREの真の価値である「迅速なリリースと高い信頼性の両立」を得る前に終わってしまいます。

短期的に苦しくても、オブザーバビリティを活用して障害原因を迅速に把握し、再発防止策を講じられる成功体験を少しずつ積み重ねることが大切です。

適切に導入が進めば、やがて運用効率や障害検知スピードが大きく改善し、結果として“J”の形で上向きのカーブを描くように、サービス品質と開発速度の両方が向上していきます。

ポストモーテムと定期的なパフォーマンス観測の両輪で進める

起きたことを「振り返る」だけでは不足、未然に防ぐための定期的なパフォーマンス観測

SREの文化では、障害発生中の調査にオブザーバビリティを活用するだけでなく、事後に「ポストモーテム」と呼ばれる振り返りを行い、再発防止策を探るのが定番です。

ただし、この振り返り自体が目的化してしまい、形式的なミーティングに終始してしまうケースもあります。具体的な改善策に結びつかなければ、同じ障害が繰り返されるリスクが高まります。

一歩進んだ取り組みとして、チームを超えた定期的なパフォーマンス観測を行い、潜在的な問題を早期に発見して対策を講じることが重要です。観測データ(オブザーバビリティ)をもとに「負荷が徐々に高まっている箇所はないか？」「ステージング環境やサンドボックスで問題の兆候が見られないか？」などをチェックします。

こうした検証を週次の「パフォーマンス定点観測会」として組織的なシステム運用に組み込むことで、本番環境で重大な障害が発生する前に対策を打ちやすくなり、障害を防ぐ可能性が格段に高まります。

“100％の信頼性”は目指さない。ビジネスを止めないために

SREは、必要十分な信頼性を保ちつつ、迅速なビジネス展開を実現するための全社的な取り組みです。「100％の信頼性」を追い求めることは、コスト面やイノベーションの面で大きなデメリットを伴います。そのため、ユーザーが不満を抱かないぎりぎりのラインをビジネス視点で見極め、それをSLOとして定義することが現実的です。

そして、そのSLOを達成するためには、サービスの状態を正確に把握し問題解決を支えるオブザーバビリティが欠かせません。さらに、ビジネス・開発・運用の各部門が「何が価値を下げる障害なのか」を共有し、全社的な合意のもとでプロセスを確実に回すことで、障害対応に追われる状況から、余裕をもって新機能を開発し続けられる体制へと移行できます。

初期段階ではJカーブによる一時的な混乱が生じるかもしれませんが、継続的な取り組みによって運用効率とビジネス成長の両面で大きなメリットを享受できるはずです。次回は、「クラウド」や「コンテナ」など、システム環境がますます複雑化する中で、どのように観測・運用を高度化していくかを掘り下げていきましょう。