아래 내용은 인터넷의 관련 글들을 기반으로 분석한 내용으로 틀릴 수도 있습니다.
Amazon EBS(Elastic Block Store)의 아키텍처는 클라우드 컴퓨팅 역사에서 가상화 기술(Hypervisor)의 발전과 궤를 같이합니다.
초기 EBS는 전통적인 하이퍼바이저의 소프트웨어 에뮬레이션에 의존하여 오버헤드가 컸으나, 현대 AWS 아키텍처는 하드웨어 가속 기술인 AWS Nitro System을 통해 하이퍼바이저를 거치지 않는 수준의 극단적인 저지연·고성능 아키텍처를 완성했습니다.
이 기술 분석 글에서는 전통적인 가상화 구조(Xen/Dom0)와 현대의 Nitro System 기반 가상화 구조를 비교하여 EBS 아키텍처가 하이퍼바이저와 어떻게 연계되고 최적화되었는지 분석합니다.
1. Legacy 가상화 아키텍처와 EBS (Xen Hypervisor & Dom0)
과거 AWS가 Xen 하이퍼바이저를 사용하던 시절, EC2 인스턴스(Guest OS)에서 발생한 EBS I/O 요청은 매우 복잡한 소프트웨어 소프트웨어 레이어를 통과해야 했습니다.
- 스플릿 드라이버 모델 (Split Driver Model): Guest OS는 I/O를 처리하기 위해 가상 디바이스 드라이버인 Frontend Driver를 사용합니다. 이 요청은 하이퍼바이저 영역을 넘어 관리 OS인 Dom0의 Backend Driver로 전달됩니다.
- Dom0의 병목 현상: Dom0는 호스트 CPU 자원의 일부를 공유하여 소프트웨어 기반으로 네트워크 패킷 캡슐화, EBS 볼륨 암호화, I/O 스케줄링 등을 전부 처리했습니다.
- CPU Context Switch 오버헤드: Guest VM에서 Dom0로 컨텍스트 스위칭이 빈번하게 일어나면서 가상화로 인한 CPU 패널티(Overhead)와 I/O 지연 시간(Latency Jitter)이 발생했습니다.
2. 현대 AWS Nitro System과 EBS 아키텍처 연계
AWS는 이러한 가상화 병목을 완전히 해결하기 위해 Nitro System을 개발했습니다. Nitro 가상화 환경에서 EBS I/O는 하이퍼바이저의 소프트웨어 연산 부하를 제로(Zero)에 가깝게 구현합니다.
① Nitro Card for EBS (하드웨어 오프로드)
Nitro 아키텍처에서 EBS 통신은 메인 CPU가 아닌 전용 ASIC/SoC가 탑재된 Nitro Card for EBS가 전담합니다.
- NVMe 컨트롤러 에뮬레이션: Nitro Card는 메인보드의 PCIe 버스를 통해 호스트 시스템에 물리적인 표준 NVMe 컨트롤러로 인식됩니다.
- Zero-Copy 및 직결: Guest OS는 가상 디바이스 드라이버 대신, 커널에 내장된 고성능 표준 NVMe 드라이버를 통해 PCIe 버스로 Nitro Card에 직접 I/O 명령을 내립니다. 이 과정에서 하이퍼바이저의 개입이나 Dom0로의 데이터 복사(Zero-copy)가 필요 없습니다.
- 라인 레이트(Line-rate) 암호화: EBS 암호화 옵션을 사용할 경우, 메인 CPU의 자원을 1%도 쓰지 않고 Nitro Card의 전용 하드웨어 엔진이 실시간으로 AES-256 암·복호화를 처리합니다.
② Nitro Hypervisor의 최소 역할
Nitro 가상화 환경에서 하이퍼바이저는 CPU와 메모리 할당 영역만 관리하는 극도로 경량화된 형태(KVM 기반)로 축소되었습니다.
- Passive 가상화 통신: EBS 볼륨이 인스턴스에 Attach될 때, Nitro Controller가 하이퍼바이저에게 PCIe Virtual Function(가상 기능)을 가상머신(VM)에 할당하라고 명령합니다.
- 가상머신 내부에는 하드웨어 핫플러그(Hot-plug) 이벤트만 발생하며, 일단 연결이 완료되면 EBS I/O 트래픽은 하이퍼바이저 코드를 전혀 거치지 않고 PCIe 파이프라인을 통해 가동됩니다.
3. EBS 네트워크 패브릭과 하이퍼바이저의 결합
EBS는 네트워크 기반 블록 스토리지이므로, Nitro Card를 통과한 I/O 데이터는 물리 네트워크망을 타고 실제 스토리지 서버(EBS Media 서버)로 전송되어야 합니다. 이 구간에서도 독보적인 네트워크 프로토콜 최적화가 적용되어 있습니다.
- SRD (Scalable Reliable Datagram) 프로토콜: AWS는 과거 TCP 프로토콜이 가졌던 병목(Head-of-Line Blocking 등)을 해결하기 위해 자체 개발한 고성능 전송 프로토콜인 SRD를 EBS 전송 패브릭에 도입했습니다.
- 멀티패스(Multipathing)와 빠른 복구: SRD는 대규모 데이터 센터 내 수천 개의 네트워크 경로로 패킷을 분산 전송(Packet Spraying)하여 네트워크 혼잡으로 인한 꼬리 지연 시간(Tail Latency)을 극도로 최소화합니다. 이 정교한 제어 역시 Nitro Card 하드웨어 내부에서 완결됩니다.
4. 아키텍처 비교 요약
전통적인 가상화와 현대 Nitro 기반 가상화에서의 EBS I/O 라이프사이클 차이는 다음과 같습니다.
| 비교 항목 | Legacy (Xen 기반 아키텍처) | Modern (Nitro 기반 아키텍처) |
| I/O 처리 주체 | 소프트웨어 에뮬레이션 (Xen Dom0) | 전용 전용 실리콘 하드웨어 (Nitro Card) |
| 디바이스 인터페이스 | PV (Paravirtualized) Block 드라이버 | 하드웨어 에뮬레이션된 표준 NVMe (PCIe) |
| CPU 자원 오버헤드 | Dom0 운영을 위해 호스트 CPU 일부 상시 점유 | 호스트 CPU 소모 0% (가상머신에 100% 자원 할당) |
| 데이터 암호화 | Dom0 커널 소프트웨어 암호화 (CPU 점유 증가) | Nitro Card 내부 전용 하드웨어 암호화 (패널티 없음) |
| 전송 프로토콜 | 표준 TCP/IP | AWS SRD (Scalable Reliable Datagram) |
결론 및 분석 시사점
현대 AWS EBS 아키텍처의 핵심은 "가상화 오버헤드의 하드웨어 오프로딩"입니다.
과거에는 하이퍼바이저와 Dom0라는 가상화 레이어가 물리 자원과 가상 머신 사이에서 거대한 중재자 역할을 하며 병목을 유발했으나, Nitro System은 이 중재 작업을 특화된 전용 하드웨어 칩셋(Nitro Card)으로 완벽하게 이관했습니다.
이 덕분에 가상머신의 하이퍼바이저는 단순 CPU/Memory 스케줄러 수준으로 가벼워졌으며, EBS는 가상화 환경임에도 불구하고 베어메탈(Bare-metal) 서버에서 로컬 NVMe SSD를 직접 사용하는 수준에 준하는 극저지연, 고대역폭 성능을 안정적으로 제공할 수 있게 되었습니다.