Redis 세션으로 옮겼더니 앱 서버 추가가 단순해졌습니다

 

서버가 두 대면 로드밸런서가 요청을 번갈아 보냅니다. 1번 서버에서 로그인해도 다음 요청이 2번 서버로 가면, 그 디스크에는 세션 파일이 없어서 로그인이 풀립니다. 그래서 모든 서버가 같은 폴더를 공유해야 합니다.

이 글은 그 파일 세션 대신 Redis에 둘 때 키가 어디에 있는지, 노드와 샤드가 어떻게 나뉘는지, Memcached·Valkey·AWS ElastiCache와 무엇이 다른지만 다룹니다. 클러스터 설치 절차 전체는 넣지 않습니다.

목차

1. 파일 세션이 마운트를 요구하는 이유
2. 디스크에 쓰면 느리고 빠지는 지점
3. Redis를 다른 서버에 두는 구조
4. Redis가 메모리에 두는 키-값인 이유
5. 저장 위치, 램과 RDB·AOF
6. 복제 노드와 센티넬
7. 클러스터와 샤드, 16384 슬롯
8. 백엔드가 서버 담당에게 요청할 항목
9. Memcached와 Redis가 다른 점
10. Valkey와 Redis가 갈라진 지점
11. AWS ElastiCache에서 Redis와 Valkey
12. 세션에 Redis를 쓰면 안 되는 경우

1. 파일 세션이 마운트를 요구하는 이유

서버가 두 대 이상이면 다른 서버에 있는 세션 파일을 읽을 수 없어서, 모든 서버가 같은 폴더를 공유해야 합니다. 앱이 한 대일 때는 다음 요청도 같은 디스크로 가니 이 문제가 없습니다.

공유는 NFS처럼 네트워크 너머의 디스크를 내 폴더처럼 붙이는 방식으로 많이 합니다. NFS는 다른 서버의 디렉터리를 네트워크로 연결하는 프로토콜입니다. 앱이 늘 때마다 마운트 경로, 권한, 네트워크 경로가 같이 늘어납니다. 설정이 하나라도 어긋나면 그 서버만 세션을 못 읽습니다.

세션은 사용자마다 파일이 생깁니다. 작은 파일이 많으면 목록을 읽는 것만으로도 디스크가 바빠지고, 그 부하를 마운트한 앱 서버가 같이 봅니다.

구분	파일 세션	Redis 세션
서버가 늘 때	세션 디렉터리 마운트가 추가됩니다.	앱은 Redis 주소만 봅니다.
저장 위치	디스크의 파일입니다.	기본은 그 서버의 램입니다.
장애 때	파일 잠금, 쓰기 중단, 끊긴 마운트가 납니다.	프로세스가 죽으면 디스크에 남기지 않은 메모리 값은 사라집니다. 그래도 세션은 다시 로그인하면 되니 문제가 적습니다.

반응형

2. 디스크에 쓰면 느리고 빠지는 지점

파일 세션이 느린 이유는 요청마다 파일을 열고 읽고 덮어쓰고 닫는데, 그 경로가 램이 아니라 디스크라서입니다. 운영체제 캐시에 걸려도 파일을 여는 호출과 잠금은 남습니다.

여러 요청이 같은 파일을 고치면 잠금이 걸립니다. 한 요청이 쓰는 동안 다른 요청은 기다려야 해서, 새로고침을 연타하거나 탭이 여러 개면 같은 세션에서 줄이 생깁니다.

쓰기가 끝나기 전에 프로세스가 죽으면 파일이 0바이트가 되거나 앞부분만 남습니다. 다음 요청은 그 파일을 세션으로 해석하지 못해서 로그아웃시킵니다. 공유 디스크는 네트워크가 끊기면 쓰기가 중간에 멈춰 같은 증상이 납니다.

마운트가 끊기면 앱은 빈 폴더만 보거나 쓰기가 멈춥니다. 증상은 저장소가 죽은 것과 비슷하지만, 로그에 NFS 타임아웃이 있으면 원인은 디스크 경로입니다.

📌 유실의 의미 파일 세션의 유실은 디스크에 있는데 못 읽는 경우입니다. 쓰기가 중간에 끊기거나 마운트가 끊긴 때입니다. Redis 세션의 유실은 메모리가 비워진 경우입니다. 디스크 기록이 꺼져 있으면 프로세스가 죽을 때 값이 같이 없어집니다.

3. Redis를 다른 서버에 두는 구조

Redis를 앱과 다른 서버에 두면, 세션이 앱 디스크 밖에 있어서 앱이 늘어도 마운트를 더하지 않습니다. 앱은 포트로 붙습니다. 기본 포트는 6379입니다.

서버가 세 대여도 키는 그 Redis에 있습니다. 어떤 앱으로 요청이 가도 같은 키를 읽습니다. 앱끼리 디스크를 공유하지 않습니다.

대신 네트워크가 생깁니다. 앱이 있는 망에서 6379가 열려 있어야 접속이 됩니다. 인터넷에 그 포트를 열면 인증 없이도 키가 읽힐 수 있어서, 앱 서버에서만 접근하게 둡니다. 비밀번호, 계정 권한, 암호화 연결은 서버 담당이 호스트를 띄울 때 같이 정합니다.

같은 데이터센터 구역 안에서는 왕복이 한 번입니다. 파일을 잠그고 기다리는 시간보다 짧은 경우가 많습니다. 리전을 건너 붙이면 왕복이 길어져서 그 차이가 줄어듭니다. 세션용 Redis를 앱과 같은 리전에 두는 이유가 여기 있습니다.

4. Redis가 메모리에 두는 키-값인 이유

세션을 메모리에 두면 디스크를 열지 않아 읽고 쓰기가 짧습니다. 세션은 잠깐 쓰다 버려도 되는 값이라, 사라져도 다시 로그인하면 됩니다. 결제 원장처럼 남아야 하는 값은 이 이유에 해당하지 않습니다.

실무에서는 키 하나에 문자열을 통째로 넣기보다, 해시의 키·필드·값으로 나누는 경우가 많습니다. 키는 세션 아이디입니다. 필드는 userId, role 같은 항목 이름입니다. 값은 그 항목의 내용입니다. 그래서 권한만 바뀌면 JSON 전체를 다시 쓰지 않아도 됩니다.

TTL은 그 키가 몇 초 뒤에 지워질지 정하는 만료 시간입니다. 로그인 유지 30분이면 1800초를 키에 겁니다. HSET으로 필드를 고쳐도 TTL은 처음 건 시간에서 줄어들 뿐 다시 늘어나지 않습니다. 그래서 요청이 올 때마다 EXPIRE로 남은 시간을 다시 늘립니다. 늘리지 않으면 사용 중에도 키가 지워져 로그아웃됩니다.

명령은 한 스레드가 순서대로 처리하는 쪽이 기본이었습니다. 그래서 한 키의 증감은 앱에서 잠금을 따로 걸지 않아도 겹치지 않습니다. Redis와 Valkey 모두 네트워크 처리를 스레드로 나누는 옵션이 있을 수 있으니, 그 기본값은 운영 버전 릴리스 노트에서 확인하면 됩니다.

명령이 한 줄로 처리돼서, 느린 명령은 그 순간 다른 세션 읽기까지 밀립니다. KEYS * 로 전체를 훑거나 큰 값을 한 번에 넣는 일은 피하고, 키를 찾을 때는 SCAN 을 씁니다.

아래는 해시 세션에 필드 두 개를 넣고 30분 TTL을 거는 명령입니다. HSET은 새로 생긴 필드 수를 돌려주고, EXPIRE가 1이면 만료가 걸린 것이며, TTL은 남은 초를 돌려줍니다.

HSET session:abc123 userId 42 role editor
EXPIRE session:abc123 1800
TTL session:abc123

 

앱은 쿠키에 abc123 같은 아이디만 둡니다. 사용자 번호는 Redis에 둡니다. 쿠키에 권한 전체를 넣으면 Redis에 둘 이유가 줄어듭니다. 권한이 쿠키에 있으면 서버 저장소를 읽지 않아도 요청이 처리되지만, 서명하지 않은 쿠키는 사용자가 값을 바꿀 수 있습니다. 또 권한을 회수해도 이미 발급된 쿠키에는 옛 권한이 남습니다.

5. 저장 위치, 램과 RDB·AOF

지금 읽는 값은 램에 있습니다. 프로세스를 끄거나 호스트가 죽으면, 디스크에 남기지 않은 값은 램과 함께 사라집니다.

디스크 기록은 설치 방식마다 기본값이 다릅니다. 직접 설치한 Redis와 Valkey는 기본 설정에서 RDB 스냅샷이 켜져 있고, ElastiCache 같은 관리형은 꺼진 상태로 시작하는 경우가 많습니다. 세션만 쓴다면 어느 쪽인지 확인하고 일부러 정하는 편이 낫습니다. RDB는 어느 시점의 스냅샷 파일입니다. AOF는 명령을 순서대로 적어 둔 로그입니다. 둘 다 켜면 복구에 쓸 자료는 늘지만, 디스크 쓰기가 다시 생깁니다. 파일을 매 요청마다 고치던 비용이 형태로만 바뀌는 셈입니다.

기록 방식	남는 것	세션에서
없음	램만 사용합니다.	재시작 시 다시 로그인합니다.
RDB	마지막 스냅샷입니다.	스냅샷 이후에 바뀐 값은 파일에 없습니다.
AOF	명령 로그입니다.	빈 구간은 짧지만 디스크에 명령을 남깁니다.

램이 가득 차면 퇴거 정책이 작동합니다. 퇴거 정책은 메모리가 한계에 닿았을 때 어떤 키부터 지울지 정한 규칙입니다. 세션은 만료가 있는 키이므로 volatile-lru 나 volatile-ttl 처럼 만료 키부터 지우는 규칙을 많이 봅니다. noeviction 이면 지우지 않고 쓰기가 실패해서, 새 로그인이 거절됩니다.

용량은 대략 동시 로그인 수에 값 크기를 곱한 크기입니다. 여유 없이 채우면 퇴거가 곧 로그아웃입니다. 인스턴스 가격은 리전마다 달라서 여기엔 적지 않습니다.

6. 복제 노드와 센티넬

노드 하나는 그 프로세스의 램이 곧 저장 공간입니다. 기록 설정이 없으면 복사본이 없어서, 노드가 죽으면 그 안의 세션도 끝입니다.

복제를 붙이면 같은 데이터를 다른 노드가 따라옵니다. 쓰기를 받는 쪽은 프라이머리이고, 따라오는 쪽은 복제본입니다. 누가 승격할지 정하는 프로세스가 없으면, 프라이머리가 죽어도 역할이 자동으로 바뀌지 않습니다.

센티넬은 프라이머리가 죽었는지 보고 복제본을 새 프라이머리로 올리는 감시 프로세스입니다. 데이터를 여러 기계로 나누는 기능은 아닙니다. 데이터 한 벌이 살아 있게 하는 장치입니다. 이렇게 죽은 쪽의 역할을 산 쪽으로 넘기는 일을 페일오버라고 합니다.

세션은 읽기가 많습니다. 복제본에서 읽으면 프라이머리 부하는 줍니다. 대신 복제가 늦으면 방금 로그인한 키가 복제본에는 아직 없습니다. 로그인 직후 조회가 실패하면 읽기를 프라이머리로 고정합니다. 방금 쓴 값을 그 노드에서 바로 읽기 위해서입니다.

프라이머리 주소가 바뀌면 앱도 접속 주소를 바꿔야 할 때가 있습니다. 관리형 서비스는 이 주소 변경을 끝점에서 숨기는 경우가 많습니다. 직접 설치라면 센티넬이 합의에 쓰는 감시 수와 페일오버까지 기다리는 시간은 서버 담당이 정합니다.

7. 클러스터와 샤드, 16384 슬롯

클러스터를 쓰는 이유는 램 한 대 또는 쓰기 처리 한 대를 넘기기 위해서입니다. 키 공간을 16384개의 해시 슬롯으로 나눕니다. 해시 슬롯은 키가 어느 조각에 들어갈지 정하는 번호입니다. 번호는 CRC16이라는 체크섬으로 키를 짧은 숫자로 만든 뒤 16384로 나눈 나머지입니다. 이 개수는 Redis 클러스터 명세에 있습니다.

샤드는 슬롯 범위를 맡은 프라이머리와, 그 프라이머리를 따라오는 복제본의 묶음입니다. 예를 들어 앞쪽 슬롯은 샤드 A, 나머지는 샤드 B입니다. 키는 자기 슬롯의 샤드로만 갑니다. 프로세스를 하나 더 띄워도 기존 키는 이동하지 않아서, 용량을 늘리려면 슬롯을 다른 샤드로 옮겨야 합니다.

샤드 안에서 복제본이 슬롯을 이어 받아서, 클러스터에서는 센티넬을 같이 쓰지 않습니다. 다른 샤드의 데이터까지 한곳으로 모이지는 않습니다.

방식	나누는 것	세션에서 보는 점
단일 노드	나누지 않습니다.	동시 접속이 램 한 대 안에 있으면 이것으로 충분합니다.
복제와 센티넬	같은 데이터 한 벌입니다.	한 대가 죽어도 세션을 이어 가려면 복제본이 필요합니다.
클러스터 샤드	16384 슬롯을 여러 프라이머리에 나눕니다.	램이나 쓰기가 한 대를 넘을 때 슬롯을 나눕니다.

한 명령이 샤드 두 대를 동시에 잠그지 않아서, 슬롯이 다른 키는 한 트랜잭션으로 묶이면 실패할 수 있습니다. 세션 키 하나만 읽고 쓰면 이 경우에 잘 안 걸립니다. 한 사용자의 키 여러 개를 항상 같은 샤드에 두려면 키에 같은 해시 태그 {user42} 를 넣습니다. 태그가 같으면 슬롯도 같아서 같은 샤드에 들어갑니다. 태그를 넓게 쓰면 다시 한 샤드로 몰립니다.

슬롯 주인이 바뀌면 클라이언트는 잠깐 다른 노드로 가라는 응답을 받습니다. 앱 클라이언트가 클러스터 모드를 알아야 합니다. 단일 노드용 클라이언트로 붙이면 일부 키를 다른 샤드에서 찾지 못합니다.

8. 백엔드가 서버 담당에게 요청할 항목

디스크 설치, 커널 설정, 백업 위치는 서버 담당 일입니다. 호스트를 띄우는 절차는 요청을 처리하는 코드와 별개입니다. 키 이름, 필드, TTL 초는 백엔드가 정합니다. 어떤 요청이 어떤 값을 읽고 몇 초 뒤에 지울지는 앱 코드에 있습니다. 저장 위치를 앱 디스크 밖으로 빼 달라는 말이 없으면, 파일 세션용 마운트가 해결책으로 돌아올 수 있습니다.

요청서에 적을 내용은 아래 정도면 됩니다. 버전 숫자는 담당이 고른 배포판 기준으로 확정하고, 앱 설정에도 그 버전을 남깁니다.

항목	예시로 적는 말
용도	웹 세션만. 결제 데이터는 퇴거되면 안 되는 값이라 넣지 않음.
엔진	Redis OSS 또는 Valkey. 앱 클라이언트가 붙는 프로토콜과 맞추기 위해서입니다.
형태	단일 또는 클러스터. 예상 동시 접속이 램 한 대를 넘는지로 고릅니다.
만료와 퇴거	키 TTL 사용. 메모리가 가득 차면 만료 키부터 삭제.
영속화	재로그인을 허용하면 세션만인 경우 영속화는 꺼도 됩니다. 켜면 RDB인지 AOF인지 적습니다.
네트워크	앱 서버에서만 접근. 공인 IP는 두지 않음.

받은 뒤에 백엔드가 맞출 것은 호스트와 포트, 인증 방식, 클러스터인지 단일인지입니다. 만료 시간은 Redis 서버가 아니라 앱이 키에 거는 TTL로 정해집니다. 프레임워크의 세션 유지 시간, Redis 키 TTL, 쿠키 만료 시간이 서로 다르면 가장 짧은 쪽이 먼저 로그아웃시킵니다. 쿠키는 30분인데 TTL을 5분으로 걸면 사용자는 5분 뒤에 풀립니다.

9. Memcached와 Redis가 다른 점

둘 다 램에 두고 앱 서버가 마운트 없이 붙는다는 점은 같습니다. 차이는 값의 종류와, 서버가 죽었을 때 누가 키를 다시 찾는지입니다.

Memcached는 문자열과 만료가 중심입니다. 복제와 슬롯 분할을 엔진이 맡지 않는 구성이 많아서, 클라이언트가 키를 서버 목록에 나누는 방식이 많습니다. 서버 한 대가 빠지면 그 구간의 키는 없고, 다음 로그인 때 다시 채웁니다.

Redis는 해시와 집합이 있고, 복제와 클러스터가 엔진 안에 있습니다. 세션을 필드로 나눠 고치거나, 같은 저장소에 짧은 잠금을 얹을 수 있습니다. 그 대가로 센티넬, 샤드, 슬롯을 운영 개념에 넣어야 합니다.

비교	Memcached	Redis
값	문자열 중심입니다.	문자열, 해시, 리스트, 집합이 있습니다.
디스크 기록	기본적으로 없습니다.	RDB, AOF를 켤 수 있습니다.
여러 대	클라이언트가 키를 나누는 구성이 많습니다.	클러스터가 슬롯으로 나눕니다.
세션	키 하나에 문자열이면 충분합니다.	필드 단위 수정이나 잠금을 같은 곳에 둘 때 해시가 있습니다.

이미 Memcached로 세션이 유지되고 있다면, 문자열 키만으로 요구가 끝나는지 보면 됩니다. 필드 수정이나 잠금을 같은 저장소에 둘 계획이면 Redis나 Valkey 쪽 요청이 됩니다. 그 계획이 없으면 엔진만 하나 더 생깁니다.

10. Valkey와 Redis가 갈라진 지점

갈라진 이유는 기능 이름보다 라이선스와 프로젝트가 나뉜 시점입니다. 명령은 세션에서 거의 같습니다. HSET, EXPIRE, TTL 은 양쪽에서 같은 역할을 합니다.

2024년 3월 Redis 쪽은 이후 버전을 기존 BSD만으로 두지 않았습니다. 같은 시기 리눅스 재단과 기여자들이 Redis OSS 7.2를 포크해 Valkey를 만들었고, 라이선스는 BSD 3-Clause입니다. AWS 설명에서는 Redis OSS 7.2를 그 이전 계열의 마지막 완전 오픈소스 버전으로 두고, Redis 8.0부터 AGPLv3가 선택지에 들어갑니다. AGPLv3는 수정분을 공개하는 조건이 있어서 회사마다 채택 기준이 다릅니다. 라이선스 문구는 바뀔 수 있으니 도입 전에 조직의 기준과 운영 버전 릴리스 노트를 보면 됩니다.

세션에 문자열이나 해시만 쓰면 둘 다 됩니다. 차이가 드러나는 곳은 모듈입니다. Redis 8은 JSON이나 검색 같은 기능을 코어로 가져온 쪽이 있고, Valkey는 그 기능을 별도 모듈로 두는 구간이 있습니다. 세션 키만 쓰면 이 차이는 거의 보이지 않습니다. 검색 모듈을 이미 쓰고 있으면 그 모듈이 Valkey에 있는지만 보면 됩니다.

💡 엔진을 적을 때 요청서에는 Redis OSS인지 Valkey인지를 적습니다. 클라이언트가 기대하는 명령과 모듈이 엔진마다 다를 수 있습니다. 설치된 버전 번호는 앱 설정 옆에 남겨 두고, 업그레이드 때 릴리스 노트와 다시 비교하면 됩니다.

11. AWS ElastiCache에서 Redis와 Valkey

ElastiCache는 Redis OSS, Valkey, Memcached를 관리형으로 띄우는 서비스입니다. 백업, 패치, 페일오버의 일부를 AWS가 맡아서, 직접 설치할 때 서버 담당이 보던 감시 프로세스를 서비스가 대신하는 구간이 있습니다. 앱은 여전히 끝점으로 붙습니다. 마운트는 없습니다.

구성은 노드를 지정하는 방식과 서버리스가 있습니다. 노드 방식은 샤드 수와 인스턴스 크기를 사람이 고릅니다. 대신 비용 상한이 보입니다. 서버리스는 용량 조절을 서비스가 더 많이 맡아서, 트래픽이 낮과 밤으로 출렁여도 노드를 직접 늘리고 줄이지 않습니다. 어느 쪽이 싼지는 리전과 사용량에 따라 달라서, 콘솔 견적 없이 단정하지 않습니다.

2026년 10월에 확인한 AWS 문서 기준으로, ElastiCache for Valkey 서버리스 요금은 다른 지원 엔진보다 33% 낮고 노드 방식은 20% 낮다고 되어 있습니다. 기존 Redis OSS 예약 노드 할인을 Valkey에 이어 쓰는 경로도 있습니다. 요금 페이지가 바뀌면 그 페이지가 우선입니다. Redis OSS에서 Valkey로의 엔진 변경은 제자리 업그레이드로 다운타임 없이 가능하다는 안내가 있습니다.

그래도 TLS, 클러스터 모드, 데이터베이스 번호 사용 여부는 스테이징에서 봅니다. Redis 클러스터는 0번 데이터베이스만 쓸 수 있어서, SELECT 1 처럼 번호로 공간을 나누던 코드는 오류가 납니다. 클러스터는 번호가 아니라 슬롯으로 키를 나누기 때문입니다. Valkey는 9.0부터 클러스터에서도 여러 번호를 쓸 수 있게 바뀌었으니, 이 기능에 기대려면 ElastiCache에서 쓰는 엔진 버전이 지원하는지 먼저 확인합니다.

MemoryDB는 같은 회사에서 재시작 뒤에도 값을 남기는 쪽을 더 강조하는 다른 서비스입니다. 세션은 사라져도 다시 로그인하면 되는 값이라, 남을 것을 전제로 한 서비스에 두지 않아도 됩니다. 남아야 하는 원장은 데이터베이스로 나누면 요청서의 용도가 세션으로 고정됩니다.

12. 세션에 Redis를 쓰면 안 되는 경우

포인트 잔액, 결제 상태, 재고는 Redis에 두지 않습니다. 퇴거되거나 프로세스가 죽으면 값이 사라지거나 옛 스냅샷으로 돌아갑니다. 그 값은 데이터베이스 트랜잭션으로 남깁니다.

값이 램보다 크면 램 비용이 커집니다. 세션에 이미지 바이너리나 검색 결과 전체를 넣으면 키 하나가 커지고, 그 명령을 처리하는 동안 다른 로그인이 기다립니다. 세션에는 아이디와 짧은 권한만 두고, 큰 데이터는 저장소 주소만 남깁니다.

다시 로그인을 허용하지 않는 요건이면 램이 비는 전제와 맞지 않습니다. 마운트는 서버가 늘 때마다 장애 지점이 늘어서, 세션을 데이터베이스에 둘 때도 파일 마운트는 피합니다. Redis에 AOF와 복제를 켜도, 그 조합은 캐시보다 작은 데이터베이스에 가깝습니다. 디스크 기록과 페일오버를 서버 담당과 다시 맞춰야 합니다.

여러 리전에서 같은 초에 같은 세션을 고치면 한 리전의 Redis로는 부족합니다. 리전 사이 복제는 지연이 있어서, 다른 리전은 방금 쓴 값을 아직 모를 수 있습니다. 세션을 리전 안에만 두고 로그인 토큰을 따로 설계하면 복제 지연을 세션 갱신에 태우지 않습니다.

자주 묻는 질문 (FAQ)

Redis 세션은 서버를 재부팅하면 다 사라지나요?

디스크 기록이 꺼져 있으면 값이 램에만 있어서 재부팅하면 사라집니다. 직접 설치한 Redis는 기본으로 RDB 스냅샷이 켜져 있어서 마지막 스냅샷까지는 남고, 그 뒤에 바뀐 값은 없을 수 있습니다. 관리형 서비스는 기본이 꺼진 경우가 많으니 설정을 확인합니다.

샤드와 노드는 같은 말인가요?

아닙니다. 노드는 프로세스 한 개입니다. 샤드는 슬롯 범위를 맡은 프라이머리와 그 복제본의 묶음입니다. 노드를 추가해도 슬롯을 옮기기 전에는 기존 키가 새 노드로 가지 않습니다.

Valkey로 바꾸면 세션 코드를 새로 짜야 하나요?

해시와 만료만 쓰는 세션은 명령이 같아서 그대로인 경우가 많습니다. 확인할 곳은 클라이언트가 붙는 엔진 이름, TLS, 클러스터 모드입니다. 모듈을 세션 밖에 쓰고 있었다면 그 모듈이 있는지만 보면 됩니다.

세션은 디스크 공유가 아니라 만료 있는 키로 둡니다

만료 있는 키로 옮기면, 서버를 늘릴 때 세션 폴더를 마운트하지 않아도 됩니다.

엔진은 Redis OSS, Valkey, Memcached 중에서 고르면 됩니다. 문자열 키만이면 셋 다 마운트 없이 공유됩니다. 필드와 샤드까지 쓰면 Redis와 Valkey 쪽으로 요청이 모입니다. 요금과 라이선스는 앞에서 인용한 문서를 보고, 도입 달의 공식 문서와 한 번 더 비교하면 됩니다.

📚 함께 보면 좋은 글

쿠키·세션·JWT·OAuth 차이와 변천사 — 패스키까지 한눈에

데이터는 어디에 저장될까 - CPU·메모리·하드디스크로 이해하는 Redis·MySQL·MongoDB

Apache Nginx Tomcat 차이 완벽 정리 - 웹서버 30년 변천사로 이해하기