카산드라와 TTL, 툼스톤 그리고 관련 동작(컴팩션)

카산드라에서는 데이터의 TTL 또는 삭제에 의해 데이터가 바로 삭제되는 것이 아니라 툼스톤을 사용하여 데이터를 삭제합니다. 카산드라와 같은 분산 데이터베이스에서 데이터를 바로 삭제하는 것은 매우 어려운 일입니다. 그렇기 때문에 데이터를 삭제하기 전에 툼스톤이라고 불리는 플래그를 사용하여 해당 데이터가 삭제 대기로 옮긴 이후 추후에 데이터를 삭제시킵니다. 관련 동작을 알기 위해서는 우선 컴팩션이 무엇인지 알아보아야 합니다.

 

컴팩션(Compaction)

카산드라에서 컴팩션은 최고의 성능을 내기 위해 적재된 데이터(SSTable)를 결합하는 행위를 뜻합니다. 반면, 압축은 컴프레션이므로 컴팩션과 햇갈려서는 안됩니다. 카산드라에서 컴팩션은 다음과 같은 전략을 제공합니다. 사용방법에 따라 적합한 전략의 컴팩션을 선택해야만 합니다.

 

- Size Tiered Compaction Strategy (STCS)
기본 설정 전략입니다. 다른 전략이 적합하지 않을 경우 이것을 사용하는 것이 좋습니다. HDD를 사용하거나 LCS사용시 I/O 부하가 많을 경우 사용하면 좋습니다.

- Leveled Compaction Strategy (LCS)
LCS는 읽기 작업이 많을 경우 사용하면 좋습니다. 또는 업데이트와 삭제가 자주 일어날때도 적합합니다. 만약 시간순으로 되어 있는 데이터가 오랜 시간 데이터가 변하지 않는 경우에는 적합하지 않습니다.

- Time Window Compaction Strategy (TWCS)
TTL을 위해 디자인되었습니다. 시간순으로 되어 있는 데이터가 변하지 않을 경우 적합합니다.

 

컴팩션의 종류

카산드라 내부에서 운영방식에 따라 여러 방식의 컴팩션이 동작합니다. 컴팩션이 일어나는 가장 일반적인 사항은 하나 또는 2개 이상의 SSTable을 새로운 SSTable로 나타내는 것입니다. 컴팩션의 종류는 다음과 같습니다.

 

- Minor compaction

카산드라가 자동으로 트리거링 되는 컴팩션

 

- Major compaction

사용자가 노드의 모든 SSTable에 트리거하는 컴팩션

 

- User defined compaction

사용자가 노드의 특정 SSTable에 트리거하는 컴팩션

 

- Scrub

이슈가 생긴 SSTable을 고치기 위한 동작. 데이터에 이상이 있을 경우 수행

 

- UpgradeSSTables

SSTable을 가장 최신버전으로 업그레이드 하는 것. major version 업그레이드 이후 실행됨.

 

- Cleanup

대상 노드가 더 이상 클러스터 소속이 아닐 경우 트리거됨. 

 

- Secondary index rebuild

노드의 세컨더리 인덱스를 리빌드하는 것

 

- Anticompaction

SSTable들을 고치고 난 이후 분산된 데이터를 고치는 것

 

- Sub range compaction

nodetool compact -st x -et y를 통해 토큰의 오동작을 고치기 위해 수행.

마이너 컴팩션은 언제 트리거링 될까?

- 노드의 sstable이 flushing/streaming을 통해 추가되는 경우

- autocompaction이 중지되어 있다가 재시작 될 경우 > nodetool enableautocompaction

- SSTable이 신규로 추가되는 경우

- 매 5분마다 수행

 

SSTable의 병합

컴팩션은 SSTable을 병합하는 과정입니다. 파티션들은 SSTable들에 정렬되어 있고 파티션 키를 기반으로 해시되어 병합하기 적합하게 되어 있습니다. 각 파티션은 정렬되어 있으므로 병합에 적합합니다.

 

툼스톤과 GC(Garbage Collection) Grace

카산드라에서 데이터를 삭제하면 실제로 데이터가 삭제되지 않습니다. 대신 툼스톤이라는 플래그로 삭제 예정임을 지정합니다. 툼스톤이 마크된 데이터는 쿼리를 하더라도 데이터가 나타나지 않습니다. 이는 분산 시스템은 카산드라에서 일반적인 방삭입니다.

 

툼스톤 없이 데이터 삭제한다면?

만약 3개의 노드에 A가 존재한다고 가정해봅시다.

[A], [A], [A]

만약 1개 노드에 이슈가 생겨 데이터가 다음과 같이 남아 있다고 가정해봅시다.

[], [], [A]

다시 노드를 고치고 나면 데이터는 다음과 같이 싱크됩니다.

[A], [A], [A]

삭제되어야 하지만 데이터가 다시 재생성되어 버리는 것입니다.

 

툼스톤을 적용하여 데이터 삭제하기

A가 3개 노드에 존재한다고 가정해봅시다.

[A], [A], [A]

A를 바로 삭제하는 대신 tombstone을 통해 삭제하는 것을 지정합니다. 그와 마지막 노드에 이슈가 생긴 것을 가정하였습니다.

[A, Tombstone[A]], [A, Tombstone[A]], [A]

노드가 복구되고 나면 해당 데이터는 tombstone이 새워진 것을 알 수 있으므로 tombstone이 싱크됩니다.

[A, Tombstone[A]], [A, Tombstone[A]], [A, Tombstone[A]]

복구가 되고 나서도 A는 삭제 대상인 것을 모든 노드에서 알 수 있게 됩니다. 하지만 그만큼 데이터는 즉각적으로 삭제되지 않고 디스크에 남게 됩니다. tombstone이 마킹된 데이터가 영원히 남지 않도록 gc_grace_seconds 파라미터를 지정할 수 있습니다.

 

gc_grace_seconds와 툼스톤 삭제

gc_grace_seconds는 테이블 단위로 설정할 수 있습니다. 이 옵션은 컴팩션을 통해 데이터가 최종적으로 삭제되기 전까지 유예 시간을 지정할 수 있습니다. 이 유예 시간 동안 노드에 장애가 났을 경우 대응할 수 있게 됩니다. gc_grace_seconds가 지나고 난 이후에 툼스톤 마크는 삭제됩니다. 그러나 데이터 자체는 sstable에 남아 있게 됩니다. 데이터가 완전히 삭제되려면 다음과 같은 요구사항이 충족되어야만 합니다.

 

- 툼스톤 데이터가 gc_grace_seconds 시간을 넘긴 경우

- 만약 특정 파티션이 툼스톤일 경우, sstable은 더 시간이 오래된 툼스톤 데이터(동일 파티션)를 찾아서 같이 컴팩션을 수행. 우리가 이 파티션에 대해 고려할 필요는 없음. 

- 만약 only_purge_repaired_tombstones 옵션이 true일 경우, 툼스톤 데이터는 repair될 때만 삭제됨.

 

만약 노드가 down 상태이거나 연결이 끊킨 상태에서 gc_grace_seconds를 지날 경우 삭제 대상 데이터는 클러스터의 다른 노드에서 다시 나타날 수 있습니다. 이것은 툼스톤 없이 데이터를 삭제하는 상황과 동일합니다. 이런 상태에서는 gc_grace_seconds가 지나고 나서도 툼스톤은 삭제되지 않습니다.

 

gc_grace_seconds의 기본값은 10일(864000초) 이고 WITH gc_grace_seconds를 통해 테이블 단위로 설정 가능 합니다.

 

TTL

카산드라의 데이터는 TTL(time to live)를 설정 할 수 있습니다. 이를 통해 시간이 지난 데이터를 만료시켜 삭제할 수 있습니다. TTL이 지난 데이터는 툼스톤이 마킹되며 gc_grace_seconds 동안 유지됩니다. 만약 TTL 데이터와 TTL이 아닌 데이터가 섞여 있을 경우 카산드라는 SSTable들이 컴팩션 되더라도 툼스톤 데이터를 삭제되지 않을 수도 있습니다.

Note that if you mix data with TTL and data without TTL (or just different length of the TTL) Cassandra will have a hard time dropping the tombstones created since the partition might span many SSTables and not all are compacted at once.

 

SSTable의 완전 만료

만약 sstable이 툼스톤 데이터만으로 가득 찼을 경우 sstable은 다른 sstable과 병합하지 않고 drop될 수 있습니다. 만약 툼스톤으로만 가득찬 sstable이 있지만 컴팩션으로 인해 데이터가 삭제되지 않는다면 sstable이 오래된 데이터를 가지고 있을 가능성이 있습니다. 이 때 sstableexpiredblockers 툴을 사용하여 sstable을 삭제할 수 있습니다. TimeWindowCompactionStrategy를 사용할 경우 유용합니다.

 

단일 sstable의 툼스톤 컴팩션

만약 sstable에 툼스톤이 만료된 데이터가 있을 경우 단일 sstable 컴팩션을 수행하여 데이터를 삭제할 수 있습니다. 이를 시작하기 전에 다른 sstable에 겹치는 툼스톤이 있는지 확인하는 과정을 거칩니다. unchecked_tombstone_compaction이 true라면 이런 체크 과정을 스킵한다.

 

컴팩션 관련 옵션들

- enabled (default: true)
마이너 컴팩션 동작을 수행할 것인지 여부를 설정.

- tombstone_threshold (default: 0.2)

툼스톤이 얼마나 찼을 때 단일 sstable에 컴팩션을 수행할 지 여부를 설정.

- tombstone_compaction_interval (default: 86400s (1 day))
단일 sstable 컴팩션을 수행해도 툼스톤 데이터가 삭제되지 않았을 때 recompact가 되지 않도록 설정. 이 옵션을 통해 sstable이 얼마나 컴팩션을 수행하는지 지정 가능

- log_all (default: false)
컴팩션 관련 내용을 로깅

- unchecked_tombstone_compaction (default: false)
단일 sstable 컴팩션을 수행할 때 다른 sstable을 체크할 것인지 여부를 설정. 

- only_purge_repaired_tombstone (default: false)
repair를 수행할 때 툼스톤 데이터를 삭제할 것인지 여부를 설정

- min_threshold (default: 4)

컴팩션을 수행할 때 최소 sstable 개수. LeveledCompactionStrategy에서는 적용되지 않음.

- max_threshold (default: 32)

컴팩션을 수행할 때 최대 sstable 개수. LeveledCompactionStrategy에서는 적용되지 않음.

 

관련 출처

- https://cassandra.apache.org/doc/latest/cassandra/operating/compaction/index.html

Compaction | Apache Cassandra Documentation