VisasQ Dev Blog

ビザスク開発ブログ

SLO Adoption (SLOの導入) を進めてどうなったか?

こんにちは。今年の8月にSREチームにjoinした西川です。

ビザスクでは、今年の春頃からDatadogを用いた監視環境の整備と開発チームへのSLI/SLOの導入を進めています。
本記事では、SLI/SLOの導入をどのように進めてきたか、導入する中での気付きと今後の課題について紹介させていただきます。SLI/SLOの導入を進める方のお役に立てば幸いです。

SLI / SLOに関する詳細な説明は省略しますが、下記の定義を基に話を進めていきます。

SLI: サービスの品質を測定するための指標
SLO: 各SLIに対する目標値

ちなみに、ブログタイトルのSLO Adoptionは「SLO Adoption and Usage in SRE」という本のタイトルからお借りしています。
(無料公開されており、下記のリンクからpdfで見ることができます)

https://sre.google/resources/practices-and-processes/slo-adoption-and-usage/

SLI/SLO 導入前の課題

最初に、SLI/SLOの導入の背景について説明します。

ビザスク はSLI/SLO導入前の段階で、 1.サービス品質の管理 2.機能追加とサービスの信頼性維持のバランス に関する課題を抱えていました。

サービス品質の管理に関して、サービスのモニタリング自体は行っていましたが、「サービスの品質を表現する」指標は設定していない状況でした。
そのため、 発生したエラーに対してアプリケーションの改修などで対応するといった個別の対応がメインになっており、サービス全体の品質観点での対応が進みにくいことが懸念点として挙がっていました。

また、機能追加と信頼性のバランスに関してはリリース直後はモニタリング体制を強化するなどの対応はしていたものの、機能追加と信頼性のバランスを定量的な指標をトラッキングしたサービス開発はできていませんでした。
そのため、1週間などのタイムスパンで見た時に最適なバランスで開発が行われているのかは判断できない状態でした。

SLO Adoption について

上記のような課題や問題意識を背景に、SREチームでは今年からDatadogを用いた監視環境の整備とSLI/SLOの導入を進めていました。

1. Datadog を用いた監視環境の整備

SLI/SLOの設定の前段階として、ビザスクではDatadogを導入し、監視環境の整備を進めました。
カスタマイズ性の高いDashboardやSLOに対応したMonitors(Alert)など、SLI/SLOを継続的に運用していく上で必要な機能が充実していたためDatadogの導入に踏み切りました。

ビザスクのプロダクトは現在、GAE上で稼働しており、アプリケーションログのexport先であるCloud Logging経由でCloud Pub/Sub → Datadogと連携させてログを転送することで、SLIの計測の前提となるログの収集基盤を整備しました。

2. SLI/SLO の定義とガイドライン作成 

本番環境へのDatadogの導入後、SLI / SLOの定義・計測に取り掛かりました。

SLIに関しては、計測可能かつSLIの推移に対して分析・対応が比較的容易にできるHTTP RequestのSuccess Rateを採用しました。
具体的には、GAEのログに含まれるLogSeverityをProcessorの一種であるLog Status Remapperを利用してDatadog上のログの公式ステータスとしてマッピングし、それを利用してSLIを算出しています。

SLOの設定にあたっては、使用しているマネージドサービスのSLOなどの依存関係を整理した上でSLOを定義しました。

加えて、SLI/SLOのトラッキングを目的としてDatadogのSLO確認用のDashboardとMonitors(SLOのAlert)を作成しました。
Dashboardに関しては、先述の依存関係にあるサービスの稼働率も確認できるような形で作成しています。

また、同時並行でSLI/SLOのガイドラインの作成に取りかかりました。

背景として、SREチームはSLI/SLOの計測だけではなく、開発チームに対してもSLI/SLOへの理解とSLI/SLOを確認する習慣の浸透を目標としているということがあります。
また、ビザスクではシステムアーキテクチャの刷新に伴ってマイクロサービス化を進めており、今後分割したサービスごとにSLI/SLOの管理を進める中でSLI/SLOの定義・判断基準に立ち返る機会が増えると考えられます。

そこで、開発チーム全体にSLI/SLOを普及させることを念頭に置いて、SLI/SLOの定義や設定根拠などのコンテキストを参照できるようにドキュメントの整備を行いました。
今後、分割されたチームごとにSLI/SLOの設定・運用ができるようにドキュメントの更新や修正は進めていく予定です。

ガイドラインの中は、Design Docsをドキュメントのベースとして下記のような項目に関して内容をまとめています。

- Overview
- Motivation
- Context & Scope
    - Goals
    - Non-Goals
    - Context
- Overview(内容)
    - 1.SLI / SLO の一般的な定義
    - 2.ビザスクにおける SLI / SLO に対する考え
    - 3.SLO の変更に関する方針
    - 4.SLO 違反に対する方針
- Reference

3. SLI/SLO 勉強会の実施

監視環境の整備とSLI/SLOの設定を行い、開発チーム全体にSLI/SLOが共有できる状態になった段階で、開発者向けの社内勉強会を開催しました。

理由は先述の通り、SLI/SLOそのものの理解を深めてSLI/SLOを普及していくためです。
この勉強会では、Datadogのハンズオンをメインに据えて、SLI/SLO自体の説明や導入理由についても合わせて話をしました。

初回の勉強会では、「開発者がDatadogを日々の業務にどのように活用できるのか」に重点を置き、SLI/SLOに直接関連しないような機能紹介 (ex. Datadog Logs, Metricsの使い方 etc.) も含めました。

SLI/SLO導入のアプローチとしてDatadog自体の有用性を理解してもらい、その延長としてDatadogをSLI/SLOの観点でも(開発チーム全体で)活用してもらうという方向で進めていきたいと考えているからです。

勉強会には、リモートからの参加者も含めて開発チームの約7割のメンバーが参加しました。今後も、Datadog内の機能紹介などを行う社内勉強会は継続的に開催予定です。

SLI/SLO の導入によるチームの変化

このような形で、約半年に渡って監視環境の整備からSLI/SLOの導入までを進めていきました。
その中で、課題意識を持っていた部分にも少しづつではありますが変化が見られるようになりました。

1.サービス品質の管理

SLIの推移から変動の要因となるエラーの種別・発生数まで一気通貫でトラッキングできるようになったことで、サービス品質を適切に管理できるようになりました。

SLIの変動要因であるエラー数の推移など具体的な数値を見れるようになったことで、優先度をつけて対応できるという意味でも管理しやすくなったと実感しています。

2.機能追加とサービスの信頼性維持

SLOの可視化により、Error Budgetを極端に消費するといった機能追加とサービスの信頼性のバランスを損なうケースでの対応が容易になりました。

SREチームでは、SLOを見る会と題して、週次でSLIの推移とエラー数の推移をチェックする機会を設けています。その中で、エラー数の増減に対して±30といった具合に増減の基準を設けて、極端に増減しているエラーの種類をトラッキングしています。
週間で極端にエラー数が増えていれば開発チームに連携するなどして、バランスが崩れた状態が長期間続かないように対応しています。
(バーンレート(=エラーバジェットの消費速度)などをうまく活用できれば、この部分は改善の余地はあるかなと思います。)

また、当初想定していた変化に加えて下記のような変化がありました。

3. Fact-Basedでの対応

Datadogによる監視環境の整備によって、Fact-Basedで動く(数値データなど裏付けがあるものをベースとして動く)という考え方が強く浸透しています。

SREチームでは先述の通り、「SLOを見る会」という会を設けてSLOの推移とエラー頻度の推移やサブシステムの稼働率を週次でチェックしています。
例えば、SLIの低下が見られた場合、依存するサブシステムの稼働率やエラー数の推移など事象に対する原因を調査します。

その際には、感覚に頼るのではなく、エラーの発生数やその増加量など具体的な数字を見れるようにDashboard, Monitorsなどを整備しています
そのため、事象に対してデータなどの裏付けを確認する意識がより強くなりました。

4. Observabilityに対する意識の変化

Observability(可観測性)に対する意識にも変化がありました。

事象に対して、具体的なデータをもって分析・判断を進めていくと「xxのデータを確認したいけど手元にない」といった具合に計測できていないものに対しても意識が向くようになりました。

そこから、収集できないメトリクスやログがあれば計測できるように環境を整備したり、ETLで分析用途に利用できるようにデータを加工するなど具体的な改善施策につながっています。

推測するな。計測せよ。という格言がありますが、チームとして当たり前にその方向に動くことができているというのは良い変化だと実感しています。

終わりに

ビザスクのSLI/SLOの導入の進め方、導入する中での気付きと今後の課題についてご紹介させていただきました。

先述の通り、SLI/SLOは設定してゴールではなく、サービス運用の中でSLOを守りかつ改善していくことがゴールです。
まだまだSLI/SLOの運用に関する課題は多いですが、ひとまずはSLO導入の第一歩を踏み出すことはできたかなと思います。

SREチームとしてのチャレンジは始まったばかりなので、運用の中で得た知見はテックブログなどでアウトプットできればと思います。