こちらは Makuake Advent Calendar 2022 の記事です。

ごあいさつ

ご無沙汰しております。株式会社マクアケ SRE チームの dev.aoki です。
アドカレが無いと特段発信をしない不精者なもので、一年ぶりの投稿になります。

マクアケでは、2013 年からアタラシイものや体験の応援購入サービス「Makuake (マクアケ)」というオンラインプラットフォームを提供しています。
https://www.makuake.com/

今回の記事では、SRE らしく SLI/SLO について書いていこうと思います。とは言え、技術的な話ではあまりなく、組織で活用していくための活動 (の真っ最中) で実際に起きたことをもとに、僕がもやもやした事例なんぞ書いていこうかなと思います。

SLI/SLO とは

オライリーのいわゆる SRE 本で語られる、 Google の提唱したシステムの信頼性に対する指標/その目標値ですね。もう語られ尽くしていると思うので僕からあえて語ることはないですが、個人的には New Relic さんの記事が非常にわかりやすくて参考になりました。

僕の理解としては、重要なポイントは以下かなと。

システムが安定している状態の定義を 自分たちで定める
- Critical User Journey (CUJ) が守られている状態かどうか
その結果、関係者の間で 信頼性に対する共通の語彙 (と理解) が生まれる
過剰に厳しくしない、過剰に達成もしないことで健全な運用が担保される

マクアケの進め方と現況

はっきり言って道半ばです。なのでこんな記事が生まれているわけですね。

SLI/SLO の展望自体は自分の入社 (2021 年 5 月) より前からあったのですが、何度も部分的にチーム単位でやっては頓挫、あるいは形骸化、みたいなことをしていたみたいで。自分の入社あたりで SRE チームが独立し、人数的にも SRE 的な活動が始められるようになってきたため、SRE チームがオーナーシップをもって本格的に動かし始めた、といった感じでした。

SLI/SLO の設計

Makuake の SLO は、現在 2 つの観点で作成しています。

一般的には Critical User Journey をもとにして分析し、SLI/SLO を構築するものと思うので、Makuake に対してもこれを構築し、 Main SLO と名付けました。

一方で、開発チームの関心ごとを考慮すると、全体よりも詳細なレベルで、自分の担当箇所の信頼性を把握したい、という需要があると考えました。なので Makuake を支えるマイクロサービスや通知機構、定期ジョブ実行基盤なども、それぞれに見たいメトリクスをもとにした SLI/SLO を構築しました。こちらは Sub SLO と名付けています。

進め方

全体的には以下のような流れで進行しています。

SRE による事前準備
- 勝手に SLI/SLO を設定してダッシュボード化
組織全体でチェック/調整の習慣付け
- 定期的に値を読み上げ、少なくとも変動などをみんなで把握する
- この時点では正しく信頼性を表現できているとは思っていない
開発チームへのオーナーシップ引き渡し
- 正しい値ってどれなんだっけって話を擦り合わせて担当チームに持ってもらう
- ここでようやく、本来の意味で正しい SLI/SLO になる
本運用
- エラーバジェット運用するなり、アラート鳴らすなり
- とかく各チームが安心して開発できるようにする

初期構築を乱暴に SRE が進め、それを見ながら誤りを修正しつつ、開発チーム側の理解度を高めていって、その上で SLO の運用ごと引き渡す、といった流れになっています。現在はこの中の 3 つめのステップにおり、定期的に (具体的には月次で) 開発チームと SLO 見直し会 という会議を開き、状況確認と、定義や計測方法の正しさについて会話をしています。チームによって進捗はまちまちで、ほぼ運用をお任せしてアドバイザリ程度の関わりしかしていないチームもあれば、そもそも SLO をうまく定義できない (この理由は後述) といったチームもあります。

また、本運用までの流れは エンジニアだけで進めました。 本来はプロダクトオーナーや、最終的には経営層にまで活用してもらうのが理想的なことは分かっていつつ、多忙な事業側の責任者を捕まえて進めるのは困難と判断しました。まずは動いているものを作り、運用し、整えた上で更なる調整を事業側の人たちを徐々に巻き込んで拡大していく、という思想で進めています (そしてこれは後述しますが、今ハードルになっています)。

気をつけている点

事例調査をしている中で、 SLO で一番大事なのは きちんと運用してもらうこと だと感じました。なので、とにかく ドラスティックに変えずに、意識の浸透を丁寧にやる ことを意識しています。活用イメージをきちんと理解してもらってじっくりと組織に浸透させていきたいです。

SLO を設定したのだから、早くエラーバジェット運用したい、させたい！みたいな気持ちもあるのですが、適切な SLO を定義できない状態でこれを急ぐと、開発チームがただただ疲弊し、開発効率が下がっていくような予想が立ちました。なので 初期はエラーバジェットや運用ルール (リリース凍結とか) などを考えずに、まずは正しい SLO を定義できるようになりたいと意識さえる ことに注力して開発チームに働きかけています。幸いなことに、これまでの開発者達の努力によって、定常的な信頼性のリスクはあまり感じない 状態であること、そして、ルールに拘らず 主体性を持って障害時に対応してくれる組織文化である ことも、この判断を後押ししました。

とはいえ活用しないままのゆるっとした SLI/SLO だと、もう一つのバッドパターンである 誰も見なくなる みたいなことに向かいそうなので、そこは月次での見直し会で担保し、意識付けをしています。これもこれで疲弊する会議になりかねないので、社内的には お茶会 と銘打って、お茶菓子食べながら楽しくやろうぜ！って言ってるんですが、実際にお菓子を食べてくれる人はなかなかおらず、僕というコンテンツのエンターテイメント性を高めねばならないなと感じているところです (本当か？)

一年半ほど進めて、起きたこと、起きなかったこと

そんなこんなで進めていて、そろそろこの活動自体は認知を得て定着しつつあります。とは言え、じゃあうまく行っているかというとそうでもなく。色々と起きたことについて考察していきましょう。

想定していたハードル

先に結論を言うと、こっちは思ったより問題が起きなかったです。

1. そもそものメンバーによる抵抗感

事例調査をしていた上では、とにかくこれがリスクとして強く感じました。SLO に振り回された結果、チームが疲弊して SLO を用いること自体に否定的な意見を持ってしまうのではないか？そんなふうに思ったので、前述のとおり非常に緩い運用から徐々に活用に持ち込むスタイルを取っています。

それが功を奏したのか、いや、個人的にはむしろ組織文化によるところだと思っていますが、実は抵抗はほぼ受けることがありませんでした。唯一あったのが SLO の定義や運用は SRE 側で持って欲しい (開発は機能開発に集中したい) というものです。色々議論はありましたが、結論、組織ポリシーとして 全エンジニアがサービス運用に関する感度を高める学習の場が必要 という CTO の見解をもらい、合意していくことができました。

脱線しましたが、SLI/SLO そのものへのネガティブな意見は今のところ聞いていないです。サービス全体をよりよくするミッション意識が、開発組織全体的に強く浸透していることの結果ではないかと思っています。

2. 技術的なハードル

SLI/SLO を定義したり読み解いたり、実際にダッシュボードを構築したりするためには、可観測性周りの整備に関わる技術スタックが必要になります。Makuake のスタックだと、主に以下の領域になります。

AWS/GCP の取得メトリクス
NGINX のログ出力制御
Datadog によるメトリクス分析・集計・監視・SLO 構築など
(アプリケーションから出力されているログの知識)

ここも割と難航を想定していたのですが、無いとは言わないまでも、危惧していたほどではなかったです。要するに学習をすること、知見共有をしあうことで解決する問題であり、エンジニアの生態的には困難に感じるほどのものではなかったかなと。

学習支援のため、Makuake としてよく活用する機能についてのまとめ記事や、SLO を立てる時に見たものや、手順、思考プロセスなどをまとめた社内向けドキュメントを整備したりもしました。特に Datadog 周りは、アラートなどはみんな見ているものの、実際に設定をしているメンバーは限られているので、丁寧めに作成をしています。実際にどれくらい有益なのかはまだ不明ですが、出したタイミングでの反応は割と良かったので、活用されているといいなあと思っています。

想定していなかったハードル

一方で、想定外の問題の方がよほど頭を悩まさせられています。そういうものですね、人生。

1. SLI/SLO のチームアサイン

先述の通り、僕らは Main / Sub の二種類の SLI/SLO を設定しました。これらの運用は、可能であれば開発チームに運用を持ってもらう思想です。

SRE で全体を見る方法も考えられましたが、これをしなかった理由としては、SLI/SLO は基本的にはユーザ体験を損なわないための指標/目標であるという考えです。つまり、事情をよく知っているチーム (担当開発チーム) が最も適切に定義できると考えており、例えば値や計測方法を調整するにしても、SRE 側で行うのが困難であると考えたからです。このため、あまりにも横断的なリソースでアサインが困難なものだけは SRE が持つにせよ、基本的にはチームへのアサインを進めてきました。

ところで、マクアケの開発チームはミッションごとに分かれているのですが、この分ける際の切り口が実は異なるものが二種類あります。

施策単位でのチーム組成
- プロジェクトの質を向上する施策をやる、ユーザの定着のための施策をやる、とかとか
基盤コンポーネント単位でのチーム組成
- 決済基盤、認証基盤、通知基盤、とかとか

このうち、後者は概ねコンポーネント (≒マイクロサービス) に対して責務を持ちやすく、結果チームと SLI/SLO の紐付けがスムーズに行えました。一方前者は、コードベース的には非常に多岐に渡る範囲を見ることになります (Web サーバ本体、API サーバ、通知系ロジック、定期実行バッチ、とかとか)。こうなってくると、このチームがどの SLO を持つとかではなく、共有財産として使われてるね、ってものがめちゃくちゃ多くなってしまいました。とは言えそこをよく触るよってな濃淡があったりもしますし、全部 SRE のものね、ってなるのは本末転倒感があるので、多少強引にでもアサインをしていこうと現在調整をしていたりもします。

2. 指標の決定権を持てる人を探す

これまたチーム的には施策ベースの切り口のチームで発生した問題です。基盤コンポーネント系を開発保守しているチームの場合、　Sub SLO の決定はエンジニア側で設定することが可能でした。つまり、システム都合としてどれくらいの秒数でレスポンスが返ってこないと困りそう、とか、この時間帯は絶対にアクセスされないから信頼性への影響はない、とか、機能的なロジックだけである程度判定可能だからです。そのため日常的に機能仕様をエンジニア側が決めるフローで開発が進んでいました。

一方、施策ベースのチーム側は、その意思決定のためにプロダクトオーナーが各チームについています。各種仕様の意思決定は、エンジニア側から情報提供のサポートを受けつつ、プロダクトオーナーが責務を持つフローでした。このため、エンジニアのみでまず進めてきた SLI/SLO の運用ですが、見直し会のたびに 「うーんここなー」「多分こんな感じだと思うんだけど……PO に相談かな」「自分たちでは判断しきれないっすね」 みたいなことになり、結果この座組みで進めるのは困難だね、という着地になりました。はい伏線回収。

ということで今まさに絶賛準備中という感じですが、 プロダクトオーナー×開発チーム×SRE という新しい座組みでの運用を進めようとしています。プロダクトオーナー陣には以前ざっくりとしたレベルでした SLI/SLO を導入したい動機が話せていなかったのと、メンバーもその時から増えたので、再度しっかりと意義の説明、今後の運用拡大に向けたイメージ、目的感を合わせて、月次での SLO 見直し会に巻き込んでいくという予定で検討を進めています。

考察

所感として、 SLI/SLO の運用のための肝は 組織文化 と 組織構造 なんじゃないか、と今は思っています。主体性の強い組織文化に助けられたことが多い点、コンウェイの法則のような意味で SLI/SLO を組織構成に当てはめる困難にぶつかっている点などから、そう考察できます。

また組織は変化していきます。僕の入社してからの一年半ほどでも、チームの再編や解散などがありました。それにサービスコンポーネントを完全追従することは非現実的です。となると、組織構造とはまた別に SLI/SLO を見る構造を持つと有益なのかな？なんて妄想をしたりはしています。

あとは、そもそもみんなで見るはずの Main SLO こそが肝であり、Sub SLO はその名の通りオプショナルな位置付けです。チーム再編の影響で受け取り先が困る SLO が生まれたり、そもそも色々なチームが触っていてオーナーシップを持ちづらいコンポーネントの SLO があったり、と疲弊するなら、これ見る必要あるのかな……？いやいやしかし不安定だとみんな困るやつだし……みたいなことをグルグルしながら、今なお組織にベストフィットするような SLO 運用を模索している状況です。

万人向けの正解はたぶん無いやつな気がしています。

おわりに

現在進行形で悩んでいることの記事なので、全体的に歯切れが悪くて恐縮ですが、同じように悩んでいる人もいるんじゃないかなって思って (実際自分がこの活動を始める時には先行事例がとにかくためになった) 、モヤモヤしたまま書きました。

今後何か妙案が生まれて改善されたり、泥臭い活動が実を結んでうまく活用できそうになったら、そこでの結論についても発信していけたらと思います。