MLOps導入のための組織作りの第一歩

新しくMLOpsに着手しようと思っても、どのような技術スタックが必要なのか、MLの経験がなくても参画できるのか、など簡単にチームづくりすることが難しいと思います。今回は、MLOpsを実行するための組織を作るための最初の一歩をどのように進めればいいかをお伝えします

Transcript

1. MLOps導入のための組織作りの第一歩 株式会社スリーシェイク Sreake事業部 赤川 大空 Copyright © 3-shake, Inc. All Rights Reserved.
2. 自己紹介 2 - 赤川大空（Akasan） - 株式会社スリーシェイク Sreake事業部 アプリチームの中で、特にML領域を担当 - MLOpsの構築支援や生成AIアプリケーションの実装 - NVIDIA Inceptionパートナーとしての活動のリード - 最近の興味 - MLOps - ML/AI - クラウド（Google Cloudを中心）
3. 会社紹介 3 会社名 株式会社スリーシェイク 設立日 2015/1/15 Mission: インフラをシンプルにして イノベーションが起こりやすい世界を作る Vision: 労苦〈Toil〉を無くすサービスを適正な価格で提供し続ける 2015 2016 2017 2018 2019 2020 2021 2022 0 50 10 0 従業員: 200名over Engineer 60% 所在地 東京都中央区銀座8丁目21番1号 住友不動産汐留浜離宮ビル7F 代表者 代表取締役社長 吉田 拓真 Google Cloud×SRE / GenAIにおいて、スリーシェイクは国内トップパートナー Googleクラウド・AWSの両方のエンジニアリングに強みを持つ （2024年8月に国内2例目の、GoogleCloudのDevOpsスペシャライゼーションを取得） 日本のSREをリードする インフラ・アプリ・データ・セキュリティ・AI 全方位で顧客の内製化を推進する伴走支援 あらゆるサービスを 連携するハブになる 「いいエンジニア」を あなたのチームに 事業者が抱える セキュリティリスクをゼロに あらゆるSaaSをノーコードで連携する クラウド型ETL/データパイプラインSaaS セキュリティ対策をワンストップで 実現する脆弱性診断SaaS ハイスキル人材の紹介とHR戦略支援の両輪で エンジニア組織の課題に併走 会社・事業部説明資料（SpeakerDeck）
4. SREを主軸にクラウドネイティブ化/エンジニアリング内製化を支援 4 SRE/DevOp s SecOps BizOps HR ・SRE総合支援からセキュリティ対 策を全方位支援 ・Geminiを用いた生成AIの活用支援 ・ワンストップで脆弱性診断を行う セキュリティ対策SaaS ・クラウド型ETL/データパイプ ラインSaaSの決定版 ・あらゆるSaaSをノーコードで連携 ・ハイスキルフリーランスエンジニ ア紹介エージェント IT内製化 / 高度化 クラウドネイティブ化 モダナイゼーション ITアジリティ向上
5. 目次 5 01 MLOpsとは？ MLOpsの基本要素 02 基本的なケイパビリティ どのような能力が必要？ 03 MLの知識は必要？ MLOpsチームのメンバーになる ことをためらわない！ 04 初期チームの構築 スモールスタートしよう 05 組織を育てよう 実践を通して強化しよう
6. 取り扱う内容 6 学べること • MLOpsチーム構築について 議論するための共通言語 • 現在の状況に合った「最初のステ ップ」を決定するための基準 • 明日から始められる具体的な行動 本発表でカバーしないこと • ケイパビリティに関する 具体的な説明 • 個別のツールに関する具体的な説明 • アーキテクチャのデザインパターン など
7. MLOpsとは？ Copyright © 3-shake, Inc. All Rights Reserved. 7
8. MLOps is not a collection of tools, MLOps is organization / mechanism. 8
9. MLOpsとは？ 9 https://blogs.nvidia.com/blog/what-is-mlops/ MLOps = Machine Learning + Operations
10. 近年とても注目されている 10 https://www.oreilly.com/library/view/imple menting-mlops-in/9781098136574/ https://www.oreilly.com/library/view/introd ucing-mlops/9781492083283/ https://www.manning.com/books/mlops- engineering-at-scale
11. MLOpsを構成する技術要素 11 MLOps データの取得から 特徴量エンジニアリングまで データの取り扱い モデルの提供と性能劣化検知 デプロイとモニタリング モデルの学習と パフォーマンスチェック モデルの学習 モデル・インフラを 常に最新に CI / CD / CT
12. データの取り扱い 12 データ取得 データを取得・格納 データバリデーション 欠損値やイレギュラー値への対応 特徴量エンジニアリング Raw dataから有用なデータへ バージョニング 再現性確保に向けた管理 ラベリング Ground truthの付与 プライバシーとセキュリティ コンプライアンスに準拠した対応
13. モデルの学習と評価 13 データ分割 学習・検証・テスト用のデ ータ作成 モデルの評価 想定した性能に達しているかなど チェックを実施 モデルアーキテクチャ検討 様々なモデルアーキテクチャの検 討 モデル学習 学習データを用いた モデルの訓練 ビジネスKPIチェック 受け入れ可否を実施
14. デプロイとモニタリング 14 インフラ管理 モデル実行基盤の維持 モデルのサービング ユーザが利用可能な状態にする オブザーバビリティ インフラだけでなく モデル・データもチェック
15. CI/CD/CTによるサービスの自動運用 15 CD コード品質チェック 本番環境デプロイに向け たコード整備 パッケージ化 モデルや推論エンジンの パッケージ化 モデルの更新 データドリフトなどを 検知してモデルを自動更新 パイプラインの検証 パイプラインが適切に 動くことを常に検証 デプロイ ユーザが利用できる形で モデルを提供 メタデータ管理 学習履歴を全て レコードとして保存 CI CT
16. 必要なケイパビリティ Copyright © 3-shake, Inc. All Rights Reserved. 16
17. Capabilities encompass not only technical skills but also operational processes and organizational structure. 17
18. MLOpsの三本柱 18 組織 • 機械学習エンジニアと他のエンジニア間の コラボレーションプロトコル • ビジネスサイドとの期待値の調整 • ガバナンスとコンプライアンス 心理的安全性 プロセス・運用 • リリース基準 • インシデント対応とロールバック • ドキュメント • データ／機能／モデルのレビュー 基盤技術 • バージョン管理 • 再現可能なパイプライン • 実験追跡 • モニタリングとアラート • インフラストラクチャ
19. 不足しているケイパビリティの見つけ方 19 事故や挫折はどこで発生したのか？ モデル開発を複雑にする要因は何か？ インシデント／リリース失敗／再学習できなかったため、処理を中止 再現性の欠如／本番ログの確認ができない メンバー間のボトルネックはある？ テクノロジーでは解決できない問題を、構造によって解決する 02 03 01 属人化しているところはあるか？ ナレッジ化もされておらず「その人しかできない」状況を回避 04
20. MLの知識はMLエンジニア 以外に必要？ Copyright © 3-shake, Inc. All Rights Reserved. 20
21. Rather than the depth of ML knowledge, what's important is the breadth of being able to "talk about your company's model as if it were your own." 21
22. MLOpsチームメンバーに求められる能力 22 ML Engineer Must know • 機械学習に関する深い理解、モデルの 作成、モデルの評価など • 実験結果の管理 • ノートブックではなく、サービス提供 のためのコードを記述する Nice-to-have • インフラストラクチャに関する経験 • 分散コンピューティング技術 Non-ML Engineer Must know • コンテナ技術（Docker、Kubernetes） • CI/CDパイプラインの構築方法 • IaCを用いたインフラストラクチャ構築 の経験 • GPUサーバの運用経験 Nice-to-have • 機械学習に関する知識 • 機械学習特有のセキュリティと コンプライアンス
23. MLの知識が求められるシチュエーション 23 ML 特有 • モデル性能の低下 • 機械学習固有の指標をレビューする • データサイエンスからの要件を 「基盤設計」に落とし込む • データ／概念のずれ 一般的なシチュエーション • インフラストラクチャの構築 • IaC（Infrastructure as Code） • セキュリティ • パイプラインの保守 • SREに基づいた運用設計
24. よくある誤解 24 機械学習エンジニアだけがMLOpsを構築する場合、運用 設計が脆弱になり、本番環境で不具合が発生しやすい MLOpsチーム = MLエンジニアチームである 01 ドリフトなどML特有の課題に対応できる基盤を 構築できない可能性が高い SRE / SWEだけで構築できる 02 座学ではなく、実践を通して学ぶことが 最も現実的な解決策 全員が機械学習のトレーニングを受ける 03
25. Problem 応答が停止したため、ログとメトリ クスを確認したところ、過剰なアク セスによりGPUメモリが不足してい たことが判明した Solution モデルのメモリ使用方法に問題がある 可能性はあるものの、GPUのスケール アウトとスケールアップによって解決 できる可能性がある 25 サンプルシチュエーション①
26. Problem 推薦モデルのクリック率（CTR）は、 前週と比較して20%減少した。 Solution ? 機械学習エンジニアがいなければ、唯 一の結論は「推論APIのレイテンシは 正常であり、インフラストラクチャの 問題ではない」となるかもしれない 26 サンプルシチュエーション② MLエンジニアがいない場合
27. Problem 推薦モデルのクリック率（CTR）は、 前週と比較して20%減少した。 Solution 1. ドリフトが発生している 2. トレーニングデータセットにデータが 存在しない 3. ラベル収集パイプラインに不具合がある 4. データ前処理に問題がある 27 サンプルシチュエーション② MLエンジニアがいる場合
28. 組織づくりで意識すること Copyright © 3-shake, Inc. All Rights Reserved. 28
29. The first step isn't recruitment or infrastructure development, but rather focusing on stakeholder mapping, initial members, and decision-making criteria. 29
30. ステークホルダーの整理 30 経営層・マネージャー 事業部 Why ML Engineer Data Scientist Data Engineer What SRE Platform Engineer How 法務 コンプライアンス 情シス セキュリティ Risk このプロセスでは、「なぜ」→「何を」→「どのように」→「リスク」という順序で検討
31. MLOpsチームメンバーのロール 31 Ops Engineer Data Engineer Infra Engineer ML Engineer データ取り込み、前処理、 データ保存などのデータ 処理を担当 データ処理、モデル開発、 モデル提供のためのイン フラストラクチャを構築 データに基づいて実行可 能なモデルを開発 生産状況の監視、アラート （ドリフト／遅延）、およ びオンコール／インシデン ト対応 ◎ 企業文化構築、ビジネス知識、低コスト △ 機械学習経験が限られている可能性あり 内部メンバー 外部採用がメイン ◎ 専門知識とベストプラクティス △ 時間、コスト、導入リスク
32. 意思決定基準 32 Activity ML Engineer Data Engineer Infra Engineer Ops Engineer Stakeholders Model development R/A C I I C Build training pipeline R/A R/A C C I Production deployment R C C C A Monitoring / Operation C R R R/A I Incident primary response C C C R/A I Decision on keep serving model or withdrawing it. C I I I R/A Data Quality and Features R R/A I I R R: 実行責任 A: 承認責任 C: 協議 I: 情報共有 「デプロイの決定」および「撤退決定」は、 必ず事業部門に委ねられなければならない。
33. チームの育成 Copyright © 3-shake, Inc. All Rights Reserved. 33
34. フラグシップユースケースを作ろう 34 高い確率で失敗することが想定される 大規模な建設プロジェクトを一度に始めるよりも、 小さなステップを着実に踏んでいく方が良いでしょう 会社のインフラ全体をゼロから構築しない 01 まずは最小限の要素だけで基盤を構築し、 利用しながら必要な機能を追加 基盤が完成してから利用するのは間違い 02 機械学習モデルに価値をもたらすために使われないものは 作らないようにしましょう MLOpsはプロダクトでもある 03
35. どのようにユースケースを選ぶ？ 35 3つの基準 ビジネス価値が数字で表せる 売上、コスト、作業時間など定量的にビ ジネス価値が測れる項目に焦点を当てる こういうものは避けよう データがすでに存在している データを集めるところから実施すると 最低限の環境構築にも余計な時間が必要 失敗しても許容できる 人命や法令遵守に直接関わる状況には 不向き 完璧な汎用予測プラットフォーム 他社で人気があるから 最初の目標が完璧なプラットフォーム だと成功体験を積むことができない 他の人がたくさんやっているからでは なく、何が自分たちに必要か考える
36. トップダウン型：明確なゴールありきのスタート 36 強み リスク • 迅速な意思決定 • 投資と人材の獲得が容易 • 現場のニーズとの乖離 • 未使用のMLOpsインフラ • 短期的な成果を求める プレッシャーによる基盤の軽視 目標をビジネスKPI （売上／コスト）に変換する 01. 2～3つのユースケース → 共通 の問題点を抽出する 02. 中央チームはランナーに付き添う ことを最優先事項とする 03. マイルストーンの定量化 3ヶ月 → 6ヶ月 → 12ヶ月 04.
37. ボトムアップ型：将来に備えて 37 強み リスク • 現場の課題を原動力として、無駄を なくす • 小規模から始められる • 活用される可能性が高い • 予算と権限の不足による停滞 • 個人の努力への依存 （一人の熱意に頼っている） • 会社側から認識されにくく、 評価されない まずは小さな改善点をイメージ することから始める 01. MLエンジニアが直面する問題点 を取り上げる 02. 成果は数字と事例によって 測られる 03. 人脈を広げる 勉強会、Slackなどを活用する 04.
38. やならいことリストも作ろう！ 38 最初はマネージドサービスで十分です 学習インフラをゼロから構築する 01 全社展開を目指してしまうとゴールが不明瞭になります 全社的な標準化 02 まず、基本的な土台を築くことから始めましょう 完璧なドキュメント 03 他社の例を完全に模倣する 04 自分たちが抱える課題を解決するために仕組みを検討しましょう
39. サマリー 39 トップダウン ボトムアップ きっかけ 経営判断・既存事業 現場で起こった課題 予算 専用の予算がない可能性 スピード 既存事業のスピード感に依存 現場に密着したスピード 主なリスク 使われない大規模基盤になる可能性 属人化・停滞 最初の一歩 ビジネスKPI達成に向けた課題整理 小さな改善の繰り返し 組織配置のおすすめ 独立部門またはプラットフォーム傘下 事業部直下またはチーム発足 成功への鍵 現場との距離を縮める 成功体験の蓄積
40. まとめ Copyright © 3-shake, Inc. All Rights Reserved. 40
41. まとめ 41 MLOpsは組織課題 コード、データ、モデルは、複数の専門分野に わたる連携なしには扱うことができません。 ツールだけでは解決できません。 01. 組織設計は「一枚の紙」から 最初の課題は、ステークホルダー、初期メンバー、 そしてRACIフレームワークを明確に定義すること 02. 最初のユースケースを育成 スモールスタートでPJをはじめ、経験を通して ケイパビリティを身につける 03.
42. ぜひチームを組んで議論してみてください 42 01 02 03 04 組織配置で揉めている方（Platform傘下 vs 事業部直下） 経営・事業部の巻き込み方（予算・稟議が通らない） 初期メンバーが集められない（内部異動 vs 外部採用） 小規模チーム（～5人）でどう始めるか