윤영 교수님 기초데이터베이스 수업을 듣는데 계속 Memcached 언급을 하셔서 좀 더 알아보기로 했다. 시험에도 십자말풀이 문제로 내셨었고, 수업에서는 분산 시스템 설명 중 Facebook에서 선택한 기술인데 당연히 알아야 되지 않을까요? 하는 뉘앙스로 언급하셨다.
1. Memcached란 무엇인가?
Memcached는 데이터베이스의 부하를 줄여 웹 애플리케이션의 속도를 높이기 위해 설계된 고성능 분산 메모리 객체 캐싱 시스템이다.
2003년에 처음 개발되어 무려 20년이 넘은 기술이지만, 페이스북(Meta), 넷플릭스 등 글로벌 빅테크 기업들은 여전히 핵심 인프라에 Memcached를 사용하고 있다. 그 이유가 무엇일까?
2. Memcached의 핵심 아키텍처: Slab Allocation
Memcached가 왜 빠른지를 설명할 때 빠지지 않는 개념이 바로 Slab Allocation이다.
일반적인 시스템은 메모리를 할당하고 해제하는 과정에서 운영체제 시간에 배우는 메모리 파편화(Fragmentation)가 발생해 성능이 저하되곤 한다. Memcached는 이를 방지하기 위해 미리 메모리를 일정한 크기의 덩어리(Slab)로 쪼개어 관리한다.
- Chunks: 데이터를 저장하는 실제 공간
- Slab Class: 비슷한 크기의 Chunk들을 모아놓은 그룹
- 장점: 메모리 재사용 효율이 극대화되며, 가비지 컬렉션(GC)으로 인한 멈춤 현상이 없다.
3. 왜 Memcached인가? (핵심 장점)
- 극강의 응답 속도: 모든 데이터를 메모리에만 저장하며, O(1)의 시간 복잡도로 데이터를 조회한다.
- 멀티스레드 아키텍처: Redis가 싱글 스레드 기반인 것과 달리, Memcached는 멀티스레드를 지원하여 코어 수가 많은 서버에서 훨씬 높은 처리량(Throughput)을 보여준다.
- 수평적 확장성: 데이터 간의 관계가 없는 단순 구조라 노드를 추가하기만 하면 용량이 선형적으로 늘어난다.
4. Memcached vs Redis
가장 많이 비교되는 두 기술의 차이점을 표로 살펴보자.
| 비교 항목 | Memcached | Redis |
| 데이터 구조 | String (단순 Key-Value) | String, List, Set, Hash, Sorted Set 등 다양 |
| 스레드 모델 | 멀티스레드 (Multi-threaded) | 싱글스레드 (Single-threaded) |
| 데이터 영속성 | 휘발성 (재시작 시 삭제) | Snapshot, AOF 등을 통해 디스크 저장 가능 |
| 메모리 관리 | Slab Allocator (파편화 방지) | 필요 시마다 동적 할당 |
| 추천 용도 | 단순 캐싱, 대규모 트래픽 처리 | 데이터 구조 활용, 랭킹 시스템, 메시지 큐 |
5. 실무에서의 선택 기준
"Redis가 기능도 많고 영구 저장도 되는데, 왜 Memcached를 쓰나요?"라는 질문에 대한 답은 "단순함이 주는 안정성"에 있다고 할 수 있다.
- 순수 캐시 목적인 경우: 데이터가 유실되어도 DB에서 다시 읽어오면 되는 단순 캐시라면, 설정이 복잡한 Redis보다 Memcached가 운영 공수가 훨씬 적다.
- 매우 높은 초당 처리량(TPS)이 필요할 때: 멀티스레드 이점을 활용해 수만 건의 요청을 동시에 처리해야 하는 대형 서비스에 유리하다.
- 오버헤드 최소화: 기능이 적은 만큼 가볍다. 오직 속도와 효율만 생각한다면 최고의 선택이라 할 수 있다.
(보충) Facebook은 왜 Memcached에 진심일까?
교수님께서 Facebook을 언급하신 이유는, Facebook이 세계에서 Memcached를 가장 거대하게 운영하는 조직 중 하나이기 때문이다. 그들은 수천 대의 서버를 연결해 사용하는 방식(분산 방식)을 사용하고 있다.
1. 클라이언트 기반의 분산 (Consistent Hashing)
Memcached 서버 자체는 서로 통신하지 않는다. 대신 클라이언트가 "A라는 데이터는 1번 서버에, B는 2번 서버에 저장하자"라고 결정한다.
- 이때 서버가 추가되거나 빠져도 데이터 재배치를 최소화하는 Consistent Hashing(일관된 해싱) 기법이 사용된다.
2. 대규모 트래픽에서의 '멀티스레드' 이점
Redis는 싱글 스레드라 한 번에 하나의 명령만 처리하지만, Memcached는 멀티스레드를 지원한다. Facebook처럼 초당 수억 건의 요청이 들어오는 환경에서는 서버 한 대당 처리량을 극대화할 수 있는 Memcached가 유리할 때가 많다.
3. 분산 시스템의 코디네이터: ZooKeeper와의 조합
서버가 수천 대가 되면 "지금 어떤 Memcached 서버가 살아있지?"를 관리해야 한다. 이때 ZooKeeper와 같은 미들웨어가 "현재 살아있는 서버 리스트"를 관리하며 Memcached와 짝궁처럼 움직인다.
(보충) Memcached와 ZooKeeper의 관계
Memcached 자체는 아주 똑똑한 시스템이 아니다. 서버끼리 서로 아는 척도 안 하고, 오직 자기 메모리에 데이터만 저장할 뿐이다. 그래서 대규모 환경에서는 다음과 같은 문제 해결을 위해 ZooKeeper를 함께 사용한다.
1. 서버 리스트 관리 (Service Discovery)
서버가 1,000대 있는데 그중 5번 서버가 고장 나서 죽었다고 가정해 보자. 클라이언트(애플리케이션)는 5번이 죽었는지 모르고 계속 데이터를 보내려다 에러가 발생할 것이다.
- ZooKeeper의 역할: 실시간으로 Memcached 서버들의 상태를 체크(Health Check)한다. 5번이 죽으면 즉시 "5번 죽었으니까 이제 거기로 보내지 마!"라고 모든 클라이언트에게 공지해준다.
2. 설정 정보 동기화
수많은 Memcached 서버의 설정(메모리 크기, 포트 번호 등)을 일일이 수정하기는 불가능에 가깝다.
- ZooKeeper의 역할: ZooKeeper에 설정 파일을 올려두면, 연결된 모든 서버가 동일한 설정을 내려받아 적용한다.
3. 일관된 해싱(Consistent Hashing) 지원
분산 캐시에서는 데이터를 어느 서버에 넣을지 결정하는 '지도'가 필요하다.
- ZooKeeper의 역할: 서버가 추가되거나 삭제될 때마다 이 '지도(해시 링)' 정보를 업데이트하고 클라이언트들이 최신 지도를 가질 수 있도록 조율한다.
Facebook은 실제로는 McRouter라는 자체 미들웨어를 쓰기도 하지만, 개념적으로는 ZooKeeper와 같은 역할을 한다고 보면 된다.
정리하면 Memcached가 데이터를 담는 그릇이라면, Zookeeper나 McRouter같은 미들웨어는 수천 개의 그릇이 깨지지 않았는지, 어디에 배치해야 하는지 관리하는 창고 관리자라고 할 수 있겠다.
6. 마치며
Memcached는 최신 유행하는 화려한 기술은 아닐지 모르겠다. 하지만 기본에 충실한 것이 가장 강력하다는 것을 증명하는 기술이다. 서버 성능 최적화를 위해 복잡한 로직 없이 빠르고 안정적인 캐시 시스템이 필요하다면, Memcached를 도입을 고려해보자.
'Newly I Learned' 카테고리의 다른 글
| 분산 락 시스템 (0) | 2025.11.05 |
|---|---|
| 분산 컴퓨팅, RAID의 한계를 넘어 분산 플랫폼의 시대로(대본) (0) | 2025.11.05 |
| NoSQL, Cassandra (0) | 2025.11.05 |
| 모놀리식 아키텍쳐(MA)의 한계와 마이크로서비스 아키텍쳐(MSA)의 등장 (0) | 2025.10.12 |
| 왜 Entity를 그대로 반환하면 안 될까? – 백엔드 계층 분리의 이유 (3) | 2025.05.22 |