[Storage (ストレージ)] - Amazon EKS
データ管理とストレージ

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

[Storage (ストレージ)]

データ管理とストレージ

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

AI/ML ワークロードでは、多くの場合、大規模なモデルアーティファクト (トレーニング済みの重み、設定など) にアクセスする必要があり、ポッドではコンテナイメージに埋め込まずにこれらにアクセスするための信頼性が高くスケーラブルな方法が必要であるため、イメージサイズとコンテナレジストリのプル時間が長くなる可能性があります。ボリュームマウントを管理する運用上のオーバーヘッドを減らすには、それぞれの CSI ドライバーを使用して Amazon ストレージサービス (S3、FSx for Lustre、FSx for OpenZFS、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 ファイルを以下に示します。

パフォーマンスのモニタリング ディスクのパフォーマンスが低いと、コンテナイメージの読み取りが遅くなり、ポッドの起動レイテンシーが増加し、推論やトレーニングのスループットが低下する可能性があります。Amazon CloudWatch を使用して、AWS ストレージサービスのパフォーマンスメトリクスをモニタリングします。パフォーマンスのボトルネックを特定するときは、ストレージ設定パラメータを変更してパフォーマンスを最適化します。

シナリオ: 複数の 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 ストレージオプションを使用してデプロイできます。

  • スクラッチ 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 ドライバーの例を参照してください。Amazon CloudWatch を使用して Amazon 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 FSx for OpenZFS 永続共有ストレージ

レイテンシーの影響を受けやすいワークロードを持つ複数の EC2 GPU コンピューティングインスタンスで、さまざまなアプリケーションに高可用性、高性能、コスト感度、複数のポッドデプロイを必要とするシナリオでは、Amazon FSx for OpenZFS をお勧めします。ワークロードの例には、リアルタイム推論、強化学習、生成攻撃者ネットワークのトレーニングなどがあります。FSx for OpenZFS は、小さな IO データアクセスパターンを使用する小さなファイルを持つ集中型ディレクトリ構造への高性能アクセスを必要とするワークロードに特に有益です。また、FSx for OpenZFS は、ストレージ容量とは別にパフォーマンスを柔軟にスケールできるため、必要なパフォーマンスレベルを維持しながら、ストレージサイズを実際のニーズに合わせることで、最適なコスト効率を実現できます。

ネイティブ FSx for OpenZFS CSI ドライバーを使用すると、複数のボリュームを作成して、単一のファイルシステムに複数の PVCs を作成できます。これにより、単一のファイルシステムに統合されたアプリケーションポッドをデプロイすることで、管理オーバーヘッドが削減され、ファイルシステムのスループットと IOPS の使用率が最大化されます。さらに、ゼロコピースナップショット、ゼロコピークローン、CSI ドライバーを介して動的にプロビジョニングできるユーザーおよびグループのクォータなどのエンタープライズ機能も含まれています。

FSx for OpenZFS は、作成時に 3 つの異なるデプロイタイプをサポートします。

  • シングル AZ: ミリ秒未満のレイテンシーを持つ最低コストのオプションですが、ファイルシステムまたはアベイラビリティーゾーンレベルでは高可用性を提供しません。開発およびテストワークロード、またはアプリケーションレイヤーで高可用性を持つワークロードに推奨されます。

  • シングル AZ (HA): ミリ秒未満のレイテンシーでファイルシステムレベルで高可用性を提供します。高可用性を必要とする最高のパフォーマンスのワークロードに推奨されます。

  • マルチ AZ: ファイルシステムレベルおよびアベイラビリティーゾーン間で高可用性を提供します。アベイラビリティーゾーン間で追加の可用性を必要とする高性能ワークロードに推奨されます。

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

  • デプロイタイプ： アベイラビリティーゾーン間の追加の可用性が要件でない場合は、シングル AZ (HA) デプロイタイプの使用を検討してください。このデプロイタイプは、書き込みのスループットの最大 100% を提供し、ミリ秒未満のレイテンシーを維持します。Gen2 ファイルシステムには、頻繁にアクセスされるデータを最大 テラバイト保存するための追加の NVMe キャッシュがあります。マルチ AZ ファイルシステムは、書き込みのスループットの最大 75% を提供し、クロス AZ トラフィックに対応するためのレイテンシーが増加します。

  • スループットと IOPS: ファイルシステム用に設定されたスループットと IOPS の両方をデプロイ後にスケールアップまたはスケールダウンできます。最大 10GB/秒のディスクスループットをプロビジョニングし、最大 21GB/秒のキャッシュされたデータアクセスを提供できます。IOPS はディスクから最大 400,000 までスケールでき、キャッシュは 100 万 IOPS 以上を提供できます。シングル AZ ファイルシステムのスループットスケーリングでは、高可用性が存在しないため、ファイルシステムが短時間停止することに注意してください。シングル AZ (HA) またはマルチ AZ ファイルシステムのスループットスケーリングは、中断することなく実行できます。SSD IOPS は 6 時間に 1 回スケールできます。

  • ストレージクラス： FSx for OpenZFS は、SSD ストレージクラスと Intelligent-Tiering ストレージクラスの両方をサポートしています。AI/ML ワークロードでは、SSD ストレージクラスを使用して、CPU / GPU の をできるだけビジー状態に保つワークロードに一貫したパフォーマンスを提供することをお勧めします。

  • 圧縮： 圧縮できるワークロードがある場合は、LZ4 圧縮アルゴリズムを有効にします。これにより、各ファイルがキャッシュで消費するデータの量が減少し、より多くのデータをネットワークスループットとしてキャッシュから直接提供でき、IOPS により SSD ディスクの負荷が軽減されます。

  • レコードサイズ： ほとんどの AI/ML ワークロードは、デフォルトの 128KiB のレコードサイズのままにしておくとメリットがあります。この値は、データセットがアプリケーションから 128KiB 未満の一貫した小さなブロックアクセスを持つ大きなファイル (10GiB 128KiB 以上) で構成されている場合にのみ削減する必要があります。

ファイルシステムが作成されると、関連付けられたルートボリュームがサービスによって自動的に作成されます。ファイルシステムのルートボリュームの子ボリューム内にデータを保存するのがベストプラクティスです。FSx for OpenZFS CSI ドライバーを使用して、関連付けられた永続ボリュームクレームを作成し、子ボリュームを動的に作成します。

例:

FSx for OpenZFS ボリュームのストレージクラス (SC) 定義。既存のファイルシステムにルートボリュームの子ボリューム ($ROOT_VOL_ID) を作成し、NFS v4.2 プロトコルを使用してボリュームを VPC CIDR ($VPC_CIDR) にエクスポートするために使用されます。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fsxz-vol-sc
provisioner: fsx.openzfs.csi.aws.com
parameters:
  ResourceType: "volume"
  ParentVolumeId: '"$ROOT_VOL_ID"'
  CopyTagsToSnapshots: 'false'
  DataCompressionType: '"LZ4"'
  NfsExports: '[{"ClientConfigurations": [{"Clients": "$VPC_CIDR", "Options": ["rw","crossmnt","no_root_squash"]}]}]'
  ReadOnly: 'false'
  RecordSizeKiB: '128'
  Tags: '[{"Key": "Name", "Value": "AI-ML"}]'
  OptionsOnDeletion: '["DELETE_CHILD_VOLUMES_AND_SNAPSHOTS"]'
reclaimPolicy: Delete
allowVolumeExpansion: false
mountOptions:
  - nfsvers=4.2
  - rsize=1048576
  - wsize=1048576
  - timeo=600
  - nconnect=16
  - async

上記の fsxz-vol-sc に対して動的に作成された永続ボリューム要求 (PVC)。割り当てられたストレージ容量は 1Gi です。これは、CSI ドライバーのよくある質問に記載されているように、FSx for OpenZFS ボリュームに必要です。ボリュームには、この設定でファイルシステムにプロビジョニングされたフルキャパシティが提供されます。ボリューム容量を制限する必要がある場合は、ユーザーまたはグループのクォータを使用して制限できます。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-vol-pvc
  namespace: example
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: fsxz-vol-sc
  resources:
    requests:
      storage: 1Gi

dynamic-vol-pvc の永続ボリュームクレーム (PVC) を使用してボリュームをマウントするようにポッドを設定します。

kind: Pod
apiVersion: v1
metadata:
  name: fsx-app
  namespace: example
spec:
  volumes:
    - name: dynamic-vol-pv
      persistentVolumeClaim:
        claimName: dynamic-vol-pvc
  containers:
    - name: app
      image: amazonlinux:2023
      command: ["/bin/sh"]
      volumeMounts:
        - mountPath: "/mnt/fsxz"
          name: dynamic-vol-pv

共有モデルキャッシュの 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 ドライバーの例を参照してください。Amazon CloudWatch を使用して Amazon EFS パフォーマンスメトリクスをモニタリングします。パフォーマンスのボトルネックが特定されたら、必要に応じて設定パラメータを調整します。

レイテンシーの影響を受けやすいオブジェクト指向ワークフローに S3 Express One Zone を使用する

大規模なモデルトレーニング、推論、高性能分析など、Amazon EKS のレイテンシーの影響を受けやすい AI/ML ワークロードの場合は、SS3 Express One Zone を使用して高性能モデルのストレージと取り出しを行うことをお勧めします。S3 Express One Zone は、ファイルシステムなどの階層名前空間を提供します。この名前空間では、ディレクトリバケットにアップロードするだけで、高速を維持しながらすべてを「チャッキングする」のに適しています。これは、オブジェクト指向ワークフローに慣れている場合に特に便利です。または、ファイルシステム (POSIX 準拠など) に慣れている場合は、Amazon FSx for Lustre または OpenZFS を使用することをお勧めします。Amazon S3 Express One Zone は、ディレクトリバケットを使用して単一のアベイラビリティーゾーン (AZ) にデータを保存し、複数の AZ にデータを分散する標準 S3 バケットよりも低いレイテンシーを提供します AZs 。最良の結果を得るには、EKS コンピューティングを Express One Zone バケットと同じ AZ にコロケーションしてください。S3 Express One Zone の違いの詳細については、「ディレクトリバケットの違い」を参照してください。

ファイルシステムのセマンティクスを使用して S3 Express One Zone にアクセスするには、ローカルファイルシステムとして S3 バケット (Express One Zone を含む) をマウントする Mountpoint S3 CSI ドライバーを使用することをお勧めします。 S3 これにより、ファイルオペレーション (オープン、読み取り、書き込みなど) が S3 API コールに変換され、複数のクライアントからの読み取り負荷の高いワークロードや新しいオブジェクトへのシーケンシャル書き込みに最適化された高スループットアクセスが提供されます。サポートされているオペレーションと制限 (完全な POSIX コンプライアンスがないが、Express One Zone でサポートされている名前を追加および変更するなど) の詳細については、Mountpoint セマンティクスドキュメントを参照してください。

パフォーマンス上の利点

  • S3 Standard よりも最大 10 倍高速なデータアクセスを提供し、1 桁ミリ秒の一貫したレイテンシーと最大 80% の低いリクエストコストを実現します。

  • ディレクトリバケットごとに 1 秒あたり数十万から数百万のリクエストを処理するようにスケールし、極度の負荷 (ネットワークを飽和させる数十から数十万の GPUs/CPUs を持つクラスターなど) 中に標準 S3 で見られるスロットリングやブラウンアウトを回避します。

  • セッションベースの認証メカニズムを使用します。一度認証してセッショントークンを取得し、リクエストごとの認証オーバーヘッドなしで高速で繰り返しオペレーションを実行します。これは、頻繁なチェックポイントやデータロードなどのワークロードに最適化されています。

推奨されるユースケース

  • キャッシュ: S3 Express One Zone で Mountpoint S3 CSI ドライバーを使用する主なユースケースの 1 つはキャッシュです。最初のインスタンスは S3 Standard (汎用) からデータを読み取り、低レイテンシーの Express One Zone にキャッシュします。他のクライアントによるそれ以降の読み取りはキャッシュされたデータにすばやくアクセスするため、複数の EKS ノードが同じデータ (共有トレーニングデータセットなど) を読み取るマルチノードシナリオに最適です。これにより、繰り返しアクセスする場合にパフォーマンスが最大 7 倍向上し、コンピューティングコストを削減できます。完全な POSIX コンプライアンス (ファイルロックやインプレース変更など) を必要とするワークロードでは、代わりに Amazon FSx for Lustre または OpenZFS を検討してください。

  • 大規模な AI/ML トレーニングと推論: 汎用 S3 スロットリングによって遅延が発生し、GPUs など) を持つワークロードに最適です。例えば、LLM の研究者や日常的なモデルテスト/チェックポイントを実行する組織は、リージョン S3 を中断することなく、高速で信頼性の高いアクセスからメリットを得られます。小規模なワークロード (ノード数 10 個など) では、S3 Standard または他のストレージクラスで十分です。

  • データパイプライン: モデルのロード/準備、トレーニングデータのアーカイブ、チェックポイントのストリーミングを行います。チームが従来のファイルシステムよりもオブジェクトストレージを優先する場合は (S3 に慣れているためなど）、FSx for Lustre などの POSIX 準拠のオプションを設計変更する代わりに、これを使用します。

考慮事項

  • 耐障害性: シングル AZ 設計は、マルチ AZ クラス (99.99% の可用性) と比較して、99.999999999% の耐久性 (AZ 内の冗長性による標準 S3 と同じ) を提供しますが、可用性 (99.95% 設計、99.9% SLA) は低くなります。AZ 障害に対する耐障害性が低くなります。再利用可能なデータまたはキャッシュされたデータには、 を使用します。重要なワークロードには、マルチ AZ レプリケーションまたはバックアップを検討してください。

  • API と機能のサポート: S3 APIs のサブセット (ライフサイクルポリシーやレプリケーションなしなど) をサポートします。セッション認証やオブジェクト処理には、アプリケーションのマイナーな変更が必要になる場合があります。

  • EKS 統合: ネットワークレイテンシーを最小限に抑えるために、EKS ポッド/ノードをディレクトリバケットと同じ AZ に配置します。Mountpoint for Amazon S3 または CSI ドライバーを Kubernetes ネイティブアクセスに使用します。

  • テスト： 非本番環境で取得レイテンシーをテストして、パフォーマンスの向上を検証します。標準 S3 シナリオ (GPU 飽和度が高いなど) のスロットリングをモニタリングし、比較します。

S3 Express One Zone ストレージクラスは複数のリージョンで利用でき、ストレージを待たずにオブジェクトへのアクセスを必要とするワークロードの EKS と統合されます。詳細については、S3 Express One Zone の開始方法」を参照してください。