[Generative AI Summit Tokyo '24] セッション参加レポート - 生成 AI 時代に Google Kubernetes Engine は何を解決してくれるのか

2024.03.09 XIMIX 江口

Generative AI Summit Tokyo '24

「生成 AI」は、ビジネスの成長やイノベーションを促進する非常に大きな可能性を秘めています。昨年 Google は生成 AI アシスタントの「Bard」の提供を開始し、そして「PaLM」や「Gemini」を搭載した Google Cloud の企業向け生成 AI サービスの提供をはじめました。また、生成 AI を利用したアプリケーションを簡単に開発できる統合 AI プラットフォーム「Vertex AI」を進化させています。

本イベントでは、「触ってみる」段階から、「生成 AI を活用したアプリケーションやソリューションを開発する」段階に移行するためのヒントや、開発者、IT 企画、ビジネスまで広く利用できる生成 AI 関連の企業向けソリューションについて、わかりやすく解説します。

この記事では、本イベントのセッション「生成 AI 時代に Google Kubernetes Engine は何を解決してくれるのか」の内容についてまとめます。

はじめに

本セッションの概要は以下の通りです

「Google Kubernetes Engine (GKE) は Google が提供するフルマネージドな Kubernetes プラットフォームです。本セッションでは、生成 AI や ML ワークロードの需要が高まるなかで発生する様々な課題（HW 確保の難しさやインフラコストの増大、低遅延でスケーラブルな学習・推論、等）を GKE がどのようにして解決できるのかについてご説明します。」

実際にAIを用いたシステムの利用者よりも開発者、特にインフラ構築にかかわる開発者向けの内容です。AIに関しては、どういうモデルを構築するとか、サービスをどういう構成にして作ったなどのアプリケーション層が注目されがちですが、どうやってそのアプリケーションを安定的にかつ適切なコストで稼働させられるかというのも非常に重要な観点です。

内容

AI/MLのワークロードにおける課題として、以下の3点が挙げられていました。

ハードウェアリソースの確保の難しさ
インフラコストの増大
低遅延でスケーラブルな学習・推論基盤の提供

これらを、GKEでどのようなアプローチをとることで解決できるかが説明されました。

GKEの特性

まず、GKEの魅力は何といっても柔軟なインフラを構成できることです。
アプリケーションからの要求に応じて自動でスケールアップ/スケールダウンされたり、アプリケーションがコンテナ化されるためにインフラが変わっても簡単に移行できるといった特性があります。
更に、GPUを使いたい場合にドライバのインストールなど事前作業をせずとも定義を記述するだけで利用可能になるなど、ニーズに合わせてマシンを使うことが可能です。

このようなGKEの基本的な特徴を踏まえたうえで、先に挙げた課題への対策が紹介されました。

課題1.ハードウェアリソースの確保の難しさ

AI/MLにおいてはGPUやTPUを利用すべきシーンが多く出てきていますが、ハードウェアを確保するのはオンプレにおいても、クラウドにおいても難しくなってきているようです。
これに対して、GKEではCPU,GPU,TPUなど幅広くハードウェアを提供しているため、実施したい処理の特性やコストに応じた選択をすることが出来ます。
さらに、これらのハードウェアリソースをGKE上で確保するための機構として2023年12月にDWS (Dynamic Workload Scheduler)という機能が発表されました。
これは、ワークロードからのハードウェアリソース確保要求に対して無駄なく応えるためのものです。

例として、「アプリケーションがGPUが3台同時に必要とする場合には、3台同時に確保できるようになるまでGoogleCloud側ではリソース要求を行い、同時に確保できてからGKE上でプロビジョニングする」という動きが挙げられていました。
もし同時に3台確保できずに1台だけ確保された状態になると、アプリケーションとしては処理が出来ないにもかかわらずそのマシンの利用コストがかかってしまいます。DWSはこのような問題を解決するのに役立ちます。

また、事前に特定期間中のリソース確保しておくFeature Reservationsという機能を使うことで、クラウドにおけるリソース確保の確実性を高めることもできます。

課題2.インフラコストの増大

GPUの利用において、GPUは統計的には使用率が低く無駄になっているそうです。これに対して最適に使用されるようにする方法が提示されました。
ノード単位で課金されるGKE Standardにおいては、GPU単位課金にはならないものの、マルチインスタンスGPU, GPUタイムシェアといったオプションによって、複数のPodやコンテナで1つのGPUを共用することが可能です。

また、Kueueというオープンソースツールによる最適化も提案されていました。Kueueはジョブのキューイングをしてジョブの実行順やリソース利用に関する制御を行います。これを用いて、「各チームが使うジョブのハードウェアの利用上限を設ける」ことにより、無駄なハードウェアリソースの確保を避けることが可能です。

もちろんこれらを取り入れずとも、GKE自体が水平/垂直スケーリングを簡単に行えるため、莫大な無駄コストというのはそもそも避けられるのがGKEの良さともいえるでしょう。

課題3.低遅延でスケーラブルな学習・推論基盤の提供

AI/MLのワークロードはサイズが大きくなるようです。そのために、コンテナイメージを取得してきたり、学習のモデルをダウンロードしてくるなどの処理によりアプリケーションが動き出すまでに時間を要するというのが課題です。

それぞれの対応方法としては以下のようなものが紹介されました。

コンテナイメージPull時間削減
コンテナイメージをストリーミングしたり事前Pullしておく方法です。いずれもGKEに設定を行うことで実現可能です。

巨大なモデル取得時間削減
GCSやPersistent Diskに配置して、それらをGKEでマウントする方法です。前者は以前はサードパーティ製でしたが、Cloud Storage FUSE CSI DriverによりGoogle Cloudで公式サポートされるようにもなっています。いずれの方法でもGKEからはローカルファイルと近い形で利用できるので、ダウンロードにかかる時間は不要です。

また、グローバルに利用されるようなシステムの場合、ネットワークレイテンシーも意識する必要があります。
こちらについてはGKEクラスタをマルチクラスタ構成にすることで対応が可能です。単一のIPでありながら、アクセス元に近いリージョンにあるクラスタに通信できることで、レイテンシーの低減に期待することが出来ます。

まとめ・感想

私自身、業務の中でGKEによるスケーラブルなインフラの恩恵を受けるような開発に携わっていますが、AIのように高いスペックが要求される基盤においてGKEを利用するメリットの大きさを強く感じるようなセッションでした。そのうえで、一般的なウェブアプリケーション以上に意識させられるコスト・レイテンシーといった観点においてもGoogleCloudがきめ細やかな機能を提供しているのを知ることが出来る内容でした。

大規模なAI関連のワークロードを運用している方、今後運用しようと考えている方は、今回のセッションを参考にGKEでの運用やその改善を検討してみてはいかがでしょうか？