@2020__arXiv__Serverless inferencing on Kubernetes

> [!abstract] 概要(arXiv abstract の日本語訳) > 組織は機械学習モデルを大規模に本番投入することが増えている。サーバーレスのスケールツーゼロパラダイムの人気の高まりは、多くのモデルが継続的に利用されるとは限らない状況においてインフラコストを緩和するために機械学習モデルをデプロイする機会をもたらす。本稿では、KNative のサーバーレスパラダイムを基盤として構築され、データサイエンティストがモデルを一貫した単純なインターフェースでデプロイできるようにするサーバーレス機械学習推論ソリューションを提供する KFServing プロジェクトについて論じる。GPU ベースの推論のオートスケーリングという課題をどのように解決するかを示し、本番環境での利用から得られたいくつかの教訓について論じる。 ## 論文情報 - **タイトル**: Serverless inferencing on Kubernetes - **著者・所属**: [[Clive Cox]]([[Seldon Technologies]]) / [[Dan Sun]]([[Bloomberg L.P.]]) / [[Ellis Tarn]](所属記載なし。correspondence はプライベート gmail アドレス) / [[Animesh Singh]]([[IBM]]) / [[Rakesh Kelkar]]([[Microsoft]]) / [[David Goodwin]]([[NVIDIA]]) - **媒体**: ICML 2020 ワークショップ「Challenges in Deploying and Monitoring Machine Learning Systems」で発表。4 ページ・図 1 点。 - **arXiv ID**: 2007.07366(v1: 2020-07-14 投稿、v2: 2020-07-24) - **カテゴリ**: cs.DC(Distributed, Parallel, and Cluster Computing)/ cs.LG / stat.ML - **関連プロジェクト**: [[KFServing]] のコード([[GitHub]]: kubeflow/kfserving)を前提とした実装解説論文。 ## 概要機械学習モデルの本番運用が拡大するなか、多くのモデルが常時稼働している必要はないという特性に注目し、サーバーレスのスケールツーゼロパラダイムでインフラコストを緩和する [[KFServing]] プロジェクトを紹介するポジション/経験報告論文。[[Knative]](さらにその基盤の [[Istio]])上に構築され、単一の Custom Resource Definition(CRD)でデータサイエンティストがフレームワークを問わずモデルをデプロイできる一貫インターフェースを提供する。GPU ベース推論のオートスケーリング問題への解法と、2020年時点での本番運用の教訓・未解決課題を論じる。 ## 問題設定組織が ML モデルを本番投入する際に直面する 4 つの中核的課題を整理する。 1. **多様な ML フレームワークの一貫した扱い**: TensorFlow・PyTorch・XGBoost・SKlearn に加え、RAPIDS・Intel OpenVino のような最適化ソリューションが混在する。ONNX のような標準化も進むが、ONNX は依然としてモデルの一部しか表現できないため、フレームワークネイティブなサービング基盤への需要は根強い。 2. **稼働中モデルのバージョン更新**: canary・shadow デプロイとローリングアップデート・red-green 戦略の組み合わせによる安全な新モデル評価が必要。 3. **制約下での適切なスケーリング**: 同時実行数・レイテンシ・スループット要件に対して、コストとのトレードオフを取りながら反応的にスケールアップ/ダウンする必要がある。 4. **モデルの監視**: レイテンシ・スループット・エラー率という基本指標に加え、精度・入出力分布のようなデータサイエンス固有の指標、ドリフト・外れ値・敵対的攻撃の検知も必要になる。 ## 提案手法 - **アーキテクチャ**: [[Kubeflow]] プロジェクトエコシステム内で作られた [[KFServing]] は、[[Knative]](サーバーレス Kubernetes プロジェクト)を拡張して ML 推論に対応させる。Knative 自身は [[Istio]] を含むサービスメッシュ技術の上に構築され、ルーティング・セキュリティ・トラフィック管理を提供する。KFServing の技術スタックは以下の図の通り、CPU・GPU・TPU を含む Kubernetes クラスタ上で多様な ML サーバー技術を利用可能にする。 **Figure 1: KFServing のクラウドネイティブ技術スタック** ![[_attachments/arxiv-2007.07366/fig01-kfserving-tech-stack.png]] (Figure 1. 最上段に TensorFlow・PyTorch・scikit-learn・XGBoost・ONNX・TensorRT という各種フレームワークと Pre-process/Predict/Post-process/Explain の4処理ステージ、その下に KFServing(Kubeflow 上)、さらに下に Knative・Istio・Kubernetes という各層を積み重ね、最下段の Compute cluster(GPU/TPU/CPU)上で稼働する構成を示す。モデルアセットは右側のストレージと双方向にやり取りされる。) - **InferenceService CRD**: データサイエンティストは保存済みモデルの場所とサーバー種別を指定するだけで、KFServing が (1) 適切なサーバーイメージを持つ Knative サービスの作成、(2) Google Storage/Amazon S3/Azure/ローカルディスクなど主要ストレージからのアーティファクトダウンロード用 storage initializer の作成、(3) 推論エンドポイント用ネットワーキングの配線、を自動で行う。CPU/GPU/TPU/メモリのリソース要求・制限も指定でき、スケジューリングと制限順守が行われる。 ```yaml apiVersion: serving.kubeflow.org/v1alpha2 kind: InferenceService metadata: name: flowers-sample spec: default: predictor: tensorflow: storageUri: gs://kfserving-samples/models/tensorflow/flowers ``` - **canary デプロイ**: `canaryTrafficPercent` フィールドで一部トラフィックを新モデルへ振り分けられる(下記例は 10%)。Kubernetes の宣言的インフラ定義がもたらす reconciliation プロセスにより、リソース定義のバージョン更新のたびにクラスタが最終的にその定義を反映するよう調整される。これは GitOps パターン(バージョン管理下のリソース定義による監査可能な履歴とロールバック)を可能にする。 ```yaml apiVersion: serving.kubeflow.org/v1alpha2 kind: InferenceService metadata: name: flowers-sample spec: default: predictor: tensorflow: storageUri: gs://kfserving-samples/models/tensorflow/flowers canaryTrafficPercent: 10 canary: predictor: tensorflow: storageUri: gs://kfserving-samples/models/tensorflow/flowers-2 ``` - **Transformers / Explainers**: コアモデルサーバーにリクエスト・レスポンスのデータ変換を行う transformer(例: テキストを特徴埋め込みベクトルへ変換)や、個々のリクエスト/レスポンスに対する人間可読な説明を提供する explainer をアタッチ可能。 - **Payload logging**: リクエスト・レスポンスのペイロードを非同期に監視・分析用へ送信するロギングを有効化できる。 - **スケールツーゼロ**: [[Knative]] を基盤とすることで、着信リクエストがない場合にモデルサーバー全体をゼロへスケールし、クラスタがそのリソースを他の稼働中サービスへ割り当て直せる。 ### GPU オートスケーリング(§4.1) GPU を利用するモデルの正しいオートスケーリングは課題が大きい。GPU duty cycle メトリクスは一部の Kubernetes クラウドプラットフォームでしか容易に取得できず、Horizontal Pod Autoscaler(HPA)の設定は容易でない。さらに稼働中サーバーの CPU 使用率と GPU 使用率を組み合わせてオートスケーリング判断へ落とし込むことも難しい。レイテンシベースのオートスケーリングという代替も、スケールアップ判断はできてもスケールダウン判断の実装が難しい。KFServing は Knative を利用することで **Knative Pod Autoscaler(KPA)** の**リクエストベースオートスケーリング**を活用する。KPA は現在処理中(未応答)のインフライトリクエスト数と、設定された同時実行数(既定 1/サーバー、変更可)を見比べてスケール判断を行う。これは複雑な GPU/CPU メトリクスに踏み込まずにスケールアップ・ダウン双方の判断ができる、直感的で汎用的な解法だとされる。 ## 新規性先行研究・既存手法との比較よりも、既存のクラウドネイティブ基盤(Kubernetes・Knative・Istio・Kubeflow)を「組み合わせる」ことによる課題解決に主眼が置かれたシステム論文である。特に強調されるのは、**GPU duty cycle メトリクスの取得困難性・CPU/GPU 指標の統合困難性という GPU オートスケーリング特有の障壁を、GPU/CPU メトリクスに一切依存しないリクエストベース(同時実行数ベース)オートスケーリングへ置き換えることで回避する**という設計判断である。これにより「GPU 向けに個別最適化された複雑なオートスケーリング機構」ではなく、Knative がサーバーレス Web サービス一般向けに持つ既存の KPA をそのまま ML 推論に転用するという、実装コストの小さい汎用解を採る点が特徴。 ## 実験設定本論文は制御実験・ベンチマーク評価を伴わない**本番運用経験の報告(§5 Production Experience)**である。2020年初頭時点で複数組織の本番環境において KFServing が稼働しており、GPT-2(Radford et al., 2019)規模のモデルを含む運用が報告されている。参照される事例: - NVIDIA GTC 2020 の Goodwin & Sun によるプレゼンテーション「Accelerate and autoscale deep learning inference on GPUs with KFServing」 - KubeCon Europe 2020 の Wen & Chen によるプレゼンテーション「Scalable ML model iteration and skewless features with Kubeflow and Feast」 - CoreWeave による KFServing working group プレゼンテーション(GPT-2 規模モデルの本番運用、AI Dungeon) ## 実験結果(本番運用からの知見) - **KPA サイドカー(queue-proxy)と CFS スケジューラの相互作用**: KPA はインフライトリクエストのメトリクスを取得する queue-proxy サイドカーコンテナで一部実装されており、この CPU 利用にはクォータが設定される。しかし Linux カーネルの CFS(Completely Fair Scheduler)のスケジューリングバグにより、主に I/O タスクで構成される「行儀の良い」コンテナであっても CPU スロットリングを受けることがあり、Knative の場合これがモデルサーバーのテールレイテンシへ不必要に悪影響を与える。CPU スロットリングメトリクスの継続的な監視が必要と述べられる。 - **スケールツーゼロ/初回リクエストのレイテンシ**: レイテンシが高いプレミアムを持つシナリオでは、ゼロからの初回リクエストやスケールアップにかかる時間が、特にモデルアーティファクトが大きい場合にプロヒビティブ(許容できないほど大きい)になりうる。この場合、一貫した低レイテンシが全リクエストで要求される要件と、インフラコスト削減というサーバーレスの利点はトレードオフの関係になり、サーバーレスの恩恵が薄れる。 - **バッチングとバッチ遅延**: GPU 上での推論で高いスループットを引き出すにはリクエストのバッチングが重要で、多くの ML/DL フレームワークはバッチリクエスト向けに最適化されている。しかし最適なバッチサイズはトラフィックパターンやロード済みモデル数に依存するため試行が必要であり、秒間トランザクション数がバッチサイズを下回ると「バッチ遅延」が生じてリクエストあたりのレスポンスレイテンシがスパイクする。ロードパターンに応じた慎重・動的なチューニングが必要になる。 - **Istio/Knative スタックの大規模運用**: 数百〜数千のInferenceServiceを抱える規模で Istio/Knative スタックを管理するのは困難な作業になる。Istio の VirtualService はそれぞれ Ingress ゲートウェイのメモリフットプリントを増やし、サービスメッシュ運用時は各サイドカーが Istio コントロールプレーンへの負荷を増やすため、ゲートウェイ・コントロールプレーンのレプリカ数や CPU/メモリ制限の定期的な調整が必要になる。Istio 1.5 でコントロールプレーンの全コンポーネントが単一の istiod に統合され、クラスタ管理者の運用負荷が簡素化されたと述べられる。 ## 考察 **未解決の課題(§6 Open Problems)として明示されたもの:** - 今日の多くのモデルは 5〜30GB 級で、単一リクエストへのサービングに提供 CPU の 100% を消費しうる。インフラコストを許容範囲に保ちながらこれらをスケールする方法は未解決。5〜30GB のモデルダウンロードには非自明な時間がかかり、これがオートスケーリングのレイテンシに悪影響を与えるため、大規模モデルを効果的にスケールするには何らかのキャッシュ・アーティファクト共有の仕組みが必要と指摘される。 - 別のトレンドとして、異なるデータ部分集合で学習された数百〜数千個の小規模モデルを作るケースが観測されている。これらのモデルごとに個別のモデルサーバーを立てるのは実用的でない。モデルサーバーが複数モデルを透過的に共有できる技術、モデルのスケジューリング・オートスケーリング・基盤サーバーへの透過的なシャーディングが必要と述べられる(のちの multi-model serving 研究領域を先取りする課題設定)。 - モデルの監視(入出力データ分布のリアルタイム分析から外れ値・ドリフト・敵対的攻撃検知器の設置まで)は開かれた研究領域であり、各デプロイモデルに対して効率的・自動・正確にこれらのコンポーネントをデプロイすることは難しい課題。KFServing は検知器・分析モジュールをメインのサービングリクエストと非同期に実行する初期解を実装しているが、モデルの新リリースごとにすべての監視コンポーネントを管理・バージョン管理・更新する仕組みにはさらなる作業が必要と述べられる。 **総括(§7 Summary)**: KFServing は container ベースのサーバーレスアプローチによって ML 推論の本番投入課題を解決するが、多様なインフラ・データサイエンス上の課題ゆえに未解決の問題が多く残るとし、OSS プロジェクトとしてコミュニティの協力を呼びかけて結ぶ。 ## 強み / 弱点・課題 **Strengths**: - 単一の CRD(InferenceService)により、フレームワークを問わず一貫したデプロイインターフェースを提供する。 - 宣言的な Kubernetes リソース定義により GitOps ワークフロー(バージョン管理・監査・ロールバック)と自然に統合する。 - canary デプロイ・スケールツーゼロ・transformer/explainer アタッチ・ペイロードロギングを標準機能として内包する。 - GPU オートスケーリングを GPU/CPU メトリクスの複雑な統合なしに、Knative の既存リクエストベースオートスケーラ(KPA)へ委譲することで解決する、実装コストの低い汎用解を採る。 **Weaknesses/Limitations(論文が明示するもの)**: - queue-proxy サイドカーの CPU クォータと Linux CFS スケジューラのバグの組み合わせにより、意図せぬテールレイテンシ悪化が起こりうる(モニタリング負担が生じる)。 - 大規模モデル(5〜30GB)ではスケールツーゼロ/スケールアップのレイテンシが許容できないほど大きくなりうり、低レイテンシ要件とサーバーレスの利点がトレードオフになる。 - 最適バッチサイズはトラフィックパターン・ロード済みモデル数に依存し、ユーザー側の試行・チューニング負担が残る。 - Istio/Knative スタックを大規模(数百〜数千 InferenceService)に運用する際のリソースチューニング負荷が高い。 - 大規模モデルのキャッシュ・アーティファクト共有、数百〜数千個の小規模モデルの透過的な多重化は 2020 年時点で未解決。 - 監視コンポーネント(ドリフト・外れ値・敵対的攻撃検知)のライフサイクル管理(バージョニング・モデルリリースごとの更新)は初期解にとどまる。