ネクストエンジンのSLO導入のこれまでとこれから

この記事はNE開発ブログ/開幕連続投稿企画の20日目の記事です。

現在、NE株式会社のSREとしてネクストエンジンのSLOの導入活動をしています。
この記事では現在までの活動内容と得られた学びを紹介します。

はじまりと動機

2020年から2022年にかけて、オンプレミスで稼働していたネクストエンジンのクラウド移行が実施されました。
マルチテナントの運用の改善もあって、アプリケーションはよりスケーラブルな構成となり、わずかな設定変更でパフォーマンスの調整が可能になりました。
そして監視の強化にも力を入れた結果、システムの様子をそれまでよりも詳細に観測できるようになっていました。

しかしクラウドのメリットを最大限に引き出すには判断基準が不足しています。
DBあたりのテナント収容数を上げた際のレイテンシの低下はどこまでなら許容されるのか、キューイングされたジョブはいつまでに処理されれば良いのか、メンテナンスによる停止は月に何回何時間を上限とするか、など明確な指標がありません。
結果として全てを安全側に倒さざるを得ず"今より良くなるもの"以外は認めることが難しく、変更スピードやコストパフォーマンスに課題感が生じました。

そこで、当時のSREチームでDraft版SLOを作成しました。

Web、バッチ、メール取込という特性の違うワークロードごとに、可用性、レイテンシ、障害対応、セキュリティについてそれぞれ指標と目標を仮置きしてみました。
ユーザーのページビューに対して、1ヶ月のリクエストのうち、最低でも99.9%の割合で、XX秒以内に502, 503, 504以外のレスポンスを返します。のようなインフラのメトリクスを主体とした汎用的なSLOです。

作成後まもなく、仮置きした指標では不十分であると感じ始めます。
ネクストエンジンは巨大なモノリスのサービスです。
ALBへのリクエストは長時間かかることが前提のパスが混在したり、不定期実行のバッチや特定ユーザー向けのバッチも同じコンテナ内で実行されていたりすることもあり、全体でまとめてしまうとネクストエンジンの重要なパフォーマンス低下が見えないことや、ユーザー影響の小さな事象で指標が大きく変動してしまうことがありました。
この改善にはコアとなる重要な処理に着目しフィルタリングする必要があると考えました。
コアとなる重要な処理はクリティカルユーザージャーニー（CUJ)に紐づくものです。
ここから、教科書通りの ①CUJの発見、②SLIの決定、③SLOの策定 のステップを踏んだSLOの再定義が始まりました。

コミュニティ活動

改めてSLOを定義すべく、エンジニア全体に呼びかけコミュニティ活動をはじめました。
みんなが納得できる説得力のあるSLOとするためにはより深いドメイン知識を持つメンバーと協力する必要もありましたし、みんながSLOに責任を持つ当事者意識を共有するために策定の過程から関わって欲しいという狙いもありました。

コミュニティの主な活動はワークショップです。主業務の傍ら参加してくれるエンジニアが多く定期的に決められた時間内での活動を中心にしました。
ワークショップでは手順を踏み徐々にSLOを作り上げていきました。
まずはCUJの見極めです。プロダクトの紹介資料やマニュアル、カスタマーサポートを担当するマネージャーへのヒアリングを参考に、ユーザーがプロダクトに期待することやどんな使い方をしているかを深掘りし、中核となるサービスを絞り込みました。
CUJを元に関連する機能から特に重要な箇所をピックアップし、SLIを決めました。ユーザーごとなのかサーバーごとなのかといった粒感や、どうなれば処理成功なのかといった条件について認識を合わせ、客観的に観測可能なものに落とし込みました。
SLOについては決め手に欠けたため、仮置きで取得開始した後に現状ユーザーは満足しているという前提で調整していくことにしました。
決まったSLOについてドキュメントとダッシュボードを作成し、週次での確認も始めました。

失敗と再計画

当初、SLOダッシュボードが完成した後は、カスタマーサポートのメンバーなど巻き込んでよりユーザーの体験に影響する指標にアップデートしていく計画でした。
しかし完成したダッシュボードをしばらく眺めてみると、全体のリクエストに比例せず常に一定数のエラーが出ている、障害を起こし機能が停止したのにSLIが下がらないなど、明らかに期待する動きをしていませんでした。

原因は仕様の考慮漏れです。
例えば、ユーザーの設定（外部モール連携用のAPIキーなど）が間違っていると連続して毎回失敗し続ける定期実行処理があったとして、現状仕様変更は難しい場合に、ユーザーの設定ミスは許容し、バグやリソース不足による失敗のみをカウントしたいのですが、現状のメトリクスやログでは区別ができませんでした。ユーザーの放置により常にエラーが出てしまいます。

このままSLOのアップデートを進めても、結局見たい値は見ることができない事態になるのは明らかです。
またエンジニア以外の人を巻き込むにあたって、目に見えてわかりやすく役立ちそうなグラフは活動の理解を助けてくれるキーアイテムでした。信頼できないグラフではピンとこない可能性が高いです。
いったん立ち止まり、計画を見直すことにしました。

そこで改めてSLOを作り上げるためのロードマップを作成し、マイルストーンを置き直しました。
組織、定義、運用、ツールの観点で構成した成熟度モデルをベースに組み立てています。

作成の際にはこちらの発表を参考にさせていただきました。

現状まずは、信頼に足る確かなSLOを一つ作り上げることを最初のマイルストーンに置いています。
その過程で必要な情報を収集するための仕組みを構築し、今後SLIが追加され新たな情報が必要な時に使える基盤、ライブラリとして再利用可能な状態を作ろうとしています。

最初のSLIを決めるにあたっては、改めてエンジニア以外も含む全社にアンケートをとり、ネクストエンジンが提供するサービスとは何か、再確認の機会を設けました。結果的にはエンジニア内で話し合った内容と大きな差はなかったものの、広く認識を確認できたことはよかったです。

現在、新たなログ収集の仕組みとSLIの実装を進めています。

学びとこれから

SLOの策定は特に以下の点で難しいと感じています。

• サービスの定義の具体化
• 適切なログの取得

サービスの定義の具体化

ユーザージャーニーから順を追ってサービスを深掘りしていくことの重要さを感じました。
ネクストエンジンはユースケースによって必要最小限な特定の機能だけを使うことが可能です。
機能や使われ方のバリエーションが多すぎて、ケースを絞らなければとりあえずのSLOすら決められなかったです。
CUJを特定した後の、システムの動きの把握、SLIの設定にも苦労しています。バッチ同士のDBロックやユーザー間で共有するリソースで発生する待ち時間などCUJのフロー上は見えない依存が存在しています。これが非同期に処理が進む箇所ではユーザーの目的達成に想定外の待ちが発生するため考慮に入れたSLIにしなければなりません。

SLO策定プロセスに関しては、Googleの公開している設計プロセスに関するブログ記事に検討すべき点などわかりやすくまとまっています。また、テンプレートを見ると成果物をイメージしやすいです。SLIについてはサービスのタイプ別の一般的な例が参考になりました。

またITや監視のリテラシーが高くないメンバーの協力を得る場合には、前提を伝えることにも力を入れなければならないと感じました。
アンケートをとった時に、各機能の信頼性は問い合わせの発生件数を指標にできるという意見が何件かありました。
ユーザーごとの月間平均問い合わせ数とすれば一定の指標にはなりそうです。しかし、"ユーザーが問い合わせによって問題を解決すること"は"ユーザーが複数モールの在庫を連携すること"とは明らかに違った体験です。問い合わせ件数を在庫連携サービスの指標にすると、在庫連携サービスがカスタマーサポートという別のサービスに依存しているため、サポートが窓口を閉じれば在庫連携サービスのSLIが向上してしまいます。今回定義したかったSLIはネクストエンジンの各サービスの性能そのものを示す値です。サポートとは独立した指標が望ましいと考えられます。
こういったすれ違いも前提をしっかり伝えて揃えることでより充実したコミュニケーションに繋げられたかもしれません。
他にも、そもそもどういった情報が取得可能なのかがわからなければ、客観的に観測可能なSLIも提案しようがありません。特定の操作のレスポンスに5秒かかるのは許容されるか？という質問に答えるためには世の中一般に使われるモデルや現状のプロダクトの統計情報も欲しくなります。逆に今のプロダクトでは取得が難しい情報も含めて都度丁寧に伝えておけると良さそうです。

適切なログの取得

SLIが決まってもサービスの構築時から意識されていたものでなければ取得するのも困難なことがあります。
ネクストエンジンの大部分は、ユーザーは設定だけしておけば自動で処理が進みます。この時、①データの変更（≒要求の発生）が起きる、②ジョブがエンキューされる、③ワーカーが処理するというプロセスが非同期に連動しています。それぞれの実行時間は取得できていても、間の時間や一連の紐付けがわからずにジャーニーの目標達成を測れない課題がありました。
解決策や事例を探しても意外と見つかりません。まずはログの取得など簡単な解決を試みていますが、ちゃんとするならリファクタリングやリアーキテクチャが望ましいかもしれません。プロダクトごとに最適な方法を模索する必要がありそうです。

現在、SLO導入活動は作成したロードマップに沿って再始動したところです。今後はSLOの運用方法も固めていかねばなりません。
一方でプロダクトの技術的負債を返済する動きも徐々に進んでいます。
改めて"サービス"の定義を見直し、安定した、信頼できるサービスに生まれ変わるフェーズにしたいと思います。