🚀 베어메탈 vs 가상머신: 컨테이너를 위한 최적의 아키텍처는?

[cloudbro-radar]

현대적인 애플리케이션을 구축하고 실행하는 것은 베이스라인으로 쿠버네티스(Kubernetes) 배포판을 선택하는 것에서 시작하고, 플랫폼 팀이 오케스트레이션 계층을 선택하고 나면, 다음으로 마주하는 아키텍처 선택 중 하나는 해당 클러스터가 실행될 배포 아키텍처입니다.

컨테이너는 베어메탈(Bare Metal) 서버에 직접 배포하거나 가상머신(Virtual Machines, VMs) 위에 배포할 수 있습니다.

이 번 글에서는 베어메탈과 가상머신에 컨테이너를 배포할 때의 특징, 트레이드오프(Tradeoffs), 그리고 커뮤니티에서 얻은 교훈을 살펴봅니다.

1. 베어메탈 상에서 컨테이너를 실행하는 것은 최대 성능과 최소한의 인프라 오버헤드를 우선시하는 조직들에게 매력적이었습니다. 하이퍼바이저 계층을 우회함으로써 컨테이너가 컴퓨팅 및 스토리지 리소스에 직접 액세스할 수 있었기 때문입니다.

2. 하지만 하이퍼바이저 기술의 발전은 가상화 환경의 성능과 효율성을 크게 향상시켰으며, 이제는 가상머신(VM) 위의 컨테이너도 운영상의 이점과 유연성을 갖춘 프로덕션 워크로드로 충분히 실행 가능하게 되었습니다.

최근 몇 년간 IT 요구사항이 증가함에 따라 플랫폼 팀은 더 엄격한 보안 정책 적용, 애플리케이션 가용성을 높이기 위한 장애 도메인(Fault Domain) 축소, 여러 버전의 쿠버네티스 지원, 그리고 더 타이트한 서비스 수준 계약(SLA) 준수 등 확대된 책임을 맡게 되었습니다. 이는 CNCF의 TAG Runtime 및 TAG Security에서도 멀티테넌시 모델, 워크로드 격리, 수명주기 관리와 관련하여 자주 논의되는 주제입니다.

이러한 현대적인 요구 사항과 기술 발전으로 인해, 클러스터를 어디에서 실행해야 하며 플랫폼 팀이 SLA, 보안, 멀티 버전 요구 사항을 어떻게 충족할 수 있을지에 대한 커뮤니티의 논의가 다시 활발해지고 있습니다.

IT 실무자들은 이 결정을 내릴 때 고려해야한 요소는 다음과 같습니다.

1. 성능 (Performance)

   • 역사적으로 베어메탈은 성능 우위를 점했습니다. 하드웨어에 직접 액세스하여 지연 시간(Latency)과 오버헤드를 줄였기 때문에 CPU나 GPU 집약적인 워크로드에서 유리했습니다. 하지만 최근 벤치마크 연구에 따르면 베어메탈과 가상화 환경 간의 성능 격차는 이제 무시할 수 있는 수준입니다.
   • MLPerf 벤치마크 테스트에 따르면, VM 플랫폼에서 실행되는 컨테이너는 vGPU를 사용하는 AI/ML 워크로드에 대해 베어메탈 성능의 최대 99%를 유지할 수 있습니다. KServe, Kubeflow, Volcano와 같은 AI/ML 중심의 CNCF 프로젝트에서 플랫폼 팀은 워크로드 유형과 스케줄링 요구 사항에 따라 베어메탈과 가상화 환경을 모두 운영하는 것이 일반적입니다.

2. 다중 호환 쿠버네티스 버전 (Multiple Conformant Kubernetes Versions)

   • 베어메탈 환경은 일반적으로 호스트당 하나의 쿠버네티스 버전만 지원합니다. 이와 대조적으로 VM 상의 컨테이너는 호스트당 여러 쿠버네티스 버전을 허용하여 호스트 활용도를 높이고, 효율적인 용량 계획(Capacity Planning)을 가능하게 하며, 더 유연한 업그레이드 경로를 지원합니다.

   • 운영상의 이점으로는 동일한 물리적 클러스터에 있는 모든 애플리케이션 클러스터를 업데이트할 필요 없이, 특정 애플리케이션 클러스터의 쿠버네티스 버전만 업데이트할 수 있다는 점이 있습니다.

3. 보안 및 격리 (Security and Isolation)

   • 네임스페이스(Namespace)는 보안 경계 역할을 하도록 설계되지 않았습니다. 베어메탈의 핵심적인 문제는 네임스페이스가 강력한 보안이나 격리 경계를 생성하지 않는다는 것입니다. 이는 쿠버네티스 클러스터 내의 모든 컨테이너가(심지어 서로 다른 네임스페이스에 있더라도) 결국 동일한 호스트 커널을 공유하기 때문입니다.

   • 즉, 한 컨테이너가 침해당하면 공유된 기본 운영 체제로 인해 다른 컨테이너에 영향을 미칠 가능성이 있습니다. 보안(측면 이동 공격 방지), 규정 준수, 멀티테넌시(다양한 워크로드와 테넌트의 안전한 호스팅)를 위해서는 더 강력한 격리가 필수적입니다. VM 기반 환경은 각 가상 머신이 고유한 커널로 작동하므로 워크로드에 대해 강화된 격리를 제공합니다.

   • VM에서 컨테이너를 실행하면 워크로드 격리가 강화되고 교차 테넌트 간의 영향 범위(Blast Radius)가 줄어듭니다. 이 주제는 조직들이 멀티테넌트 플랫폼 엔지니어링 모델을 채택함에 따라 CNCF TAG Security 논의에서 반복적으로 강조되는 사항입니다.

4. 리소스 보장 및 SLA (Resource Guarantees and SLAs)

   • 베어메탈 구성에서 네임스페이스는 “소프트(Soft)” 리소스 제한을 적용하므로, 다른 워크로드가 리소스를 필요로 할 때 제한이 초과될 수 있습니다. CPU와 메모리가 컨테이너에 할당되더라도 가용성이 보장되지는 않습니다.

   • VM 기반 배포의 컨테이너는 하이퍼바이저 수준에서 “하드(Hard)” 리소스 제한을 적용하며, 할당된 리소스는 시스템 수요와 관계없이 예약되어 다른 워크로드가 사용할 수 없습니다. 이는 소위 “노이지 네이버(Noisy Neighbor)” 문제도 해결합니다. 이 모델은 더 예측 가능한 스케줄링을 제공하며 플랫폼 팀이 내부 SLA를 충족하기 쉽게 만듭니다.

5. 올바른 아키텍처 선택하기 (Choosing the right architecture)

   • 현대적인 하이퍼바이저는 격리, 버전 유연성, 네이티브에 가까운 성능을 제공하므로 많은 조직이 멀티테넌트 플랫폼을 위해 VM 기반 쿠버네티스를 표준으로 채택하고 있습니다.
   • 베어메탈 배포는 매우 특수하거나 지연 시간에 극도로 민감한 사용 사례에서 그 자리를 지킬 것입니다.

인프라 전략이 진화함에 따라 플랫폼 팀은 가상화, 베어메탈, GPU 풍부 환경의 어떤 조합이 운영, 성능, 거버넌스 요구 사항에 가장 잘 부합하는지 평가하고 있습니다.

수십억 개의 컨테이너를 호스팅하는 주요 퍼블릭 클라우드 제공업체들은 관리형 쿠버네티스 서비스를 베어메탈이 아닌 VM 기반 인프라에서 실행하는 의도적인 선택을 했습니다. 이는 대부분의 워크로드에서 성능 동등성을 유지하면서도, 엄격한 격리, 보안, SLA를 충족하고 규모에 맞게 테넌트 전반에 걸쳐 여러 쿠버네티스 버전을 지원하기 위함입니다.

[출처] An architectural decision: Containers on bare metal or on virtual machines | CNCF