예매 시스템으로 배우는 실전 Redis
1.[설계] 예매 시스템에 왜 Redis가 필요할까?
이번 프로젝트는 Redis를 단순한 캐시 도구로 넘어서, 분산 환경에서의 시스템 안정성과 성능을 지탱하는 핵심 인프라로서 어떻게 활용할 수 있는지 체득하기 위한 실험이었다.나는 항해99에서 진행된 Redis 중심의 단기 실습 프로그램에 참여했다. 이 프로그램에서는 Re
2.[설계] 헥사고날 아키텍처 구조 설계
이 프로젝트는 단순한 기능 구현 실습이 아니라, Redis를 활용한 성능 최적화, 분산 락, 요청 제한, 3단 캐시 계층 등 다양한 기술 정책을 설계하고 실험하는 것이 목적이었다. 하지만 기술 정책은 언제나 도메인 로직을 침범할 위험을 동반한다. 예를 들어, 캐시나 락
3.[설계] Redis 실험에 집중하기 위한 멀티 모듈 구조
이 프로젝트는 어디까지나 Redis의 실전 활용 방식을 실험하기 위한 목적에서 출발했다.분산 락을 적용해 중복 좌석 예약을 막고, 3단 캐시 구조로 응답 속도를 개선하며, 요청 제한(RateLimit)을 통해 비정상 트래픽을 제어하는 흐름을 만들고, 그 결과를 테스트해
4.[설계] 예매 시스템의 데이터 구조
영화 예매 시스템의 본질은 좌석이라는 한정된 자원을 여러 사용자에게 안전하게 할당하는 것이다. 이를 위해선 정확하고 일관된 데이터 모델이 필요하다.이번 글에서는 실제 구현한 JPA 기반의 엔티티들을 중심으로, 도메인 요구사항을 어떻게 데이터 구조로 표현했는지 설명한다.
5.[설계] 예매 API 구조
예매 시스템에서 가장 중요한 것은 신뢰성과 일관성이다. 예약이 중복되지 않아야 하고, 캐시는 응답 속도를 높이면서도 정확한 정보를 제공해야 한다. 이번 글에서는 실전 중심으로 API를 어떻게 설계했는지, 그 안에서 Redis와 분산락, 캐시 구조가 어떻게 녹아 있는지를
6.[Redis] 스프링에서 레디스 사용하기 — Lettuce 편
Spring Boot에서 Redis를 사용하는 가장 기본적인 방법은 Lettuce 클라이언트를 활용하는 것이다. 별도의 의존성 추가 없이도 Spring Boot Starter를 사용하면 Lettuce 기반의 Redis 설정이 자동으로 구성되며, 복잡하지 않은 데이터 캐
7.[Redis] 스프링에서 레디스 사용하기 — RedisRepository vs RedisTemplate
앞선 글에서는 Lettuce 기반의 RedisTemplate을 이용해 Redis 명령어를 사용하는 기본적인 방법을 소개했다. 이번 글에서는 RedisTemplate과 RedisRepository의 차이를 비교하고, 각각의 장단점과 실무에서의 사용 사례를 정리해본다.Re
8.[Redis] 스프링에서 레디스 사용하기 — 원자성을 보장하는 Redisson + Lua
앞선 글에서는 Lettuce 기반의 RedisTemplate과 RedisRepository를 활용한 기본적인 Redis 사용법과 그 한계를 정리했다. 이번 글에서는 그 대안으로 자주 활용되는 Redisson과 Lua 스크립트 조합을 소개한다.이 조합은 특히 원자성 보장
9.[Redis] 스프링에서 레디스 사용하기 — Redisson으로 저장 가능한 객체와 고급 기능
앞선 글에서 Redisson과 Lua를 활용한 원자적 연산의 흐름과 구조를 소개했다. 이번 글에서는 Redisson이 어떤 객체를 Redis에 저장할 수 있는지, 그리고 이를 활용한 고급 기능들인 분산 락, 캐시, 원자 스크립트 실행은 어떤 구조로 제공되는지를 살펴본다
10.[캐시전략] Caffeine으로 로컬 캐시 적용해보기
영화 예매 시스템에서 가장 많은 요청이 집중되는 API는 "상영 중인 영화 목록 조회" API였다. 특히 홈 화면에서 진입 시마다 호출되는 이 API는 페이징 없이 전체 영화를 반환하기 때문에, 쿼리량이 많고 응답 바이트 크기 또한 컸다. DB 조회 없이 빠르게 응답할
11.[캐시전략] Caffeine + Redis + DB, 3단 캐시 구조로 확장하기
이전 글에서는 Caffeine을 활용한 로컬 캐시만으로도 API 성능이 충분히 개선되는 것을 확인했다.그러나 이 방식은 단일 서버 환경에 한정된 최적화다.서비스가 실제 운영 환경에서 서버를 여러 대로 수평 확장하는 순간, 각 인스턴스에 존재하는 Caffeine 캐시는
12.[캐시전략] K6로 캐시 적용 전후 성능 테스트해보기
이 프로젝트에서 가장 먼저 캐시가 필요한 지점은 단연 홈 화면이었다. 홈 화면은 모든 사용자가 진입하자마자 자동으로 호출하게 되는 고정 API를 가지고 있고, 특히 /api/movies 엔드포인트는 상영 중인 영화 목록을 페이징 없이 전부 내려주는 API였다. 이 AP
13.[동시성제어] JPA 비관적 락으로 중복 예약 막기
예약 시스템에서 동일 좌석에 대해 동시에 예약이 들어오는 상황을 고려해야 한다. 단일 서버 환경에서도 트랜잭션 타이밍이 미세하게 겹치면 중복 예약이 발생할 수 있기 때문에, 우리는 이를 방지하기 위한 비관적 락(Pessimistic Lock) 전략을 적용했다.비관적 락
14.[동시성제어] 한 좌석에 100명이 몰리면? - CountDownLatch로 JPA 락 테스트하기
예매 시스템은 본질적으로 다중 사용자 요청이 동시에 들어오는 환경을 전제로 설계되어야 한다. 단일 사용자의 테스트로는 '정상 흐름'만을 검증할 수 있을 뿐, 동시 요청 시 발생할 수 있는 Race Condition, 트랜잭션 충돌, 캐시 무효화 타이밍 이슈 등은 감지할
15.[동시성제어] Redisson으로 분산 락 적용해보기
JPA 기반의 비관적 락을 통해 단일 서버 환경에서의 중복 예약 문제는 효과적으로 해결할 수 있었다. 하지만 서비스가 멀티 인스턴스 환경으로 확장되면 이야기가 달라진다. 각 서버 인스턴스는 서로 다른 JVM에서 동작하기 때문에, JPA 수준의 락은 인스턴스 간에 공유되
16.[동시성제어] 서버가 2대라면? 분산 락으로 한 좌석만 예약되게 막기 — Redisson 테스트
좋아, 지금까지 테스트 과정에서 겪은 시행착오와 고민을 녹여서 10편 블로그 글을 풍부하게 다시 구성해볼게. 목표는 단순한 테스트 결과 정리가 아니라, 분산 락 테스트를 설계하고 디버깅하며 얻은 인사이트를 진중하게 담는 것이야. [10편] 분산 환경에서 하나의 좌석을
17.[RateLimit] 1분에 20번만 조회할 수 있다 — Redis + Lua로 구현한 봇 차단
1. 요청 폭주, 어떻게 제어할 것인가? 예매 시스템에서 사용자는 빠르게 요청을 보낼 수 있고, 경우에 따라 동일한 유저가 초당 10회 이상의 요청을 보내는 시나리오도 존재한다. 이는 네트워크 상태가 불안정한 경우일 수도 있고, 악의적인 봇일 수도 있다. 중요한 점은
18.[RateLimit] 같은 영화 스케줄은 10초에 한 번만 예약 가능하다 - Redis + Lua로 실현한 비즈니스 제약
예약 시스템을 운영하다 보면 단순한 "사용자 요청 제한"을 넘어서, 도메인 정책에 가까운 제한을 고민하게 된다. 예를 들어, 동일한 좌석에 대해 사용자가 반복적으로 예약을 시도하면 어떻게 해야 할까? 사용자는 실수로 여러 번 버튼을 누를 수도 있고, 비정상적인 봇이 반