[설계 면접] 트래픽이 갑자기 몰리는 경우 어떻게 처리할 수 있도록 설계했나요?

사용한 기술 스택은 다음과 같습니다.

Java 17
Spring
JPA
QueryDSL
Redis(Redisson, LuaScript)
Kafka
Spring Cloud
Filebeat, ELK, Prometheus, Grafana
micrometer, Zipkin
Spring Batch

트래픽 급증에 대비하여 여러 계층에서 대응할 수 있도록 설계했습니다. 우선, JMeter를 사용해 TPS 1000~6500 수준까지 부하 테스트를 진행했고, 애플리케이션 레벨에서는 Tomcat의 쓰레드 풀 사이즈를 조정해 커넥션 처리량을 높였습니다.
이후 Redis 캐시를 활용하여 조회 요청이 많은 엔드포인트에는 데이터 TTL 기반의 캐시를 설정하였고, 일부 데이터는 정적 캐시로 처리하여 I/O 병목을 방지했습니다.
쓰기 요청이나 부하가 집중되는 비즈니스 로직은 Kafka로 분리해 비동기 이벤트 기반으로 처리하며, Outbox 패턴을 적용해 DB 트랜잭션과 메시지 발행을 원자적으로 보장했습니다.
Kafka 컨슈머는 파티션 기반 병렬 처리를 통해 확장 가능하게 했으며, Lag 및 처리 실패 시 DLQ로 메시지를 분리하여 안정성을 확보했습니다.
추가적으로 CPU/메모리/트래픽 지표 기반으로 HPA 설정 및 ALB 레벨의 로드 밸런싱 구성도 함께 고려했습니다.

꼬리 질문

1. Kafka 컨슈머 처리 속도가 느릴 경우 어떻게 대응했나요?

컨슈머 처리 속도가 느릴 경우, Prometheus를 통해 Kafka lag을 모니터링하고, lag이 지속적으로 증가한다면 다음과 같은 대응을 했습니다.
먼저 concurrency 값을 조정해 병렬 처리 스레드를 확장했고, max.poll.records를 조절해 한 번에 처리할 메시지 수를 튜닝했습니다. 또한 파티션 수를 늘려 컨슈머 그룹 내에서 처리 분산을 강화했으며, 메시지 처리 시간이 길 경우 백프레셔 전략과 DLQ 도입도 병행했습니다.

2. Redis 캐시에 장애가 생긴다면 어떤 Fallback 로직이 동작하나요?

Redis 장애 상황에서는 캐시 미스 시 DB에서 데이터를 조회한 뒤 다시 Redis에 갱신하는 구조로 fallback을 구성했습니다.
만약 Redis 자체 장애가 발생하면, Sentinel을 이용한 고가용성 구성을 통해 자동으로 새로운 master를 할당받을 수 있도록 설정했습니다. 추가적으로 Redis 접근 불가 시에는 서비스는 degrade된 상태로 동작하도록 구성했고, 이때의 로그를 남겨 알림 시스템과 연동하여 대응할 수 있도록 했습니다.

3. 캐시 데이터의 TTL은 어떻게 설정하였고, 무효화는 어떤 방식으로 하였나요?

캐시의 TTL은 데이터 변경 빈도에 따라 달리 설정했습니다. 변경이 드문 데이터는 장기 TTL로 설정했고, 잦은 수정이 필요한 데이터는 짧게 설정하거나, 슬라이딩 TTL 방식을 적용하기도 했습니다.
무효화는 데이터 수정/삭제 시 명시적으로 캐시를 제거하며, TTL 만료 시 자동 제거되도록 설정했습니다.