こんにちは。SREチームの宮後（みやうしろ）です。

前回、「SREチーム発足から2年間の取り組み〜急成長するモビリティSaaSで信頼性とアジリティの両立を目指す～」でSREチームの発足から今までの取り組みについて紹介しました。今回は記事の中の「信頼性に対する取り組み」でも触れたSLI/SLOの策定・運用についての話を紹介します。なお、SLI/SLO自体が何かについては、詳しく説明された記事が世の中に溢れているのでそちらに譲りたいと思います。

SLI/SLOの策定から改善の取り組み

Park Direct（パークダイレクト）ではSLI/SLOを初めて策定してからこれまでに２度改善をしており、現在、３度目の改善に取り組んでいます。まずはこれまでの取り組みについて順番に紹介します。

最初のSLI/SLO

Park Directでは2023年3月に初めてSLI/SLOを策定し運用を開始しました。
初めての取り組みでしたので『SRE サイトリライアビリティエンジニアリング』を参考に、当時計測可能だったApplication Load Balancer（以下、ALB）のメトリクスを使用し、フロントエンドとバックエンドに対してリクエスト成功率とレイテンシ（90パーセンタイル）を次のように定義しました。

１度目の改善：APIのグルーピング

SLI/SLOを初めて策定してから2ヶ月ほど運用する中で次のような課題がでてきました。

• 全APIをまとめたレイテンシで計測しているため閾値が大きな値となってしまう

• 速いAPIのレイテンシが悪化してもSLIの変化に現れず検知できない

これらの課題を踏まえて、1度目の改善ではAPIをHTTPメソッドでグルーピングすることで大まかに速いAPIと遅いAPIを分類することにしました。

他にもAPIのパス階層でのグルーピングや、HTTPメソッドとパス階層の組み合わせなども検討しましたが、計測結果に大きな差がなかったので低コストで運用可能なHTTPメソッドでのグルーピングに落ち着きました。

この変更に伴い、計測に使用していたALBのメトリクスではHTTPメソッドを識別することができなかったため、Datadog APMで計測されるメトリクスを使用するように変更しました。

２度目の改善：時間ベースからイベントベースへ

１度目の改善からさらに2ヶ月程運用し、深夜帯などのリクエスト数が減少する時間帯に、1回の遅いリクエストでSLIが大幅に低下してしまうという課題がでてきました。

これはレイテンシのSLIを閾値を満たしている時間で計測していたこと（以下、時間ベース）に起因していました。時間ベースの計測ではリクエスト数の大小によって、遅いリクエストのSLIに対するウェイトが変わってきてしまいます。これは、ある時間帯では1000分の1のリクエストが閾値を下回っても0.1%の影響だが、別の時間帯で10分の1のリクエストが閾値を下回ると10%の影響となる、といった具合です。

そこで、2度目の改善ではリクエスト成功率と同様に、レイテンシが閾値を満たすリクエストの割合（イベントベース）で計測するように変更しました。こうすることで期間中の全リクエスト数分の閾値を満たすリクエスト数となるため、全てのリクエストを同様のウェイトで扱うことが可能になります。

この変更を実装する上で、Datadog APMで計測されるメトリクスを利用することはできなくなったため、Datadogのlog-based metricの機能を使いNginxのアクセスログをメトリクス化することで対応しました。

現在はこの2度目の改善の状態で運用しています。

クリティカルユーザージャーニーをもとにしたSLI/SLO策定の取り組み

これまでSLI/SLOを策定し２度の改善を経て、着実に改善のサイクルを回せるようになってきました。しかし、まだ真に顧客の満足度と関連の強いSLI/SLOを策定できていないと感じていたこともあったので、2023年9月頃からクリティカルユーザージャーニー（CUJ）を定義した上で、SLI/SLOを策定する取り組みをはじめました。

「急成長モビリティSaaSの開発組織の変遷と組織デザインで大事にしていること」でも紹介されていますが、Park DirectはBtoBtoCのサービスでtoCの借主様、toBの不動産管理会社様、自社のカスタマーサクセス（CS）メンバーをユーザと位置付けています。そのため、CUJはこの3方向のユーザーに対して定義することにしました。

まず始めに「toCの借主様」向けについてです。
借主様は駐車場を探し契約することを目的にPark Directを使用するため次の3つをCUJとして定義することにしました。

1. トップページを開く

2. 駐車場を検索する

3. 駐車場を契約する

続いて「toBの不動産管理会社様」向けについてです。
不動産管理会社様はtoCとは異なりPark Directの管理画面を利用して、主に駐車場と契約者（借主）様の管理をおこなっています。そこで次の４つをCUJとして定義することにしました。

1. 管理画面にログインする

2. 駐車場情報を確認／登録／更新する

3. 顧客情報を確認／登録／更新する

4. サポートへ問い合わせる

Park Directの管理画面にはCSに対して問い合わせる機能があります。システム上でスムーズに問合せができることは満足度に直結する部分と考えCUJに含めています。

最後に「自社のCSメンバー」向けについてです。
自社のCSメンバーは不動産管理会社様と同様にPark Directの管理画面を利用しています。CSメンバー専用のものも含めて約50程の画面、100を超える機能があります。また、CSの中でも部署が細分化されており、部署毎に使用する機能やその重要度が異なっている状況でしたのでCUJの定義はとても難航しました。

始めは部署ごとにCUJを定義していくことを検討していましたが、定義できたとしても数が多くなったり、異なるCUJだが同じ機能を利用していてSLIに落とし込むことを考えると、日々の運用やメンテナンスの負荷が高くなってしまうと考えました。

そのため、「自社のCSメンバー」向けについては、ユーザージャーニーで考えるのではなく、「複数の部署が共通で利用する機能 = 重要な機能」と考えるようにしました。そこで、管理機能の利用状況を把握するために、部署毎の利用機能と重要度を次のように整理しました。

上記の表をもとに、各部署の利用する機能が50%以上になるように機能をピックアップしました。

そして、ピックアップした機能をグルーピング化することでCUJの代替とし、最終的には以下のような定義となりました。

• ログイン関連

• 拠点関連

• 顧客関連

• 請求・入金関連

以上で３方向のユーザに対するCUJを定義できたので、まずは今までと同様にリクエスト成功率とレイテンシーをSLIとして定義し計測を開始しています。

こちらの取り組みは手探りで進めている状況のため、今後の運用の中で試行錯誤を繰り返して改善していくことになると思っています。

課題

以上の通り、策定から既に二度の改善を行ってきましたが、まだまだ課題がなくなったわけではありません。

課題１：エラーバジェットポリシー

SLI/SLOを策定し運用をしていますが、エラーバジェットポリシーを明確に策定できていないという課題があります。

現在、エラーバジェットが50%を下回ったら、SREチームで原因の調査と対処をおこなうというゆるいルールを設けて運用しています。しかし、エラーバジェットを使い切ってしまった時の対応については定義できていません。現在のところは幸いにも改善のサイクルを回せているので、エラーバジェットを使い切る事態には至っていないですが今後に備えて定義が必要だと考えています。

エラーバジェットポリシーとして使い切った場合にはリリースを止めて回復に努める事例などがありますが、リリースを完全に止めてしまうのは今の事業フェーズでは許容できないため、今後は自分達に合ったエラーバジェットポリシーを定義していきたいと考えています。

課題２：開発チームとの協業

SLI/SLOを策定し運用はしているもののSREチーム内に閉じてしまっているという課題もあります。

これまでの取り組みの中で当然開発チームへのヒアリングなどをおこなってきましたが、日々のSLI/SLOの状況確認や悪化時の対応はほぼSREチームが実施している状況にあります。これは、SREチームがSLI/SLOの活用方法などを開発チームに伝えられていないことや開発リソース不足などの問題に起因していると考えています。

各CUJに対してオーナーシップを持つチームを決めて運用してもらうというような事例を見たことがありますが、我々も今あまり負担が大きくならない形で開発チームを巻き込み、よりオープンな運用方法を考えていきたいと思います。

今後やっていきたいこと

直近では前述した２つの課題の解決に取り組んでいく予定ですが、もう少し先の未来では次のようなことにも取り組みたいと考えています。

SLIと顧客満足度との相関関係の確認

SLIはユーザーの満足度に強い相関のある指標を計測することで信頼性を計測する手法です。しかし、現在策定しているSLIがユーザー満足度と強く相関があるかを明確には確認できていません（当たらずといえども遠からずだとは思っています）。

サイトの離脱率やコンバージョン率などと現在のSLIやその他のシステム的なデータを分析することで、SLOの根拠にできたり、新たな指標を見つけることに繋がるのではと考えています。そのため、一区切り付いたタイミングで分析してみたいと思っています。

他サービスに対するSLI/SLOの策定と運用

ニーリーではPark Directだけでなく、法人向けにPark Direct for Businessというサービスを提供しています。こちらもPark Directと同様に事業上重要なサービスとなるため、SLI/SLOを策定することでしっかりと信頼性を計測していきたいと考えています。

また、サービスとは異なりますがニーリーにはサクセスエンジニアリングという、機能開発とは別のアプローチ（RPAなど）でユーザサクセスをサポートするエンジニアリングチームが存在します。こちらのチームの取り組みについても同様にSLI/SLOを策定できないか考えてみたいと思っています。

さいごに

ここ１年間のSREでのSLI/SLOに関する取り組みを紹介しました。まだまだ課題は多くありますが、着実に進んでおり改善のサイクルを回せるようになってきていると思います。
Park Directは3方向のユーザが存在し、 それぞれで大きく性質が異なるシステムです。そんな中でSLI/SLOを策定し運用していくことは難しいですが、とてもチャレンジングな取り組みだと感じています。この記事を読んで少しでも興味をもっていただいた方は是非、気軽にお声がけください！

株式会社ニーリー　プロダクト開発本部　プラットフォーム開発グループ
宮後 啓介　Keisuke Miyaushiro
2011年に株式会社日立ソリューションズに新卒入社。Web系業務システムのスクラッチ開発に従事。2017年2月にヤフー株式会社に入社。Yahoo!メール、PayPayフリマのサービス開発やSWATとして複数サービスの開発支援に従事。2023年3月に株式会社ニーリーに入社。