OpenSearch와 RocksDB는 생각보다 닮아있다

서비스 규모가 작을 때는 데이터를 어떻게 저장하는지 크게 신경 쓰지 않는다. 하지만 로그가 하루 수백만 건, 수천만 건씩 쌓이기 시작하면 저장 방식 자체가 시스템 성능을 결정하게 된다. 최근 로그 엔진과 저장소 구조를 공부하면서 재밌는 점을 발견했다. 검색 엔진인 OpenSearch와 Key-Value 저장소인 RocksDB는 전혀 다른 제품처럼 보이지만 내부 구조를 살펴보면 비슷한 철학을 가지고 있다.

왜 데이터를 수정하지 않을까?

일반적으로 데이터베이스는 데이터를 수정할 때 기존 데이터를 덮어쓴다.

사용자 수정
    ↓
기존 데이터 수정
    ↓
디스크 기록

데이터가 적을 때는 문제가 없다. 하지만 로그 시스템은 초당 수천 건에서 수만 건 이상의 쓰기가 발생한다. 이 상황에서 기존 파일을 계속 수정하면 다음과 같은 문제가 발생한다.

• 랜덤 디스크 쓰기 증가
• 파일 잠금(Lock) 발생
• 디스크 I/O 병목
• 성능 저하

그래서 대부분의 로그 엔진은 다른 방식을 선택한다.

기존 데이터를 수정하지 않는다. 대신 새로운 데이터를 계속 추가한다.

OpenSearch의 저장 방식

OpenSearch는 내부적으로 Lucene을 사용한다. 문서(Document)가 들어오면 기존 Segment를 수정하지 않는다. 대신 새로운 Segment를 생성한다. Segment가 많아지면 백그라운드에서 Merge 작업을 수행하여 큰 Segment로 합친다.

즉,

1. 데이터를 빠르게 저장한다.
2. 작은 Segment를 만든다.
3. 나중에 정리한다.

라는 전략을 사용한다.

RocksDB의 저장 방식

RocksDB 역시 비슷한 접근 방식을 사용한다. 쓰기 요청은 먼저 MemTable에 기록된다. MemTable이 가득 차면 SSTable 파일로 Flush 된다. 그리고 여러 SSTable이 생성되면 Compaction을 통해 정리된다.

여기서 Compaction은 OpenSearch의 Merge와 거의 같은 역할을 한다.

LSM Tree란 무엇?

RocksDB는 LSM Tree(Log Structured Merge Tree) 기반으로 동작한다. 이 구조의 핵심은 다음과 같다.

데이터를 바로 수정하지 않고 작은 파일로 저장한 뒤 나중에 합친다.

쓰기 성능을 극대화할 수 있다는 장점이 있다. 반면 Compaction이 잘못 설계되면 시스템 전체 성능에 영향을 줄 수 있다.

OpenSearch와 RocksDB 비교

처음에는 전혀 다른 기술처럼 보인다. 하지만 내부 동작을 보면 둘 다 같은 문제를 해결하고 있다.

대량의 데이터를 어떻게 빠르게 저장할 것인가?

사실 Splunk도 비슷하다

Splunk 역시 데이터를 Bucket 단위로 관리한다.

Hot Bucket
    ↓
Warm Bucket
    ↓
Cold Bucket
    ↓
Frozen

용어는 다르지만 철학은 같다. 작은 단위로 저장하고 시간이 지나면서 정리한다.

결국 중요한 것은 Merge다

많은 사람들이 검색 속도나 저장 공간에 관심을 가진다. 하지만 대규모 시스템에서는 Merge 정책이 전체 성능을 결정하는 경우가 많다.

예를 들어,

• Merge가 너무 적으면 파일 수가 증가한다.
• Merge가 너무 많으면 디스크 사용량이 증가한다.
• Merge가 느리면 검색 성능이 저하된다.
• Merge가 과하면 쓰기 성능이 저하된다.

결국 데이터 규모가 커질수록 중요한 것은 저장 기술 자체보다

데이터를 언제, 어떻게 합칠 것인가

가 된다.

이름만 다를 뿐 같은 철학

아래 그림은 OpenSearch, RocksDB, Splunk의 공통된 구조를 단순화한 것이다.

처음에는 서로 다른 기술처럼 보인다. 하지만 결국 모두 같은 전략을 사용한다.

1. 빠르게 저장한다.
2. 작은 단위로 쪼갠다.
3. 백그라운드에서 정리한다.
4. 검색 성능을 유지한다.

마치며

로그 엔진을 공부하면서 느낀 점은 저장 엔진의 핵심은 검색이 아니라 정리(Merge)라는 것이다. 데이터가 적을 때는 모든 구조가 비슷해 보인다. 하지만 수십억 건 이상의 데이터가 쌓이기 시작하면 Merge 전략이 곧 성능이 된다. OpenSearch의 Segment Merge, RocksDB의 Compaction, Splunk의 Bucket Roll은 이름만 다를 뿐 결국 같은 문제를 해결하기 위한 방법이다.

데이터를 수정하지 말고 계속 쌓아라. 대신 나중에 잘 합쳐라.

대규모 로그 시스템의 많은 설계는 이 단순한 철학에서 시작되는 것 같다.