Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration

이 논문은 합의 프로토콜과 저장 엔진 간의 중복 지속성 작업으로 인한 I/O 오버헤드를 해결하기 위해 키 - 값 분리 아키텍처와 Raft 를 혁신적으로 통합하여 읽기 및 쓰기 성능을 대폭 향상시킨 분산 키 - 값 저장소 'Nezha'를 제안합니다.

핵심

네자 (Nezha): 데이터 저장소의 '불로장생'을 찾아서

이 논문은 현대의 거대한 데이터(빅데이터) 를 다루는 시스템이 겪는 '지루한 반복 작업' 문제를 해결하기 위해 개발된 새로운 기술, **네자 (Nezha)**에 대한 이야기입니다.

이해하기 쉽게 **우주선 (데이터 센터)**과 **우주선 승무원 (데이터)**의 비유를 들어 설명해 드리겠습니다.

---

1. 문제: 왜 우주선은 그렇게 느릴까요? (기존 시스템의 한계)

과거의 데이터 저장소 시스템 (Raft 기반) 은 데이터를 안전하게 지키기 위해 아주 보수적인 방식을 썼습니다. 마치 우주선이 발사될 때, 승무원이 세 번이나 같은 서류를 작성하고 서명하는 것과 비슷합니다.

1. 첫 번째 서명 (Raft 로그): "우리가 이 데이터를 저장하기로 합의했다"는 기록을 남깁니다.
2. 두 번째 서명 (WAL): 저장소 엔진이 "내가 이 데이터를 받았습니다"라고 기록합니다.
3. 세 번째 서명 (SSTable): 실제로 데이터를 정리해서 파일로 저장합니다.

문제점: 데이터가 작을 때는 괜찮지만, 데이터가 거대해지면 이 불필요한 세 번의 서명 과정 때문에 디스크 (하드디스크) 가 과부하가 걸리고, 우주선 (시스템) 이 매우 느려집니다. 마치 택배를 보낼 때 박스를 3 번이나 겹쳐서 포장하는 것과 같습니다.

2. 해결책: 네자 (Nezha) 의 혁신적인 아이디어

저자들은 이 문제를 해결하기 위해 '키 (Key)'와 '값 (Value)'을 분리하는 방식을 도입했습니다.

• 기존 방식: 모든 것 (주소와 내용물) 을 한 번에 옮기려다 지친 상태.
• 네자의 방식:
  • **주소 (Key)**만 작은 메모장에 적어서 정리합니다.
  • **내용물 (Value, 실제 데이터)**은 별도의 창고 (ValueLog) 에 그냥 쌓아둡니다.
  • 그리고 **주소와 내용물의 연결고리 (오프셋)**만 저장소에 남깁니다.

비유: 우편배달부가 편지 (데이터) 를 직접 들고 다니지 않고, **"편지가 창고 3 번 선반에 있습니다"**라는 작은 쪽지만 들고 다니는 것입니다. 이렇게 하면 배달부가 훨씬 가볍고 빠르게 움직일 수 있습니다.

3. 핵심 기술 3 가지: 네자가 어떻게 작동하나요?

네자는 이 아이디어를 실현하기 위해 세 가지 마법 같은 기술을 사용했습니다.

① KVS-Raft: 합의의 지혜

기존의 '합의 알고리즘 (Raft)'은 무조건 모든 데이터를 복사해서 저장하라고 했습니다. 하지만 네자는 **"합의할 때는 실제 내용물 (무거운 박스) 이 아니라, 주소 (가벼운 쪽지) 만 공유하자"**고 제안합니다.

• 효과: 데이터를 디스크에 쓰는 횟수가 3 번에서 1 번으로 줄어듭니다. (쓰기 성능 460% 향상!)

② 지능형 쓰레기 수거 (GC): 정리 정돈의 달인

데이터를 따로따로 쌓아두면 (주소와 내용물이 분리되면), 나중에 찾아볼 때 헤매기 쉽습니다. "어디에 있었지?"라고 찾는 데 시간이 걸리는 것입니다.
네자는 지능형 쓰레기 수거 (Garbage Collection) 시스템을 도입했습니다.

• 비유: 산더미처럼 쌓인 쓰레기 (데이터) 를 주기적으로 정리해서, 가나다순으로 정렬된 깔끔한 장부로 바꿔줍니다.
• 효과: 나중에 데이터를 찾을 때 (읽기 작업) 헤매지 않고 바로 찾아낼 수 있게 되어 읽기 속도도 빨라집니다.

③ 3 단계 요청 처리: 공사 중인 도로의 교통 통제

쓰레기 수거 (정리 작업) 가 일어나는 동안에도 시스템은 멈추지 않고 계속 작동해야 합니다.

• 비유: 도로를 공사할 때, 차가 멈추지 않고 우회로를 이용하게 하거나, 공사 구간을 분리해서 교통 체증을 막는 것과 같습니다.
• 네자는 정리가 끝난 상태, 정리 중인 상태, 정리가 시작되기 전 상태에 따라 데이터를 찾는 경로를 다르게 설정하여 절대 멈추지 않는 서비스를 제공합니다.

4. 결과: 얼마나 빨라졌나요?

실험 결과, 네자는 기존 시스템에 비해 놀라운 성과를 거두었습니다.

• 데이터 넣기 (Put): 460% 더 빠릅니다. (약 4.6 배)
• 데이터 찾기 (Get): 12.5% 더 빠릅니다.
• 데이터 훑어보기 (Scan): 72.6% 더 빠릅니다.

5. 요약: 왜 이 기술이 중요한가요?

지금까지 데이터 저장소는 **"안전함 (Consistency)"**을 위해 **"속도 (Performance)"**를 희생해야 했습니다. 하지만 네자는 "안전함"을 해치지 않으면서 "속도"까지 모두 잡은 혁신적인 시스템입니다.

한 줄 요약:

"무거운 데이터를 3 번이나 복사해서 저장하던 구식 방식을 버리고, 가벼운 주소표만 공유하고 실제 데이터는 따로 관리하는 지능형 창고 시스템을 만들어, 데이터 처리 속도를 비약적으로 높였습니다."

이 기술은 클라우드 서비스, 빅데이터 분석, 실시간 금융 거래 등 거대한 데이터를 다루는 모든 분야에서 비용을 줄이고 속도를 높이는 데 큰 도움을 줄 것입니다.

기술 요약

1. 문제 정의 (Problem)

분산 키 - 밸류 (Key-Value) 저장소는 대규모 데이터 애플리케이션의 핵심 인프라로 널리 사용되며, 데이터 일관성을 보장하기 위해 Raft 와 같은 합의 알고리즘을 활용합니다. 그러나 기존 시스템 (LSM-tree 기반 스토리지 엔진 + Raft) 은 다음과 같은 중복된 I/O 오버헤드로 인해 성능 병목 현상이 발생합니다.

• 중복 쓰기 (Redundant Writes): 클라이언트의 쓰기 요청이 처리될 때, 데이터는 최소 3 번 이상의 디스크 쓰기를 거칩니다.
  1. Raft 로그 지속성: 합의 상태를 유지하기 위해 Raft 로그 (ValueLog) 에 기록.
  2. LSM-tree WAL: 스토리지 엔진의 Write-Ahead Log 에 기록.
  3. Memtable 지속성: MemTable 이 가득 차면 SSTable 파일로 플러시 (Flush).
• 성능 저하: 이러한 중복 기록은 특히 대용량 값 (Value) 을 다룰 때 I/O 부하를 급증시키고, Compaction 과정에서의 Write Amplification 을 악화시켜 전체 처리량 (Throughput) 을 제한합니다.
• 읽기 성능의 딜레마: 키 - 밸류 분리 (Key-Value Separation) 기술을 도입하면 쓰기 성능은 향상되지만, 값이 별도의 로그 파일에 흩어져 있어 읽기 시 추가적인 I/O 와 인덱스 조회 오버헤드가 발생하여 읽기 성능이 저하될 수 있습니다.

2. 방법론 (Methodology)

저자들은 Nezha라는 새로운 분산 키 - 밸류 저장 시스템을 제안하며, 합의 계층 (Consensus Layer) 과 스토리지 계층 (Storage Layer) 을 통합적으로 재설계하여 위 문제를 해결합니다.

핵심 아키텍처 및 기술

1. KVS-Raft (합의 계층 최적화):

   • 키 - 밸류 분리 전략의 Raft 통합: Raft 로그에 실제 값 (Value) 을 직접 저장하지 않고, 값은 별도의 ValueLog(순차 쓰기 전용 로그) 에 저장하고, Raft 로그에는 키와 값의 위치를 나타내는 오프셋 (Offset) 만 저장합니다.
   • 효과: 값의 디스크 쓰기를 기존 3 번에서 1 번으로 줄여 Write Amplification 을 근본적으로 제거합니다. 상태 머신 (State Machine) 에는 경량의 오프셋만 저장하여 업데이트 속도를 높입니다.

2. Raft 인식형 GC 프레임워크 (Raft-aware Garbage Collection):

   • 문제 해결: 키 - 밸류 분리로 인해 값이 흩어지면 읽기 성능이 떨어지고, Raft 로그의 순차성 유지가 어려워집니다. 이를 해결하기 위해 GC 를 Raft 의 로그 관리와 연동합니다.
   • 작동 원리:
     • Unordered Log Files: 새로운 요청을 순차적으로 기록 (Active Storage).
     • Ordered Log Files: GC 를 통해 흩어진 데이터를 키 순서대로 정렬하여 압축 저장 (Final Compacted Storage).
     • Hash Index: 정렬된 파일에 해시 인덱스를 구축하여 오프셋 조회를 가속화합니다.
   • 3 단계 요청 처리 메커니즘: GC 수행 중에도 시스템 가용성을 보장하기 위해 Pre-GC, During-GC, Post-GC 단계로 나누어 읽기/쓰기 요청을 처리합니다. 특히 During-GC 단계에서는 새 요청은 New Storage로, 기존 데이터는 Active Storage로 병렬 조회하여 최신 데이터를 보장합니다.

3. 안전성 보장:

   • Raft 의 안전성 속성 (Safety) 을 훼손하지 않으면서 GC 를 수행합니다. TLA+ 를 통한 형식적 검증 (Formal Verification) 을 통해 시스템의 일관성과 복구 메커니즘이 Raft 의 안전성을 유지함을 증명했습니다.

3. 주요 기여 (Key Contributions)

• 병목 현상 규명: 분산 키 - 밸류 저장소에서 합의 프로토콜과 스토리지 엔진 간의 중복 지속성 (Redundant Persistence) 이 현대 하드웨어 환경에서 주요 성능 병목임을 규명했습니다.
• Nezha 시스템 설계:
  • KVS-Raft: 키 - 밸류 분리를 Raft 프로토콜에 유기적으로 통합하여 쓰기 성능을 극대화하면서도 강한 일관성을 유지하는 합의 알고리즘을 제안했습니다.
  • Raft-aware GC: 읽기 성능 저하를 방지하고 저장 효율성을 높이기 위해 Raft 로그 관리와 연동된 적응형 GC 프레임워크를 설계했습니다.
  • 3 단계 처리 메커니즘: 시스템 최적화 (GC) 과정 중에도 요청 처리의 정확성과 가용성을 보장하는 메커니즘을 구현했습니다.
• 광범위한 실험 평가: 기존 시스템 대비 Put, Get, Scan 작업에서 획기적인 성능 향상을 입증했습니다.

4. 실험 결과 (Results)

저자들은 3 노드 클러스터 환경에서 다양한 워크로드 (YCSB, 다양한 값 크기 등) 를 통해 Nezha 를 평가했습니다.

• 처리량 (Throughput) 향상:
  • Put (쓰기): 평균 460.2% 향상 (기존 Raft 기반 시스템 대비). 값 크기가 클수록 성능 격차가 커짐.
  • Get (읽기): 평균 12.5% 향상. (기존 키 - 밸류 분리 방식인 Nezha-NoGC 는 오프셋 조회 오버헤드로 인해 성능이 저하되었으나, Nezha 의 GC 및 인덱싱으로 이를 상쇄하고 오히려 향상됨).
  • Scan (범위 조회): 평균 72.6% 향상. 정렬된 파일 구조와 해시 인덱스로 인해 랜덤 I/O 가 순차 I/O 로 변환되어 성능이 크게 개선됨.
• 지연 시간 (Latency): Put 작업에서 평균 59.2% 감소, Get 작업에서 10.3% 감소, Scan 작업에서 39.2% 감소.
• 확장성 (Scalability): 클러스터 노드 수 (37 개) 가 증가해도 기존 시스템보다 3.5 배5.3 배 높은 처리량을 유지하며 우수한 확장성을 보임.
• 복구 시간: 장애 발생 시 복구 시간이 기존 시스템 대비 약 33% 단축됨 (경량 오프셋만 저장하여 복구 데이터 양이 감소).

5. 의의 및 결론 (Significance)

• 합의 - 스토리지 공동 설계 (Co-design) 의 중요성: 기존에는 합의 프로토콜과 스토리지 엔진이 독립적으로 동작하며 중복 I/O 를 발생시켰으나, Nezha 는 두 계층을 통합하여 근본적인 I/O 비효율을 제거했습니다.
• 키 - 밸류 분리의 한계 극복: 키 - 밸류 분리 기술이 가진 읽기 성능 저하 문제를 Raft 인식형 GC 를 통해 해결함으로써, 쓰기 성능 향상과 읽기 성능 유지/향상을 동시에 달성했습니다.
• 실용성: Etcd, TiDB, CockroachDB 등 Raft 기반 시스템의 성능 병목을 해결할 수 있는 실용적인 솔루션을 제공하며, 클라우드 환경에서의 저장 비용 절감 (중복 쓰기 제거) 효과도 기대됩니다.

결론적으로, Nezha 는 분산 저장 시스템의 성능 한계를 돌파하기 위해 합의 프로토콜과 스토리지 아키텍처를 혁신적으로 재설계한 성공적인 사례로 평가됩니다.