Tombstone이 분산 데이터베이스에서 삭제 데이터를 즉시 제거하지 않는 이유

분산 데이터베이스에서 삭제가 즉시 이루어지지 않는 이유

현대적인 분산 데이터베이스를 다루다 보면 데이터를 삭제했는데도 저장 공간이 즉시 확보되지 않거나, 삭제한 데이터가 잠시 동안 다시 조회되는 경험을 하게 됩니다. 이는 데이터베이스가 고장 났기 때문이 아니라, 분산 시스템의 데이터 일관성과 무결성을 유지하기 위한 고도의 설계 전략인 툼스톤(Tombstone) 메커니즘 때문입니다. 툼스톤은 직역하면 묘비라는 뜻으로, 데이터가 삭제되었음을 알리는 일종의 표식입니다.

툼스톤이 필요한 근본적인 이유

분산 데이터베이스는 데이터를 여러 노드(서버)에 나누어 저장합니다. 사용자가 삭제 명령을 내리면 시스템은 데이터가 저장된 모든 노드에 즉시 삭제 메시지를 보냅니다. 하지만 네트워크 지연이나 노드의 일시적인 오프라인 상태 때문에 모든 노드가 동시에 삭제 명령을 처리하는 것은 불가능합니다. 만약 데이터가 즉시 물리적으로 제거된다면 다음과 같은 심각한 문제가 발생합니다.

• 데이터의 유령 현상: 특정 노드에서만 삭제가 완료되고 다른 노드에서는 아직 삭제되지 않은 데이터가 남아있을 경우, 시스템은 삭제된 데이터를 다시 복구하거나 잘못된 정보를 제공할 수 있습니다.

• 복제 불일치: 분산 시스템은 데이터를 복제하여 저장합니다. 특정 노드가 일시적으로 다운되었다가 복구될 때, 삭제된 사실을 모르는 노드가 자신의 데이터를 다른 노드에 다시 복제(전파)하게 되면 삭제된 데이터가 부활하는 현상이 나타납니다.

이러한 문제를 해결하기 위해 데이터베이스는 데이터를 물리적으로 지우는 대신 툼스톤이라는 마커를 남깁니다. 이것은 해당 데이터가 삭제되었음을 기록하는 일종의 상태 값입니다. 툼스톤을 통해 시스템은 특정 데이터가 실제로 삭제된 것인지, 아니면 아직 추가되지 않은 새로운 데이터인지를 명확히 구분할 수 있습니다.

툼스톤의 작동 원리와 생애 주기

툼스톤은 데이터베이스 내부에서 다음과 같은 과정을 통해 관리됩니다.

• 삭제 요청 발생: 사용자가 삭제 명령을 내리면 데이터베이스는 데이터를 즉시 지우지 않고 툼스톤을 생성합니다.
• 전파 및 동기화: 툼스톤은 일반 데이터와 마찬가지로 다른 노드로 전파됩니다. 이제 모든 노드는 해당 데이터가 삭제되었음을 인지하게 됩니다.
• 조회 시점의 필터링: 데이터를 읽을 때 데이터베이스는 툼스톤이 있는 데이터는 결과를 반환하지 않도록 처리합니다. 사용자 입장에서는 데이터가 사라진 것처럼 보입니다.
• 컴팩션 또는 가비지 컬렉션: 일정 시간이 지나거나 특정 조건이 충족되면 데이터베이스는 툼스톤과 함께 물리적으로 데이터를 완전히 삭제하는 작업을 수행합니다. 이를 보통 컴팩션(Compaction)이라고 부릅니다.

흔히 발생하는 오해와 진실

데이터를 삭제했는데 저장 공간이 왜 줄어들지 않나요

가장 흔한 오해 중 하나입니다. 툼스톤은 데이터의 크기만큼은 아니지만, 여전히 메타데이터로서 저장 공간을 차지합니다. 또한 물리적인 데이터는 컴팩션이 수행되기 전까지 디스크에 그대로 남아있습니다. 따라서 삭제 직후에 디스크 용량이 늘어나지 않는 것은 정상적인 동작입니다.

툼스톤은 영원히 남아있나요

그렇지 않습니다. 만약 툼스톤이 영원히 남아있다면 데이터베이스는 삭제된 데이터의 흔적으로 가득 차 성능이 저하될 것입니다. 대부분의 분산 데이터베이스는 ‘GC Grace Seconds’와 같은 설정값을 가지고 있습니다. 이 시간 동안만 툼스톤을 유지하고, 그 이후에는 안전하게 물리적으로 제거합니다.

데이터베이스 성능을 최적화하는 실용적인 팁

툼스톤 메커니즘을 이해하고 있다면 시스템 운영 시 다음과 같은 전략을 활용할 수 있습니다.

• 컴팩션 주기 최적화: 데이터 삭제가 빈번한 시스템이라면 컴팩션 주기를 적절히 조절해야 합니다. 너무 짧은 주기는 시스템 부하를 일으키고, 너무 긴 주기는 디스크 공간 낭비를 초래합니다.
• 대량 삭제 주의: 한꺼번에 너무 많은 데이터를 삭제하면 수많은 툼스톤이 생성되어 읽기 성능이 떨어질 수 있습니다. 가급적 배치 단위로 나누어 삭제하는 것이 좋습니다.
• 데이터 수명 주기 관리: TTL(Time To Live) 기능을 적극 활용하세요. 데이터가 특정 시간 이후 자동으로 삭제되도록 설정하면 툼스톤 관리가 시스템에 의해 자동으로 수행되므로 운영 효율이 높아집니다.

분산 데이터베이스 종류별 툼스톤 관리 방식

모든 데이터베이스가 동일한 방식으로 툼스톤을 관리하는 것은 아닙니다. 각 설계 철학에 따라 차이가 있습니다.

카산드라(Cassandra)와 같은 LSM 트리 기반 데이터베이스

로그 구조화 병합 트리(LSM Tree)를 사용하는 데이터베이스는 수정과 삭제를 모두 추가 작업으로 처리합니다. 삭제는 툼스톤을 삽입하는 것과 같으며, 이후 컴팩션 프로세스를 통해 툼스톤과 원본 데이터를 함께 제거합니다. 이 방식은 쓰기 성능이 매우 뛰어나지만 컴팩션 과정에서 리소스 소모가 발생합니다.

분산 키-값 저장소

일부 키-값 저장소는 툼스톤 대신 특별한 상태 플래그를 사용하거나, 삭제된 키를 특정 기간 동안 별도의 무효화 목록에 보관합니다. 이 방식은 구현이 단순하지만 복잡한 데이터 관계를 맺고 있는 시스템에서는 일관성을 유지하기 위해 더 정교한 논리가 필요합니다.

전문가가 제안하는 운영 관리 전략

분산 데이터베이스 전문가들은 툼스톤으로 인한 성능 저하를 방지하기 위해 다음과 같은 조언을 합니다. 첫째, 데이터 모델 설계 시 삭제보다는 상태 변경을 우선 고려하세요. 예를 들어 ‘사용자 삭제’를 실제로 수행하기보다는 ‘상태: 비활성’으로 변경하는 것이 시스템 부하 측면에서 훨씬 안전할 수 있습니다. 둘째, 노드의 복구 시간을 고려하여 툼스톤 유지 시간을 설정하세요. 만약 노드가 3일 만에 복구된다면 툼스톤 유지 시간은 최소 3일 이상이어야 데이터 불일치를 막을 수 있습니다.

자주 묻는 질문과 답변

질문: 툼스톤이 너무 많이 쌓여서 조회 속도가 느려졌습니다. 어떻게 해야 할까요?

답변: 이는 컴팩션이 제때 이루어지지 않고 있거나 툼스톤 유지 시간이 너무 길게 설정되어 있을 가능성이 큽니다. 데이터베이스의 컴팩션 로그를 확인하고, 불필요하게 긴 유지 시간을 줄이거나 수동 컴팩션을 트리거하여 성능을 복구할 수 있습니다.

질문: 특정 데이터를 완전히 지우고 싶은데, 툼스톤 때문에 잔재가 남는 것이 걱정됩니다.

답변: 분산 시스템의 특성상 물리적인 즉시 삭제는 데이터 무결성을 해칠 위험이 큽니다. 보안상의 이유로 반드시 즉시 삭제가 필요하다면, 해당 데이터를 암호화하여 저장하고 삭제 시 암호화 키를 파기하는 방식을 고려해 보세요. 데이터는 남아있더라도 키가 없으면 복구할 수 없으므로 사실상의 삭제와 동일한 효과를 냅니다.

질문: 컴팩션은 시스템 성능에 영향을 많이 주나요?

답변: 네, 컴팩션은 디스크 I/O와 CPU를 많이 사용하는 작업입니다. 따라서 트래픽이 몰리는 피크 타임에는 컴팩션을 피하고, 사용량이 적은 시간대에 예약하여 실행하는 것이 좋습니다. 최근 많은 데이터베이스는 컴팩션 부하를 조절하는 기능을 제공하고 있습니다.

결론적으로 툼스톤은 분산 환경에서 데이터의 무결성을 지키기 위한 필수적인 안전장치입니다. 당장 삭제되지 않는다고 해서 조급해할 필요는 없습니다. 오히려 시스템이 데이터를 안전하게 동기화하고 있다는 신호로 이해하는 것이 좋습니다. 시스템의 특성에 맞게 컴팩션 주기와 툼스톤 유지 시간을 적절히 튜닝한다면, 분산 데이터베이스의 성능과 안정성을 모두 잡을 수 있을 것입니다.