“SSD 안에 ‘구역 나누기’가 들어가면” – ZNS SSD가 바꾸는 클라우드 저장소의 뒷모습

SSD를 더 빨리 만들기보다, 더 ‘예측 가능하게’ 만들기
– Zoned Namespace(ZNS)가 노리는 지점

---

1. ZNS SSD, 한 줄 정리

Zoned Namespace(ZNS) SSD는 SSD 내부 주소 공간을 여러 개의 ‘존(Zone)’으로 나누고, 각 존에 순차적으로만 쓰게 만드는 새로운 NVMe 인터페이스입니다. 기존 SSD는 호스트가 랜덤하게 쓰더라도, 내부에서 FTL·가비지 컬렉션이 알아서 정리해 주는 구조였지만, ZNS에서는 “순차 쓰기”라는 제약을 호스트에 공개하고, 데이터 배치·공간 회수 전략을 호스트와 나눠 가지는 방식으로 바뀝니다. NVMe 워킹그룹은 이를 “SSD 내부 동작을 호스트와 정렬해, 쓰기 증폭·DRAM·오버프로비저닝을 줄이고, 지연을 예측 가능하게 만들기 위한 업계 표준”이라고 정의합니다.

2. 왜 이런 걸 만들었나 – 기존 SSD의 ‘숨은 비용’

NVMe 기술 그룹은 ZNS 제안 배경으로, 플래시 SSD가 가진 세 가지 구조적 문제를 짚습니다.

• 쓰기 증폭(Write Amplification)
  - 호스트는 작은 블록을 자주 덮어쓰지만, NAND는 큰 블록 단위로만 지울 수 있어, 내부에서 데이터 이동·병합이 반복되며 실제 쓰기는 훨씬 많아집니다.
• 오버프로비저닝(Over‑provisioning)
  - GC·웨어 레벨링을 위해 사용자에게 보이지 않는 여분 공간을 많이 잡아둬야 하고, 그만큼 비용·용량 효율이 떨어집니다.
• DRAM 의존도
  - 논리→물리 매핑 테이블을 SSD 안에서 관리해야 해서, 보통 1TiB NAND당 약 1GiB DRAM이 필요하다는 식의 부담이 있습니다.

NVMe 문서는 “이 모든 비용은 결국 데이터센터·클라우드 사업자의 TCO(총소유비용)로 이어진다”고 지적하면서, 호스트가 데이터 배치를 더 잘 알 수 있는 워크로드라면, 그 지식을 활용해서 관리 부담을 나눠 가지는 게 합리적이라고 설명합니다. 이게 바로 “호스트에게 존 구조를 공개하고, 순차 쓰기를 요구하는” ZNS 모델이 등장한 이유입니다.

3. ZNS SSD가 어떻게 동작하나 – 존, 순차 쓰기, 리셋

이미지 출처 : SK Hynix

ZNS SSD의 핵심 개념은 다음 세 가지입니다.

• ① 존(Zone)으로 나눈 주소 공간
  - SSD 논리 주소 공간을 여러 개의 고정 크기 존으로 나눕니다.
  - 각 존은 “처음부터 끝까지 한 번 쭉 쓰는” 큰 연속 영역처럼 동작합니다.
• ② 순차 쓰기 규칙
  - 각 존은 append‑only: 쓰기는 항상 “현재 기록 포인터” 뒤에만 할 수 있고, 임의 위치 덮어쓰기는 허용되지 않습니다.
  - 읽기는 존 안 어디든 자유롭게 가능하지만, 쓰기는 오직 앞으로만 진행됩니다.
• ③ 리셋(Reset)으로 재사용
  - 한 존을 다시 쓰려면, 호스트가 명시적으로 존 리셋 명령을 보내야 합니다.
  - 이때 SSD는 해당 존을 지우고, 기록 포인터를 처음으로 되돌립니다.

ZonedStorage.org는 “존 추상화 덕분에, 호스트가 SSD의 ‘순차 쓰기 요구’를 직접 맞춰 줄 수 있고, 그 결과 내장 GC·복잡한 매핑이 줄어든다”고 설명합니다. eZNS·ZNS+ 같은 연구들도, 호스트가 존 관리를 맡으면 SSD는 더 적은 DRAM·더 낮은 쓰기 증폭·더 예측 가능한 지연으로 동작할 수 있다고 보고합니다.

4. 그래서 뭐가 좋아지나 – 데이터센터 관점의 이점

NVMe 워킹그룹·SanDisk·연구 논문들은 ZNS SSD의 장점을 다음과 같이 정리합니다.

• 더 적은 DRAM, 더 낮은 비용
  - ZNS SSD는 존 단위 매핑만 관리하면 되기 때문에, 기존 4KB 페이지 매핑 SSD 대비 매핑 테이블 크기를 수천 배까지 줄일 수 있습니다.
  - NVMe 측은 “SSD당 DRAM 요구량 감소로 TCO 절감”을 대표 이점으로 꼽습니다.
• 쓰기 증폭·오버프로비저닝 감소
  - 호스트가 순차 쓰기를 지키면, 내부에서 데이터 재배치·GC가 크게 줄어 WAF가 4~5배까지 낮아질 수 있다는 시연도 있습니다.
  - 그만큼 여분 NAND(오버프로비저닝)를 줄이거나, 같은 용량에서 수명·일관성을 끌어올릴 수 있습니다.
• 지연·QoS 개선
  - 디바이스 내부의 갑작스러운 GC·블록 이동 작업이 줄어, tail latency(지연 꼬리)가 짧아지고, I/O 예측 가능성이 좋아집니다.
• QLC·차세대 NAND 활용성 증가
  - Reddit·업계 글에서도, ZNS가 쓰기 증폭을 줄여줘서 내구성이 약한 QLC·차세대 고밀도 NAND를 데이터센터에 더 적극적으로 쓰게 하는 기술로 평가합니다.

NVMe 공식 자료는 ZNS를 두고 “SSD당 DRAM 최소화, 오버프로비저닝 감소, 수명·지연·처리량 개선을 동시에 노리는 기술”이라고 요약합니다. SanDisk 역시 “디바이스 GC를 없애고, 호스트가 순차 쓰기를 책임지는 대신, 더 높은 성능·QoS·용량 효율을 얻는 것”이 ZNS SSD의 핵심이라고 강조합니다.

5. 개발자·운영자가 볼 때 중요한 포인트

문제는, 이런 이점을 얻는 대신 호스트·소프트웨어가 더 똑똑해져야 한다는 점입니다. ZNS 관련 논문·도구 문서를 보면, 실제로 고려해야 할 지점들이 정리돼 있습니다.

• 애플리케이션·파일 시스템 설계
  - 로그 구조 스토리지, 시계열 DB, 오브젝트 스토리지처럼 원래부터 순차 쓰기·배치 삭제 패턴을 가진 시스템이 ZNS와 잘 맞습니다.
  - 반대로 무작위 작은 쓰기가 많은 워크로드는 ZNS 전용 계층(예: ZNS 대응 파일 시스템·엔진) 위에 올리는 게 필요합니다.
• ‘열 수 있는 존’ 제한
  - ZNS 스펙은 동시에 active/open할 수 있는 존 개수에 제한을 둘 수 있다고 명시합니다.
  - 애플리케이션이 너무 많은 존을 동시에 열어두면 SSD 제약에 걸릴 수 있어, 이 부분을 고려한 설계가 필요합니다.
• 호스트 메모리 vs 디바이스 DRAM
  - FTL·매핑 일부가 호스트로 올라오면서, 디바이스 DRAM은 줄지만, 호스트 소프트웨어가 그만큼 메모리를 써야 합니다.
  - 연구자들은 이를 파일 시스템·엔진 레벨에 자연스럽게 녹여, 추가 오버헤드를 최소화하는 방향을 제안합니다.
• 툴링·에코시스템
  - Linux는 nvme-cli, zns-tools 등으로 ZNS 디바이스 관리를 지원하고 있고, ZonedStorage.org가 커널·라이브러리·샘플을 정리해 두고 있습니다.
  - 다만, 여전히 ‘일반 SSD’만큼 쉽지는 않고, 로그 구조·존 관리 개념에 익숙해질 필요가 있습니다.

USENIX·ACM 논문들(eZNS, ZNS+)은, 미래 데이터센터 스토리지 인프라에서 ZNS가 비용 효율·QoS를 끌어올리는 핵심 인터페이스가 될 수 있다고 평가하면서도, “정적 존 인터페이스를 얼마나 유연하게 만들 수 있느냐”가 다음 과제라고 말합니다. 즉, ZNS SSD는 단순히 “새로운 SSD 제품”이 아니라, 저장소 스택 전체(디바이스·OS·파일 시스템·DB)를 함께 바꾸는 방향의 기술에 가깝다고 볼 수 있습니다.