SREとは：SREメトリクスと監視のゴールデンシグナル

日本でもDevOpsやSREというキーワードを聞くようになりましたが、肝心のITシステム自体はまだまだ従来のまま、といったケースが非常に多いかと思います。そして多くの場合、監視の仕組みも従来のままとなっているのではないかと思います。にもかかわらず、ビジネス側からITへの期待は飛躍的に増大しており、システムのパフォーマンスや可用性を維持するだけでも、とても大変なタスクとなっているのではないでしょうか。

こういった状況はIT先進国であるアメリカでも当然発生しており、その中でのベストプラクティスとして4つのゴールデンシグナルというものが定められました。具体的には、レイテンシー、トラフィック、エラー、サチュレーションです。これが一定以上の水準である場合にシステムは「健全」と判断されます。この4つのゴールデンシグナルをIT運用側と開発側の共通認識とすることで、「何が起きているか」「どうするべきか」 の議論をより建設的に行えるようになり、双方のチームの連携を強化できます。その議論の結果がすべて、高いパフォーマンスと可用性といった、カスタマーエクスペリエンスを守るための重要なポイントです。

以下「SRE Metrics: Four Golden Signals of Monitoring」の抄訳になりますが、従来のシステムを新しくすることは非常に手間がかかります。まずは監視のあり方、監視のツールに新しい要素を取り入れて、いわゆるオブザーバビリティを高めることは、DXを支えるIT部門の新しい取り組みとして非常に有益ではないかと考えています。

SREとは

SRE (サイトリライアビリティエンジニアリング)とは、ソフトウェアエンジニアリングチームやIT運用チームがより信頼性の高いサービスをプロアクティブに構築および管理するための方法論です。SREは、IT運用の問題にソフトウェア開発の解決策を適用するための具体的な方法を提供します。サイトリライアビリティエンジニアの役割は、開発スピードを落とすことなくサービスのレジリエンス(回復力)を向上させることができるよう、IT監視からソフトウェアデリバリー、インシデント対応まで、本番環境のすべてを構築および監視することです。

一般的にSREは、開発チームとIT運用チームの関係を強化するための、高度に統合された手法として使用されます。SREの最大の役割は、システム全体のレジリエンスを向上させ、すべてのアプリケーションとインフラで運用されるサービスの健全性とパフォーマンスを可視化することです。サイトリライアビリティエンジニアは、作業をコード化することで、サービスのレジリエンスと柔軟性を向上させることができます。また、DevOpsチームやビジネスチームと情報を共有することで、業務やワークフローの可視化とコラボレーションを重視する協調的な文化を築くことができます。

SRE誕生までのITシステムの管理や監視

従来のサービス管理アプローチ ITSM

ITサービス管理(ITSM)の考え方は、コンピューターが誕生した頃からありました。システム管理者は当時、ソフトウェアコンポーネントの組み立てから導入、インシデントへの対応まで、すべてのプロセスを担っていました。その後、パーソナルコンピューターが登場したことで、IT担当者は、アプリケーションやインフラを確実に管理するための普遍的な原則を定義する必要に迫られます。

コンピューターの普及とともに主流となったガイドラインがITIL (IT Infrastructure Library)です。ITILには、IT運用のあらゆる面に関する規則がまとめられています。その中に定義された「ソフトウェア開発者はコードを記述してシステム管理者に引き渡し、システム管理者がサービスの設定と導入を行う」という規則は、当面はうまく機能しました。しかし、その分業体制はソフトウェア開発者とシステム管理者の間に自然と壁を作ることになりました。

その後、インターネットの普及や高度に統合された複雑なシステムの誕生とともに、アジャイルなソフトウェア開発手法やCI/CDの導入が必要になりました。また、いつでも利用できるサービスを迅速に提供するために、ITサービス管理の方法にも変化が求められるようになりました。

DevOpsの登場

開発とリリースのプラクティスの変化に対応して、DevOpsの考え方が誕生しました。DevOpsでは、フィードバックループを促進し、ソフトウェア開発チームとIT運用チーム間のコラボレーションを強化することを重視します。DevOpsの方法論によると、IT運用チームはソフトウェアデリバリーライフサイクルの早い段階から関与し、開発者は本番環境のサービスに対してより多くの責任を担います。また、アプリケーションやインフラのテストを自動化し、開発ライフサイクル全体をより密接に統合します。さらに、開発者は自身が開発したサービスのオンコールの責任を担います。 

複雑化するアプリケーションとクラウドインフラをより迅速に提供するには、信頼性の問題にもプロアクティブに対処する必要があります。そしてそのことが、最新のSREプラクティス誕生のきっかけになりました。

SREの誕生

SREの方法論はGoogle社で生まれました。同社は当時、IT中心の組織に転換して、エンジニアリングからセールスまで、社内の連携を強化する必要に迫られていました。このビジョンを実現するための道を拓いたのがSREです。Google社でエンジニアリング担当VPを務めるBen Treynor氏は、SREを次のように定義しています。

基本的には、ソフトウェアエンジニアに運用業務の設計を任せたときに起きることです。- Google社によるBen Treynor氏へのインタビュー

Google社は、これまで手動で解決していた問題をソフトウェアの問題として扱うことに決め、正式なSREチームを編成して、ソフトウェア開発の専門知識を従来のIT運用の問題に適用する取り組みを始めました。開発者が運用の改善を目標に掲げ、手動で行っていた多くのタスクとテストの自動化、システムの健全性の可視化、IT運用チームとエンジニアリングチーム間のコラボレーションの強化に注力した結果、開発スピードを維持したままサービスの信頼性を向上させることができるようになりました。

SREを実現するための重要な要素や中核業務

システムの総コストの40～90%はデプロイ後に発生します。- Google社のSREブック

開発プロセスの改善には多くのDevOpsチームやIT運用チームが熱心に取り組みますが、本番環境のシステムを気に掛けるチームはあまりありません。しかし、アプリケーションやインフラのコストのほとんどはデプロイ後に発生します。開発チームが現行のサービスのサポートにもっと時間を費やす必要があることは明らかです。開発スピードを落とさずにサポートの時間を確保するには、開発者によるSREチームを編成し、本番システムの信頼性を継続的に改善することを任務として割り当てる必要があります。

一般的にSREチームの中核業務は以下のカテゴリに分類されます。

1) 可用性

基盤となるサービスについて、サービスレベルの目標(SLO)、契約(SLA)、指標(SLI)を設定します。まずは、顧客がシステムに期待するサービスレベルの具体的な測定単位をSLIとして定義します。次に、各SLIについて、システムに期待される目標(99.99%の可用性など)をSLOとして設定します。最後に、SLOに基づいて、顧客が使用するサービスの信頼性目標とその目標が達成されなかった場合の対応を明記した契約書をSLAとして作成し、顧客と合意します。

• 社内チーム、顧客、その他の外部関係者は何を期待しているか？

• 多くの組織はサービス全体で何を重視しているか？

• 99.999%の可用性は本当に必要か？

こうした質問を用意して、SREチームによるSLO、SLA、SLIの初期設定の方法を形式化すれば、新しい機能やサービスの信頼性を高め、リリースを迅速化するために役立ちます。

SREチームに余裕ができて、本番環境の改善により多くの時間を費やせるようになれば、エンジニアリングチームもアーキテクチャの信頼性向上に目を向け始め、フェイルオーバーオプションの追加やロールバック機能の高速化に取り組むようになります。そうなれば、顧客や関係者の期待をより高く設定し、優れたSLO、SLA、SLIを作成してビジネス価値の向上につなげることができます。より大規模な開発チームやIT運用チームがリリースパイプラインの一貫性を維持する責任を持つのに対して、SREチームの役割は、本番環境でのサービスの全体的な可用性を維持することです。

2) パフォーマンス

SREチームの成熟度が上がり、可用性が安定してくると、サービスのパフォーマンスメトリクス(遅延、ページの読み込み速度、ETLなど)の改善に注目するようになります。

• 障害がよく発生するサービスやノードはどれか？

• 顧客側で常にページの読み込みや応答の遅延が発生していないか？

パフォーマンスの問題が全体的な可用性に影響を与えていない場合でも、その問題が顧客側で頻繁に発生すれば、顧客は不満を持ち、サービスの使用を止めてしまう可能性もあります。

SREチームは、アプリケーションのサポートや開発チームによるバグ修正だけでなく、システム全体のパフォーマンスの問題を未然に察知することも求められます。問題が軽微であっても、時間とともに悪化して、顧客に大きな影響を及ぼす場合もあります。サービス全体の信頼性を高めるには、ある程度時間を割いてパフォーマンスに関する軽微な問題を特定し、修正する必要があります。

3) 監視

パフォーマンスの問題を特定してサービスの可用性を維持するには、SREチームがシステムの状況をリアルタイムで把握する必要があります。そうなると当然、監視ソリューションの導入という大仕事をSREチームが担うことになります。さまざまなサービスのパフォーマンスと稼働時間を測定しなければならないため、何をどのように監視すれば効果的かはSREエンジニアにとって頭の痛い問題です。

重要なのは、システムの健全性を包括的に把握することが監視の目標である点です。エンジニアリングチームやIT運用チームのメンバーが、担当するサービスの全体的なパフォーマンスと可用性を単一のソースで確認できるようにすることが大切です。

サービスの違いを超えたチーム横断的な可視化を実現するために誕生したのが、SREのゴールデンシグナルです。ゴールデンシグナルは、DevOpsチームやIT運用チームにとって効果的な監視とアラート生成を実現する基盤となります。SREに重要な監視の4つのゴールデンシグナルの概要と、これがサービスの信頼性を確立する基盤として重要である理由については、後ほど詳しく説明します。

4) 環境の整備

監視、インシデント対応、サービスの可用性とパフォーマンスの最適化の改善に継続的に取り組めば、システムのレジリエンスは自然に向上します。SREチームの仕事は最終的に、エンジニアリングチームやIT運用チームがより効率的に作業できる環境を整備することです。SREチームが提供する監視リソースを活用することで、開発チームやIT運用チームが新しいサービスを迅速にデプロイし、インシデントに数秒以内に対応できるようになります。

適切な環境が整備されていれば、管理するサービスの健全性を把握し、問題が起きたときに対応方法をすばやく特定できます。SREエンジニアがエンジニアリングチームやIT運用チームと連携すれば、開発者が本番環境に触れる機会が増え、IT運用担当者がソフトウェア開発ライフサイクルのより早い段階から関与できるようになります。一方で組織は、SREチームによって信頼性に関する問題の対応に必要な手段と状況把握能力を確保できます。リアクティブなSREチームは単に問題に対応して修正するだけですが、プロアクティブなSREチームは個々のチームメンバーがシステムのレジリエンス強化に積極的に取り組みます。

SREの重要な要素を効果的に実践するには、システム内のすべてのサービスとアプリケーションを可視化して透明性を高める必要があります。しかし、異なるサービスのパフォーマンスと可用性を一元的に測定することは容易ではありません。そこで、Google社のSREチームは、すべてのアプリケーションとインフラでサービスの健全性を一貫して追跡するための4つのゴールデンシグナルを定めました。

SREの4つのゴールデンシグナルとは

SREの4つのゴールデンシグナルには、レイテンシー、トラフィック、エラー、サチュレーションがあり、システムが「健全」であると判断する基準を定義します。各メトリクスについて、システムが健全であることを示すベンチマークを確立することで、十分なカスタマーエクスペリエンスと稼働時間を確保できます。システムではほかにも多くのメトリクスやログを監視しているかもしれませんが、この4つのゴールデンシグナルは効果的な監視戦略に欠かせない基本要素です。

レイテンシー

(リクエストの処理にかかる時間)

「健全」と判断するレイテンシー率のベンチマークを定めます。その上で、成功したリクエストと失敗したリクエストを区別してレイテンシーを監視し、健全性を追跡します。システム全体でレイテンシーを監視することで、パフォーマンスが悪いサービスを特定し、インシデントを迅速に検出できます。また、エラーのレイテンシーを測定すれば、インシデントを特定するまでの時間を短縮し、迅速にインシデント対応に取り掛かることができます。

トラフィック

(システムに対する要求の負荷)

サービスで処理されるユーザーまたはトランザクションが一定時間にシステムに与える負荷を示します。何をトラフィックと定義するかは組織によって大きく異なります。たとえば、一定時間内にサイトに訪問したユーザー数や受け取ったリクエスト数などが考えられます。アプリケーションやサービスで発生する実際のユーザーとの通信とトラフィックを監視することにより、ユーザー視点でエクスペリエンスを把握し、システムが需要の変化にどの程度対応しているかを測定できます。

エラー

(リクエストの失敗率)

エラーの発生率は、システム全体だけでなく、個々のサービスレベルでも監視する必要があります。また、手動で定義したロジックに起因するエラーと、HTTPリクエストの失敗のような明示的なエラーの両方を監視する必要もあります。エラーの重大度を定義することも重要です。どのエラーが重大で、どのエラーがリスクが低いかを明確にすれば、サービスについてユーザー視点で健全性を把握し、頻発するエラーにすばやく対応して修正できます。

サチュレーション

(サービスの全体的なキャパシティ)

サチュレーションは、システムの使用率を包括的に示します。サービスのキャパシティにどのくらい余裕があり、どのような場合にピークに達するかを把握できます。通常は、使用率が100%に達する前にパフォーマンスが低下し始めるため、「健全」な使用率のベンチマークを確立することも重要です。サービスのサチュレーションがどの程度であれば、顧客に影響が及ばないだけのパフォーマンスと可用性を確保できるかを検討します。

サービス監視による対応

インシデント管理ライフサイクルにおけるSREの4つのゴールデンシグナル

4つのゴールデンシグナルは、効果的な監視を始める際の基準として最適です。すべてのサービスのレイテンシー、トラフィック、エラー、サチュレーションをほぼリアルタイムで追跡すれば、問題の迅速な特定につながります。また、どのチームが管理しているかに関係なくすべてのサービスの健全性を一元的に可視化することもできます。機能やサービスごとに監視するのではなく、すべての監視メトリクスとログを1カ所に統合できます。

効果的に監視できれば、インシデント管理だけでなく、インシデントライフサイクル全体を継続的に改善できます。

SREでDevOpsのマインドセットを促進

SREエンジニアがシステムのさまざまな側面に関与することで、開発チームとIT運用チーム間のコラボレーションが自然と強化されます。SREを通じてDevOpsのマインドセットを促進することは、チームの生産性とシステムのレジリエンスの大幅な向上につながります。インシデントが発生したときは、SREチームが率先して対処方法に関する透明性の高い議論を促すことで、開発チームとIT運用チームとの摩擦を解消できます。SREは、効率的で信頼性の高いソフトウェア開発プラクティスを維持し、本番環境でIT運用チームが担う責任を一部負担するという重要な役割を担います。さらに詳しく知りたい方は、DevOpsに関するカンファレンスやイベントにぜひご参加ください。

SREと監視の4つのゴールデンシグナルを導入すれば、チーム横断的な可視化とコラボレーションを実現し、IT運用チームと開発チーム間の連携を強化できます。SREの4つのゴールデンシグナルを活用して建設的なエンジニアリング文化を醸成し、カスタマーエクスペリエンスを向上させている組織はすでにあります。皆さんもすぐにこの取り組みを始めましょう。

What is Splunk? (Splunkとは)

これは私独自の記事であり、必ずしもSplunkの姿勢、戦略、見解を代弁するものではありません。

関連記事：CI/CDツールとDevOpsの関係とは？Jenkinsの導入まで解説します

----------------------------------------------------
Thanks!
加藤 教克