[네이버클라우드 기술&경험] 가상화 개념 이해하기#2, SPDK와 NVMe-oF 알아보기
이번 시간에는 Part.1 후반부에 언급한 I/O 가상화에 이어서 스토리지 I/O의 성능을 높이기 위해 등장한 SPDK*에 대해 소개하는 시간을 가져보도록 하겠습니다. 후반부에는 여기서 한발 더 나아가, 최근 SDDC**에서 자주 언급되는 기술인…
[네이버클라우드 기술&경험] 가상화 개념 이해하기#2, SPDK와 NVMe-oF 알아보기
이번 시간에는 Part.1 후반부에 언급한 I/O 가상화에 이어서 스토리지 I/O의 성능을 높이기 위해 등장한 SPDK에 대해 소개하는 시간을 가져보도록 하겠습니다. 후반부에는 여기서 한발 더 나아가, 최근 SDDC에서 자주 언급되는 기술인 NVMe-oF에 대해서도 알아보도록 하겠습니다.
*SPDK: Storage Performance Development Kit
**SDDC: Software Defined DataCenter
***NVMe-oF: NVMe Over Fabrics
목차
1. SPDK
1.1 Overview
1.2 Simple Test
1.3 Legacy vs SPDK
2. NVMe-oF
2.1 Overview
2.2 RDMA
2.3 iWARP vs RoCEv2
1. SPDK
1.1 Overview
SPDK는 User space에서 사용하는 스토리지 I/O 가속 솔루션입니다. 개발용 라이브러리, 가상머신용 vhost 등 다양한 사용 모델을 제공하고 있으며 iSCSI, NVMe-oF를 위한 모듈도 지원하고 있습니다.
[그림 1] 원본 출처 바로 가기
가상머신에서 발생하는 I/O의 경우 지난 시간에 알아본 KVM의 vhost (이하 k-vhost)가 범용적으로 사용되어 왔습니다. 네트워크는 k-vhost-net, 스토리지는 k-vhost-scsi, k-vhost-blk 등이 있습니다. 하지만 인터럽트 기반의 복잡한 호출 구조를 가지고 있고, memcpy나 lock이 다수 존재하여 성능의 한계가 분명히 존재합니다.
SPDK는 이러한 문제를 해결하기 위해 User space에서 Polling mode로 동작하는 vhost (이하 u-vhost)를 제안하고 있습니다. 대표적인 특징을 키워드로 나열하면 아래와 같습니다.
- User Space
- Kernel Bypass
- Zero Copy Access
- Polling Mode
- Avoid All Locks in I/O Path
- Asynchronous
u-vhost의 Polling mode는 k-vhost와 대비되는 특징으로써 코어가 I/O 발생 즉시 이를 처리하여 Latency를 획기적으로 단축시킬 수 있습니다. 또한 커널을 우회하여 memcpy, lock 등과 같은 성능 저하의 원인들이 제거됩니다. 이러한 k-vhost와 u-vhost의 성능 차이는 [그림 2]에 나타난 것처럼 FIO를 이용한 Random read 테스트를 통해 알 수 있습니다.
[그림 2] Ziye Yang, SPDK Vhost-NVMe: Accelerating I/Os in Virtual Machines on NVMe SSDs via User Space Vhost Target (IEEE, 2018)
Single VM인 경우 k-vhost-scsi와 u-vhost-scsi의 IOPS는 3배 이상 차이가 나는 것을 확인할 수 있으며 VM의 개수가 늘어나서 8 VM인 경우에도 2배에 가까운 성능 차이를 보이고 있습니다.
1.2 Simple Test
SPDK의 동작을 간단하게 테스트해보기 위해 [그림 3]과 같이 두 가지 환경을 꾸며보았습니다. 호스트 머신(노트북)에 VirtualBox를 설치하고, VT-d를 활성화시킨 후 가상 머신 생성한 다음 그 내부에서 다시 한번 KVM을 이용하여 VM을 띄우는 방식(Nested VM)을 사용했습니다. VirtualBox의 경우 SSD, NVMe와 같은 디바이스 에뮬레이션을 제공해 주고 있어서 SPDK 드라이버의 기본적인 동작을 확인하는 것이 매우 용이하였습니다.
[그림 3] Local Test 환경
[그림 4] QEMU-virtio, SPDK u-vhost 성능 비교
성능 테스트 도구는 FIO*를 이용하였으며 2MB 파일을 4K 단위로 Random Read를 수행하였습니다. QEMU의 virtio scsi 및 SATA SSD를 이용한 경우 IOPS는 573, BW는 2348 kB/s였으며 SPDK u-vhost-scsi의 경우 IOPS는 989, BW는 4055 kB/s였습니다.
저장 장치 컨트롤러 (SATA, NVMe)가 에뮬레이션 되었으므로 절대적인 수치는 물리 장비에 비해 크게 떨어지지만 상대적인 성능 차이를 확인할 수 있었으며, SPDK 드라이버의 동작 방식을 분석할 수 있었습니다.
*FIO: Flexible I/O Tester, 리눅스의 디스크 성능 측정 도구
1.3 Legacy vs SPDK
SPDK는 앞서 설명드린 것처럼 VM 내부의 반가상화 Storage I/O 가속을 위해 virtio-scsi, virtio-blk, virtio-NVMe와 같은 인터페이스에 대한 back-end 처리를 지원합니다. 호스트 머신의 저장 장치가 NVMe SSD라고 가정했을 때 I/O를 처리하는 방식에 있어서 Legacy virtio, k-vhost 및 u-vhost의 차이점은 [그림 5]와 같습니다.
![[그림 5] Ziye Yang, SPDK Vhost-NVMe: Accelerating I/Os in Virtual Machines on NVMe SSDs via User Space Vhost Target, IEEE, 2018]](https://miro.medium.com/v2/resize:fit:567/0*W71zN7cF67wk0gC0)
[그림 5] Ziye Yang, SPDK Vhost-NVMe: Accelerating I/Os in Virtual Machines on NVMe SSDs via User Space Vhost Target, IEEE, 2018]
먼저 전통적인 Virtio의 경우 User space의 virtio backend가 이를 처리합니다. 때문에 KVM 과의 Mode Switching Overhead를 발생시키며 이는 곧 성능의 저하로 이어지게 됩니다. 가상 머신이 여러 개 생성될 경우 Scalability 이슈도 함께 발생하게 되며, 이를 해결하기 위한 것이 바로 k-vhost입니다. Virtio back-end 역할을 vhost가 커널에서 직접 수행함으로써 Mode Switching Overhead를 감소시키며 Scalability 문제도 함께 해결하는 구조입니다. 하지만 여전히 인터럽트 기반의 복잡한 호출 구조로 인해 성능의 한계가 존재합니다.
[그림 5]의 ©에서 볼 수 있듯 SPDK는 vhost 모듈을 User space로 끌어올린 후 호스트 머신에 장착된 물리 저장 장치 (e.g., NVMe SSD)에 직접 접근하며, 가상머신에서 발생하는 I/O를 직접 처리하여 이를 KVM에 알려주는 방식으로 동작합니다.
2. NVMe-oF
2.1 Overview
본 절에서는 앞서 살펴본 SPDK에서 한발 더 나아가 최근 많은 연구결과가 쏟아지고 있는 NVMe-oF에 대해 알아보도록 하겠습니다. NVMe-oF는 PCIe에 장착하여 사용하는 SSD인 NVMe를 Remote로 접근하는 방식을 의미합니다. NVMe-oF는 원격 NVMe에 접근하기 위해 Ethernet, Infiniband와 같은 네트워크 위에서 동작하게 됩니다.
저장 장치를 원격으로 접근함으로써 얻게 되는 가장 큰 변화는 클라우드 환경에서의 Compute Node과 Storage Node 간의 물리적 의존성 제거입니다. 이를 통해 얻을 수 있는 장점은 크게 세 가지입니다.
- Resource Efficient Scale In/Out
- Easy Migration
- Fault Tolerance
Computing 자원과 Storage 자원이 결합되어 있는 경우 어느 한쪽의 부족으로 인해 Scale out이 되면 불필요한 자원이 함께 증가합니다. 하지만 물리적 의존성이 제거될 경우 부족한 자원만 선택적으로 Scale out을 할 수 있습니다.
또한 Live Migration과 같이 가상머신이 다른 Node로 이동하는 경우 공통의 Remote Storage를 사용한다면 Computing 자원만 Migration하면 되므로 Disk에 저장된 File 복제에 대한 부하는 제거됩니다. 즉 이를 통해 발생하는 네트워크 부하가 획기적으로 줄어들기 때문에 Migration에 걸리는 시간도 대폭 줄어들게 됩니다.
장애의 경우에도 Computing Node에 Fault가 발생하는 경우 Storage는 영향을 받지 않으므로 빠르게 복구가 가능합니다. 반대의 경우도 마찬가지이므로 장애에 효과적인 대처가 가능해집니다.
2.2 RDMA
본 절에서는 앞에서 소개해드린 NVMe-oF와 함께 많이 사용되는 RDMA에 대해 간단하게 정리해보겠습니다. RDMA는 한 컴퓨터의 메모리에서 다른 컴퓨터의 메모리에 직접 접근하는 방법을 의미합니다.
이 방식의 가장 큰 장점은 CPU Utilization을 획기적으로 감소시킬 수 있다는 것입니다. 앞 장에서 Computing과 Storage가 Disaggregate 되었을 때 많은 장점이 생긴다고 말씀드렸는데요, 이와 더불어 RDMA를 함께 사용하게 되면 [그림 6]과 같이 Compute Node가 Remote Storage의 정보를 자신의 메모리에 CPU를 거치지 않고 바로 가져올 수 있게 됩니다. 따라서 Compute Node에서 생성되는 가상머신이 더 많은 물리 CPU를 활용할 수 있게 됩니다. 하지만 RDMA를 사용하기 위해서는 이를 지원하는 NIC과 Driver가 필요하므로 도입을 위해서는 이러한 하드웨어의 지원 여부를 반드시 확인해야 합니다.
[그림 6] 원본 출처 바로 가기
RDMA를 사용하는 Storage 프로토콜은 NVMe-oF 외에도 SRP (Storage RDMA Protocol), iSER (iSCSI Extension for RDMA) 등 다양한 구현체가 있지만 Mellanox의 경우 성능이 뛰어난 NVMe-oF를 개발 표준으로 공표하고 있으며 업계의 흐름도 크게 다르지 않은 것으로 보입니다.
2.3 iWARP vs RoCEv2
본 절에서는 앞서 살펴본 NVMe-oF, RDMA를 Ethernet 상에서 동작할 수 있게 구현한 iWARP, RoCEv2 프로토콜에 대해 알아보겠습니다. 설명에 앞서서 [그림 7]에서 볼 수 있듯이 NVMe-oF는 RDMA를 사용할 수도 있고, 그렇지 않을 수 있으며 Ethernet, Infiniband, Fibrae Channel 등 다양한 통신 프로토콜 위에서 동작할 수 있습니다. 하지만 데이터 센터에서 매우 범용적으로 사용되는 Ethernet을 기반으로 NVMe-oF를 구현하고, RDMA를 함께 적용하고자 한다면 사용 가능한 프로토콜은 iWARP와 RoCEv2 두 가지로 좁혀집니다.
[그림 7] 원본 출처 바로 가기
먼저 RoCEv2부터 살펴보겠습니다. RoCE는 RDMA over Converged Ethernet의 약자입니다. 이 프로토콜은 Ethernet을 통해 IB 전송 패킷을 캡슐화하여 RDMA를 수행합니다. v1, v1.5, v2가 순서대로 발표되었으며 RoCEv2에서는 UDP를 기반으로 개발되었습니다. 이 때문에 TCP에서 수행하는 Congestion Control, Retransmission이 없으므로 Packet Loss에 매우 취약합니다.
이를 보완하기 위해 RoCEv2는 DCB (Data Center Bridging)에 의존합니다. DCB는 Ethernet 환경에서 Lossless를 구현하기 위한 표준의 집합이며 PFC (Priority-based Flow Control), ETS (Enhanced Transmission Selection), DCBX (Data Center Bridging eXchange)로 구성되어 있습니다. 즉 Underlay 환경에서 스위치와 NIC에 이러한 구성을 설정해 주어야 RoCEv2 사용 시 패킷의 유실을 막을 수 있습니다.
결과적으로 RoCEv2는 위와 같은 DCB 환경을 벗어나는 구간에 대해서는 패킷이 유실될 수 있으므로 확장성이 제한되지만 바로 다음에 소개해드릴 iWARP에 비해서는 Bandwidth 및 Latency에 대해 좋은 성능을 보이고 있습니다.
[그림 8] 원본 출처 바로 가기
RoCEv2와는 다르게 iWARP는 TCP를 기반으로 하여 DCB에 대한 종속성을 제거하였습니다. TCP의 Congestion Control 및 Retransmission을 통해 Underlay 환경의 변화 없이 즉시 도입이 가능합니다. 하지만 TCP Stack의 복잡성으로 인해 RoCEv2에 비해서는 성능이 떨어집니다. Latency Benchmark로 성능 측정 시 2048 Bytes 패킷을 기준으로 iWARP는 약 10 us, RoCEv2는 약 2 us의 성능을 보입니다.
[그림 9] 원본 출처 바로 가기
지금까지 SPDK, NVMe-oF, RDMA, iWARP 및 RoCEv2에 대해 알아보았습니다. 가장 먼저 User Space 기반 Storage I/O 가속 솔루션인 SPDK를 소개 드리면서 가상머신의 I/O backend로 사용되는 u-vhost에 대해 설명드렸습니다. 이후 NVMe-oF, RDMA의 개념을 설명드리고 마지막으로 iWARP와 RoCEv2를 비교해보았습니다. 이들을 이용하여 Underlay와 Overlay에 대한 Storage 네트워크를 설계한다면 고성능의 신뢰성 높은 클라우드 환경을 구축할 수 있을 것으로 생각됩니다.
이렇게 총 2회차에 걸쳐 가상화 기술에 대해 알아보았습니다.
Part.1에서는 가상화 기본 개념과 I/O 가상화의 작동 원리를,
Part.2에서는 SPDK를 설명해드렸는데 어떠셨나요?
도움이 되셨기를 바라며, 더 유익한 포스팅으로 찾아올 수 있도록 노력하겠습니다. 감사합니다!
메타데이터
- post_id
- 6eae4ef1dd4c
- slug
- 네이버클라우드-기술-경험-가상화-개념-이해하기-2-spdk와-nvme-of-알아보기-6eae4ef1dd4c
- url
- https://medium.com/naver-cloud-platform/%EB%84%A4%EC%9D%B4%EB%B2%84%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B8%B0%EC%88%A0-%EA%B2%BD%ED%97%98-%EA%B0%80%EC%83%81%ED%99%94-%EA%B0%9C%EB%85%90-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-2-spdk%EC%99%80-nvme-of-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-6eae4ef1dd4c
- canonical_url
- https://medium.com/naver-cloud-platform/%EB%84%A4%EC%9D%B4%EB%B2%84%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B8%B0%EC%88%A0-%EA%B2%BD%ED%97%98-%EA%B0%80%EC%83%81%ED%99%94-%EA%B0%9C%EB%85%90-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-2-spdk%EC%99%80-nvme-of-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0-6eae4ef1dd4c
- author_url
- https://medium.com/@navercloudplatform
- status
- ok
- fetched_at
- 2026-07-28 17:41:00