BASEプロダクトチームブログ

ネットショップ作成サービス「BASE ( https://thebase.in )」、ショッピングアプリ「BASE ( https://thebase.in/sp )」のプロダクトチームによるブログです。

BASEにおけるサービスレベルマネジメントのこれまでとこれから

はじめに

この記事は BASE アドベントカレンダー21日目の記事です。

devblog.thebase.in

こんにちは、バックエンドエンジニアの小笠原（@yukineko_819）です。

今回は、私がこの2年間ほどをかけて取り組んできたBASEにおけるサービスレベルマネジメントの取り組みの歩みと、今後の展望についてお話しようと思います。

始まり

最初のきっかけは、New Relic社主催のFutureStack Tokyo 2023に参加したことでした。

devblog.thebase.in

BASEではこれより以前からNew Relicを導入して活用していましたが、イベントの参加を通じてまだまだNew Relicを十分に活かしきれていなかったことを知りました。

そして、ここではじめてサービスレベルマネジメントという概念を知り、私たちも取り組んでみようか、という話になりました。

最初の一歩

まずは小さく身近なところから始めてみようということで、当時の所属チームが担当していたCRM領域、特に当時開発中であったメンバーシップAppにおけるSLI/SLOを考えるところからスタートしました。

とは言っても最初は何もわからない状態からのスタートだったため、New RelicやGoogleが公開しているSLOに関する資料や、他社事例のテックブログなどを参考にインプットを重ねながら、およそ2ヶ月をかけて以下のような議論を進めていました。

  • メンバーシップAppにおける絶対に毀損してはいけない体験とは何か？
  • フロントエンド、ALB、バックエンドAPI、どのレイヤーのイベントをSLIとするのか？
  • SLIにおける「成功のイベント数」はどのようなイベントを成功とみなすのか？
  • SLOは何を基準に定めれば良いのか？

活動の中で「購入者がメンバーシップ会員として商品を購入することができる」という体験をCritical User Journey(CUJ)の一つとして定めてSLOを設定しようと議論を重ねていきましたが、残念ながら結局SLOを設定するところまで至ることはできませんでした。

しかし、この2ヶ月間の活動を通して取り組んだメンバーの間では、CUJを検討する過程でそのサービスが提供している価値をより深く理解する必要があり、加えて適切なSLIを選定するためにはそのサービスがどのような機能やアーキテクチャ、インフラストラクチャで構成されているのかを理解する必要がある、ということを強く認識することができた活動でした。

ある1領域のSLMからサービス全体のSLMへ

SLMとは何なのか、そしてSLOを設定することの難しさを痛感した我々ではありましたが、次の一歩を踏み出しました。

一般的なECサービスが提供しているようなECサイトを公開したり商品を購入したりといった体験は、ショップオーナーや購入者から見ても最もコアとなる体験であり、BASEとしてもそれらの体験は重要であるはず、という考えのもと、「ショップを開設して商品を登録して出品し、その商品が実際に購入された後、発送を完了してショップに売上が立つ」という一つのサイクルをBASEにおける最も重要な体験であると定義して、このサイクルを構成するCUJ群に「Tier1 CUJ」と名付けてSLOを設定することにしました。

SLOの設定にあたっては、最初から良いものを作ろうと深く悩みすぎたことでなかなかSLOを設定するところまで辿り着けなかった前回の反省を踏まえ、ひとまずは計測することを第一目標として掲げ、集まった有志数人でこれらのCUJに対してSLOを設定していきました。

これまでの「商品ページが重い」「機能がうまく動いていないというお問い合わせが何件か来ている」といった定性的な指標に加えて、この水準でこのくらいの人が使えている、のようにSLOという定量的な指標で表現できるようになった瞬間でした。 ここまで取り組んできたサービスレベルマネジメントの取り組みとして、一つの大きな成果です。

惜しむらくは、それを知っているのが設定を行った数名の有志だけであること、質より速度を優先したことで設定したメンバー達ですらSLOの妥当性に対する信頼性に不安があったこと、そしてSLOが未達でもそれを改善するという活動に繋げるまでのフローをまだ整備できていないためにSLO未達の状態が続いてもアクションを取れずにいる、ということでした...

一般的なSLOからBASEのSLOへ

さて、いろいろ課題が残るもののTier1 CUJをカバーするようにSLOを設定することはひとまずできたので、次の段階としてよりSLOの精度をあげる取り組みをすることにしました。 サービスレベルマネジメントとしては運用・監視・改善のサイクルを回すことが大事であり、改善の部分が抜け落ちてしまっている状態ではありましたが、SLOの精度を上げてアラートがなった場合はなおさねばならない状況を作った方が運用を軌道に乗せるにはスムーズだろう、と判断してのことです。

購入にまつわる決済や発送の領域に詳しいエンジニア、インフラストラクチャに詳しいSREチーム、アーキテクチャに詳しいplatformチームといったメンバーに声をかけて総勢12名の「サービスレベル定点観測会」という会議体を組成しました。 BASEのサービスやTier1 CUJの体験を実現する各種機能に対して深い知識と理解を持っているメンバーでSLO検討を実施することで、より実態に即した質の高いSLOを設定できると考えたためです。

この取り組みはうまくいった部分もあれば、失敗した部分もありました。

成功した点は以下が挙げられます。

  • 参加したメンバーにサービスレベルマネジメントの意義を理解してもらうことができた
  • CUJの検討からSLOを設定するところまでの1サイクルを経験してもらうことができた
  • 実際に幾つかのCUJに対して、より検討を深めた上でSLOを追加したり置き換えたり、そのままで良いという確認が取れたりといったSLOの品質向上が実現できた

一方で失敗した点としては、

  • メンバーをいきなり数倍に増やしたがそれに対応した会議体のマネジメントは私のキャパシティを超えていた
  • 二週間に一度の開催枠の中で活動をしていたので都度どこまでやったかの思い出し作業が発生した

といった点が反省点でした。

SLI/SLOワークショップの開催

また、サービスレベル定点観測会の取り組みとは別に、New RelicのBASEのサポート担当の方に支援いただき、BASE社内向けのSLI/SLOワークショップを開催しました。 参加するメンバーが多く2回に分けて開催したのですが、1回目はNew Relicの方が、2回目はBASE社内のエンジニアが進行を担当して、どちらの回も大変好評で良い結果となりました。

ワークショップによって一定の認知を広げることができたことで、これ以降開発チームが自発的にリリース予定の機能についてSLOを設定してみるといった事例も見受けられ、BASEにサービスレベルマネジメントの種をまいたとても重要な施策だったと思います。

SLOの再定義とエンジニア以外との協力

いきなり少し規模を大きくしすぎたという前回の反省から、メリットの部分は維持しつつ1チームとして機動力高く動けそうな人数として4人にまで絞り込み、改めてスタートしました。

そしてある程度品質も向上したSLOが揃ってきたため、次のフェーズとしてこのSLOをエンジニアが活用する運用指標の一つというだけではなくBASEとして共通の守るべきサービス品質基準として整えていくために、改めてTier1 CUJを以下のように整理しなおしました。

区分 内容
Revenue Critical 商品の購入や注文の発送など、BASEの売上に直結する最重要のCUJ群
EC Service Core ECサービスとして一般的に備えているCUJのうち、Revenue Criticalに該当しないCUJ群
Engagement Support ショップオーナーの集客をサポートするCUJ群

その上で、この区分やCUJ群がBASEとして重要であるとすることに違和感がないか、不足がないか、といった観点でエンジニア以外のチームとも相談を実施し、ここに違和感がないと合意した上でまだ設定されていない箇所のSLOの設定を進めました。 特にRevenue Criticalについては事業KPIに強く関連するCUJに焦点を当てて、事業KPIがどのような要素から構成されているのかを紐解き、そこからよりビジネスと相関を持ちうるSLOを選定して設定することを進めていきました。

エンジニアの指標からみんなで見る指標へ

同時に、New Relic上で管理しているSLOを誰でも見ることのできる指標として整備し、事業KPIをはじめとする各種データと絡めて分析ができる環境を整える取り組みにも着手しました。いわゆるビジネスオブザーバビリティと言われる取り組みで、具体的には以下の2点を実施しました。

  1. 毎月、先月のSLOが達成できていたか、できなかった場合どのような要因があったのか、という点をサービスベルサマリーレポートとしてスライドにまとめSlack上で全社共有する
  2. New Relic上で設定・管理しているSLOを、MetricデータをNerdGraph APIを用いてBigQueryに溜め込むことでLookerで閲覧できるようにする

2のSLOをLookerで閲覧できるようにした理由は、エンジニア職以外はLookerを使ってデータの分析や事業KPIの分析などを行なっていたためです。BASEではエンジニアは全員がNew Relicのアカウントを付与されているのですが、エンジニア職以外はLookerを使ってデータの分析や事業KPIの分析などを行なっており、New Relicのアカウントを持っている方はほぼいませんでした。 データ資産という意味でもLookerで分析するために整えられた各種データが揃っている状態だったため、改めてNew Relicにそれらのビジネスメトリクスを取り込むよりは、New Relic上にしかないSLOのデータもLooker上で分析できるようにして統一する方が良い、と考えたためです。

これらの取り組みはすぐに効果が出て全員がSLOに興味を持って活用してくれるようになる類のものではありませんが、それでも今まで見ることのできなかったデータを公開したこと、定期的にそのデータの見方や分析内容を発信すること、には意義があったと思っています。

データを公開したとして本当に興味を持ってもらえるのだろうか、データの公開よりも先にやった方がいいことがあるのではないか、という点はサービスレベル定点観測会のメンバーとしても不安を抱えながら作業を進めていましたが、いざ公開してみると詳しく話を聞いてみたい、この応答速度のSLOは維持できているとしても遅いと思うので改善したほうがいいのではないか、といったような声を何件かかけてもらうことができるようになっていきました。

SLOでサービスの品質を定量的に観測して維持するための改善をしていく、というサービスレベルマネジメントを全社で実施していくことの芽が出始めたことを実感しました。

全体を俯瞰するSLOから、どこに影響があったのかわかるSLOへ

SLOを設定する上で難しいなと感じるのは、どこをSLIとして定義するか、という選定の部分だと思います。例えば一つ一つのAPI単位で細かく設定することもできてしまいますし、あるいはもっと大雑把にフロントエンドの画面描画を指標として設定することもできます。

サービスレベル定点観測会では、購入体験を支えるカート機能はとりわけ重要なサービスであると考え、次の観点としてこのカートでの購入体験をより詳細にSLOでカバーしていくことを目標としました。 ビジネス面でも大量のトラフィックを高速に処理できるかどうかは事業KPIであるGMVの増加に影響がありますし、ユーザー体験の面でも商品を購入するというECサービスを使用する購買層のユーザーとしては最もコアとなる価値体験を司る部分です。

単に購入が正常に高速に完了できたのか、という指標だけではなく購入者のカート体験として「カートに商品を追加する」「カート内の送り先情報を編集する」「確認画面で内容が正しいかを確認する」といった、購入を行う上での一連の体験を全て洗い出し、必要な箇所を選定してSLOを設定していきました。 これにより、購入体験に関してより具体的にどのような影響が出ていたのかを把握できるようになりました。

ここから、さらに一歩先へ

このように、手探りで模索を続けながらも、サービス全体を俯瞰してどこに何が起こっているかを把握する、ビジネス戦略に強く影響がある箇所に問題が起きていないかを把握する、コアとなるユーザー体験で快適なサービスを提供できている、といった様々な角度観点からアプローチをかけてBASEとして重要なサービス価値とは何か、どこにSLOを設定していくべきかを考えて進めてきました。

ここまでの活動を通して、サービスレベル定点観測会の中にも、それぞれ自発的にSLOの設定にチャレンジしてくれたエンジニア達の中にも、その知見がだいぶ溜まってきたのではないかと思います。

次なるチャレンジとして、来年からは今までサービスレベル定点観測会が推進してきたサービスレベルマネジメントを、いよいよ開発組織全体で分担して担当していくということに挑戦していきたいと考えています。

おわりに

改めて振り返ってみると、上長や同僚に大いに助けてもらいながら、なんとかここまで形にしようと賛同し協力してくれた皆さんと一緒に一歩一歩、少しずつ進んできた2年間だったと思います。

特に印象深いのは、誰に相談を持ちかけてもサービスレベルマネジメントの意義を理解していただけて、その上で「ぜひ一緒にやりましょう！」という言葉をいただけたことです。 より良いユーザー体験を提供するため、安定してサービスを提供していくためには協力を惜しまない、という温かい後押しが私の背中を常に支えてくれていました。

ようやくここまで辿り着き、そしてまだまだここからという状態ではありますが、引き続きユーザーに安定してサービスを提供していけるようにサービスレベルマネジメントの取り組みを推進していきます。

最後に、BASEでは今後の事業成長を一緒に支えてくれるエンジニアを募集しています。 ご興味があれば、ぜひ採用情報をご覧ください。

binc.jp

明日のBASEアドベントカレンダーは松原(@simezi9)さんの記事です。お楽しみに！