1 CacheDB 이해하기
1.1. Cache 의 개념
Cache 란, 미래의 사용 될 데이터를 빠르게 조회할 수 있는 곳(물리적 장소 또는 소프트웨어로 구현된 위치)에 두고서 사용하는 것을 말한다. 보통 원본 데이터는 다른 곳에 있고 그것으로부터 copy된 데이터가 Cache에 존재한다.
Cache hit: 조회하는 데이터를 Cache에서 찾을 때Cache miss: 조회하는 데이터를 Cache에서 찾지 못했을 때Hit ratio(rate): access 시도 횟수 대비 cache hit 의 비율. 이 값이 (상대적으로) 높으면 캐시가 Cost-Effective 하다.
1.2 Cache의 사용 사례
-
CPU 칩 내에 자주 사용하는 데이터, 또는 최근 사용된 데이터를 임시 저장하는 작은 cache가 있어서, CPU cache에 hit되는 경우 메모리 IO에 의한 속도를 줄일 수 있다.
-
데이터베이스에서 인덱싱 데이터는 메모리에 올려두고 관리하기 때문에, 인덱싱 기준으로 조회하면 조회속도가 빠르다.
-
웹 브라우저에서 최근 방문 기록, 최근 로드한 이미지 등을 임시 저장해서 사이트내 이동 또는 재방문시 웹서비스의 이용을 빠르게 한다.
-
업데이트 할 일이 거의 없는 정보(메타데이터, 설정정보 등)를 어플리케이션 메모리에 올려두고 재사용하고, 주기적으로 또는 업데이트 푸시에 의해서만 cache를 업데이트하는 방법을 사용한다.
1.3 Cache 사용시 고려할 점
-
Cache는 임시 데이터이다. 원본이 다른 곳에 있어야 하고, 언제든 유실될 수 있음을 고려하고 시스템을 설계해야 한다.
-
Cache 저장소는 용량이 (상대적으로) 적고, 용량의 비용이 비싸다. (Cost-Effectiveness)
-
Cost-Effectiveness를 위해서 Cache hit ratio 를 측정하고 높일 수 있는 방법을 고민해야 한다. (Efficient use of data)
1.4 Cache(In-memory) DB란?
데이터를 디스크에 저장하지 않고, 메모리에만 저장한 뒤, 빠른 데이터 조회 및 저장을 제공하는 데이터베이스이다.
일반 데이터베이스는 디스크 IO를 기반으로 동작하고, 효율을 높이기 위해서 memory를 사용한다. 따라서 빠른 조회를 위해서는 데이터베이스가 메모리와 디스크 IO를 활용하는 방식을 이해하면서 설계와 구현을 해야한다. 이것은 어려울 뿐더러, 모든 쿼리에 항상 적용할 수 있는 절대적인 규칙 같은 것이 없다.
하지만, in-memory database는 모든 데이터를 메모리에서 다루고, 저장과 조회 방식도 그것에 맞추어져 있기 때문에 일반적으로 Disk IO 기반의 데이터베이스보다는 조회속도가 빠르다.
다만, 메모리가 디스크보다 가격이 비싸고, 메모리는 용량의 확장에도 제한이 있기 때문에 위에서 이야기한 특징을 고려해서 선택적으로 사용해야한다.
1.5 CacheDB의 종류들
❗ 아래 내용은 각 데이터베이스의 아키텍처와 기능을 기반으로 정리한 것이다. 버전 및 기능 업데이트에 따라 달라질 수 있다.
1.5.1 Memcached
-
구조: 단순한 key-value 형태의 In-Memory Cache 시스템이다.
-
성능: 멀티 스레드 기반으로 고성능 처리가 가능하다. 고트래픽 환경에서도 응답 속도가 안정적이다.
-
메모리 관리: slab allocator를 사용하여 메모리 단편화(memory fragmentation) 문제가 상대적으로 적다(Redis 대비). 다만, 데이터 변경이 잦을 경우 단편화가 발생하기 쉽다.
-
특징:
- 데이터 변경이 적고, 한 번 저장된 후 변경되지 않는 정보를 캐싱할 때 유용하다.
- 메타데이터 사용이 적어 메모리 사용량이 낮은 편이다.
- 복잡한 데이터 구조나 지속성(persistence)을 지원하지 않는다.
1.5.2 Redis
-
구조: 다양한 자료구조를 지원하는 In-Memory 데이터 저장소이다.
-
성능:
Redis는 싱글 스레드 기반으로 동작한다. 이 덕분에 데이터 락(lock)에 대한 걱정 없이, 클라이언트가 read나 write를 자유롭게 실행할 수 있다. 실제로는 여러 클라이언트가 다중 스레드로 Redis에 접속하지만, 모든 명령(command) 실행은 단일 스레드에서 순차적으로 처리된다.
이 아키텍처는 context switching, locking과 같은 비용을 제거하고 빠른 처리 속도를 보장한다.
다만, 트래픽이 과도하게 몰리는 경우, 하나의 스레드만 사용하기 때문에 응답 속도 저하가 발생할 수 있다. -
데이터 구조: 문자열(String), 리스트(List), 해시(Hash), 집합(Set), 정렬된 집합(Sorted Set), 비트맵(Bitmap) 등 다양한 자료구조를 지원한다. 대부분의 자료구조는 O(1) 또는 최적화된 시간복잡도로 작동할 수 있도록 설계되어 있어, 잘못된 사용 방식만 피하면 전체적으로 매우 우수한 성능을 낼 수 있다.
-
지속성:
- RDB (Snapshot): 일정 시점의 메모리 상태를 디스크에 저장.
- AOF (Append Only File): 수행된 모든 쓰기 작업을 순차적으로 기록하여 재실행을 통해 복구 가능.
이러한 메커니즘을 통해 Redis는 인메모리 기반임에도 불구하고 데이터의 영속성(persistence)을 보장한다또한, 지속성을 위해 데이터를 디스크에 저장할 때 CoW(Copy-on-Write) 기법이 사용되며, 이로 인해 실제 데이터 양보다 더 많은 메모리가 일시적으로 필요할 수 있다. RDB 스냅샷 저장이나 AOF rewrite 과정에서는 원본 데이터를 복사하여 유지하기 위한 추가 메모리가 사용되므로, 시스템 메모리 용량에 여유가 있어야 한다.
이 외에도 Redis는 각 key-value에 대한 메타데이터(예: 만료 시간, 타입 정보 등)를 함께 저장하므로, 실제 데이터의 크기보다 메모리 사용량이 더 커질 수 있다.
-
특징:
- 풍부한 기능과 넓은 커뮤니티를 갖추고 있다.
- 다양한 언어와 플랫폼에서의 지원이 우수하다.
- 복잡한 데이터 구조, 고급 기능(예: Pub/Sub, Lua 스크립트, 트랜잭션 등)이 필요한 경우에 적합하다.
- dis는 전체적으로 “빠른 성능 제공”을 아키텍처 설계 목표로 삼은 시스템이다.
1.5.3 Couchbase
-
구조: In-Memory First Document Database로, JSON 기반의 Document 지향 데이터 저장소이다. 내부적으로는 Key-Value 구조지만, Value로 Document(JSON 객체)를 저장한다.
-
성능: 메모리 우선 아키텍처로 빠른 데이터 접근 및 처리가 가능하다.
-
확장성: 분산 클러스터 아키텍처로 구성되어 있어 수평적 확장이 용이하다.
-
특징:
- SQL과 유사한 N1QL 쿼리 언어를 지원하여 복잡한 쿼리 처리가 가능하다.
- Secondary Index, Full-Text Search, Vector Search 등 고급 기능을 지원한다.
- 메모리 전용 버킷(Ephemeral Buckets)과 디스크 지속성 버킷을 선택적으로 사용할 수 있다.
- 무료 버전에서는 일부 기능 제한 및 안정성 이슈가 발생할 수 있다.
secondary index
Key-Value 구조는 key 하나로만 데이터를 조회할 수 있다.
하지만 Couchbase는 세컨더리 인덱스 도큐먼트 안에 있는 다른 정보를 가지고 인덱싱을 해서 빨리 다른 기준으로도 조회할 수 있게 해준다. 즉, key 외의 다른 값으로도 검색이 가능하게 해주는 기능이다.
1.6 왜 Redis를 배울까?
데이터 엔지니어링에서는 대용량 트래픽을 주로 다루므로 클라이언트 요청 처리에 멀티스레드를 사용하는 memcached나, document(multi-model)을 지원하는 Couchbase가 필요할수 있다.
하지만 다음과 같은 이유로 Redis는 In-Memory DB 선택시 가장 우선적인 고려대상이 된다.
- Redis는 CacheDB의 기본적인 목표인 가장 빠른 조회속도를 내기 가장 쉽다. 자료구조의 설계와 사례가 용도에 따라 명확하기 때문이다. 몇 가지 주의사항만 지켜주면 일반적으로 빠른 속도를 낸다.
- 분산 클러스터 모드를 지원하므로 확장성도 제공할 수 있다.
- 자료구조와 기능이 다양하다.
- Self-Managed 하기에 레퍼런스가 충분히 많고, managed service 도 여러 회사에서 지원한다.
