멀티 서버 세션 저장소는 왜 Redis 많을까? Memcached 비교로 정리

Memcached와 Redis가 필요한 상황부터 정리

웹 서비스가 커지면 DB나 외부 API 호출이 반복되고, 같은 결과를 다시 계산하는 일이 늘어납니다.

이때 자주 재사용되는 결과를 메모리에 올려두면 요청당 비용이 바로 줄어듭니다. 캐시는 보통 key-value 형태로 저장되며, “같은 key로 다시 요청하면 즉시 반환”되는 방식입니다.

멀티 서버 세션 저장소

왜 Redis 많을까?

Memcached

비교 후기

Memcached와 Redis는 모두 이런 목적에 맞는 인메모리 저장소입니다. 다만 2026년 기준 서비스 환경에서는 “캐시만 할 것인지”, “세션/락/큐 같은 운영성까지 함께 가져갈 것인지”에 따라 선택이 달라지는 편입니다.

Memcached 요약 빠르고 단순한 캐시 엔진

Memcached는 오픈소스 분산 메모리 캐시로, DB 조회 결과나 API 응답, 렌더링 결과 같은 데이터를 작은 단위로 잘라 key - value로 저장합니다.

데이터가 캐시에 있으면 DB/외부 호출이 줄고, 동적 페이지 응답이 빨라집니다.

특히 Memcached는 “단순 캐시”라는 목표에 집중되어 있어서 설정이 간단합니다.

대신 메모리에만 저장되므로 프로세스가 내려가면 캐시도 같이 사라집니다. 캐시 용도라면 보통 이게 문제로 이어지진 않지만, 세션처럼 “사라지면 바로 장애”가 되는 데이터는 신중히 봐야 합니다.

Memcached를 쓸 때 체감되는 이점

가장 중요한 건 “캐시가 어디에 저장되든 애플리케이션이 같은 규칙으로 접근할 수 있느냐”입니다. Memcached를 여러 대로 묶으면 애플리케이션 입장에서는 여러 노드의 캐시 용량을 한 덩어리처럼 활용하는 것처럼 동작합니다. 결과적으로 각 웹서버가 캐시를 ‘각자 조금씩’ 들고 있는 구성보다 낭비가 줄어듭니다.

반대로 Memcached를 쓰지 않고 서버별 로컬 캐시만 두면, 웹팜 환경에서 “A 서버에만 캐시가 있고 B 서버는 미스” 같은 상황이 반복됩니다. 같은 데이터를 여러 서버가 중복 저장할 수 있고, 캐시 히트율이 떨어져 DB 부하가 다시 올라가는 일이 자주 막히는 지점입니다.

Redis 요약: 캐시를 넘어 운영 기능까지 가져가는 저장소

Redis는 인메모리 기반이지만, 서비스 환경에서는 캐시 + 세션 저장 + 작업 큐 + 분산 락 같은 용도로 묶어서 쓰는 경우가 많습니다. 분류상 NoSQL로 부르기도 하고, 캐시 솔루션으로 보기도 합니다.

WHM(EasyApache 4) PHP 8.4 OPcache + Redis Object Cache 구성 장애 복구후기

Redis가 눈에 띄는 이유는 “값(Value)이 단순 문자열이 아니라 자료구조”라는 점입니다. 문자열 하나만 저장하는 수준을 넘어 집합/정렬 집합/해시/리스트처럼 서버 측에서 구조를 유지합니다. 이 구조를 활용하면 애플리케이션에서 처리하던 일부 연산을 Redis로 밀어 넣을 수 있어, 배포 후 확인 단계에서 병목이 빨리 잡히는 경우도 많습니다.

Redis의 데이터 타입이 의미 있는 이유

단순 key-value 캐시만 필요하면 Memcached로도 충분합니다.

하지만 세션이나 랭킹, 태그, 카운터, 큐 같은 요구가 섞이면 Redis 쪽이 관리가 편해집니다.

• String : 일반 문자열뿐 아니라 숫자/바이너리도 저장됩니다. 단순 카운터도 여기서 해결됩니다.
• Set : 중복 없는 값 집합입니다. 태그나 “좋아요한 글 목록” 같은 케이스에 맞습니다.
• Sorted Set : 점수(score) 기반 정렬 집합입니다. 랭킹/인기글 같은 “상위 N개”가 바로 나옵니다.
• Hash : 필드-값 형태의 테이블 구조입니다. 사용자 세션/프로필을 한 키 아래에 묶기 좋습니다.
• List : 양쪽에서 넣고 빼는 구조입니다. 간단한 작업 큐에 자주 씁니다.

정리하면, Redis는 “저장”만이 아니라 저장된 데이터에 대한 연산이 기본 기능으로 들어가 있습니다. 그래서 기능이 늘어날수록 Memcached보다 Redis 쪽으로 자연스럽게 기울어지는 편입니다.

멀티 서버에서 세션을 로컬에 두면 바로 터지는 문제

Multi Server 환경에서의 Session데이터를 Servere마다 관리하도록 설계한다면 어떻게 될까요?

사용자가 로그인한 상태에서 요청 서버가 바뀐다면, 해당 사용자는 로그인이 해제될 것입니다.(해당 서버의 세션 저장소에는 사용자가 로그인한 데이터가 없으므로) 그렇기 때문에 웹 서버에서는 세션 데이터를 서버가 아닌 외부 저장소에 저장합니다.

사용자 입장에서는 “새로고침했는데 로그인이 풀림”으로 보이고, 운영 입장에서는 로드밸런서 설정이나 스케일아웃 타이밍에 따라 재현됩니다. 가장 중요한 건 세션 저장 위치가 웹서버 밖으로 빠져야 한다는 점입니다. 이 부분만 확인하시면 됩니다.

Multi Server환경의 Service

Spring Data Redis를 적용한 경우

이때 사용하는 저장소에 대해 의문이 들었습니다. Spring의 세션 클러스터링은 기본적으로 Redis를 이용하여 진행됩니다.

세션 정보 저장과 캐싱에 Redis를 사용하던 도중 왜 Spring은 Redis를 이용하게 되었을까에 대한 궁금증이 생겼습니다. RDBMS에도 저장할 수 있고 MongoDB, Memcached 등 다른 NoSQL에도 데이터를 저장할 수 있기 때문입니다.

RDBMS와 NoSQL을 세션/캐시 관점에서 보면

가장 큰 틀인 RDBMSA와 NoSQL을 비교해보았습니다.

캐싱 전략과 세션 저장에 RDBMS가 어울리지 않는다고 생각할 수 있지만 실제로 MySQL을 캐싱에 사용할 수도 있습니다. Spring Data Redis Doc에서는 왜 RDBMS 대신 NoSQL을 선택했는지 말해주고 있습니다.

결론부터 말씀드리면, 캐시/세션은 지연 시간에 민감하고, 트래픽이 올라갈수록 쓰기보다 읽기가 폭증하는 편입니다.

RDBMS로도 구현은 되지만, 잠금/인덱스/디스크 I/O 특성 때문에 “반복 조회를 빠르게” 처리하는 데서 손해가 날 수 있습니다. 반면 NoSQL 계열 key-value 저장소는 이 용도에 맞춰 설계된 경우가 많습니다.

RDBMS vs NoSQL

우선 Spring Data Redis Doc를 살펴보았습니다.

2. Why Spring Data Redis? The Spring Framework is the leading full-stack Java/JEE application framework. It provides a lightweight container and a non-invasive programming model enabled by the use of dependency injection, AOP, and portable service abstractions. NoSQL storage systems provide an alternative to classical RDBMS for horizontal scalability and speed. In terms of implementation, key-value stores represent one of the largest (and oldest) members in the NoSQL space. The Spring Data Redis (SDR) framework makes it easy to write Spring applications that use the Redis key-value store by eliminating the redundant tasks and boilerplate code required for interacting with the store through Spring’s excellent infrastructure support.

문서에서 강조하는 방향은 “확장성과 속도”입니다. 세션과 캐시는 요청이 몰릴수록 바로 병목이 되기 때문에, 저장 엔진을 고를 때도 수평 확장과 짧은 응답 시간을 우선으로 두게 됩니다.

NoSQL에서 Redis와 Memcached를 같이 놓고 보면

그렇다면 NoSQL 중 캐싱 전략에 자주 사용되는 Redis, Memcached 중 왜 Redis를 선택하게 되었을까요? 이 두 가지 선택지는 캐싱과 세션 저장 시 자주 비교되는 선택지입니다.

Spring Doc에는 왜 Redis를 선택했는지는 나와있지 않습니다. 그러므로 이 문단부터는 필자의 주관적인 분석을 적을 예정입니다.

2026년 기준으로 보면 “세션 클러스터링”은 단순 캐시보다 요구가 까다롭습니다. 예를 들어 TTL(만료), 원자적 연산, 장애 시 복구, 운영 도구가 같이 따라오면 Redis 쪽으로 가는 케이스가 많습니다. 반대로 “정말로 캐시만, 사라져도 괜찮음”이면 Memcached가 더 가볍게 맞아떨어집니다.

NoSQL - Redis vs Memcached

1. 특징

우선 두 NoSQL의 특징을 정리해보았습니다.

	Redis	Memcached
저장소	In Memory Storage
저장 방식	Key-Value
데이터 타입	String, Set, Sorted Set, Hash, List	String
데이터 저장	Memory, Disk	Only Memory
메모리 재사용	메모리 재사용 하지 않음(명시적으로만 데이터 삭제 가능)	메모리 부족시 LRU 알고리즘을 이용하여 데이터 삭제 후 메모리 재사용
스레드	Single Thread	Multi Thread
캐싱 용량	Key, Value 모두 512MB	Key name 250 byte,  Value 1MB

표만 보면 “기능은 Redis, 단순함은 Memcached”로 보이실 겁니다. 여기에 2026년 관점으로 한 줄 더 붙이면, 세션/락/큐까지 한 곳에서 다루려면 Redis, 캐시만 가볍게 가져가려면 Memcached 쪽이 판단이 빠릅니다.

공통점

Redis와 Memcached 모두 In Memory, key-value 방식의 NoSQL입니다.

Redis 쪽이 더 낫다고 말하는 이유

1. 자료구조가 있어서 “세션 저장”이 깔끔해집니다.

Memcached는 값이 사실상 문자열 하나로 끝나는 경우가 많습니다. Redis는 Hash나 Set 같은 구조를 제공해서, 세션 속성이나 권한/토큰 같은 정보를 키 아래에 묶어 관리하기 쉽습니다. 헷갈림이 줄어듭니다.

2. 재시작 시 데이터 복구 옵션이 있습니다.

Memcached는 프로세스가 내려가면 데이터도 같이 사라집니다. Redis는 메모리 기반이지만 디스크 저장 옵션이 있어서, 재시작 이후에도 이전 데이터를 다시 올릴 수 있습니다. 세션 저장처럼 “유실이 곧 장애”인 경우에는 이 차이가 크게 느껴집니다.

3. 만료/삭제 정책을 더 세밀하게 다룰 수 있습니다.

Memcached는 대표적으로 LRU 기반으로 캐시가 밀려납니다. Redis는 상황별로 정책을 더 세분화할 수 있어 “세션은 절대 밀리지 않게, 일반 캐시는 밀리게” 같은 운영 환경의 요구를 반영하기가 수월합니다.

Memcached가 더 편한 경우

1. 멀티스레드로 자원을 잘 씁니다.

Redis는 구조상 단일 스레드로 처리되는 구간이 있고, Memcached는 멀티스레드로 처리됩니다. 단순 캐시에서 스케일업을 강하게 타는 서버라면 Memcached가 더 자연스럽게 맞는 경우가 있습니다.

2. “가벼운 캐시”만 필요하면 메모리 부담이 적습니다.

HTML 조각이나 계산 결과처럼 단순한 캐시를 빠르게 넣고 빼는 용도라면 Memcached가 부담이 적습니다. Redis는 기능이 많은 만큼 메모리 오버헤드가 생길 수 있어, 같은 용량에서도 체감이 달라질 수 있습니다.

선택이 필요한 순간: “캐시”인지 “세션/운영”인지

운영 환경에서 고민이 길어지는 이유는 두 제품이 “빠르다/느리다”보다 장애가 났을 때 복구 방식과 관리 포인트가 다르기 때문입니다.

캐시만 두고 싶다면 단순한 쪽이 시간이 줄어듭니다. 반대로 세션을 외부로 빼고, 토큰/레이트리밋/락 같은 요구가 같이 붙으면 Redis가 한 번에 정리가 됩니다.

선호도

Stackoverflow

Memcached vs. Redis?

StackOverflow에서도 “가능하면 Redis로 가라”는 의견이 자주 보입니다. 이유는 단순합니다. 캐시만 보더라도 Redis가 커버하는 범위가 넓고, 세션이나 메시징으로 확장될 때 같은 엔진을 그대로 가져갈 수 있기 때문입니다. 다만 이미 Memcached로 안정적으로 운영 중이면, 굳이 바꾸지 않는 선택도 흔합니다.

극찬 수준의 Redis 추천

Conclusion Without hesitation I would recommend redis over memcached for any new projects, or existing projects that don't already use memcached. The above may sound like I don't like memcached. On the contrary: it is a powerful, simple, stable, mature, and hardened tool. There are even some use cases where it's a little faster than redis. I love memcached. I just don't think it makes much sense for future development. Redis does everything memcached does, often better. Any performance advantage for memcached is minor and workload specific. There are also workloads for which redis will be faster, and many more workloads that redis can do which memcached simply can't. The tiny performance differences seem minor in the face of the giant gulf in functionality and the fact that both tools are so fast and efficient they may very well be the last piece of your infrastructure you'll ever have to worry about scaling. There is only one scenario where memcached makes more sense: where memcached is already in use as a cache. If you are already caching with memcached then keep using it, if it meets your needs. It is likely not worth the effort to move to redis and if you are going to use redis just for caching it may not offer enough benefit to be worth your time. If memcached isn't meeting your needs, then you should probably move to redis. This is true whether you need to scale beyond memcached or you need additional functionality.

클라우드 매니지드 환경에서의 비교 관점

최근에는 자체 설치보다 매니지드 서비스를 붙이는 경우가 많습니다. 이때는 “엔진 자체의 기능”과 함께 장애 조치 범위, 모니터링, 자동 페일오버 같은 요소가 같이 움직입니다. 캐시만 보면 선택이 쉬워 보이지만, 세션을 함께 담는 순간부터는 복구/일관성이 더 중요한 축으로 올라옵니다.

AWS 공식 문서 비교

Compare Redis OSS vs. Memcached

AWS에서 비교한 Memcached와 Redis

AWS에서는 동작 방식과 요구사항에 맞춰 고르라고 안내합니다. 문맥상으로는 “기능이 필요한 쪽은 Redis, 단순 캐시는 Memcached”로 정리되는 편이고, 특히 세션/퍼시스턴스/복제 같은 항목은 Redis 쪽 설명이 더 구체적입니다.

성능 비교를 볼 때 헷갈리지 않게

성능 비교는 숫자만 보면 판단이 흔들립니다. 가장 중요한 건 워크로드입니다. 캐시는 “작은 값, 많은 요청”이 기본인데, 세션이나 자료구조 연산이 섞이면 Redis가 강해지고, 정말 단순한 get/set만 반복하면 Memcached가 유리하게 나올 때도 있습니다.

응답 속도

Memcached는 Redis에 비해 안정적인 응답 속도를 기대할 수 있습니다. 트래픽이 많아질 때 Redis는 응답 속도가 불안정하다는 이슈가 있습니다. Redis가 jemalloc 메모리 할당 구조를 사용하기 때문인데 malloc과 free를 사용하여 메모리 파편화가 발생하고 이 할당 비용으로 인해 응답 속도가 느려지는 이슈입니다.

이 구간에서 원인 분리가 여기서 시작됩니다. 같은 TPS라도 키 개수, 값 크기, 만료 정책, 파이프라이닝 여부에 따라 결과가 크게 달라집니다. “Redis가 느려졌다”로 보일 때는 서버가 느린 게 아니라 메모리 압박/만료 처리/백업 설정 쪽에서 비용이 튀는 경우가 많습니다.

Memcached는 slab 메모리 할당 구조를 사용한다고 합니다.

Read / Write

Jedis jed = new Jedis("localhost", 6379);
int count = 100000;
long startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  jed.set("u112-"+i, "v51"+i);
}
long endTime = System.currentTimeMillis();
System.out.println("Time taken to store "+ count + " values is ="+(endTime-startTime)+"ms");

startTime = System.currentTimeMillis();
for (int i=0; i<count; i++) {
  client.get("u112-"+i);
}
endTime = System.currentTimeMillis();
System.out.println("Time taken to retrieve "+ count + " values is ="+(endTime-startTime)+"ms");

Redis Time taken to store 100000 values is = 18954ms Time taken to load 100000 values is = 18328ms Memcached Time taken to store 100000 values is = 797ms Time taken to retrieve 100000 values is = 38984ms 출처(Stackoverflow)

이 결과처럼 “쓰기/읽기 편차”는 충분히 나올 수 있습니다. 다만 벤치마크는 환경이 달라지면 바로 뒤집힙니다. 그래서 실제 서비스에서는 숫자보다 요구 기능으로 먼저 좁히고, 마지막에 부하 테스트로 확인하는 쪽이 시간 낭비가 줄어듭니다.

Redis는 Memcached의 단점을 개선하여 만들었다고 합니다. Spring 운영 서버에서 데이터 복구 기능과 다양한 자료구조를 가진 Redis는 캐싱과 세션 관리에 있어서 더욱 강력한 기능을 제공하고 있습니다.

결론부터 말씀드리면, 세션을 외부 저장소로 빼야 하는 순간부터는 Redis가 편해지는 경우가 많습니다. 캐시만 놓고 보면 Memcached가 더 가볍고 빠르게 느껴질 수도 있습니다.

추가로 꼭 챙길 것 장애 분리와 보안

세션/캐시가 문제를 일으킬 때는 “느림”보다 “로그인 풀림, 데이터가 뜨다 말다, 특정 시간대만 튐”처럼 증상이 먼저 보입니다. 이때 가장 중요한 건 네트워크 문제인지, 저장소 자원 문제인지, 애플리케이션 키 설계 문제인지를 빠르게 가르는 겁니다.

안 될 때 먼저 보는 체크리스트

• TTL/만료가 맞는지 : 세션이 예상보다 빨리 끊기면 만료 시간이 먼저 의심됩니다.
• 키 네임스페이스 : 서비스/환경(dev, stg, prod)이 섞이면 캐시 오염이 생깁니다.
• 값 크기 : 세션에 객체를 통째로 넣으면 네트워크/메모리 비용이 급격히 커집니다.
• 커넥션/풀 설정 : 순간 트래픽에 풀 고갈이 나면 타임아웃이 연쇄로 터집니다.
• 메모리 압박 : eviction이 잦아지면 캐시 미스가 늘고 DB가 다시 뜁니다.

보안에서 자주 놓치는 지점

캐시/세션은 내부망에서만 접근하도록 두는 게 기본입니다. 가장 중요한 건 공인망에 바로 노출하지 않는 것입니다. 인증/ACL이 없는 상태로 열어두면 세션 탈취로 바로 이어질 수 있습니다. 사내 환경이라도 접근 대역을 제한하고, 관리 포트는 운영망으로 분리해두는 편이 안전합니다.

대체 선택지 로컬 캐시와 분산 캐시를 같이 쓰는 패턴

트래픽이 큰 서비스에서는 “로컬 캐시 + Redis/Memcached”를 섞는 경우도 많습니다. 로컬은 네트워크 비용이 없고, 분산 캐시는 인스턴스가 늘어도 데이터가 공유됩니다. 다만 로컬 캐시가 커지면 인스턴스별 데이터가 달라져 일관성 이슈가 생길 수 있으니, 정말 짧은 TTL로 제한하거나 읽기 전용 성격의 데이터에만 쓰는 편이 안전합니다.

Q. 세션 저장소로 Memcached를 쓰면 안 되나요?

A. 가능은 하지만 “프로세스 재시작/장애 시 유실”을 감수해야 합니다. 로그인 유지가 중요한 서비스라면 Redis처럼 복구 옵션이 있는 쪽이 사고가 줄어듭니다.

Q. Redis를 캐시로만 쓰면 과한가요?

A. 캐시만 놓고 보면 과할 수 있습니다. 다만 이후에 세션/락/큐 요구가 붙을 가능성이 있으면 Redis로 시작하는 편이 이관 비용이 줄어듭니다.

Q. 멀티 서버에서 로그인 풀림이 생길 때 제일 먼저 확인할 건 뭔가요?

A. 세션이 웹서버 로컬에 남아 있는지, 로드밸런서가 특정 서버로 고정(sticky)되어 있는지부터 보시면 됩니다. 외부 저장소로 세션이 빠져 있지 않으면 재현이 쉽습니다.

Q. 캐시 미스가 갑자기 늘고 DB가 튀면 원인이 뭘까요?

A. 메모리 압박으로 eviction이 늘었거나 TTL이 과하게 짧은 경우가 흔합니다. 키 개수/값 크기/만료 정책을 같이 확인해야 증상이 정리됩니다.

Q. 운영 환경에서 Redis를 안전하게 쓰려면 최소한 무엇을 해야 하나요?

A. 접근 대역 제한, 인증 설정, 관리 포트 분리(운영망), 그리고 세션/민감 데이터는 평문 노출을 피하도록 설계하는 것이 기본입니다.