AI事業本部におけるGPU活用の取り組みとKubernetes - CloudNative Days Spring 2021 Online / cndo2021-ca-ml-gpuaas-aiplatform

AI事業本部におけるGPU活用の取り組みとKubernetes
at CloudNative Days Spring 2021 Online

Speaker: 青山 真也・李 榮宰・高橋 大輔
Video: https://event.cloudnativedays.jp/cndo2021/talks/451

サイバーエージェント AI事業本部では、広告領域を始めとして、様々な領域での機械学習のワークロードが増えています。研究者・データサイエンティスト・プロダクト開発者など様々なメンバーが機械学習を利用するなか、利便性の高いGPU/ML環境の提供は欠かせません。 現在に至るまでAI事業本部におけるオンプレGPU環境は様々な変遷があり、現在は2020年にリリースされた NVIDIA A100を利用しNetApp TridentとKubernetesをあわせてGPU/ML環境の提供を開始しています。 本セッションではこれまでの背景をお話しつつ、オープンソースなエコシステムと拡張性を活かしながら、GPU/ML基盤をどのように開発しているかについて紹介します。

Transcript

1. 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
2. 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プラットフォームの基 盤となる物理インフラを構築。
3. AIソリューションの実行環境 (例) ユーザ：Researcher, DataScientist, MLOps Engineer Jupyter Notebook ：GUI上で動作する対話型プログラム実行環境 Google AI Platform ：Clientツール/GUIでMLワークフローを管理 モデル学習、評価 モデルのデプロイ モデルによる推論 推論のモニタリング モデルのバージョン管理 コードの実装 入力データの用意
4. システム構成 DGX A100 AFF A800 GPUaaS （Kubernetes） AI Platform DGX A100 + AFF A800 → 高性能GPUとストレージを提供 GPU as a Service → Jupyter Notebookを提供 独自AI Platform → Google AI Platform相当の基盤を提供
5. GPUaaSのハードウェアと Kubernetes
6. • 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
7. NVIDIA DGX A100 • スペック ◦ GPU: 8x NVIDIA A100 40GB (320GB) ◦ CPU: 2x AMD Rome EPYC 7742 (128コア) ◦ メモリ: 1TB • 「DGX-Ready」対応データセンターへ設置 ◦ 今回はIDCフロンティア様 ◦ 電力や冷却能力、搬入経路などが安心
8. NVIDIA A100 • Ampereアーキテクチャ ◦ 前世代 (V100) と比べて最大20倍 の性能 • 新しいハードウェア機能 ◦ Multi-instance GPU, Sparsity • GPU同士のより高速な内部接続 ◦ 第3世代NVLink/第2世代NVSwitch ◦ 最大16枚まで接続可能 ◦ 各GPU間を600Gbpsで接続
9. 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インスタンスのメモリ・コア・転送帯域が独立
10. MIG for Kubernetes • パターン1: 事前に分割 ◦ 公式Device Pluginで実装済み ◦ すべてのワークロードを事前に把握できる必要 ▪ 様々な利用者を抱える今回の基盤には不適 ▪ 最小単位で分割してマルチGPUとして使うことは不能 (現行CUDAの制約) • パターン2: 動的に分割 ◦ 公式Device Pluginで未実装 ◦ Podのresource.requestsに応じて分割 ◦ 実装に向けた課題が複数存在 (以下は一部) ▪ GPU空き領域のフラグメント化 • GPUインスタンスの配置を工夫して軽減 ▪ Pod作成時はKubernetesから空きGPUが見えない (unschedulable) • Pending Pod検知→空き領域のあるノードでGPUインスタンス作成
11. GPUaaS based on Kubernetes
12. コンテナ + Kubernetes を利用した 利用者や上位のサービスに対して GPUインスタンスを提供する基盤 多岐にわたる Kubernetes の エコシステムをフル活用 ⇒ エコシステムの進化にも追従しながら、 　 プラットフォームの進化を続けることで 　 ビジネスの成功へ GPU as a Service の概要 Container icons: https://icons8.jp/icons/set/video-card Computing resource pool Storage pool
13. 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 （コンテナランタイム側の対応も必要）
14. 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
15. Kubernetes とさらなる拡張 Kubernetes の拡張性を生かして、自社の特定のドメインに特化した機能を追加 例えば、 • DB の代替としてアプリケーションが利用するメタデータの保管（Custon Resource / Secret） • クラウド向け認証情報の自動的なインジェクト（Mutating Webhook / Validating Webhook） • 自動的に S3 / GCS からのデータロード ＋ キャッシュ（Custom Controller） • Kubernetesから取得される情報を元にした課金システム
16. DB の代替としてメタデータの保管 Web UI Console が利用するメタデータは Custom Resource として保存 • データベースを別途用意する必要が不要 • Kubernetes RBAC で制限可能 • 将来的に Controller での機能拡張も容易 e.g. Web UI から起動する際に利用可能なコンテナイメージ
17. クラウド向け認証情報との連携 クラウド向けの認証情報用に Secret の type を拡張（Validating webhook で検証） • type: gcp-credential • type: aws-credential クラウド向けの認証情報を自動マウント（Mutating webhook で挿入） • Pod のアノテーションに指定 • ServiceAccount への紐付け ※ その他にも Pod のアノテーションでのマウント無効化など、いくつかの機能も実装
18. 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）
19. GPU as a Service の 2 つの利用方法 GPUaaS は 「専用の Web コンソール」 と 「kubectl」 から操作する Kubernetes API Server GPUaaS API Server $ kubectl ... • Notebook の起動 • ボリュームの管理 • 課金情報の表示 • プロジェクトの管理 • etc Web Console kubectl A B
20. Kubernetes におけるマルチテナンシー ClusterRole と RoleBinding を用いて権限を管理 　「WebUI Console からのプロジェクトへのメンバーの追加」 ＝ 「RoleBinding の追加」 　　にすることで、シームレスに管理（ある意味前述のユーザーDB的にも利用） 　　WebUI Console 側ではその他ロールに応じて様々な処理が可能 UserA namespace UserB namespace TeamX namespace A B TeamY namespace admin clusterrole member clusterrole rolebinding
21. Hierarchical Namespace によるマルチテナント管理 Hierarchical Namespace Controller を利用して全ての Namespace に対して共通設定を伝搬 　ポリシー、設定データ、クラウドの共通アカウントの認証情報、メタデータ（CustomResource）、etc UserA namespace UserB namespace TeamX namespace GPUaaS namespace policy policy policy policy A B
22. 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"
23. GPU インスタンスの提供方法 1. Jupyter notebook 環境の提供 with 独自の Web Console データサイエンティストや研究者など Kubernetes に詳しくないユーザー向け 2. Kubernetes CLI を使った SSH ライクな環境 $ kubectl exec -it PODNAME-0 -- bash PODNAME-0 #
24. GPU インスタンスの提供方法 3. 上位のサービスへの基盤の提供 Kubernetes をベースとした機械学習基盤の開発へ 下位のレイヤーの機能が不十分だと実現したいことが実現できない 　⇒ ストレージの機能、CSI Driver の機能性は重要 DGX A100 AFF A800 AI Platform GPUaaS （Kubernetes） AI Platform Kubernetes のポータビリティを 生かしてマルチ DC 上への展開も検討
25. AI Platform based on GPUaaS
26. GCP AI Platform コードベースでMLワークフローを管理するサービス • Training ◦ 機械学習フレームワークで学習 ◦ ハイパーパラメータチューニング ◦ 分散学習 • Prediction ◦ 学習済みモデルをホスティング ◦ サーバレス・スケール可能 ◦ 推定値を取得 • Optimaizer ◦ ハイパーパラメータのブラックボックス最適化 • Pipeline ◦ MLワークフローをパイプライン化 AI Platform
27. #!/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
28. 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
29. 開発スピードが下がってしまうため、 GCP/AWSで完結させたい GCP AI Platformのように簡単に学習させられな いため クラウドから移行するのが大変なので使わない (複数回答可) 現在提供しているGPUサービスの不満点を教えてください。 なぜ独自のAI Platformが必要なのか
30. 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
31. 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
32. 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
33. Kubernetes上でMLワークフローを構築できるツールキット https://www.kubeflow.org/docs/started/kubeflow-overview/ • デプロイする環境を選ばない ◦ オンプレミスにデプロイ • Kubernetesによってリソースを管理 ◦ 拡張性、豊富なエコシステム • ハイパーパラメータチューニング ◦ Katib • 多様なOperator ◦ 多様なMLフレームワーク Kubeflow
34. 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
35. Katib Manifest #1 Metadataなど を定義 Trial数を定義 最適化したい Metricsを定義 アルゴリズム を定義 Metrics Collector を定義 ハイパーパラメータ を定義
36. Katib Manifest #2 Trialで利用する ハイパーパラメータを定義 TrialのJob Template を定義
37. 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で 変換/生成
38. AI Platformシステム構成 icons: https://icons8.jp/icons/set/video-card
39. AI Platformの内部フロー Job submit基本フロー ①submitコマンド実行 ②モデルのコードを圧縮 ③圧縮したコードをGCSへ ④KatibのExperiment作成 ⑤TrialがPodを作成(+PVをアタッチ) ⑥圧縮されたコードをダウンロード ⑦トレーニング実行 ⑧トレーニング済みモデルを GCSへ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧
40. AI Platformシステム ~Jobの振り分け~ LabelsでTrialのPod Template内のJob (Operator)を振り分け • TFJob (TF Operator) ◦ --labels framework=tensorflow • PytorchJob (Pytorch Operator) ◦ --labels framework=pytorch • Job ◦ それ以外
41. AI Platformシステム ~カスタムイメージ~ 利用開始時にINIT処理を行う(ADMIN権限) • NamespaceのLabelsを更新 ◦ katib-metricscollector-injection: enabled • AI Platform用のServiceAccount作成 ◦ imagePullSecretsを管理 imagePullSecretsでカスタムイメージをPullする
42. AI Platformシステム ~Monitoring~ Metricsの収集を有効化 • Job Submit時に--metrics-collectorオプションを指定 • ハイパーパラメータチューニングの設定 → MetricsがPersistent Volumeに保存できる Monitoring環境の構築 • Monitoring用コマンド発行 → TensorBoardのPod + Ingressが払い出される
43. TensorBoard 学習フレームワークの可視化ツールキット • Metricsの追跡と可視化 • データフローグラフの可視化 • 学習の履歴の可視化 • 途中過程で生成される画像などの表示
44. OSSによる継続的な機能改善 Kubernetesの強みを最大限に まとめ DGX A100 GPUaaS (Kubernetes) AI Platform AI Platform OSSを積極的に活用し、プラットフォームを改善することで、 アプリケーション開発のアジリティが向上し、ビジネスに大 きなインパクトを与える AFF A800 Google AI Platformとの互換性 超高性能なGPU/ストレージ
45. 今後の展望 GPUaaS • MIGの自動分割機能 AI Platform • サービング機能 ◦ 推論のエンドポイント • モデルのバージョン管理 ◦ トラフィック制御 • パイプライン機能 ◦ MLワークフローの自動化 物理 • DGX A100/A100 GPU、AFF A800の増強 • 他のGPU(T4など)との統合によるコスト効率の向上
46. ご静聴ありがとうございました