한줄 요약:
소프트웨어의 유연성과 하드웨어의 효율성을 결합한 이중 레이어 압축으로 성능 저하 없이 DB 저장 비용을 60% 절감
클라우드 네이티브 RDBMS 환경에서 컴퓨팅 자원은 탄력적으로 관리되지만, 저장 비용은 여전히 사용자에게 큰 부담이다. 데이터 압축은 가장 직관적인 해결책이지만, 소프트웨어 방식은 CPU 오버헤드와 복잡한 인덱스 관리 문제가 있고, 하드웨어 방식은 고정된 알고리즘과 입력 크기 때문에 유연성이 떨어진다는 치명적인 Trade-off가 존재한다. 알리바바가 FAST '25에서 발표한 PolarStore는 이 문제를 하드웨어와 소프트웨어의 Co-design으로 풀어냈다.
1. 이 내용이 중요한 이유
클라우드 DB 사용자들에게 성능만큼 중요한 것이 비용이다. 특히 데이터가 방대해질수록 저장 비용의 비중이 커지는데, 기존의 압축 방식들은 성능을 희생하거나 공간 효율이 떨어지는 문제가 있다.
B+-Tree 기반 시스템은 4KB 블록 정렬로 인해 Fragmentation이 발생하고, LSM-Tree 기반은 가비지 컬렉션 오버헤드가 크다. PolarStore는 100PB 이상의 대규모 실서비스 환경에서 압축률 3.55배, 비용 60% 절감을 달성하면서도 비압축 클러스터와 대등한 성능을 보여주었다는 점에서 실질적인 임팩트가 있었다.
2. 핵심 주장: 이중 레이어 압축(Dual-layer Compression)
PolarStore의 핵심은 '이중 레이어' 구조다. 소프트웨어 레이어는 데이터를 4KB 단위로 압축하여 유연성을 확보하고, 하드웨어 레이어인 PolarCSD는 이를 다시 바이트 단위의 정밀도로 압축한다.
- 소프트웨어 레이어: 워크로드에 따라 lz4나 zstd 같은 알고리즘과 입력 크기를 유동적으로 선택한다.
- 하드웨어 레이어(PolarCSD): FTL(Flash Translation Layer)을 확장해 바이트 단위 인덱싱을 지원한다.
이를 통해 소프트웨어는 4KB 정렬만 관리하면 되고, 실제 미세한 공간 최적화는 하드웨어가 담당하여 가비지 컬렉션 등의 오버헤드를 줄인다.
3. DB 성능을 위한 세 가지 최적화
압축은 필연적으로 지연시간을 유발한다. PolarStore는 사용자 체감 성능에 직접적인 영향을 주는 'Redo 로그 쓰기'와 '페이지 읽기' 경로에 집중했다.
- Opt#1:
- Redo 로그 쓰기 우회: 트랜잭션 커밋 속도를 위해 Redo 로그는 압축을 건너뛰고 Intel Optane 같은 고성능 SSD에 직접 기록한다.
- Opt#2:
- 적응형 알고리즘 선택: lz4와 zstd 중 무엇을 쓸지 실시간으로 판단한다. zstd가 더 많이 압축하더라도 하드웨어 압축(gzip)을 거치면 lz4와 결과물 차이가 크지 않은 경우가 많다. 따라서 압축 효율 대비 지연시간 이득이 큰 경우에만 zstd를 선택하는 동적 전략을 취한다.
- Opt#3:
- 페이지별 로그(Per-page Log): RO(Read-Only) 노드에서 페이지를 읽을 때 흩어진 Redo 로그를 찾는 '읽기 증폭' 현상을 해결하기 위해, 메모리에서 로그가 방출될 때 해당 페이지의 전용 공간에 로그를 미리 모아두는 방식을 사용한다.
4. 대규모 배포에서의 교훈과 해결책
이 논문에서 특히 흥미로운 부분은 이론적 설계를 넘어 실제 운영에서 겪은 실패를 공유한 점이다.
- PolarCSD 1.0의 한계:
- 초기에는 호스트 기반 FTL을 썼으나, 수십 개의 드라이브를 장착한 서버에서 CPU와 메모리 경합이 발생해 I/O 지터(Jitter)가 심했다.
- PolarCSD 2.0으로의 전환:
- 결국 다시 장치 내부에서 FTL을 관리하는 방식으로 돌아갔다. 대신 매핑 엔트리 크기를 8바이트에서 7바이트로 줄이는 하드웨어 최적화를 통해 메모리 오버헤드 문제를 해결했다.
- 압축 인식 스케줄링(Compression-aware Scheduling):
- 데이터마다 압축률이 다르기 때문에 논리 공간 기준 스케줄링은 물리 공간 불균형을 초래한다. PolarStore는 클러스터 내 노드들의 압축률을 모니터링하여 물리/논리 공간 사용량을 균형 있게 맞추는 전용 알고리즘을 도입했다
5. 의미와 한계
PolarStore는 하드웨어 가속기(CSD)가 단순히 '빠른 압축기'를 넘어, DB의 인덱스 구조와 어떻게 맞물려야 하는지를 보여주는 좋은 사례다. 특히 하드웨어 압축 결과물 위에 소프트웨어 압축이 들어갔을 때의 시너지가 생각보다 크지 않다는 데이터(lz4 vs zstd 비교)는 실무적으로 가치가 있어 보인다.
다만, 이러한 구조는 알리바바와 같이 자체 하드웨어를 설계하고 생산할 수 있는 빅테크 기업만이 누릴 수 있는 혜택이라는 한계도 명확하다. 알리바바같은 큰 규모의 기업이 아니라면 범용 클라우드 환경에서 이 정도 수준의 Co-design을 구현하기는 쉽지 않기 때문이다.
PolarStore의 사례는 하드웨어 가속기가 아키텍처의 핵심 요소로 녹아들 수 있음을 시사한다. 차세대 시스템 설계에 있어 소프트웨어와 하드웨어의 궁합을 잘 맞춰서 디자인함으로써 아키텍처 효율을 끌어올리는 방식이 중요해 질 가능성이 높다.