11
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

カオスなML基盤を統一して運用負荷を激減させた話

11
Last updated at Posted at 2025-12-04

はじめに

こんにちは。
アイスタイルに入社して早2年9ヶ月、データ分析システム部の永冨です。

MLチームのリーダーとしてJoinさせていただき、当時は長くチームを見てくれていた方との入れ違いだったこともあり【チームと運用体制の立て直し、新規プロジェクトへの対応】というミッションのもと、ML/AIのPoC標準化やMLOps成熟度の引き上げを目標としていました。

今年に入って育休をいただき復職したばかりなので、休職前に取り組んだ「ML基盤統一プロジェクト」の話をしたいと思います。
※2024/3~11頃の取り組みになります。

当時のMLチームの状況・課題感

今振り返ってみても当時はカオスな状況だったと思います。笑
(その分やり甲斐もありましたし成長を感じられた期間でした🫶)

チームの規模感は入社時点で3人、その後も2~4人体制で、PoC案件から本番開発、運用までML系のものは基本うちで開発・運用していました。
とにかくいろんな課題はあったんですが、記憶している主な課題は↓

  1. 属人的な運用体制が続いており、システム内部を詳しく知る人もほぼ不在で、システムが動く/動かないの運用しかできなかった(モデルの改善なども当然できない)
  2. PoCとMLOpsの違いやそれぞれの標準的な定義がチーム内で共通認識化できておらず、PoCプロジェクト〜本番導入開発〜運用のベストプラクティスが無かった(考えることも出来なかった)
    • 私自身も当時はMLOpsの解像度はとても低かったです
  3. 新規PoCプロジェクトの依頼が事業サイドから来るも当然、超超手探りで1プロジェクトに時間がかかりすぎていた(ML系機能やりたい!って事業ニーズにスムーズにスピーディに対応できない)
  4. ML特有の「精度検証」ニーズから、どの環境からも本番のデータ基盤を参照する必要があり、セキュリティ的な懸念があった
  5. 本番稼働しているMLシステムの基盤がバラバラ・開発ルールもバラバラで運用負荷が高かった
    • Cloud Composer、VertexAI、スケジュールクエリ+Cloud Functionなど、システムによって基盤が違った
    • 当然開発方法やルールも異なってくるし、コードの二重管理をしているシステムもあた・・omg
  6. 開発/テスト環境がなく、本番環境しかないMLシステムがほとんどだった
    • DevOpsに携わる方ならびっくりすると思いますが、当時のMLシステム状況は
      「一度開発して本番稼働後は放置だったので基本追加開発がない(MLOpsのCT概念がなかった)」
      「データ提供のみのバッチ稼働だったので、障害対応時は本番影響がない時間帯に本番環境で開発/テストができた」
      ので本番環境のみでも回っちゃってたんです

今日は特に下2つの、

  • 5. ML基盤バラバラ
  • 6. 開発/テスト環境がない

な課題とそれについて取り組んだことを話していこうと思います

一番の課題だったML基盤バラバラ

ML基盤が標準的に整備できておらずバラバラだったことで何が辛かったかというと、

  • PoCがうまくいき本番導入できるとなっても、MLパイプラインの新規設計における判断基準が持てない
  • 障害発生時に「このシステムはどの基盤だっけ?どう動かすっけ?」から毎回スタートし対応コストも心理的負荷も高かった
  • これからもっとML活用を推進できるようにするためにも、MLOps成熟度あげたいとか、運用体制見直したいとかあったけど、手元が整っていないので進めようにも進められない

などなどです

そもそも何で基盤がこんなにバラバラだったか

入社時点で既にそうだったので私の想像(完全主観)でしかないのですが、以下のような背景があったと推測しています。

  • 数年前のML開発といえば、業界全体でもPoC的な取り組みが多かったと思います。特にML領域が成熟しきれてない企業は、PoCが成功したら急いで本番化することが優先されがちで、MLOpsの概念/定義や重要性があまり浸透していなかったと思います。おそらくうちも例外ではなく、PoC的に試したものがそのまま本番環境になっちゃったのかなと思っています。
  • あとは、MLの案件体制やチーム編成するとなると、MLエンジニアは必須ですがその多くは「Notebookをメインに使ってモデルを検証的に開発する」だったと思います(自分もそうでした)。なのでソフトウェアエンジニアリング(DevOps)の経験とMLの専門知識を併せ持つ「MLOpsエンジニア」という職種や概念は、当時はまだ一般的ではなく貴重人材でしたし、うちもそうだったんだと思います。

でもこういった状況は決して珍しいことだとは思っておらず、むしろML領域を成熟させていく過渡期にあるあるな話なのかなあーなんて思っていたりします。

ML基盤を統一しよう!となった

というわけで、まずは早急に現状を打破するべく、運用コストの削減と長期的な基盤改善の道筋をつけるため、統一されたML基盤化を目指すフェーズ1がスタートしました!

スクリーンショット 2025-12-03 12.01.49.png

※フェーズ2以降は統合基盤の計画が変更されたため今回は触れません
現在のデータ基盤への取り組みは同士が執筆してくれているのでリンクしておきます!

実際の取り組み

直近で開発されていた【VertexAI workbench+Poetry】構成のシステムが、既存の中で一番洗練されていた&長期的な改善を見据えられると判断しました。
そこで、非破壊的変更を前提に、他のバラバラなシステムをこの基盤に統一(寄せる)する方針を採りました。

スクリーンショット 2025-12-03 12.34.16.png

スクリーンショット 2025-12-03 12.34.31.png

※将来的なTOBEも考えていましたが、そこまでは休職前にはやりきれませんでした..
スクリーンショット 2025-12-03 12.36.42.png
スクリーンショット 2025-12-03 12.36.52.png

基盤統一を取り組んだ結果

結果、とても良かったです!🎉🎉🎉

  • 運用コストが減った(数人体制で回していたのが、1人でも見れるようになった)
  • 心理的負荷もさがった!
  • 開発環境ができたので改修がしやすくなった!
  • 基盤のシンプル化(およびドキュメント整備)により、ML専門外の他チームの方でも、障害発生時の原因調査ができるように!

これからどうしていくか

リソース的な問題もあり、実はMLチームは現在一時的に消滅しています
元々私の上司だった方にシステムを引き継いで、現在はその方がメイン担当となり、他チームの方々の協力も得ながら運用を継続していただいています
最近ではまたML系の新規プロジェクトも引き受けるようになってきており、私もアドバイザーとして参画しています

生成AIなどAI技術が進化する「AI時代」の到来を受け、部としてはML/AI領域を盛り上げていきたい気持ちは超あるので、これからまた体制含めて再構築を検討していきます!

さいごに

この記事を読んで、少しでも何か得られるものがありましたら嬉しい限りです。

文中に触れたデータ基盤に関して、絶賛データエンジニア募集中です。
少しでもご興味持っていただけた方はぜひお繋ぎしますのでお気軽にお声がけください🌻
【istyle】プロジェクトマネージャー/大規模データ分析基盤領域
【istyle】テクニカルリーダー候補/データ基盤インフラ領域
【istyle】データモデリングリード候補/データ基盤モデリング領域

最後までお読みいただき、ありがとうございました!🌻

11
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
11
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?