본문 바로가기

DevOps

[AWS EKS] (29) EKS 스터디 11주차 ( AWS EKS ML Infra(GPU) )

CloudNet@팀의 EKS 스터디 AEWS 2기에 작성된 자료를 토대로 작성합니다.
  1. AI/ML 인프라의 GPU를 사용하는 워크로드들에 대해서 과거 사용하던 방식들에 대해 이해 하려 합니다.
  2. 컨테이너의 장점을 통해 GPU 사용을 용이하게 하는 방식에 대해 이해하려 합니다.

AI/ML 인프라에 대한 문제점 

머신러닝과 딥러닝이 기업의 핵심 경쟁력으로 부상하면서, 데이터 과학자들은 점점 더 복잡하고 계산 집약적인 모델을 개발하고 있다. 이러한 모델을 효율적으로 학습하고 배포하기 위해서는 강력한 컴퓨팅 인프라가 필수적입니다. 특히 GPU를 사용하는 것은 병렬 처리 능력으로 딥러닝 워크로드를 가속화하는 데 있어 중요한 역할을 한다.

  • 전통적으로 ML 엔지니어들은 베어메탈 서버에 직접 GPU 드라이버와 라이브러리를 설치하여 작업하였다.
  • 이 접근 방식은 몇 가지 심각한 문제점을 가지고 있었다
    • 환경 구성의 복잡성: CUDA, cuDNN 등 복잡한 드라이버 스택 설치 및 관리가 필요. 특히 버전 호환성 문제로 인해 특정 프레임워크(TensorFlow, PyTorch)가 특정 CUDA/cuDNN 버전만 지원하는 경우가 많았음.
    • 재현성 부족: 동일한 실험 환경을 다른 시스템에서 재현하기 어려움. '내 컴퓨터에서는 잘 작동하는데요?.'와 같은 이야기를 많이 들을 수 있었음.
    • 리소스 비효율성: 고가의 GPU 리소스가 특정 사용자나 프로젝트에 고정되어 활용도가 저하. (베어메탈 GPU 서버의 활용률은 30% 미만인 경우가 많았음)
    • 확장성 제한: 대규모 분산 학습을 위한 인프라 확장이 어려웠음. 새로운 GPU 서버를 추가할 때마다 동일한 환경 구성 과정을 반복 필요.

AI/ML 인프라에 대한 문제점 -> 컨테이너의 장점 도입

컨테이너 기술은 주로 두 가지 핵심 Linux 커널 기능에 의존한다:

  • Cgroups (Control Groups): 프로세스 그룹의 리소스 사용(CPU, 메모리, 디스크 I/O, 네트워크 등)을 제한하고 격리하는 메커니즘
  • Namespaces: 프로세스가 시스템의 특정 리소스만 볼 수 있도록 격리하는 기능 Linux는 여러 유형의 네임스페이스(PID, 네트워크, 마운트, UTS, IPC, 사용자 등)를 제공

https://www.youtube.com/watch?v=el7768BNUPw

 

https://medium.com/techbeatly/container-internals-deep-dive-5cc424957413 , https://blog.omoknooni.me/81

AI/ML 인프라에 대한 문제점 -> 컨테이너의 장점 도입-> 한계점

  • 물리적으로 분할하기 어려운 GPU: CPU 코어나 메모리와 달리, 초기 GPU는 물리적으로 분할하여 여러 컨테이너에 할당하기 어려웠음 (최근에는 MIG 기술로 개선됨 - Nvidia GPU A100에서 새롭게 생긴 기능, 2020년 등장)
  • GPU 드라이버 복잡성: GPU 접근은 복잡한 사용자 공간 라이브러리와 커널 드라이버를 통해 이루어짐
  • 장치 파일 접근 제어: /dev/nvidia* 과 같은 장치 파일에 대한 접근을 안전하게 관리 필요

컨테이너 환경에서의 GPU 리소스 사용 진화 (단일 GPU)

✅  Passthrough 방식이란?

GPU Passthrough물리 서버(호스트)에 장착된 GPU를 하나의 가상 머신(또는 컨테이너)에 직접 할당하는 방식이에요.
이 방식에서는 GPU 리소스가 전용으로 할당되기 때문에, 해당 GPU는 다른 VM이나 컨테이너가 공유해서 사용할 수 없습니다.

 

✅ VMware 에서 Passthrough 방식 사용 예시 (Kubernetes 환경에서 단일 GPU 할당)

 
  • 가상머신 또는 컨테이너 내부에  NVIDIA Device Plugin이 설치된 상태여야 함 
  • 가상머신 또는 pod가 단일 GPU를 전용으로 사용하도록 요청하는 예입니다.
  • 이 경우, K8s는 GPU를 다른 파드와 공유하지 않고 하나의 pod 또는 VM 에만 할당합니다.
  • 거의 native 수준의 성능을 보임 

✅ 장점 vs 단점

장점

  • 최고의 성능: 거의 로우 레벨 수준의 접근
  • 드라이버 레벨 제어 가능: 특정 GPU 기능 활용 가능 (예: Tensor Core)

단점

  • 자원 낭비 가능성: GPU가 해당 VM 또는 컨테이너 전용이기 때문에 미사용 시간에도 리소스를 점유
  • 확장성 제한: GPU 자원을 여러 컨테이너에 유연하게 나누기 어려움
  • 멀티 사용자 환경 비효율적

MIG와 vGPU 구분 하기 

MIG (Multi-Instance GPU)                                                         vGPU (Virtual GPU)

기술 개념 GPU를 하드웨어 수준에서 여러 인스턴스로 분할 GPU를 소프트웨어 기반으로 시간 공유(time-sharing) 하여 가상화
지원 GPU Ampere 아키텍처 이상 (예: A100) 에서만 지원 대부분의 NVIDIA GPU에서 지원 가능
격리 수준 메모리, 캐시, SM 등 완전 하드웨어 격리 메모리는 논리적으로 분리, 연산은 time-sharing
리소스 공유 방식 고정된 물리 자원을 분리하여 각 인스턴스에 할당 동일한 물리 자원을 시간 분할하여 여러 VM이 공유
동시 사용 가능 인스턴스 A100 기준 최대 7개 (구성 조절 가능) 수십 개 이상의 vGPU 생성 가능
성능 예측 가능성 매우 높음 – 자원 격리로 인해 성능 일관성 보장 낮음 – 타 VM의 부하에 따라 성능 변동 가능
오버헤드 매우 낮음 – 하드웨어 분할 방식 상대적으로 높음 – context switching 등으로 인한 성능 손실 가능
동적 확장/변경 가능 – MIG 인스턴스를 실시간으로 조절 및 재구성 가능 불가 – VM 생성 시 설정한 vGPU 리소스는 고정
적합한 워크로드 고정된 성능이 필요한 AI 추론, MLOps, 멀티테넌트 환경 유연성이 필요한 데스크탑 가상화(VDI), 일반 연산용 VM 환경
대표 사용 사례 클라우드 서비스 제공자(CSP), 모델 호스팅 플랫폼 기업 내 VDI, GPU가 필요한 개발 테스트 환경
라이선스 요구 MIG 사용 자체는 라이선스 필요 없음 (NVIDIA 드라이버 필요) vGPU 소프트웨어 라이선스가 별도로 필요