[Redis] CacheDB 이해하기 - 1

해당 글에서는 Redis에 대해 본격적으로 사용해보기 전에 Cache/CacheDB란 무엇이고 다양한 CacheDB중에 왜 Redis를 사용하는지를 알아보겠습니다.

 

Cache란?

Cache 란, 미래의 사용 될 데이터를 빠르게 조회할 수 있는 곳(물리적 장소 또는 소프트웨어로 구현된 위치)에 두고서 사용하는 것을 말합니다. 보통 원본 데이터는 다른 곳에 있고 그것으로부터 copy된 데이터가 Cache에 존재합니다.

 

주요 개념

• Cache hit: 조회하는 데이터를 Cache에서 찾을 때
• Cache miss:조회하는 데이터를 Cahe에서 찾지 못했을 때
• Hit ratio(rate): access시도 횟수 대비 cache hit의 비율. 이 값이(상대적으로) 높으면 캐시가 Cost-Effective하다.

캐시를 사용하는 목표는 Cost-Effective(비용 효율적)를 달성하는 것입니다.

 

 

Cache의 사용 사례

1. CPU칩 내에 자주 사용하는 데이터, 또는 최근 사용된 데이터를 임시 저장하는 작은 cache가 있어서, CPU cache에 hit되는 경우 메모리 IO에 의한 속도를 줄일 수 있습니다.
2. 데이터베이스에서 인덱싱 데이터는 메모리에 올려두고 관리하기 때문에, 인덱싱 기준으로 조회하면 조회속도가 빠릅니다.
3. 웹 브라우저에서 최근 방문 기록, 최근 로드한 이미지 등을 임시 저장해서 사이트내 이동 또는 재방문시 웹서비스의 이용을 빠르게 합니다.
4. 업데이트 할 일이 거의 없는 정보(메타데이터, 설정정보 등)를 어플리케이션 메모리에 올려두고 재사용하며, 주기적으로 또는 업데이터 푸시에 의해서만 cache를 업데이트 하는 방법을 사용합니다.

 

Cache 사용 시 고려할 점

1. Cache는 임시 데이터입니다. 원본이 다른 곳에 있어야 하고, 언제든 유실될 수 있음을 고려하고 시스템을 설계해야합니다.
2. Cache 저장소는 용량이 (상대적으로) 적고, 용량의 비용이 비쌉니다. (Cost-Effectiveness)
3. Cost-Effctivenss를 위해서 Cache hit ratio를 측정하고 높일 수 있는 방법을 고민해야 합니다.

 

Cache(In-memory) DB란?

데이터를 디스크에 저장하지 않고, 메모리에만 저장한 뒤, 빠른 데이터 조회 및 저장을 제공하는 데이터베이스입니다.

 

일반 데이터베이스는 디스크 IO를 기반으로 동작하고, 효율을 높이기 위해서 memory를 사용합니다. 따라서 빠른 조회를 위해서는 데이터베이스가 메모리와 디스크 IO를 활용하는 방식을 이해하면서 설계와 구현을 해야합니다. 이것은 어려울 뿐더러, 모든 쿼리에 항상 적용할 수 있는 절대적인 규칙 같은 것이 없습니다.

 

하지만, In-memory database는 모든 데이터를 메모리에서 다루고, 저장과 조회 방식도 그것에 맞추어져 있기 때문에 일반적으로 Disk Io기반의 데이터베이스보다는 조회속다가 빠릅니다.

 

다만, 메모리가 디스크보다 가격이 비싸고, 메모리는 용량의 확정에도 제한이 있기 때문에 위에서 이야기한 특징을 고려해서 선택적으로 사용해야합니다.

 

 

CacheDB의 종류들

1. Memcached

• Key-Value 형식의 데이터 저장 및 조회를 제공하는 In-memory database입니다.
• 멀티 스레드로 데이터를 다룹니다. 때문에, 트래픽이 몰려도 Memcached의 응답 속도는 (레디스와 비교해서 상대적으로) 안정적입니다.
• 내부적으로 slab allocator를 사용하고 있어서, *memory fragmentation문제가 상대적으로 적습니다. 단, 데이터 변경이 잦은 경우에서는 fragmentation이 발생하기 쉽습니다.
• Memcached는 한 번 저장된 후, 변경되지 않는 정보를 저장할 때 유용합니다.
• Redis에 비하면 메타 데이터를 적게 사용하기 때문에 메모리 사용량이 상대적으로 낮습니다.

*memory fragmentation(메모리 단편화): Ram에서 메모리의 공간이 작은 조각으로 나뉘어져 사용가능한 메모리가 충분히 존재하지만 할당(사용)이 불가능한 상태를 보고 메모리 단편화가 발생했다고 합니다.

 

2. Redis

• Redis는 다양한 자료구조를 API로 제공하는 In-memory database입니다. (기본적으로 key-value)
• 싱슬 스레드이며, 한 번에 하나의 client만 자료를 저장/조회 하기 때문에 데이터 lock없이 빠르게 데이터를 조회할 수 있습니다. 하지만 트래픽이 몰리면 응답속도가 불안정한 경우가 있습니다.
• 실제 데이터의 양보다 더 많은 메모리가 필요합니다. (메타데이터, CoW 사용 여부 등에 영향)
• In-Memory Database종류 중에서 가장 기능이 풍부하고 레퍼런스도 많습니다.
• 원하는 경우 Disk에 persistent하게 데이터를 백업 가능합니다. (대신 성능의 손해를 고려해야합니다.)

3. Couchbase

• In-memory First Document Database입니다. 데이터를 Document단위로 저장하고, Document내의 필드도 key-value로 조회할 수 있습니다. Memory first이기 때문에 조회속도도 빠르고, 분산 클러스터 아키텍처로 구성되어 있어서 확정성도 좋습니다.
• Secondary-index, SQL등 다른 in-memory database에서 지원하지 않는 기능ㄷ르도 지원합니다.
• Document Database처럼 사용할 수 있지만, 특정 자료구조를 원하는 경우에는 Redis, memcached보다 느릴 수 있습니다.
• Client 라이브러리가 충분히 효율적이지 않고, 무료 버전의 안정성과 기능에 한계가 있습니다.

 

Redis를 선택한 이유

데이터 엔지니어링에서는 대용량 트래픽을 주로 다루므로 클라이언트 요청 처리에 멀티스레드를 사용한 memcached나, document(multi-model)을 지원하는 Couchbase가 필요할 수 있습니다.

 

하지만 다음과 같은 이유로 Redis는 In-Memory DB 선택 시 가장 우선적인 고려대상이 됩니다.

1. Redis는 CacheDB의 기본적인 목표인 가장 빠른 조회속도를 내기 가장 쉽습니다. 자료구조의 설계와 사례가 용도에 따라 명확하기 때문입니다. 몇 가지 주의사항만 지켜주면 일반적으로 빠른 속도를 냅니다.
2. 분산 클러스터 모드를 지원하므로 확장성도 제공할 수 있습니다.
3. 자료구조와 기능이 다양합니다.
4. Self-Managed하기에 레퍼런스가 충분히 많고, managed service도 여러 회사에서 지원합니다.

 

다음글 에서는 Redis의 자료형식과 기능에 대해 알아보겠습니다.