이미지 로딩 중...
AI Generated
2025. 11. 8. · 4 Views
Next.js 실전 운영 Redis 캐싱 전략 완벽 가이드
Next.js 애플리케이션의 성능을 극대적으로 향상시키는 Redis 캐싱 전략을 배웁니다. 실무에서 바로 적용 가능한 다양한 캐싱 패턴과 최적화 기법을 통해 응답 시간을 획기적으로 단축하고 서버 부하를 줄이는 방법을 익힐 수 있습니다.
목차
- Redis 클라이언트 설정 - 안정적인 연결 관리
- API 응답 캐싱 - 데이터베이스 부하 감소
- 캐시 무효화 전략 - 데이터 일관성 유지
- 페이지 단위 캐싱 - SSR 성능 최적화
- Rate Limiting - API 호출 제한
- 세션 스토어 - 빠르고 확장 가능한 인증
- 실시간 리더보드 - Sorted Set 활용
- 캐시 워밍과 사전 로딩 전략
- 분산 락 - 동시성 제어
- 캐시 만료와 갱신 전략 - Stale-While-Revalidate
1. Redis 클라이언트 설정 - 안정적인 연결 관리
시작하며
여러분이 Next.js 애플리케이션을 운영하다가 갑자기 트래픽이 급증하면서 데이터베이스 쿼리가 느려지고, 사용자들이 "페이지가 느려요"라는 불만을 제기한 적 있나요? 또는 똑같은 데이터를 반복해서 데이터베이스에서 가져오면서 불필요한 리소스를 낭비하고 있진 않나요?
이런 문제는 특히 실시간 데이터가 많거나 사용자가 많은 서비스에서 심각한 병목 현상을 일으킵니다. 데이터베이스는 매번 디스크에서 데이터를 읽어야 하기 때문에 응답 시간이 느릴 수밖에 없고, 동시 접속자가 많아질수록 성능이 급격히 저하됩니다.
바로 이럴 때 필요한 것이 Redis 캐싱입니다. Redis를 활용하면 자주 조회되는 데이터를 메모리에 저장해두고 빠르게 제공할 수 있어, 데이터베이스 부하를 줄이고 응답 시간을 10배 이상 단축시킬 수 있습니다.
개요
간단히 말해서, Redis는 메모리 기반의 초고속 데이터 저장소입니다. 일반 데이터베이스가 하드디스크에 데이터를 저장한다면, Redis는 RAM에 데이터를 저장하기 때문에 밀리초 단위의 초고속 응답이 가능합니다.
Next.js 애플리케이션에서 Redis를 사용하면 API 응답 데이터, 세션 정보, 계산 결과 등을 캐싱할 수 있습니다. 예를 들어, 인기 상품 목록이나 사용자 프로필 같이 자주 조회되지만 자주 변경되지 않는 데이터를 캐싱하면 데이터베이스 쿼리를 거의 없앨 수 있습니다.
기존에는 매 요청마다 데이터베이스에 접근해서 100ms가 걸렸다면, Redis를 사용하면 5ms 이내로 응답할 수 있습니다. 이는 사용자 경험을 크게 개선하고 서버 비용도 절감시킵니다.
Redis의 핵심 특징은 첫째, 인메모리 저장으로 초고속 읽기/쓰기가 가능하고, 둘째, 다양한 데이터 구조(문자열, 리스트, 해시, 집합 등)를 지원하며, 셋째, TTL(Time To Live)을 설정해 자동으로 데이터를 만료시킬 수 있다는 점입니다. 이러한 특징들이 실시간 애플리케이션의 성능을 극대화하는 데 핵심적인 역할을 합니다.
코드 예제
// lib/redis.ts
import { createClient } from 'redis';
// Redis 클라이언트 인스턴스를 전역으로 관리
let redisClient: ReturnType<typeof createClient> | null = null;
export async function getRedisClient() {
// 이미 연결된 클라이언트가 있으면 재사용
if (redisClient && redisClient.isOpen) {
return redisClient;
}
// 새로운 Redis 클라이언트 생성
redisClient = createClient({
url: process.env.REDIS_URL || 'redis://localhost:6379',
socket: {
reconnectStrategy: (retries) => Math.min(retries * 50, 1000), // 재연결 전략
},
});
// 에러 핸들링
redisClient.on('error', (err) => console.error('Redis Error:', err));
// Redis 서버에 연결
await redisClient.connect();
console.log('Redis connected successfully');
return redisClient;
}
설명
이것이 하는 일: Redis 서버와의 연결을 안정적으로 관리하고, 애플리케이션 전체에서 하나의 연결을 재사용할 수 있도록 하는 클라이언트 설정입니다. Next.js의 서버리스 환경에서도 효율적으로 작동하도록 설계되었습니다.
첫 번째로, getRedisClient 함수는 전역 변수 redisClient를 체크합니다. 이미 연결된 클라이언트가 있고 연결이 열려있다면 새로운 연결을 만들지 않고 기존 연결을 반환합니다.
이는 불필요한 연결 생성을 방지하고 리소스를 절약하는 중요한 패턴입니다. Next.js의 서버리스 함수는 때때로 재사용되기 때문에, 이런 싱글톤 패턴이 특히 중요합니다.
그 다음으로, createClient 함수로 새 클라이언트를 생성할 때 환경변수에서 Redis URL을 읽어옵니다. reconnectStrategy는 연결이 끊겼을 때 자동으로 재연결을 시도하는 전략을 정의합니다.
재시도 횟수가 늘어날수록 대기 시간이 증가하지만 최대 1초를 넘지 않도록 설정했습니다. 이렇게 하면 일시적인 네트워크 문제가 발생해도 자동으로 복구됩니다.
세 번째로, 에러 이벤트 리스너를 등록하여 Redis 관련 오류를 로깅합니다. 실제 프로덕션 환경에서는 이 부분에 모니터링 시스템 연동이나 알림 설정을 추가하는 것이 좋습니다.
마지막으로 await redisClient.connect()로 실제 연결을 수행하고, 성공하면 로그를 남깁니다. 여러분이 이 코드를 사용하면 애플리케이션의 모든 부분에서 안정적인 Redis 연결을 사용할 수 있습니다.
연결 풀 관리를 자동으로 처리하고, 네트워크 문제가 발생해도 자동으로 재연결되며, 메모리 누수 없이 효율적으로 작동합니다. 특히 Vercel이나 AWS Lambda 같은 서버리스 환경에서 연결 재사용이 성능에 큰 영향을 미칩니다.
실전 팁
💡 환경변수로 Redis URL을 관리하면 개발/스테이징/프로덕션 환경을 쉽게 전환할 수 있습니다. .env.local 파일에 REDIS_URL을 설정하세요.
💡 프로덕션 환경에서는 Redis 클라우드 서비스(AWS ElastiCache, Redis Cloud 등)를 사용하는 것이 좋습니다. 고가용성과 자동 백업이 보장됩니다.
💡 연결이 너무 많이 생성되는지 확인하려면 Redis CLI에서 CLIENT LIST 명령어로 현재 연결 수를 모니터링하세요.
💡 Next.js에서 Redis를 사용할 때는 반드시 서버 컴포넌트나 API 라우트에서만 사용하세요. 클라이언트 컴포넌트에서는 사용할 수 없습니다.
💡 개발 환경에서는 Docker로 Redis를 로컬에서 실행하면 편리합니다: docker run -d -p 6379:6379 redis:alpine
2. API 응답 캐싱 - 데이터베이스 부하 감소
시작하며
여러분의 Next.js 애플리케이션에서 사용자 프로필이나 상품 정보를 조회하는 API가 있다고 가정해봅시다. 같은 사용자가 페이지를 새로고침할 때마다, 또는 여러 사용자가 같은 상품을 볼 때마다 데이터베이스에 동일한 쿼리를 반복하고 있지 않나요?
이런 반복적인 데이터베이스 쿼리는 응답 시간을 느리게 만들고, 데이터베이스 서버에 불필요한 부하를 일으킵니다. 특히 복잡한 JOIN 쿼리나 집계 함수를 사용하는 경우 한 번의 쿼리에 수백 밀리초가 걸릴 수 있습니다.
트래픽이 많은 시간대에는 데이터베이스가 병목이 되어 전체 서비스가 느려질 수 있습니다. 바로 이럴 때 필요한 것이 API 응답 캐싱입니다.
한 번 조회한 데이터를 Redis에 저장해두면, 다음 요청부터는 데이터베이스를 거치지 않고 Redis에서 즉시 응답할 수 있습니다. 이를 통해 응답 시간을 10배 이상 단축하고 데이터베이스 부하를 크게 줄일 수 있습니다.
개요
간단히 말해서, API 응답 캐싱은 데이터베이스 조회 결과를 Redis에 저장했다가 재사용하는 전략입니다. 첫 번째 요청 때는 데이터베이스에서 데이터를 가져오지만, 그 결과를 Redis에 저장해두고 일정 시간 동안은 Redis에서 바로 응답합니다.
이 방법은 자주 조회되지만 자주 변경되지 않는 데이터에 특히 효과적입니다. 예를 들어, 사용자 프로필, 카테고리 목록, 인기 게시글, 통계 데이터 같은 경우 캐싱을 적용하면 데이터베이스 쿼리를 90% 이상 줄일 수 있습니다.
기존에는 매 요청마다 "데이터베이스 연결 → 쿼리 실행 → 결과 반환"의 과정을 거쳤다면, 이제는 "Redis 조회 → 있으면 즉시 반환, 없으면 데이터베이스 조회 후 Redis에 저장"의 방식으로 동작합니다. API 응답 캐싱의 핵심은 첫째, Cache-Aside 패턴을 사용하여 필요할 때만 캐싱하고, 둘째, TTL(만료 시간)을 적절히 설정하여 오래된 데이터 문제를 방지하며, 셋째, 캐시 키를 체계적으로 관리하여 업데이트와 무효화를 쉽게 한다는 것입니다.
이러한 전략들이 안정적이고 빠른 API를 만드는 데 핵심입니다.
코드 예제
// app/api/users/[id]/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { getRedisClient } from '@/lib/redis';
import { prisma } from '@/lib/prisma';
export async function GET(
request: NextRequest,
{ params }: { params: { id: string } }
) {
const userId = params.id;
const cacheKey = `user:${userId}`;
try {
const redis = await getRedisClient();
// 1. Redis에서 캐시된 데이터 확인
const cachedUser = await redis.get(cacheKey);
if (cachedUser) {
console.log('Cache HIT for', cacheKey);
return NextResponse.json(JSON.parse(cachedUser));
}
console.log('Cache MISS for', cacheKey);
// 2. 캐시 미스: 데이터베이스에서 조회
const user = await prisma.user.findUnique({ where: { id: userId } });
if (!user) {
return NextResponse.json({ error: 'User not found' }, { status: 404 });
}
// 3. Redis에 저장 (TTL: 5분)
await redis.setEx(cacheKey, 300, JSON.stringify(user));
return NextResponse.json(user);
} catch (error) {
console.error('API Error:', error);
return NextResponse.json({ error: 'Internal error' }, { status: 500 });
}
}
설명
이것이 하는 일: 사용자 정보 조회 API에서 Redis 캐싱을 적용하여 데이터베이스 부하를 줄이고 응답 속도를 극대화합니다. Cache-Aside(Lazy Loading) 패턴을 사용하여 실제로 요청이 있을 때만 캐시를 채웁니다.
첫 번째로, 캐시 키를 user:${userId} 형식으로 생성합니다. 이런 명명 규칙을 일관되게 사용하면 나중에 특정 사용자의 캐시를 무효화하거나 관련 캐시를 찾기가 쉽습니다.
Redis에서 redis.get(cacheKey)로 캐시된 데이터가 있는지 확인하고, 있다면 "Cache HIT"라고 로깅한 후 즉시 반환합니다. 이 경우 데이터베이스 쿼리가 전혀 발생하지 않아 응답이 매우 빠릅니다.
그 다음으로, 캐시에 데이터가 없으면 "Cache MISS"를 로깅하고 Prisma를 사용해 데이터베이스에서 실제 사용자 정보를 조회합니다. 이때 사용자가 존재하지 않으면 404 에러를 반환하여 적절한 에러 처리를 합니다.
이런 에러 케이스도 캐싱하고 싶다면 별도의 캐시 키로 저장할 수 있습니다. 세 번째로, 데이터베이스에서 가져온 사용자 정보를 redis.setEx()로 Redis에 저장합니다.
setEx는 SET과 EXPIRE를 한 번에 실행하는 명령어로, 여기서는 300초(5분) 후에 자동으로 만료되도록 설정했습니다. JSON.stringify로 객체를 문자열로 변환해서 저장하고, 조회할 때는 JSON.parse로 다시 객체로 변환합니다.
여러분이 이 코드를 사용하면 같은 사용자 정보를 5분 동안 수십 번, 수백 번 조회해도 데이터베이스 쿼리는 단 한 번만 발생합니다. 실제 벤치마크 결과 데이터베이스 조회가 평균 100ms 걸린다면, Redis 캐시는 5ms 이하로 응답하여 20배 빠른 성능을 보입니다.
또한 데이터베이스 연결 수가 줄어들어 동시 접속자가 많아져도 안정적으로 서비스할 수 있습니다.
실전 팁
💡 TTL은 데이터 특성에 따라 조정하세요. 거의 변하지 않는 데이터는 1시간1일, 자주 변하는 데이터는 15분이 적당합니다.
💡 Cache HIT/MISS 비율을 모니터링하여 캐싱 전략의 효과를 측정하세요. HIT 비율이 80% 이상이면 성공적입니다.
💡 데이터가 업데이트될 때는 해당 캐시를 수동으로 삭제(redis.del(cacheKey))하여 일관성을 유지하세요.
💡 민감한 개인정보는 캐싱 전에 꼭 필요한 필드만 선택하고, Redis 서버도 암호화와 접근 제어를 설정하세요.
💡 JSON.stringify/parse 오버헤드를 줄이려면 msgpack 같은 바이너리 직렬화 라이브러리를 사용할 수 있습니다.
3. 캐시 무효화 전략 - 데이터 일관성 유지
시작하며
여러분이 Redis 캐싱을 적용했는데, 사용자가 프로필을 업데이트했는데도 여전히 이전 정보가 보인다는 문제를 경험한 적 있나요? 또는 상품 가격을 변경했는데 캐시 때문에 오래된 가격이 계속 노출되어 고객 불만이 발생한 적은요?
이런 문제는 캐싱을 사용할 때 가장 흔하게 발생하는 데이터 일관성 문제입니다. 캐시는 성능을 높여주지만, 잘못 관리하면 사용자에게 잘못된 정보를 제공하게 됩니다.
특히 결제 금액, 재고 수량, 권한 정보처럼 정확성이 중요한 데이터에서는 치명적일 수 있습니다. 바로 이럴 때 필요한 것이 체계적인 캐시 무효화 전략입니다.
데이터가 변경될 때 관련된 캐시를 즉시 삭제하거나 업데이트하여 항상 최신 정보를 제공할 수 있습니다. 이를 통해 성능과 정확성을 동시에 확보할 수 있습니다.
개요
간단히 말해서, 캐시 무효화는 원본 데이터가 변경되었을 때 캐시된 데이터를 제거하거나 갱신하는 작업입니다. 이를 통해 사용자가 항상 최신 데이터를 보도록 보장합니다.
캐시 무효화 전략은 크게 세 가지가 있습니다. Write-Through는 데이터를 쓸 때 동시에 캐시도 업데이트하고, Write-Behind는 나중에 비동기로 업데이트하며, Cache Invalidation은 캐시를 삭제만 하고 다음 조회 때 다시 채우는 방식입니다.
Next.js API에서는 주로 Cache Invalidation 방식이 가장 간단하고 안전합니다. 기존에는 TTL에만 의존해서 "5분 뒤에 자동으로 만료될 거야"라고 생각했다면, 이제는 "데이터가 변경되는 즉시 캐시를 삭제해서 다음 요청 때 새 데이터를 가져오도록" 할 수 있습니다.
캐시 무효화의 핵심은 첫째, 데이터 변경과 캐시 삭제를 원자적으로 처리하고, 둘째, 관련된 모든 캐시를 찾아서 삭제하며, 셋째, 무효화 실패 시에도 시스템이 안전하게 동작하도록 설계하는 것입니다. 이러한 원칙들이 신뢰할 수 있는 캐싱 시스템을 만듭니다.
코드 예제
// app/api/users/[id]/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { getRedisClient } from '@/lib/redis';
import { prisma } from '@/lib/prisma';
export async function PATCH(
request: NextRequest,
{ params }: { params: { id: string } }
) {
const userId = params.id;
const updateData = await request.json();
try {
const redis = await getRedisClient();
// 1. 데이터베이스 업데이트
const updatedUser = await prisma.user.update({
where: { id: userId },
data: updateData,
});
// 2. 관련 캐시 무효화
const cacheKeys = [
`user:${userId}`, // 사용자 상세 정보
`user:${userId}:posts`, // 사용자 게시글 목록
`users:list`, // 전체 사용자 목록
];
// 여러 캐시 키를 한 번에 삭제
await redis.del(cacheKeys);
console.log('Invalidated caches:', cacheKeys);
// 3. 선택적: 새 데이터를 즉시 캐싱 (Write-Through 패턴)
await redis.setEx(`user:${userId}`, 300, JSON.stringify(updatedUser));
return NextResponse.json(updatedUser);
} catch (error) {
console.error('Update Error:', error);
return NextResponse.json({ error: 'Update failed' }, { status: 500 });
}
}
설명
이것이 하는 일: 사용자 정보를 업데이트할 때 데이터베이스 변경과 함께 관련된 모든 캐시를 무효화하여 데이터 일관성을 보장합니다. 이를 통해 사용자가 항상 최신 정보를 보도록 합니다.
첫 번째로, Prisma를 사용해 데이터베이스의 사용자 정보를 업데이트합니다. 이 작업이 성공해야만 캐시 무효화를 진행합니다.
만약 데이터베이스 업데이트가 실패하면 캐시도 건드리지 않아 일관성이 유지됩니다. 트랜잭션이 필요한 복잡한 경우에는 Prisma의 $transaction을 사용할 수 있습니다.
그 다음으로, 무효화해야 할 캐시 키들을 배열로 정의합니다. 단순히 해당 사용자의 정보만 삭제하는 것이 아니라, 그 사용자와 관련된 모든 캐시를 찾아서 삭제해야 합니다.
예를 들어 사용자의 이름이 바뀌면 사용자 목록 캐시에도 영향을 미치므로 함께 삭제해야 합니다. 이런 관계를 명확히 파악하는 것이 중요합니다.
세 번째로, redis.del(cacheKeys)로 여러 캐시를 한 번에 삭제합니다. Redis의 DEL 명령어는 여러 키를 배열로 받을 수 있어 효율적입니다.
삭제된 키 목록을 로깅하면 디버깅할 때 유용합니다. 마지막으로 선택적으로 업데이트된 데이터를 즉시 다시 캐싱할 수 있습니다.
이는 Write-Through 패턴이라고 하며, 다음 조회 요청을 더 빠르게 처리할 수 있습니다. 여러분이 이 코드를 사용하면 사용자가 정보를 수정한 즉시 모든 관련 화면에서 업데이트된 정보가 표시됩니다.
TTL 만료를 기다릴 필요 없이 실시간으로 동기화되어 사용자 경험이 크게 개선됩니다. 또한 불필요한 캐시가 남아있지 않아 메모리 효율성도 좋아집니다.
실무에서는 이 패턴을 모든 업데이트/삭제 API에 적용하는 것이 좋습니다.
실전 팁
💡 캐시 키 명명 규칙을 문서화하고 팀 전체가 일관되게 사용하세요. 예: {resource}:{id} 또는 {resource}:{id}:{relation} 형식
💡 캐시 무효화 로직을 별도 함수로 분리하면 재사용성이 높아집니다: async function invalidateUserCache(userId) { ... }
💡 패턴 매칭으로 관련 캐시를 한 번에 삭제하려면 redis.keys('user:*')를 사용할 수 있지만, 프로덕션에서는 성능 문제가 있으니 조심하세요.
💡 캐시 무효화가 실패해도 애플리케이션이 동작하도록 try-catch로 감싸고, 실패 시 로그만 남기는 것도 고려하세요.
💡 매우 중요한 데이터는 캐시 무효화 후 강제로 다시 조회하여 실제로 최신 데이터인지 확인하는 검증 로직을 추가할 수 있습니다.
4. 페이지 단위 캐싱 - SSR 성능 최적화
시작하며
여러분이 Next.js의 서버 사이드 렌더링(SSR)을 사용해서 동적 페이지를 만들었는데, 페이지 로딩이 너무 느려서 사용자들이 이탈한다는 분석 결과를 받은 적 있나요? 특히 복잡한 데이터 조회와 계산이 필요한 대시보드나 리포트 페이지에서는 서버 렌더링에 수 초가 걸리기도 합니다.
이런 문제는 SSR의 근본적인 특성 때문입니다. 매 요청마다 서버에서 모든 데이터를 조회하고 HTML을 생성해야 하므로, 복잡한 페이지일수록 응답 시간이 길어집니다.
그렇다고 CSR로 전환하면 SEO와 초기 로딩 성능이 나빠지는 딜레마에 빠집니다. 바로 이럴 때 필요한 것이 페이지 단위 캐싱입니다.
렌더링된 HTML이나 필요한 데이터를 Redis에 캐싱해두면, SSR의 장점은 유지하면서도 빠른 응답 속도를 얻을 수 있습니다. 특히 모든 사용자에게 같은 내용이 보이는 페이지라면 한 번 렌더링한 결과를 재사용할 수 있어 서버 부하를 극적으로 줄일 수 있습니다.
개요
간단히 말해서, 페이지 단위 캐싱은 서버에서 생성한 페이지 데이터나 HTML을 Redis에 저장했다가 재사용하는 전략입니다. Next.js의 getServerSideProps나 Server Component에서 데이터를 조회할 때 Redis 캐시를 먼저 확인합니다.
이 방법은 특히 뉴스 목록, 상품 카탈로그, 통계 대시보드처럼 모든 사용자에게 동일한 내용을 보여주는 페이지에 효과적입니다. 예를 들어, 일일 통계 페이지는 하루에 한 번만 계산하면 되므로 첫 번째 방문자를 위해 계산한 결과를 캐싱해두고 나머지 사용자들에게는 즉시 제공할 수 있습니다.
기존에는 매 요청마다 "여러 데이터베이스 쿼리 → 데이터 가공 → HTML 렌더링"의 전체 과정을 거쳤다면, 이제는 "Redis 조회 → 있으면 즉시 반환, 없으면 전체 과정 수행 후 캐싱"으로 바뀝니다. 페이지 캐싱의 핵심은 첫째, 사용자별로 다른 내용이 아닌 공통 데이터만 캐싱하고, 둘째, 적절한 캐시 키 전략으로 페이지 변형(페이지네이션, 필터 등)을 처리하며, 셋째, Stale-While-Revalidate 패턴으로 백그라운드에서 캐시를 갱신하는 것입니다.
이러한 기법들이 사용자 경험과 서버 효율성을 모두 높입니다.
코드 예제
// app/products/page.tsx
import { getRedisClient } from '@/lib/redis';
import { prisma } from '@/lib/prisma';
async function getProducts(category?: string) {
const redis = await getRedisClient();
const cacheKey = `products:list:${category || 'all'}`;
// 1. 캐시 확인
const cached = await redis.get(cacheKey);
if (cached) {
console.log('Page cache HIT:', cacheKey);
return JSON.parse(cached);
}
console.log('Page cache MISS:', cacheKey);
// 2. 데이터베이스 조회 (복잡한 쿼리 시뮬레이션)
const products = await prisma.product.findMany({
where: category ? { category } : {},
include: {
reviews: { take: 5 },
images: true,
},
orderBy: { popularity: 'desc' },
});
// 3. 데이터 가공
const processedData = products.map(p => ({
...p,
averageRating: p.reviews.reduce((a, r) => a + r.rating, 0) / p.reviews.length,
}));
// 4. 캐싱 (10분 TTL)
await redis.setEx(cacheKey, 600, JSON.stringify(processedData));
return processedData;
}
export default async function ProductsPage({
searchParams,
}: {
searchParams: { category?: string };
}) {
const products = await getProducts(searchParams.category);
return (
<div>
<h1>상품 목록</h1>
{products.map(product => (
<ProductCard key={product.id} product={product} />
))}
</div>
);
}
설명
이것이 하는 일: Next.js App Router의 서버 컴포넌트에서 상품 목록 페이지 데이터를 Redis에 캐싱하여 SSR 성능을 극대화합니다. 복잡한 데이터베이스 쿼리와 데이터 가공 작업을 첫 번째 요청에서만 수행하고, 이후 요청들은 캐시된 결과를 즉시 반환합니다.
첫 번째로, 캐시 키를 products:list:${category || 'all'} 형식으로 생성합니다. 카테고리별로 다른 캐시를 사용하므로 "전자제품" 카테고리와 "의류" 카테고리가 각각 독립적으로 캐싱됩니다.
이런 세분화된 캐시 키 전략은 불필요한 캐시 무효화를 방지하고 효율성을 높입니다. searchParams를 캐시 키에 포함시켜서 필터나 정렬 옵션도 별도로 캐싱할 수 있습니다.
그 다음으로, 캐시가 없을 때 Prisma로 복잡한 쿼리를 실행합니다. 여기서는 상품 정보와 함께 리뷰 5개, 이미지를 모두 조인하여 가져옵니다.
이런 복잡한 쿼리는 대량의 데이터가 있을 때 수백 밀리초가 걸릴 수 있습니다. 또한 인기도 순으로 정렬하는데, 이런 정렬 작업도 데이터베이스 부하를 증가시킵니다.
세 번째로, 조회한 데이터를 가공합니다. 여기서는 리뷰들의 평균 평점을 계산하는데, 이런 집계 연산을 매번 하는 것은 비효율적입니다.
실제 프로덕션에서는 더 복잡한 비즈니스 로직이나 외부 API 호출이 있을 수 있습니다. 이 모든 작업의 결과를 Redis에 10분간 캐싱하여 이후 요청들은 즉시 처리됩니다.
여러분이 이 코드를 사용하면 상품 목록 페이지의 로딩 시간을 극적으로 단축할 수 있습니다. 데이터베이스 쿼리와 데이터 가공에 500ms가 걸렸다면, 캐시를 사용하면 10ms 이내로 응답합니다.
특히 트래픽이 많은 시간대에 서버 부하가 크게 줄어들어 더 많은 동시 사용자를 처리할 수 있습니다. SEO를 위한 서버 렌더링은 유지하면서 성능은 정적 사이트 수준으로 향상됩니다.
실전 팁
💡 사용자별로 다른 내용을 보여주는 페이지(개인화된 추천 등)는 페이지 전체 캐싱 대신 데이터 조각별로 캐싱하세요.
💡 페이지네이션이 있다면 캐시 키에 페이지 번호를 포함시키세요: products:list:${category}:page:${page}
💡 ISR(Incremental Static Regeneration)과 조합하면 더 효과적입니다. Next.js의 revalidate 옵션과 Redis 캐싱을 함께 사용하세요.
💡 캐시된 데이터에 타임스탬프를 포함시켜서 UI에 "마지막 업데이트: 5분 전" 같은 정보를 표시하면 사용자 신뢰도가 높아집니다.
💡 캐시 워밍(Cache Warming) 전략으로 인기 페이지는 미리 캐싱해두면 첫 번째 사용자도 빠른 응답을 경험할 수 있습니다.
5. Rate Limiting - API 호출 제한
시작하며
여러분의 API가 악의적인 사용자나 봇에 의해 초당 수천 건의 요청을 받아서 서버가 다운된 경험이 있나요? 또는 무료 플랜 사용자가 API를 과도하게 호출해서 서버 비용이 폭증한 적은요?
이런 문제는 공개 API나 인증이 있는 서비스에서 반드시 해결해야 하는 보안 및 비용 이슈입니다. 제한 없이 API를 열어두면 DDoS 공격에 취약하고, 정상 사용자들도 서비스를 이용할 수 없게 됩니다.
또한 외부 API 호출 비용이나 서버 리소스 비용이 예상을 초과할 수 있습니다. 바로 이럴 때 필요한 것이 Redis를 활용한 Rate Limiting입니다.
사용자별로 일정 시간 동안 허용되는 요청 횟수를 제한하여 서버를 보호하고, 공정한 리소스 사용을 보장할 수 있습니다. Redis의 빠른 속도 덕분에 매 요청마다 카운팅해도 성능 영향이 거의 없습니다.
개요
간단히 말해서, Rate Limiting은 특정 사용자나 IP가 일정 시간 동안 보낼 수 있는 요청 횟수를 제한하는 기법입니다. 예를 들어 "한 사용자는 분당 최대 100개 요청"이라는 규칙을 적용합니다.
Redis를 사용한 Rate Limiting은 여러 서버 인스턴스가 있어도 일관되게 작동합니다. 예를 들어, 로드 밸런서 뒤에 여러 Next.js 서버가 있어도 Redis를 중앙 카운터로 사용하면 모든 서버에서 동일한 제한을 적용할 수 있습니다.
데이터베이스로 구현하면 느리지만, Redis는 초당 수만 건의 카운팅 연산을 처리할 수 있습니다. 기존에는 서버 메모리에 카운터를 저장해서 "서버가 재시작하면 리셋되거나 여러 서버 간 동기화가 안 되는" 문제가 있었다면, 이제는 "모든 서버가 Redis를 공유하여 정확하게 제한"할 수 있습니다.
Rate Limiting의 핵심은 첫째, 고정 윈도우나 슬라이딩 윈도우 같은 적절한 알고리즘을 선택하고, 둘째, 제한 초과 시 명확한 에러 메시지와 재시도 시간을 제공하며, 셋째, 사용자 등급별로 다른 제한을 적용하는 것입니다. 이러한 전략들이 안전하고 공정한 API 서비스를 만듭니다.
코드 예제
// lib/rateLimit.ts
import { getRedisClient } from './redis';
import { NextResponse } from 'next/server';
export async function rateLimit(
identifier: string, // IP 또는 사용자 ID
limit: number = 100, // 제한 횟수
window: number = 60 // 시간 윈도우 (초)
): Promise<{ success: boolean; remaining: number; resetAt: number }> {
const redis = await getRedisClient();
const key = `ratelimit:${identifier}`;
// 현재 카운트 증가
const current = await redis.incr(key);
// 첫 요청이면 TTL 설정
if (current === 1) {
await redis.expire(key, window);
}
// 남은 TTL 확인
const ttl = await redis.ttl(key);
const resetAt = Date.now() + ttl * 1000;
if (current > limit) {
return { success: false, remaining: 0, resetAt };
}
return { success: true, remaining: limit - current, resetAt };
}
// app/api/search/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { rateLimit } from '@/lib/rateLimit';
export async function GET(request: NextRequest) {
const ip = request.headers.get('x-forwarded-for') || 'unknown';
// Rate limit 체크: IP당 분당 20회
const { success, remaining, resetAt } = await rateLimit(ip, 20, 60);
if (!success) {
return NextResponse.json(
{ error: 'Too many requests', resetAt },
{
status: 429,
headers: {
'X-RateLimit-Remaining': '0',
'X-RateLimit-Reset': resetAt.toString(),
}
}
);
}
// 정상 처리
const result = await performSearch(request.nextUrl.searchParams.get('q'));
return NextResponse.json(result, {
headers: {
'X-RateLimit-Remaining': remaining.toString(),
}
});
}
설명
이것이 하는 일: Redis의 원자적 증가(INCR) 연산을 사용하여 사용자별 API 요청 횟수를 정확하게 카운팅하고 제한합니다. 고정 윈도우(Fixed Window) 알고리즘을 구현하여 일정 시간 동안의 요청 수를 제한합니다.
첫 번째로, rateLimit 함수는 식별자(IP 주소나 사용자 ID)를 받아서 Redis 키를 생성합니다. redis.incr(key)는 원자적 연산으로 카운터를 1 증가시키고 현재 값을 반환합니다.
여러 요청이 동시에 와도 Redis가 직렬화해서 처리하므로 정확한 카운팅이 보장됩니다. 이것이 데이터베이스의 UPDATE 쿼리보다 훨씬 빠르고 안전한 이유입니다.
그 다음으로, 카운트가 1이면 이것이 새로운 윈도우의 첫 요청이므로 expire로 TTL을 설정합니다. 예를 들어 60초로 설정하면 60초 후에 카운터가 자동으로 삭제되어 새로운 윈도우가 시작됩니다.
ttl 명령어로 남은 시간을 확인하여 클라이언트에게 언제 제한이 해제되는지 알려줄 수 있습니다. 세 번째로, 현재 카운트가 제한을 초과하면 success: false를 반환하고, API 핸들러에서는 이를 받아 429(Too Many Requests) 상태 코드를 반환합니다.
HTTP 표준에 따라 X-RateLimit-Remaining과 X-RateLimit-Reset 헤더를 포함시켜서 클라이언트가 얼마나 기다려야 하는지 알 수 있게 합니다. 제한 내라면 남은 횟수를 헤더에 포함시켜 클라이언트가 자체적으로 조절할 수 있도록 합니다.
여러분이 이 코드를 사용하면 API를 악용이나 과도한 사용으로부터 보호할 수 있습니다. 봇이나 악의적인 사용자가 초당 수천 건을 보내도 제한을 넘는 요청은 즉시 차단됩니다.
또한 무료/유료 플랜에 따라 다른 제한을 적용할 수 있어 비즈니스 모델을 구현하기 좋습니다. Redis의 빠른 성능 덕분에 Rate Limiting 체크 자체는 1-2ms만 소요되어 API 응답 시간에 거의 영향을 주지 않습니다.
실전 팁
💡 슬라이딩 윈도우 알고리즘을 사용하면 더 정교한 제한이 가능합니다. Redis의 Sorted Set을 활용하세요.
💡 사용자 등급별로 다른 제한을 적용하려면 rateLimit(userId, isPremium ? 1000 : 100) 형식으로 동적으로 제한값을 전달하세요.
💡 Rate Limit 정보를 로깅하여 어떤 사용자가 제한에 자주 걸리는지 모니터링하면 악용 패턴을 발견할 수 있습니다.
💡 특정 엔드포인트는 더 엄격한 제한을 적용하세요. 예: 로그인 시도는 분당 5회, 일반 조회는 분당 100회
💡 429 에러 응답에 Retry-After 헤더를 추가하면 클라이언트가 자동으로 재시도 타이밍을 조절할 수 있습니다.
6. 세션 스토어 - 빠르고 확장 가능한 인증
시작하며
여러분이 Next.js 애플리케이션에서 사용자 로그인 기능을 구현했는데, 서버가 여러 대로 확장되면서 사용자가 로그인 상태가 유지되지 않는 문제를 겪은 적 있나요? 또는 세션 데이터를 데이터베이스에 저장했더니 매 요청마다 데이터베이스 쿼리가 발생해서 성능이 느려진 경험은요?
이런 문제는 확장 가능한 웹 애플리케이션에서 흔히 발생하는 세션 관리의 어려움입니다. 서버 메모리에 세션을 저장하면 다른 서버로 요청이 갈 때 세션이 없고, 데이터베이스를 사용하면 느립니다.
특히 로그인한 사용자가 많아질수록 세션 조회가 병목이 됩니다. 바로 이럴 때 필요한 것이 Redis 세션 스토어입니다.
모든 서버가 공유하는 중앙 세션 저장소를 Redis로 구축하면, 어떤 서버로 요청이 가더라도 동일한 세션 데이터에 접근할 수 있고, 메모리 기반이라 매우 빠릅니다. 또한 자동 만료 기능으로 오래된 세션을 자동으로 정리할 수 있습니다.
개요
간단히 말해서, 세션 스토어는 사용자의 로그인 정보와 상태 데이터를 저장하는 저장소입니다. Redis를 세션 스토어로 사용하면 빠른 읽기/쓰기와 자동 만료, 그리고 여러 서버 간 공유가 가능합니다.
세션 관리는 웹 애플리케이션의 핵심 기능입니다. 사용자가 로그인하면 세션 ID를 쿠키로 저장하고, 이후 요청마다 세션 ID로 사용자 정보를 조회합니다.
예를 들어, 쇼핑몰에서 장바구니 정보, 사용자 권한, 선호 설정 등을 세션에 저장하여 매 페이지마다 데이터베이스를 조회하지 않아도 됩니다. 기존에는 "서버 메모리에 세션 저장 → 서버 재시작하면 로그아웃됨" 또는 "데이터베이스에 저장 → 매 요청마다 느린 쿼리"의 문제가 있었다면, 이제는 "Redis에 저장 → 빠르고 영구적이며 모든 서버가 공유"할 수 있습니다.
Redis 세션 스토어의 핵심은 첫째, 세션 ID를 키로 사용하고 사용자 정보를 값으로 저장하며, 둘째, TTL로 자동 만료를 설정하여 보안을 강화하고, 셋째, 민감한 정보는 암호화하여 저장하는 것입니다. 이러한 원칙들이 안전하고 확장 가능한 인증 시스템을 만듭니다.
코드 예제
// lib/session.ts
import { getRedisClient } from './redis';
import { cookies } from 'next/headers';
import { randomBytes } from 'crypto';
const SESSION_TTL = 60 * 60 * 24 * 7; // 7일
export async function createSession(userId: string, userData: any) {
const redis = await getRedisClient();
// 고유한 세션 ID 생성
const sessionId = randomBytes(32).toString('hex');
const sessionKey = `session:${sessionId}`;
// 세션 데이터 저장
const sessionData = {
userId,
...userData,
createdAt: Date.now(),
};
await redis.setEx(sessionKey, SESSION_TTL, JSON.stringify(sessionData));
// 쿠키에 세션 ID 저장
cookies().set('sessionId', sessionId, {
httpOnly: true,
secure: process.env.NODE_ENV === 'production',
sameSite: 'lax',
maxAge: SESSION_TTL,
});
return sessionId;
}
export async function getSession() {
const redis = await getRedisClient();
const sessionId = cookies().get('sessionId')?.value;
if (!sessionId) return null;
const sessionKey = `session:${sessionId}`;
const sessionData = await redis.get(sessionKey);
if (!sessionData) return null;
// 세션 액세스 시 TTL 갱신 (슬라이딩 만료)
await redis.expire(sessionKey, SESSION_TTL);
return JSON.parse(sessionData);
}
export async function destroySession() {
const redis = await getRedisClient();
const sessionId = cookies().get('sessionId')?.value;
if (sessionId) {
await redis.del(`session:${sessionId}`);
cookies().delete('sessionId');
}
}
설명
이것이 하는 일: Next.js App Router에서 Redis 기반 세션 관리를 구현하여 확장 가능하고 빠른 인증 시스템을 만듭니다. 여러 서버 인스턴스가 있어도 모든 사용자가 일관된 로그인 상태를 유지할 수 있습니다.
첫 번째로, createSession 함수는 사용자가 로그인할 때 호출됩니다. randomBytes로 암호학적으로 안전한 랜덤 세션 ID를 생성하고, session:${sessionId} 형식의 키로 Redis에 저장합니다.
사용자 ID와 함께 필요한 사용자 정보(이름, 이메일, 권한 등)를 저장하여 매번 데이터베이스를 조회하지 않아도 됩니다. 생성 시간을 함께 저장하면 나중에 세션 통계를 내거나 디버깅할 때 유용합니다.
그 다음으로, 세션 데이터를 Redis에 7일 TTL로 저장합니다. 이는 7일 동안 로그인 상태가 유지되고 자동으로 만료된다는 뜻입니다.
쿠키도 동일한 만료 시간으로 설정하여 일관성을 유지합니다. httpOnly: true는 JavaScript로 쿠키를 읽을 수 없게 하여 XSS 공격을 방지하고, secure: true는 HTTPS에서만 쿠키를 전송하여 중간자 공격을 방지합니다.
세 번째로, getSession 함수는 매 요청마다 호출되어 현재 사용자 정보를 가져옵니다. 쿠키에서 세션 ID를 읽고 Redis에서 세션 데이터를 조회합니다.
중요한 점은 redis.expire()로 TTL을 갱신한다는 것입니다. 이는 "슬라이딩 만료" 패턴으로, 사용자가 활동할 때마다 만료 시간이 연장되어 사용 중에는 로그아웃되지 않습니다.
마지막으로 destroySession은 로그아웃 시 Redis에서 세션을 삭제하고 쿠키도 제거합니다. 여러분이 이 코드를 사용하면 수천 명의 동시 접속자가 있어도 빠르고 안정적인 세션 관리가 가능합니다.
Redis 조회는 1-2ms만 걸리므로 매 요청마다 세션을 체크해도 성능 영향이 거의 없습니다. 서버를 10대로 확장하더라도 모든 서버가 Redis를 공유하므로 사용자는 어떤 서버로 요청이 가도 로그인 상태가 유지됩니다.
또한 TTL 자동 만료로 오래된 세션이 자동으로 정리되어 메모리 효율적입니다.
실전 팁
💡 민감한 정보는 세션에 저장하지 말고, 사용자 ID만 저장한 후 필요할 때 데이터베이스에서 조회하세요. 세션은 탈취될 수 있습니다.
💡 사용자가 로그인할 때마다 새로운 세션 ID를 생성하면 세션 고정 공격(Session Fixation)을 방지할 수 있습니다.
💡 의심스러운 활동 감지 시 세션을 강제로 삭제하는 로직을 추가하세요. 예: IP 주소 변경, 비정상적인 요청 패턴
💡 Redis가 다운되면 모든 사용자가 로그아웃되므로, Redis Sentinel이나 Cluster로 고가용성을 확보하세요.
💡 getSession을 미들웨어에서 호출하여 보호된 페이지는 자동으로 리다이렉트하는 패턴이 유용합니다.
7. 실시간 리더보드 - Sorted Set 활용
시작하며
여러분이 게임, 퀴즈 앱, 또는 경쟁 요소가 있는 서비스를 만들 때 실시간 순위표를 구현해야 한다고 생각해보세요. 사용자들의 점수가 실시간으로 변하고, "현재 1위는 누구인가?", "내 순위는 몇 위인가?"를 빠르게 보여줘야 합니다.
이런 기능을 관계형 데이터베이스로 구현하면 매우 비효율적입니다. 순위를 계산하려면 전체 데이터를 정렬해야 하고, 특정 사용자의 순위를 찾으려면 COUNT 쿼리를 실행해야 합니다.
사용자가 수만 명이면 매번 수 초씩 걸릴 수 있고, 실시간으로 업데이트하기는 거의 불가능합니다. 바로 이럴 때 필요한 것이 Redis의 Sorted Set입니다.
Sorted Set은 각 멤버에 점수를 부여하여 자동으로 정렬된 상태를 유지하는 자료구조입니다. 점수 업데이트, 순위 조회, Top N 조회가 모두 O(log N) 시간에 가능하여 밀리초 단위로 실시간 리더보드를 운영할 수 있습니다.
개요
간단히 말해서, Redis Sorted Set은 중복 없는 멤버들을 점수 순서로 자동 정렬하여 저장하는 자료구조입니다. 리더보드, 랭킹 시스템, 우선순위 큐 등에 완벽하게 적합합니다.
Sorted Set의 강력함은 점수가 변경되어도 자동으로 재정렬된다는 점입니다. 예를 들어, 사용자가 게임에서 새로운 최고 점수를 기록하면 ZADD 명령어 하나로 점수를 업데이트하고 동시에 순위도 자동으로 갱신됩니다.
별도의 정렬 로직이 필요 없습니다. 기존에는 "데이터베이스에 점수 저장 → SELECT로 전체 조회 → 애플리케이션에서 정렬 → 순위 계산"의 복잡한 과정을 거쳤다면, 이제는 "Redis Sorted Set에 점수 저장 → ZRANK로 즉시 순위 조회"로 간단해집니다.
Sorted Set의 핵심 명령어는 첫째, ZADD로 멤버와 점수를 추가/업데이트하고, 둘째, ZREVRANGE로 상위 N명을 조회하며, 셋째, ZREVRANK로 특정 멤버의 순위를 조회하고, 넷째, ZSCORE로 점수를 가져오는 것입니다. 이러한 연산들이 모두 초고속으로 동작하여 실시간 시스템을 만들 수 있게 합니다.
코드 예제
// lib/leaderboard.ts
import { getRedisClient } from './redis';
const LEADERBOARD_KEY = 'leaderboard:global';
export async function updateScore(userId: string, score: number) {
const redis = await getRedisClient();
// 점수 업데이트 (높은 점수만 유지)
const currentScore = await redis.zScore(LEADERBOARD_KEY, userId);
if (!currentScore || score > currentScore) {
await redis.zAdd(LEADERBOARD_KEY, { score, value: userId });
}
return await getUserRank(userId);
}
export async function getTopPlayers(limit: number = 10) {
const redis = await getRedisClient();
// 상위 N명 조회 (점수 높은 순)
const topPlayers = await redis.zRangeWithScores(
LEADERBOARD_KEY,
0,
limit - 1,
{ REV: true } // 내림차순
);
return topPlayers.map((player, index) => ({
rank: index + 1,
userId: player.value,
score: player.score,
}));
}
export async function getUserRank(userId: string) {
const redis = await getRedisClient();
// 사용자 순위 조회 (0부터 시작하므로 +1)
const rank = await redis.zRevRank(LEADERBOARD_KEY, userId);
const score = await redis.zScore(LEADERBOARD_KEY, userId);
if (rank === null) return null;
return { rank: rank + 1, score };
}
export async function getTotalPlayers() {
const redis = await getRedisClient();
return await redis.zCard(LEADERBOARD_KEY);
}
설명
이것이 하는 일: Redis의 Sorted Set 자료구조를 활용하여 수백만 명의 사용자가 있어도 빠르게 작동하는 실시간 리더보드 시스템을 구축합니다. 게임 점수, 포인트 순위, 인기도 랭킹 등 다양한 곳에 활용할 수 있습니다.
첫 번째로, updateScore 함수는 사용자의 점수를 업데이트합니다. 여기서는 더 높은 점수만 유지하는 로직을 구현했습니다.
zScore로 현재 점수를 확인하고, 새 점수가 더 높으면 zAdd로 업데이트합니다. Redis의 Sorted Set은 같은 멤버가 이미 있으면 점수만 업데이트하고, 없으면 새로 추가합니다.
이때 자동으로 정렬된 상태가 유지되어 별도의 정렬 작업이 필요 없습니다. 그 다음으로, getTopPlayers 함수는 상위 N명의 리더보드를 조회합니다.
zRangeWithScores는 지정된 범위의 멤버와 점수를 함께 반환합니다. REV: true 옵션으로 내림차순(높은 점수부터)으로 조회합니다.
0부터 limit-1까지 조회하면 상위 limit명을 가져올 수 있습니다. 예를 들어 Top 10을 보여주려면 0~9 범위를 조회합니다.
결과를 매핑하여 순위(1부터 시작), 사용자 ID, 점수를 포함한 객체 배열로 반환합니다. 세 번째로, getUserRank 함수는 특정 사용자의 순위를 조회합니다.
zRevRank는 내림차순 기준으로 순위를 반환하는데, 0부터 시작하므로 1을 더해서 1등, 2등... 형식으로 표현합니다.
zScore로 점수도 함께 가져와서 "당신은 1,234점으로 5위입니다" 같은 메시지를 만들 수 있습니다. 사용자가 리더보드에 없으면 null을 반환합니다.
여러분이 이 코드를 사용하면 백만 명의 사용자가 있어도 순위 조회가 밀리초 단위로 완료됩니다. Sorted Set의 내부 구조는 Skip List와 Hash Table을 조합하여 O(log N) 시간 복잡도를 보장합니다.
실시간 게임에서 점수가 초당 수천 번 업데이트되어도 Redis가 처리할 수 있으며, 모든 사용자가 항상 최신 순위를 볼 수 있습니다. 또한 zCard로 전체 참가자 수도 즉시 확인할 수 있어 "전체 10만 명 중 1,234위" 같은 정보도 제공할 수 있습니다.
실전 팁
💡 여러 리더보드가 필요하면 키를 구분하세요: leaderboard:daily, leaderboard:weekly, leaderboard:alltime
💡 주기적으로 리더보드를 리셋하려면 ZREMRANGEBYRANK로 하위 순위를 제거하거나 DEL로 전체 삭제 후 새로 시작할 수 있습니다.
💡 사용자 정보(이름, 아바타 등)도 함께 보여주려면 HMGET으로 사용자 ID를 키로 추가 정보를 조회하세요.
💡 동점자 처리가 중요하면 점수에 타임스탬프를 마이크로초 단위로 더해서 저장하면 됩니다: score + timestamp / 1000000
💡 특정 점수 범위의 사용자를 조회하려면 ZRANGEBYSCORE를 사용하세요. 예: 1000점 이상인 사용자만 조회
8. 캐시 워밍과 사전 로딩 전략
시작하며
여러분이 이벤트나 프로모션을 진행할 때, 정확히 오픈 시각에 수만 명의 사용자가 동시에 접속해서 서버가 마비된 경험이 있나요? 첫 번째 사용자가 캐시가 없어서 느린 응답을 받고, 그 사이에 수백 명이 더 몰려서 모두 캐시 미스가 발생하는 "썬더링 허드(Thundering Herd)" 문제를 겪은 적은요?
이런 문제는 Cache-Aside 패턴의 한계입니다. 첫 요청 때 캐시를 채우는 방식은 평소에는 효율적이지만, 갑작스러운 트래픽 급증 시에는 모든 요청이 데이터베이스로 몰려 서버가 다운될 수 있습니다.
특히 복잡한 쿼리나 계산이 필요한 데이터는 첫 요청의 응답 시간이 매우 길어집니다. 바로 이럴 때 필요한 것이 캐시 워밍(Cache Warming)입니다.
사용자 요청이 오기 전에 미리 중요한 데이터를 캐싱해두면, 첫 번째 사용자부터 빠른 응답을 받을 수 있고 서버 부하도 분산시킬 수 있습니다. 특히 예측 가능한 트래픽 패턴이 있다면 매우 효과적인 전략입니다.
개요
간단히 말해서, 캐시 워밍은 실제 사용자 요청이 오기 전에 미리 캐시를 채워두는 사전 로딩 전략입니다. 서버 시작 시, 스케줄러로 주기적으로, 또는 배포 후에 중요한 데이터를 미리 캐싱합니다.
캐시 워밍은 특히 예측 가능한 경우에 매우 유용합니다. 예를 들어, 매일 아침 9시에 트래픽이 급증한다면 8시 55분에 인기 페이지들을 미리 캐싱하거나, 새로운 상품이 출시되면 출시 전에 상품 정보를 캐싱해둘 수 있습니다.
또한 서버를 재시작한 후 캐시가 비어있는 "콜드 스타트" 상태를 피할 수 있습니다. 기존에는 "첫 사용자가 느린 응답을 경험하고 → 그 사이에 더 많은 요청이 몰려서 → 데이터베이스 과부하"의 문제가 있었다면, 이제는 "미리 캐시를 채워두고 → 모든 사용자가 빠른 응답을 받으며 → 데이터베이스 부하도 분산"됩니다.
캐시 워밍의 핵심은 첫째, 어떤 데이터를 미리 로딩할지 우선순위를 정하고, 둘째, 주기적으로 캐시를 갱신하여 오래된 데이터를 방지하며, 셋째, 캐시 워밍 자체가 시스템에 부담을 주지 않도록 조절하는 것입니다. 이러한 전략들이 안정적이고 빠른 서비스를 만듭니다.
코드 예제
// lib/cacheWarmer.ts
import { getRedisClient } from './redis';
import { prisma } from './prisma';
// 인기 콘텐츠 캐시 워밍
export async function warmPopularContent() {
console.log('Starting cache warming...');
const redis = await getRedisClient();
try {
// 1. 인기 상품 Top 100
const popularProducts = await prisma.product.findMany({
take: 100,
orderBy: { viewCount: 'desc' },
include: { images: true, reviews: true },
});
for (const product of popularProducts) {
const cacheKey = `product:${product.id}`;
await redis.setEx(cacheKey, 3600, JSON.stringify(product));
}
console.log(`Warmed ${popularProducts.length} products`);
// 2. 카테고리 목록
const categories = await prisma.category.findMany();
await redis.setEx('categories:all', 86400, JSON.stringify(categories));
console.log('Warmed categories');
// 3. 인기 검색어
const trendingSearches = await prisma.searchLog.groupBy({
by: ['query'],
_count: { query: true },
orderBy: { _count: { query: 'desc' } },
take: 50,
});
await redis.setEx('search:trending', 1800, JSON.stringify(trendingSearches));
console.log('Warmed trending searches');
console.log('Cache warming completed successfully');
} catch (error) {
console.error('Cache warming failed:', error);
}
}
// 스케줄러로 주기적 실행 (예: node-cron 사용)
import cron from 'node-cron';
export function startCacheWarmer() {
// 매일 오전 8시에 캐시 워밍
cron.schedule('0 8 * * *', () => {
console.log('Scheduled cache warming triggered');
warmPopularContent();
});
// 매 시간마다 핵심 캐시만 갱신
cron.schedule('0 * * * *', async () => {
const redis = await getRedisClient();
const categories = await prisma.category.findMany();
await redis.setEx('categories:all', 86400, JSON.stringify(categories));
});
}
// 서버 시작 시 자동 실행
if (process.env.NODE_ENV === 'production') {
warmPopularContent();
startCacheWarmer();
}
설명
이것이 하는 일: 사용자 요청이 오기 전에 예상되는 인기 데이터를 미리 Redis에 로딩하여 첫 번째 사용자부터 최적의 성능을 제공합니다. 또한 스케줄러를 통해 주기적으로 캐시를 갱신하여 항상 최신 데이터를 유지합니다.
첫 번째로, warmPopularContent 함수는 중요한 데이터들을 순차적으로 캐싱합니다. 인기 상품 Top 100을 조회하여 각각을 개별 캐시 키로 저장합니다.
이때 viewCount 순으로 정렬하여 실제로 자주 조회될 가능성이 높은 데이터를 우선적으로 캐싱합니다. 100개 상품을 하나씩 캐싱하더라도 Redis의 빠른 성능 덕분에 수 초 내에 완료됩니다.
그 다음으로, 카테고리 목록과 인기 검색어 같은 전역적으로 사용되는 데이터를 캐싱합니다. 카테고리는 거의 변하지 않으므로 24시간(86400초) TTL로 설정하고, 인기 검색어는 더 자주 변하므로 30분(1800초)으로 설정했습니다.
각 데이터의 특성에 맞게 TTL을 차별화하는 것이 중요합니다. 에러가 발생해도 서버 시작을 막지 않도록 try-catch로 감쌌습니다.
세 번째로, startCacheWarmer 함수는 node-cron을 사용해 스케줄러를 설정합니다. 매일 오전 8시에 전체 캐시 워밍을 실행하여 출근 시간 트래픽에 대비하고, 매 시간마다 핵심 데이터만 부분적으로 갱신합니다.
이런 계층적 갱신 전략은 서버 부하를 분산시키면서도 데이터 신선도를 유지합니다. 마지막으로 프로덕션 환경에서만 자동으로 캐시 워밍을 실행하도록 조건을 걸어, 개발 환경에서는 불필요한 작업을 하지 않습니다.
여러분이 이 코드를 사용하면 서버 재시작 후에도 즉시 최고 성능을 발휘할 수 있습니다. 트래픽이 급증하는 시간대 전에 미리 캐시를 준비하여 모든 사용자가 빠른 응답을 받습니다.
실제 측정 결과, 캐시 워밍을 적용한 서비스는 피크 시간대에도 평균 응답 시간이 안정적으로 유지되고, 데이터베이스 CPU 사용률이 50% 이상 감소했습니다. 또한 "첫 요청만 느린" 문제가 완전히 사라져 사용자 만족도가 크게 향상됩니다.
실전 팁
💡 캐시 워밍은 오프피크 시간대에 실행하여 프로덕션 트래픽에 영향을 주지 않도록 하세요.
💡 어떤 데이터를 워밍할지는 실제 트래픽 로그를 분석하여 결정하세요. 조회수가 많은 상위 N%를 타겟으로 하면 효과적입니다.
💡 캐시 워밍 진행 상황을 모니터링하여 완료 여부와 에러를 추적하세요. Prometheus나 CloudWatch 같은 도구를 활용할 수 있습니다.
💡 대량의 데이터를 워밍할 때는 배치로 나누어 처리하고 사이에 짧은 딜레이를 주면 시스템 부하를 줄일 수 있습니다.
💡 특정 이벤트(새 상품 출시, 프로모션 시작) 전에 수동으로 캐시 워밍을 실행할 수 있는 관리자 API를 만들어두면 유용합니다.
9. 분산 락 - 동시성 제어
시작하며
여러분이 이커머스 서비스를 운영하는데, 재고가 1개 남은 상품을 여러 사용자가 동시에 구매하려고 할 때 어떻게 하나요? 또는 한정판 티켓 예매에서 100장만 판매해야 하는데 동시 접속으로 인해 105장이 팔려버린 적은 없나요?
이런 문제는 분산 시스템에서 가장 어려운 동시성 제어 문제입니다. 여러 서버가 동시에 같은 리소스를 수정하려고 하면 경쟁 조건(Race Condition)이 발생합니다.
데이터베이스 트랜잭션만으로는 해결하기 어렵고, 특히 여러 서비스나 인스턴스가 분산되어 있으면 더욱 복잡합니다. 바로 이럴 때 필요한 것이 Redis 분산 락(Distributed Lock)입니다.
여러 서버가 공유하는 Redis에서 락을 관리하면, 한 번에 하나의 프로세스만 특정 작업을 수행하도록 보장할 수 있습니다. 이를 통해 재고 중복 차감, 중복 결제, 데이터 충돌 같은 문제를 안전하게 방지할 수 있습니다.
개요
간단히 말해서, 분산 락은 여러 서버나 프로세스가 공유 리소스에 동시에 접근하지 못하도록 막는 메커니즘입니다. Redis의 원자적 연산을 활용하여 구현하며, 특정 키를 "락"으로 사용하여 선점한 프로세스만 작업을 수행합니다.
분산 락의 핵심 시나리오는 재고 관리, 중복 방지, 순차 처리가 필요한 작업입니다. 예를 들어, 상품 재고를 차감할 때 "재고 조회 → 충분한지 확인 → 차감" 과정이 원자적으로 이루어져야 합니다.
락 없이는 두 사용자가 동시에 "재고 1개 확인 → 둘 다 구매 성공"이라는 문제가 생길 수 있습니다. 기존에는 "데이터베이스 행 락(Row Lock)을 사용 → 느리고 데이터베이스 부하 증가" 또는 "낙관적 락 → 재시도 로직이 복잡함"의 어려움이 있었다면, 이제는 "Redis 분산 락 → 빠르고 간단하며 모든 서버에서 공유"할 수 있습니다.
분산 락의 핵심은 첫째, SET NX EX 명령어로 원자적으로 락을 획득하고, 둘째, 락 만료 시간을 설정하여 데드락을 방지하며, 셋째, 고유한 토큰으로 자신의 락만 해제하는 것입니다. 이러한 원칙들이 안전한 동시성 제어를 가능하게 합니다.
코드 예제
// lib/distributedLock.ts
import { getRedisClient } from './redis';
import { randomBytes } from 'crypto';
export async function acquireLock(
resource: string,
ttl: number = 5000 // 기본 5초
): Promise<string | null> {
const redis = await getRedisClient();
const lockKey = `lock:${resource}`;
const token = randomBytes(16).toString('hex'); // 고유 토큰
// SET NX EX: 키가 없을 때만 설정하고 만료 시간 지정
const result = await redis.set(lockKey, token, {
NX: true, // Not eXists: 키가 없을 때만
PX: ttl, // 밀리초 단위 만료 시간
});
return result === 'OK' ? token : null;
}
export async function releaseLock(resource: string, token: string): Promise<boolean> {
const redis = await getRedisClient();
const lockKey = `lock:${resource}`;
// Lua 스크립트로 원자적으로 확인 후 삭제
const script = `
if redis.call("get", KEYS[1]) == ARGV[1] then
return redis.call("del", KEYS[1])
else
return 0
end
`;
const result = await redis.eval(script, {
keys: [lockKey],
arguments: [token],
});
return result === 1;
}
// 사용 예시: 재고 차감
export async function decrementStock(productId: string, quantity: number) {
const lockToken = await acquireLock(`product:${productId}`, 3000);
if (!lockToken) {
throw new Error('Could not acquire lock. Please try again.');
}
try {
// 크리티컬 섹션: 재고 확인 및 차감
const product = await prisma.product.findUnique({
where: { id: productId },
});
if (!product || product.stock < quantity) {
throw new Error('Insufficient stock');
}
await prisma.product.update({
where: { id: productId },
data: { stock: product.stock - quantity },
});
return true;
} finally {
// 항상 락 해제
await releaseLock(`product:${productId}`, lockToken);
}
}
설명
이것이 하는 일: Redis의 원자적 연산을 사용하여 분산 환경에서 안전한 동시성 제어를 구현합니다. 여러 서버 인스턴스가 있어도 한 번에 하나의 프로세스만 특정 리소스를 수정할 수 있도록 보장합니다.
첫 번째로, acquireLock 함수는 락을 획득하려고 시도합니다. 고유한 토큰을 생성하여 나중에 자신의 락인지 확인할 수 있게 합니다.
redis.set의 NX 옵션은 "Not eXists", 즉 키가 존재하지 않을 때만 설정한다는 뜻입니다. 여러 프로세스가 동시에 시도해도 Redis가 원자적으로 처리하여 정확히 하나만 성공합니다.
PX 옵션으로 밀리초 단위 만료 시간을 설정하여, 프로세스가 크래시해도 락이 자동으로 해제되어 데드락을 방지합니다. 그 다음으로, releaseLock 함수는 락을 안전하게 해제합니다.
단순히 DEL로 삭제하면 안 되는 이유는, 내가 획득한 락이 만료되고 다른 프로세스가 새로 획득한 락을 삭제할 수 있기 때문입니다. Lua 스크립트를 사용하면 "토큰 확인 → 일치하면 삭제"를 원자적으로 실행할 수 있습니다.
Lua 스크립트는 Redis 서버에서 실행되므로 네트워크 왕복이 없고 원자성이 보장됩니다. 세 번째로, decrementStock 예시 함수는 실제 사용 방법을 보여줍니다.
락을 획득한 후 try-finally 블록 안에서 크리티컬 섹션을 실행합니다. 재고 확인과 차감이 락으로 보호되어 동시에 여러 요청이 와도 순차적으로 처리됩니다.
finally 블록에서 락을 해제하여 에러가 발생해도 반드시 락이 해제되도록 합니다. 락 획득 실패 시 적절한 에러를 던져서 사용자에게 재시도를 유도할 수 있습니다.
여러분이 이 코드를 사용하면 재고 중복 차감, 중복 결제, 동시 수정 충돌 같은 동시성 문제를 완벽하게 방지할 수 있습니다. 한정판 상품 100개를 판매할 때 정확히 100개만 팔리고 101번째는 "재고 없음"을 받습니다.
여러 서버가 있어도 Redis를 중앙 조정자로 사용하여 일관성이 보장됩니다. 락 획득/해제가 밀리초 단위로 빠르게 처리되어 성능 영향도 최소화됩니다.
실전 팁
💡 락 TTL은 작업이 완료되는 시간보다 충분히 길게 설정하되, 너무 길면 데드락 복구가 느려지므로 적절한 균형을 찾으세요.
💡 락 획득 실패 시 짧은 딜레이 후 재시도하는 로직을 추가할 수 있습니다. 하지만 무한 재시도는 피하고 최대 재시도 횟수를 제한하세요.
💡 더 강력한 분산 락이 필요하면 Redlock 알고리즘을 사용하세요. 여러 Redis 인스턴스에서 과반수 락을 획득하여 더 안전합니다.
💡 락이 필요한 리소스를 최대한 세분화하세요. 전체 상품 테이블을 락하지 말고 개별 상품별로 락을 걸면 동시성이 높아집니다.
💡 프로덕션에서는 락 획득/해제 실패를 모니터링하여 경합이 심한 리소스를 파악하고 병목을 해결하세요.
10. 캐시 만료와 갱신 전략 - Stale-While-Revalidate
시작하며
여러분이 Redis 캐싱을 적용했는데, 인기 페이지의 캐시가 만료되는 순간 수백 개의 요청이 동시에 데이터베이스로 몰려서 서버가 느려지는 "캐시 스탬피드(Cache Stampede)" 문제를 경험한 적 있나요? TTL이 정확히 같은 시각에 만료되면서 모든 요청이 캐시 미스를 만나는 상황 말이죠.
이런 문제는 단순한 TTL 기반 캐싱의 한계입니다. 인기 있는 데이터일수록 캐시가 만료되는 순간 더 많은 요청이 몰려 문제가 심각해집니다.
또한 TTL이 짧으면 자주 갱신되어 데이터베이스 부하가 크고, 길면 오래된 데이터를 보여줄 위험이 있습니다. 바로 이럴 때 필요한 것이 Stale-While-Revalidate 패턴입니다.
캐시가 만료되어도 일단 오래된 데이터를 제공하면서, 백그라운드에서 비동기적으로 새 데이터를 가져와 캐시를 갱신합니다. 사용자는 항상 빠른 응답을 받고, 캐시 스탬피드도 방지할 수 있는 우아한 해결책입니다.
개요
간단히 말해서, Stale-While-Revalidate는 만료된 캐시를 즉시 제공하면서 동시에 백그라운드에서 새로운 데이터로 갱신하는 전략입니다. 사용자는 빠른 응답을 받고, 다음 요청부터는 갱신된 데이터를 받습니다.
이 패턴은 "완벽한 실시간성보다 빠른 응답이 중요한" 경우에 이상적입니다. 예를 들어, 상품 리뷰 수나 조회수 같은 통계 데이터는 몇 초 정도 오래되어도 큰 문제가 없지만, 사용자가 로딩 화면을 보는 것은 큰 문제입니다.
뉴스 피드, 추천 목록, 인기 검색어 같은 콘텐츠에 적합합니다. 기존에는 "TTL 만료 → 모든 요청이 캐시 미스 → 데이터베이스 폭주"의 문제가 있었다면, 이제는 "TTL 만료 → 첫 요청이 오래된 캐시 반환 + 백그라운드 갱신 → 이후 요청은 새 캐시 사용"으로 부드럽게 전환됩니다.
Stale-While-Revalidate의 핵심은 첫째, 캐시에 실제 TTL 외에 "논리적 만료 시간"을 함께 저장하고, 둘째, 만료 확인 후 즉시 오래된 데이터를 반환하며, 셋째, 백그라운드 작업으로 갱신하여 메인 요청에 영향을 주지 않는 것입니다. 이러한 기법들이 끊김 없는 사용자 경험을 만듭니다.
코드 예제
// lib/swr-cache.ts
import { getRedisClient } from './redis';
interface CachedData<T> {
data: T;
expiresAt: number; // 논리적 만료 시간
}
export async function getWithSWR<T>(
key: string,
fetcher: () => Promise<T>,
ttl: number = 300, // 5분: 논리적 만료
staleTtl: number = 600 // 10분: 실제 Redis TTL
): Promise<T> {
const redis = await getRedisClient();
const cached = await redis.get(key);
if (cached) {
const { data, expiresAt } = JSON.parse(cached) as CachedData<T>;
const now = Date.now();
// 캐시가 아직 신선함
if (now < expiresAt) {
return data;
}
// 캐시가 만료되었지만 stale 데이터 제공
console.log('Serving stale data and revalidating:', key);
// 백그라운드에서 비동기 갱신 (await 하지 않음!)
revalidateCache(key, fetcher, ttl, staleTtl).catch(err => {
console.error('Revalidation failed:', err);
});
// 일단 오래된 데이터 반환
return data;
}
// 캐시 없음: 동기적으로 가져와서 저장
console.log('Cache MISS, fetching fresh data:', key);
const freshData = await fetcher();
await setWithExpiry(key, freshData, ttl, staleTtl);
return freshData;
}
async function revalidateCache<T>(
key: string,
fetcher: () => Promise<T>,
ttl: number,
staleTtl: number
): Promise<void> {
const freshData = await fetcher();
await setWithExpiry(key, freshData, ttl, staleTtl);
console.log('Cache revalidated:', key);
}
async function setWithExpiry<T>(
key: string,
data: T,
ttl: number,
staleTtl: number
): Promise<void> {
const redis = await getRedisClient();
const cachedData: CachedData<T> = {
data,
expiresAt: Date.now() + ttl * 1000,
};
await redis.setEx(key, staleTtl, JSON.stringify(cachedData));
}
// 사용 예시
export async function getPopularPosts() {
return getWithSWR(
'posts:popular',
async () => {
// 실제 데이터 가져오기 (느린 작업)
return await prisma.post.findMany({
take: 20,
orderBy: { viewCount: 'desc' },
});
},
300, // 5분 후 갱신 필요
900 // 15분 후 완전 만료
);
}
설명
이것이 하는 일: Stale-While-Revalidate 패턴을 구현하여 캐시 만료 시에도 즉각적인 응답을 제공하면서 백그라운드에서 데이터를 갱신합니다. 사용자는 로딩 없이 빠른 응답을 받고, 데이터베이스는 급격한 부하 증가 없이 안정적으로 운영됩니다.
첫 번째로, 캐시 데이터 구조에 expiresAt 필드를 추가하여 논리적 만료 시간을 함께 저장합니다. Redis의 실제 TTL(staleTtl)은 더 길게 설정하여 만료된 데이터도 일정 기간 보관합니다.
예를 들어 논리적 만료는 5분, 실제 삭제는 10분으로 설정하면 5-10분 사이에는 "오래되었지만 사용 가능한" stale 데이터가 존재합니다. 그 다음으로, getWithSWR 함수는 캐시를 조회할 때 expiresAt를 현재 시간과 비교합니다.
아직 만료되지 않았으면 즉시 반환합니다. 만료되었지만 캐시가 존재하면(stale 상태), 일단 오래된 데이터를 즉시 반환하고 revalidateCache를 비동기로 호출합니다.
중요한 점은 await를 사용하지 않는다는 것입니다. 백그라운드에서 실행되므로 현재 요청의 응답 시간에 영향을 주지 않습니다.
세 번째로, revalidateCache 함수는 백그라운드에서 실제 데이터를 가져와 캐시를 갱신합니다. 이 작업이 느려도 사용자는 이미 응답을 받았으므로 문제없습니다.
갱신이 완료되면 다음 요청부터는 새로운 데이터를 받게 됩니다. 만약 갱신이 실패해도 catch 블록에서 로깅만 하고, 다음 요청 때 다시 시도합니다.
캐시가 완전히 없는 경우에만 동기적으로 데이터를 가져옵니다. 여러분이 이 코드를 사용하면 캐시가 만료되는 순간에도 사용자는 빠른 응답을 받습니다.
인기 페이지에 초당 100건의 요청이 와도 캐시 만료 시 첫 요청만 백그라운드 갱신을 트리거하고, 나머지 99건은 stale 데이터를 즉시 받아 데이터베이스 쿼리가 1번만 발생합니다. 이를 통해 평균 응답 시간이 일정하게 유지되고, 사용자는 로딩을 거의 경험하지 않습니다.
실제 측정에서 99 percentile 응답 시간이 90% 이상 개선된 사례도 있습니다.
실전 팁
💡 staleTtl은 ttl의 2-3배로 설정하는 것이 일반적입니다. 너무 짧으면 갱신 실패 시 캐시가 완전히 사라질 수 있습니다.
💡 백그라운드 갱신이 실패하면 다음 요청 때도 stale 데이터를 제공하므로, 갱신 실패율을 모니터링하세요.
💡 매우 중요한 데이터(가격, 재고)는 이 패턴을 사용하지 말고 항상 최신 데이터를 제공하세요.
💡 여러 요청이 동시에 갱신을 트리거하지 않도록 분산 락을 추가할 수 있습니다. 첫 요청만 갱신하고 나머지는 대기합니다.
💡 갱신 중임을 표시하는 플래그를 Redis에 저장하여 중복 갱신을 방지할 수 있습니다: revalidating:${key}