CADDi AI LabにおけるマネージドなMLOps 第20回 MLOps 勉強会 2022/06/15 CADDi AI Lab Tech Lead Shunsuke Kawai

I AM • CADDi, inc. AI Lab Tech Lead M3, inc. Engineering Fellow Developers Guild Bolder’s Owner Shunsuke Kawai (@vaaaaanquish)

AGENDA 1. CADDi AI Lab 2. CADDiでのスケーラブルなMLOps 3. まとめ

CADDi AI Lab

CASE • CADDiは製造業を変える企業です • Tech Blog、Speaker Deck、テックイベントで応用事例を公開中

Algorithm Eng 2D/3D Image Processing AtCoder Ranker PdM / EM ex - PFN, NTT, CTO ML Eng ex - DeNA, M3, Mckinsey Kaggle Master/Grandmaster Data Eng ex-Yahoo! DataAnalyst MEMBERS ● ＋海外にManager/MLEメンバー ● ML EngineerとAlgorithm Engineerが共存している ● MLOps Engineerが居ない

TECH STACK • PythonとRustが共存 • Python：機械学習 • Rust：画像処理アルゴリズム、WebAssembly • データの管理、検索にも対応 • Opensearch：情報検索、ANN • dbt：全社データPipeline

MLOps • 機械学習エンジニア、アルゴリズムエンジニア、データエンジニアが プラットフォームチーム(5名)と協業しながらMLOpsをしている • Productionへの提供スピードを上げるためにデプロイ、運用までが基本 • マネージドでスケーラブルなサービスに乗っかる事だけを考えたい

CADDiでの スケーラブルなMLOps

BACKGROUND ● Kubernetes (GKE) を極力避けたい ○ GPUの扱いの難しさ ■ CPUマシンとのリソースの取り方の違いによるAuto ScalingやProvisioning ○ k8sクラスタ管理の大変さ ■ MLモデルに起因した問題か一見して判別出来るようになるまでに整備が必要 ■ yaml, ArgoCD, CLI, Logging ,監視, Driver, …など関連ツールや権限の管理 ○ サービス毎に必要な単位でGKEクラスタ自体はあるが、横断組織であるAI Labにはない ○ MLOps Engineerが居る場合やSREチームが面倒見てくれる場合は良いがAI LabにはToo Match ● モデルファイル用のバージョン管理だとかストレージだとかloaderとかも頑張りたくない ● Cloud Runくらい簡単なコンテナベースでマネージドな上に粗結合なシステムで運用したい！ ○ Cloud RunでGPUはAnthosで出来なくはないけど… ● 定期学習/推論を考えるとAPIとBatch両方扱える必要がある

10 ● 最大限Vertex AIに依存したMLOps ○ Vertex Pipeline ○ Vertex Model/Endpoint/Batch Prediction ○ Vertex Matching Engine ● ユースケースに合わせてServingや認証認可も出来る限り省エネに ○ Tract：DNNモデルをONNXに変換しRustから呼び出す (Rust、何もわからない... #2) ○ TorchServe ○ Cloud Run / Cloud Functions ○ IAM / Auth0 Vertex AI ＆ Tools

Vertex Pipeline ● Good ○ kubeflowのDSLのような形式で PythonのみでPipelineの記述が可能 ○ 各Task毎に独自のContainer/GPU ■ RustとPython、CPU/GPU共存 ○ GCSマウント等も可能かつサーバレス ● Bad ○ デバッグがつらい ■ 起動時のImage Buildに時間がかかる ■ 既に動作しているスクリプトを Pipelineに乗せるという運用が良い

© 2022 CADDi Inc. Cloud Storage train vertex pipeline RECOMMENDATION PIPELINE Recommendation for manufacturing supplier ● 受発注の会社を紐付けるための社内向けレコメンドエンジン Using ● Vertex Pipeline ● LightGBM Big Query predict vertex pipeline CADDi AI Lab Description - speakerdeck

Vertex Model/Endpoint/Batch Prediction ● Model ○ GCRよりCustom Containerを指定 ○ Input/Outputの固定Interfaceを返せるHTTP Serverが立っていれば良い ● Endpoint ○ Modelに設定したContainerをAPIとしてHostingできる ○ Good ■ min_replica_count(>1) から max_replica_countの間でオートスケール ■ GPUが指定できる ○ Bad ■ Cloud Run等と違ってインスタンスを0の状態にはできない ■ DataDog等を使っている場合接続が厄介（VertexAI MetricsもあるがBETA） ● Batch Prediction ○ Modelに設定したContainerをBatchとして実行できる ○ Good ■ アウトプットをGCSに設置する前提ならGPUも使えて十分機能する ■ 予測利用者側がnode数やリソースを指定するようにできる ○ Bad ■ GCSに設置された結果を触るCloud Functionsなりが必要

TorchServe ● 良い感じにServingしてくれるAWS/Facebookが作っているツール ● Flask/FastAPI/gunicorn/uvicorn/…等でServingすると xxxicornのwokerとPyTorchのスレッド数とGPUとk8s podのバランスを考えたり… ○ 良い感じに解決してくれる ○ CPU/GPU/woker管理、複数モデル管理、Management API、監視 ● Bad point程ではないがGCSのmodel file設置には現時点で未対応 (S3はある) APP BESTPRACTICE - PyTorch Document Google Cloud上のPyTorch：VertexAIにPyTorchモデルをデプロイする方法 - Google Cloud TorchServe を使用した大規模な推論のための PyTorch モデルをデプロイする - AWS

Vertex Endpoint + TorchServe • Vertex Endpoint　→　Cloud Run • Vertex Batch Prediction　→　GCS + Cloud Functions/PubSub TorchSearve Vertex Model Model File torch-model-archiver Model File hundler Inference API Vertex Endpoiont / Batch Prediction 各種サービスへ提供

Vertex Endpoint + TorchServe • Good • ModelのServingやAuto Scalingについてはほぼ考えなくて良い • MLEがPythonでFastAPI実装するよりも簡単 • 複雑な設定ファイルやツール郡は不要になる (gcloud, aiplatform, terraform程度) • Rustなどでの画像処理アルゴリズムも同様に乗せる事ができる • サービス間の連携、認証認可のみ考えれば良い • Bad • Model FileをDocker内に収める必要あり • Vertex EndpointがInterface固定なためTorchServeのManagementAPIが十分に使えない

Vertex Matching Engine • ANN検索を提供するフルマネージドサービス（近い〇〇をフルマネージドで提供できる） • Good • Opensearch等より簡易にANN類似画像検索が提供可能 • DNNモデルがあるなら提供までが一番早い • SaaS用に作ったものから社内検証のために利用 • indexの張替え等もフルマネージド • response速度がかなり早い (< 10ms) • Bad • 任意のidに対する類似、のような機能はない • AI LabではFirestoreに{id, 特徴vector}を保存 • やや高い (> $1000/month) あらゆるデータの瞬時アクセスを実現する Google のベクトル検索技術 - Google Cloud

MISTAKE • Vertex workbench • ホスティングされたNotebook • カスタムコンテナも使えて任意のサービスアカウントでGUI内から直接BigQuery等が見える • notebookを使わないアルゴリズムエンジニアも居るためベース環境ではなくなった • Rust扱いづらいしインスタンス立てた方が…となった • 最初のモデルはFastAPIに乗ってしまった • Dockerの状態で出来てしまっていたため移植簡単だと判断 • thread/woker設定、k8s設定の調整で足元持っていかれた • 負荷テストを書いたりして検証していった • MLOps EngineerをAI Lab設立から半年採用できなかった • スケールするには必須（何も考えてませんでした…）

SUMMARY • Vertex Endpoint + TorchServeが良いぞ • Vertex Pipelineが良いぞ • CADDiにおけるMLOps/Data Engineerの ファーストペンギンになりませんか？