症状検索エンジン「ユビー」の共通基盤を支えるシステム運用改善活動
こんにちは、syucream です。最近は業務で、症状検索エンジン「ユビー」 のプロダクト開発に携わっています。
お陰様で症状検索エンジン「ユビー」はユーザ数も伸びて事業的にも重要なプロダクトとなってきています。プロダクトの成長に伴い、関わるチーム・エンジニアも増えて活発に機能開発がされています。一方で現在のスケールが見えてきたフェーズにおいて、今まで多少雰囲気でシステム運用してきたことの反動も起こっています。本記事ではシステム運用の観点で直近やってきたことやこれから取り組もうとしていることについて記述します。
職人芸での運用、カオスなエラー捕捉体制、低いオブザーバビリティ
今年初め頃はまだまだ属人性の高いシステム運用を行っていました。何かトラブルが発生した場合に、感度が高いエンジニアが勘や職人芸で対応しているシーンが多々ありました。システム運用はやや職人芸が輝く性質があるとは思われますが、属人的であるゆえプロダクトがスケールし始めていることを考えるとこのバス係数が低い体制は不健全です。また感度が高い特定のエンジニアが当事者意識を発揮しすぎてあらゆることをすることで、そのメンバーの燃え尽きや他メンバーの（システム運用における）当事者意識を育むチャンスの毀損など、長期的に見て様々なマイナスの影響もあると考えます。
さて、以下に症状検索エンジン「ユビー」を支えるシステムの概略図を示します。（ここでは雰囲気が掴める程度まで簡単にしていますが）この図において FE・BFF・core BE は機能を継ぎ足し開発されていき肥大化してきています。加えてこれらのうち特に FE・BFF は複数のチームが関心を持っており活発に開発されてもいます。その裏側はややマイクロサービスアーキテクチャに倣ったような思想のもとドメインごとに基盤系サービスが分離された状態で配置されています。このアーキテクチャがベストかと言うと全くそうとは考えておらずリアーキテクチャプロジェクトが進行してはいるのですが、システム運用を考えると現状にも十分に目を向けなければなりません。
システム運用体制は基本的な下地は整っているのですが、細部は詰まりきっていない状態でした。例えば、症状検索エンジン「ユビー」を支えるサービス群では Sentry でエラーを捕捉可能にしているのですが、捕捉はされるものの放置されるエラーが多く混沌としているのも問題でした。とりわけ FE はエラー量も多く愚直にトリアージするのは不可能な状態です。またオブザーバビリティが低く、どこで何の問題が起こっているかを迅速に把握するのが困難になっていました。
一歩進んだシステム運用体制へ
プロダクトの成長に合わせて、システム運用も完璧とは言わずとも現状より一歩先に進みたいものです。そのためにまず目指したのが属人性の低減です。
従来、属人的な職人芸で特に支えられてきたのが Sentry で捕捉していたエラーです。しかしカオスな状態でそのまま活用するのは困難です。これに対して以下の軸で整理を行いました
- 特に有効活用できそうな BFF のエラー整理
- 新規エラーに限定した通知
- エラー数の監視
まず BFF のエラー整理について。前述の通り比較的活発に開発が行われているのは FE と BFF です。この中で FE はユーザの利用環境に依存してバリエーションが非常に豊かなエラーが発生する一方、 BFF の方はバリエーションは定まっています。これに着目して、まず BFF のエラーをトリアージして特に立ち向かうべきエラーを明らかにしていきました。この時のトリアージ方法としては以下の記事を参考にしました。
次に新規エラーの通知です。 Sentry のアラート機能では、 Sentry 上で初出と判定されたエラーかどうかを条件にできます。これを用いて「初出のエラーのみ Slack に通知する」ことを実現しました。例えば何らかのリリースを行った直後に Slack に通知が来るようになったのならリリース内容を見直すといった活用が可能になります。
Sentry の初出かどうかの判定はエラーが既存のものと同じグループに属するかの判定で行われ、これが期待に反する場合もあります。そのような場合には Issue Grouping の記述を参考に Fingerprint Rules を追記するなどの対応を行います。
また、 Sentry のアラート機能ではエラー数が閾値を超えた時に通知することができるのでこれも合わせてセットしています。前述の新規エラー通知では把握しきれない、既出のエラーが大量発生しているようなケースもこれで拾えます。 これらにより、 Sentry で捕捉しているエラーがカオスな状態でトリアージがしきれていない状態でも、一定はその中から価値ある洞察を得られています。
また、基礎的なところからですがオブザーバビリティを高める活動にも着手しています。 Ubie のシステムのインフラは GCP に乗っかっていることを加味して、親和性の高い Cloud Trace を活用する、あるいは近しいところで Sentry の Profiling 機能を使い始めています。
アーキテクチャがまだ複雑過ぎると言うほどではないにせよ、人目でぱっと把握できるレベルは通り過ぎはじめています。その中で、どの処理がどこで遅くなっているかなど状況を把握できるデータが増えることの重要性は増してきています。 この基礎的なオブザーバビリティ改善活動によって、例えば N+1 を解決してレイテンシを安定させた事例などもでてきています。
ここまででシステム運用を簡単にする最低限の下地は改善してきているものの、これを一部メンバーで回している限りは属人性課題は改善していきません。これへの対処はまだ草の根的に模索中なのですが、
- アラートが届くチャンネルに関心を持ってくれそうなメンバーを広く巻き込む
- 各メンバーが担当するシステムに当事者意識を持てるようなアーキテクチャ・システム・ガバナンス上の工夫をする
を試しているところです。これも模索中ではありますが、粗々でも今あるツールを有効活用して異常時に多人数でコトに当たりインシデントハンドリングを以前より迅速に行えています。
これから目指したいところ
ということで、プロダクトの成長に寄り添いシステム運用も改善する活動を紹介しました。もちろん現状が理想の形ではなく不足は多々ありますし、プロダクトがさらに成長することで要求も高まります。それにどう組織として立ち向かうかは引き続き考える必要があります。 Ubie のプロダクト開発組織においてはちょうど数ヶ月前に名前を「Ubie Discovery」から「Ubie Product Platform」に変更してより長期に渡るプロダクト価値最大化を目指すようになりました。このような組織レベルでのマインドの変化にも合わせてシステム運用の登り方もアップデートしていきたいものです。
個人的には、さらなるオブザーバビリティや長期的にシステム運用に向きあるガバナンス整理、妥当な SLO の策定と運用、持続可能なトイル対処体制などやれることはまだまだあると感じています。さらに冒頭で触れたアーキテクチャ図は我々の理想にはあまり沿っておらず、特に肥大化している FE 、 BFF 部分に関してはモジュラーモノリスに置き換えていく構想もあります。このようなリアーキテクチャ活動にどうシステム運用を装着していくかも課題の一つになっていきます。
最後に、 Ubie ではシステム運用にも知見が豊富なソフトウェアエンジニアを募集しております！プロダクトの成長に伴いやることは枚挙に暇がありません。ぜひ一緒にやっていきませんか！少しでもご興味があれば、まずはカジュアル面談からでも、何卒！！
