SSTable이 수정 불가능한 파일 구조를 사용하는 이유

데이터베이스의 심장 SSTable이 수정 불가능한 이유

현대 IT 서비스에서 우리가 매일 사용하는 소셜 미디어, 쇼핑몰, 로그 분석 시스템은 엄청난 양의 데이터를 실시간으로 처리합니다. 이 거대한 데이터 흐름을 뒷받침하는 핵심 기술 중 하나가 바로 SSTable입니다. SSTable은 Sorted String Table의 약자로, 데이터베이스 시스템에서 데이터를 영구 저장소에 저장하는 방식 중 하나입니다. 그런데 흥미로운 점은 이 SSTable이 한 번 생성되면 절대 수정할 수 없는 불변(Immutable)의 성질을 가진다는 것입니다. 왜 데이터베이스는 굳이 수정이 불가능한 방식을 택했을까요? 이 구조가 왜 현대 데이터 아키텍처에서 필수적인지 깊이 있게 파헤쳐 보겠습니다.

SSTable의 기본 개념과 작동 원리

SSTable은 이름 그대로 정렬된 데이터들의 집합입니다. 데이터를 저장할 때 키(Key) 값을 기준으로 오름차순으로 정렬하여 디스크에 기록합니다. 데이터가 수정 불가능하다는 것은, 일단 파일이 디스크에 써지면 그 파일 안의 내용을 변경하거나 삭제할 수 없다는 의미입니다. 만약 기존 데이터에 수정이나 삭제가 필요하다면, 시스템은 이전 파일을 건드리는 대신 새로운 파일을 생성합니다. 이를 흔히 로그 구조 병합 트리(LSM Tree) 기반 시스템에서 자주 볼 수 있는 방식이라고 합니다.

이러한 구조가 갖는 핵심적인 장점은 순차적 쓰기(Sequential Write)가 가능하다는 것입니다. 하드디스크나 SSD와 같은 저장 매체는 데이터를 여기저기 옮겨 다니며 쓰는(Random Write) 것보다, 한 줄로 쭉 쓰는 것이 압도적으로 빠릅니다. SSTable은 메모리에 데이터를 모아두었다가 한 번에 정렬된 상태로 디스크에 쏟아내기 때문에, 디스크 헤드의 움직임을 최소화하고 데이터 처리량을 극대화할 수 있습니다.

수정 불가능한 구조가 가져오는 데이터 효율성

데이터를 수정할 수 없다는 것은 얼핏 보면 비효율적으로 보일 수 있습니다. 하지만 이 제약 조건은 오히려 데이터베이스 관리 측면에서 강력한 이점을 제공합니다.

• 동시성 제어의 단순화: 여러 사용자가 동시에 같은 파일에 접근해도 수정이 일어나지 않으므로 잠금(Lock) 메커니즘이 필요 없습니다. 이는 읽기 성능을 비약적으로 향상시킵니다.

• 데이터 복구의 용이성: 파일이 수정되지 않기 때문에 데이터가 깨질 위험이 적습니다. 장애가 발생해도 마지막에 생성된 파일들만 복구하면 되므로 데이터 정합성을 유지하기 쉽습니다.
• 효율적인 압축: 정렬된 데이터는 압축률이 매우 높습니다. 수정이 일어나지 않는 파일은 압축 알고리즘을 적용하기에 최적의 환경을 제공합니다.
• 캐싱 전략: 파일이 변하지 않으므로 운영체제나 데이터베이스 차원에서 해당 파일을 메모리에 캐싱해두면, 이후 읽기 요청을 디스크 접근 없이 즉시 처리할 수 있습니다.

흔한 오해와 진실

많은 사람들이 SSTable이 수정 불가능하다는 점 때문에 데이터베이스가 느려질 것이라고 생각합니다. “수정할 때마다 새 파일을 만들면 저장 공간이 낭비되지 않을까?”라는 의문은 매우 합리적입니다. 하지만 이를 해결하기 위해 데이터베이스는 컴팩션(Compaction)이라는 과정을 거칩니다.

컴팩션은 여러 개의 작은 SSTable 파일을 하나로 합치면서, 삭제된 데이터나 중복된 데이터를 제거하고 최신 상태의 데이터만 남기는 작업입니다. 이 과정을 통해 저장 공간을 확보하고, 여러 파일에 파편화되어 있던 데이터를 다시 정렬하여 읽기 성능을 최적화합니다. 즉, 수정 불가능한 구조는 ‘쓰기 시점’에는 성능을 극대화하고, ‘백그라운드 작업’을 통해 전체적인 데이터 품질을 관리하는 전략을 취하는 것입니다.

실생활 활용 사례와 기술적 조언

SSTable 구조는 대규모 데이터를 다루는 분산 데이터베이스에서 주로 사용됩니다. 대표적으로 아파치 카산드라(Apache Cassandra), 구글의 빅테이블(Bigtable), 록스DB(RocksDB) 등이 있습니다. 만약 여러분이 대량의 로그 데이터를 저장하거나, 초당 수만 건의 쓰기 요청이 발생하는 애플리케이션을 설계하고 있다면 SSTable 기반의 데이터베이스를 고려하는 것이 좋습니다.

실무자를 위한 최적화 팁

• 메모리 버퍼 크기 조절: 메모리에서 디스크로 데이터를 넘기는 임계값(Memtable Flush)을 적절히 설정해야 합니다. 너무 작으면 빈번한 디스크 쓰기가 발생하고, 너무 크면 메모리 부족 현상이 생길 수 있습니다.

• 컴팩션 정책 설정: 데이터의 성격에 따라 컴팩션 전략을 선택하세요. 데이터가 자주 업데이트된다면 더 공격적인 컴팩션 설정이 필요합니다.
• 데이터 모델링의 중요성: 키 설계를 할 때 정렬 순서를 고려하세요. SSTable은 키 기반으로 정렬되므로, 범위 쿼리(Range Query)가 자주 발생하는 필드를 키로 잡으면 읽기 성능이 획기적으로 개선됩니다.

비용 효율적인 활용 방법

SSTable 구조를 활용하면 하드웨어 비용을 절감할 수 있습니다. 무작위 쓰기 성능이 보장되어야 하는 고가의 NVMe SSD 대신, 순차적 쓰기에 강한 비교적 저렴한 스토리지를 활용해도 높은 성능을 낼 수 있기 때문입니다. 또한 데이터 압축률이 높기 때문에 동일한 용량의 스토리지에 더 많은 데이터를 저장할 수 있어 클라우드 비용 절감에도 큰 도움이 됩니다.

무엇보다 운영 자동화 관점에서 이점이 큽니다. 데이터가 수정되지 않는다는 것은 데이터의 상태가 예측 가능하다는 의미입니다. 이는 자동화된 백업 및 복구 프로세스를 설계할 때 엔지니어의 수고를 크게 덜어줍니다. 파일 시스템 수준에서 스냅샷을 찍는 것만으로도 완벽한 데이터 백업이 가능하기 때문입니다.

자주 묻는 질문과 답변

Q1. SSTable은 삭제 작업을 어떻게 처리하나요?

데이터베이스는 삭제를 위해 ‘툼스톤(Tombstone)’이라는 특별한 표식을 기록합니다. 특정 데이터를 삭제하라는 명령이 오면 데이터를 즉시 지우는 대신, 해당 데이터가 삭제되었음을 알리는 툼스톤 데이터를 SSTable에 씁니다. 이후 컴팩션 과정에서 실제 데이터와 툼스톤이 만나면 그때 비로소 물리적으로 삭제됩니다.

Q2. 데이터가 많아지면 읽기 성능이 떨어지지 않나요?

SSTable은 각 파일마다 인덱스를 메모리에 유지합니다. 또한 블룸 필터(Bloom Filter)라는 기술을 사용하여 특정 데이터가 어떤 파일에 있는지 미리 파악합니다. 따라서 데이터가 수천 개로 늘어나도 디스크를 일일이 뒤지는 것이 아니라 필요한 파일만 정확히 찾아가므로 읽기 성능 저하를 최소화합니다.

Q3. 수정 불가능한 구조의 최대 단점은 무엇인가요?

가장 큰 단점은 ‘쓰기 증폭(Write Amplification)’입니다. 하나의 데이터를 수정하기 위해 기존 내용을 읽고, 새로운 내용을 쓰고, 나중에 컴팩션으로 다시 합치는 과정에서 실제 데이터 크기보다 더 많은 양의 데이터가 디스크에 쓰이게 됩니다. 이는 스토리지 수명에 영향을 줄 수 있으므로 시스템 설계 시 고려해야 할 요소입니다.

전문가의 관점

데이터 엔지니어링 전문가들은 SSTable의 불변성을 ‘복잡성을 단순함으로 바꾼 승리’라고 평가합니다. 가변 데이터를 다루는 기존의 B-Tree 구조는 동시성 제어와 페이지 분할 등 복잡한 알고리즘이 필요하지만, SSTable은 수정 불가라는 제약을 통해 쓰기 작업을 극도로 단순화했습니다. 이러한 설계 철학은 현대의 분산 시스템이 수평적으로 확장(Scale-out)할 수 있는 근간이 되었습니다. 데이터 양이 폭발적으로 늘어나는 현대 사회에서, 수정 불가능한 파일 구조는 단순히 기술적 선택을 넘어 대용량 데이터 관리를 위한 표준으로 자리 잡고 있습니다.

결국 기술을 선택할 때는 우리가 다루는 데이터의 특성을 먼저 이해해야 합니다. 수정이 잦은 트랜잭션 데이터라면 전통적인 RDBMS가 유리할 수 있지만, 로그 데이터, 시계열 데이터, 혹은 대규모 분석용 데이터라면 SSTable 구조를 가진 데이터베이스를 선택하는 것이 성능과 비용 측면에서 압도적으로 유리합니다. SSTable이 가진 불변의 가치는 데이터의 무결성을 지키면서도 처리 성능을 극대화하려는 엔지니어링의 고민이 담긴 결과물임을 기억하시기 바랍니다.