GENDA IT戦略部 データサイエンスチームの馬渡です。
GENDAのデータサイエンスチームでは各メンバーが事業貢献のために日々活躍しています。
M&Aを続けるGENDAではデータサイエンティストが本質的な業務に集中しPMI (M&A後の業務プロセス最適化) に貢献していくことが非常に重要です。
本記事では、レコメンドモデル開発環境改善の一環としてAWS ECSからDatabricksへ移行し、データサイエンティストの開発体験を向上させた事例を紹介します。
移行前の環境 [AWS ECS]
はじめに、移行前の環境をご紹介します。
移行前のアーキテクチャ
下図に示すように、「AWSでGPUを利用しつつジョブを安定稼働させる」という観点では特にクセのないアーキテクチャで構成されていました。
しかし、この「AWSに馴染みのあるエンジニアにとって 特にクセのないアーキテクチャ」が、データサイエンティストにとっては負担となっていました。というのも、この状況ではコンテナやCI/CDについて理解しなければコードを実行することもできないためです。
データサイエンティストの開発フローと課題
このアーキテクチャにおける典型的な開発フローは以下の通りです。
- 学習・推論コードを書きGitHubリポジトリにpush
- GitHub ActionsでDockerイメージをビルド・push
- AWSコンソールからECSタスクを手動実行
- CloudWatch Logsでログを確認したり、RDSの推論結果を確認したりする
その際、データサイエンティストとして感じる課題がいくつか存在していました。
インターン生の学習コストが高い
GENDAではデータサイエンティストのインターン生が活躍してくれているのですが、このアーキテクチャでの開発は学習コストが高いものとなっていました。
データサイエンティストの本来の強み、あるいはインターンを通じて成長したい分野は統計モデリングや機械学習アルゴリズムの設計にあるのに対し、この環境では最低限でも下記のAWS特有の知識が必要となってしまいます。
- DockerとECR (GitHub Actionsで自動化しているものの、理解は必要)
- ECSタスクの実行方法
- CloudWatch Logsでのログ追跡
その結果、インターン期間の初期はインフラの学習に時間を多く取られる状態になっていました。
開発サイクルを早められない
このアーキテクチャでは基本的に気軽にコードを実行できず開発サイクルが遅くなってしまいます。
開発フローは先述の通りで、開発の際には具体的には以下のようなサイクルが発生します。
- 何らかの修正
- GitHubリポジトリへpush
- GitHub Actionsでのイメージビルド & ECRへのpush (5分)
- ECSタスク実行 (30分から1時間程度かかる)
- 実行後にCloudWatch Logsでエラー内容確認
構文エラーなどローカル環境であればすぐ気付ける軽微な修正であっても、このアーキテクチャでは最短でも毎回15分程度かかります。
1日に10回試行錯誤すると、それだけで2.5時間が待ち時間として消えることになります。
移行後の環境 [AWS + Databricks]
データエンジニアが主導して導入したDatabricks on AWSを活用し、既存のアーキテクチャを変えすぎない範囲で移行を行いました。
移行後のアーキテクチャ
データサイエンティストの開発フローと改善できた点
このアーキテクチャにより、データサイエンティストの開発フローは以下のように変化しました。
- ノートブックで学習・推論コードを書きつつ実行
- キリの良いタイミングでGitHubリポジトリにpush
- リリース前に統合テストのようにECSタスクを手動実行してRDSへの書き込みを確認
この変化により、以下の点が改善できました。
AWSの学習コストが実質ゼロに
Databricksを活用することでAWSの学習コストが実質ゼロになりました。
なぜならばDatabricksではノートブックベースのUIで対話的に開発が完結し、以下のようなAWS知識が不要になったからです。
- コンテナ：ノートブックに直接コードを書くだけなのでコンテナ関連の知識が不要になった
- ログ確認：ノートブックの実行結果が同じ画面に表示されるのでCloudWatch Logsでの確認が不要になった
- IAMポリシー：Databricks向けに担当者 (私) が設定済みのため、詳細な理解が不要になった
結果として、インターン生のキャッチアップはDatabricksのみで完結し、早期にモデル開発に着手できるようになりました。
開発体験が大幅に向上した
Databricks ノートブック上でコードを書きつつ実行できるため、開発体験が大幅に向上しました。
一般的な話にはなりますが、ノートブックの利点として以下のような点が挙げられます。
- セル単位での実行が可能：コードの一部だけを試すことができ、デバッグが容易
- 変数の状態を保持可能：前のセルで読み込んだデータを再利用しながら分析可能
- 実行結果の可視化が可能：Matplotlibやpandasの出力がそのまま表示され、分析結果が即座に確認可能
開発から本番運用までの流れがスムーズに
Databricksではノートブックの画面から数クリックで簡単にジョブ化できるため、開発環境でひと通りのノートブックの動作確認を終えたら、直ちに本番運用を開始できます。
気軽にジョブ化できることの副産物としてデータサイエンティスト自身がジョブの実行状況を直接確認しやすくなり、運用の透明性が向上しました。
今後の展望
データエンジニアとの連携強化
Databricks上に機械学習向けの特徴量データマートを構築することでデータサイエンティストの扱うコード量を削減したり、クエリの最適化を図ることで開発体験の更なる向上が見込めます。
具体的には以下のような改善が見込めます。
- 複数テーブルの結合処理の簡易化：JOIN処理を意識せずに特徴量を取得できる
- 各テーブルに関する情報の提供：Databricksのメタデータやdbtプロジェクトから得られる情報によりデータ探索時間を削減できる
- 特徴量データマートのデータ品質監視：データエンジニア側で構築したデータ品質監視の仕組みに相乗りすることで、モデルの精度劣化の予兆を検知できる
プロダクトエンジニア並みの生成AI利用体験の提供
GENDAでは開発における生成AI活用に取り組んでいます。
とはいえ、データサイエンティストの開発体験はプロダクト開発を担うエンジニアに比べるとまだまだ良いとは言えません。
というのも、クラウド上のノートブック中心の開発環境ではローカル環境で動かすAIエージェントが直接コードの読み書きを行うことが難しいためです。
その対策として、ローカルからDatabricksの計算リソースを部分的に利用できてClaude Codeと併用できるような開発環境を試験的にデータサイエンティストに提供しています。
現在はローカルで開発を完結させるべく再調整を進めており、今後はデータサイエンティスト全員が実際に使いこなしていけるようなノウハウ共有もしていければと考えています。
その後の展望としては、例えばノートブックを中心とした開発において、ソフトウェア開発文脈的なテスト結果やモデル評価指標などをAIエージェントが参照して更に自律的にコードを改善させることを目指しています。
これが実現すると、例えばモデルの精度が悪化した際にAIエージェントが自律的に原因を分析し、コード改善まで実施させることも可能になります。これによりデータサイエンティストはより高度な問題解決や新しいタスクに取り組みやすくなります。
おわりに
本記事では、アーキテクチャ移行による改善点や今後の展望を紹介しました。
まだまだ少数精鋭のデータサイエンスチームですが、埋もれがちな困りごとを拾い上げ、データサイエンティストが本質的な業務に集中するための環境整備を続けていきます！
Discussion