[Storage (ストレージ)]

データ管理とストレージ

CSI ドライバーを使用して AI モデルをポッドにデプロイする

AI/ML ワークロードでは、多くの場合、大規模なモデルアーティファクト (トレーニング済みの重み、設定など) にアクセスする必要があり、ポッドではコンテナイメージに埋め込まずにこれらにアクセスするための信頼性が高くスケーラブルな方法が必要であるため、イメージサイズとコンテナレジストリのプル時間が長くなる可能性があります。ボリュームマウントを管理する運用上のオーバーヘッドを減らすには、それぞれの CSI ドライバーを使用して Amazon ストレージサービス (S3、FSx for Lustre、EFS など) を永続ボリューム (PVs) としてマウントすることで、ポッドに AI モデルをデプロイすることをお勧めします。実装の詳細については、このセクションの後続のトピックを参照してください。

EKS での ML モデルキャッシュのストレージの最適化

最適なストレージソリューションを活用することは、ポッドとアプリケーションの起動レイテンシーを最小限に抑え、メモリ使用量を削減し、必要なレベルのパフォーマンスを取得してワークロードを高速化し、ML ワークロードのスケーラビリティを確保するために不可欠です。ML ワークロードはモデルファイル (重み) に依存することが多いため、サイズが大きくなり、ポッドまたはノード間でデータへの共有アクセスが必要になる場合があります。最適なストレージソリューションの選択は、単一ノード効率、マルチノードアクセス、レイテンシー要件、コスト制約、データ統合要件 (Amazon S3 データリポジトリなど) など、ワークロードの特性によって異なります。ワークロードでさまざまなストレージソリューションをベンチマークして、どのソリューションが要件を満たすかを把握することをお勧めします。ワークロードの要件に基づいて評価できるように、以下のオプションが用意されています。

EKS CSI ドライバーは、次の AWS ストレージサービスをサポートしています。それぞれに独自の CSI ドライバーがあり、AI および ML ワークフローに独自の強みがあります。

AWS ストレージサービスの選択は、デプロイアーキテクチャ、スケール、パフォーマンス要件、コスト戦略によって異なります。Storage CSI ドライバーは EKS クラスターにインストールする必要があります。これにより、CSI ドライバーは Pod のライフサイクル外で永続ボリューム (PV) を作成および管理できます。CSI ドライバーを使用すると、サポートされている AWS ストレージサービスの PV 定義を EKS クラスターリソースとして作成できます。その後、ポッドは PV の永続ボリュームクレーム (PVC) を作成して、データボリュームのこれらのストレージボリュームにアクセスできます。AWS ストレージサービスとデプロイシナリオに応じて、単一の PVC (および関連する PV) をワークロードの複数の Pod にアタッチできます。たとえば、ML トレーニングの場合、共有トレーニングデータは PV に保存され、複数の Pod によってアクセスされます。リアルタイムのオンライン推論の場合、LLM モデルは PV にキャッシュされ、複数の Pod によってアクセスされます。AWS ストレージサービス用のサンプル PV および PVC YAML ファイルを以下に示します。

シナリオ: 複数の GPU インスタンスのワークロード

Amazon FSx for Lustre: 分散トレーニングやモデル提供など、レイテンシーの影響を受けやすい高帯域幅スループットの動的ワークロードを持つ複数の EC2 GPU コンピューティングインスタンス環境があり、ネイティブの Amazon S3 データリポジトリ統合が必要な場合は、Amazon FSx for Lustre をお勧めします。FSx for Lustre は、ハイパフォーマンスコンピューティング (HPC)、Machine Learningなどのコンピューティング集約型のワークロード向けに設計されたフルマネージド型のハイパフォーマンス並列ファイルシステムを提供します。

FSx for Lustre CSI ドライバーをインストールして FSx ファイルシステムを永続ボリューム (PV) として EKS にマウントし、FSx for Lustre ファイルシステムをスタンドアロンの高性能キャッシュとしてデプロイするか、S3-linkedファイルシステムとしてデプロイして S3 データの高性能キャッシュとして機能し、GPU コンピューティングインスタンス間でデータアクセスの高速 I/O と高スループットを実現できます。FSx for Lustre は、Scratch-SSD または Persistent-SSD ストレージオプションを使用してデプロイできます。

Scratch-SSD ストレージ: 一時的または短期間 (時間) のワークロードに推奨され、TiB あたりの固定スループット容量がプロビジョニングされます。
永続的 SSD ストレージ: HPC シミュレーション、ビッグデータ分析、Machine Learningトレーニングなど、最高レベルの可用性を必要とするミッションクリティカルで長時間実行されるワークロードに推奨されます。Persistent-SSD ストレージでは、必要なストレージ容量とスループット容量 (TiB あたり) の両方を設定できます。

パフォーマンスに関する考慮事項：

FSx for Lustre ファイルシステムを管理する管理ポッド: lustre クライアントがインストールされ、FSx ファイルシステムがマウントされた「管理」ポッドを設定します。これにより、アクセスポイントは FSx ファイルシステムのファインチューニングを有効にできます。また、GPU コンピューティングインスタンスを起動する前に ML トレーニングデータまたは LLM モデルを使用して FSx ファイルシステムを事前ウォーミングする必要がある状況でも有効にできます。これは、アーキテクチャがスポットベースの Amazon EC2 GPU/コンピューティングインスタンスを使用している場合に特に重要です。ここでは、管理ポッドを使用して、必要なデータを FSx ファイルシステムに「ウォーム」または「プリロード」して、スポットベースの Amazon EC2 インスタンスの実行時にデータを処理できるようにすることができます。
Elastic Fabric Adapter (EFA): Persistent-SSD ストレージデプロイタイプは Elastic Fabric Adapter (EFA) をサポートしています。EFA の使用は、高性能でスループットベースの GPU ベースのワークロードに最適です。FSx for Lustre は NVIDIA GPUDirect Storage (GDS) をサポートしています。ここで、GDS は、ローカルストレージまたはリモートストレージと GPU メモリ間の直接データパスを作成し、データアクセスを高速化するテクノロジーです。
圧縮: 圧縮できるファイルタイプがある場合は、ファイルシステムでデータ圧縮を有効にします。これにより、データ圧縮によって FSx for Lustre ファイルサーバーとストレージ間で転送されるデータ量が減るため、パフォーマンスを向上させることができます。
Lustre ファイルシステムのストライピング設定：
- データストライピング: FSx for Luster が Lustre ファイルシステム内の複数のオブジェクトストレージターゲット (OSTs) にファイルのデータを分散できるようにします。特に大規模な ML トレーニングジョブでは、並列アクセスとスループットを最大化します。
- スタンドアロンファイルシステムのストライピング: デフォルトでは、FSx for Lustre のプログレッシブファイルレイアウト (PFL) 機能を介して 4 コンポーネントの Lustre ストライピング設定が作成されます。ほとんどのシナリオでは、デフォルトの PFL Lustre ストライプ数/サイズを更新する必要はありません。Lustre データストライピングを調整する必要がある場合は、FSx for Lustre ファイルシステムのストライピングパラメータを参照して、Lustre ストライピングを手動で調整できます。
- S3-Linkedファイルシステム: ネイティブ Amazon S3 統合 (データリポジトリ関連付けまたは DRA) を使用して FSx ファイルシステムにインポートされたファイルは、デフォルトの PFL レイアウトではなく、ファイルシステムの ImportedFileChunkSizeパラメータでレイアウトを使用します。より大きい S3-imported、ImportedFileChunkSize定義された値 (デフォルトImportedFileChunkSizeは 1GiB) に基づいてストライプカウントを持つ複数の OSTs に保存されます。大きなファイルがある場合は、このパラメータをより高い値に調整することをお勧めします。
- 配置: FSx for Lustre ファイルシステムをコンピューティングノードまたは GPU ノードと同じアベイラビリティーゾーンにデプロイして、データへのレイテンシーを最小限に抑え、アベイラビリティーゾーン間のアクセスパターンを回避します。異なるアベイラビリティーゾーンに複数の GPU ノードがある場合は、低レイテンシーのデータアクセスのために各アベイラビリティーゾーンに FSx ファイルシステムをデプロイすることをお勧めします。

例

静的プロビジョニング (FSx インスタンスがすでにプロビジョニングされている場合) を使用した FSx for Lustre ファイルシステムの永続ボリューム (PV) 定義。


apiVersion: v1
kind: PersistentVolume
metadata:
  name: fsx-pv
spec:
  capacity:
    storage: 1200Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  mountOptions:
    - flock
  persistentVolumeReclaimPolicy: Recycle
  csi:
    driver: fsx.csi.aws.com
    volumeHandle: [FileSystemId of FSx instance]
    volumeAttributes:
      dnsname: [DNSName of FSx instance]
      mountname: [MountName of FSx instance]

例

と呼ばれる PV の永続ボリュームクレーム定義fsx-pv：


apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fsx-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: ""
  resources:
    requests:
      storage: 1200Gi
  volumeName: fsx-pv

例

の永続ボリュームクレームを使用するようにポッドを設定しますfsx-claim。


apiVersion: v1
kind: Pod
metadata:
  name: fsx-app
spec:
  containers:
  - name: app
    image: amazonlinux:2023
    command: ["/bin/sh"]
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: fsx-claim

完全な例については、GitHub の FSx for Lustre ドライバーの例を参照してください。

シナリオ: 単一 GPU インスタンスのワークロード

Mountpoint for Amazon S3 with CSI Driver: Mountpoint for Amazon S3 CSI ドライバーを使用して、S3 バケットをポッド内のボリュームとしてマウントできます。 Amazon S3 この方法では、どのポッドが特定の S3 バケットにアクセスできるかをきめ細かく制御できます。各ポッドには独自のマウントポイントインスタンスとローカルキャッシュ (5～10 GB) があり、ポッド間でモデルのロードと読み取りのパフォーマンスを分離します。この設定では、サービスアカウントの IAM ロール (IRSA) によるポッドレベルの認証と、さまざまなモデルまたは顧客の独立したモデルバージョニングがサポートされています。各ポッドは S3 API コールを発行し、独自のキャッシュを維持するため、トレードオフはメモリ使用量と API トラフィックの増加です。

例 CSI ドライバーを使用したポッドデプロイ YAML の部分的な例：


# CSI driver dynamically mounts the S3 bucket for each pod

volumes:
  - name: s3-mount
    csi:
      driver: s3.csi.aws.com
      volumeAttributes:
        bucketName: your-s3-bucket-name
        mountOptions: "--allow-delete"  # Optional
        region: us-west-2

containers:
  - name: inference
    image: your-inference-image
    volumeMounts:
      - mountPath: /models
        name: s3-mount
volumeMounts:
  - name: model-cache
    mountPath: /models
volumes:
  - name: model-cache
    hostPath:
      path: /mnt/s3-model-cache

パフォーマンスに関する考慮事項：

データキャッシュ: Mountpoint for S3 はコンテンツをキャッシュしてコストを削減し、同じファイルへの繰り返し読み取りのパフォーマンスを向上させることができます。キャッシュオプションとパラメータについては、「キャッシュ設定」を参照してください。
オブジェクトのパートサイズ: 72GB を超えるファイルを保存してアクセスする場合は、「Mountpoint パフォーマンスの設定」を参照して、データプロファイルとワークロード要件を満たすように --read-part-sizeおよび --write-part-size コマンドラインパラメータを設定する方法を理解します。
共有キャッシュは、最大 1MB のサイズのオブジェクト用に設計されています。大きなオブジェクトはサポートされていません。EKS ノードの NVMe または EBS ボリュームにオブジェクトをキャッシュするには、ローカルキャッシュオプションを使用します。
API リクエスト料金: Mountpoint for S3 で多数のファイルオペレーションを実行すると、API リクエスト料金がストレージコストの一部になる可能性があります。これを軽減するには、強力な整合性が必要ない場合は、常にメタデータキャッシュを有効にし、API オペレーションの数を S3 に減らすmetadata-ttl期間を設定します。

詳細については、Amazon EKS 公式ドキュメントの「Mountpoint for Amazon S3 CSI Driver」を参照してください。ボトルネックが発生した場合は、Amazon CloudWatch メトリクスを使用して Amazon S3 のパフォーマンスメトリクス Amazon CloudWatchをモニタリングし、必要に応じて設定を調整することをお勧めします。

共有モデルキャッシュの Amazon EFS

複数の EC2 GPU コンピューティングインスタンス環境があり、複数のノードとアベイラビリティーゾーン間で共有モデルアクセスを必要とする動的なワークロード (Karpenter によるリアルタイムオンライン推論など) があり、パフォーマンスとスケーラビリティのニーズが中程度である場合は、EFS CSI ドライバーを介して Amazon Elastic File System (EFS) ファイルシステムを永続的ボリュームとして使用することをお勧めします。Amazon EFS は、フルマネージドで可用性が高く、スケーラブルなクラウドベースの NFS ファイルシステムです。共有ファイルストレージを持つ EC2 インスタンスとコンテナを一貫したパフォーマンスで実現し、ストレージの事前プロビジョニングは必要ありません。EFS をモデルボリュームとして使用し、EKS クラスターで永続ボリュームを定義して、ボリュームを共有ファイルシステムとしてマウントします。EFS ファイルシステムによってバックアップされる各永続ボリュームクレーム (PVC) は、EFS EFS ファイルシステムへの EFS アクセスポイントとして作成されます。EFS を使用すると、複数のノードとポッドが同じモデルファイルにアクセスできるため、各ノードのファイルシステムにデータを同期する必要がなくなります。EFS CSI ドライバーをインストールしてEFS を EKS と統合します。

Amazon EFS ファイルシステムは、次のスループットモードでデプロイできます。

バーストスループット: ファイルシステムサイズでスループットをスケーリングし、バーストが時折発生するさまざまなワークロードに適しています。
プロビジョンドスループット: 専有スループット。予測可能なパフォーマンスニーズが制限内の一貫した ML トレーニングジョブに最適です。
Elastic Throughput (ML に推奨）: ワークロード、さまざまな ML ワークロードの費用対効果に基づいて自動的にスケーリングします。

パフォーマンス仕様を確認するには、「Amazon EFS パフォーマンス仕様」を参照してください。

パフォーマンスに関する考慮事項：

さまざまなワークロードに Elastic スループットを使用します。
アクティブな ML ワークロードには標準ストレージクラスを使用します。

Amazon EFS ファイルシステムを EKS クラスターとポッド内の永続ボリュームとして使用する完全な例については、GitHub の EFS CSI ドライバーの例を参照してください。

パフォーマンスのモニタリング ディスクのパフォーマンスが低いと、コンテナイメージの読み取りが遅延し、ポッドの起動レイテンシーが増加し、推論やトレーニングのスループットが低下する可能性があります。ボトルネックが発生した場合は、それぞれの AWS Storage サービスのパフォーマンスメトリクスをモニタリングし、必要に応じて設定を調整するために、次の方法をお勧めします。

Amazon FSx コンソールとそのパフォーマンスメトリクス。FSx ファイルシステムに関連するパフォーマンスメトリクスを表示します。
Amazon EFS の Amazon CloudWatch メトリクスにアクセスして、EFS ファイルシステムに関連するパフォーマンスメトリクスを表示します。
Amazon CloudWatch で Amazon S3 メトリクスをモニタリングして、S3 バケットに関連するパフォーマンスの詳細を表示します。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

セキュリティ

オブザーバビリティ