SREを実践する

サイト信頼性エンジニアリング（SRE）は、新しい用語でも実践手法でもありません。ソフトウェアエンジニアリングのスキルと原則を運用上の問題と作業に適用することは、「サイト信頼性エンジニア」という職名が定義される以前から行われていました。ソフトウェアの構築と維持に対する積極的なアプローチを体系化することで、運用効率、データ駆動型ロードマップの計画策定、一般的な稼働時間、信頼性の向上における長期的成功が促進されます。SREがこれほど広く導入されている理由は、これらのメリットによるものです。

このブログでは、サイト信頼性エンジニアリングを習得するには何が必要か、自社にそれをどのように導入するべきか、そしてSREの成熟へ向けた歩みで前進して行く際に念頭に置くべきコア原則とベストプラクティスについて詳しく見てゆきます。

SREとは何か?

SRE、すなわちサイト信頼性エンジニアリングとは、DevOpsと運用上の問題にソフトウェアエンジニアリングの専門知識を適用する実践手法です。多くの場合、これは信頼性とパフォーマンス上の課題を解決するために、積極的にコードを書いたり、社内のアプリケーションやサービスを開発したりすることを意味します。SREは長年行われてきたことですが、2016年3月にGoogleがSite Reliability Engineering: How Google Runs Production Systemsを出版したことで、近年さらに広く普及するようになっています。

SREという頭字語は、職名であるサイト信頼性エンジニア(site reliability engineer)と、開発およびITチームが導入する一般的実践手法であるサイト信頼性エンジニアリング(site reliability engineering)の両方を指すため、紛らわしいものとなっています。

SREチームの編成は、多くの場合、組織やサポートするサービスによって異なります。サイト信頼性エンジニア(SRE)が、開発チームに分散して配属されている場合もあります。これは、ロードマップ計画策定中に懸念事項を率直に指摘し、QAチームと密接に仕事することで、機能の導入からプロダクション環境の管理をステージングすることに至るまで、あらゆる面で協力できるようになることを意味します。

別のアプローチでは、SREチームは独立したグループとして編成されます。SREチームは全体において、アプリケーションとインフラストラクチャーのモニタリング、信頼性メトリクスの規定、新しいリリースに伴う問題の追跡、即時対応するための待機などの責任事項に注力します。どのような形で組織されている場合も、全てのSREに共通するのは信頼性とパフォーマンスへの取り組みです。

DevOps vs. SRE

DevOpsの実践手法が急速に導入されたことで、「SREはDevOpsと何が違うのか？」と疑問に思うかもしれません。通常、これら2つの言葉は一緒に使われます。SREの実践手法は必ずしもDevOpsの文化および導入の一部となる必要はありませんが、多くの場合、DevOps導入の歩みが進んでいる会社ではSREが導入されています。DevOps成熟度モデルで成熟度が高ければ高いほど、SREの実践手法を導入している可能性が高くなります。

検討すべき重要なことは「SRE vs. DevOps」ではありません。重要なのは、DevOpsの実践手法を強化するために、いかにして積極的なSREチームと運用モデルを確立するかを話し合うということです。SREのフレームワークを開発チームとITチームに統合させるか、SREを独立したビジネスユニットにするかにかかわらず、その一般的な責任事項を理解する必要があります。

SREチームの責任事項

サイト信頼性エンジニアは、アプリケーション、サービス、インフラストラクチャーについて語る際に、 パフォーマンスと信頼性が厳密に何を意味するかを定義する必要があります。日常業務では、新しいモニタリングソリューションのインストゥルメントから、技術サポートチームのためにカスタマイズされたアプリケーションの構築まで多岐にわたります。バグを修正するために新しいコードを送ったり、新しい機能を供給したり、もしくは、リアルタイムでインシデントに対応したり、望ましい顧客体験を提供するためにサポートチームと密接に協力したりする場合があります。

サイト信頼性エンジニアは、顧客にとってプロダクトの実際の使い勝手がどのようなものか、顧客の視点からシステムのパフォーマンスと信頼性をどのように追跡するかを正確に理解するうえで鍵となるチームです。SREチームは、開発チームが提供したものと顧客が体験していることの間のどこにサービス境界があるのかを、正確に見極める必要があります。それを踏まえたうえで、内部チームが積極的にリスクを明らかにし、より良いソフトウェアを提供するのを支援するような形で、信頼性とパフォーマンスに関する懸念事項をモニターする方法を見つけなければなりません。

SREチームは、信頼性の定義が全社共通のものとなるよう、全てのプロダクトと開発チームに知識を広めます。全員の理解が一致していることで、新しい機能をリリースしたりプロダクションにおける現在の経験を改善したりする際、エンジニアリングチームはデータドリブンな決定ができるようになります。

サイト信頼性エンジニアリングの原則および実践手法

大まかに言うと、GoogleはSREの原則と実践手法のコアを「リスクを包含する」能力と定義しています。サイト信頼性エンジニアは、継続的イノベーションに対する会社のニーズと、プロダクション環境における信頼性とパフォーマンスを伴う新しいソフトウェアを提供することのバランスを図ります。たとえば、顧客に影響が及ばない場合、サービスの中で重要度が低い部分は99.999%の稼働時間は必要ないかもしれません。信頼性に関する取り組みのためにソフトウェアの提供ライフサイクルが大幅に遅れるにもかかわらず、顧客の視点から分かるほどサービスが改善されないのであれば、それは時間のムダになります。

SREとDevOpsはともに、相互に相反する場合がある開発チームと運用チームのニーズのバランスを図るうえで役立つので、SREの実践手法はDevOpsの導入が進むのに伴い拡大します。サイト信頼性エンジニアは、パフォーマンスと信頼性を改善するために CI/CD（継続的インテグレーション/継続的デリバリー）およびソフトウェアの提供ワークフローにプロセスを挿入しますが、どの時点でスピードのために安定性を犠牲にすべきかを知っています。SREは、DevOpsチームと密接に協働し、アプリケーションとインフラストラクチャーにおける重要なコンポーネントを理解することで、重要性の低いコンポーネントについても知ることができます。

全てのチームにアプリケーションとシステムの健全性に関する透明性を提供することは、サイト信頼性エンジニアが、安心して受容できるリスクレベルを見定めるうえで役立ちます。望ましいサービス可用性と、合理的観点から許容可能なパフォーマンス上の問題のレベルは、サポート対象となるサービスのタイプによっても異なります。SREの原則と実践手法は、進んで実験を受け容れ、サポート対象となるサービスの健全性を積極的に理解するための献身的取り組みを必要とします。

SREの運用および成熟度モデル

サイト信頼性エンジニアに求められる多くの責任事項を果たしながら、依然としてソフトウェアエンジニアという職名を持っている場合があります。では、自社のサイト信頼性エンジニアのプラクティスがどの程度成熟しているかは、どうしたら分かるのでしょう？効果的なSRE運用モデルを構築し、それに照らした成熟度を追跡するための簡単な方法を説明するので心配はいりません。

通常、SRE運用モデルには3つの要素が含まれ、以下のフェーズを通して達成できます。

1. SER実践手法に特化したチーム（または、少なくとも一人）
2. プロダクト、開発、運用の全てのチームにおける深いインテグレーションと影響力
3. アプリケーションまたはシステムのほぼ全ての部分について、ワークフローを自動化しコードを書くうえでの自律性

SREの成熟度は、SRE運用モデルのこれら3つの構成要素について自社がどの段階にあるかによって決まります。SREチームを結成するステップを踏み出した、または最初のサイト信頼性エンジニアを雇用したばかりであれば、SREの歩みを始めた段階です。すでにチームがあり、ロードマップの議論、QA、デプロイメントのワークフロー、インシデント管理プロセスで重要な役割を果たしているのであれば、SREの実践手法はある程度成熟しています。

SREビジネスユニットが、ワークフローの自動化、アプリケーションの構築、独自のモニタリングおよびアラート用ソリューションについて自律性をもっている、または、ほぼ全ての議論に参加するようになり、会社は初めて完全なSRE成熟度に達したことになります。あらかじめパフォーマンスと信頼性に関する懸念事項を率直に指摘し、それについて積極的に話し合うことは、遅すぎる段階まで無視し続けるより、常に望ましいことです。

モニタリング、CI/CD、組織の自動化

サイト信頼性エンジニアは、実質的に全てのことを自動化でき、また自動化してゆきます。問題を積極的に検出、修正、解決できるのであれば、それは自動化しなければなりません。SREには、継続的なインテグレーションや提供からプロダクション環境のモニタリングに至るまでの事柄について、一定の可視性がなければなりません。パフォーマンスと信頼性の問題を積極的に発見する方法を明らかにできた場合は、その変更を導入する権限がなければなりません。

自動化、モニタリング、人工知能、機械学習に関する近年のDevOpsおよびIT の機能により、SREチームは問題の特定、報告、是正に際し、大きな優位性が得られます。DevOpsおよびSREの実践手法が成熟している会社は、ステージングの段階で問題を見つけられるとともに、自動化されたインシデント管理ワークフローと自己修正システムを構築できます。SREは、アプリケーションとインフラストラクチャーにおける重要なコンポーネントを明らかにすることで、重大な問題をもたらしかねない事柄の対象範囲を狭めることができます。

サービスレベルの実践（SLI、SLO、SLA）

サービスレベルは、SREチームが全ての関係者に対し、デジタルプロダクトとサービスの本当の健全性を伝えるための役割を果たします。これは、望ましい顧客体験を実現するうえで鍵となる重要なコンポーネントを特定し測定することて実現されます。特にSREチームと信頼性エンジニアは、一つまたは複数のコンポーネントが、どの時点で外部の顧客に直接機能を提供するのかを知る必要があります。こうした共通領域はシステム境界と呼ばれています。システム境界とは、サイトの信頼性エンジニアがシステムのパフォーマンスと信頼性に関する本当の状況を知るために、自分のメトリクスにサービスレベル指標と目標を適用する必要がある場所です。

• サービスレベル指標（SLI）とは、システムの可用性を特定するための主要な測定値です。
• サービスレベル目標（SLO）とは、システムから期待される可用性に関して設定した目標です。
• サービスレベル契約（SLA）とは、システムがSLOを満たさなかった場合の対応を説明した法的契約です。

SREは必ずしも常にサービスレベルの管理責任を担うわけではありませんが、それは、往々にして彼らの管轄下に置かれることになります。SLIを追跡しSLOと結び付けることにより、システムのパフォーマンスに関する目標を設定できるようになります。GoogleのSREブックでは、サービスレベルの4つのゴールデン・シグナル を、レイテンシ、トラフィック、エラー、サチュレーション（飽和）と定義しています。そのため、たとえばAPIコールをチェックし、成功/不成功のリクエストの数（SLI）を、顧客が良好な体験を得るために必要とされる一般的な成功リクエストのパーセンテージと比較して追跡することができます。

SREチームは、顧客とどのくらい厳しいSLAに合意できるかに関する理解を深めるため、しばしば自分達のアプリケーションとサービス内で、重要なコンポーネントに対して厳しいSLOを設定します。ここでチームは、SLOに違反しないためには、どのくらい迅速に問題を解決する必要があるかを理解する方法として、エラーバジェットを適用できます。サービスレベルがあると、チームはメトリクスを集計し、組織全体を対象にアップタイム、パフォーマンス、信頼性に関する透明性のあるビューを取得できます。ビジネスリーダーたちはサービスレベルを利用すれば、複数のチーム、アプリケーション、サービスなどを対象に、一目でコンプライアンスの状況をモニターし、システムの健全性に関する包括的理解を得ることができます。

SREのベストプラクティスの導入に向けて

SREのベストプラクティスと原則は、一夜にして導入することはできません。パフォーマンスと信頼性に関する懸念事項についてチームとシステムを積極的にモニターできるようになるには、時間と努力が必要です。しかし最終的に、DevOpsと特に顧客は、サイト信頼性エンジニアリングの活用を決定したことを感謝してくれるでしょう。