Stockage

Gestion et stockage des données

Déployez des modèles d'IA sur des pods à l'aide d'un pilote CSI

Les charges de travail IA/ML nécessitent souvent l'accès à de grands artefacts de modèles (par exemple, poids entraînés, configurations), et les pods ont besoin d'un moyen fiable et évolutif pour y accéder sans les intégrer dans des images de conteneur, ce qui peut augmenter la taille des images et les temps d'extraction du registre des conteneurs. Pour réduire les frais opérationnels liés à la gestion des montages de volumes, nous recommandons de déployer des modèles d'IA sur des pods en installant les services de stockage Amazon (par exemple, S3, FSx pour Lustre, FSx pour OpenZFS, EFS) en tant que volumes persistants (PVs) à l'aide de leurs pilotes CSI respectifs. Pour plus de détails sur la mise en œuvre, consultez les rubriques suivantes de cette section.

Optimisation du stockage pour les caches de modèles ML sur EKS

Il est essentiel de tirer parti d'une solution de stockage optimale pour minimiser la latence de démarrage des pods et des applications, réduire l'utilisation de la mémoire, obtenir les niveaux de performance souhaités pour accélérer les charges de travail et garantir l'évolutivité des charges de travail de machine learning. Les charges de travail ML reposent souvent sur des fichiers modèles (poids), qui peuvent être volumineux et nécessiter un accès partagé aux données entre les pods ou les nœuds. Le choix de la solution de stockage optimale dépend des caractéristiques de votre charge de travail, telles que l'efficacité d'un nœud unique, l'accès à plusieurs nœuds, les exigences de latence, les contraintes de coûts ainsi que les exigences en matière d'intégration des données (comme dans le cas d'un référentiel de données Amazon S3). Nous vous recommandons d'évaluer les différentes solutions de stockage en fonction de vos charges de travail afin de déterminer laquelle répond à vos exigences. Nous vous proposons les options suivantes pour vous aider à évaluer en fonction de vos exigences en matière de charge de travail.

Le pilote EKS CSI prend en charge les services de stockage AWS suivants. Chacun possède son propre pilote CSI et possède ses propres atouts pour les flux de travail d'IA et de ML :

• Mountpoint pour Amazon S3

• Amazon FSx pour Lustre

• Amazon FSx pour OpenZFS

• Amazon EFS

• Amazon EBS

Le choix du service de stockage AWS dépend de votre architecture de déploiement, de votre échelle, de vos exigences en matière de performances et de votre stratégie en matière de coûts. Les pilotes CSI de stockage doivent être installés sur votre cluster EKS, ce qui permet au pilote CSI de créer et de gérer des volumes persistants (PV) en dehors du cycle de vie d'un pod. À l'aide du pilote CSI, vous pouvez créer des définitions PV des services de stockage AWS pris en charge en tant que ressources de cluster EKS. Les pods peuvent ensuite accéder à ces volumes de stockage pour leurs volumes de données en créant une réclamation de volume persistante (PVC) pour le PV. En fonction du service de stockage AWS et de votre scénario de déploiement, un seul PVC (et le PV associé) peut être attaché à plusieurs pods pour une charge de travail. Par exemple, pour la formation ML, les données d'entraînement partagées sont stockées sur un PV et accessibles par plusieurs pods ; pour une inférence en ligne en temps réel, les modèles LLM sont mis en cache sur un PV et accessibles par plusieurs pods. Des exemples de fichiers YAML PV et PVC pour les services de stockage AWS sont fournis ci-dessous pour vous aider à démarrer.

Surveillance des performances Les performances médiocres du disque peuvent retarder la lecture des images des conteneurs, augmenter le temps de latence au démarrage du pod et dégrader le débit d'inférence ou d'entraînement. Utilisez Amazon CloudWatch pour surveiller les indicateurs de performance de vos services de stockage AWS. Lorsque vous identifiez des problèmes de performance, modifiez les paramètres de configuration de votre stockage afin d'optimiser les performances.

Scénario : charge de travail de plusieurs instances GPU

Amazon FSx for Lustre : dans les scénarios où vous disposez d'un environnement d'instances de calcul à plusieurs EC2 GPU avec des charges de travail dynamiques sensibles à la latence et à haut débit de bande passante, tels que la formation distribuée et le service de modèles, et que vous avez besoin d'une intégration native au référentiel de données Amazon S3, nous recommandons Amazon for Lustre. FSx FSx for Lustre fournit un système de fichiers parallèle hautes performances entièrement géré, conçu pour les charges de travail intensives telles que le calcul haute performance (HPC) et le Machine Learning.

Vous pouvez installer le pilote CSI FSx for Lustre pour monter des FSx systèmes de fichiers sur EKS en tant que volume persistant (PV), puis le déployer FSx pour le système de fichiers Lustre en tant que cache haute performance autonome ou en tant que système de fichiers lié au S3 pour agir comme cache haute performance pour les données S3, fournissant ainsi un débit rapide I/O et élevé pour l'accès aux données entre vos instances de calcul GPU. FSx for Lustre peut être déployé avec les options de stockage Scratch-SSD ou Persistent-SSD :

• Stockage sur SSD Scratch : recommandé pour les charges de travail éphémères ou de courte durée (heures), avec une capacité de débit fixe par To allouée.

• Stockage SSD permanent : recommandé pour les charges de travail critiques de longue durée nécessitant le plus haut niveau de disponibilité, par exemple les simulations HPC, l'analyse de mégadonnées ou la formation au Machine Learning. Avec le stockage SSD persistant, vous pouvez configurer à la fois la capacité de stockage et la capacité de débit (par To) requises.

Considérations relatives aux performances :

• Module d'administration FSx pour gérer le système de fichiers Lustre : configurez un module « administratif » sur lequel le client Lustre est installé et le système de FSx fichiers est monté. Cela permettra d'activer un point d'accès pour affiner le système de FSx fichiers, et également dans les situations où vous devez préchauffer le système de FSx fichiers avec vos données d'entraînement ML ou vos modèles LLM avant de démarrer vos instances de calcul GPU. Cela est particulièrement important si votre architecture utilise des instances GPU/Compute EC2 Amazon basées sur Spot, dans lesquelles vous pouvez utiliser le module d'administration pour « réchauffer » ou « précharger » les données souhaitées dans FSx le système de fichiers, afin que les données soient prêtes à être traitées lorsque vous exécutez vos instances Amazon basées sur Spot. EC2

• Elastic Fabric Adapter (EFA) : les types de déploiement de stockage SSD persistants prennent en charge Elastic Fabric Adapter (EFA), où l'utilisation d'EFA est idéale pour les charges de travail basées sur des GPU à hautes performances et basées sur le débit. Notez que FSx for Lustre prend en charge le GPUDirect stockage NVIDIA (GDS), technologie qui crée un chemin de données direct entre le stockage local ou distant et la mémoire du GPU, afin de permettre un accès plus rapide aux données.

• Compression : activez la compression des données sur le système de fichiers si certains types de fichiers peuvent être compressés. Cela peut contribuer à améliorer les performances, car la compression des données réduit la quantité de données transférées entre les serveurs FSx de fichiers Lustre et le stockage.

• Configuration du découpage du système de fichiers Lustre :

  • Bandage des données : permet à Luster de distribuer FSx les données d'un fichier sur plusieurs cibles de stockage d'objets (OSTs) au sein d'un système de fichiers Lustre, ce qui maximise l'accès parallèle et le débit, en particulier pour les tâches de formation ML à grande échelle.

  • Rayage autonome du système de fichiers : Par défaut, une configuration de découpage Lustre à 4 composants est créée pour vous via la fonctionnalité PFL (Progressive File Layouts) de for Lustre. FSx Dans la plupart des scénarios, il n'est pas nécessaire de mettre à jour le comptage et la taille des bandes PFL Lustre par défaut. Si vous devez ajuster le découpage des données Lustre, vous pouvez le régler manuellement en vous référant aux paramètres de découpage d'un système de fichiers FSx pour Lustre.

  • Système de fichiers lié au S3 : les fichiers importés dans le système de FSx fichiers à l'aide de l'intégration native Amazon S3 (Data Repository Association ou DRA) n'utilisent pas la mise en page PFL par défaut, mais utilisent plutôt la mise en page dans les paramètres du système de fichiers. ImportedFileChunkSize Les fichiers importés au format S3 dont la taille est supérieure à la taille ImportedFileChunkSize seront stockés sur plusieurs OSTs avec un nombre de bandes basé sur la valeur ImportedFileChunkSize définie (1 Go par défaut). Si vous avez des fichiers volumineux, nous vous recommandons de régler ce paramètre sur une valeur supérieure.

  • Emplacement : déployez un système de fichiers FSx pour Lustre dans la même zone de disponibilité que vos nœuds de calcul ou de GPU afin de permettre un accès aux données avec le plus faible temps de latence et d'éviter les modèles d'accès entre zones de disponibilité. Si vous avez plusieurs nœuds GPU situés dans différentes zones de disponibilité, nous vous recommandons de déployer un système de FSx fichiers dans chaque zone de disponibilité pour un accès aux données à faible latence.

Exemple

Définition du volume persistant (PV) pour un système de fichiers FSx pour Lustre, à l'aide du provisionnement statique (lorsque l' FSx instance a déjà été provisionnée).

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]

Exemple

Définition de la demande de volume persistant pour le PV appelée fsx-pv :

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

Exemple

Configurez un pod pour utiliser une réclamation de volume persistante de 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

Pour des exemples complets, consultez les exemples FSx de pilotes Lustre dans GitHub. Surveillez les indicateurs de performance FSx d'Amazon for Lustre à l'aide d'Amazon CloudWatch. Lorsque des problèmes de performance sont identifiés, ajustez vos paramètres de configuration selon vos besoins.

Scénario : charge de travail d'une instance de GPU unique

Mountpoint pour Amazon S3 avec pilote CSI : vous pouvez monter un compartiment S3 sous forme de volume dans vos pods à l'aide du pilote CSI Mountpoint pour Amazon S3. Cette méthode permet un contrôle d'accès précis sur les pods autorisés à accéder à des compartiments S3 spécifiques. Chaque pod possède sa propre instance de point de montage et son propre cache local (5 à 10 Go), ce qui permet d'isoler les performances de chargement et de lecture des modèles entre les pods. Cette configuration prend en charge l'authentification au niveau du pod avec les rôles IAM pour les comptes de service (IRSA) et le versionnement indépendant des modèles pour différents modèles ou clients. Le compromis est une augmentation de l'utilisation de la mémoire et du trafic d'API, car chaque pod émet des appels d'API S3 et gère son propre cache.

Exemple partiel de déploiement d'un Pod YAML avec pilote CSI :

# 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

Considérations relatives aux performances :

• Mise en cache des données : Mountpoint for S3 peut mettre en cache le contenu afin de réduire les coûts et d'améliorer les performances lors de lectures répétées d'un même fichier. Reportez-vous à la section Configuration de la mise en cache pour connaître les options et les paramètres de mise en cache.

• Taille partielle de l'objet : lorsque vous stockez et accédez à des fichiers d'une taille supérieure à 72 Go, reportez-vous à la section Configuration des performances de Mountpoint pour comprendre comment configurer les paramètres et les paramètres de --write-part-size ligne de commande en fonction de votre profil de données --read-part-size et de vos exigences en matière de charge de travail.

• Le cache partagé est conçu pour les objets d'une taille maximale de 1 Mo. Il ne supporte pas les objets de grande taille. Utilisez l'option de cache local pour mettre en cache des objets NVMe ou des volumes EBS sur le nœud EKS.

• Frais de demande d'API : lorsque vous effectuez un grand nombre d'opérations sur les fichiers avec Mountpoint pour S3, les frais de demande d'API peuvent devenir une partie des coûts de stockage. Pour atténuer ce problème, si une forte cohérence n'est pas requise, activez toujours la mise en cache des métadonnées et définissez la metadata-ttl période pour réduire le nombre d'opérations d'API à S3.

Pour plus de détails, consultez le pilote CSI Mountpoint pour Amazon S3 dans la documentation officielle Amazon EKS. Nous vous recommandons de surveiller les indicateurs de performance d'Amazon S3 à l'aide des CloudWatch indicateurs Amazon en cas de goulots d'étranglement et d'ajuster votre configuration si nécessaire.

Stockage partagé persistant Amazon FSx pour OpenZFS

Pour les scénarios impliquant plusieurs instances de calcul EC2 GPU avec des charges de travail sensibles à la latence nécessitant une haute disponibilité, des performances élevées, une sensibilité aux coûts et le déploiement de plusieurs modules pour différentes applications, nous recommandons Amazon pour OpenZFS. FSx Certains exemples de charge de travail incluent l'inférence en temps réel, l'apprentissage par renforcement et la formation de réseaux antagonistes génératifs. FSx pour OpenZFS est particulièrement utile pour les charges de travail nécessitant un accès performant à une structure de répertoires ciblée contenant de petits fichiers utilisant de petits modèles d'accès aux données d'E/S. En outre, OpenZFS offre la flexibilité nécessaire FSx pour adapter les performances indépendamment de la capacité de stockage, ce qui vous aide à atteindre une rentabilité optimale en adaptant la taille du stockage aux besoins réels tout en maintenant les niveaux de performance requis.

Le pilote CSI natif FSx d'OpenZFS permet de créer plusieurs PVCs ou un seul système de fichiers en créant plusieurs volumes. Cela permet de réduire les frais de gestion et d'optimiser l'utilisation du débit et des IOPS du système de fichiers grâce à des déploiements de modules d'applications consolidés sur un seul système de fichiers. En outre, il inclut des fonctionnalités d'entreprise telles que les instantanés sans copie, les clones sans copie et les quotas d'utilisateurs et de groupes qui peuvent être provisionnés de manière dynamique via le pilote CSI.

FSx car OpenZFS prend en charge trois types de déploiement différents lors de sa création :

• Mono-AZ : option la plus économique avec des latences inférieures à la milliseconde, mais qui ne fournit aucune haute disponibilité au niveau du système de fichiers ou de la zone de disponibilité. Recommandé pour les charges de travail de développement et de test ou celles présentant une haute disponibilité au niveau de la couche application.

• Mono-AZ (HA) : fournit une haute disponibilité au niveau du système de fichiers avec des latences inférieures à la milliseconde. Recommandé pour les charges de travail les plus performantes qui nécessitent une haute disponibilité.

• Multi-AZ : assure une haute disponibilité au niveau du système de fichiers ainsi que dans toutes les zones de disponibilité. Recommandé pour les charges de travail à hautes performances qui nécessitent une disponibilité accrue dans toutes les zones de disponibilité.

Considérations relatives aux performances :

• Type de déploiement : si la disponibilité supplémentaire entre les zones de disponibilité n'est pas une exigence, envisagez d'utiliser le type de déploiement mono-AZ (HA). Ce type de déploiement fournit jusqu'à 100 % du débit pour les écritures, maintient des latences inférieures à la milliseconde et les systèmes de fichiers Gen2 disposent d'un NVMe cache supplémentaire pour stocker jusqu'à plusieurs téraoctets de données fréquemment consultées. Les systèmes de fichiers multi-AZ fournissent jusqu'à 75 % du débit pour les écritures avec une latence accrue afin de tenir compte du trafic inter-AZ.

• Débit et IOPS : le débit et les IOPS configurés pour le système de fichiers peuvent être augmentés ou diminués après le déploiement. Vous pouvez fournir jusqu'à 10 % GB/s of disk throughput providing up to 21GB/s de l'accès aux données mises en cache. Les IOPS peuvent être augmentées jusqu'à 400 000 à partir du disque et le cache peut fournir plus d'un million d'IOPS. Notez que le dimensionnement du débit d'un système de fichiers mono-AZ entraîne une brève interruption du système de fichiers car il n'existe aucune haute disponibilité. La mise à l'échelle du débit d'un système de fichiers mono-AZ (HA) ou multi-AZ peut être effectuée sans interruption de service. Les IOPS du SSD peuvent être ajustés une fois toutes les six heures.

• Classe de stockage : FSx pour OpenZFS, prend en charge à la fois la classe de stockage SSD et la classe de stockage Intelligent-Tiering. Pour les AI/ML charges de travail, il est recommandé d'utiliser la classe de stockage SSD qui fournit des performances cohérentes à la charge de travail en maintenant les processeurs/GPU aussi occupés que possible.

• Compression : activez l'algorithme de LZ4 compression si votre charge de travail peut être compressée. Cela réduit la quantité de données que chaque fichier consomme dans le cache, ce qui permet de diffuser davantage de données directement à partir du cache sous forme de débit réseau et d'IOPS réduisant la charge sur le disque SSD.

• Taille d'enregistrement : la plupart des AI/ML charges de travail gagneront à conserver la taille d'enregistrement par défaut de 128 Ko. Cette valeur ne doit être réduite que si l'ensemble de données est constitué de fichiers volumineux (supérieurs à 10 Go) avec un accès constant à de petits blocs inférieur à 128 Ko depuis l'application.

Une fois le système de fichiers créé, un volume racine associé est automatiquement créé par le service. Il est recommandé de stocker les données dans les volumes enfants du volume racine du système de fichiers. À l'aide du pilote CSI FSx pour OpenZFS, vous créez une réclamation de volume persistant associée pour créer dynamiquement le volume enfant.

Exemples :

Définition de classe de stockage (SC) pour un volume FSx pour OpenZFS, utilisée pour créer un volume enfant du volume racine ($ROOT_VOL_ID) sur un système de fichiers existant et exporter le volume vers le VPC CIDR ($VPC_CIDR) à l'aide du protocole NFS v4.2.

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

Une réclamation de volume persistante (PVC) créée dynamiquement par rapport à ce qui fsxz-vol-sc a été créé ci-dessus. Notez que la capacité de stockage allouée est de 1 Go, ce qui est requis FSx pour les volumes OpenZFS, comme indiqué dans la FAQ sur le pilote CSI. Le volume bénéficiera de la pleine capacité allouée au système de fichiers avec cette configuration. Si la capacité du volume doit être limitée, vous pouvez le faire en utilisant des quotas d'utilisateurs ou de groupes.

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

Configurez un pod pour monter un volume en utilisant le Persistent Volume Claim (PVC) de dynamic-vol-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 pour les caches de modèles partagés

Dans les scénarios où vous disposez d'un environnement d'instances de calcul à plusieurs EC2 GPU et que vous avez des charges de travail dynamiques nécessitant un accès partagé aux modèles sur plusieurs nœuds et zones de disponibilité (par exemple, inférence en ligne en temps réel avec Karpenter) avec des besoins modérés en termes de performances et d'évolutivité, nous vous recommandons d'utiliser un système de fichiers Amazon Elastic File System (EFS) en tant que volume persistant via le pilote EFS CSI. Amazon EFS est un système de fichiers NFS basé sur le cloud entièrement géré, hautement disponible et évolutif qui permet aux EC2 instances et aux conteneurs de bénéficier d'un stockage de fichiers partagé, avec des performances constantes et pour lesquels aucun provisionnement initial du stockage n'est requis. Utilisez EFS comme volume modèle et montez le volume en tant que système de fichiers partagé en définissant un volume persistant sur le cluster EKS. Chaque demande de volume persistant (PVC) soutenue par un système de fichiers EFS est créée en tant que point d'accès EFS au système de fichiers EFS. EFS permet à plusieurs nœuds et pods d'accéder aux mêmes fichiers de modèle, éliminant ainsi le besoin de synchroniser les données avec le système de fichiers de chaque nœud. Installez le pilote EFS CSI pour intégrer EFS à EKS.

Vous pouvez déployer un système de fichiers Amazon EFS avec les modes de débit suivants :

• Débit en rafale : adapte le débit à la taille du système de fichiers, adapté à des charges de travail variées avec des rafales occasionnelles.

• Débit provisionné : débit dédié, idéal pour les tâches de formation au machine learning cohérentes avec des besoins de performance prévisibles dans des limites limites.

• Débit élastique (recommandé pour le ML) : s'adapte automatiquement en fonction de la charge de travail, rentabilité pour différentes charges de travail ML.

Pour consulter les spécifications de performances, consultez les spécifications de performance d'Amazon EFS.

Considérations relatives aux performances :

• Utilisez Elastic Throughput pour différentes charges de travail.

• Utilisez la classe de stockage standard pour les charges de travail ML actives.

Pour des exemples complets d'utilisation du système de fichiers Amazon EFS en tant que volume persistant au sein de votre cluster EKS et de vos pods, reportez-vous aux exemples de pilotes EFS CSI dans GitHub. Surveillez les indicateurs de performance d'Amazon EFS à l'aide d'Amazon CloudWatch. Lorsque des problèmes de performance sont identifiés, ajustez vos paramètres de configuration selon vos besoins.

Utilisez S3 Express One Zone pour les flux de travail orientés objet et sensibles à la latence

Pour les AI/ML charges de travail sensibles à la latence sur Amazon EKS, telles que la formation de modèles à grande échelle, l'inférence ou les analyses hautes performances, nous recommandons d'utiliser S3 Express One Zone pour le stockage et la récupération de modèles à hautes performances. S3 Express One Zone propose un espace de noms hiérarchique, comme un système de fichiers, dans lequel il suffit de le télécharger dans un compartiment de répertoire, ce qui permet de « tout stocker » tout en maintenant une vitesse élevée. Cela est particulièrement utile si vous êtes habitué aux flux de travail orientés objet. Sinon, si vous êtes plus habitué aux systèmes de fichiers (par exemple, compatibles POSIX), vous pouvez préférer Amazon FSx for Lustre ou OpenZFS. Amazon S3 Express One Zone stocke les données dans une seule zone de disponibilité (AZ) à l'aide de compartiments de répertoire et offre une latence inférieure à celle des compartiments S3 standard, qui distribuent les données entre plusieurs. AZs Pour de meilleurs résultats, assurez-vous de colocaliser votre ordinateur EKS dans la même zone AZ que votre bucket Express One Zone. Pour en savoir plus sur les différences entre S3 Express One Zone, consultez la section Différences entre les compartiments d'annuaire.

Pour accéder à S3 Express One Zone avec la sémantique du système de fichiers, nous vous recommandons d'utiliser le pilote CSI Mountpoint S3, qui monte les compartiments S3 (y compris Express One Zone) en tant que système de fichiers local. Cela traduit les opérations sur les fichiers (par exemple, ouverture, lecture, écriture) en appels d'API S3, fournissant un accès haut débit optimisé pour les charges de travail intensives en lecture provenant de plusieurs clients et les écritures séquentielles sur de nouveaux objets. Pour plus de détails sur les opérations prises en charge et les limitations (par exemple, aucune conformité totale avec POSIX, mais les ajouts et les renommages pris en charge dans Express One Zone), consultez la documentation sémantique de Mountpoint.

Avantages en termes de performances

• Fournit un accès aux données jusqu'à 10 fois plus rapide que le S3 Standard, avec une latence constante d'une milliseconde à un chiffre et des coûts de demande jusqu'à 80 % inférieurs.

• S'adapte pour traiter des centaines de milliers, voire des millions de requêtes par seconde et par compartiment de répertoire, évitant ainsi les ralentissements ou les baisses de tension observés dans la norme S3 lors de charges extrêmes (par exemple, en provenance de clusters comportant des dizaines, voire des centaines de milliers de GPUs/CPUs réseaux saturés).

• Utilise un mécanisme d'authentification basé sur les sessions. Authentifiez-vous une fois pour obtenir un jeton de session, puis effectuez des opérations répétées à grande vitesse sans surcharger l'authentification par demande. Ceci est optimisé pour les charges de travail telles que les points de contrôle fréquents ou le chargement de données.

Cas d'utilisation recommandés

• Mise en cache : L'un des principaux cas d'utilisation du pilote CSI Mountpoint S3 avec S3 Express One Zone est la mise en cache. La première instance lit les données depuis S3 Standard (usage général) et les met en cache dans Express One Zone à faible latence. Les lectures ultérieures effectuées par d'autres clients accèdent plus rapidement aux données mises en cache, ce qui est idéal pour les scénarios à nœuds multiples dans lesquels plusieurs nœuds EKS lisent les mêmes données (par exemple, des ensembles de données d'entraînement partagés). Cela peut améliorer les performances jusqu'à 7 fois pour les accès répétés et réduire les coûts de calcul. Pour les charges de travail nécessitant une conformité totale avec POSIX (par exemple, verrouillage de fichiers et modifications sur place), envisagez Amazon FSx for Lustre ou OpenZFS comme alternatives.

• AI/ML Formation et inférence à grande échelle : idéal pour les charges de travail comportant des centaines ou des milliers de nœuds de calcul (par exemple, GPUs dans les clusters EKS) où la régulation S3 à usage général peut entraîner des retards et gaspiller des ressources informatiques coûteuses. Par exemple, les chercheurs en LLM ou les organisations utilisant un modèle quotidien tests/checkpoints bénéficient d'un accès rapide et fiable sans perturber le S3 régional. Pour les charges de travail à petite échelle (par exemple, des dizaines de nœuds), S3 Standard ou d'autres classes de stockage peuvent suffire.

• Pipelines de données : Load/prepare modèles, données d'entraînement archivées ou points de contrôle des flux. Si votre équipe préfère le stockage d'objets aux systèmes de fichiers traditionnels (par exemple, en raison de sa familiarité avec S3), utilisez-le au lieu de procéder à des modifications techniques pour des options conformes à POSIX, comme FSx pour Lustre.

Considérations

• Résilience : la conception mono-AZ offre une durabilité de 99,999999999 % (identique à celle du S3 standard, grâce à la redondance au sein de l'AZ) mais une disponibilité inférieure (99,95 % conçu, 99,9 % SLA) par rapport aux classes multi-AZ (disponibilité de 99,99 %). Il est moins résistant aux défaillances de l'AZ. À utiliser pour les données recréables ou mises en cache. Envisagez la réplication multi-AZ ou les sauvegardes pour les charges de travail critiques.

• Support des API et des fonctionnalités : prend en charge un sous-ensemble de S3 APIs (par exemple, aucune politique de cycle de vie ni réplication) ; peut nécessiter des modifications mineures de l'application pour l'authentification de session ou la gestion des objets.

• Intégration EKS : colocalisez votre EKS pods/nodes dans la même zone que le compartiment d'annuaire afin de minimiser la latence du réseau. Utilisez Mountpoint pour Amazon S3 ou les pilotes CSI pour un accès natif à Kubernetes.

• Tests : testez la latence de récupération dans un environnement hors production pour valider les gains de performances. Surveillez les ralentissements dans les scénarios S3 standard (par exemple, saturation élevée du GPU) et comparez.

La classe de stockage S3 Express One Zone est disponible dans plusieurs régions et s'intègre à EKS pour les charges de travail nécessitant un accès aux objets sans attendre le stockage. Pour en savoir plus, consultez Commencer à utiliser S3 Express One Zone.