Penyimpanan - Amazon EKS
Manajemen dan Penyimpanan Data

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Penyimpanan

Manajemen dan Penyimpanan Data

Menerapkan Model AI ke Pod Menggunakan Driver CSI

Beban kerja AI/ML seringkali memerlukan akses ke artefak model besar (misalnya, bobot terlatih, konfigurasi), dan pod memerlukan cara yang andal dan dapat diskalakan untuk mengaksesnya tanpa menyematkannya dalam gambar kontainer, yang dapat meningkatkan ukuran gambar dan waktu tarik registri Container. Untuk mengurangi overhead operasional pengelolaan volume mount, kami merekomendasikan penerapan model AI ke pod dengan memasang layanan penyimpanan Amazon (misalnya, S3, untuk Lustre, FSx untuk FSx OpenZFS, EFS) sebagai Persistent Volume () menggunakan driver CSI masing-masing. PVs Untuk detail implementasi, lihat topik selanjutnya di bagian ini.

Optimalkan Penyimpanan untuk Cache Model ML di EKS

Memanfaatkan solusi penyimpanan yang optimal sangat penting untuk meminimalkan latensi start-up pod dan aplikasi, mengurangi penggunaan memori, mendapatkan tingkat kinerja yang diinginkan untuk mempercepat beban kerja, dan memastikan skalabilitas beban kerja ML. Beban kerja ML sering bergantung pada file model (bobot), yang bisa berukuran besar dan memerlukan akses bersama ke data di seluruh pod atau node. Memilih solusi penyimpanan yang optimal bergantung pada karakteristik beban kerja Anda, seperti efisiensi simpul tunggal, akses multi-node, persyaratan latensi, kendala biaya, dan juga persyaratan integrasi data (seperti dengan repositori data Amazon S3). Kami merekomendasikan untuk membandingkan solusi penyimpanan yang berbeda dengan beban kerja Anda untuk memahami mana yang memenuhi persyaratan Anda, dan kami telah menyediakan opsi berikut untuk membantu Anda mengevaluasi berdasarkan persyaratan beban kerja Anda.

Driver EKS CSI mendukung layanan AWS Storage berikut, masing-masing memiliki driver CSI sendiri dan dilengkapi dengan kekuatan mereka sendiri untuk alur kerja AI dan ML:

Pilihan layanan AWS Storage bergantung pada arsitektur penerapan, skala, persyaratan kinerja, dan strategi biaya Anda. Driver CSI penyimpanan harus diinstal pada kluster EKS Anda, yang memungkinkan driver CSI untuk membuat dan mengelola Persistent Volume (PV) di luar siklus hidup Pod. Dengan menggunakan driver CSI, Anda dapat membuat definisi PV dari layanan AWS Storage yang didukung sebagai sumber daya kluster EKS. Pod kemudian dapat mengakses volume penyimpanan ini untuk volume datanya melalui pembuatan Persistent Volume Claim (PVC) untuk PV. Bergantung pada layanan penyimpanan AWS dan skenario penerapan Anda, satu PVC (dan PV terkait) dapat dilampirkan ke beberapa Pod untuk beban kerja. Misalnya, untuk pelatihan ML, data pelatihan bersama disimpan di PV dan diakses oleh beberapa Pod; untuk inferensi online real-time, model LLM di-cache pada PV dan diakses oleh beberapa Pod. Contoh file PV dan PVC YAMB untuk layanan AWS Storage disediakan di bawah ini untuk membantu Anda memulai.

Kinerja pemantauan Kinerja disk yang buruk dapat menunda pembacaan gambar kontainer, meningkatkan latensi startup pod, dan menurunkan inferensi atau throughput pelatihan. Gunakan Amazon CloudWatch untuk memantau metrik kinerja untuk layanan penyimpanan AWS Anda. Saat Anda mengidentifikasi kemacetan kinerja, ubah parameter konfigurasi penyimpanan Anda untuk mengoptimalkan kinerja.

Skenario: Beberapa instans GPU beban kerja

Amazon FSx for Lustre: Dalam skenario di mana Anda memiliki beberapa lingkungan instans komputasi EC2 GPU dengan beban kerja dinamis throughput bandwidth tinggi yang sensitif terhadap latensi, seperti pelatihan terdistribusi dan penayangan model, dan Anda memerlukan integrasi repositori data Amazon S3 asli, kami merekomendasikan Amazon untuk Lustre. FSx FSx untuk Lustre menyediakan sistem file paralel kinerja tinggi yang dikelola sepenuhnya yang dirancang untuk beban kerja intensif komputasi seperti komputasi kinerja tinggi (HPC), Machine Learning.

Anda dapat Menginstal driver FSx for Lustre CSI untuk memasang sistem FSx file di EKS sebagai Persistent Volume (PV), lalu menerapkan sistem file Lustre sebagai cache kinerja tinggi mandiri atau sebagai sistem file terkait S3 FSx untuk bertindak sebagai cache kinerja tinggi untuk data S3, memberikan throughput cepat dan tinggi untuk akses data di seluruh instance komputasi GPU Anda. I/O FSx untuk Lustre dapat digunakan dengan opsi penyimpanan Scratch-SSD atau persistent-SSD:

  • Penyimpanan Scratch-SSD: Direkomendasikan untuk beban kerja yang bersifat sementara atau berumur pendek (jam), dengan kapasitas throughput tetap per TIB yang disediakan.

  • Penyimpanan SSD persisten: Direkomendasikan untuk beban kerja yang kritis dan berjalan lama yang memerlukan tingkat ketersediaan tertinggi, misalnya simulasi HPC, analisis data besar, atau pelatihan Machine Learning. Dengan penyimpanan SSD persisten, Anda dapat mengonfigurasi kapasitas penyimpanan dan kapasitas throughput (per-TIB) yang diperlukan.

Pertimbangan kinerja:

  • Pod administratif FSx untuk mengelola sistem berkas Lustre: Konfigurasikan Pod “administratif” yang memiliki klien lustre diinstal dan sistem berkas terpasang. FSx Ini akan memungkinkan titik akses untuk mengaktifkan fine-tuning sistem FSx file, dan juga dalam situasi di mana Anda perlu melakukan pra-pemanasan sistem FSx file dengan data pelatihan ML atau model LLM Anda sebelum memulai instance komputasi GPU Anda. Hal ini sangat penting jika arsitektur Anda menggunakan instans GPU/komputasi EC2 Amazon berbasis Spot, di mana Anda dapat memanfaatkan Pod administratif untuk “menghangatkan” atau “memuat” data yang diinginkan ke dalam FSx sistem file, sehingga data siap diproses saat Anda menjalankan instans Amazon berbasis Spot. EC2

  • Elastic Fabric Adapter (EFA): Jenis penyebaran penyimpanan SSD persisten mendukung Elastic Fabric Adapter (EFA), di mana penggunaan EFA sangat ideal untuk kinerja tinggi dan beban kerja berbasis GPU berbasis throughput. Perhatikan bahwa FSx untuk Lustre mendukung NVIDIA GPUDirect Storage (GDS), di mana GDS adalah teknologi yang menciptakan jalur data langsung antara penyimpanan lokal atau jarak jauh dan memori GPU, untuk memungkinkan akses data yang lebih cepat.

  • Kompresi: Aktifkan kompresi data pada sistem file jika Anda memiliki jenis file yang dapat dikompresi. Ini dapat membantu meningkatkan kinerja karena kompresi data mengurangi jumlah data yang ditransfer antara FSx untuk server file Lustre dan penyimpanan.

  • Konfigurasi striping sistem file lustre:

    • Data striping: Memungkinkan Luster FSx untuk mendistribusikan data file di beberapa Object Storage Target (OSTs) dalam sistem file Lustre memaksimalkan akses paralel dan throughput, terutama untuk pekerjaan pelatihan ML. skala besar.

    • Pengupasan sistem file mandiri: Secara default, konfigurasi striping Lustre 4 komponen dibuat untuk Anda melalui kemampuan tata letak file Progresif (PFL) untuk Lustre. FSx Dalam sebagian besar skenario, Anda tidak perlu memperbarui hitungan/ukuran garis PFL Lustre default. Jika Anda perlu menyesuaikan striping data Lustre, maka Anda dapat secara manual menyesuaikan lustre striping dengan mengacu pada parameter striping dari sistem file for Lustre. FSx

    • Sistem File Tertaut S3: File yang diimpor ke sistem FSx file menggunakan integrasi Amazon S3 asli (Data Repository Association atau DRA) tidak menggunakan tata letak PFL default, melainkan menggunakan tata letak dalam parameter sistem file. ImportedFileChunkSize File yang diimpor S3 yang lebih besar dari file ImportedFileChunkSize akan disimpan di beberapa OSTs dengan jumlah garis berdasarkan nilai yang ImportedFileChunkSize ditentukan (default 1GiB). Jika Anda memiliki file besar, kami sarankan menyetel parameter ini ke nilai yang lebih tinggi.

    • Penempatan: Menerapkan sistem file FSx for Lustre di Availability Zone yang sama dengan node komputasi atau GPU Anda untuk mengaktifkan akses latensi terendah ke data, hindari pola akses akses lintas Availability Zone. Jika Anda memiliki beberapa node GPU yang terletak di Availability Zone yang berbeda, sebaiknya gunakan sistem FSx file di setiap Availability Zone untuk akses data latensi rendah.

Contoh

Definisi Persistent Volume (PV) untuk sistem file FSx for Lustre, menggunakan Static Provisioning (di mana FSx instance telah disediakan).

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]

Contoh

Definisi Klaim Volume Persisten untuk PV disebutfsx-pv:

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

Contoh

Konfigurasikan pod untuk menggunakan Klaim Volume Persisten darifsx-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

Untuk contoh lengkap, lihat FSx untuk Contoh Driver Lustre di. GitHub Pantau Amazon FSx untuk metrik kinerja Lustre menggunakan Amazon. CloudWatch Saat kemacetan kinerja diidentifikasi, sesuaikan parameter konfigurasi Anda sesuai kebutuhan.

Skenario: Beban kerja instance GPU tunggal

Mountpoint untuk Amazon S3 dengan Driver CSI: Anda dapat memasang bucket S3 sebagai volume di pod Anda menggunakan driver Mountpoint untuk Amazon S3 CSI. Metode ini memungkinkan kontrol akses berbutir halus di mana Pod dapat mengakses bucket S3 tertentu. Setiap pod memiliki instans mountpoint dan cache lokal (5-10GB) sendiri, mengisolasi kinerja pemuatan dan pembacaan model antar pod. Pengaturan ini mendukung otentikasi tingkat pod dengan IAM Roles for Service Accounts (IRSA) dan versi model independen untuk model atau pelanggan yang berbeda. Trade-off adalah peningkatan penggunaan memori dan lalu lintas API, karena setiap pod mengeluarkan panggilan API S3 dan mempertahankan cache-nya sendiri.

Contoh sebagian contoh penerapan Pod YAMB dengan Driver 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

Pertimbangan kinerja:

  • Caching data: Mountpoint untuk S3 dapat menyimpan konten cache untuk mengurangi biaya dan meningkatkan kinerja untuk pembacaan berulang ke file yang sama. Lihat konfigurasi Caching untuk opsi dan parameter caching.

  • Ukuran bagian objek: Saat menyimpan dan mengakses file berukuran lebih dari 72GB, lihat Mengonfigurasi kinerja Mountpoint untuk memahami cara mengonfigurasi parameter --write-part-size baris perintah --read-part-size dan profil data untuk memenuhi persyaratan profil data dan beban kerja Anda.

  • Shared-cache dirancang untuk objek berukuran hingga 1MB. Itu tidak mendukung benda besar. Gunakan opsi cache lokal untuk caching objek dalam NVMe atau volume EBS pada node EKS.

  • Biaya permintaan API: Saat melakukan sejumlah besar operasi file dengan Mountpoint untuk S3, biaya permintaan API dapat menjadi bagian dari biaya penyimpanan. Untuk mengurangi ini, jika konsistensi yang kuat tidak diperlukan, selalu aktifkan caching metadata dan atur metadata-ttl periode untuk mengurangi jumlah operasi API ke S3.

Untuk detail selengkapnya, lihat Mountpoint untuk Driver CSI Amazon S3 di dokumentasi resmi Amazon EKS. Kami menyarankan untuk memantau metrik kinerja Amazon S3 dengan metrik CloudWatch Amazon jika terjadi kemacetan dan menyesuaikan konfigurasi Anda jika diperlukan.

Amazon FSx untuk penyimpanan bersama persisten OpenZFS

Untuk skenario yang melibatkan beberapa instans komputasi EC2 GPU dengan beban kerja yang sensitif terhadap latensi yang membutuhkan ketersediaan tinggi, kinerja tinggi, sensitivitas biaya, dan beberapa penerapan pod untuk aplikasi yang berbeda, kami merekomendasikan Amazon untuk OpenZFS. FSx Beberapa contoh beban kerja termasuk inferensi waktu nyata, pembelajaran penguatan, dan pelatihan jaringan permusuhan generatif. FSx untuk OpenZFS sangat bermanfaat untuk beban kerja yang membutuhkan akses kinerja tinggi ke struktur direktori terfokus dengan file kecil menggunakan pola akses data IO kecil. Selain itu, FSx untuk OpenZFS memberikan fleksibilitas untuk menskalakan kinerja secara independen dari kapasitas penyimpanan, membantu Anda mencapai efisiensi biaya yang optimal dengan mencocokkan ukuran penyimpanan dengan kebutuhan aktual sambil mempertahankan tingkat kinerja yang diperlukan

Asli FSx untuk driver OpenZFS CSI memungkinkan pembuatan beberapa PVCs ke satu sistem file dengan membuat beberapa volume. Ini mengurangi overhead manajemen dan memaksimalkan pemanfaatan throughput sistem file dan IOPS melalui penerapan pod aplikasi terkonsolidasi pada satu sistem file. Selain itu, ini mencakup fitur perusahaan seperti snapshot zero-copy, klon zero-copy, dan kuota pengguna dan grup yang dapat disediakan secara dinamis melalui driver CSI.

FSx untuk OpenZFS mendukung tiga jenis penerapan yang berbeda saat pembuatan:

  • Single-AZ: Opsi biaya terendah dengan latensi sub-milidetik, tetapi tidak memberikan ketersediaan tinggi di sistem file atau tingkat Availability Zone. Direkomendasikan untuk pengembangan dan pengujian beban kerja atau yang memiliki ketersediaan tinggi di lapisan aplikasi.

  • Single-AZ (HA): Menyediakan ketersediaan tinggi pada tingkat sistem file dengan latensi sub-milidetik. Direkomendasikan untuk beban kerja kinerja tertinggi yang membutuhkan ketersediaan tinggi.

  • Multi-AZ: Menyediakan ketersediaan tinggi di tingkat sistem file serta di seluruh Availability Zones. Direkomendasikan untuk beban kerja berkinerja tinggi yang memerlukan ketersediaan tambahan di seluruh Availability Zone.

Pertimbangan kinerja:

  • Jenis penerapan: Jika ketersediaan tambahan di seluruh Availability Zones bukan merupakan persyaratan, pertimbangkan untuk menggunakan tipe penerapan Single-AZ (HA). Jenis penerapan ini menyediakan hingga 100% throughput untuk penulisan, mempertahankan latensi sub-milidetik, dan sistem file Gen2 memiliki NVMe cache tambahan untuk menyimpan hingga terrabyte data yang sering diakses. Sistem file multi-AZ menyediakan hingga 75% dari throughput untuk penulisan pada latensi yang meningkat untuk mengakomodasi lalu lintas lintas AZ.

  • Throughput dan IOPS: Baik throughput dan IOPS yang dikonfigurasi untuk sistem file dapat ditingkatkan atau diturunkan pasca penerapan. Anda dapat menyediakan hingga 10 akses data GB/s of disk throughput providing up to 21GB/s yang di-cache. IOPS dapat ditingkatkan hingga 400.000 dari disk dan cache dapat menyediakan lebih dari 1 juta IOPS. Perhatikan bahwa penskalaan throughput dari sistem file Single-AZ memang menyebabkan pemadaman singkat sistem file karena tidak ada ketersediaan tinggi. Penskalaan throughput dari sistem file Single-AZ (HA) atau Multi-AZ dapat dilakukan tanpa gangguan. SSD IOPS dapat diskalakan setiap enam jam sekali.

  • Storage Class: FSx untuk OpenZFS mendukung kelas penyimpanan SSD serta kelas penyimpanan Intelligent-Tiering. Untuk AI/ML beban kerja, disarankan untuk menggunakan kelas penyimpanan SSD yang memberikan kinerja yang konsisten terhadap beban kerja menjaga CPU/GPU sesibuk mungkin.

  • Kompresi: Aktifkan algoritma LZ4 kompresi jika Anda memiliki beban kerja yang dapat dikompresi. Ini mengurangi jumlah data yang dikonsumsi setiap file dalam cache yang memungkinkan lebih banyak data dilayani langsung dari cache sebagai throughput jaringan dan IOPS mengurangi beban pada disk SSD.

  • Ukuran rekaman: Sebagian besar AI/ML beban kerja akan mendapat manfaat dari meninggalkan ukuran catatan 128KiB default. Nilai ini hanya boleh dikurangi jika dataset terdiri dari file besar (di atas 10GiB) dengan akses blok kecil yang konsisten di bawah 128KiB dari aplikasi.

Setelah sistem file dibuat, volume root terkait secara otomatis dibuat oleh layanan. Ini adalah praktik terbaik untuk menyimpan data dalam volume anak dari volume root pada sistem file. Menggunakan driver CSI FSx for OpenZFS, Anda membuat Klaim Volume Persisten terkait untuk membuat volume anak secara dinamis.

Contoh:

Definisi Storage Class (SC) untuk volume OpenZFS, digunakan untuk membuat volume anak dari volume root ($ROOT_VOL_ID) pada sistem file yang ada dan mengekspor volume ke VPC CIDR ($VPC_CIDR) menggunakan protokol NFS v4.2. FSx 

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

Klaim Volume Persisten (PVC) yang dibuat secara dinamis terhadap yang fsxz-vol-sc dibuat di atas. Catatan, kapasitas penyimpanan yang dialokasikan adalah 1Gi, ini diperlukan FSx untuk volume OpenZFS seperti yang tercantum dalam FAQ driver CSI. Volume akan diberikan kapasitas penuh yang disediakan untuk sistem file dengan konfigurasi ini. Jika kapasitas volume perlu dibatasi, Anda dapat melakukannya menggunakan kuota pengguna atau grup.

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

Konfigurasikan pod untuk memasang volume menggunakan Persistent Volume Claim (PVC) dari 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 untuk cache model bersama

Dalam skenario di mana Anda memiliki beberapa lingkungan instans komputasi EC2 GPU dan memiliki beban kerja dinamis yang memerlukan akses model bersama di beberapa node dan Availability Zone (misalnya, inferensi online real-time dengan Karpenter) dengan kinerja moderat dan kebutuhan skalabilitas, sebaiknya gunakan sistem file Amazon Elastic File System (EFS) sebagai Volume Persisten melalui Driver EFS CSI. Amazon EFS adalah sistem file NFS berbasis cloud yang dikelola sepenuhnya, sangat tersedia, dan dapat diskalakan yang memungkinkan EC2 instance dan wadah dengan penyimpanan file bersama, dengan kinerja yang konsisten, dan di mana tidak diperlukan penyediaan penyimpanan di muka. Gunakan EFS sebagai volume model, dan pasang volume sebagai sistem file bersama dengan mendefinisikan Volume Persisten pada kluster EKS. Setiap Klaim Volume Persisten (PVC) yang didukung oleh sistem file EFS dibuat sebagai titik akses EFS ke sistem file EFS. EFS memungkinkan beberapa node dan pod untuk mengakses file model yang sama, menghilangkan kebutuhan untuk menyinkronkan data ke setiap sistem file node. Instal driver EFS CSI untuk mengintegrasikan EFS dengan EKS.

Anda dapat menerapkan sistem file Amazon EFS dengan mode throughput berikut:

  • Meledak Throughput: Timbangan throughput dengan ukuran sistem file, cocok untuk berbagai beban kerja dengan semburan sesekali.

  • Throughput yang Disediakan: Throughput khusus, ideal untuk pekerjaan pelatihan ML yang konsisten dengan kebutuhan kinerja yang dapat diprediksi dalam batasnya.

  • Throughput Elastis (direkomendasikan untuk ML): Secara otomatis menskalakan berdasarkan beban kerja, efektivitas biaya untuk berbagai beban kerja ML.

Untuk melihat spesifikasi performa, lihat Spesifikasi performa Amazon EFS.

Pertimbangan kinerja:

  • Gunakan Elastic Throughput untuk berbagai beban kerja.

  • Gunakan kelas penyimpanan Standar untuk beban kerja MS aktif.

Untuk contoh lengkap penggunaan sistem file Amazon EFS sebagai Volume persisten dalam cluster EKS dan Pod Anda, lihat Contoh Driver EFS CSI di GitHub. Pantau metrik kinerja Amazon EFS menggunakan Amazon CloudWatch. Saat kemacetan kinerja diidentifikasi, sesuaikan parameter konfigurasi Anda sesuai kebutuhan.

Gunakan S3 Express One Zone untuk Alur Kerja Berorientasi Objek yang Sensitif Latensi

Untuk AI/ML beban kerja yang sensitif terhadap latensi di Amazon EKS, seperti pelatihan model skala besar, inferensi, atau analitik performa tinggi, sebaiknya gunakan S3 Express One Zone untuk penyimpanan dan pengambilan model berkinerja tinggi. S3 Express One Zone menawarkan namespace hierarkis, seperti sistem file, tempat Anda cukup mengunggah ke bucket direktori, cocok untuk “membuang semuanya”, sambil mempertahankan kecepatan tinggi. Ini sangat berguna jika Anda terbiasa dengan alur kerja berorientasi objek. Atau, jika Anda lebih terbiasa dengan sistem file (misalnya, Posix-compliant), Anda dapat memilih Amazon FSx untuk Lustre atau OpenZFS. Amazon S3 Express One Zone menyimpan data dalam Availability Zone (AZ) tunggal menggunakan bucket direktori dan menawarkan latensi yang lebih rendah daripada bucket S3 standar, yang mendistribusikan data ke beberapa. AZs Untuk hasil terbaik, pastikan untuk menempatkan komputasi EKS Anda di AZ yang sama dengan bucket Express One Zone Anda. Untuk mempelajari selengkapnya tentang perbedaan S3 Express One Zone, lihat Perbedaan untuk bucket direktori.

Untuk mengakses S3 Express One Zone dengan semantik sistem file, sebaiknya gunakan Driver Mountpoint S3 CSI, yang memasang bucket S3 (termasuk Express One Zone) sebagai sistem file lokal. Ini menerjemahkan operasi file (misalnya, buka, baca, tulis) ke dalam panggilan API S3, menyediakan akses throughput tinggi yang dioptimalkan untuk beban kerja baca-berat dari beberapa klien dan penulisan berurutan ke objek baru. Untuk detail tentang operasi dan batasan yang didukung (misalnya, tidak ada kepatuhan POSIX penuh, tetapi menambahkan dan mengganti nama yang didukung di Express One Zone), lihat dokumentasi semantik Mountpoint.

Manfaat kinerja

  • Menyediakan akses data hingga 10x lebih cepat daripada Standar S3, dengan latensi milidetik satu digit yang konsisten dan biaya permintaan hingga 80% lebih rendah.

  • Timbangan untuk menangani ratusan ribu hingga jutaan permintaan per detik per bucket direktori, menghindari throttling atau brownout yang terlihat di S3 standar selama beban ekstrim (misalnya, dari cluster dengan puluhan hingga ratusan ribu jaringan jenuh). GPUs/CPUs

  • Menggunakan mekanisme otentikasi berbasis sesi. Otentikasi sekali untuk mendapatkan token sesi, lalu lakukan operasi berulang dengan kecepatan tinggi tanpa overhead auth per permintaan. Ini dioptimalkan untuk beban kerja seperti checkpointing yang sering atau pemuatan data.

Kasus penggunaan yang direkomendasikan

  • Caching: Salah satu kasus penggunaan teratas menggunakan Driver Mountpoint S3 CSI dengan S3 Express One Zone adalah caching. Contoh pertama membaca data dari Standar S3 (tujuan umum), menyimpannya di Zona Satu Ekspres latensi rendah. Pembacaan selanjutnya oleh klien lain mengakses data yang di-cache lebih cepat, yang ideal untuk skenario multi-node di mana beberapa node EKS membaca data yang sama (misalnya, kumpulan data pelatihan bersama). Ini dapat meningkatkan kinerja hingga 7x untuk akses berulang dan mengurangi biaya komputasi. Untuk beban kerja yang memerlukan kepatuhan POSIX penuh (misalnya, penguncian file dan modifikasi di tempat), pertimbangkan Amazon FSx untuk Lustre atau OpenZFS sebagai alternatif.

  • AI/ML Pelatihan dan inferensi skala besar: Ideal untuk beban kerja dengan ratusan atau ribuan node komputasi (misalnya, GPUs dalam kluster EKS) di mana pelambatan S3 tujuan umum dapat menyebabkan penundaan, membuang-buang sumber daya komputasi yang mahal. Misalnya, peneliti LLM atau organisasi yang menjalankan model harian tests/checkpoints mendapat manfaat dari akses yang cepat dan andal tanpa merusak S3 regional. Untuk beban kerja skala yang lebih kecil (misalnya, 10 detik node), Standar S3 atau kelas penyimpanan lainnya mungkin cukup.

  • Pipa data: Load/prepare model, data pelatihan arsip, atau pos pemeriksaan aliran. Jika tim Anda lebih suka penyimpanan objek daripada sistem file tradisional (misalnya, karena keakraban dengan S3), gunakan ini alih-alih rekayasa perubahan untuk opsi yang sesuai dengan POSIX seperti untuk Lustre. FSx

Pertimbangan-pertimbangan

  • Ketahanan: Desain single-AZ memberikan daya tahan 99,999999999% (sama dengan standar S3, melalui redundansi dalam AZ) tetapi ketersediaan lebih rendah (dirancang 99,95%, SLA 99,9%) dibandingkan dengan kelas Multi-AZ (ketersediaan 99,99%). Ini kurang tahan terhadap kegagalan AZ. Gunakan untuk data recreatable atau cache. Pertimbangkan replikasi atau cadangan multi-AZ untuk beban kerja penting.

  • API dan Dukungan Fitur: Mendukung subset S3 APIs (misalnya, tidak ada kebijakan siklus hidup atau replikasi); mungkin memerlukan perubahan aplikasi kecil untuk otentikasi sesi atau penanganan objek.

  • Integrasi EKS: Temukan bersama EKS Anda pods/nodes di AZ yang sama dengan bucket direktori untuk meminimalkan latensi jaringan. Gunakan driver Mountpoint untuk Amazon S3 atau CSI untuk akses asli Kubernetes.

  • Pengujian: Uji latensi pengambilan di lingkungan non-produksi untuk memvalidasi peningkatan kinerja. Pantau pelambatan dalam skenario S3 standar (misalnya, saturasi GPU tinggi) dan bandingkan.

Kelas penyimpanan S3 Express One Zone tersedia di beberapa wilayah dan terintegrasi dengan EKS untuk beban kerja yang membutuhkan akses objek tanpa menunggu penyimpanan. Untuk mempelajari lebih lanjut, lihat Memulai dengan S3 Express One Zone.