ユーザーの幸福度を定量化――SLI、SLO実践の4ステップ：SREの文化を組織にどう定着させるか

SREは計測、自動化など取り組むことが多く、求められる知識量も少なくない。また周囲の理解が得られなければ、組織でSLI、SLOを定義してSREを実践するのも容易ではない。組織でSREに取り組む最初の一歩をどう踏み出せばいいのか。

[タンクフル，＠IT]

　企業がITを通じて新たな価値を提供することが必須要件となる中、顧客接点となるアプリケーションやサービスの重要性はさらに高まっている。価値提供を通じて競合優位性を保つには、新たなアプリケーションや機能の開発はもちろん、注目を集める「クラウドネイティブ技術」などを試していくことが不可欠だ。だが、その裏ではアプリケーションやサービスの安定稼働も求められる。

　つまり、組織には新しい変化への取り組みが評価される開発者と、安定稼働を実現することで評価される運用管理者が存在する。相反する目標を持つ開発者や運用管理者に対し、「DevOps」という考え方も広まったが、実際にどう意思決定を進めればいいのか。

　そこで注目されてきたのが、アプリケーションの信頼性を保証することを目標とし、可観測性を高めたり、サービスの堅牢（けんろう）性を高めたりするために取り組むSRE（Site Reliability Engineer／Site Reliability Engineering）だ。

　2020年1月に開かれた「SRE NEXT 2020」に登壇したQuipperの近藤健司氏（@chaspy_）は、「SLI（Service Level Indicator）とSLO（Service Level Objective）を定義してSREを実践するには、組織やプロジェクトメンバーの理解が不可欠だ」と話す。近藤氏は、なぜSREが重要視されているのかをあらためて振り返りつつ、開発者を含むプロダクトチームに、SLI、SLO、エラーバジェットの考え方を浸透させていった方法や、その取り組みの中でどのような失敗を経験してきたのか紹介した。

今さら聞けないSLI、SLO、エラーバジェットの基本――なぜエラーを許容するのか

　近藤氏は冒頭、SLI、SLO、エラーバジェットの基本に立ち返り、これらが求められる理由を説明した。

　SLIとはサービスの信頼度を定量化する指標、数値のことだ。SLOとは端的に言うと目標のことだ。例えば、「アプリケーションのリクエスト成功率」（http success rate）をSLIとした場合、SLOはリクエスト成功率の目標を示す。Webアプリケーションやサービスの利用者から送信されたHTTPリクエストに対し、成功を示す「2xx」が返されたのか、サーバエラーを示す「5xx」が返されたのか、その割合を求めることでSLIとSLOを計測できる。

　1万回の「2xx」と5回の「5xx」が計測されたと仮定すると、SLIは「99.95％」（エラー率は0.05％）になる。SLOを99.9％としていた場合、あと5回分の「5xx」のリクエストが発生するとSLIはSLOを下回る。視点を変えれば、あと5回分の「5xx」を許容できる。これがエラーバジェット（エラー予算）の考え方だ。エラーバジェットとは、SLIとSLOを基にエラーの発生を許容するという概念だ。

Datadogが定義する「Event Based SLO」と「Monitor Based SLO」だと前者のEvent Based SLOに分類される（出典：近藤氏の発表資料）

Quipper Site Reliability Engineer 近藤健司氏

　SLIやSLOを基にエラーの発生を許容することで、開発者はエラーバジェットの制約の中で新たなアプリケーションや新機能を開発する自由を得られる。運用管理者はエラーバジェットを基に「安定稼働」を具体化することで開発者に自由を与えることができる。

　「俊敏性を持って新しい機能を実装したい開発者と、障害リスクを減らしたい運用管理者が対立してきた。それを解決するために『DevOps』という考え方が生まれた。信頼性と俊敏性、どちらに投資するかは、SLI、SLO、エラーバジェットといったファクトベースの意思決定が必要だ」（近藤氏）

「マイクロサービスアーキテクチャではSLI、SLOが不可欠」

　さらに、近藤氏は「マイクロサービスアーキテクチャにおいてSLI、SLOは必要不可欠なものになってきている」と説明を続けた。

　マイクロサービスアーキテクチャを採用すると、アプリケーションの可用性は機能ごとに分割された各サービスから影響を受ける。分割された各サービスのSLOが定義されていなければ、アプリケーション全体のSLIとSLOを定義することが難しくなってしまう。

　「どこでどのように計測するかも重要だ。クライアントサイドからデータストアまで複数の選択肢がある。計測する範囲に限界があるため、どのメトリクスを収集していればアプリケーションの信頼度を計測できるかという視点で考える必要もあるだろう」（近藤氏）

組織にSLIとSLOの考え方を浸透させる4ステップ

　Quipperは「Self-Contained（自己完結化）」をテーマに、開発チームの意思決定だけでプロダクト開発、運用ができる世界を目指している。そして、SREが開発チームを支援するポジションになることを目指しているという。

　同社のSREチームは以前から自己完結化に近いテーマに取り組んできた。2019年1月に、同社が提供するWebサービスのマイクロサービス化を見越して、サービス基盤をKubernetesに移行。また2019年3月にはSREが信頼性の観点で開発者の実装内容を評価する「Production Readiness Checklist」を策定した。その後、開発チームに対しインフラ構築自動化ツール「Terraform」の管理移譲も実施した。

　SREがSLIとSLOを定義してレビューするため、以下の4ステップで徐々に進めていくことにしたという。

1. システムと組織をひも付け、Ownershipを決める。
2. 1人でプロセスを回してみて、実現方法を確立する
3. Developerと一緒にSLIとSLOを定義し、プロセスを回す
4. 「Error Budget Policy」を定義して全員が従う

　「この4つのステップを策定したのは、SLIとSLOが良さそうなことは分かっていても何をすれば良いのか、何が正解なのか分からないからだ。定義した数値自体、本当にユーザーの幸福度を表しているのか分からない。正確でない限り、SREが『Error Budget Policyに基づいてリリースを止めて』と開発チームに指示しても説得力はない。こうした状況で合意形成は難しいと考え、段階的に取り入れようと判断した」（近藤氏）

　近藤氏は15個のプロダクトチームに対して、SLIとSLOをレクチャーし、チーム自身で運用してもらうことを最終的なゴールとして取り組んだという。

1人で始めた段階ではアラートを記録するシステムがなかったため、SlackやGitHubのIssue、Datadogを活用しながら簡易的なシステムを作り試行錯誤したという（出典：近藤氏の発表資料）

　「最初に悩むのが『SLIとSLOはどのくらいの値が適切？』ということだ。こうした取り組みを始めたことで、1週間で1.6時間もエラーを許容する『99.0％』は低すぎるが、『99.99％』は、1週間で約1分のみのエラーしか許容しないのは高すぎるため、『99.9％』で初めてみるのが良いだろうという感覚を得ることもできた」（近藤氏）

　とくに、SLIとSLOを定義して定期的にレビューを繰り返すことは良い習慣だと近藤氏は気付いたという。

　「SLIとSLOを定期的にレビューすることも良いと感じた。実は計測すべきだったが計測できていないメトリクスがあることにも気が付けた。継続的にレビューをすることで、『メトリクスを計測しよう』というモチベーションも高められる」（近藤氏）

DoS攻撃対策が信頼度計測を阻害――取り組んで分かった課題

　一方で、SLIとSLOを定義して信頼度の計測に取り組んだ結果、信頼性を阻害する要因が存在することに気付いたという。例えば、SLIとしてWebサーバのNginxが出力する「http success rate」を採用した結果、短期間で大量のリクエストがあった際に503エラーを返却するDoS攻撃対策の機能が、計測のノイズになると分かった。

　「HTTPのステータスコードをSLIとして用いている状況で、DoS攻撃が発生して大量の503エラーが発生した場合、サービスの信頼度が落ちたかのように見えてしまう。だがDoS攻撃対策はサービスの信頼度を守るために存在するものだ。DoS攻撃対策で返すステータスコードの変更のために、オープンソースソフトウェア（OSS）の機能自体に変更を加える必要があるなど苦労した」（近藤氏）

　また同一ドメインの中に別々のチームが存在していた場合、信頼度の問題が発生した際にどのチームが作業をすべきか判断に困るケースがあったという。

　「メトリクスを収集する際に識別子を付与するなど、SLIを計測する上で不足している部分を追加していった。またマイクロサービスのサービス間通信に関するメトリクスが一切取れていないという課題があり、『Envoy Proxy』を経由させることでメトリクスを収集できるようにした」（近藤氏）

各サービス間の可観測性を高めるためにEnvoy Proxyを導入（出典：近藤氏の発表資料）

SLI／SLOの実践を検討する企業へのアドバイス

　アプリケーションの信頼性を保証するため、SREは運用監視、セキュリティ、自動化などさまざまな取り組みを進める必要がある。SREを組織に取り入れることは容易ではない。だが、先述したようにマイクロサービスアーキテクチャのようなクラウドネイティブ技術が注目される中で、SREという役割は重要さを増している。

　「SREの実践は開発や運用のプロセスを変える取り組みになる。当然だが、ドキュメントの整備やコミュニケーションも不可欠だ。今回の取り組みを通じて、一度定義したSLIやSLOを定期的に見直すことも価値があると実感した。レビュー後も『完璧ではないこと』を前提に取り組みを続けていくことでSLIやSLOを定義することがチームの常識になっていく」（近藤氏）

　近藤氏は「プロダクトチーム自身にSLIやSLOを定義してもらうのが一番良いが、SREがSLIやSLOのテンプレートを用意すべきだ」とし、講演を締めくくった。

　「現実としてインフラ面でどのようなメトリクスが計測できているかはプロダクトチームで認識できていないケースも少なくない。SREがSLIやSLOを定義したり実装したりして開発者に共有した方が良いと感じる。すでに計測できている可用性やレイテンシで取りあえず始めてみて、できていないことをリスト化する。さらに、SLIとSLOを定期的にレビューして定義を変えていくなら指標をコード化することも役に立つだろう」（近藤氏）

特集：「DevSecOps」を支えるSRE

ユーザーに素早く価値を提供しつつセキュアなサービスを運用していく上では「DevSecOps」の考え方が欠かせない。そのような中でGoogleが実践、提唱している「Site Reliability Engineering」（SRE）という役割の導入が、Webテクノロジー企業の間で進んでいる。サービスの信頼性向上をミッションとして改善を行うSREにサービスのセキュリティ部分を担当させる動きもある。一方で、限られたリソースの中でSREを実践することは容易ではない。SREが成果を果たすためには、複数の目標／方針を定め、インシデント対応はもちろん、ロギング、サービス監視、インフラのコード化、運用自動化など並行して取り組んでいく必要があるためだ。日常業務に加えて、自動化に向けた取り組み、そして企業によってはセキュリティへの対応などすべきことは多い。SREを実践している企業は、SREの考え方をどうデザインして実践し、SRE実践に当たって抱えた課題にどう取り組んでいるのか。インタビューや事例を通じて俯瞰（ふかん）してみよう。

特集：「DevSecOps」実現を支えるSRE