AI事業本部におけるGPU活用の取り組みとKubernetes CyberAgent, Inc. ・Masaya Aoyama ・Lee Yeongjae ・Daisuke Takahashi @CloudNative Days Spring 2021 Online Session page: https://event.cloudnativedays.jp/cndo2021/talks/451

Who are we? AI Platform Project Manager 2016年にサイバーエージェントに入社。入 社後は広告プロダクトでソリューションアー キテクト、さらにプライベートクラウドや GKE互換なコンテナプラットフォームの開発 を担当。AI系基盤プロジェクトのマネージャ としてAIプラットフォームを開発。 Lee Yeongjae Masaya Aoyama Daisuke Takahashi Developer Experts Kubernetes / Cloud Native 2016年入社。OpenStackを使ったプラ イベートクラウドやGKE互換なコンテナ プラットフォームを構築。Kubernetes 完全ガイド著者。CloudNative Days Tokyo 2019/2020 の Co-chairの他、 MeetupのOrganizerなどにも従事。 Infrastructure Engineer 主にプライベートなOpenStackプラット フォームとKubernetes-as-a-Serviceの 開発、およびさまざまなアクセラレータ デバイス提供における全ての工程を担 当。 GPUaaS / AIプラットフォームの基 盤となる物理インフラを構築。

AIソリューションの実行環境 (例) ユーザ：Researcher, DataScientist, MLOps Engineer Jupyter Notebook ：GUI上で動作する対話型プログラム実行環境 Google AI Platform ：Clientツール/GUIでMLワークフローを管理 モデル学習、評価 モデルのデプロイ モデルによる推論 推論のモニタリング モデルのバージョン管理 コードの実装 入力データの用意

システム構成 DGX A100 AFF A800 GPUaaS （Kubernetes） AI Platform DGX A100 + AFF A800 → 高性能GPUとストレージを提供 GPU as a Service → Jupyter Notebookを提供 独自AI Platform → Google AI Platform相当の基盤を提供

GPUaaSのハードウェアと Kubernetes

● AI基盤の需要に応じて増設 ● GPU不要なワークロードには、 OpenStack環境のVMを提供 ○ Kubernetesクラスタは同一 ● 設計/運用はGPUaaS以外と独立 ○ 物理的な要件の極端な違い ■ 電源: 0.5~1kW→6.5kW ■ NW: ~40GbE→100GbE GPUaaSの物理構成 100GbE 25GbE Compute NVIDIA DGX A100 Network Mellanox SN2010 Storage NetApp AFF A800

NVIDIA DGX A100 ● スペック ○ GPU: 8x NVIDIA A100 40GB (320GB) ○ CPU: 2x AMD Rome EPYC 7742 (128コア) ○ メモリ: 1TB ● 「DGX-Ready」対応データセンターへ設置 ○ 今回はIDCフロンティア様 ○ 電力や冷却能力、搬入経路などが安心

NVIDIA A100 ● Ampereアーキテクチャ ○ 前世代 (V100) と比べて最大20倍 の性能 ● 新しいハードウェア機能 ○ Multi-instance GPU, Sparsity ● GPU同士のより高速な内部接続 ○ 第3世代NVLink/第2世代NVSwitch ○ 最大16枚まで接続可能 ○ 各GPU間を600Gbpsで接続

MIG: Multi-instance GPU MIG mode in the NVIDIA Ampere architecture can run seven jobs in parallel on an A100 GPU (NVIDIA Blog) ● マルチテナンシー ○ DGX A100の場合、8GPUを最大56インスタンスに分割可能 ○ アプリに応じたサイズのGPUを提供可能 ● QoS保証 ○ 各GPUインスタンスのメモリ・コア・転送帯域が独立

MIG for Kubernetes ● パターン1: 事前に分割 ○ 公式Device Pluginで実装済み ○ すべてのワークロードを事前に把握できる必要 ■ 様々な利用者を抱える今回の基盤には不適 ■ 最小単位で分割してマルチGPUとして使うことは不能 (現行CUDAの制約) ● パターン2: 動的に分割 ○ 公式Device Pluginで未実装 ○ Podのresource.requestsに応じて分割 ○ 実装に向けた課題が複数存在 (以下は一部) ■ GPU空き領域のフラグメント化 ● GPUインスタンスの配置を工夫して軽減 ■ Pod作成時はKubernetesから空きGPUが見えない (unschedulable) ● Pending Pod検知→空き領域のあるノードでGPUインスタンス作成

GPUaaS based on Kubernetes

コンテナ + Kubernetes を利用した 利用者や上位のサービスに対して GPUインスタンスを提供する基盤 多岐にわたる Kubernetes の エコシステムをフル活用 ⇒ エコシステムの進化にも追従しながら、 　 プラットフォームの進化を続けることで 　 ビジネスの成功へ GPU as a Service の概要 Container icons: https://icons8.jp/icons/set/video-card Computing resource pool Storage pool

Kubernetes と GPU Kubernetes には Device Plugin という仕組みが用意されている Device Plugin は Plugable になっており、様々なデバイスを Kubernetes で取り扱うことが可能 ● GPU (NVIDIA / AMD / Intel) ● TPU (Tensor Processing Unit) ● FPGA ● etc. 先程紹介した NVIDIA A100 の MIG (Multi Instance GPU) も 将来的には Device Plugin によって動的に扱えるように進めています モニタリングでは Prometheus + DCGM Exporter を利用し、GPU とメモリ使用率を収集 containers: - name: mljob image: my-mljob:v0.1 resources: limits: nvidia.com/gpu: 1 nvidia.com/mig-3g.20gb: 1 （コンテナランタイム側の対応も必要）

Kubernetes とストレージ ストレージ / CSI Driver には NetApp / Trident を採用 １．CSI Driver が多くの機能に対応 ● 3 ヶ月おきのリリースサイクル（2016年12月〜） ● オープンソースでの開発 ● コミュニティへの貢献にも積極的なため、Upstream の追従速度への期待も大きい ○ ストレージ側の機能が十分であっても、CSI Driver が未対応ならその機能は利用できない ○ ＝ 基盤側の機能不足で上位のサービスの価値が提供できない懸念が生まれる ２． ReadWriteMany / ReadWriteOnce の両方に対応（弊社は AFF A800） ● NAS：ML ワークロード向け ● SAN：GPUaaS を構成するアプリケーション向け（Databese、Prometheus、etc） Storage Kubernetes (CO) Container Storage Interface

Kubernetes とさらなる拡張 Kubernetes の拡張性を生かして、自社の特定のドメインに特化した機能を追加 例えば、 ● DB の代替としてアプリケーションが利用するメタデータの保管（Custon Resource / Secret） ● クラウド向け認証情報の自動的なインジェクト（Mutating Webhook / Validating Webhook） ● 自動的に S3 / GCS からのデータロード ＋ キャッシュ（Custom Controller） ● Kubernetesから取得される情報を元にした課金システム

DB の代替としてメタデータの保管 Web UI Console が利用するメタデータは Custom Resource として保存 ● データベースを別途用意する必要が不要 ● Kubernetes RBAC で制限可能 ● 将来的に Controller での機能拡張も容易 e.g. Web UI から起動する際に利用可能なコンテナイメージ

クラウド向け認証情報との連携 クラウド向けの認証情報用に Secret の type を拡張（Validating webhook で検証） ● type: gcp-credential ● type: aws-credential クラウド向けの認証情報を自動マウント（Mutating webhook で挿入） ● Pod のアノテーションに指定 ● ServiceAccount への紐付け ※ その他にも Pod のアノテーションでのマウント無効化など、いくつかの機能も実装

PersistentVolume への S3/GCS データのロード PersistentVolumeClaim 作成時にアノテーションを付与することで S3 / GCS からデータをロード 前述のクラウド向け認証情報を利用することで、Private Bucket のロードも可能 1. PVC にデータをロードする Job の作成 2. PVC の .status.conditions で状態管理 （type = Loading を拡張して追加） 　　　課題：.status.conditions が特に使われておらず、 　　　ロード完了前にも PVC の attach が行われてしまう 機械学習の元データを効率的に扱えるように、 Volume Snapshot との連携も検討中 ※ その他にも 元データを変更されないように ReadOnly なマウントなど、いくつかの機能も実装 （Controller）

GPU as a Service の 2 つの利用方法 GPUaaS は 「専用の Web コンソール」 と 「kubectl」 から操作する Kubernetes API Server GPUaaS API Server $ kubectl ... ● Notebook の起動 ● ボリュームの管理 ● 課金情報の表示 ● プロジェクトの管理 ● etc Web Console kubectl A B

Kubernetes におけるマルチテナンシー ClusterRole と RoleBinding を用いて権限を管理 　「WebUI Console からのプロジェクトへのメンバーの追加」 ＝ 「RoleBinding の追加」 　　にすることで、シームレスに管理（ある意味前述のユーザーDB的にも利用） 　　WebUI Console 側ではその他ロールに応じて様々な処理が可能 UserA namespace UserB namespace TeamX namespace A B TeamY namespace admin clusterrole member clusterrole rolebinding

Hierarchical Namespace によるマルチテナント管理 Hierarchical Namespace Controller を利用して全ての Namespace に対して共通設定を伝搬 　ポリシー、設定データ、クラウドの共通アカウントの認証情報、メタデータ（CustomResource）、etc UserA namespace UserB namespace TeamX namespace GPUaaS namespace policy policy policy policy A B

OAuth2 Proxy + Ingress の連携による認証 API へのアクセス認証は 　OAuth2 Proxy + Ingress（ingress-nginx） 　を利用して Google Account 認証 API Server 側では ユーザ情報をもとに処理を行う GPUaaS API Server Web Console kind: Ingress metadata: name: gpuaas-api-server annotations: nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth" nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"

GPU インスタンスの提供方法 1. Jupyter notebook 環境の提供 with 独自の Web Console データサイエンティストや研究者など Kubernetes に詳しくないユーザー向け 2. Kubernetes CLI を使った SSH ライクな環境 $ kubectl exec -it PODNAME-0 -- bash PODNAME-0 #

GPU インスタンスの提供方法 3. 上位のサービスへの基盤の提供 Kubernetes をベースとした機械学習基盤の開発へ 下位のレイヤーの機能が不十分だと実現したいことが実現できない 　⇒ ストレージの機能、CSI Driver の機能性は重要 DGX A100 AFF A800 AI Platform GPUaaS （Kubernetes） AI Platform Kubernetes のポータビリティを 生かしてマルチ DC 上への展開も検討

AI Platform based on GPUaaS

GCP AI Platform コードベースでMLワークフローを管理するサービス ● Training ○ 機械学習フレームワークで学習 ○ ハイパーパラメータチューニング ○ 分散学習 ● Prediction ○ 学習済みモデルをホスティング ○ サーバレス・スケール可能 ○ 推定値を取得 ● Optimaizer ○ ハイパーパラメータのブラックボックス最適化 ● Pipeline ○ MLワークフローをパイプライン化 AI Platform

#!/bin/bash CURRENT_DATE=$(date +%Y%m%d-%H%M%S) MODEL_NAME="test-model" PACKAGE_PATH=./trainer JOB_NAME=${MODEL_NAME}-${CURRENT_DATE} gcloud ai-platform jobs submit training ${JOB_NAME} --package-path ${PACKAGE_PATH} --config ./config.yaml trainingInput: scaleTier: CUSTOM region: us-east1 jobDir: "gs://test-bucket/test-job" masterType: n1-standard-16 masterConfig: acceleratorConfig: count: 1 type: NVIDIA_TESLA_V100 args: - "--test_arg1=test1" - "--test_arg2=test2" pythonModule: trainer.task pythonVersion: 3.7 runtimeVersion: 2.2 GCP AI Platform Training Training Job definition Submit Training Job trainer/ ├── __init__.py ├── experiment.py ├── model.py └── task.py ML Application Execute ML Application

trainingInput: scaleTier: CUSTOM ・・・ hyperparameters: algorithm: BAYESIAN_OPTIMIZATION goal: MAXIMIZE hyperparameterMetricTag: accuracy maxTrials: 30 maxParallelTrials: 1 params: - parameterName: test-metrics1 type: INTEGER minValue: 40 maxValue: 400 ・・・ runtimeVersion: 2.2 GCP AI Platform Hyperparameter Tuning Training Job definition #!/bin/bash CURRENT_DATE=$(date +%Y%m%d-%H%M%S) MODEL_NAME="test-model" PACKAGE_PATH=./trainer JOB_NAME=${MODEL_NAME}-${CURRENT_DATE} gcloud ai-platform jobs submit training ${JOB_NAME} --package-path ${PACKAGE_PATH} --config ./config.yaml Submit Training Job trainer/ ├── __init__.py ├── experiment.py ├── model.py └── task.py Hyperparameter Section ML Application

開発スピードが下がってしまうため、 GCP/AWSで完結させたい GCP AI Platformのように簡単に学習させられな いため クラウドから移行するのが大変なので使わない (複数回答可) 現在提供しているGPUサービスの不満点を教えてください。 なぜ独自のAI Platformが必要なのか

GCP AI Platformと互換性のあるMLワークフローを管理できる社内基盤 (現状学習部分のみ) 要件 ● GCP AI PlatformのMLワークフローをオフロードできる ○ オブジェクトストレージをハブに ● GCP AI Platformと操作性を統一できる ○ kubectlのプラグイン機能 ● ハイパーパラメータチューニングができる ○ KubeflowのコンポーネントであるKatibを利用 ● GCP AI Platformの設定を再利用できる ○ Katib用のマニフェストに変換 GPUaaS上で動作 & GPUaaSの特徴を継承 AI Platform の概要 DGX A100 AFF A800 GPUaaS （Kubernetes） AI Platform ML Pod

Kubectl Plugin kubectlを拡張し、サブコマンドを作成 1. スクリプト/Binary作成 2. 実行権限設定 3. $PATH以下にkubectl-というPrefixで保存 ※ コマンドで-を使用したい場合は_を使用 $ kubectl plugin list The following kubectl-compatible plugins are available: /usr/local/bin/kubectl-plugin_test $ mv plugin_test.sh /usr/local/bin/kubectl-plugin_test $ kubectl plugin-test This is kubectl plugin test $ chmod +x plugin_test.sh $ cat << EOT >> plugin_test.sh #!/bin/bash echo "This is kubectl plugin test" EOT

GCP AI Platformとの操作性の統一 kubectl ai-platform jobs submit training kubectl ai-platform jobs list|get kubectl ai-platform jobs describe kubectl ai-platform jobs stream-logs kubectl ai-platform jobs cancel On-prem. resource gcloud ai-platform jobs submit training gcloud ai-platform jobs list|get gcloud ai-platform jobs describe gcloud ai-platform jobs stream-logs gcloud ai-platform jobs cancel Cloud resource GCP AI Platform Job definition

Kubernetes上でMLワークフローを構築できるツールキット https://www.kubeflow.org/docs/started/kubeflow-overview/ ● デプロイする環境を選ばない ○ オンプレミスにデプロイ ● Kubernetesによってリソースを管理 ○ 拡張性、豊富なエコシステム ● ハイパーパラメータチューニング ○ Katib ● 多様なOperator ○ 多様なMLフレームワーク Kubeflow

Katib Components Experiment Suggestion Trial Trial Trial TFJob/PytorchJob/Job Pod Worker Container Experiment ● ハイパーパラメータチューニングの実行単位 ● アルゴリズムなど全ての設定を書き込む Suggestion ● ハイパーパラメータを生成 Trial ● 生成したハイパーパラメータを用いて学習を実行 Metrics Container ● 学習モデルの予測精度をMetricsとして保存 Metrics Collector ● MetricsをDBに書き込んでチューニングを完了 Metrics Collector Katib DB Metrics Container

Katib Manifest #1 Metadataなど を定義 Trial数を定義 最適化したい Metricsを定義 アルゴリズム を定義 Metrics Collector を定義 ハイパーパラメータ を定義

Katib Manifest #2 Trialで利用する ハイパーパラメータを定義 TrialのJob Template を定義

GCP AI Platformの設定を再利用 trainingInput: scaleTier: CUSTOM region: us-east1 jobDir: "gs://test-bucket/test-job" workerType: n1-standard-16 workerCount: 2 workerConfig: imageUri: gcr.io/kubeflow-ci/tf-mnist-with-summaries:1.0 hyperparameters: algorithm: RANDOM goal: MAXIMIZE hyperparameterMetricTag: accuracy_1 maxTrials: 12 maxParallelTrials: 3 params: - parameterName: learning_rate type: DOUBLE minValue: 0.01 maxValue: 0.05 - parameterName: batch_size type: INTEGER minValue: 100 maxValue: 200 pythonModule: trainer.task pythonVersion: 3.7 runtimeVersion: 2.2 Clientで 変換/生成

AI Platformシステム構成 icons: https://icons8.jp/icons/set/video-card

AI Platformの内部フロー Job submit基本フロー ①submitコマンド実行 ②モデルのコードを圧縮 ③圧縮したコードをGCSへ ④KatibのExperiment作成 ⑤TrialがPodを作成(+PVをアタッチ) ⑥圧縮されたコードをダウンロード ⑦トレーニング実行 ⑧トレーニング済みモデルを GCSへ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧

AI Platformシステム ~Jobの振り分け~ LabelsでTrialのPod Template内のJob (Operator)を振り分け ● TFJob (TF Operator) ○ --labels framework=tensorflow ● PytorchJob (Pytorch Operator) ○ --labels framework=pytorch ● Job ○ それ以外

AI Platformシステム ~カスタムイメージ~ 利用開始時にINIT処理を行う(ADMIN権限) ● NamespaceのLabelsを更新 ○ katib-metricscollector-injection: enabled ● AI Platform用のServiceAccount作成 ○ imagePullSecretsを管理 imagePullSecretsでカスタムイメージをPullする

AI Platformシステム ~Monitoring~ Metricsの収集を有効化 ● Job Submit時に--metrics-collectorオプションを指定 ● ハイパーパラメータチューニングの設定 → MetricsがPersistent Volumeに保存できる Monitoring環境の構築 ● Monitoring用コマンド発行 → TensorBoardのPod + Ingressが払い出される

TensorBoard 学習フレームワークの可視化ツールキット ● Metricsの追跡と可視化 ● データフローグラフの可視化 ● 学習の履歴の可視化 ● 途中過程で生成される画像などの表示

OSSによる継続的な機能改善 Kubernetesの強みを最大限に まとめ DGX A100 GPUaaS (Kubernetes) AI Platform AI Platform OSSを積極的に活用し、プラットフォームを改善することで、 アプリケーション開発のアジリティが向上し、ビジネスに大 きなインパクトを与える AFF A800 Google AI Platformとの互換性 超高性能なGPU/ストレージ

今後の展望 GPUaaS ● MIGの自動分割機能 AI Platform ● サービング機能 ○ 推論のエンドポイント ● モデルのバージョン管理 ○ トラフィック制御 ● パイプライン機能 ○ MLワークフローの自動化 物理 ● DGX A100/A100 GPU、AFF A800の増強 ● 他のGPU(T4など)との統合によるコスト効率の向上

ご静聴ありがとうございました