memcached 예찬

• 캐시는 데이터베이스 부하를 줄이기 위해 들어오지만, Redis처럼 쓰기 쉬운 도구는 시간이 지나며 영속 저장소처럼 의존되기 쉬움
• 문제는 Redis의 영속성 기능이 아니라, 처음에는 휘발성 캐시로 도입된 구성 요소가 애플리케이션의 핵심 상태와 엮이는 운영 흐름임
• memcached는 공식 정의부터 분산 메모리 객체 캐싱 시스템이고 디스크 저장을 전제로 하지 않아, 상태 없는 캐시 워크로드로 다루기 쉬움
• 여러 memcached 인스턴스는 서버가 아니라 클라이언트가 URL 목록과 키 해시로 나누며, 장애 노드는 해셔에서 빠졌다가 나중에 재연결을 시도함
• “데이터베이스가 느리다”는 이유로 캐시부터 추가하기보다, 먼저 느린 쿼리와 누락된 인덱스를 확인해야 함

Redis가 캐시에서 저장소로 변하는 순간

• 인프라를 운영하다 보면 “캐시가 필요하다”는 요구가 자주 나오고, 익숙하고 기능이 많은 Redis가 먼저 떠오르기 쉬움
• Redis 홈페이지는 AI 앱용 실시간 컨텍스트 엔진인 Redis Iris를 전면에 내세우지만, Redis가 수익을 내야 하는 회사라는 점에서는 이해 가능한 방향임
• Redis를 배포하고 연결 문자열을 넘기면 처음에는 신뢰할 수 있는 캐시처럼 동작함
• 시간이 지나면 cache.set("key", "value")가 INSERT INTO table VALUES ('key', 'value')보다 훨씬 단순해, 사람들이 Redis를 다음처럼 취급하기 시작함
  • 항상 존재하는 구성 요소
  • 데이터를 보존하는 장소
  • 사실상의 데이터베이스
• 운영팀이 Redis를 휘발성 캐시로 전제하면 알림과 운영 방식도 그 가정에 맞춰짐
• Redis 업그레이드, 노드 이동, 디스크 장애 같은 이벤트가 생기면 이 전제가 깨지기 시작함
• Redis에 영속성이 없어서가 아니라, Redis가 보통 캐시라는 가정으로 도입되고 운영된다는 점이 문제의 중심임
• 뒤늦게 의존성을 발견하면 Redis가 애플리케이션에 너무 깊게 엮여 제거하기 어렵고, 결국 “애완동물”처럼 유지보수하고 모니터링해야 함

memcached가 캐시 역할에 더 직접적인 이유

• memcached는 “무료 오픈소스, 고성능, 분산 메모리 객체 캐싱 시스템”이며, 데이터베이스 부하를 줄여 동적 웹 애플리케이션을 빠르게 하기 위한 범용 캐시임
• Django처럼 플러그형 캐싱을 지원하는 프레임워크에서는 캐싱 백엔드를 바꿀 수 있음
• Redis보다 기능이 적어도 memcached를 선택할 만한 이유는 운영 특성이 단순하기 때문임
  • 다운타임 처리가 쉬움: 클라이언트 라이브러리가 연결 예외를 무시하는 경우가 많고, 단순 get은 서버가 내려가도 기본값이나 None을 반환할 수 있음
  • 클라이언트 측 분산이 기본 방식임: memcached 자체에 내장 클러스터링이 없고, 클라이언트 라이브러리에 여러 URL을 설정하면 키 해시로 대상 인스턴스를 고름
  • 클라이언트 호출이 인스턴스 다운을 감지하면 해셔에서 노드를 제거하고, 일정 시간이 지난 뒤 자동으로 재연결을 시도함
  • 영속성 부담이 구조적으로 줄어듦: memcached는 디스크에 저장하지 않아 상태 없는 워크로드로 원하는 곳에 스케줄링하기 좋음
• Redis로도 비슷한 운영 방식을 만들 수는 있지만, memcached의 아키텍처는 이런 방향에 더 가까워 캐시로 다루기 직관적임
• memcached는 비교적 단순한 애플리케이션이고, 약 64MB 캐시 크기의 인스턴스를 수십 개 실행해도 오버헤드가 거의 없다는 점이 선택 이유가 됨
• 많은 “데이터베이스가 느리다” 문제는 실제로 느린 쿼리나 누락된 인덱스에서 시작하므로, 캐시 추가와 함께 쿼리 최적화도 봐야 함
• memcached의 설계 결정이 궁금하면 memcached blog를 볼 수 있고, 5월에는 “How Long Does That Response Take… For Real?”이 올라옴