LSM Tree가 무작위 쓰기를 순차 쓰기로 바꾸는 방식

데이터베이스의 성능을 책임지는 마법 LSM Tree의 원리

현대적인 데이터베이스 시스템에서 데이터 쓰기 성능은 시스템 전체의 처리량을 결정하는 매우 중요한 요소입니다. 우리가 매일 사용하는 수많은 서비스는 초당 수만 건의 데이터를 기록하는데, 전통적인 방식인 B-Tree는 무작위 쓰기 상황에서 큰 병목을 겪곤 합니다. 이를 해결하기 위해 등장한 개념이 바로 LSM Tree(Log Structured Merge Tree)입니다. LSM Tree는 무작위 쓰기를 순차 쓰기로 바꾸는 마법 같은 구조를 통해 현대 데이터 저장소의 핵심 기술로 자리 잡았습니다.

무작위 쓰기가 왜 문제가 되는가

컴퓨터의 저장 장치, 특히 전통적인 하드디스크(HDD)는 데이터를 읽고 쓸 때 물리적인 헤더 이동이 필요합니다. 무작위 쓰기(Random Write)는 데이터가 저장된 곳곳을 헤더가 분주하게 오가야 하므로 매우 느립니다. SSD 역시 물리적인 헤더는 없지만, 특정 블록을 수정하기 위해 전체 페이지를 읽고 지운 뒤 다시 쓰는 과정(Write Amplification)이 필요하여 쓰기 성능이 저하됩니다. 데이터베이스가 데이터의 위치를 찾기 위해 매번 디스크를 뒤지는 행위는 시스템 전체를 느려지게 만드는 주범입니다.

LSM Tree가 쓰기 성능을 높이는 핵심 원리

LSM Tree는 이름 그대로 로그 구조를 기반으로 데이터를 병합하는 방식을 취합니다. 핵심은 데이터를 즉시 수정하지 않고, 일단 메모리에 쌓아두었다가 나중에 한꺼번에 디스크에 기록하는 것입니다. 이 과정은 크게 세 단계로 나뉩니다.

• 메모리 기반의 MemTable: 데이터가 들어오면 즉시 디스크에 쓰지 않고 메모리 공간인 MemTable에 저장합니다. 메모리는 무작위 접근 성능이 매우 뛰어나므로 쓰기 요청을 아주 빠르게 처리할 수 있습니다.
• 순차적인 디스크 기록: MemTable이 꽉 차면 이를 디스크로 내보내는데(Flush), 이때 데이터를 정렬된 순서로 한꺼번에 기록합니다. 이를 SSTable(Sorted String Table)이라고 합니다. 디스크의 특정 위치를 찾아 헤맬 필요 없이, 빈 공간에 차례대로 데이터를 이어 붙이는 순차 쓰기(Sequential Write)가 발생하므로 디스크 성능을 극대화할 수 있습니다.
• 백그라운드 병합: 여러 개의 SSTable이 생성되면 시스템은 백그라운드에서 이들을 병합(Compaction)합니다. 중복된 데이터를 정리하고 최신 버전만 남기며, 정렬된 상태를 유지하여 데이터 읽기 성능까지 보완합니다.

LSM Tree 활용 사례와 실무 적용

LSM Tree 구조는 높은 쓰기 처리량이 요구되는 환경에서 빛을 발합니다. 대표적으로 다음과 같은 기술들이 이 구조를 기반으로 설계되었습니다.

• Apache Cassandra: 대규모 분산 데이터베이스로, 쓰기 작업이 매우 빈번한 IoT 데이터 수집이나 로그 분석에 최적화되어 있습니다.
• RocksDB: 페이스북에서 개발한 키-값 저장소로, 높은 성능을 요구하는 다양한 데이터베이스 엔진의 하부 저장소로 사용됩니다.
• LevelDB: 구글에서 만든 가벼운 데이터 저장소로, 브라우저의 IndexedDB나 블록체인 노드 데이터 저장 등에 널리 쓰입니다.
• InfluxDB: 시계열 데이터베이스로, 끊임없이 들어오는 센서 데이터를 효율적으로 처리하기 위해 LSM Tree 방식을 채택하고 있습니다.

실무자를 위한 팁과 조언

LSM Tree 기반의 데이터베이스를 운영할 때는 몇 가지 고려해야 할 사항이 있습니다. 첫째, Compaction 과정에서 발생하는 CPU와 디스크 I/O 부하를 모니터링해야 합니다. 데이터가 쌓일수록 백그라운드 병합 작업이 시스템 자원을 점유할 수 있기 때문입니다. 둘째, 메모리 사이즈를 적절히 설정하는 것이 중요합니다. MemTable이 너무 작으면 디스크 쓰기가 너무 자주 발생하고, 너무 크면 시스템 전체 메모리 부족 현상이 일어날 수 있습니다. 셋째, 읽기 성능을 위해 블룸 필터(Bloom Filter)를 적극적으로 활용하세요. 블룸 필터는 특정 데이터가 어떤 SSTable에 있는지 빠르게 확인하여 불필요한 디스크 읽기를 획기적으로 줄여줍니다.

흔한 오해와 사실 관계

LSM Tree에 대해 사람들이 흔히 하는 오해 중 하나는 “데이터 읽기가 무조건 느리다”는 것입니다. B-Tree는 데이터 위치를 즉시 찾을 수 있지만, LSM Tree는 여러 SSTable을 뒤져야 하므로 최악의 경우 읽기가 느릴 수 있다는 점은 사실입니다. 하지만 캐싱 기술과 블룸 필터, 그리고 주기적인 Compaction을 통해 이러한 단점은 충분히 상쇄됩니다. 또한, “쓰기 작업이 많지 않으면 LSM Tree를 쓸 필요가 없다”는 생각도 있습니다. 물론 쓰기 부하가 적다면 B-Tree가 더 효율적일 수 있으나, 현대의 모든 서비스는 데이터 규모가 커질 가능성이 높으므로 확장성을 고려한다면 LSM Tree는 매우 합리적인 선택입니다.

비용 효율적인 데이터 관리 전략

비용 측면에서 LSM Tree는 하드웨어의 수명을 연장하는 데 큰 도움을 줍니다. SSD의 경우 쓰기 횟수에 따른 수명 제한이 있는데, 순차 쓰기 방식은 무작위 쓰기에 비해 SSD의 셀 마모를 현저히 줄여줍니다. 또한, 데이터를 압축하기 쉬운 구조를 가지고 있어 디스크 사용 비용을 절감할 수 있습니다. 운영 중인 시스템에서 LSM Tree를 잘 활용하려면 다음 전략을 고려하세요.

• 계층형 저장소 활용: 오래된 데이터는 저렴한 하드디스크나 클라우드 스토리지로 내리고, 최신 데이터 위주로 SSD 성능을 활용하세요.
• 압축 알고리즘 선택: 데이터 성격에 따라 Snappy, LZ4, Zstd 등 적절한 압축 알고리즘을 선택하여 디스크 공간을 절약하세요.
• Compaction 정책 튜닝: 데이터의 유입 패턴에 맞춰 병합 정책(Size-tiered vs Leveled)을 조정하면 시스템 성능을 최적화할 수 있습니다.

전문가들이 바라보는 LSM Tree의 미래

데이터베이스 설계 전문가들은 LSM Tree가 단순한 쓰기 성능 향상을 넘어, 하드웨어의 발전과 발맞추어 진화하고 있다고 평가합니다. NVMe SSD와 같은 고속 저장 장치가 보편화되면서, 병합 작업의 병목을 하드웨어 수준에서 해결하려는 시도가 늘고 있습니다. 또한, 클라우드 네이티브 환경에서는 저장소와 컴퓨팅 자원을 분리하여 LSM Tree의 백그라운드 작업을 유연하게 관리하는 방식이 표준으로 자리 잡고 있습니다. 앞으로의 시스템은 쓰기 성능뿐만 아니라, 데이터의 생애 주기 전반을 관리하는 지능형 LSM Tree 구조로 발전할 것입니다.

자주 묻는 질문과 답변

Q: 데이터 수정이나 삭제는 어떻게 이루어지나요?

A: LSM Tree에서 데이터 삭제는 삭제하려는 데이터에 ‘Tombstone’이라는 표시를 남기는 것으로 처리합니다. 실제 데이터 삭제는 나중에 백그라운드에서 Compaction이 일어날 때 수행됩니다. 수정 역시 새로운 값을 추가하는 것과 동일하게 처리하며, 나중에 병합 과정에서 최신 값만 남게 됩니다.

Q: B-Tree와 LSM Tree 중 무엇을 선택해야 할까요?

A: 읽기 작업이 압도적으로 많고 데이터의 수정이 적다면 B-Tree 계열(예: MySQL의 InnoDB, PostgreSQL)이 유리합니다. 반면, 쓰기 작업이 매우 많고 실시간으로 대량의 로그를 처리해야 한다면 LSM Tree 기반의 저장소(예: Cassandra, RocksDB)가 훨씬 뛰어난 성능을 보여줍니다.

Q: 시스템이 갑자기 종료되면 메모리에 있는 데이터는 어떻게 되나요?

A: 이를 방지하기 위해 LSM Tree 시스템은 데이터를 메모리에 쓰기 전, 디스크에 로그(Write Ahead Log, WAL)를 먼저 기록합니다. 시스템 재시작 시 WAL을 읽어 메모리 상태를 복구하므로 데이터 유실을 방지합니다.

이러한 원리들을 이해하고 실무에 적용한다면, 데이터 규모가 커지더라도 성능 저하 없는 안정적인 서비스를 구축하는 데 큰 도움이 될 것입니다. 기술의 본질을 이해하는 것이야말로 진정한 시스템 엔지니어링의 시작입니다.