성능 - Amazon EKS
애플리케이션 조정 및 성능

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

성능

애플리케이션 조정 및 성능

ML 아티팩트, 서비스 프레임워크 및 시작 최적화 관리

Amazon EKS에 기계 학습(ML) 모델을 배포하려면 모델을 컨테이너 이미지 및 런타임 환경에 통합하는 방법을 신중하게 고려해야 합니다. 이렇게 하면 확장성, 재현성 및 효율적인 리소스 사용률이 보장됩니다. 이 주제에서는 ML 모델 아티팩트를 처리하고, 프레임워크 제공을 선택하고, 사전 캐싱과 같은 기술을 통해 컨테이너 시작 시간을 최적화하는 다양한 접근 방식을 설명합니다.이 모든 방법은 컨테이너 시작 시간을 줄이도록 조정되었습니다.

컨테이너 이미지 크기 줄이기

  • 시작 시 컨테이너 이미지 크기를 줄이는 것은 이미지를 더 작게 만드는 또 다른 방법입니다. 컨테이너 이미지 빌드 프로세스의 모든 단계에서 줄일 수 있습니다. 시작하려면 필요한 종속성 수가 가장 적은 기본 이미지를 선택합니다. 이미지 빌드 중에는 필요한 필수 라이브러리와 아티팩트만 포함합니다. 이미지를 빌드할 때 여러 RUN 또는 COPY 명령을 결합하여 더 적은 수의 더 큰 계층을 생성해 보세요. 더 작은 이미지를 빌드하면 다음과 같은 장단점이 있습니다.

  • 장점:

    • 이미지 풀이 더 빠르고 전반적으로 스토리지가 덜 필요합니다.

    • 이미지가 작을수록 공격 벡터가 줄어듭니다.

  • 단점:

    • 컨테이너 이미지가 더 간소화되면 다양한 환경에서 실행해야 하는 요구 사항을 충족하기 위해 여러 이미지를 생성해야 합니다.

    • 명령을 결합하여 크기를 절약하는 것은 때때로 무시할 수 있으므로 다양한 빌드 접근 방식을 테스트하여 최상의 결과를 가져오는 것이 무엇인지 확인해야 합니다. AI/ML 프레임워크의 경우 런타임 전용 이미지(예: 3.03GBpytorch/pytorch:2.7.1-cuda11.8-cudnn9-runtime에서 대 6.66GB에서 개발)와 같은 변형을 선택하지만, 작은 이미지로 워크로드를 벤치마킹하면 JIT 컴파일을 건너뛰어 코드 경로가 느려질 수 있습니다. 다단계 빌드를 사용하여 필요한 아티팩트만 복사하여 빌드와 런타임을 분리합니다(예: 레지스트리 또는 로컬 컨텍스트의 경우 COPY —from=를 통해). 더 적은 계층을 위해 어셈블리 단계에서 COPY를 결합하여 계층 최적화를 사용합니다. 단, 캐시 효율성 감소 및 빌드 시간 연장에 대비합니다.

배포에서 ML 모델 아티팩트 처리

핵심 결정은 ML 모델 아티팩트(예: 가중치, 구성) 자체를 처리하는 방법입니다. 선택 사항은 이미지 크기, 배포 속도, 모델 업데이트 빈도 및 운영 오버헤드에 영향을 미칩니다. "모델" 저장을 참조할 때는 모델 아티팩트(예: 훈련된 파라미터, 모델 가중치)를 참조하지 않습니다. Amazon EKS에서 ML 모델 아티팩트를 처리하는 방법에는 세 가지가 있습니다. 각 에는 단점이 있으며, 가장 좋은 단점은 모델의 크기, 업데이트 주기 및 인프라 요구 사항에 따라 달라지며, 최소 권장 사항부터 가장 권장 사항까지 나열됩니다.

모델을 컨테이너 이미지로 베이킹 이미지 빌드 중에 모델 파일(예: .safetensors, .pth, .h5)을 컨테이너 이미지(예: Dockerfile)에 복사합니다. 모델은 변경 불가능한 이미지의 일부입니다. 업데이트 빈도가 낮은 소형 모델에는이 접근 방식을 사용하는 것이 좋습니다.

  • 장점: 일관성과 재현성을 보장하고, 로드 지연이 없으며, 종속성 관리를 간소화합니다.

  • 단점: 이미지 크기가 커지고 빌드 및 푸시 속도가 느려지며 모델 업데이트를 위해 재구축 및 재배포가 필요하므로 레지스트리 풀 처리량으로 인한 대규모 모델에 적합하지 않습니다. 또한 더 복잡한 설정으로 인해 실험, 디버깅 및 테스트에 대한 피드백 루프가 길어질 수 있으며, 여러 이미지에 함께 배치하면 스토리지 비용이 증가할 수 있습니다.

런타임 시 모델 다운로드 컨테이너 시작 시 애플리케이션은 init 컨테이너 또는 진입점의 스크립트를 통해 외부 스토리지(예: Mountpoint for S3 CSI 드라이버, Amazon S3 S3)에서 모델을 다운로드합니다. S3 업데이트가 빈번한 대규모 모델의 경우이 접근 방식부터 시작하는 것이 좋습니다.

  • 장점: 컨테이너 이미지를 코드/런타임에 초점을 맞추고, 재구축 없이 손쉬운 모델 업데이트를 지원하며, 스토리지 메타데이터를 통한 버전 관리를 지원합니다. 또한 컨테이너 이미지 크기를 늘리지 않고 모델을 A/B 테스트, 핫 스왑 또는 롤백할 수 있으며, 모든 컨테이너 이미지에 패키징하지 않고도 여러 애플리케이션 간에 모델을 공유할 수 있습니다. 또한 ML 또는 애플리케이션 팀의 워크플로에 최소한의 변경 사항을 도입하고 더 빠른 컨테이너 빌드를 지원하여 실험 및 테스트를 지원합니다. AWS CLI, s5cmd 또는 Mountpoint S3 CSI 드라이버와 같은 S3 CRT 지원 도구를 사용하면 다운로드 지연 시간을 크게 줄이고 대용량 파일의 성능을 개선할 수 있으므로 네트워크 및 레지스트리 성능에 따라 ECR과 같은 레지스트리에서 대규모 베이크 컨테이너 이미지를 가져오는 것보다 전체 포드 시작 시간이 빨라지는 경우가 많습니다. S3

  • 단점: 잠재적 네트워크 장애를 도입하고(재시도 로직 필요), 인증 및 캐싱이 필요합니다. ECR 기능을 복제하는 추가 스토리지 및 정리 관리와 함께 재시도, 오류 처리 및 백오프를 포함하여 다운로드 프로세스를 처리하면 추가적인 운영 복잡성이 발생합니다.

영구 볼륨을 통해 모델 탑재 모델을 외부 스토리지(예: Amazon EFS, EBS, FSx for NetApp ONTAP, FSx for Lustre, FSx for OpenZFS 또는 Mountpoint S3 CSI 드라이버를 통해 S3)에 저장하고 Kubernetes PersistentVolume(PV)으로 탑재합니다. 이는 예측 또는 추론을 수행할 수 있도록 모델의 훈련 프로세스 중에 생성된 파일 및 데이터입니다. 포드 또는 클러스터 전반의 공유 모델에이 접근 방식을 사용하는 것이 좋습니다.

  • 장점: 공유 액세스를 위해 이미지에서 모델을 분리하고, 재시작 없이 업데이트를 용이하게 하며( 프레임워크에서 지원하는 경우), 대규모 데이터 세트를 효율적으로 처리합니다. 또한 복제, 공유 및 스냅샷과 같은 기능을 통해 Kubernetes 기반 프로비저닝 및 액세스 제어를 지원하므로 모델을 복사하고 새 작업을 생성할 필요가 줄어듭니다. 컨테이너 이미지를 재구축하지 않고도 애플리케이션과 별도로 모델 버전을 업데이트하고 실험 및 테스트를 위해 컨테이너 빌드를 가속화할 수 있는 기능과 함께 모델에 대한 POSIX 기반 액세스 제어가 가능합니다. 아티팩트를 메모리로 읽는 AI/ML 추론 애플리케이션의 경우 노드의 로컬 디스크에 중간에 저장할 필요 없이 외부 파일 시스템에서 직접 데이터를 로드할 수 있으므로 로드 성능이 향상됩니다. 또한 대규모 모델을 대규모로 저장하기 위해 FSx for NetApp ONTAP과 같은 서비스인 FSx for Lustre는 스토리지 최적화 기법(예: 중복 제거, 압축, 씬 프로비저닝), 스냅샷을 통한 버전 관리, 스토리지 공간 낭비 없이 동일한 파일 재사용 지원을 제공합니다. S3와 같은 다른 서비스는 네이티브 버전 관리를 제공합니다. 이 접근 방식은 복제 구성(예: FSx의 비동기 복제 또는 S3 및 EFS의 리전 간 복제)에 따라 클러스터와 잠재적 리전에 걸쳐 있을 수도 있습니다.

  • 단점: 네트워크에 연결되어 있고 스토리지 프로비저닝 및 액세스 제어가 필요한 경우 I/O 지연 시간을 추가할 수 있으며, 스토리지가 클러스터별인 경우 이동성이 떨어질 수 있습니다(예: EBS). 단점으로는 CI/CD 변경 및 로더 프로세스 유지 관리에 대한 추가 운영 복잡성, 스토리지 비용을 줄이기 위한 사용자 지정 TTL/보존 메커니즘의 필요성, 보다 복잡한 리전 간 복제 등이 있습니다. 모델 아티팩트의 읽기 성능은 컨테이너 이미지 다운로드 시간을 기준으로 측정해야 합니다.

ML 모델 제공

Amazon EKS에서 기계 학습(ML) 모델을 배포하고 제공하려면 지연 시간, 처리량, 확장성 및 운영 단순성을 최적화할 수 있는 적절한 모델 제공 접근 방식을 선택해야 합니다. 선택은 모델 유형(예: 언어, 비전 모델), 워크로드 요구 사항(예: 실시간 추론) 및 팀 전문 지식에 따라 달라집니다. 일반적인 접근 방식에는 프로토타이핑을 위한 Python 기반 설정, 프로덕션급 기능을 위한 전용 모델 서버, 고성능 및 효율성을 위한 특수 추론 엔진이 포함됩니다. 각 방법에는 설정 복잡성, 성능 및 리소스 사용률의 장단점이 포함됩니다. 서비스 프레임워크는 종속성으로 인해 컨테이너 이미지 크기(여러 GBs 늘릴 수 있으며, 이는 시작 시간에 영향을 미칠 수 있습니다. 이를 완화하기 위해 아티팩트 처리 기술을 사용한 분리를 고려하세요. 옵션은 최소 권장부터 가장 권장까지 나열됩니다.

Python 프레임워크 사용(예: FastAPI, PyTorch를 사용하는 HuggingFace 변환기) 컨테이너화된 노드 설정 내에 모델 파일(가중치, 구성, 토큰화기)을 포함하는 Python 프레임워크를 사용하여 사용자 지정 애플리케이션을 개발합니다.

  • 장점: 간편한 프로토타이핑, 추가 인프라 없이 Python 전용, 모든 HuggingFace 모델과 호환, 간단한 Kubernetes 배포.

  • 단점: 단일 요청/단순 일괄 처리, 느린 토큰 생성(최적화된 커널 없음), 메모리 비효율성, 규모 조정/모니터링 부족, 긴 시작 시간으로 제한합니다.

  • 권장 사항: 사용자 지정 로직 통합이 필요한 초기 프로토타이핑 또는 단일 노드 작업에 사용합니다.

전용 모델 서비스 프레임워크(예: TensorRT-LLM, TGI) 사용 ML 추론을 위해 TensorRT-LLM 또는 TGI와 같은 특수 서버를 채택하고 모델 로드, 라우팅 및 최적화를 관리합니다. 이러한는 선택 사항인 컴파일 또는 플러그인과 함께 Safetensor와 같은 형식을 지원합니다.

  • 장점: 일괄 처리(정적/진행 중 또는 연속), 양자화(INT8, FP8, GPTQ), 하드웨어 최적화(NVIDIA, AMD, Intel, Inferentia) 및 다중 GPU 지원(Tensor/Pipeline Parallelism)을 제공합니다. TensorRT-LLM은 다양한 모델(LLMs, Encoder-Decoder)을 지원하는 반면, TGI는 HuggingFace 통합을 활용합니다.

  • 단점: TensorRT-LLM은 컴파일이 필요하며 NVIDIA 전용입니다. TGI는 일괄 처리에서 덜 효율적일 수 있습니다. 둘 다 구성 오버헤드를 추가하고 일부 모델 유형(예: 비변환기)에 맞지 않을 수 있습니다.

  • 권장 사항: A/B 테스트 또는 호환되는 하드웨어를 사용한 높은 처리량과 같은 프로덕션 기능이 필요한 PyTorch/TensorFlow 모델에 적합합니다.

특수한 고처리량 추론 엔진(예: vLLM) 사용 vLLM과 같은 고급 추론 엔진을 활용하여 PagedAttention을 사용한 LLM 서비스, 진행 중인 배치 및 양자화(INT8, FP8-KV, AWQ)를 최적화하고 EKS Auto Scaling과 통합 가능합니다.

  • 장점: 높은 처리량 및 메모리 효율성(40~60% VRAM 절감), 동적 요청 처리, 토큰 스트리밍, 단일 노드 Tensor 병렬 다중 GPU 지원, 광범위한 하드웨어 호환성.

  • 단점: 디코더 전용 변환기(예: LLaMA)에 최적화되어 있고 비변환기 모델에 덜 효과적이므로 호환되는 하드웨어(예: NVIDIA GPUs)와 설정 작업이 필요합니다.

  • 권장 사항: EKS에서 지연 시간이 짧은 대용량 LLM 추론을 위한 최고의 선택으로 확장성과 성능을 극대화합니다.

컨테이너 이미지 사전 캐싱

컨테이너 이미지가 크면(예: PyTorch와 같은 모델) 콜드 스타트 지연이 발생하여 지연 시간에 영향을 미칠 수 있습니다. 가로로 확장되는 실시간 추론 워크로드와 같이 지연 시간에 민감한 워크로드의 경우 빠른 포드 시작이 중요하므로 초기화 지연을 최소화하기 위해 컨테이너 이미지를 미리 로드하는 것이 좋습니다. 가장 적게 권장되는 것부터 가장 권장되는 것까지 다음과 같은 접근 방식을 고려하세요.

컨테이너 런타임 캐시를 사용하여 이미지 미리 가져오기

  • Kubernetes 리소스(예: DaemonSet 또는 배포)를 사용하여 노드에 컨테이너 이미지를 미리 끌어와 노드의 컨테이너 런타임 캐시를 채울 수 있습니다. 컨테이너 런타임 캐시는 레지스트리에서 가져온 후 이미지가 저장되는 컨테이너 런타임(예: [containerd](https://containerd.io/))에서 관리하는 로컬 스토리지입니다. 미리 풀링하면 로컬에서 이미지를 사용할 수 있으므로 포드 시작 중에 다운로드 지연이 방지됩니다. 이 접근 방식은 EBS 스냅샷이 사전 구성되지 않았거나 이미지 사전 풀링이 선호되는 경우에 유용합니다. 사전 풀링 이미지의 예는 [AWS 샘플 GitHub 리포지토리](https://github.com/aws-samples/aws-do-eks/tree/main/Container-Root/eks/deployment/prepull)를 참조하세요. [SOCI Snapshotter](https://github.com/awslabs/soci-snapshotter)(부분 이미지 풀용 컨테이너형 플러그인)를 사용한 지연 로딩과 같은 대안은 사용자 지정 설정이 필요하고 모든 시나리오에 적합하지 않을 수 있지만 이러한 방법을 보완할 수 있습니다. 컨테이너 런타임 캐시 사용에는 다음과 같은 장단점이 함께 제공됩니다.

  • 장점:

    • EBS 스냅샷을 관리할 필요가 없습니다.

    • DaemonSets를 사용하면 항상 최신 컨테이너 이미지 버전을 얻을 수 있습니다.

    • 스냅샷을 다시 생성하지 않고도 이미지를 업데이트할 수 있으므로 더 유연합니다.

    • 여전히 이미지가 이미 노드에 있는지 확인하여 포드 시작 시간을 줄입니다.

  • 단점:

    • 큰 이미지를 처음 가져오는 작업은 미리 완료되었지만 여전히 시간이 걸릴 수 있습니다.

    • 포드 시작 시가 아니더라도 풀링이 여전히 필요하므로 매우 큰 이미지(10GB 이상)의 경우 EBS 스냅샷만큼 효율적이지 않을 수 있습니다.

    • DaemonSets를 사용하면 포드가 실행될 수 있는 모든 노드에 이미지가 미리 풀링됩니다. 예를 들어 1,000개의 노드가 포드의 인스턴스 하나만 실행하고 있는 경우 1,000개의 모든 노드에서 공간이 소비되어 하나의 노드에서 인스턴스 하나를 실행합니다.

    • 노드가 스케일 인/아웃되는 실시간 추론 워크로드의 경우 Cluster Autoscaler와 같은 도구가 추가한 새 노드는 미리 풀링된 DaemonSet가 이미지 풀링을 완료하기 전에 워크로드 포드를 예약할 수 있습니다. 이로 인해 새 노드의 초기 포드가 풀을 트리거하여 시작이 지연되고 지연 시간이 짧은 요구 사항에 영향을 미칠 수 있습니다.

    • Kubelet 이미지 가비지 수집은 디스크 사용량이 특정 임계값을 초과하거나 구성된 최대 미사용 기간을 초과할 때 미사용 이미지를 제거하여 미리 풀링된 이미지에 영향을 미칠 수 있습니다. 스케일 인/아웃 패턴에서는 유휴 노드에서 이미지를 제거할 수 있으므로 후속 스케일 업 중에 다시 풀링하고 버스트 워크로드에 대한 캐시의 신뢰성을 줄여야 합니다.

EBS 스냅샷 사용

  • 캐시된 컨테이너 이미지의 Amazon Elastic Block Store(EBS) 스냅샷을 만들고이 스냅샷을 EKS 작업자 노드에 재사용할 수 있습니다. 이렇게 하면 노드 시작 시 로컬에서 이미지를 미리 가져와 포드 초기화 시간을 줄일 수 있습니다. Karpenter 및 관리형 노드 그룹에 대한이 EKS Terraform 블루프린트를 사용한 자세한 내용은 Bottlerocket 데이터 볼륨을 사용하여 Amazon EKS에서 컨테이너 시작 시간 단축을 참조하세요. 최신 컨테이너 이미지 버전으로 up-to-date 상태를 유지하려면 CI/CD 파이프라인의 일부로 EBS 스냅샷 생성을 자동화하는 것이 좋습니다. EBS 스냅샷 사용에는 다음과 같은 장단점이 함께 제공됩니다.

  • 장점:

    • 포드 시작 시 대용량 컨테이너 이미지를 가져올 필요가 없으므로 시작 시간이 크게 단축됩니다(예: 10GB보다 큰 이미지의 경우 10~15분에서 초).

    • 노드 시작 시 로컬에서 이미지를 사용할 수 있는지 확인합니다.

    • 대용량 컨테이너 이미지가 있는 추론 워크로드에 특히 유용합니다.

  • 단점:

    • 모든 이미지 또는 버전 업그레이드 시 EBS 스냅샷을 유지 관리하고 업데이트해야 합니다.

    • 모든 워크로드가 최신 컨테이너 이미지 버전을 사용하도록 하려면 추가 단계가 필요합니다.

    • 스냅샷을 생성하고 관리하기 위한 추가 운영 활동을 포함합니다.

    • 적절하게 관리되지 않는 경우 불필요한 이미지를 포함할 수 있지만 적절한 노드 풀 구성으로 완화할 수 있습니다.

이미지 풀 성능 최적화

AI/ML 워크로드를 실행하는 Amazon EKS 클러스터의 컨테이너 이미지 풀 성능을 최적화하는 것이 좋습니다. 최적화되지 않은 대규모 기본 이미지 또는 비효율적인 계층 순서를 사용하면 포드 시작 시간이 느려지고 리소스 소비가 증가하며 추론 지연 시간이 저하될 수 있습니다. 이를 해결하려면 워크로드에 맞게 최소한의 종속성을 가진 작고 가벼운 기본 이미지를 채택하십시오. 또한 널리 사용되는 AWS Deep Learning Containers 딥 러닝 컨테이너(DLCs)를 고려할 수 있습니다. PyTorch TensorFlow 사용자 지정 이미지 빌드에 대한 자세한 내용은 딥 러닝 컨테이너 사용자 지정을 참조하세요. 사용자 지정 이미지를 빌드할 때는 경량 기본 이미지를 고려하고 이미지를 린 상태로 유지하는 데 필요한 라이브러리만 추가합니다. 다단계 빌드를 사용하여 계층 크기를 줄이고 효율적인 캐싱을 위해 계층 순서를 최적화합니다. 자세한 내용은 이미지 구축을 위한 Docker 모범 사례를 참조하세요.

컨테이너 이미지를 데이터 볼륨에 미리 로드하여 컨테이너 시작 시간 단축

실시간 추론과 같이 포드 시작 지연 시간이 짧은 기계 학습 워크로드의 경우 초기화 지연을 최소화하기 위해 컨테이너 이미지를 미리 로드하는 것이 좋습니다. 대용량 컨테이너 이미지는 특히 대역폭이 제한된 노드에서 포드 시작 속도를 늦출 수 있습니다. 최소 기본 이미지, 다단계 빌드 및 지연 로드 기술을 사용하는 것 외에도 Amazon EKS에서 이미지를 미리 로드하려면 다음 접근 방식을 고려하세요. 최소 기본 이미지, 다단계 빌드 및 지연 로드 기술을 사용하는 것 외에도 다음 옵션을 고려하세요.

  • EBS 스냅샷을 사용하여 이미지 사전 로드: 캐시된 컨테이너 이미지의 Amazon Elastic Block Store(EBS) 스냅샷을 만들고이 스냅샷을 EKS 작업자 노드에 재사용합니다. 이렇게 하면 추가 운영 활동이 추가되지만 노드 시작 시 이미지를 로컬로 미리 가져와 포드 초기화 시간을 줄일 수 있습니다. Karpenter 및 관리형 노드 그룹에 대한이 EKS Terraform 블루프린트를 사용한 자세한 내용은 Bottlerocket 데이터 볼륨을 사용하여 Amazon EKS에서 컨테이너 시작 시간 단축을 참조하세요.

  • 컨테이너 런타임 캐시로 이미지 미리 가져오기: Kubernetes 리소스(예: DaemonSet 또는 배포)를 사용하여 노드에 컨테이너 이미지를 미리 끌어와 노드의 컨테이너 런타임 캐시를 채웁니다. 컨테이너 런타임 캐시는 레지스트리에서 가져온 후 이미지가 저장되는 컨테이너 런타임(예: 컨테이너식)에서 관리하는 로컬 스토리지입니다. 미리 풀링하면 로컬에서 이미지를 사용할 수 있으므로 포드 시작 중에 다운로드 지연이 발생하지 않습니다. 이 접근 방식은 EBS 스냅샷이 사전 구성되지 않았거나 이미지 사전 풀링이 선호되는 경우에 유용합니다. 스테이징 환경에서이 접근 방식을 테스트하여 지연 시간 개선을 검증합니다. 사전 풀링 이미지의 예는 AWS 샘플 GitHub 리포지토리를 참조하세요.