KubernetesベースのGPU as a Service Platform ～サイバーエージェントにおけるGPU活用の取り組み～ [INSIGHT Japan 2022 Digital]

Slide 1

Slide 1 text

KubernetesベースのGPU as a Service Platform ～サイバーエージェントにおけるGPU活用の取り組み～ Lee Yeongjae Masaya Aoyama (@amsy810) Daisuke Takahashi

Slide 2

Slide 2 text

Who we are? Daisuke Takahashi Infrastructure Engineer 2019年にサイバーエージェントへ新卒入社。プライベートクラウド運用やコンテナ基盤開発に携わった後、現在は主に Solution ArchitectとしてML/3DCG/アドテク領域を担当。本プロジェクトでは物理層を設計・運用。 Masaya Aoyama 2016年新卒入社。OpenStackを使ったプライベートクラウドや GKE互換なコンテナプラットフォームをゼロから構築。国内最大のCloud Nativeカンファレンスの Co-chairの他、Kubernetes Meetupの Organizerなどにも従事。著書『Kubernetes完全ガイド』 Software Engineer 2016年にサイバーエージェントに入社。入社後は広告プロダクトでソリューションアーキテクト、さらにプライベートクラウドや GKE互換なコンテナプラットフォームの開発を担当。基盤開発チームのマネージャとして AIプラットフォームを開発。 Lee Yeongjae Manager

Slide 3

Slide 3 text

Agenda 1. GPUの必要性 2. ハードウェア 3. KubernetesベースのGPU as a Service 4. AI Platform 5. まとめ・今後の展望

Slide 4

Slide 4 text

なぜAIソリューションが必要なのかコスト削減 ● ビジネスのドメイン知識習得 ● 広告の自動生成効果改善 ● 思いもよらない効果的な広告の発見 ● 広告の効果分析と改善リスク対応 ● 掲載広告の炎上リスク回避

Slide 5

Slide 5 text

なぜGPUが必要なのか莫大・複雑な処理 ● 広告と掲載メディアの組み合わせが膨大 ● 人口統計情報（地域、年齢など）など考慮する情報が膨大高速な実行 ● 急速なトレンドの変化 ● リアルタイムな情報取得

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

なぜオンプレミスなのか機能面 ● 柔軟なソフトウェアスタック ● 既存のサービスとの接続が容易コスト面 ● クラウドの費用は高い ● 長期的に見ると安いクラウドのGPU費用 (ある部門)

Slide 9

Slide 9 text

GPU as a Serviceのハードウェアの歴史

Slide 10

Slide 10 text

v1: GPUコンテナ  ● 複数の研究者が持つ GPU資源の一元管理を実現  ○ 原則、各自が1ホストを占有     v2: GPUコンテナ + Jupyter Notebook  ● 研究者向けにマネージドなNotebook環境を提供  ● v1同様のGPUコンテナ単体も選択可能     v3: GPUコンテナ + Jupyter Notebook + AI Platform  ● 研究者に加え、開発者向けにもv2と同等機能を提供   ● GPUaaS上で動作するAI Platform (GCP互換のML基盤) を開発・ホスティング   GPUaaSの歴史

Slide 11

Slide 11 text

GPUaaS v1 GPU資源の運用の効率化 ● 研究者が個別に利用していたワークステーションを一元管理 ○ 各利用者に1ホスト (ノード) 単位で提供 ● オフィス内のサーバールーム (という名前のMDF室) に設置 ○ GPU: 20x NVIDIA GeForce GTX 1080Ti 11GB (220GB) ○ CPU: 324コア ○ メモリ: 1.28TB 再現が容易な環境 ● コンテナ型仮想化によって実験環境を容易に再構築可能 ● 社内でマネージド基盤の運用実績がある Kubernetesを導入 ○ Kubernetes APIへの直接アクセスを利用者に提供

Slide 12

Slide 12 text

GPUaaS v2 GPUaaS v1の後継 ● GPU資源などはv1から移行 ● ホスト占有から共同利用へ変更 (マルチテナント) NEW: 学習データ用共有ストレージ ● クラスタ内の各コンテナから同一データを参照可能 ● Kubernetes上にSoftware-defined Storageを構築 ○ Rook (Ceph) によるNFSストレージ ○ SATA SSD 48TB分 NEW: マネージドな学習環境 ● Kubernetesを意識させずにJupyter Notebookを提供 ● 他のコンテナイメージも利用可能

Slide 13

Slide 13 text

v2の運用上の課題設置環境 ● オフィスへの高電力機器の設置は想定外 ○ 限られた電力供給と冷却性能 ○ 法定停電 ● データセンターとの接続品質 ○ Site-to-site VPNのみ ○ 非冗長構成マシンの管理 ● リモート管理機能 (IPMI/BMC) の欠如 ○ 些細な作業でも現地での運用が必要 ○ COVID-19によるオフィスの制限性能 ● GPUメモリの不足 ○ ML向けではないGeForceシリーズ ● 経年による陳腐化 ○ 新世代のCPUやGPUの登場 ○ ハードウェア故障の頻度上昇

Slide 14

Slide 14 text

GPUaaSの改善のための検討好評を受けて、サービスの開発者から本番環境としての要望が届いていた求められる品質の達成には、ソフトウェアだけでなく、ハード面の取り組みが不可欠設置環境 ● オフィスの一角を脱却 ● プライベートクラウドを運用している DC (東京都内) に設置スペック ● GPUaaS用のサーバーを新規調達 (IPMI搭載) ● 大容量のメモリを持つデータセンター向け GPU ○ Tesla V100, T4, etc.

Slide 15

Slide 15 text

NVIDIA A100 Ampereアーキテクチャ ● 前世代 (V100) と比べて20倍の性能新しいハードウェア機能 ● Multi-Instance GPU, Sparsity, etc. より高速なGPU-to-GPU接続 ● 第3世代NVLink / 第2世代NVSwitch ● 最大16GPU ● 600 Gbpsのフルメッシュ

Slide 16

Slide 16 text

GPUaaS v3 GPUハードウェアを刷新 ● NVIDIA DGX A100を採用 ○ GPU: 8x NVIDIA A100 40GB (320GB) ○ CPU: 128コア / メモリ: 1TB ■ ソフトウェア面の詳細は後述 ● 「DGX-Ready」対応データセンターへ設置 ○ 電力や冷却能力、搬入経路などが安心 ● 推論: 9x NVIDIA T4 (144GB) を導入済み ● 学習: NVIDIA A100 80GB (500W仕様) を導入予定 INSIGHT初公開情報

Slide 17

Slide 17 text

「ストレージも刷新したい」 

Slide 18

Slide 18 text

v2のストレージの制約 (ハードウェアの仕様)   ● ラックの占有スペースに対して、容量効率が低い  → 大容量ディスクやディスク搭載数の多い筐体の導入  ● A100 GPUの性能に対して、アクセス速度の不足   → ディスク性能とネットワーク性能の改善    ストレージ運用からの解放  ● Rook (Ceph) は既存資源を活用する方針にマッチしていたため選定   ○ ストレージ自体が目的ではないため、 SDSへのモチベーションが高くない  ● → SDSに限らず、アプライアンスも検討     追加の機能  ● GPUaaSの内部メタデータ用のブロックアクセス  ● GPUaaSのログ・メトリクス用のオブジェクトアクセス   ストレージの改善 INSIGHT初公開情報

Slide 19

Slide 19 text

学習データ用共有ストレージを刷新 ● NetApp AFF A800を採用 ○ NVMe SSD 62TB (All-lash) ■ スケールアウト・スケールアップが可能: ● 空きベイへのディスク追加 ● ディスクシェルフ追加 ● コントローラー追加 ○ マルチプロトコルでのアクセスに対応 ■ File (NFS, SMB), Block (iSCSIなど), Object (S3) ○ Kubernetesとの連携は後述 ● 「NVIDIA DGX POD」を意識して選定 ○ DGXシステムとストレージの scalableな参考構成 ○ NetAppからはONTAP AIとして発表 GPUaaS v3 (ストレージ) * Photo of the evaluation system. Some conﬁgurations diﬀer.

Slide 20

Slide 20 text

参考: v3のハードウェア概要 (2022) Compute NVIDIA DGX A100 Dell PowerEdge Servers Network Mellanox SN2010 Storage NetApp AFF A800 100 GbE 25 GbE 10 GbE

Slide 21

Slide 21 text

GPU as a Service with Kubernetes

Slide 22

Slide 22 text

GPU as a Service の概要 Container Computing resource pool Storage pool GPU資源をユーザー・上位サービスに提供する基盤要件 ● タスク実行時に影響を受けないよう GPUを隔離して提供 ● 同時接続可能な高性能ストレージを提供基盤としてコンテナ + Kubernetes を採用

Slide 23

Slide 23 text

Kubernetes の GPU 対応 Kubernetes には Device Plugin という仕組みが用意されている Device Plugin は Plugable になっており、様々なデバイスを Kubernetes で取り扱うことが可能 ● GPU (NVIDIA / AMD / Intel) ● TPU (Tensor Processing Unit) ● FPGA ● etc. NVIDIA A100 の Multi-instance GPU にも対応 containers: - name: mljob image: my-mljob:v0.1 resources: limits: nvidia.com/gpu: 1 （コンテナランタイム側の対応も必要）

Slide 24

Slide 24 text

Kubernetes の強み Reconciliation Loop による宣言された状態への収束エコシステムの豊富さプラットフォームとしての拡張性の高さ 1 2 3

Slide 25

Slide 25 text

1. Reconciliation loop による宣言された状態への収束 Kubernetes では Controller と呼ばれるプログラムがシステムを制御複数の Controller によって宣言された状態に収束 ● 指定されたレプリカ数の維持 ● ノード障害によりコンテナ停止時の再復旧 ● 機密情報や設定ファイル変更時の自動的な再読み込み ● ロードバランサーのメンバーの自動管理 ● etc Actual ReplicaSet (replicas=3) Watch ReplicaSet Controller kind: ReplicaSet spec: replicas: 3 template: spec: containers: - image: nginx:1.16 Desired State Watch

Slide 26

Slide 26 text

2. エコシステムの豊富さ CNCF / Kubernetes コミュニティではオープンな技術促進が進められており、 Kubernetes と連携した様々な OSS が開発・公開されている Reconciliation Loop を利用した OSS の拡張 Controller を利用することで、様々な定常的な運用の大部分を Kubernetes に委譲し、機能追加することが可能【参考】 ● Prometheus / Grafana：GPU や多岐にわたるミドルウェアの監視 ● cert-manager：ACMEを利用した証明書の自動生成と管理、 LoadBalancerとの自動連携 ● external-dns：払い出されたIPアドレスとDNSレコードの管理 ● oauth2-proxy + nginx ingress：WebUI へのリクエストに対する OAuth2 連携 ● Others：オートスケーリング、 Progressive Delibery、プロジェクト間のデータ伝搬、 etc

Slide 27

Slide 27 text

3. プラットフォームとしての拡張性の高さ Kubernetes は自社の特定のドメインに特化した機能拡張も可能 Controller を実装するためのフレームワークなども提供されている（汎用的な OSS も利用している）例えば、 ● 自動的に S3 / GCS からのデータロード＋キャッシュ（Custom Controller） ● クラウド向け認証情報の自動的なインジェクト（ Mutating Webhook） ● DB の代替としてアプリケーションが利用するメタデータの保管（ Secret / ConfigMap） ● Kubernetesから取得される情報を元にした課金システム他にも、コンテナランタイム（ OCI/CRI）・ネットワーク（CNI）・ストレージ（CSI）など、様々な標準化と歩幅を合わせながら実装が進められている

Slide 28

Slide 28 text

Kubernetes の強み Reconciliation Loop による宣言された状態への収束エコシステムの豊富さプラットフォームとしての拡張性の高さ ● 復元力がある ● 管理しやすい ● 可観測性がある ● 堅牢な自動化で頻繁な更新 ● etc 1 2 3 ⇒ OSS の進化にも追従しながら、　プラットフォームの進化を続けることで　ビジネスの成功へ

Slide 29

Slide 29 text

Kubernetes & Storage

Slide 30

Slide 30 text

Kubernetes とストレージの連携 Kubernetes とストレージの連携には Container Storage Interface (CSI) を利用 CSI はオープンな仕様のみ定められており、実際に利用できる機能は CSI Driver により異なる ● https://github.com/container-storage-interface/spec ● https://kubernetes-csi.github.io/docs/drivers.html Storage Container Orchestrator Container Storage Interface ● ボリュームの作成・削除 ● ボリュームのアタッチ・デタッチ ● ボリュームの拡張 ● ボリュームのクローン ● スナップショット・リストア ● トポロジ指定 ● RAWボリュームの作成

Slide 31

Slide 31 text

CSI の機能セット Kubernetes における CSI Driver は複数のサブ機能に分けられているストレージ側の機能が十分であっても、CSI Driver が未対応ならその機能は利用できない CSI Driver 面でストレージ選定時に考慮した点 1. Kubernetes Upstream の機能への追従スピード　　（リリース頻度・Upstream への参加具合） 2. CSI Driver のクオリティ　　（バグ修正の対応速度含む） Container Orchestrator Container Storage Interface Storage Trident

Slide 32

Slide 32 text

OSS としての Trident Trident (CSI Driver) は OSS として公開 ● CSI 以前から開発されていたこともあり、品質も十分開発体制が優れている ● 3 ヶ月おきのリリースサイクル（2016年12月〜） ● コミュニティへの貢献にも積極的なため、Upstream の追従速度への期待も大きい ReadWriteOnce / ReadWriteMany の両方に対応（弊社は AFF） ● NAS：ML ワークロード向け ● SAN：GPUaaS を構成するアプリケーション向け（Databese、Prometheus、etc） ● Object Storage：ストレージバックエンドに利用するアプリケーション向け（Loki、etc）

Slide 33

Slide 33 text

GPU as a Service experience

Slide 34

Slide 34 text

GPUインスタンスのユーザーへの提供 GPU as a Service は専用のコンソールからの操作・kubectl からの操作の 2通り Kubernetes API Server GPUaaS API Server $ kubectl ... ● notebook の管理 ● ボリュームの管理 ● 課金情報の表示 ● プロジェクトの管理 ● etc Web Console kubectl A B

Slide 35

Slide 35 text

GPU インスタンスの提供方法 Kubernetes Namespace を利用してテナント分離 ClusterRole と RoleBinding を利用して権限管理特定のプロジェクトにユーザを追加する＝特定の Namespace で RoleBinding を追加する Console からは Impersonate して Kubernetes API を使用 UserA namespace UserB namespace TeamX namespace A B TeamY namespace admin clusterrole member clusterrole rolebinding

Slide 36

Slide 36 text

GPU インスタンスの提供方法 Hierarchical Namespace Controller を用いて各 Namespace に設定を伝搬ポリシー、設定ファイル、クラウドの認証情報、メタデータ（ CustomResource）など UserA namespace UserB namespace TeamX namespace GPUaaS namespace policy policy policy policy A B

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

AI Platform

Slide 40

Slide 40 text

なぜオリジナルのAI Platformが必要か (複数回答可) 現在のGPUaaSの不満点は何ですか？開発スピードが下がってしまうため、 GCP/AWSで完結させたい AI Platformのように簡単に学習させられないためクラウドから移行するのが大変なので使わない

Slide 41

Slide 41 text

AI Platformの要件学習&推論 ● Google AI PlatformのMLワークフローをオフロードできる ○ オブジェクトストレージをハブに ● Google AI Platformと操作性を統一できる ○ kubectlのプラグイン機能学習 ● ハイパーパラメータチューニングができる ○ Kubeflowのコンポーネントである Katibを利用 ● Google AI Platform Trainingの設定ファイルを再利用できる推論 ● 推論エンドポイントが作成できる ○ Kubeflowのコンポーネントである KFServingを利用 ● モデルのバージョン管理 ○ 社内独自のモデルメタデータ管理基盤を利用 ● 社外からの推論エンドポイントへのアクセス ○ IstioとExternal Authorizationで認可 ● Google AI Platform Predictionの設定ファイルを再利用できる

Slide 42

Slide 42 text

学習&推論

Slide 43

Slide 43 text

オブジェクトストレージをハブに

Slide 44

Slide 44 text

操作性の統一 kubectl ai-platform jobs submit training... kubectl ai-platform jobs submit prediction... kubectl ai-platform predict... kubectl ai-platform models... kubectl ai-platform versions... On-prem. resource gcloud ai-platform jobs submit training... gcloud ai-platform jobs submit prediction... gcloud ai-platform predict... gcloud ai-platform models... gcloud ai-platform versions... Cloud resource Google AI Platform Definition

Slide 45

Slide 45 text

学習

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Katib 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

Slide 48

Slide 48 text

設定を再利用 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 Katibの Manifestに変換/生成

Slide 49

Slide 49 text

AI Platform Trainingのシステム構成

Slide 50

Slide 50 text

推論

Slide 51

Slide 51 text

Kubeflow https://www.kubeflow.org/docs/started/kubeflow-overview/

Slide 52

Slide 52 text

KFServing 概要 ● 推論機能を提供(InferenceServerで定義) ● モデルのサービングを抽象化 (TensorFlow, PyTorch, XGBoostなど対応) ● サービング用コンテナを管理(Knative) ● トラフィックルーティングを管理(Istio) 特徴 ● 自動スケーリング可能 ● カナリアロールアウト/ABテスト可能 ● 予測、前処理、後処理が実行可能

Slide 53

Slide 53 text

Inference Server 概要 ● KFServingのCustom Resource Definition ● 推論エンドポイントの実体 ○ モデルがロードされたコンテナ ○ 推論エンドポイント(FQDN)を払い出す特徴 ● 前処理 / 後処理なども可能 ● PodSpecが記述可能なのでカスタムコンテナも利用可能

Slide 54

Slide 54 text

KFServing Manifests Metadataなどを定義コンテナレプリカ数を定義モデルのロケーションを定義リソースを定義 nodeSelectorなどを定義

Slide 55

Slide 55 text

設定を再利用 name: "tensorflow-gpu" machineType: "n1-standard-32" framework: "TENSORFLOW" deploymentUri: "gs://kfserving-samples/models/tensorflow/flowers" runtimeVersion: "2.4" acceleratorConfig: count: 1 type: "NVIDIA_A100_40GB" autoScaling: minNodes: 0 maxNodes: 5 KFServingの Manifest 変換/生成

Slide 56

Slide 56 text

独自のモデルメタデータ管理基盤概要 ● モデルに様々なメタデータを付与して管理 ● 元々は実験の追実験や再現のための基盤 ● 他の部署で開発・運用特徴 ● モデルのバージョン履歴を保存可能 ● モデルに様々なメタデータを紐付け可能 ○ コードやデータセットなど ● モデルへのアクセス権限を制御可能 ○ READ / WRITE / RWの3パターン ● モデルのロケーションを指定可能 ○ GCS / S3に対応

Slide 57

Slide 57 text

IstioとExternal Authorization External Authorization ● Envoyの機能の一部 ● リクエストの認可を外部の認可サーバに移譲 ● 独自の認可ロジックを実装可能 ● 認可は決められたREST API / gRPC Serviceを実装 ● Istioを用いると設定が簡略化 apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: ext-authz spec: selector: matchLabels: app: istio-ingressgateway action: CUSTOM provider: name: "ext-authz-service" rules: - to: - operation: paths: ["/auth/*"] extensionProviders: - name: "ext-authz-service" envoyExtAuthzGrpc: service: "ext-authz.default.svc.cluster.local" port: 9000 認可対象の登録認可サーバの登録

Slide 58

Slide 58 text

AI Platform Predictionのシステム構成

Slide 59

Slide 59 text

AI Platform PredictionのPredictフロー model作成 ①models createコマンド実行 ②External Authzサーバにて認可 ③モデル登録リクエスト生成 ④メタデータサーバにモデル登録 predict実行 ⑩predictコマンド実行 ⑪External Authzサーバにて認可 ⑫リクエストをInferenceServerに転送 ⑬推論実行 ⑭推論のレスポンスを返却 model version作成 ⑤versions createコマンド実行 ⑥External Authzサーバにて認可 ⑦InferenceServer作成リクエスト生成 ⑧モデルを GCS / S3からダウンロード ⑨InferenceServer生成 ① ② ⑥ ⑪ ③ ④ ⑤ ⑨ ⑦ ⑧ ⑩ ⑫ ⑬ ⑭

Slide 60

Slide 60 text

ログについて必要なログ ● Training Jobのログ ○ 機械学習コンテナの出力 ● Predictionのログ ○ 推論コンテナの出力 ● システムの各種コンポーネントのログ ○ 各種コンポーネント(コンテナ)のログ ■ Katib ■ KFServingなどユーザに提供アプリケーションのDebugに使用システム管理者に提供障害発生時のアラート通知に使用

Slide 61

Slide 61 text

Grafana Loki 概要 ● OSSのロギングツール ● ログの可視化や検索が実現可能に ● 3つのコンポーネントでログ基盤として動作 ○ Grafana + Loki + Promtail 特徴 ● マルチテナント管理 ● 1ログデータ毎にラベルを持つ ● 圧縮されたデータとメタデータを扱うので軽量 ● 複数のバックエンドストレージを利用可能 ● Alert Managerと連携してアラート設定可能 ● Helm Chartsがあるので構築が容易

Slide 62

Slide 62 text

Grafana Loki と NetApp All Flash FAS(AFF) ログデータの構成と対応ストレージ ● Index (検索用インデックス) ○ BoltDB (Local Storage) ○ Single Store (boltdb-shipper) ○ Amazon DynamoDB / Google Bigtable ○ Apache Cassandra ● Chunk (実データ) ○ Local File System ○ Amazon DynamoDB / Google Bigtable ○ Apache Cassandra ○ Amazon S3 / Google Cloud Storage NetApp AFFはブロックストレージとしてもS3としても利用できるので最適 boltdb-shipper

Slide 63

Slide 63 text

まとめ

Slide 64

Slide 64 text

まとめなぜGPUが必要なのか ★莫大・複雑な処理を高速にする必要があるオンプレミスのメリット機能面 ● 柔軟なソフトウェアスタックが組める ● 既存のサービスとの接続が容易コスト面 ● クラウドの費用はやはり高い ● 長期的に見ると安い

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

今後の展望機能 ● パイプライン機能 ○ MLワークフローの自動化 ● ブラックボックス最適化機能物理 ● DGX A100/A100 GPU、AFF A800の増強 ● 他のGPU(T4など)との統合によるコスト効率の向上

Slide 67

Slide 67 text

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