스토리지 - Amazon EKS
데이터 관리 및 스토리지

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

스토리지

데이터 관리 및 스토리지

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 스토리지 서비스의 선택은 배포 아키텍처, 규모, 성능 요구 사항 및 비용 전략에 따라 달라집니다. 스토리지 CSI 드라이버를 EKS 클러스터에 설치해야 합니다. 그러면 CSI 드라이버가 포드의 수명 주기 외부에서 영구 볼륨(PV)을 생성하고 관리할 수 있습니다. CSI 드라이버를 사용하여 지원되는 AWS 스토리지 서비스의 PV 정의를 EKS 클러스터 리소스로 생성할 수 있습니다. 그런 다음 포드는 PV에 대한 영구 볼륨 클레임(PVC)을 생성하여 데이터 볼륨에 대한 이러한 스토리지 볼륨에 액세스할 수 있습니다. AWS 스토리지 서비스 및 배포 시나리오에 따라 단일 PVC(및 관련 PV)를 워크로드의 여러 포드에 연결할 수 있습니다. 예를 들어 ML 훈련의 경우 공유 훈련 데이터는 PV에 저장되고 여러 포드가 액세스합니다. 실시간 온라인 추론의 경우 LLM 모델은 PV에 캐시되고 여러 포드가 액세스합니다. 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 드라이버를 설치하여 EKS에 FSx 파일 시스템을 영구 볼륨(PV)으로 탑재한 다음 FSx for Lustre 파일 시스템을 독립형 고성능 캐시 또는 S3-linked 파일 시스템으로 배포하여 S3 데이터에 대한 고성능 캐시 역할을 하여 GPU 컴퓨팅 인스턴스 전반에서 데이터 액세스를 위한 빠른 I/O와 높은 처리량을 제공할 수 있습니다. FSx for Lustre는 Scratch-SSD 또는 영구-SSD 스토리지 옵션을 사용하여 배포할 수 있습니다.

  • Scratch-SSD 스토리지: TiB당 고정 처리량 용량이 프로비저닝된 임시 또는 단기(시간) 워크로드에 권장됩니다.

  • 영구 SSD 스토리지: HPC 시뮬레이션, 빅 데이터 분석 또는 Machine Learning 훈련과 같이 최고 수준의 가용성이 필요한 미션 크리티컬 장기 실행 워크로드에 권장됩니다. 영구 SSD 스토리지를 사용하면 필요한 스토리지 용량과 처리량 용량(TiB당)을 모두 구성할 수 있습니다.

성능 고려 사항:

  • FSx for Lustre 파일 시스템을 관리하기 위한 관리 포드: lustre 클라이언트가 설치되어 있고 FSx 파일 시스템이 탑재된 "관리" 포드를 구성합니다. 이렇게 하면 액세스 포인트가 FSx 파일 시스템을 미세 조정할 수 있으며, GPU 컴퓨팅 인스턴스를 시작하기 전에 ML 훈련 데이터 또는 LLM 모델로 FSx 파일 시스템을 사전 워밍해야 하는 상황도 가능합니다. 이는 아키텍처가 스팟 기반 Amazon EC2 GPU/컴퓨팅 인스턴스를 활용하는 경우 특히 중요합니다. 스팟 기반 Amazon EC2 인스턴스를 실행할 때 데이터를 처리할 준비가 되도록 관리 포드를 사용하여 FSx 파일 시스템에 원하는 데이터를 "웜" 또는 "사전 로드"할 수 있습니다.

  • EFA(Elastic Fabric Adapter): 영구 SSD 스토리지 배포 유형은 EFA(Elastic Fabric Adapter)를 지원합니다. EFA를 사용하면 고성능 및 처리량 기반 GPU 기반 워크로드에 적합합니다. FSx for Lustre는 NVIDIA GPUDirect 스토리지(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에 저장됩니다. 파일이 큰 경우이 파라미터를 더 높은 값으로 조정하는 것이 좋습니다.

    • 배치: 컴퓨팅 또는 GPU 노드와 동일한 가용 영역에 FSx for Lustre 파일 시스템을 배포하여 데이터에 대한 지연 시간을 최소화하고 교차 가용 영역 액세스 패턴을 방지합니다. 서로 다른 가용 영역에 여러 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 성능 지표를 모니터링합니다. Amazon CloudWatch 성능 병목 현상이 식별되면 필요에 따라 구성 파라미터를 조정합니다.

시나리오: 단일 GPU 인스턴스 워크로드

CSI 드라이버가 포함된 Mountpoint for Amazon S3: Mountpoint for Amazon S3 CSI 드라이버를 사용하여 포드에 볼륨으로 S3 버킷을 탑재할 수 있습니다. Amazon S3 이 방법을 사용하면 특정 S3 버킷에 액세스할 수 있는 포드에 대한 세분화된 액세스 제어가 가능합니다. 각 포드에는 자체 탑재 지점 인스턴스와 로컬 캐시(5~10GB)가 있어 포드 간에 모델 로드 및 읽기 성능을 격리합니다. 이 설정은 서비스 계정에 대한 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 요청 요금은 스토리지 비용의 일부가 될 수 있습니다. 이를 완화하려면 강력한 일관성이 필요하지 않은 경우 항상 메타데이터 캐싱을 활성화하고 metadata-ttl 기간을 설정하여 API 작업 수를 S3로 줄입니다.

자세한 내용은 Amazon EKS 공식 설명서의 Mountpoint for Amazon S3 CSI Driver를 참조하세요. 병목 현상이 발생하는 경우 Amazon CloudWatch 지표를 사용하여 Amazon Amazon S3의 성능 지표를 모니터링하고 필요한 경우 구성을 조정하는 것이 좋습니다.

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는 생성 시 세 가지 배포 유형을 지원합니다.

  • 단일 AZ: 지연 시간이 밀리초 미만인 최저 비용 옵션이지만 파일 시스템 또는 가용 영역 수준에서 고가용성을 제공하지 않습니다. 개발 및 테스트 워크로드 또는 애플리케이션 계층에서 고가용성이 있는 워크로드에 권장됩니다.

  • 단일 AZ(HA): 파일 시스템 수준에서 밀리초 미만의 지연 시간으로 고가용성을 제공합니다. 고가용성이 필요한 고성능 워크로드에 권장됩니다.

  • 다중 AZ: 파일 시스템 수준과 가용 영역 전체에서 고가용성을 제공합니다. 가용 영역 전체에서 추가 가용성이 필요한 고성능 워크로드에 권장됩니다.

성능 고려 사항:

  • 배포 유형: 가용 영역 전반의 추가 가용성이 필요하지 않은 경우 단일 AZ(HA) 배포 유형을 사용하는 것이 좋습니다. 이 배포 유형은 쓰기 처리량의 최대 100%를 제공하고, 밀리초 미만의 지연 시간을 유지하며, Gen2 파일 시스템에는 최대 테라바이트의 자주 액세스하는 데이터를 저장할 수 있는 추가 NVMe 캐시가 있습니다. 다중 AZ 파일 시스템은 쓰기 처리량의 최대 75%를 제공하며 교차 AZ 트래픽에 대한 지연 시간이 증가합니다.

  • 처리량 및 IOPS: 배포 후 파일 시스템에 대해 구성된 처리량 및 IOPS를 모두 확장하거나 축소할 수 있습니다. 최대 10GB/s의 디스크 처리량을 프로비저닝하여 최대 21GB/s의 캐시된 데이터 액세스를 제공할 수 있습니다. IOPS는 디스크에서 최대 400,000까지 확장할 수 있으며 캐시는 1백만 IOPS 이상을 제공할 수 있습니다. 단일 AZ 파일 시스템의 처리량 조정으로 인해 고가용성이 없으므로 파일 시스템이 잠시 중단됩니다. 단일 AZ(HA) 또는 다중 AZ 파일 시스템의 처리량 조정은 중단 없이 수행할 수 있습니다. SSD IOPS는 6시간마다 한 번씩 확장할 수 있습니다.

  • 스토리지 클래스: FSx for OpenZFS는 SSD 스토리지 클래스와 Intelligent-Tiering 스토리지 클래스를 모두 지원합니다. AI/ML 워크로드의 경우 CPU/GPU의 사용량을 최대한으로 유지하면서 워크로드에 일관된 성능을 제공하는 SSD 스토리지 클래스를 사용하는 것이 좋습니다.

  • 압축: 압축할 수 있는 워크로드가 있는 경우 LZ4 압축 알고리즘을 활성화합니다. 이렇게 하면 각 파일이 캐시에서 사용하는 데이터의 양이 줄어들어 캐시에서 직접 더 많은 데이터를 네트워크 처리량 및 IOPS로 제공할 수 있어 SSD 디스크의 부하가 줄어듭니다.

  • 레코드 크기: 대부분의 AI/ML 워크로드는 기본 128KiB 레코드 크기를 그대로 두면 도움이 됩니다. 데이터 세트가 애플리케이션에서 128KiB 미만의 일관된 작은 블록 액세스 권한을 가진 큰 파일(10GiB 128KiB 이상)로 구성된 경우에만이 값을 줄여야 합니다.

파일 시스템이 생성되면 서비스에 의해 연결된 루트 볼륨이 자동으로 생성됩니다. 파일 시스템에서 루트 볼륨의 하위 볼륨 내에 데이터를 저장하는 것이 가장 좋습니다. FSx for OpenZFS CSI 드라이버를 사용하여 연결된 영구 볼륨 클레임을 생성하여 하위 볼륨을 동적으로 생성합니다.

예시:

기존 파일 시스템에서 루트 볼륨의 하위 볼륨($ROOT_VOL_ID)을 생성하고 NFS v4.2 프로토콜을 사용하여 볼륨을 VPC CIDR($VPC_CIDR)로 내보내는 데 사용되는 FSx for OpenZFS 볼륨에 대한 스토리지 클래스(SC) 정의입니다.

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 드라이버 FAQ에 명시된 대로 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 CSI 드라이버를 설치하여 EFS를 EKS와 통합합니다.

다음 처리량 모드로 Amazon EFS 파일 시스템을 배포할 수 있습니다.

  • 버스팅 처리량: 가끔 버스트가 발생하는 다양한 워크로드에 적합한 파일 시스템 크기에 따라 처리량을 조정합니다.

  • 프로비저닝된 처리량: 제한 내에서 예측 가능한 성능 요구 사항이 있는 일관된 ML 훈련 작업에 이상적인 전용 처리량입니다.

  • 탄력적 처리량(ML에 권장): 다양한 ML 워크로드에 대한 비용 효율성, 워크로드에 따라 자동으로 확장됩니다.

성능 사양을 보려면 Amazon EFS 성능 사양을 참조하세요.

성능 고려 사항:

  • 다양한 워크로드에 탄력적 처리량을 사용합니다.

  • 활성 ML 워크로드에는 표준 스토리지 클래스를 사용합니다.

Amazon EFS 파일 시스템을 EKS 클러스터 및 포드 내의 영구 볼륨으로 사용하는 전체 예제는 GitHub의 EFS CSI 드라이버 예제를 참조하세요. Amazon CloudWatch를 사용하여 Amazon EFS 성능 지표를 모니터링합니다. Amazon CloudWatch 성능 병목 현상이 식별되면 필요에 따라 구성 파라미터를 조정합니다.

지연 시간에 민감한 객체 지향 워크플로에 S3 Express One Zone 사용

대규모 모델 훈련, 추론 또는 고성능 분석과 같은 Amazon EKS의 지연 시간에 민감한 AI/ML 워크로드의 경우 고성능 모델 스토리지 및 검색에 S3 Express One Zone을 사용하는 것이 좋습니다. S3 Express One Zone은 파일 시스템과 같은 계층적 네임스페이스를 제공합니다.이 네임스페이스는 고속을 유지하면서 "모든 것을 집어넣기"에 적합한 디렉터리 버킷에 업로드하기만 하면 됩니다. 이는 객체 지향 워크플로에 익숙한 경우에 특히 유용합니다. 또는 파일 시스템에 더 익숙한 경우(예: POSIX 준수) Amazon FSx for Lustre 또는 OpenZFS를 선호할 수 있습니다. Amazon S3 Express One Zone은 디렉터리 버킷을 사용하고 여러 AZ에 데이터를 분산하는 표준 S3 버킷보다 짧은 지연 시간을 제공하는 단일 가용 영역(AZs)에 데이터를 저장합니다. 최상의 결과를 얻으려면 Express One Zone 버킷과 동일한 AZ에 EKS 컴퓨팅을 공동 배치해야 합니다. 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배 빠른 데이터 액세스를 제공하며, 일관된 한 자릿수 밀리초 지연 시간과 최대 80% 낮은 요청 비용을 제공합니다.

  • 디렉터리 버킷당 초당 수십만 개에서 수백만 개의 요청을 처리하도록 규모를 조정하여 과도한 로드(예: 수십 개에서 수십만 개의 GPUs/CPUs 포화 네트워크가 있는 클러스터) 중에 표준 S3에서 볼 수 있는 제한 또는 브라운아웃을 방지합니다.

  • 세션 기반 인증 메커니즘을 사용합니다. 한 번 인증하여 세션 토큰을 얻은 다음 요청당 인증 오버헤드 없이 고속으로 반복 작업을 수행합니다. 이는 빈번한 체크포인트 또는 데이터 로드와 같은 워크로드에 최적화되어 있습니다.

권장 사용 사례

  • 캐싱: Mountpoint S3 CSI 드라이버를 S3 Express One Zone과 함께 사용하는 주요 사용 사례 중 하나는 캐싱입니다. 첫 번째 인스턴스는 S3 Standard(범용)에서 데이터를 읽고 지연 시간이 짧은 Express One Zone에서 캐싱합니다. 다른 클라이언트의 후속 읽기는 캐시된 데이터에 더 빠르게 액세스하므로 여러 EKS 노드가 동일한 데이터(예: 공유 훈련 데이터 세트)를 읽는 다중 노드 시나리오에 적합합니다. 이를 통해 반복 액세스의 성능을 최대 7배 개선하고 컴퓨팅 비용을 절감할 수 있습니다. 전체 POSIX 규정 준수(예: 파일 잠금 및 현재 위치 수정)가 필요한 워크로드의 경우 Amazon FSx for Lustre 또는 OpenZFS를 대안으로 고려하세요.

  • 대규모 AI/ML 훈련 및 추론: 범용 S3 제한으로 인해 지연이 발생하여 비용이 많이 드는 컴퓨팅 리소스가 낭비될 수 있는 수백 또는 수천 개의 컴퓨팅 노드(예: EKS 클러스터의 GPUs)가 있는 워크로드에 적합합니다. 예를 들어 LLM 연구원 또는 일일 모델 테스트/체크포인트를 실행하는 조직은 리전 S3를 중단하지 않고 빠르고 안정적인 액세스의 이점을 누릴 수 있습니다. 소규모 워크로드(예: 노드 10개)의 경우 S3 Standard 또는 기타 스토리지 클래스로 충분할 수 있습니다.

  • 데이터 파이프라인: 모델 로드/준비, 훈련 데이터 아카이브 또는 스트림 체크포인트. 팀이 기존 파일 시스템보다 객체 스토리지를 선호하는 경우(예: S3에 익숙함) FSx for Lustre와 같은 POSIX 호환 옵션에 대한 변경 사항을 엔지니어링하는 대신이 옵션을 사용합니다.

고려 사항

  • 복원력: 단일 AZ 설계는 다중 AZ 클래스(99.99% 가용성)에 비해 99.999999999% 내구성(표준 S3와 동일, AZ 내의 중복성을 통해)을 제공하지만 가용성은 낮습니다(99.95% 설계, 99.9% SLA). AZ 장애에 대한 복원력이 떨어집니다. 다시 생성 가능하거나 캐시된 데이터에 사용합니다. 중요한 워크로드에 대해 다중 AZ 복제 또는 백업을 고려합니다.

  • API 및 기능 지원: S3 APIs의 하위 집합을 지원합니다(예: 수명 주기 정책 또는 복제 없음). 세션 인증 또는 객체 처리를 위해 사소한 앱 변경이 필요할 수 있습니다.

  • EKS 통합: 디렉터리 버킷과 동일한 AZ에 EKS 포드/노드를 공동 배치하여 네트워크 지연 시간을 최소화합니다. Kubernetes 네이티브 액세스를 위해 Mountpoint for Amazon S3 또는 CSI 드라이버를 사용합니다.

  • 테스트: 비프로덕션 환경에서 검색 지연 시간을 테스트하여 성능 향상을 검증합니다. 표준 S3 시나리오(예: 높은 GPU 포화도)에서 제한을 모니터링하고 비교합니다.

S3 Express One Zone 스토리지 클래스는 여러 리전에서 사용할 수 있으며 스토리지를 기다리지 않고 객체 액세스가 필요한 워크로드에 대해 EKS와 통합됩니다. 자세한 내용은 S3 Express One Zone 시작하기를 참조하세요.