ウーブン・バイ・トヨタ、Cloud Storage FUSE で AI のトレーニング時間を 20% 短縮
Google Cloud Japan Team
※この投稿は米国時間 2024 年 5 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。
編集者注: この記事ではウーブン・バイ・トヨタの事例をご紹介します。ウーブン・バイ・トヨタは、トヨタの自動運転（AD）と先進運転支援システム（ADAS）の両テクノロジー、それに静岡県裾野市にあるモビリティのためのテストコースである Woven City を支える社内チームです。両テクノロジーはいずれも（また、その他の多くのテクノロジーも）、ウーブン・バイ・トヨタの Enterprise AI プラットフォーム上に構築されています。このブログ投稿では、ウーブン・バイ・トヨタの Enterprise AI プラットフォームを支えるストレージ インフラストラクチャの簡素化に Cloud Storage がどのように役立ったか、そして新しい Cloud Storage FUSE ファイル キャッシュで実現された AI / ML トレーニングの時間短縮と費用削減について、同社の担当者が説明します。 続いて、Google Cloud のプロダクト マネージャーが、Cloud Storage FUSE の仕組みや、独自の AI ワークロードでの構成と実行のベスト プラクティスをご紹介します。
ウーブン・バイ・トヨタは、モビリティにソフトウェア定義自動車のアプローチを採用し、ソフトウェアが持つ変革の力を活用して、自動車分野の革命を先導しています。ウーブン・バイ・トヨタのソフトウェア プラットフォームは、AI の力を数十年に及ぶ経験やイノベーションと組み合わせることで、再利用可能、安全、カスタマイズ可能かつ高品質なアプリケーションを実現します。これらのアプリケーションは、個々の顧客体験に合わせて大規模にパーソナライズできます。
ウーブン・バイ・トヨタのすべての業務を支えるのが Enterprise AI プラットフォームであり、これは ML エンジニアが活用する全社規模のクラウド トレーニング サービスです。 このプラットフォームは、さまざまなエントリー ポイント（コマンドライン ツール、ウェブ ユーザー インターフェース、SDK）と、クラウドにおける当社の ML トレーニングの動作基盤となっているインフラストラクチャ コンポーネントを抽象化する機能を提供します。
簡単に言うと、Enterprise AI プラットフォームにより、ML エンジニアはインフラストラクチャではなく ML 開発に注力できるようになります。それと並行して、ウーブン・バイ・トヨタの ML インフラストラクチャ チームは、このプラットフォームを活用して、分野固有のさまざまな要件のサポート、最適なパフォーマンスを最小限の費用で実現するためのインフラストラクチャのチューニング、増大するトヨタの GPU 需要のマルチクラウド プラットフォーム戦略を通じたサポートにより、トレーニング プロセスを最適化しています。
ウーブン・バイ・トヨタの以前のクラウド ストレージ ソリューション
当社は、ML データセットの信頼できる情報源を実現するために、スケーリングと高い総スループットを提供する能力に着目して、クラウドベースのオブジェクト ストレージ サービスを利用しています。ただし、トレーニング ジョブで低レイテンシ（特に小さなファイル I/O の場合に）を実現し、シンプルなファイル システム ベースのトレーニング データへのアクセスを提供するために、別のクラウド プロバイダによるオブジェクト ストレージ ベースの Lustre 分散ファイル システム サービスも利用していました。
このソリューションには多くの課題がありました。第一に、データ マネジメントとデータ ガバナンスが困難になりました。ウーブン・バイ・トヨタの ML ユーザーは数百万のファイルを含む数テラバイトのデータセットを扱い、それらをクラウド オブジェクト ストレージ、安全なオンプレミスの GPU マシン（ローカル開発用）、クラウドのトレーニング ジョブの間でコピーする必要がありました。ここに Lustre ファイル システムを追加すると、データのコピーと同期が必要となるために、さらに複雑になりました。当社のデータ ガバナンス ポリシーに基づいてデータを適切に管理する必要のある場所が 1 つ増えることにもなりました。
第二に、Lustre ファイル システムの管理と使用には固有の課題があり、メンテナンスも独特です。Enterprise AI チームは Lustre ファイル システム インスタンスの管理とユーザーのサポート リクエストへの対応にますます多くの時間をとられるようになりました。ファイル システムの数とサイズが徐々に増大するにつれ、同チームが抱える運用上の複雑さは増すばかりでした。
最後の課題は費用でした。クラウドベースの Lustre サービスは高額で、倍々に膨れ上がり始めました。ある 1 年間に Lustre サービスの月間ランレートが 10 倍に増加しました。
これらの事情から、ML トレーニングのパフォーマンスのニーズを別のストレージ ソリューションで満たせるかどうかを見極めるための詳細なテストを開始しました。
初期の比較
ウーブン・バイ・トヨタは、同等のパフォーマンス、使いやすさの大幅な向上、全体的な TCO の大幅な削減を実現できるストレージ ソリューションを探しました。そして、当社のニーズを満たすシンプルなソリューションとして、Cloud Storage FUSE のテストを開始しました。Cloud Storage FUSE を使用すると、ML データセットを直接 Cloud Storage バケットからトレーニング ジョブにマウントし、ローカル ファイル システムにファイルとして表示できます。
パフォーマンスのテストと費用比較のために、ウーブン・バイ・トヨタの Enterprise AI チームは、（オープンソースの Detectron2 ライブラリに基づく）カスタム PyTorch フレームワークを使用し、マルチクラスのオブジェクト検出用に ResNet バックボーンに基づくコンピュータ ビジョン モデルを学習するトレーニング ジョブを実行しました。当社の ML エンジニアはこのトレーニング タスクを深く理解していて、実際にユーザーが記述したトレーニング コードによる、オブジェクト検出用の典型的なコンピュータ ビジョン ジョブの良い実例となります。
初期テストでトレーニング時間が 14% 短縮し、費用は 50% 削減されました。Cloud Storage が Lustre のようなファイル システム サービスを利用しないでネイティブに高帯域幅のアクセスを提供し、ストレージ費用が 97% 削減されたことに嬉しい驚きを覚えました。
カイゼンテスト
ウーブン・バイ・トヨタは継続的な改善を意味するカイゼン哲学に組織として傾倒しているため、より深みのあるテストとチューニングを通してパフォーマンスをさらに最適化する方法を探ったのは驚きではないでしょう。
カイゼンテストの次の段階では、1 画像が 500 KiB から 3 MiB の範囲の約 70 万画像サンプルで構成されるトレーニング データセットを使用しました。各トレーニング画像の境界ボックスラベルとメタデータは、一連の JSON ファイルに格納しました。トレーニング ジョブの開始時に、コードがトレーニング画像、ラベル、メタデータのファイルすべてへのパスの一覧を提示する大きな JSON インデックス ファイルを読み取ります。その後、トレーニング プロセスで必要なときにいつでも、コードはデータソース（以前は Lustre ファイル システム）から画像とラベルを再度読み取ります。データ形式とデータのアクセス パターンで効率に改善の余地がありましたが、トレーニング ジョブを実行するために ML ユーザーが実際に記述したコードを反映しているため、最適化は施しませんでした。
使用するスレッド数が異なる場合の ML トレーニング速度への影響、特にデータの読み込みがどれくらい高速になるかをテストしたいと考えました。Cloud Storage を効果的に活用するために、データの同時読み込みを可能にする num_workers 設定で、PyTorch のスレッド数を増やしました。4、8、12 でテストを実施し、num_workers をバッチサイズに設定するのが最適であると判明しました（それ以降は収穫逓減が発生します）。
テストのこの段階で、Cloud Storage FUSE が Enterprise AI プラットフォームにとって最適な選択肢であることを確信しました。実際、Cloud Storage FUSE は、エンジニアに力を与え、費用を最適化する、エレガントで管理しやすいソリューションであることが証明されました。Cloud Storage FUSE により、当社は Cloud Storage を ML データセットのための信頼できる唯一の情報源として維持するとともに、優れたスケーラビリティとパフォーマンス、ML エンジニアにとっての使いやすさに加え、優れた費用管理とデータ ガバナンスを確保できます。しかも、費用は最大 50% 削減されます。
Google Cloud Next ‘24 でも当社の経験を共有しました。こちらから動画をご覧いただけます。
何より、この結果は新たに導入された Cloud Storage FUSE ファイル キャッシュをテストするより前に得られたものです。Cloud Storage FUSE ファイル キャッシュでは、さらなるパフォーマンスと節減を実現できます。では、Google Cloud Storage FUSE プロダクト マネージャーにお返しして、この新機能の詳細を紹介していただきます。
Cloud Storage FUSE ファイル キャッシュの概要とベスト プラクティス
Google Cloud Next ‘24 において、Cloud Storage FUSE の上に構築されるクライアント ベースの読み取りキャッシュである、Cloud Storage FUSE ファイル キャッシュを紹介しました。これを使用すると、ファイルの繰り返し読み取りを、ローカル SSD、Persistent Disk、さらにはインメモリ /tmpfs などの、選択したより高速なローカルのキャッシュ ストレージから提供できます。Cloud Storage FUSE キャッシュはデータの待機に費やされる時間を短縮することで、AI / ML トレーニングの高速化と費用対効果の向上をもたらし、アクセラレータ利用率の向上につながります。
ウーブン・バイ・トヨタは、新しい Cloud Storage FUSE ファイル キャッシュを活用することによりパフォーマンスをさらに向上させました。オペレーション料金の減少による費用削減に加えて、2 エポック目の時間が 33%、合計トレーニング時間が 20% 短縮しました。同社は、本番環境で大規模にデプロイする際に、より大きなデータセットをより長期間トレーニングする結果、改善効果がさらに高まると予想しています。
ウーブン・バイ・トヨタにおける Cloud Storage FUSE ファイル キャッシュの活用によるパフォーマンス改善
Cloud Storage FUSE ファイル キャッシュの使用
Cloud Storage FUSE ファイル キャッシュは、ファイル キャッシュとメタデータ キャッシュ（統計情報、タイプ）からなり、構成ファイルで構成されます。読み取りキャッシュはデフォルトでは無効であり、cache-dir にディレクトリを渡すか、Cloud Storage FUSE GKE CSI ドライバを使用している場合に fileCacheCapacity を指定することで、有効になります。
ご存じですか？A2 と A3 のマシンタイプにはすでに最大 6 TB のローカル SSD がバンドルされていて、Cloud Storage Fuse ファイル キャッシュに使用できます。
キャッシュ容量
max-file-size-mb はファイル キャッシュに使用できる最大サイズ（MiB 単位）です。マウントされているディレクト内で Cloud Storage FUSE キャッシュに利用可能な総容量を制限する場合に有用です。
デフォルトでは、max-size-mb フィールドは -1 の値に設定されていて、データのキャッシュ保存は cache-dir で指定されるディレクトリの利用可能な容量がすべて占有されるまで増加します。キャッシュに保存されているメタデータとデータのエビクションは、最も長い間使用されていないものを削除する（LRU）アルゴリズムに基づいており、上限 max-size-mb で構成される使用量のしきい値に達すると開始されます。
有効期間（TTL）設定
キャッシュの無効化は ttl-secs フラグで制御されます。ファイル キャッシュを使用する場合、データ変更の重要性と頻度に応じて、 ttl-secs をワークロードで許容される最高水準まで増加することをおすすめします。たとえば、ML トレーニング ジョブでは通常は同じデータを複数のエポックすべてで読み取るため、このフラグを全エポックの予想合計トレーニング期間に設定できます。
Cloud Storage FUSE ファイル キャッシュでは、キャッシュの無効化を秒単位の値で指定する以外に、より高度な設定もサポートされています。
-
0 の値では整合性が保証されます。Cloud Storage の呼び出しが少なくとも 1 回行われ、キャッシュ内のオブジェクトの世代が Cloud Storage 内と一致するかどうかがチェックされ、最新ファイルの読み取りが保証されます。
-
一方、-1 の値では、キャッシュ内でファイルを利用できる場合は、オブジェクトの世代をチェックしないで、常にキャッシュからファイルを提供するよう、キャッシュに指示します。これによりパフォーマンスは最適化されますが、整合性のないデータが提供されることがあります。トレーニングのニーズに応じて、これらの高度なオプションを慎重に検討する必要があります。
ランダムおよび部分読み取り
初めてのファイル読み取りで、ファイルの先頭（オフセット 0）から順次読み取る場合は、狭い範囲のサブセットしか読みとらないときでも、Cloud Storage FUSE ファイル キャッシュがインテリジェントにファイル全体を非同期的にキャッシュに取り込みます。これにより、同じオブジェクトからのその後のランダム / 部分読み取りは、同じオフセットからかどうかにかかわらず、入力済みのキャッシュから直接提供されます。
しかし、Cloud Storage FUSE のファイル読み取りが先頭（オフセット 0）から行われない場合は、デフォルトでは非同期の完全ファイル取得がトリガーされません。この動作を変更するには、cache-file-for-range-read: true を渡します。同じオブジェクトから多くの異なるランダム / 部分読み取りを行う場合は、この設定を有効にすることをおすすめします。たとえば、定義された構造化データセットを表す Avro または Parquet ファイルを操作する場合は、同じファイルに対して多くの異なる範囲 / オフセットで多くの異なるランダム読み取りが行われ、この設定の有効化による恩恵を受けます。
統計情報キャッシュとタイプ キャッシュ
Cloud Storage FUSE の統計情報キャッシュとタイプ キャッシュにより、同じファイルの繰り返し読み取りで Cloud Storage のシリアル呼び出しの回数が減少します。これらのキャッシュはデフォルトで有効化され、ファイル キャッシュを伴わないで使用できます。これらのキャッシュを適切に構成すると、パフォーマンスに大きな効果が見られる可能性があります。各キャッシュ タイプで次の上限をおすすめします。
-
stat-cache-max-size-mb: ワークロードが 20,000 ファイルまでの場合は、デフォルト値の 32 を使用します。ワークロードが 20,000 ファイルより大きい場合は、6,000 ファイル追加するごとに stat-cache-max-size-mb の値を 10 増やします（1 ファイルにつきほぼ 1,500 バイト）。
-
type-cache-max-size-mb: マウントするバケットの単一ディレクトリ内の最大ファイル数が 20,000 以下の場合は、デフォルト値の 4 を使用します。マウントする単一ディレクトリ内の最大ファイル数が 20,000 を超える場合は、5,000 ファイルごとに type-cache-max-size-mb の値を 1 増やします（1 ファイルにつきほぼ 200 バイト）。
または、各々の値を -1 に設定して、必要とするだけのメモリ使用をタイプ キャッシュと統計情報キャッシュに許可します。この設定は、上述のガイダンスに基づいて、マウントするバケットのサイズに対応する十分なメモリを利用できる場合にのみ行うようにしてください。他の実行プロセスのメモリ枯渇や、メモリ不足エラーが発生する恐れがあります。
Cloud Storage FUSE と GKE
ウーブン・バイ・トヨタの場合を含め、GKE は AI / ML ワークロードを実行するための重要なインフラストラクチャ コンポーネントになっています。GKE ユーザーは Cloud Storage FUSE を使用して、Cloud Storage FUSE CSI を介し、使い慣れた Kubernetes API でオブジェクトへのシンプル ファイル アクセスを確保しています。また、GKE で Cloud Storage FUSE ファイル キャッシュを有効にして、パフォーマンス向上を実現できるようにもなりました。次の YAML サンプルを使用して、Pod を作成し、fileCacheCapacity に特定の値を渡すことで Cloud Storage FUSE ファイル キャッシュを有効化できます。fileCacheCapacity は Cloud Storage FUSE ファイル キャッシュの最大サイズを制御します。または、ボリューム属性 metadataStatCacheCapacity、metadataTypeCacheCapacity、metadataCacheTtlSeconds を構成し、ワークロードのニーズに応じてファイル キャッシュ設定を調整します。
キャッシュの場所は GKE で自動的に検出、構成されるため、明示的に指定する必要はありません。ノードでローカル SSD が有効な場合、ファイル キャッシュ メディアは自動的にローカル SSD を使用します。それ以外の場合は、デフォルトではファイル キャッシュ メディアはノードのブートディスクです。
次のステップ
ファイル キャッシュ機能の構成に関する追加の詳細を確認し、こちらを参照して Cloud Storage FUSE を今すぐ使い始めましょう。必要な GKE バージョンを確認し、こちらで GKE の追加の手順をご覧ください。
