1. はじめに：本記事について
私の所属する部署では自動車にかかわる様々な開発をしています。その中でも私のチームでは、特に コネクテッドカー（Connected Car） にかかわるバックエンド開発を担当しています。 コネクテッドカー とは、インターネットやクラウドサービスと常時接続された自動車のことです。車両が車両外のデータセンタ/クラウド基盤とデータを送受信することで、ドライバー・運行管理者・メーカー・第三者のサービスと連携して多様な機能やサービスを提供します。具体的にはプローブデータ(CAN)やドライブレコーダーの映像データなどが収集されています。
当部では上記基盤開発を長きにわたり取り組んでおり、その中でも本日は 映像データ×MLパイプライン を紹介します。
参考：第一回では動画像処理の方式設計を紹介しています
ちなみに：クラウドサービスはAmazon Web Services (AWS)を前提としています。
なぜ"映像データ×MLパイプライン"に注目したのか
MLOpsが定着しつつある中で、MLワークフローを自動化・管理するための「パイプライン設計」は避けて通れません。MLOpsというとMLモデルを取り巻くすべてを指しますが、本記事ではそのパイプライン部分、つまり複数の機能を連動させて動作させ、MLモデル開発にとって重要な情報を管理できることにフォーカスを当てています。
ただし、世の中には Airflow や Step Functions、SageMaker Pipelines といった選択肢は多くありますが、機械学習に特化したクラウドサービスやインフラレイヤも含めた観点で比較された文献が非常に少ないのが実情です。もっと言うと"映像系"のMLについては未成熟で、サービスの手厚さは構造化データを使った教師あり学習／教師なし学習のものが多い印象を持っています。映像系のモデル学習において、もう少し具体的に補足すると、画像データに対してラベル付けをする必要があります。そのラベル付けのツールやラベルをつけるべきかの推論処理が必要となります。
本記事では、パイプライン方式をインフラエンジニアの視点から比較しつつ、その中でも一番事例が少ない SageMaker Pipelines についてDeepDiveします
2. MLOpsにおける主要パイプライン方式の比較
これは私の主観も入っていますが、以下のような捉え方をしています。実際にはさらに横軸が増えますが、今回はSageMaker Pipelinesにフォーカスを当てたいこともあり、本記事の主目的に合わせた観点に絞って記載しています。
| 観点 | MWAA (Airflow) | Step Functions | Kubeflow Pipelines | SageMaker Pipelines | Flyte | W&B Pipelines |
|---|---|---|---|---|---|---|
| AWSマネージドサービス対応 | 〇 | 〇 | ×（EKS構築要） | 〇 | ×（Kubernetes構築要） | ×（SaaS・AWS非公式） |
| 機械学習に特化 | △ | △ | 〇 | 〇 | 〇 | 〇 |
| 視覚的管理 | 〇(ワークフローのみ) | 〇(ワークフローのみ) | ◎（ワークフロー＋学習管理） | ◎（ワークフロー＋学習管理） | ◎（ワークフロー＋学習管理） | ◯(学習管理のみ) |
| パイプラインの書き方 | Python DAG | JSON/YAML or SDK | Python | Python | Python | Python |
解説
本解説はあくまで私個人の主観であり、正確な比較はユースケース次第で変わるものになります。
汎用的なワークフローを考えるうえで、AWS的に強いのはStep Functionsの印象を持っています。
理由は、マネージドで使いやすく、MLに限らず触ったことが多いこと。また、インフラ設計とアプリ設計の責任分界点もわかりやすいためです。次点でMWAAも入ってきますが、以下の癖がある印象です。
MWAAの良い点：
・Airflowベースなので、PythonのDAGでワークフローが管理されている＝他クラウドやオンプレに持って行っても微修正で使える
・インフラ構築自体は楽、マネージド化されているのでボタンをポチポチすれば基盤ができる
どちらともいえない点：
・ワークフローがPythonで書けるので、インフラエンジニアがチームにいない場合でも一定の可用性が担保された基盤が出来上がる。アプリメンバが強い体制にしたい際にフル投入できる。
ただし、逆に言うとインフラエンジニアが得意なyamlが封じられ、IaC感がない(コードで基盤ができるという意味ではIaCではある)
悪い点：
・マネージドサービスで、サーバに対して定常的にコストがかかるので、使用頻度が低い場合は割高。ただし最近はマイクロサイズもリリースされており、お安くはなっている。
ここまでは汎用的なワークフローの比較をしました。残りの右4つはML用のワークフローになります。アプリやコンテナなどでラップされた実行単位のワークフローに加え、モデル学習で必要な学習管理機能等を具備された点が特徴です。この中でマネージドサービスとなるとSageMaker Pipelinesが候補として挙がってきます。
他にもKubeflowといったKubernetes（k8s）由来のものも候補として挙がってきます。k8s有識者を抱えることでML領域でも使いやすくなるものの、有識者を集めることができるかどうかがカギとなります。他はデータサイエンス系で使われることが多く、インフラさえうまく整えば使い勝手はよくなるといった特徴があります。
3. SageMaker Pipelinesの構成とメリデメ
3.1 パイプラインの構成イメージ
以下のようなGUIが組めます。データの前処理やモデル学習、評価、デプロイなどを仕込むことが可能です。
-
どこにできるのか
SageMaker Studio内
-
どうやってこのパイプラインを作るか
以下に示すようなPythonでの記述でワークフローが用意可能。MWAAに近い。
定義したパイプラインは、SageMaker StudioのJupyterサーバー上で実行することで、Studio UIやAWS SDK経由でデプロイ・実行可能。StudioではGUI操作による実行やDAGの確認、ノード単位の再実行もできる。
- 付帯する機能
モデル学習をフローに含めた際に、MLflow連携した実験管理が可能(旧：SageMaker Experiments)
モデル管理はレジストリで管理できる(モデル情報以外にも学習データのパスなど様々な情報を管理可能であり、再現性が担保される)
他にもClarifyや前処理用のData Wranglerなどと連携でき、一元的な管理ができるので、ワークフローを作りつつ、いろいろMLモデルを作るうえでの便利機能が使いやすい(SDK連携しやすい)特徴があります。
3.2 ちょっと脱線：映像処理×MLパイプラインの観点
はじめにでも述べましたが、上記について補足します。パイプラインを用意すること自体は構造化/非構造化データの差は感じなかったですが、以下が主な留意点になります。理解して用いることでプラットフォームを最適化できます。
・非構造化データはまだ発展途上の場合がある
例えば、Data Wranglerについて、基本的な変換(リサイズ、グレースケール化、画像フォーマットの変換）はできるものの、オーグメンテーションやアノテーションデータの取り込みや再加工、加工したデータの統計分析結果の出力など、MLモデル開発において追加で欲しい機能は不足しているものもある。
参考：構造化データについての機能紹介
・データを大量にReadするにはテコ入れが必要
これはSageMaker以外でも起こりうることですが、データの前処理やReadなどをパイプライン記述、SageMaker Processing記述すれば実現できる一方で、画像データを大量にReadしたい場合＝容量の大きい非構造化データをローカルに置きたい場合は時間が多くかかるため、キャッシュする、高速化のための並列処理を入れる等の対策が必要になります。
こちらは設計ノウハウになるので具体手法は記載しませんが、構造化データに比べて顕著に差が出るところですので、アーキテクト、並びにアプリ開発の腕の見せ所となります。
・容量の大きいGPUサーバを確保できないケースの打ち手が難しい
これはMLモデルや要件に依りますが、画像を使ったモデル学習では大型のGPUサーバを使ったモデル学習が必要なケースが多いです。AWSに限らずGPUサーバは枯渇気味ですので、マルチクラウド(クラウド-オンプレ)化する等の打ち手が必要となりますが、SageMakerは用いるサーバをマネージド化しているため、ロックインされてしまう＝上記打ち手が難しい課題があります。例えば、AWSでいうとECS/EKS Anywhereなどにする手があります。
3.3 メリット（構成・運用面）
- Studio UIでの視覚的なフロー管理と再実行ができる
- Experiment管理、Model Registryとの統合が容易（Python SDK記述）
- マネージドサービスベースなので、サーバの管理の手間がなく、可用性を担保したうえでモデル開発者が自走しやすい
- MLモデルの管理機能が充実(レジストリ)
- CDKなどでIaC化可能 → インフラエンジニアと連携しやすい(ただし限定的)
- サービング機能もあり、インフラ観点での性能UP/コスパUPの構成が知見が少なくても取りやすい
メリットについては、ほぼほぼ上記で述べた事項が該当します。端的に言うと SageMakerを用意すれば手軽にだいたいのことができる という点になります。こちらはおおむねSageMakerの一般的なイメージ通りなんじゃないかなと思います。
3.4 デメリット（実装・運用面）
ここまでをまとめると、SageMaker Pipelinesは、前処理から学習・評価・モデル登録・デプロイまでをAWS上で完結できる、魅力的なMLパイプラインサービスに見えますが、以下の注意点があります。
- 条件分岐が柔軟ではない（条件式の制限／ループ不可など）
- 一部のみ再実行したい時のワークフロー操作がやや不便(Airflow比)
- 上記でも述べましたが、ツールが微妙に惜しいところがある
- 実践事例が少なく、参考記事が少ない
- せっかくなら開発環境と本番環境を包含したマネージドサービスを提供してほしい
補足：開発環境と本番環境を包含したマネージドサービス とは？
一般的な商用システムでは、dev（開発）/ stg（検証）/ prod（本番）といった環境分離が定石です。これは、開発中の変更や障害の影響を本番から隔離するための基本設計です。
一方で画像系などの大規模学習では、A100 のような高価な GPU を長時間・大量に占有します。もし dev と stg / prod で同一の学習を再実行すると、時間とコストが二重に発生します。したがって、学習は1つの環境（もしくは1つのアカウント／面）に集約し、出来上がったモデルという成果物を配布・昇格させる設計が、ML 特有のコスト構造にフィットします。
SageMaker には推論を担う Endpoint をはじめ、Model Registry や CodePipeline との連携があり、「学習→モデル登録→承認→stg/prodへ段階デプロイ」というフローはマネージドサービスの組み合わせで実現できます。
今後は、環境分離の原則を守りつつ“学習の一元化＋モデル配布”を前提にしたベストプラクティスの体系化が重要と考えており、いっそこれがマネージドサービスであまり何も考えなくてもテンプレート提供されるとよいなと思って説明しました。まだ触れていないですが、SageMaker JumpStart を用いれば簡単に実現できるかもしれません。
ここまで説明したことをアーキテクト図で示すと以下のようになります。
(注意)SageMaker Model Registryについて、あくまで格納先情報やモデル学習の条件がわかるものであり、要件や作り方次第ですが、別途モデルの実態を格納するストレージやレジストリを用意するケースもあります。以下に示す通り、共通のGUIから利用でき、管理がしやすい作りになっているので、実運用をしていく際には使いやすい印象を持っており、随時機能アップデートもされているため、さらなる進化も期待できます。
話は戻りますが、上記デメリットの中で、特に重要なのはマネージドサービスが要件に合致する機能を提供するかの目利きになります。凝ったことをしようとすると機能が足りなくなる点に注意なためです。
例えば、繰り返しになりますが、Data Wranglerについて、もう少し画像加工のバリエーションを足したい！となったときに、一から作ったほうが早いのかもしれないと開発フェーズの終盤で気が付いたとします。
もちろん、足りないときにそれら機能を自作して解決もできますが、SageMakerの一番の利点である各サービスの連携の手軽さを失うので、なんでSageMaker Pipelines使っているんだっけ？という事態を引き起こす可能性が起こり得ます。
おススメは自分で一度触ってみたうえで、担ぐ判断をすることです。
昨今は生成AI(OpenAI/Gemini など)に聞けば大体のことが帰ってくる時代ですが、この領域はまだニッチな領域ですので、有効な回答が少ない印象です。2024年の夏にExperimentsがMLflowに置き換わったこともあり、仕方ないことですが、ハルシネーションもまあまあ起こします。(今後は解決するかもしれません)
実際にこのプロダクトを使っている昨今でも生成AIツールを試しましたが、こちらが聞きたい細かなことまでは解が出ず、機能実装やデバッグに苦戦するシーンも多々ありました。ですので、実現したい機能が要件を満たすかどうかをPoC等で試すことが重要と考えます。
4. まとめ
MLOpsパイプラインを選定する際は、目的（汎用かML特化か）、管理のしやすさ、IaC対応、運用チームのスキルセットなど、多角的な観点で評価する必要があります。
SageMaker Pipelinesは、特に以下のような状況に適しています：
- MLエンジニア主導で進めるプロジェクトの場合
- ML開発における前処理や管理を手軽にしたい場合
- AWS環境で学習・推論・デプロイを一貫して設計したい場合
- Studioベースでのチーム共有・レビューが求められる場合
5. おわりに
我々のチームでは自動車を軸に、R&Dから商用開発まで幅広に開発をしています。
** 興味がある方は **
** 自チームの取り組み紹介 **
** 本件に関するお問い合わせ先 **
株式会社NTTデータ
システムインテグレーション事業本部
ビジネスエンジニアリングサービス事業部
自動車開発統括部
E-mail：connected-car-cloud@hml.nttdata.co.jp
🔖 参考文献
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。