SLOの導入は早ければ早いほどよい 〜FAANSの事例とその効果〜

運用改善 監視 品質管理

SLOの導入は早ければ早いほどよい 〜FAANSの事例とその効果〜

はじめに

こんにちは、FAANS部バックエンドブロックでFAANSのバックエンドシステムの開発と運用をしている田島です。

2021年11月にZOZOTOWNとアパレルのブランド実店舗をつなぐOMOプラットフォーム「ZOZOMO」が始動しました。FAANSは、ZOZOMOで展開するサービスの1つで、ブランド実店舗で働くショップスタッフ専用の販売サポートツールです。FAANSは2022年8月の正式版リリース以来、これまで様々な機能をリリースしてきました。以下はその一部です。

  • 投稿機能： ショップスタッフが自身で自社のアイテムを着て撮ったコーディネート画像やコーディネート動画といったコンテンツを複数チャネルに同時投稿できる機能。投稿先チャネルとしては、ZOZOTOWNやWEAR、Yahoo!ショッピングといった弊社並びに弊社のグループ会社のWebサイトに加え、ブランド企業の自社ECサイトへの同時投稿も可能。
  • 成果確認機能： 投稿機能で投稿したコンテンツがどのくらい閲覧されたのか、それをきっかけにEC上の売上にどのくらい貢献できたか、といった様々な切り口の『成果』をアプリ上で確認できる機能。
  • 顧客直送機能： ブランド実店舗で欠品している商品の在庫が弊社の物流拠点「ZOZOBASE」にある場合、お客様は店頭で決済し、ZOZOBASEからお客様の自宅へ商品を直送できる機能。
  • ブランド実店舗の在庫取り置き機能： ZOZOTOWN上で実店舗の在庫取り置きを希望したお客様への対応を、ショップスタッフがFAANS上の簡単操作で完結できる機能。

FAANSではリリースから1年も経っていない段階でSLO（サービス品質目標）を導入し、ここまで試行錯誤を重ねて運用してきました。本記事ではFAANSにおけるSLO運用の実践とそこから得られた知見について紹介します。

目次

1 SLO導入の背景

スタートアップ事業として立ち上がったFAANSはサービスローンチに向けた立ち上げフェーズを経て、現在は成長フェーズに移行しています。私達はさらなる顧客価値の提供のために、新機能のリリースや既存機能を強化するためのスピーディーな開発を日々行っています。一方で、FAANSではサービス企画段階から「当たり前品質の追求」を掲げてきました。ブランド実店舗で働くショップスタッフは、忙しい実店舗業務の傍らでFAANSを通じてコーディネート画像を投稿したり、FAANSを使ってお客様を接客したりします。そのため、アパレルブランド企業やそのショップスタッフがFAANSを利用する業務において、不満やストレスを感じることのないよう、サービス品質を維持することは極めて重要です。とはいえ限られたエンジニアリングリソースの中で、機能開発によるさらなる価値提供の取り組みとユーザーが不満を抱かないサービス品質維持の取り組みを両立することは、工夫なしでは実現できません。その両立を図るためにSLOを導入するに至りました。

2 FAANSのシステムとそれを支える開発組織

具体的なSLOの導入について話をする前に、まずはその前提知識となるFAANSのシステムの特徴とFAANSの開発組織の体制を概説します。

2.1 システムの特徴

FAANSのシステムは以下のような特徴を有しています。

  • FAANSのユーザーが利用するクライアントアプリとしてWeb/iOS/Androidに対応しています。
  • バックエンドシステムのインフラリソースは全てパブリッククラウド環境に存在します。そのほとんどがGoogle Cloudで構築されており、メール配信処理などで一部AWS(Amazon Web Services)を使用しています。
  • Web APIサーバーは役割の異なる複数種類のシステムコンポーネントが存在します。それらは全てGKE(Google Kubernetes Engine)*1の1つのKubernetesクラスタ上でPodとしてサービングされています。以下はその一部です。
    • FAANSのiOS/Android/Webアプリからのリクエストを直接捌くクライアントアプリ用API。
    • 他のWeb APIサーバーから非同期でオフロードされたジョブを実行する非同期ジョブ用API。
    • アパレルブランド企業の自社ECサイトのシステムから直接アクセスされる外部システム連携用API。
  • ワークフローエンジンとしてKubernetesネイティブなArgo Workflows*2を採用しており、Web APIサーバーが稼働するGKEクラスタに相乗りしています。スケジュールやイベント駆動で実行されるバッチ処理は基本的には全てArgo Workflowsのワークフローとして稼働しています。
  • ユーザーのマスタデータなどが管理されているオンライントランザクション向けのデータベースとしてGoogle CloudのCloud SQL(PostgreSQL)*3を使用しています。このデータベースはWeb APIサーバーやバッチ処理からアクセスされています。
  • WEARやFulfillment by ZOZOといった弊社の別プロダクトのWeb APIにアクセスするWeb APIやバッチ処理も多く、社内の別チーム管轄の別プロダクトに依存したプロダクトです。

2.2 開発組織の体制

続いて、FAANSの開発組織についてです。以下はFAANSのプロダクト開発・運用に関わるメンバーが所属するブランドソリューション開発本部の組織図です。

organization_chart ※引用元スライド： https://speakerdeck.com/zozodevelopers/company-deck

弊社ではチームをブロックという単位で編成しています。この中でFAANSのプロダクト開発と運用に中心的に関わるブロックを簡単に説明します。まず、プロダクト戦略部FAANSプロダクトマネジメントブロックにはFAANSのPO(プロダクトオーナー)やPM(プロジェクトマネージャー)といったロールのメンバーが所属しています。FAANSの開発と運用に携わるエンジニアはFAANS部に所属しています。フロントエンドブロックはFAANSのWeb/iOS/Android用のクライアントアプリの開発を、バックエンドブロックがFAANSのバックエンドシステム全体の開発と運用をそれぞれ担当しています。なお、以前はWEARバックエンド部のSREブロックがFAANSとWEARの2つのプロダクトのSRE業務を兼務していました。しかし、現在ではFAANS部バックエンドブロックにその責務は委譲されています。この体制移行の意思決定については後述の「6.3 フルサイクルエンジニアリングチームへの体制移行」で説明します。また、この図には記載していませんが、別の本部に所属するBizDev職メンバーやQA（品質保証）エンジニアもFAANSのプロダクトの開発や運用に深く関わっています。

3 最初のゴール設定

SLOのコアとなるプロセスは極端に単純化すれば以下に集約されます。

  • ユーザーの満足度に強く関連しているであろう代表指標=SLI（サービス品質指標）を選定し、ユーザーの信頼性を測定可能なものとする。
  • 選定したSLIに対してユーザーが満足しているか、していないかに対応する目標値=SLOを定める。
  • SLOを満たしていない、つまりエラーバジェットが尽きた場合はSLOを満たすようにする改善を開発タスクより優先して実施する。

一方で、SLOは組織的な取り組みであるため、実用的な運用に乗せるためには戦略的な導入計画を考える必要があります。SLOを導入するにあたって、私達は慎重に「最初のゴール」を設定しました。

3.1 バックエンドシステムのみを対象としたSLOを運用に乗せる

理想的には、SLOはシステム全体、すなわちバックエンドシステムに限らず、クライアントアプリを含めたエンドツーエンドでの監視と運用をすることが望ましいです。ユーザーはクライアントアプリを介してバックエンドシステムを利用するので、バックエンドシステムのサービス品質がいくら高くても、クライアントアプリのサービス品質が悪ければユーザーハピネスに繋がりません。しかし、私達は導入段階で小さく始めることを選び、敢えてバックエンドシステムのみを対象にすることとしました。クライアントアプリは、今後の拡張フェーズでSLOの対象に加える予定です。このように小さなステップから始める理由は、SLOの運用が初期段階では試行錯誤の連続であり、最初からシステム全体に適用すると運用が複雑になりすぎる可能性があるためです。初期段階では対象範囲を絞ることで、SLOの設定や運用フローを確立し、チーム全体がその運用に慣れることを優先しました。この段階での成功体験をもとに、次のステップとして対象範囲を拡大していく方が、最終的な全体最適を図るためにも有効だと判断しました。

3.2 SLOアラートは導入せず、SLOの達成状況の定期的な確認に留める

もう1つの重要な決定として、SLOアラートの導入を見送りました。SLOアラートは本来、サービスの品質が低下した際に迅速に対応するための仕組みですが、初期段階でこれを運用に組み込むと、試行錯誤が多い中でアラートが頻発し、かえってノイズとなる恐れがあります。これを防ぐため、まずはアラートを設けずに定期的なSLOの達成状況のチェックに留め、運用に慣れるまで柔軟に改善を重ねる体制を取りました。具体的には、SLOの達成状況を関係者で確認し、現状の目標の達成状況や運用課題を共有する形で進めています。その詳細は「5 『SLO定例』による信頼性チェック」で説明します。

このように、最初のゴールをあえて小さく設定し、段階的に運用を確立していくことで、無理なく改善を重ねることが可能となると考えました。

4 最初のSLI/SLOの選定

SLOは、SREのコアとなるプラクティスです。最初のSLI/SLOの設定を考える上で、まずはGoogleのSREチームによって執筆された2冊の書籍の該当章に目を通し、理解を深めました。それが「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」と、その副読本である「サイトリライアビリティワークブック ―SREの実践方法」です。これらの書籍では、SLI/SLOの概念から実際の運用方法までが体系的に解説されています。なお、私達がSLOを導入したタイミングでは和訳本がまだ存在していなかった「SLO サービスレベル目標 ―SLI、SLO、エラーバジェット導入の実践ガイド」という書籍が昨年発刊されました。SLOにまつわるトピックで1冊書かれた貴重な書籍です。これからSLOの導入を検討する方々には、参考文献としてぜひおすすめしたいです。また、これらに加えて各社のSLO導入事例を取り上げたWeb上の記事にも目を通し、他の企業がどのようにSLOを運用しているか、どのような課題に直面したかを学びました。これにより、理論だけでなく現実世界でのSLO導入に伴う具体的な実践方法や成功要因についても理解を深めることができました。

4.1 選定方針

書籍や記事で得たSLOに関する知識をベースにFAANSのシステムの特性を踏まえて考え、FAANSの最初のSLI/SLOを選定する上での方針を以下のように整理しました。

4.1.1 対象システムはWeb APIサーバーのみとする

最初のSLOを選定するにあたって、まずは小さく始めることを意識し、バックエンドシステムの中でもWeb APIサーバーのみを対象とする方針を立てました。この選定には、Web APIサーバーがFAANSにおけるサービスの中核を成しているという理由があります。FAANSのユーザーは、日常的にFAANSのクライアントアプリを通じてサービスを利用します。そして、ユーザーが行うアクションは、すべてWeb APIを介して処理されています。Web APIはユーザー体験の根幹を担っており、可用性やパフォーマンスが低下すれば、即座にユーザー体験へ悪影響を及ぼします。ユーザーであるアパレルブランド企業とそのショップスタッフにとって、Web APIサーバーはFAANSを利用する上で最も重要なシステムコンポーネントです。これを効果的に監視・管理することがSLO運用の初期段階で不可欠だと判断しました。なお、定時実行されるバッチ処理といったその他のシステムコンポーネントの信頼性の追跡に関してはSLO運用の拡大フェーズで検討することとしました。

4.1.2 重要機能の単位とシステムコンポーネントの単位の2軸でSLOを定める

SLOを効果的に運用するためには、システムの属性をうまくカバーできる必要最小限の選択をすることが重要です。私達は、そのためのアプローチとして、重要機能の単位とシステムコンポーネントの単位の2軸でSLI/SLOを定めることにしました。

まず、重要機能の単位のSLO設定において、ユーザー体験の中で最も重要な操作やシナリオを把握するために、簡易的なCUJ(クリティカルユーザージャーニー)を実施しました。CUJとは、ユーザーがサービスを利用する際の主要なステップやアクションを追跡し、業務やサービスの成功に直結するポイントを特定するプロセスです。このプロセスを通じて、どの機能がユーザーにとって欠かせないのか、またその機能に関係するAPIの中で重要なものはどれなのか精査しました。例えば、ECサイトであれば「商品検索」「カートへの追加」「購入手続き」の各ステップがCUJの重要なポイントとなり、それに対応するAPIが重視されるでしょう。このCUJの結果をもとに、具体的な測定対象APIを選定しました。これにより、ユーザー体験の中で本質的な価値を持つ操作に焦点を当てることができ、SLOがユーザーにとって最大限の価値を提供できるような形となると考えています。

次に、システムコンポーネントの単位のSLO設定です。前述の通り、対象システムはWeb APIのみとするため、システムコンポーネントとしてはWeb APIサーバーの種別の単位となります。具体的には、前述のクライアントアプリ用Web APIサーバーや外部システム連携用Web APIサーバーなどです。そして、Web APIサーバーには複数のAPIが実装されていますが、それら全てのAPIを対象としたリクエスト処理に対する総合的な品質に対してSLOを定めることを指します。ただし、ヘルスチェックエンドポイントのようにユーザー体験に直接的な影響を与えないAPIは、サービス品質の測定結果に不要なノイズを生じさせる可能性があるため対象外としています。

このように、重要機能の単位とシステムコンポーネントの単位という2軸でSLOを定めた理由は、業務の優先度と技術的な健全性の両面をカバーするためです。システム全体の可用性やパフォーマンスを考慮しつつ、ビジネスにとって重要なユーザージャーニーの品質を確保することが、このアプローチの根幹にあります。SLOは、その設定が業務やサービスに与えるインパクトによって初めて価値を持ちます。もし、設定されたSLOがビジネスの優先度を反映しておらず、業務に影響を与えない指標にばかり焦点を当てていた場合、そのSLOは十分な価値を提供できないでしょう。この点を踏まえ、システムの技術的要素とビジネスの主要な機能の両方をカバーできるバランスを保つことが実用的で効率的なSLO運用のためには重要だと考えました。

4.1.3 レイテンシーと可用性の2つのSLIを選定する

私達は、Web APIサーバーというシステムのユーザーの信頼性を測る指標としてレイテンシーと可用性の2つにフォーカスすることとしました。

まず、Web APIのレイテンシー、つまり応答時間は、ユーザー体験に直結します。APIのレスポンスがわずかに遅れるだけでも、特にリアルタイム性が求められるアプリケーションでは、ユーザーはフラストレーションを感じ、場合によってはサービスを離脱してしまいます。例えば、モバイルアプリやWebサービスでの検索やデータの読み込みが数秒以上かかると、ユーザーは「遅い」と感じ、その印象がサービス全体の評価に影響を与えることになります。ただし、前述の非同期ジョブ用APIは、そもそも処理に時間がかかることを前提として非同期で行われるためレイテンシーがそれほど重要ではないことから、今回はSLIの対象から除外しました。なお、レイテンシーのSLOは例えば『30日間のローリングウィンドウで99パーセンタイル値のレイテンシーが500ミリ秒以下』といった形で具体的に定義されます。

続いて、可用性（Availability）は、サービスがユーザーに常にアクセス可能な状態であることを示す指標です。可用性が低下するとユーザーはサービスにアクセスできなくなり、エラーやダウンタイムが発生すれば顧客に対する信頼性が著しく損なわれます。現代の多くのサービスは、24時間365日の稼働が当然とされています。Web APIサーバーは、他のシステムやクライアントアプリとの連携を担う中心的な役割を果たしているため、その可用性が低下すれば単にAPI自体の問題に留まらず、サービス全体へ広範な影響が及びます。なお、私達の場合は、Web APIサーバーや各APIの可用性を成功したリクエスト数/全体のリクエスト数というイベントベースの稼働率として算出しています。また、可用性のSLOは例えば『30日間のローリングウィンドウで99.5％以上の稼働率』といった形で具体的に定義されます。

私達がSLO運用の初期段階でレイテンシーと可用性にフォーカスしたのは、これらの指標がユーザー体験とサービスの信頼性に最も大きく影響を与えるからです。複雑な指標を多数導入するよりも、まずはWeb APIのようなリクエスト処理システムのSLIにおける2つの基本指標に絞り、運用フローをシンプルかつ効果的にスタートさせることが重要だと考えました。これにより、チーム全体がSLIの監視と改善サイクルに慣れ、徐々に運用の精度を上げていく狙いです。

4.1.4 クラウドインフラのSLA未満の水準のSLOを定める

FAANSのバックエンドシステムは前述の通りGoogle CloudやAWSといったパブリッククラウド上に構築されています。そのため、そのシステムのサービス品質はパブリッククラウドのサービス品質に依存することとなります。例えば、FAANSのWeb APIのシステムはDNS、ロードバランサー、サーバーインスタンスやデータベースインスタンスなどのインフラコンポーネントで構成されています。Web APIへのHTTPリクエストがエラーを返すことなく正常に処理されるためには、これらのインフラコンポーネントが正常に稼働している必要があります。パブリッククラウドが提供するプロダクトの中にはSLA（サービス品質保証）が定められているものも多いです。これら個々のインフラコンポーネントの役割を担うプロダクトの可用性SLAを調べたところ、最も低い水準だったものはGKE AutopilotのPodの『99.9％以上の稼働率』というSLA*4でした。よって、FAANSのWeb APIサーバーの可用性SLOを定義する上で、『99.9％以上の稼働率』というインフラのSLA未満の水準で定義する必要があると考えました。

その理由を具体例を用いて説明します。例えば、Web APIのシステムを構成するクラウドインフラの可用性SLAが『99.9％以上の稼働率』だったとします。しかし、実際にしばらく計測してみると安定して『99.99％以上の稼働率』でした。そこで、Web APIの可用性SLOを「30日間のローリングウィンドウで『99.95％以上の稼働率』」と定義しSLOを運用し始めたとします。すると、しばらくの間はSLOを満たした状態が続いていたのですが、ある時Web APIの可用性SLOが未達状態に陥ってしまいました。調べてみると原因はクラウドインフラの可用性の低下であることが判明し、低い時では『99.90％の稼働率』にまで下がっていました。SLOの目標値である『99.95％以上の稼働率』を下回る品質が一定期間続きエラーバジェットを使い切ったので、SLOを満たす状態に戻す改善を早急に実施する必要があります。ところが、この時原因はクラウドインフラの可用性が低下したことなので提供元のクラウドベンダーに相談しても、可用性が改善されるとは限りませんし一般的には期待できません。なぜならば、『99.90％の稼働率』にまで下がっていたとしても『99.9％以上の稼働率』というSLAを満たせているからです。クラウドベンダーは顧客との間で合意済みのサービス品質で依然として提供できているため、顧客のための改善のアクションを取る必要性は基本的にはないのです。

この例からも分かる通り、クラウドインフラのSLAを超える水準のSLOを定めて運用することは現実的とはいえません。ただし、ここで重要なことは、あくまで現状のインフラ構成のままの場合の制約であることです。SLOはユーザーの満足度に基づいて決めることが重要です。もし、クラウドインフラのSLAがあるべきSLOの基準を超えていなかった場合、インフラ構成そのものを変えるという選択肢も検討すべきでしょう。SLAの水準が高くなるようにインフラ構成を変えることで、ユーザーの満足度に基づいたSLOがインフラリソースのSLAの水準を超えないように調整できる可能性があるからです。

4.1.5 依存している社内の別プロダクトのサービス品質やSLOは一旦考慮しない

前述の通り、FAANSのバックエンドシステムはWEARなどの社内の別プロダクトのシステムに依存しています。そのため、FAANSのサービス品質は依存先の別プロダクトのサービス品質の影響を受けます。例えば、FAANSのあるWeb APIエンドポイントはAPIの内部処理で社内の別プロダクトのWeb APIに同期的に1回アクセスしているとします。この場合、このFAANSのAPIのレイテンシーの品質は社内の別プロダクトのAPIのレイテンシーの品質を上回ることはありません。そして、別プロダクトのAPIのレイテンシーの品質が悪化すれば、それに引きずられる形でFAANSのAPIのレイテンシーも悪化します。このような依存関係が存在しますが、私達は依存先プロダクトのサービス品質やSLOを一旦は考慮せず、ユーザー満足度に基づいたSLOを定めて運用し始めてみることとしました。そのように判断した理由を説明します。ユーザーが満足するか、しないかの基準でFAANSのあるAPIのレイテンシーSLOを考えたときに、例えば『99パーセンタイル値で500ミリ秒以内』という目標値が妥当だという結論に至ったとします。一方で、このAPIの内部処理で同期的に1回アクセスするWEARのAPIのレイテンシー品質が『99パーセンタイル値で700ミリ秒』という実測でした。つまり、依存するWEARのサービス品質の実測に対してこのSLOは無理があるということになります。とはいえ、必ずしもこのSLOを達成まで持っていけないとは限りません。私達が管理していない別プロダクトであっても、同じ会社のその別プロダクトの開発チームに品質改善の相談や依頼をするというアクションはとれます。そして、その際にSLOは他チームに品質改善の必要性を理解をしてもらう上で説得力のある論拠となり得ます。まずは、そのようなアクションをとってみることが重要だと考えました。FAANSのSLOを踏まえて別プロダクトのサービス品質の改善やSLOの見直しを行うといった結果につながるかもしれません。もちろん、このやり方で全てが滞りなく解決されるとは限らず、難しい場面もあるかもしれませんが、その場合はチーム間で協議して現実的な落とし所を探っていけばよいと考えました。ただし、この時私達が定めたSLOは絶対的に正しい閾値ではない点には注意する必要があるでしょう。SLOは初期フェーズで適切な閾値を設定することは難しく、運用の中で適切な閾値となるようにイテレーティブに改善していくものです。また、いくら閾値を改善しても、絶対的に正しい閾値には到達し得ないものでもあります。私達はこのような前提を理解した上で、FAANSのSLOを絶対的な論拠とはせず、他チームと協調的に話を進めるべきだと考えています。

4.2 ステークホルダーとの合意

前述の選定方針を踏まえて選定した最初のSLI/SLOを実際に設定して運用を開始するには、関係者との合意が必要です。まず、関係者全員にSLOとは何か、そのメリットや基本的な考え方を丁寧に説明することから始めました。特に非エンジニア向けにSLOの理解を深めてもらうために、山口能迪さんによる「SLOをもっとカジュアルに活用しよう」という記事を事前に読んでもらうことを意識しました。この記事は、SLOの要点を非エンジニアにもわかりやすく簡潔に説明しており、初めてSLOに触れる人にとって理解しやすく、導入への前向きな姿勢を促す素晴らしい内容のため重宝させていただいています。なお、関係者ごとにどのような点で合意を取るべきかを明確にすることも重要です。POやPMとは、SLIの選定とSLOの目標値が適切であるかを丁寧にすり合わせ、その基準を下回った場合にエンジニアリングリソースを優先的に修正や改善に投入する必要があることを理解してもらいました。SLOがビジネス価値やユーザー体験に直結することを納得してもらい、リソース配分の重要性を認識してもらうことが大事です。また、エンジニアリングチームとは、エラーバジェットが尽きた際にサービスの安定性回復を優先し、機能開発を一時停止することに合意します。これにより、システムの信頼性がビジネスやユーザー体験にどれほど重要かを共有し、リソース投入のタイミングについて共通認識を持つことができます。

5 「SLO定例」による信頼性チェック

「3 最初のゴール設定」にも設定したように、私達はSLOの運用開始に伴い、SLOの達成状況や運用上の課題を定期的に確認し、必要な改善アクションを迅速に実行するための体制を整える必要があります。そこで、バックエンドシステムの開発・運用に関わるバックエンドブロックとSREブロックの2チームによるSLO定例という定例会議を立ち上げました。SLO定例は、FAANSに必要な信頼性を維持することを目的としており、SLO運用に関連する認識合わせや議論だけでなく、信頼性維持に寄与するその他の情報共有や意思決定も行う場です。ただし、後述の「6.3 フルサイクルエンジニアリングチームへの体制移行」により、SREブロックはFAANSの業務から離れたため、現在はバックエンドブロックのみでこの定例会議を行っています。そのような経緯や試行錯誤を経た最新の会議形式を説明します。

会議の流れは以下のようになっています。

  • 前回のNext Actionの対応状況の確認
  • 直近のリリース内容の確認
  • 直近のアプリケーションエラーやシステム障害の確認
  • SLOの達成状況の確認
  • データベースのシステムメトリクスの確認
  • Next Actionの整理

続いて、これらを個別に説明します。

5.1 直近のリリース内容の確認

GitHubで管理されている前回のSLO定例以降にリリースされたプルリクエスト一覧をチームで確認し、信頼性に影響を与える可能性があるリリースを特定します。信頼性に関わるリリースとは、信頼性向上を目的とした修正だけでなく、大規模な新機能のリリースなど、システム全体のパフォーマンスや可用性に影響を及ぼす可能性のある変更も含まれます。この確認を最初に行うことで、リリースがシステムに与えた影響を理解しやすくなり、後続のログやメトリクスの分析がより効果的なものとなります。

5.2 直近のアプリケーションエラーやシステム障害の確認

私達は、アプリケーションエラーを監視するツールとしてSentryを利用しており、この場では前回のSLO定例から現在までに発生したアプリケーションエラーの一覧をSentryで確認します。エラーが発生すると即座に通知され、迅速にエラー内容の把握と必要なアクションをとる体制を築いています。そのため、この会議の場では原因の深掘りや解決策の策定は行わず、どのエラーがどれだけの頻度で発生したかとそれぞれの対応状況を俯瞰的に確認し、全員で状況を共有するのみに留めています。また、稀に発生する中規模以上のシステム障害に関しては、その発生時期や進行中の再発防止策の状況も確認します。これにより、全員が現状をしっかりと把握し、迅速な対応や適切な判断ができる体制を整えています。さらに、この確認をSLOの達成状況の確認前に行うことで、SLOの改善や悪化時の要因分析がしやすくなります。

5.3 SLOの達成状況の確認

私達は、システム監視ツールとしてDatadogを利用しており、各種システムメトリクスがDatadogで確認できるようになっています。そのため、SLOの達成状況はDatadogのダッシュボードを活用してリアルタイムに監視できるようにしました。このダッシュボードには、例えばAPIごとのエラーレートやレイテンシーが一目で確認できるウィジェットなども配置されており、SLOに変化が生じた際にはその原因を特定しやすい設計となっています。なお、このダッシュボードは「WEARにおけるSLOを用いた信頼性改善の取り組み」で紹介されているDatadogのダッシュボードを参考に作っています。エラーバジェットの枯渇状況を確認し、原因を特定して適切な対応策を議論することで、SLOのプロセスが回るようになっています。

5.4 データベースのシステムメトリクスの確認

私達が利用しているCloud SQL(PostgreSQL)の監視として、アラート監視と定期的なメトリクス監視の二重体制を構築しています。まず、アラート監視に関して、データベースのログやメトリクスを対象とした適切なアラート設定を入れて、問題を迅速に検知して対応できるようにすることはデータベースの監視において重要です。また、それとは別で、状況の変化を時系列のメトリクスで管理しキャパシティプランニングや障害の予兆の把握に役立てることを目的とした、定期的なメトリクスの確認も重要です。このようなメトリクス監視もこの会議で行っています。なお、このメトリクス監視で見るべきメトリクスの一覧もダッシュボード化して、容易に確認できるようにしています。

6 SLO運用開始後の工夫と取り組み

SLOの運用開始後、運用の過程でさまざまな工夫や取り組みを行ってきました。本章ではその一部をご紹介します。

6.1 SLI/SLOの設定変更の記録をADR形式で残す「SLO-DR」

SLI/SLOは最初に定義した設定を一切変えずに恒久的に使い続けるわけではなく、その設定自体もイテレーティブに見直すものです。例えば、既に運用しているSLOの設定をより適切な閾値となるように調整したり、運用していく中で見出したより適切なSLIに差し替えたり、新機能のリリースに伴い新たなSLI/SLOを盛り込むことがあります。FAANSではSLI/SLOの設定を変更する際にADRの形式で設定変更の意思決定の内容とそのコンテキストをドキュメントに残す規約とし、そのドキュメントを私達はSLO-DRと名付けました。

ADR*5とは、Architecture Decision Recordの略で、ソフトウェアアーキテクチャに関する意思決定とそのコンテキストを残すドキュメント手法の一種です。FAANSの開発チームでは以前からADRによるドキュメント文化が浸透しており、ADRの形式は慣れ親しんだものでした。また、ADRは個々の意思決定を独立したドキュメントとして作成しますが、一般的には一度作成したドキュメントを廃止することはあっても、内容を更新することはない追記型のスタイルです。この追記型のスタイルはSLOの設定に関する意思決定がどのような変遷を辿ったかというコンテキストが追いやすく、今回の要件に適していました。

例えば、新規で構築したAという名前のWeb APIサーバーがあり、Aの可用性SLOの設定に関して、ある期間に時系列順で以下のタイトルで3つのSLO-DRのドキュメントが作成されたとします。

  1. 2024/08/01 新規構築したAのWeb APIサーバー全体の可用性SLOを30日間のローリングウィンドウで『99.9％以上』の稼働率として定義した
  2. 2024/10/01 Aの全体の可用性SLOを30日間のローリングウィンドウで『99.9％以上』→『99.5％以上』の稼働率に変更した
  3. 2024/12/01 Aの全体の可用性SLOを30日間のローリングウィンドウで『99.5％以上』→『99.8％以上』の稼働率に変更した

最初と最新の状態だけを比べれば『99.9％以上』から『99.8％以上』に目標値を下げたという変化としてまとめられますが、実際にはその過程で一度『99.5％以上』という設定を経由しています。一度『99.5以上』に下げてその後『99.8％以上』に上げたという個々の意思決定とそのコンテキスト、そしてそれらの時系列の変遷という情報には将来の意思決定の際に有用な情報が隠れていることがあります。この例では比較的単純な意思決定の流れを示していますが、実際のより複雑なケースでは、個々の意思決定とそのコンテキストがさらに重要な要素となります。SLO-DRでは、そのような情報が喪失せず、かつ追いやすい形式になっています。一方で、SLI/SLOの設定は頻繁に見直されることがあるわけではないことから、追記型がゆえのドキュメント数の増大に伴う認知負荷に関しては長期的な視点に立っても懸念がないと判断しました。また、最新のSLI/SLO設定の全体像は前述のダッシュボードでも容易に把握できます。私達は、SLI/SLO設定や運用開始日、エラーバジェットポリシーなどの決定内容と、そのコンテキストであるCUJや関係者との協議と合意の記録をまとめたドキュメントとして作成し一覧化して管理しています。

6.2 チームで行う継続的学習「SLO Study」

私達のチームでは、SLOに関する知識を共有し、運用の知見を深めるためにSLO Studyと名付けた継続的な学習の場を設けています。FAANSにはSLOの運用経験があるメンバーは少なく、SLOに対する関心や知識レベルにもばらつきがあります。そこで、全員がSLOに関する共通の知識を身に付け、チーム全体でSLOの効果的な運用を考えられる体制を築くことを目指して、この取り組みを開始しました。具体的には、事前にSLO Study用のドキュメントに記載の表にSLOに関するWeb上の記事のURLとそこから得た学びや議論したいことを記入しておきます。そして、SLO定例の最後の余った時間を使って記入者がその内容を発表し、定例の参加者で議論します。

SLO運用のあるべき姿は、事業やシステム、さらには組織の特性によって異なるため、一般化された知識だけではすべての現場に適用するのは難しいと感じています。よって、各々の開発組織が自分たちに合ったSLOのあり方を見つけ出すために、独自の試行錯誤を積み重ねていく必要があるでしょう。Google社がSLOのプラクティスを提唱して以来、多くの企業やサービスでSLOの取り組みが行われ、試行錯誤を経てきました。それぞれの現場で得られた実践的な知見を取り入れることは、私達にとって最適な運用方法を見つける上で非常に参考になります。SLO Studyの場では、SLO関連の資料や実際の運用事例をキャッチアップし、学んだことを「FAANSに活かせるか」「FAANSの場合どう適用するか」という視点で議論しています。このような負担の小さく無理のない継続的学習の取り組みを通じて、SLOに対する共通理解を深め、チーム全体での一体感を持ってSLO運用の改善を進めることが目標です。特に、書籍に記載されている一般的な知識だけでなく、各社の具体的な事例を学ぶことで、私達の現場に合った最適なSLOのあり方を模索していきたいと考えています。

6.3 フルサイクルエンジニアリングチームへの体制移行

SLOの運用を進める中で、SREブロックにアサインされていたFAANSの信頼性維持に関するタスクが思うように進まないという課題が浮上しました。この課題に対し、チームトポロジーの考え方を用いることで、状況を客観的に整理できました。

チームトポロジーとは、書籍「チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計」で紹介されている、組織のチーム設計において適応型のフレームワークを提供するモデルです。特にチームが担う認知負荷を最適化することを重視しています。この認知負荷が過剰になると、チームのパフォーマンスが低下し、システムの安定性に影響を及ぼすことが指摘されています。

FAANSとWEARは、それぞれ異なるビジネスドメインに属しており、どちらも複雑な要件を持っています。FAANSは新しいサービスながらも急速に成長しており、独自のビジネスニーズと技術的な要件が求められます。一方、WEARは長い歴史を持つ大規模なシステムであり、その運用には深い知識が必要です。これら2つの異なるビジネスドメインに対応することは、SREブロックに大きな認知負荷を強いる要因となっており、これは構造的な課題でもありました。さらに、FAANSとWEARは歴史的な経緯で両者の技術スタックの統一性が低いという事情もあります。そのため、SREブロックは異なる技術基盤の両システムに対応する必要があり、さらに認知負荷が増大していました。現に、SREブロックからは「WEARに手一杯で、FAANSに十分なアテンションを張れない」という声が上がっていました。このアテンションという言葉は、チームが持つ認知負荷に関連する概念で、適切な注意力を割けないことが認知的な過負荷の表れです。このような状況から明らかなのは、問題の本質が単なるリソース不足ではなく、過剰な認知負荷にあるということです。たとえSREブロックの人員を増やしても、認知負荷が軽減されない限り、この問題は解決しません。そこで、私達はチーム間の責任境界の見直しを行い、バックエンドブロックの責任範囲を広げてSREブロックの負担を軽減することによって、両者のフロー効率を改善する道を選びました。

歴史の浅いFAANSのバックエンドシステムは、WEARに比べて小規模なシステムで運用負荷が低いため、バックエンドブロックがSREブロックの責務を引き継いでも認知負荷的に無理はありません。さらに、バックエンドブロックはこれまでもインフラ構成や監視設定の変更、インフラ起因の問題解決に積極的に取り組んできた経験があります。また、バックエンドブロックにはSREブロックが担当していた運用業務の知識やスキルを持つメンバーが複数名いることもあり、体制移行は円滑に進行しました。この結果、現在ではSREブロックがFAANSの運用から離れ、バックエンドシステムの開発と運用はバックエンドブロックで自己完結する体制に移行しました。

バックエンドブロックにとっては責務が拡大したことでやるべき業務が増える一方で、大きなメリットもあります。運用を含む開発ライフサイクル全体を一貫して管理できるフルサイクルエンジニアリングチーム*6として機能し始め、分業体制でのコミュニケーションコストやサイロ化の問題が解消されます。その結果として、開発ライクサイクル全体へのフィードバックループがより効率的に回りやすくなるのです。ただし、開発ライフサイクルの中でQAに関しては、高い専門性を有したQAエンジニアが複数名おり開発ライフサイクルのボトルネックにはなっていないため、引き続き外部化されたままの体制を維持しています。

6.4 開発組織への定期報告

SLOは、開発組織の全体に共有されるべき重要な指標です。バックエンドシステムを中心にSLO運用を開始していますが、SLOの設定や達成状況、そして取り組んでいる改善アクションは、プロダクト開発・運用に携わる全ての関係者によって把握されている状態が理想です。そこで、私達はFAANSのプロダクト開発のための情報共有や相談の場である週次の定例会議で、SLO運用に関する報告をするようにしました。この場でSLOの状況を定期的に共有することで、機能拡充や新機能開発に偏りがちな意識を、信頼性という側面にも広げ、バランスの取れた価値提供を意識し続けることができると考えています。これは、私達が目指す組織全体へのSLO文化の浸透における重要なステップの1つだと捉えています。特に、信頼性維持に関するタスクを行う際に、そのタスクが今なぜ必要で、どのように全体の価値提供に寄与するのかを組織全体で理解することが重要だと考えています。SLOの定期報告を通じて、信頼性維持の取り組みが単なる技術的メンテナンスにとどまらず、ユーザーやビジネスにとって直結した価値提供の一環であることが明確になります。結果として、組織全体で信頼性に対する意識が強化され、持続的な改善活動につながっていくと考えています。

限られた時間の中で効率的にSLOの情報を共有するため、報告のフォーマットにも工夫を凝らしました。この定例会議は、プロダクト開発に関わる全てのメンバーが集まる唯一の場です。エンジニアだけでなくプロジェクトマネージャーやデザイナー、ビジネスサイドのメンバーも参加しています。そのため、技術的な背景を持たないメンバーにも理解できるシンプルかつ視覚的に分かりやすい形式が求められます。SLOの詳細な分析やアクションの議論は、専用のSLO定例で行うため、定例会議では現状のSLOの達成状況と必要なアクションを簡潔に示すことに集中しています。各SLOの達成状況は『達成』（=エラーバジェットに余裕がある状態）または『未達』（=エラーバジェットが枯渇している状態）として色分けし、一目で判断できるようにしました。また、前回の報告からの変化は赤色の文字で記載し、未達状態のSLOに関するアクションプランも簡潔に記載することで、状況の変化や必要な対応を迅速に把握できるようにしています。

具体的には以下の項目を含めるようにしました。

  • 測定日: 各SLOの測定時点を明記する。測定日はSLO定例の開催日に対応。
  • SLOの設定内容とその達成状況: SLOの設定内容と各SLOの『達成』または『未達』という達成状況を色分けして記載。
  • 前回測定時との比較: 前回測定時の達成状況も併記することで改善や悪化といった変化が読み取れるようにする。
  • 品質改善アクション:『未達』状態のSLOに関しては、『達成』に持っていくためのアクションプランを記載する。
  • 補足情報: システムコンポーネントやSLO関連の用語の解説を添えることで、背景を理解しやすいようにする。

一方で、具体的なSLIの数値や過去の傾向分析といった細かなデータは報告には敢えて含めていません。それらは前述のSLOダッシュボードで確認でき、SLO定例で議論されるため、開発定例では最小限の情報に絞り込み、報告のスムーズな進行を心掛けています。

具体的には以下のようなフォーマットの資料で報告しています。

slo_table

7 SLOを導入して得られた効果

SLOの導入によって、私達の開発・運用プロセスにおける意思決定が大きく改善されました。

7.1 明確な判断基準による会議の充実化

SLO導入以前も、バックエンドシステムの運用に関わるエンジニアが集う定例会議の中で、APIのレイテンシーやエラーレートなどのメトリクスを確認してはいました。しかし、それらがどの程度問題であるのか、具体的にどのようなアクションが必要なのか判断することが難しく、会議の進行が散漫になることがありました。メトリクスは収集できていても、問題の有無やアクションの必要性が不明確だったため、何となく会議を終えてしまうケースも少なくありませんでした。

SLO導入後は、その定例会議が前述のSLO定例として生まれ変わりました。各サービスにおいて設定されたSLOに基づいて判断できるようになり、会議でのディスカッションがより具体的かつ建設的なものとなりました。これにより、サービス品質に関する合意形成がスムーズに進み、どのタイミングでアクションを取るべきかが明確になりました。結果として、会議が締まりのあるものに変わり、効果的な意思決定を行う場としての役割を果たせるようになっています。

7.2 信頼性維持のためのアクション促進

SLOを満たせておらずエラーバジェットが尽きた場合には、即座に対策を講じるための具体的な行動に移る習慣が根付いてきました。もちろん、全ての問題が一度に解決されるわけではありませんが、少なくともSLOを基準に優先順位をつけ、後回しにされがちなサービス品質の課題に対しても確実に対応が取られるようになりました。これにより、従来は見過ごされていたような品質問題に対しても、早期に改善のためのアクションが取られるようになり、ユーザー体験の向上につながっています。例えば、APIのエラーレートがSLOを下回ることがあれば、その原因を特定し、必要な修正や最適化を実施する体制が整っています。以前であれば、「重大な問題でなければ後回し」という姿勢が取られていた場面でも、SLOに照らし合わせることで緊急性が明確となり、速やかに改善に取り組むことが可能になりました。

7.3 他チームへの改善依頼の円滑化

SLOの導入により、私達が依存している社内の他プロダクトの開発チームに対して、品質改善を依頼する際の根拠も強化されました。以前は、依存先の他プロダクトのAPIのレイテンシーがなんとなく遅いとは感じつつもどこまで改善すべきかも不明確で、他チームに働きかける具体的なアクションへ繋がりにくい状態でした。しかし、SLOによってその判断基準が明確になったことで、そのようなアクションに繋がりやすくなりました。また、「SLOを満たしていない」という明確な基準を提示できるため、依頼内容が具体的かつ論拠のあるものになり、依頼先にとっても協力してもらいやすいものとなりました。この結果、プロダクト間での協力体制も強化され、全体のサービス品質向上に寄与しています。

7.4 技術的な意思決定の改善

SLOの導入により、技術的な意思決定の際に信頼性への意識が高まりました。システムアーキテクチャの設計やパフォーマンス最適化には、トレードオフを踏まえた判断が求められます。SLOという信頼性基準が明確に定義されたことで、どの程度の信頼性が必要かという具体的な指標が提供され、意思決定の根拠がより明確になりました。例えば、レイテンシーに関するSLOが設定されていることで、負荷テスト実施の際にも目標とすべき性能値の意思決定がスムーズになり、試験結果に基づく判断がより合理的に行えるようになりました。また、SLOが信頼性の指標として組み込まれたことで、アーキテクチャ設計の際にも信頼性を意識した選択がより自然に行われるようになりました。

8 SLOの導入は早ければ早いほどよい

SLOを運用していく中で感じたこととして、本記事のタイトルにもなっているSLOの導入は早ければ早いほどよいということがあります。もちろん、早ければ何でもよいわけではなく、導入のスピードを重視するあまり重要な要素を見落としては本末転倒です。しかし、早いタイミングでSLOを導入することには多くの利点があると感じました。

8.1 SLO文化を浸透させるハードルが低い

SLOを効果的に運用するためには、開発組織にその文化を浸透させることが不可欠です。一般的に、組織が大きくなるほど新しい文化を浸透させるのは難しくなります。開発組織が拡大するにつれて、SLO文化の浸透には労力と時間が必要となるでしょう。FAANSは、まだ成長段階にあり、開発組織も比較的小さいです。その点において、SLOの概念を関係者に伝える際の障壁が低く、皆で同じ目標に向かいやすい環境でした。これは信頼性への意識向上とSLOに基づいた意思決定が迅速かつ効果的に行えるようになった一因だと考えています。

8.2 SLOはソフトウェア設計の意思決定を支援する

前述の「7.4 技術的な意思決定の改善」からも明らかなように、サービス品質の基準とはソフトウェア開発の非機能要件の一部であり、ソフトウェア設計において重要な役割を果たします。SLOが早期に設定されていることで、開発プロセスの初期段階から信頼性の基準を考慮した意思決定が促進されます。後から信頼性を確保するよりも、最初からその基準を意識した設計をする方が遥かに効率的です。また、設計や実装のトレードオフを明確に理解し、最適なバランスを追求できるようになります。そして、システム全体の安定性が向上し、開発チームはより自信を持ってプロダクトの成長に貢献できるようになると考えています。

8.3 信頼性は事業にとって最初から重要な指標である

そもそもユーザーの信頼性とは事業にとって初期段階から重要な指標です。サービスがローンチされ、ユーザーが実際に利用し始めた瞬間から、信頼性は欠かせない要素となります。ユーザー体験の質を維持するためには、信頼性を継続的に追跡し、改善し続けることが不可欠です。これを怠り、後回しにすることは、事業にとって大きなリスクとなります。

おわりに

本記事では、FAANSにおけるSLOの導入事例と、それによって得られた効果や運用の中での工夫と気付きを紹介しました。SLOの導入は、サービス品質を継続的に改善し、信頼性を維持するための重要なステップでした。導入初期の段階では、SLOに基づくフィードバックループを確立し、運用を通じて改善を重ねることで、一定の成果を達成できたと感じています。

今後の目標は、現在のSLO運用をさらに洗練させ、より効果的なフィードバックループを回し続けることです。その一例として、バーンレートアラートを導入し、エラーバジェットの消費速度をリアルタイムで把握し問題を早期に検知・対応する体制を整備することを検討しています。このような取り組みを通じて、信頼性に対する迅速なアクションをさらに強化し、SLOの達成をより確実にすることを目指します。また、このフェーズで得られた成功体験を基にSLOを定めるシステムの範囲を拡大し、組織全体でSLO文化を深く醸成していきたいと考えています。

本記事が読者の皆さんのSLO導入のきっかけや、導入手順と運用方法の参考となれば幸いです。また、FAANSでは、機能開発と信頼性維持の両方にコミットし、フルサイクルな開発プロセスを実現できるエンジニアを募集しています。私達と共に、信頼性を高めながらプロダクトの価値を最大化していく挑戦をしませんか。

corp.zozo.com

*1:関連記事 FAANSにおけるCloud RunからGKE Autopilotへのリプレイス事例

*2:関連記事 Kubernetesネイティブなワークフローエンジンとは！FAANSでArgo Workflowsを導入した話

*3:関連記事 Cloud FirestoreからPostgreSQLへ移行したお話

*4:なお、このSLAは私達のSLO導入時点におけるものですが、本記事の執筆時点においてもそのSLAに変わりはありません。Google Cloudの公式ドキュメント

*5:関連記事 ZOZOFITにおけるADRを利用した意思決定を残す文化作り

*6:関連記事 Full Cycle Developers at Netflix — Operate What You Build

カテゴリー