안녕하세요. 쿡앱스 기술팀 서버 프로그래머 이정훈입니다. 오늘은 실제 서비스 운영 중 겪었던 DocDB 병목 문제를 어떻게 Redis 캐시 아키텍처로 해결했는지, 그 과정의 고민과 선택, 그리고 결과를 풀어서 이야기해보려고 합니다. 이 아티클을 통해 가져가실 수 있는 포인트는 대략 이런 것들입니다.

Redis의 notify-keyspace-event 기능을 활용해서 스케줄링/캐시 만료 후 처리하기
Redis Pub/Sub과 Kafka를 조합해 이벤트 스트림을 안전하게 분산 처리하는 방법
Write-Back 캐시 아키텍처를 실제 서비스에 적용하면서 겪은 장단점
Docker + 로컬 인프라를 이용해 이 아키텍처를 그대로 실습 환경으로 재현하는 방식

잠깐, Redis란?

본격적인 장애 스토리로 들어가기 전에, 아주 짧게 Redis부터 짚고 가겠습니다. Redis는 Remote Dictionary Server의 약자로, 인메모리 기반의 Key-Value NoSQL 데이터베이스입니다. 메모리에 올라가 있기 때문에 읽기/쓰기가 매우 빠른 대신, 서버를 재시작하면 데이터가 유실될 수 있습니다. 그래서 Redis는 이를 보완하기 위해 AOF(Append Only File), RDB 스냅샷 같은 백업 방식을 제공합니다.

Redis = Remote Dictionary Server

Redis는 기본적으로 싱글 스레드 애플리케이션이지만 `UNLINK`, `FLUSHDB`, `FLUAHALL` 같은 일부 명령은 별도의 BIO_LAZY_FREE 스레드에서 비동기로 처리됩니다. 로그 저장을 위한 AOF나 스냅샷 생성을 위한 RDB 역시 전용 스레드를 사용하며, Redis 6부터는 소켓 I/O를 다른 스레드로 분리해 사실상 멀티스레드에 가까운 동작을 보입니다.

데이터 타입도 매우 다양합니다. `String`, `HASH` 처럼 기본적인 구조부터 `List`, `Set`, `Sorted Set`, `Bitmap`, `Geo`, `Streams` 까지 폭넓게 지원하여 게임 서버에서 필요한 대부분의 데이터를 유연하게 표현할 수 있습니다. 그래서 빠르게 읽고 쓰는 작업이 필요할 때는 자연스럽게 Redis를 먼저 고려하게 됩니다.

문제는 ‘징조’와 함께 찾아온다

2023년 9월 5일. 한동안 조용하던 <포트리스 사가> 서버에서 알림이 쏟아지기 시작했습니다. 개발자들이 한 모니터 앞에 세 명 이상 모이면 안 좋다는 불문율이 있는데, 그날이 딱 그랬습니다. 다 같이 Grafana를 열어보고 지표를 확인했는데, CPU는 멀쩡한데 레이턴시는 불안정한 상태였습니다. 특히 유저 데이터 저장 콜렉션 (`User`)이 파티셔닝 되지 않은 단일 구조라는 점이 신경 쓰였습니다.

개발자가 셋 이상 모이면 불운한 징조라던데...

Grafana에 나타난 지표

CPI 콜이 아무리 많아져도 DocDB CPU가 60% 이상 올라가지 않는 점
레이턴시가 25초까지 치솟아도 ECS CPU는 40%로 안정적인 점
세이브 데이터를 저장하는 User 콜렉션이 파티셔닝 되어 있지 않은 점

우리가 의심한 3가지 포인트

DocDB 핫스팟 및 Lock 병목 구간

결론은 DB였습니다. 동시접속자가 급증하면서 세이브 API 호출이 한 곳으로 몰렸고, `User` 콜렉션에 SELECT와 UPDATE가 집중되면서 핫스팟 + Lock/Latch 병목이 발생한 상황이었죠. 그래서 우리는 긴급 점검을 공지하고 대응을 시작했습니다.

첫 번째 시도, UID 파티셔닝

긴급 상황에서 가장 먼저 떠오른 해결책은 UID 파티셔닝이었습니다. 빠르게 손댈 수 있고, 직관적으로도 “부하 분산”에 도움이 되니까요. 우리는 `User` 테이블을 10개로 나눴습니다. 유저마다 붙는 `UID` 의 1의 자리를 기준으로 :UID가 `10` 이면 users_0, UID가 `19` 면 users_9로 제법 균등하게 분산시키는 구조를 만들었습니다. 하지만 금방 한계가 보였습니다. 구조적인 병목 자체를 없애지는 못했고, 트래픽이 특정 구간에 몰리면 여전히 그 파티션만 터질 수 있었죠. 즉, 파티셔닝은 임시방편일 뿐, 장기적으로는 또 다른 병목 지점을 남기는 문제가 있었습니다.

UID 파티셔닝

두 번째 시도, 캐시 전략 재설계화

우리는 이미 랭킹이나 기타 데이터 캐싱 용도로 Redis를 적극적으로 사용하고 있었고, Tailed Demon Slayer: RISE 프로젝트에서 유저 세이브 데이터를 캐싱하는 기법도 활용해본 적이 있습니다. 그래서 자연스럽게 이런 생각이 들었습니다. “차라리 캐시로 이 문제를 근본적으로 줄일 수 있지 않을까?” 하지만 캐시는 잘못 쓰면 독이 됩니다. 만료/삭제 정책이 없으면 Redis 메모리는 단조 증가하고 DB와 다른 구조로 저장하면 정합성 이슈가 발생합니다. 실제로 예전에는 캐시가 잘 지워지지 않아 Redis 메모리 사용률이 꾸준히 올라가는 문제도 겪었습니다. 그래서 우리는 캐시 전략을 처음부터 다시 설계하기로 했습니다. 핵심은 READ 전략과 WRITE전략, 두 가지였습니다.

Read 전략

유저 데이터를 읽는 전략을 설계할 때 저희는 두 가지 선택지를 놓고 비교했습니다. Read-Through 방식은 애플리케이션이 항상 캐시를 우선적으로 바라보고, 캐시에 데이터가 없을 경우 캐시가 직접 DB에서 데이터를 가져와 채워 넣는 구조입니다. 구현이 단순하다는 장점은 있지만, 캐시가 장애가 나면 서비스 전체가 데이터를 읽지 못하게 되는 치명적인 단점이 존재했습니다. 반면 Look-Aside(Lazy Loading)는 애플리케이션이 먼저 캐시를 확인하고, 없으면 DB에서 직접 데이터를 읽어오는 방식입니다.

이 방식은 캐시 장애가 발생하더라도 DB를 통해 서비스가 계속 동작할 수 있다는 안정성이 있어, 저희가 지향하는 운영 방향과 더 잘 맞았습니다. 그래서 저희는 Look-Aside 전략을 선택했습니다. 다만 일반적인 방식과는 달리, 캐시 미스로 인해 DB에서 읽어온 값을 즉시 캐시에 다시 저장하지 않는 방식으로 변형하여 사용했습니다. 캐시에 데이터를 언제 적재하고, 언제 DB로 내릴지는 WRITE 전략에서 통제하기 위함이었습니다.

Write 전략

Write 전략을 선택하는 과정은 더 많은 검토가 필요했습니다. Write-Around 방식은 데이터를 DB에만 저장하며 캐시는 읽을 때만 사용하는 구조인데, 이 방식은 DB 오프로딩이라는 저희의 목표를 달성하는 데에는 효과적이지 않았습니다. Write-Through 방식은 데이터를 DB와 캐시에 동시에 저장하기 때문에 캐시의 최신성을 확보할 수 있으나, 모든 쓰기 작업이 두 번 일어나므로 오히려 시스템 부담이 증가하는 문제가 있습니다. 최종적으로 저희는 Write-Back 전략을 선택했습니다. 모든 쓰기 작업을 우선 캐시에 반영하고, 특정 시점이나 이벤트를 기준으로 DB에 일괄 반영하는 구조입니다. 이 방식은 DB 쓰기 부하를 크게 줄여주는 매우 강력한 장점을 가지고 있습니다.

다만 캐시에 저장된 상태에서 장애가 발생하면 데이터 유실 위험이 존재하고, 구현 난이도 역시 가장 높은 방식이었습니다. 저희가 해결해야 했던 핵심 문제는 DB Write 병목이었기 때문에, 여러 리스크가 있더라도 Write-Back 전략이 가장 합리적인 선택이라고 판단했습니다.

캐시 데이터는 언제 DB로 내릴까?

캐시 아키텍처를 설계할 때 가장 중요한 질문은 “언제 DB로 내릴 것인가?”, 그리고 “언제 Redis에서 데이터를 삭제할 것인가?”였습니다. 세이브 데이터를 캐시에만 쌓아두면 Redis 메모리는 매우 빠르게 차오르기 때문에, 또 다른 병목을 만드는 결과를 초래할 수 있었습니다. 이를 해결하기 위해 저희는 Redis의 notify-keyspace-event 기능을 활용했습니다.

이 기능은 Redis에서 key가 생성되거나 갱신되거나 만료될 때 이벤트를 Pub/Sub 형태로 발행해주는 메커니즘입니다. 저희는 유저 세션을 표현하는 가벼운 key를 만들고, 유저 접속이나 주기적 헬스 체크가 발생하면 TTL을 갱신하도록 구성했습니다. 그리고 더 이상 헬스 체크가 오지 않아 세션 key가 만료될 경우, 해당 시점을 트리거로 Redis에 저장된 유저 데이터를 DB로 내리고 필요 시 캐시를 삭제하도록 설계했습니다.

그러나 Redis Pub/Sub에는 메시지 보장이 되지 않는다는 심각한 문제가 있습니다. Subscriber가 잠시 죽어 있는 경우 해당 이벤트는 영구적으로 사라집니다. 이 문제를 해결하기 위해 저희는 Redis와 애플리케이션 사이에 Kafka를 두어 이벤트를 안정적으로 적재하고 분산 처리할 수 있는 구조로 확장했습니다.

Keyspace Event → Subscriber → Kafka → Consumer Group 흐름

최종 구조는 Redis가 keyspace 이벤트를 발행하면 Subscriber가 해당 이벤트를 Kafka로 전달하고, Kafka Consumer들은 이를 분산 처리하여 Redis에서 유저 데이터를 가져와 DB에 저장하거나 캐시를 삭제하는 방식입니다. 이 구조는 데이터 유실을 방지하고, 자동화된 캐시 정리와 안정적인 Write-Back 운영을 가능하게 만들었습니다.

성능 지표는 거짓말을 하지 않는다

24시간 동안 긴급 점검과 구조 개편을 진행한 후, APM 지표는 극적인 차이를 보여주었습니다. Save Latency는 평균 1.55초에서 15.5ms로 감소하며 99% 개선되었고, DocDB CPU는 57%에서 9.7%로 줄었습니다. ECS CPU 역시 거의 절반 수준으로 떨어졌으며, 전반적인 병목이 사라진 것을 수치로 명확하게 확인할 수 있었습니다.

점검 후 APM 지표

Redis CPU 사용률이 증가한 것은 캐시 계층이 더 많은 역할을 수행하게 되었다는 의미로, 설계한 구조가 정상 동작하고 있음을 보여주는 자연스러운 결과였습니다. 다만 점검 직후에는 Redis와 DocDB 간 데이터 구조 불일치로 인해 일부 유저 데이터가 누락되는 정합성 문제가 발생했습니다. 이후 데이터 변환 로직을 수정하고 필드 매핑을 재정비하여 해당 문제는 모두 해결되었습니다.

이번 경험이 남긴 교훈

이번 24시간 긴급 대응을 통해 몇 가지 중요한 교훈을 얻을 수 있었습니다. 먼저, 캐시와 DB의 데이터 구조는 반드시 일치해야 하며, 그렇지 않을 경우 실제 운영 환경에서 치명적인 정합성 문제를 야기할 수 있습니다. 두 번째로, 캐시 장애 시나리오는 선택이 아니라 필수입니다. 캐시가 죽는 순간 DB로 트래픽이 몰리기 때문에 본래 해결하려던 병목이 다시 되살아날 수 있습니다. 또한 Redis keyspace 이벤트 소비가 실패하면 캐시가 지워지지 않고 계속 남아 Redis 메모리가 가득 차게 되는 문제가 발생합니다.

DB 동기화 및 캐시 정리 시퀀스 다이어그램

이는 곧 Redis OOM으로 이어질 수 있기 때문에 반드시 안정적인 이벤트 소비 구조를 갖추는 것이 중요합니다. 마지막으로, Write-Back 전략은 매우 강력하지만 그만큼 높은 책임성을 요구합니다. 언제 데이터를 DB로 내릴 것인지, 캐시 장애가 발생하면 어떤 경로로 복구할 수 있는지 등 운영 측면에서 고려해야 할 부분이 많습니다.

마치며

이번 Redis 캐시 아키텍처 도입 과정은 단순한 장애 대응을 넘어, 쿡앱스 서버 구조 전반을 다시 점검하는 계기였습니다. 캐시 전략, 이벤트 흐름, 데이터 정합성처럼 당연하게 여겼던 요소들이 실제 운영 환경에서는 얼마나 큰 영향을 주는지 명확히 깨달을 수 있었죠. 이 경험을 바탕으로 앞으로는 이번에 구축한 구조를 더욱 안정적으로 다듬고, 남아 있는 레거시 저장 방식을 정비하면서 전체적인 데이터 흐름을 한층 견고하게 만드는 데 집중할 예정입니다. 이번 여정이 비슷한 고민을 가진 분들께 작은 도움이 되길 바랍니다!