Scylladb로 외부 캐쉬 대체 조사

ScyllaDB로 외부 캐쉬 대체 할 수 있다는 주장의 글을 읽고 Comet으로 조사한 내용.

ScyllaDB의 메모리 캐시 대체 주장: 벤치마크와 실사용 분석

ScyllaDB는 Redis, Memcached 같은 외부 메모리 캐시 시스템을 대체할 수 있다고 주장하고 있습니다. 이는 단순한 마케팅이 아니라 실제 벤치마크와 프로덕션 환경에서의 검증된 사례들로 뒷받침되고 있습니다.

ScyllaDB vs Memcached 공식 벤치마크

2024년 ScyllaDB는 Memcached 메인테이너 dormando와 협력하여 중립적인 비교 벤치마크를 수행했습니다. 이 벤치마크는 양측이 함께 설계하고 검증한 매우 신뢰할 수 있는 결과입니다.[1][2]

메모리 효율성

Memcached는 114GB 메모리에 약 1억 100만 개의 아이템을 저장할 수 있었던 반면, ScyllaDB는 6천만~6천 100만 개의 아이템을 저장했습니다. Memcached가 약 65% 더 많은 메모리 내 아이템을 저장할 수 있었습니다. 이는 ScyllaDB가 wide-column 지향 구조를 지원하기 위해 추가 메타데이터(타임스탬프, row liveness 등)와 Bloom Filter, Index를 메모리에 유지해야 하기 때문입니다.[1]

순수 메모리 읽기 성능

• Memcached: 초당 300만 GET 요청, 25Gbps NIC 대역폭 완전 포화, P99.999 레이턴시 1ms 미만[1]
• ScyllaDB: 데이터 모델 조정 후(16개 clustering key 사용) 초당 약 300만 row 처리(187K 읽기 작업 × 16 rows), 동일하게 네트워크 대역폭 완전 포화, 서버측 P99 레이턴시 1ms 이내, 클라이언트측 P99 0.9ms[1]

두 시스템 모두 네트워크 대역폭을 완전히 포화시키며 유사한 성능을 달성했습니다.[1]

디스크 기반 워크로드

Memcached Extstore로 1KB 아이템 테스트:

• 64 IO 쓰레드: 256K GET/초, P99 레이턴시 1-2ms[1]
• 32 IO 쓰레드: 182K GET/초, P99 레이턴시 1ms 미만[1]

ScyllaDB 동일 조건:

• 1KB: 268.8K GET/초, 서버측 P99 2ms, 클라이언트측 P99 2.4ms[1]
• 8KB: 156.8K GET/초, 서버측 P99 1.54ms, 클라이언트측 P99 1.9ms[1]

ScyllaDB는 디스크 기반 워크로드에서 더 높은 처리량을 보였지만, 단일 요청에 대해서는 Memcached의 레이턴시가 약간 더 낮았습니다.[2][1]

종합 평가

벤치마크 결론에 따르면, "올바르게 구성하면 두 시스템 모두 우수한 비용 절감 효과를 제공할 수 있다"며 단순 승패가 아닌 용도에 따른 선택의 문제라고 설명합니다. 단순 key-value 모델과 파이프라이닝이 가능한 워크로드라면 Memcached가 적합하지만, 복잡한 데이터 모델이 필요하다면 ScyllaDB가 더 적합합니다.[1]

실제 프로덕션 사례

Comcast: 가장 인상적인 사례

전환 규모

• Cassandra 962 노드 + Redis 캐시 서버 60대 → ScyllaDB 78 노드[3][4]
• 연간 250만 달러 인프라 비용 절감 (60% 절감)[3]
• P99, P999, P9999 레이턴시 95% 감소[3]

Comcast의 Xfinity 서비스는 1,500만 가구에 일 20억+ API 호출과 일 2억+ 신규 객체를 처리합니다. Cassandra의 긴 tail 레이턴시 문제를 해결하기 위해 60대의 캐시 서버를 두었으나, 캐시와 데이터베이스 간 일관성 유지가 큰 관리 부담이었습니다. ScyllaDB로 전환 후 외부 캐시 레이어를 완전히 제거하고 10배 레이턴시 개선과 2배 이상의 처리량을 달성했습니다.[4][3]

SecurityScorecard: Redis + Aurora → ScyllaDB

성과

• 레이턴시 90% 감소 (4.5초 → 303ms)[5]
• 연간 100만 달러 인프라 비용 절감[5]
• 데이터 처리 파이프라인 30% 속도 향상[5]
• Presto/Aurora 관련 프로덕션 장애 80% 감소[5]

SecurityScorecard는 1,200만 개 스코어카드를 처리하기 위해 Redis를 사용했으나, 가장 큰 Redis 인스턴스로도 확장에 한계가 있었고 Aurora는 쓰기 집약적 워크로드에서 레이턴시 스파이크 문제가 있었습니다. ScyllaDB Cloud로 전환하여 이러한 모든 문제를 해결했습니다.[5]

Grab: Redis 캐시 완전 제거

실험 세부 사항

Grab의 카운터 서비스는 Scylla + Redis 캐시 조합으로 운영 중이었습니다. 피크 시간에 수만 QPS를 처리하며, 각 요청은 평균 10개의 Scylla 조회를 수반합니다. Redis 캐시가 전체 요청의 50%를 처리했으나, 15분마다 캐시 미스로 인한 Scylla QPS 스파이크가 발생했습니다.[6][7]

점진적 제거 프로세스

• 2024년 11월 5일~13일, 8일간 점진적 실험[6]
• 5% → 25% → 35% → 75% → 100% 구성에 대해 캐시 비활성화[6]

결과

• Redis 제거 후에도 서비스 성능 유지[7][6]
• Scylla 자체 캐시 히트율 30% → 70%로 증가[6]
• 전체 서비스 비용의 25% 차지하던 Redis 제거[7][6]
• 평균 레이턴시 6-8ms → 7-12ms로 소폭 증가했으나, 추가 컴팩션 작업으로 원래 수준 회복[6]
• Scylla CPU 사용률은 50% → 52%로 미미한 증가만 발생[6]

이 사례는 ScyllaDB의 내부 캐시가 Redis 외부 캐시를 충분히 대체할 수 있음을 실증했습니다.[7][6]

Expedia: Redis + Cassandra → ScyllaDB

성과

• 35% 인프라 비용 절감[3]
• P99 읽기 레이턴시 20-80ms → 일관되게 5ms[3]
• Cassandra 대비 3배 처리량[3]

Expedia는 지리 정보 애플리케이션을 위해 Redis를 1차 캐시 레이어로, Cassandra를 2차 영구 저장소로 사용했습니다. Cassandra의 가비지 컬렉션 튜닝과 트래픽 버스트 시 P99 응답시간 영향이 주요 문제였습니다.[3]

ScyllaDB vs MongoDB 캐싱 워크로드 벤치마크

BenchANT가 수행한 독립적인 벤치마크에서 캐싱 워크로드(YCSB Workload A: 50% read, 50% update) 테스트 결과:[8][9]

처리량 비교

• 소형 클러스터: ScyllaDB 77K ops/s vs MongoDB 5K ops/s
• 중형 클러스터: ScyllaDB 306K ops/s vs MongoDB 17K ops/s
• 대형 클러스터: ScyllaDB 894K ops/s vs MongoDB 45K ops/s

레이턴시

• ScyllaDB는 모든 구성에서 P99 레이턴시 10ms 미만 달성[9][8]
• MongoDB 업데이트 레이턴시는 ScyllaDB 대비 최대 68배 더 높음[9]
• 읽기 레이턴시도 ScyllaDB가 2.8배 더 낮음[9]

비용 효율성

• 소형: ScyllaDB가 12-16배 더 나은 ops/$ 제공[8][9]
• 중대형: ScyllaDB가 18-20배 더 나은 ops/$ 제공[8][9]

심지어 3노드 ScyllaDB 클러스터가 18노드 MongoDB 클러스터보다 나은 성능을 보였습니다.[10][9]

ScyllaDB 내부 캐시 아키텍처의 핵심

ScyllaDB가 외부 캐시를 대체할 수 있는 이유는 독자적인 내부 캐시 설계에 있습니다:[11][12]

Linux 페이지 캐시 우회

ScyllaDB는 읽기 시 Linux 페이지 캐시를 완전히 우회하고 자체 row 기반 캐시를 사용합니다. Linux 페이지 캐시는 범용 캐시로 데이터베이스 특화 요구사항(부정적 캐싱, 중복 버퍼, 높은 CPU 오버헤드 등)에 비효율적이기 때문입니다.[12][11]

통합 캐시 설계

• 쓰기 시 Commitlog → Memtable(RAM) → 플러시 시 SSTable(디스크)로 이동[13][11]
• Memtable 플러시 시 내용을 캐시와 병합하여 메모리 효율 극대화[11]
• 자주 액세스되는 데이터를 SSTable에서 RAM 캐시로 자동 승격[13]
• 워크로드에 따라 동적으로 자가 튜닝되며 메모리 압력에 따라 확장/축소[12]

Cassandra와의 차이점

Apache Cassandra는 여러 경쟁하는 캐시들(row cache, key cache, chunk cache 등)을 수동으로 튜닝해야 하지만, ScyllaDB는 단일 통합 캐시로 자동 관리됩니다.[12]

성능 특성 요약

처리량

• 단일 노드에서 100만+ ops/sec 달성 가능[14][15]
• 클러스터로 확장 시 수억~수십억 ops/sec 달성[16][14]

레이턴시

• P99 레이턴시 1ms 미만 (메모리 워크로드)[14][1]
• P99 레이턴시 2-10ms (디스크 혼합 워크로드)[17][1]
• 100만 ops/sec 이상에서도 single-digit ms 레이턴시 유지[18][19]

비용 효율

• 동일 성능 대비 10분의 1 노드 수로 운영 가능[15][20]
• 연간 수십만~수백만 달러 인프라 비용 절감 사례 다수[5][3]

제약사항과 고려사항

1. 메모리 효율성

순수 메모리 캐싱 측면에서 Memcached가 약 65% 더 많은 아이템을 저장할 수 있습니다. ScyllaDB는 영속성과 복잡한 쿼리 지원을 위한 추가 메타데이터가 필요합니다.[1]

2. 단순 Key-Value 워크로드

매우 단순한 key-value 조회만 필요하고 파이프라이닝이 가능한 경우, Memcached의 프로토콜이 더 가볍고 효율적입니다. ScyllaDB의 CQL 프로토콜은 더 풍부한 기능을 제공하지만 상대적으로 무겁습니다.[1]

3. 레이턴시 민감도

Redis는 1ms 미만의 극저지연이 필수적인 워크로드에 여전히 강점이 있습니다. ScyllaDB는 디스크 기반 시스템으로 1-10ms 범위의 레이턴시를 제공합니다.[21]

4. 학습 곡선

Redis/Memcached는 단순하고 빠른 설정이 가능한 반면, ScyllaDB는 데이터 모델링과 쿼리 패턴에 대한 더 깊은 이해가 필요합니다.[5]

결론: 언제 ScyllaDB가 캐시 대체로 적합한가

ScyllaDB는 다음 조건에서 Redis/Memcached를 효과적으로 대체할 수 있습니다:

적합한 경우

• 데이터 영속성이 필요한 경우[1]
• 수백만~수십억 개 이상의 대규모 데이터셋[1]
• 복잡한 쿼리나 wide-column 데이터 모델 필요[1]
• 외부 캐시와 데이터베이스 간 일관성 유지가 부담스러운 경우[3]
• 1-10ms 레이턴시가 허용 가능한 경우[6][5][3]
• 인프라 비용 절감이 중요한 경우[5][3]

부적합한 경우

• 마이크로초~1ms 미만의 극저지연 필수[21]
• 극도로 단순한 key-value 조회만 필요[1]
• 매우 작은 데이터셋 (수백 MB 이하)[1]
• 파이프라이닝이 핵심적인 워크로드[1]

실제 프로덕션 사례들(Comcast, Grab, SecurityScorecard, Expedia 등)은 ScyllaDB의 주장이 단순한 마케팅이 아니라 실제로 검증된 솔루션임을 보여줍니다. 특히 Grab의 사례는 동일한 워크로드에서 Redis를 완전히 제거하고도 성능을 유지하며 25%의 비용을 절감한 것으로, ScyllaDB의 내부 캐시가 외부 캐시 시스템을 충분히 대체할 수 있음을 실증합니다.[7][6]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87