💾 NAND

ZNS OpenChannelSSD Analysis

ZNS · Open-Channel SSD 상세 분석

Host-Managed Flash · Zone Write Pointer · Zone Append · FTL Offload · Log-Structured Software

개요

전통 SSD는 NAND의 복잡성을 블록 인터페이스 뒤에 숨기지만, 그 대가로 GC와 write amplification, tail latency가 호스트 입장에서 불투명해집니다. 본 문서는 이를 완화하기 위한 Open-Channel SSD와 ZNS(Zoned Namespace)의 설계 철학, 인터페이스, 소프트웨어 스택 변화를 비교합니다.

Open-Channel SSD는 물리 주소와 배치 책임을 호스트 쪽으로 크게 옮기고, ZNS는 NVMe 표준 안에서 zone과 write pointer만 노출해 호스트가 append와 reclaim 정책을 더 잘 맞출 수 있게 합니다. 두 방식 모두 데이터 수명과 갱신 패턴을 가장 잘 아는 주체가 호스트라는 점을 전제로, 저장장치 내부의 숨은 정리 비용을 줄이려는 접근입니다.

1. 왜 기존 Block SSD 모델이 한계에 부딪히는가

기존 SSD는 LBA 기반 블록 장치로 보이므로 응용과 파일시스템은 단순합니다. 그러나 내부 FTL이 언제 GC를 수행하고 어떤 블록을 이동시키는지는 보이지 않기 때문에, 동일한 쓰기 패턴도 시점에 따라 지연과 WAF가 크게 흔들릴 수 있습니다.

특히 로그구조 DB나 세그먼트 기반 저장소처럼 상위 소프트웨어가 이미 '무엇이 오래 살고 무엇이 곧 버려질지'를 알고 있어도, 이를 SSD에 직접 전달할 방법이 제한적입니다.

그림 1. 기존 Block SSD 모델 — FTL의 복잡성이 디바이스 내부에 숨겨짐

2. Open-Channel SSD

Open-Channel SSD는 PPA(Physical Page Address)를 더 직접적으로 노출해, 호스트 또는 라이브러리 계층이 배치와 cleaning 정책을 통제하도록 합니다. 즉 장치 내부의 FTL 일부 책임을 상위 소프트웨어로 올려보내는 방식입니다.

이 접근은 매우 유연하지만 응용 또는 스토리지 엔진이 물리 배치 정책을 이해해야 하므로 복잡도가 크게 늘어납니다. 그래서 연구와 특정 시스템에서는 매력적이지만, 일반 목적 NVMe 생태계의 표준 인터페이스가 되기에는 부담이 큽니다.

그림 2. 전통 SSD와 Open-Channel SSD의 책임 분할 비교

3. ZNS(Zoned Namespace)의 기본 모델

ZNS는 Open-Channel처럼 물리 페이지를 전부 드러내지는 않되, 저장 공간을 Zone 단위로 나누고 각 Zone에 순차 쓰기 규칙과 write pointer를 부여합니다. 호스트는 zone append를 따라 쓰고, 필요 없어진 Zone은 reset하여 한 번에 재사용합니다.

이 모델은 NVMe 표준의 범위 안에서 host-managed 특성을 도입하는 절충안입니다. 장치는 zone 내부 배치를 단순하게 유지할 수 있고, 호스트는 로그구조 세그먼트를 Zone에 맞춰 배치해 내부 GC 부담을 줄일 수 있습니다.

Zone 종류와 제약

구분	접근 제약	재사용 방식	잘 맞는 데이터
Conventional Zone	일반 블록처럼 임의 읽기/쓰기 가능	일반 블록 동작	메타데이터, 작은 랜덤 쓰기
Sequential Zone	순차 append만 허용, write pointer 준수 필요	zone reset 후 재사용	로그, SSTable, object extent

Sequential Zone에서는 호스트가 마지막 write pointer 위치에 맞춰 append해야 하며, 필요한 경우 zone append를 사용해 장치가 실제 물리 배치를 결정하도록 맡길 수 있습니다. 일부 장치는 동시에 활성화할 수 있는 zone 수에 제한이 있으므로, 상위 계층은 open과 close 타이밍을 고려해 쓰기 실패를 피해야 합니다.

그림 3. ZNS의 Zone과 Write Pointer 모델

4. GC를 누가 맡는가

전통 SSD에서는 invalid page가 device 내부에 흩어지고, SSD가 valid page migration을 수행한 뒤 erase합니다. 반면 ZNS에서는 상위 소프트웨어가 obsolete 데이터를 정리하고, 비워진 Zone 전체를 reset하여 재사용하므로 device 내부 copy가 크게 줄어듭니다.

즉 ZNS는 FTL을 완전히 제거한다기보다, host가 더 구조적인 정보와 배치 의도를 제공해 device 내부 cleaning의 양을 줄이는 방향에 가깝습니다. 이 덕분에 tail latency와 WAF를 더 예측 가능하게 만들 수 있습니다.

호스트 처리 흐름

장치의 zone geometry를 읽고 zone 경계를 파악합니다.
쓰기 데이터는 sequential zone의 끝에 append합니다.
더 이상 필요한 데이터가 없으면 해당 zone을 reset해 공간을 회수합니다.
파일시스템이나 DB는 로그 세그먼트와 zone 경계를 맞춰 내부 migration을 줄입니다.

그림 4. 전통 GC와 ZNS의 zone reset 기반 정리 방식 비교

5. 소프트웨어 스택과 워크로드 적합성

ZNS는 RocksDB 같은 LSM-tree, 로그 수집 시스템, 객체 저장소처럼 원래도 append와 segment cleaning 개념을 갖는 소프트웨어와 특히 잘 맞습니다. Zone을 SSTable, 로그 세그먼트, object extent와 정렬하면 불필요한 내부 재배치를 줄일 수 있습니다.

반대로 덮어쓰기 중심의 범용 파일시스템이나 legacy block API에 그대로 맞추려면 중간 계층이 필요합니다. 그래서 ZNS의 성능 잠재력은 단순히 SSD만 바꾸는 것이 아니라, 파일시스템/DB/런타임이 zone 규칙을 얼마나 자연스럽게 흡수하느냐에 달려 있습니다.

모델 비교

모델	노출 범위	GC 위치	앱 복잡도	장점	한계
Traditional Block SSD	LBA만 노출	device 내부	낮음	호환성 높음	WAF와 tail latency가 숨겨짐
Open-Channel SSD	PPA와 배치 힌트까지 노출	host 또는 host-side stack	높음	제어력 최대화	소프트웨어 변경량이 큼
ZNS	zone, write pointer, reset	host + device 분담	중간	표준화된 절충안	zone-aware 계층이 필요

그림 5. ZNS 소프트웨어 스택 — Zoned-aware 계층이 배치 정책을 담당

6. Open-Channel vs ZNS 정리

Open-Channel SSD는 물리 제어권을 크게 열어주지만 앱 복잡도가 높고, ZNS는 표준화된 zone 규칙만 노출해 현실적 채택 가능성을 높였습니다. 두 접근 모두 '블랙박스 FTL에 모든 것을 맡기지 말자'는 공통 철학을 갖습니다.

결국 핵심은 host가 데이터의 수명과 갱신 패턴을 가장 잘 안다는 점입니다. 그 정보를 저장장치 인터페이스에 얼마나 반영하느냐가 앞으로의 SSD 소프트웨어-하드웨어 공동 최적화 방향을 결정합니다.

아래 도식은 이 철학을 이해하는 데 필요한 배경으로, 전통 SSD의 FTL 동작과 블록 인터페이스, Open-Channel의 책임 이동, ZNS의 write pointer 모델을 나란히 보여줍니다.

그림 6. 전통 SSD가 내부 FTL로 해결하던 매핑, GC, wear leveling, OP의 역할

그림 7. 블록 SSD 인터페이스에서는 내부 정리 비용이 호스트에 잘 드러나지 않음

그림 8. Open-Channel SSD는 배치와 cleaning 정책 일부를 호스트 스택으로 이동

그림 9. ZNS는 zone, write pointer, reset만 노출해 표준 안에서 host-managed 특성을 제공

7. 장단점

장점

host가 append와 reclaim 정책을 직접 맞출 수 있어 write amplification을 줄이기 쉽습니다.
zone reset과 순차 쓰기 규칙 덕분에 tail latency의 변동 폭을 줄이기 유리합니다.
ZNS는 NVMe 표준 기반이라 Open-Channel보다 도입 장벽이 낮고, zonefs 같은 상위 계층과도 잘 맞습니다.

한계

임의 overwrite 중심 워크로드는 zone 규칙과 잘 맞지 않아 성능 이점이 작습니다.
active/open zone 수 제한을 고려해야 하므로 앱이나 파일시스템이 더 복잡해질 수 있습니다.
기존 범용 block API를 그대로 쓰기 어렵고, zone-aware 계층이 없으면 이점이 제한됩니다.

8. 관련 기술

NAND NVMe SSD Analysis: NVMe SSD 기본 구조와 NAND/컨트롤러 관계
FTL WearLeveling GarbageCollection: L2P 매핑, GC, Wear Leveling, TRIM
SSD Internal Parallelism Channel Die Plane: 채널/다이/플레인 병렬성
VFS FS PageCache BlockIO: zonefs처럼 파일 시스템 계층이 장치 제약을 흡수하는 방식
NVMe Architecture: NVMe 큐 구조와 호스트 I/O 발행 경로
Virtual Memory: 로그형 저장소와 page cache, mmap 상호작용 이해에 도움

참고 문헌

NVM Express, Specifications — https://nvmexpress.org/specifications/
NVM Express, NVM Express Base Specification 2.0d — https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2.0d-2024.01.11-Ratified.pdf
The Linux Kernel Documentation, ZoneFS - Zone filesystem for Zoned block devices — https://www.kernel.org/doc/html/latest/filesystems/zonefs.html
Wikipedia, Open-channel SSD — https://en.wikipedia.org/wiki/Open-channel_SSD
Bjørling, Gonzalez, Bonnet, LightNVM: The Linux Open-Channel SSD Subsystem (FAST 2017) — https://www.usenix.org/system/files/conference/fast17/fast17-bjorling.pdf

9. 핵심 정리

ZNS와 Open-Channel SSD는 NAND의 비대칭성과 GC 비용을 호스트가 더 잘 다루도록 인터페이스를 바꾸려는 시도입니다. Open-Channel은 제어권이 크지만 소프트웨어 부담이 크고, ZNS는 zone과 write pointer만 노출해 표준화와 실용성 사이에서 타협합니다.

실제 성능은 장치만으로 결정되지 않고, 파일시스템과 DB가 append, reset, reclaim을 얼마나 자연스럽게 흡수하느냐에 달려 있습니다. 따라서 이 문서의 핵심은 "저장장치가 숨기던 비용을 어디까지 호스트로 드러낼 것인가"라는 설계 선택입니다.