1. 문제 발견: LIKE 검색의 치명적 성능 한계1.1. 문제 인식: 4초짜리 검색 대기 시간 100만 개 이상의 상품 데이터가 누적된 환경에서 상품명 검색 기능에 심각한 병목 현상이 발생했다. 특히 `item-performance.http`를 통해 아래의 요청을 실행했을 때, 응답 시간이 3,927ms(약 4초)를 기록하며 사용자 경험을 심각하게 저해하는 수준임을 확인했다.대상 요청: GET http://localhost:8000/items?title=Mock 상품 제목 10&page=0&size=201.2. LIKE 검색의 구조적 결함 (기존 코드 분석) 문제의 근본 원인은 ItemRepositoryImpl.java에서 QueryDSL의 .contains() 메서드를 사용한 방식에 있었다.// 기존..

1. Double Checked Locking 패턴의 필요성1.1. 단순 락 적용의 한계캐시와 락을 함께 사용할 때 일반적으로 캐시 Miss → 락 획득 → DB 조회 순서로 처리한다. 하지만 락을 획득하자마자 바로 DB 조회를 수행하는 방식에는 허점이 존재한다. 현재 스레드가 락을 획득하기 위해 대기하는 동안, 이미 다른 서버나 스레드가 락을 먼저 획득하여 DB 조회를 마치고 캐시를 채워두었을 가능성이 있기 때문이다.1.2. 캐시 재확인 없는 중복 조회 문제이 부분을 고려하지 않고 락 획득 후 즉시 DB로 향하면, 이미 캐시에 데이터가 있음에도 불구하고 불필요한 DB 조회가 한 번 더 발생하게 된다. 이를 방지하기 위해 락을 획득한 직후 캐시를 다시 한 번 확인하는 과정이 반드시 필요하며, 이러한 패턴..

1. 문제 상황 - Hot Key 문제1.1. 이상 징후 및 긴급 알림 모니터링 시스템으로부터 짧은 시간 동안 DB 부하량이 급증하여 DB CPU 이용률이 순간적으로 100%까지 치솟았다는 긴급 알림을 확인하였다. 이는 시스템 전체의 가용성을 위협하는 심각한 상황으로, 즉각적인 원인 분석이 필요하다. 1.2. 원인 파악 및 로그 분석 로그 분석 결과, 특정 작가(A 작가)의 수상 소식이 SNS에서 갑자기 화제가 되면서 해당 작가 관련 정보를 조회하는 트래픽이 평소 대비 20배 이상 폭등했음을 파악하였다. 특히 A 작가의 베스트 셀러에 대한 캐시 키가 마침 만료되는 시점과 맞물렸다. 즉, 인기 있는 단일 키가 만료되면서 해당 키에 대한 수많은 조회 요청이 Redis를 거치지 않고 데이터베이스(DB)로 직행..

1. 문제 상황 - Cache Avalanche1.1. Cache Avalanche란 무엇인가 Cache Avalanche는 말 그대로 캐시가 한순간에 무너지는 현상이다. 평소에는 Redis 캐시가 DB 앞에서 방패 역할을 하며 대부분의 요청을 처리하고 있지만, 어느 특정 시점에 그 방패가 통째로 사라져버리는 상황을 의미한다. 이를 일상적인 상황으로 비유하면 다음과 같다. 한 쇼핑몰에서 인기 도서 정보를 DB 대신 Redis 캐시에 저장해두고 있다고 가정한다. 평소에는 사용자들이 도서 상세 페이지를 조회하더라도 캐시에서 즉시 응답되기 때문에 DB는 거의 호출되지 않는다. 문제는 모든 캐시의 유효기간이 동일한 시점에 종료되는 경우이다. 어제 00시에 진행된 도서 할인 이벤트로 인해 수만 개의 인기 도서 ..

1. 문제 상황 - Cache Penetration1.1. 시스템 배경 및 현황 실제와 유사한 사례를 통해 Redis 운영 중 발생할 수 있는 문제를 경험하고, 이를 구현하여 해결 전략 적용 전후의 성능 차이를 수치로 검증하고자 한다. 현재 'BookHub'라는 도서 관리 시스템을 운영 중인 상황을 가정한다. BookHub 시스템은 현재까지 안정적으로 동작해 왔으며, 하루 평균 100만 건의 도서 조회 요청을 처리하고 있다. 이 중 약 85%는 Redis 캐시를 통해 응답하며 효율적으로 운영되고 있다. 사용자들은 API를 통해 실시간으로 도서 정보를 조회하며, 특히 인기 도서 목록과 신간 도서 정보에 대한 요청 비중이 가장 높다.1.2. 이상 징후 포착 서버와 Redis에 대한 지표를 시각화하여 모니터..

1. Redis 모니터링 설정1.1. Grafana를 통한 Redis 모니터링 환경 구축[1] 그라파나 접속 후, 왼쪽 메뉴에서 "Plugins" 선택 [2] plugin 검색 창에 "redis" 검색 후 선택 [3] Redis 를 눌러 랜딩된 화면 우측 상단의 install 을 클릭 후, Add new data source 를 선택 [4] Address 부분에 `redis-server:6379` 라고 값을 채워주고, save & test 를 실행하면 다음과 같이 Data Source 추가 [5] 다시 플러그인 검색 결과화면으로 진입 후, 이번에는 Redis Application 을 선택 [6] 오른쪽 상단의 install 클릭 후, Enable 클릭 [7] 결과 확인 1.2. 한계점 Grafana에서 ..

1. 들어가며 분산 서버 환경에서 발생하는 로컬 캐싱의 한계를 해결하기 위한 최적의 대안은 Remote 캐시를 도입하는 것이다. 그리고 현대 백엔드 시스템에서 Remote 캐시의 대명사로 자리 잡은 도구가 바로 Redis이다. 이번 장에서는 Redis의 핵심 특징과 실제 조작법에 대해 상세히 기술한다.2. Redis의 정의와 핵심 특징2.1. NoSQL 인메모리 데이터 구조 저장소Redis(Remote Dictionary Server)는 메모리 기반의 NoSQL 데이터 저장소이다. 데이터를 디스크가 아닌 RAM에 상주시켜 처리하기 때문에, 일반적인 관계형 데이터베이스(RDBMS)와 비교할 수 없을 만큼 빠른 성능을 제공한다.2.2. 풍부한 자료구조와 캐시 관리 기능Redis는 단순한 Key-Value 저..

1. 서버 환경의 변화와 캐싱의 역할1.1. 단일 서버 환경 단일 서버 환경은 모든 사용자의 요청이 하나의 서버 인스턴스로 집중되는 구조를 의미한다. 이 환경에서는 서버 내부의 로컬 캐시가 항상 최신 데이터를 보장하며, 구현이 단순하여 서비스 초기 단계에 적합하다. 하지만 시간이 지나고 유저 수가 늘어나거나, 서비스가 성장하면서 트래픽 급증 또는 서버 장애가 발생하게 되면 단일 서버 구조는 명확한 한계에 직면하게 된다. 예를 들어, 단일 서버가 과부하로 느려지거나 중단되면 전체 서비스가 멈추게 되는 단일 장애점 문제가 발생한다.1.2. 분산 서버 환경 앞서 말했듯이 단일 서버 환경에서는 트래픽이 증가함에 따라 서버 한 대로는 부하를 감당하기 어려워진다. 이를 해결하기 위해 여러 개의 서버 인스턴스를 실..