はじめに
株式会社CoeFontで、エンジニアリングマネージャーをしているsugasugaです。
機械学習モデルをサービスで提供していて、誰が責任を持って運用していくべきなのか？といった悩みはありませんか？CoeFontでは、その答えとしてMLOpsチームを設立し、定性的・定量的に良い変化がありました。
本ブログでは、上記の変化を、開発組織に対するデザインパターンであるチームトポロジーの観点から振り返ります。構成は以下の通りです。
- MLOpsチーム設立前の課題
- MLOpsチームの設立後の分析
- 得られた成果の振り返り
機械学習エンジニアリングに関わる方々・エンジニアリング組織の設計に関わる方々に、MLOpsチーム設立の事例を共有できればと考えています。
MLOpsチーム設立前の課題
機械学習システムの認知負荷の高さ
CoeFontは「欲しい声が1秒で手に入る」をコンセプトに最新のAI技術を活用し、「声」を表現豊かな「フォント」として利用できるサービスになります。
好きなAI音声を選んで、エディタで文字を入力することで、AI音声が利用できるようになります。
Productチームは、AI音声を作成・利用できるAI音声プラットフォームの開発を行っています。
使用する技術は、Golang, Next.js, AWS Lambda, DynamoDB・AuroraDBになります。
さらに、Researchチームが研究・開発したTTSモデルが動く機械学習システムを管理する必要がありました。機械学習システムでは、Python、EC2 on ECS等、AI音声プラットフォームの開発とは異なる技術を使用しています。さらに、機械学習モデルの推論・学習の知識、FastAPIなどのWebFramework、GPUの運用知識が必要です。
Productチームは、チームトポロジーの中で問題視されている「チームの扱うドメインが多く認知負荷が高い状態」でした。
認知負荷の高さが引き起こす問題
認知負荷の高さが引き起こす問題は複数あります。
チームトポロジーにおいては、デリバリーの遅延や品質問題につながるとされており、こういった現象が起こりやすい状態だったと判断しています。
また、創業期から所属する特定の個人に機械学習関連タスクが集中していました。そのため、特定の個人への強い依存が発生していました。書籍の中でも、1チームで扱うドメインが多すぎる場合に発生する事象だとされています。
さらに、弊社特有の問題の可能性はありますが、大きな価値を生む中長期プロジェクトに取り組みにくい状態だったと判断しています。
MLOpsチームの設立後の分析
チーム分割のされ方の分析
機械学習サービスを内部APIとして提供・運用することを目的としたMLOpsチームが設立されました。
メンバーは、元々Productチーム・Researchチームに所属していた方々で構成されています。
このチーム分割のされ方は、どういった意味を持っているのでしょうか？
筆者は、CoeFontにおける理想的なソフトウェアアーキテクチャに沿って、チームが分割されたと考えています。
Webサービスと機械学習サービスが完全に分離しているのは、それぞれに適した技術スタックを使用できるため、理想的なアーキテクチャだと考えています。CoeFontは、すでにwebサービスと機械学習サービスが部分的に分離されたアーキテクチャになっており、理想的なアーキテクチャに沿ってチームが設立されました。
チームトポロジーで紹介されている、「逆コンウェイ戦略」をとる形になりました。
MLOpsチーム設立前
MLOpsチーム設立後
チームの立ち位置の分析
MLOpsチームの役割はチームトポロジーにおいてどういった考察ができるでしょうか？
チームトポロジーには、4つのチームタイプを定義しています。
書籍で紹介されているストリームアラインドチームは、他のチームを待たずにユーザーにサービスを提供できるチームになります。AI音声プラットフォームを開発し、デザイナー・フロントエンド・バックエンド・PdMが所属するProductチームが該当します。
ストリームアラインドチームを支える他のチームタイプとして、コンプリケイティドサブシステムチームがあります。このチームは、ストリームアラインドチームが扱えない複雑なサービスを管理します。弊社では、機械学習サービスを内部APIとして提供するMLOpsチームが該当します。
コンプリケイティドサブシステムチームの特徴として、下記があります。
- 初期の探索や開発の段階で、ストリームアラインドチームとと密接にコラボレーションする。サブシステムが安定してきたら、サブシステムのインターフェースに集中する
- サブシステムを利用するストリームアラインドチームのニーズを尊重し、適切に優先順位度をつけて変更をデリバリーする
弊社のMLOpsチームが担当してきたプロジェクトと完全に一致しています。
そして、2024年8月時点で、Coefontには、MLOpsチーム、Productチーム、Researchチームが存在しています。関係性は以下のような図表になっています。
得られた成果の振り返り
定性的な成果
プロダクトチームの認知負荷を削減することができました。
プロダクトチームは、機械学習サービスをブラックボックスとして扱い、AI音声プラットフォームの開発に集中できます。また他にも、定性的に良い変化がありました
個人への依存が解消された
個人ではなくチームが機械学習システムに対してオーナーシップを持つことになりました。
その結果、システムアーキテクチャの整理・開発方法の整備・運用ルールなどがドキュメント化されていきました。また、チームの中で開発の知見を共有することができています。
個人に完全に依存していた部分は、ほぼ解消されました。
中長期プロジェクトが実行しやすくなった
チームとして分担することで、難易度の高い中長期プロジェクトに取り組むことが可能になりました。
バグ修正、アプリケーション監視・外形監視・インフラ監視の整備や改善、静的解析・テスト・CI/CDの改善・整備などの小規模のプロジェクトを遂行しています。その上で、新機能開発・既存のシステムのリプレースなど、中長期のプロジェクトを実行しやすくなりました。
具体的なプロジェクトの一例として下記が挙げられます。
- 学習システムのリプレース
AWS Step Functions/ECS/AWS Batchなどを用いた機械学習ワークフローを作成 - 機械学習モデルのリプレース
プラットフォーム上で作成された既存のモデルを新規のモデルに完全に移行 - Web VCのシステムの作成
録音された音声にボイスチェンジャーを適用する機能を開発 - CL-TTSの機能開発
日本語の収録を行うと英語の収録をせずとも英語TTSも同時に作成される機能を開発
定量的な成果
定量的にも良い変化がありました。
推論システムの改善
推論サーバーのレイテンシが60%削減されました。SLIも大きく改善しています。
学習システムの改善
学習時間が約99.6%まで圧縮されたモデルを導入し、料金を大幅に削減しています。
サービスの成長や音声生成を無料にする意思決定があり、作成されるAIモデルが前年の月と比べて約30倍に増えました。しかし、コストの問題は発生していません。
開発生産性の改善
改善前の数値は正確には取れていません。しかし、Four keys（デプロイの頻度、変更のリードタイム、変更失敗率、障害復旧時間）が大幅に改善しました。
まとめると、定性的・定量的に大きな成果を出すことができました。
単純にチームに人を増やした時よりも、チームとして効率的に大きな成果を上げられたと考えています。
最後に
このブログでは、チームトポロジーの観点からMLOpsチームの設立を振り返りました。
弊社のMLOpsチームは理想のシステムアーキテクチャに沿う形で設立されました。Productチームの認知負荷が大きく減り、定性的・定量的な成果を挙げることができています。
これらは、機械学習システムを運用していく際の参考事例になるのではないでしょうか。また、チームトポロジーの有効性を支持し、組織設計に関わる方々やエンジニアリングマネージャーにとっての参考事例になるとも考えています。
CoeFontは機械学習が重要な役割を果たすサービスです。
そのため、機械学習に関わるエンジニアにとって、幅広い領域を担当でき、プロダクト開発の楽しみを感じることができるサービスだと考えています。
弊社のMLOpsチームは、今後さらに難しく価値のある課題に取り組んでいくため、一緒に働いていただける方を募集しています。興味がある方は、お気軽にご連絡いただけますと幸いです。
- 参考
「チームトポロジー 価値あるソフトウェアを素早く届ける適応型組織設計」
Discussion