この記事は Ubie Engineers & Designers Advent Calendar 24 日目の記事です。
TL;DR;
- 2つのプロダクトで共通で使っていたシステムを分離した
- 結果デリバリパフォーマンスが向上した
なぜデリバリパフォーマンスをあげるのか
まず、前提としてなぜデリバリパフォーマンスをあげる必要性について説明しておきます。ここでいうデリバリパフォーマンスとは Four Keys のことを指しています。
Four Keys は Lean と DevOps の科学で語られているように、事業パフォーマンスと強い相関関係にあり、Four Keys を改善することが事業の成長につながることを研究の結果として示しています。
ユビーでも Four Keys を計測しており、この指標を改善することを目指して開発基盤を整備しているところです。本エントリではアーキテクチャ改善によって Four Keys の指標を改善した事例を紹介します。
ユビーのプロダクト
ユビーのプロダクトは toB（医療機関様）向けの「ユビーAI問診」と toC 向けの「症状検索エンジン ユビー」があります。
どちらのプロダクトにも、症状を入力として疾患を予測するというコア機能があります。このコア機能を提供するサービスは社内では diagnosis と呼ばれており、toB/toC の共通コンポーネントとして利用されていました。
（図は簡略化のため色々と省略しています）
サービス分離
このアーキテクチャがデリバリパフォーマンスを阻害する要因として、toB と toC のサービスレベルの違いがあります。toB のサービスは toC のサービスと比べて期待されるサービスレベルが高いため、リリースの日程が予め決まっていたり、QA のプロセスも toC より時間をかけて行います。
一方 toC は toB ほど求められるサービスレベルは高くなく、diagnosis 以外のサービスはカジュアルにデプロイ可能でしたが、diagnosis だけは toB のリリースサイクルに合わせてリリースする必要があるという状態で、デプロイ頻度に影響が出ていました。また、機能的にも toB だけで使うもの、toC だけで使うもの、両方で使うものが複雑に絡み合っているので、コード変更による影響範囲の検証やレビューも難しくなり、変更のリードタイムにも悪影響を与えていました。
この課題を解決するために[1]、toB/toC で diagnosis を分離するプロジェクトを立ち上げました。分離にあたっては、いくつかのステップに分割できます。
- アプリケーションの実行環境（k8sのserviceなど）を分離する
- 永続化不要なストレージ（redisなどのcacheレイヤー）を分離する
- 永続化が必要なストレージ（RDB）を分離する
- アプリケーションのコードベースを分離する
1と2については比較的分離が簡単なのでこれまでもシステムの安定性の観点で分離をおこなっており、難しいのは3のDBの分離でした[2]。diagnosis が toB, toC の共通項のみで DB を使っていれば難しくないのですが、当然リアルワールドではそんなにうまい話はなく、toB だけの機能、toC だけの機能がアプリケーションレイヤー、DBレイヤーに食い込んで複雑に絡み合っていました。
これを解決するために、データが toB/toC で干渉しないように機能を整理するところから始めました。これはひたすら地道な作業です。ひとつひとつの機能を見てコードを読んで必要に応じてアプリケーションのコードを書きかえ、DB のスキーマを分けていきます。
この作業に大半の時間をさきましたが、この改善でtoBとtoCでデータの干渉がなくなり、DB を分離することができるようになりました。ここまでくれば後は簡単で、アプリケーションコードを fork して toB/toC それぞれの道の歩みを始めるだけです。
結果として、DBとアプリケーションのコードベースと分離できたことで、改善対象だったデプロイ頻度や変更のリードタイム[3]についてはわかりやすく改善が見られています。
まとめ
toB と toC で共通で使われていたシステムを分離することでデリバリパフォーマンスをあげた事例を紹介しました。他にもアーキテクチャの改善でデリバリパフォーマンスを改善できそうなところはたくさんありますし、Four Keys の有効な使い方についてもまだまだ模索中といったところです。
ユビーではそんなデリバリパフォーマンスの向上に興味のあるエンジニアの方を積極募集中ですので、興味がある方はぜひ一度カジュアルにお話しましょう。お気軽に DM ください。
Discussion