Upstash Redis 무료 DB 1개, prefix로 서비스 여러 개 굴리기

혼자 서비스 여러 개를 굴리다 보면 인프라 비용부터 줄이게 돼요. 라이프케어로그도 플랜씨(plan-c), 플랜엘(plan-l) 같은 작은 서비스를 여럿 운영하는데, Redis까지 서비스마다 따로 두기엔 부담이었어요.

Upstash 무료 플랜은 DB가 1개예요. 그래서 DB를 늘리는 대신 키 앞에 prefix를 붙여 하나를 나눠 쓰기로 했어요. 직접 나눠 써 보니 설계 자체는 단순한데, 함정이 몇 개 있었어요.

키 구조는 3단계면 충분해요

서비스:도메인:키 순서로 3단계를 기본으로 잡았어요. 여기에 로컬 테스트용 환경 표시까지 넣으면 4단계가 돼요.

서비스 이름→환경(prod/dev)→도메인→실제 키

구분자는 콜론(:) 하나로 통일했어요. Redis GUI 도구 대부분이 콜론 기준으로 키를 폴더처럼 묶어 보여줘서, 나중에 디버깅할 때 서비스별로 접어 볼 수 있어요.

중요한 건 prefix를 코드 곳곳에 문자열로 박지 않는 거예요. 10줄짜리 키 생성 헬퍼 함수 하나를 만들어 두고, 모든 키가 이 함수를 거치게 했어요. 기존 키를 새 규칙으로 옮기는 정리는 30분 정도 걸렸어요.

함정 1: FLUSHDB는 전 서비스를 지워요

한 서비스 캐시만 비우려고 FLUSHDB를 치면, DB가 하나라서 다른 서비스 데이터까지 전부 날아가요. SCAN으로 prefix 패턴에 맞는 키만 걸러서 지워야 해요. 처음 캐시를 비울 일이 생겼을 때 손이 FLUSHDB로 가려는 걸 멈추고, prefix 범위만 지우는 스크립트를 따로 만들어 뒀어요.

함정 2: 라이브러리는 자기 마음대로 키를 써요

rate limit 라이브러리 같은 걸 붙여 보면 자기 기본 prefix로 키를 만들어요. 내 네임스페이스 규칙 밖에서 키가 생기는 거예요. 적용해 봤더니 어느 서비스 키인지 구분이 안 되는 키가 쌓여 있더라고요. 라이브러리를 붙일 땐 prefix 옵션이 있는지부터 확인하고, 없으면 다른 걸 찾는 편이 나아요.

함정 3: 한도도 같이 나눠 써요

DB가 하나면 무료 한도(요청 수·저장 용량)도 전 서비스가 공유해요. 한 서비스 캐시가 폭주하면 다른 서비스 한도까지 같이 깎아 먹어요. 그래서 캐시 키엔 TTL을 반드시 걸었어요. 돌려 보니 큰 값을 오래 들고 있는 키가 제일 문제라, 만료 시간을 짧게 잡는 쪽으로 바꿨어요.

• ✓FLUSHDB 금지
• ✓라이브러리 prefix 확인
• ✓TTL 필수

직접 운영해 보니 무료 DB 1개로도 규칙만 잡으면 서비스 여러 개가 잘 굴러가요. 핵심은 화려한 설계가 아니라, 키 하나를 만들 때도 같은 문을 지나가게 하는 작은 규칙이에요. 비슷하게 무료 티어를 쪼개 쓰고 있다면, 키 헬퍼 함수부터 하나 만들어 보세요.