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

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

스토리지

데이터 관리 및 스토리지

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 스토리지 서비스의 선택은 배포 아키텍처, 규모, 성능 요구 사항 및 비용 전략에 따라 달라집니다. 스토리지 CSI 드라이버를 EKS 클러스터에 설치해야 합니다. 그러면 CSI 드라이버가 포드의 수명 주기 외부에서 영구 볼륨(PV)을 생성하고 관리할 수 있습니다. CSI 드라이버를 사용하여 지원되는 AWS 스토리지 서비스의 PV 정의를 EKS 클러스터 리소스로 생성할 수 있습니다. 그런 다음 포드는 PV에 대한 영구 볼륨 클레임(PVC)을 생성하여 데이터 볼륨에 대한 이러한 스토리지 볼륨에 액세스할 수 있습니다. AWS 스토리지 서비스 및 배포 시나리오에 따라 단일 PVC(및 관련 PV)를 워크로드의 여러 포드에 연결할 수 있습니다. 예를 들어 ML 훈련의 경우 공유 훈련 데이터는 PV에 저장되고 여러 포드가 액세스합니다. 실시간 온라인 추론의 경우 LLM 모델은 PV에 캐시되고 여러 포드가 액세스합니다. 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 드라이버를 설치하여 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/컴퓨팅 인스턴스를 활용하는 경우 특히 중요합니다.이 인스턴스에서는 관리 포드를 활용하여 FSx 파일 시스템에 원하는 데이터를 "웜" 또는 "사전 로드"하여 스팟 기반 Amazon EC2 인스턴스를 실행할 때 데이터를 처리할 준비가 되도록 할 수 있습니다.

  • 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 드라이버 예제를 참조하세요.

시나리오: 단일 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 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 드라이버 예제를 참조하세요.

성능 모니터링 디스크 성능이 좋지 않으면 컨테이너 이미지 읽기가 지연되고 포드 시작 지연 시간이 증가하며 추론 또는 훈련 처리량이 저하될 수 있습니다. 병목 현상이 발생할 경우 각 AWS Storage 서비스의 성능 지표를 모니터링하고 필요한 경우 구성을 조정하려면 다음 방법을 사용하는 것이 좋습니다.