[feat/#11]: Kafka 기반 Event-Driven 아키텍처를 도입하고 Non-blocking 처리를 구현한다

[woong2e]

✅ PR 유형

어떤 변경 사항이 있었나요?

• 새로운 기능 추가
• 버그 수정
• 코드에 영향을 주지 않는 변경사항(오타 수정, 탭 사이즈 변경, 변수명 변경)
• 코드 리팩토링
• 테스트코드 추가
• 성능 개선 작업
• 주석 추가 및 수정
• 문서 수정
• 빌드 부분 혹은 패키지 매니저 수정
• 파일 혹은 폴더명 수정
• 파일 혹은 폴더 삭제

---

🚀 작업 내용

이번 PR에서 작업한 내용을 구체적으로 설명해주세요. (이미지 첨부 가능)

Verification

k6 부하 테스트 시나리오
규모: 유저 10,000명 (VU 200명이 각각 50명씩 대행) / 부하: 총 30,000 요청 (1인당 3회 '따다닥' 연속 전송)

Kafka 기반의 Event-Driven 아키텍처 전환

Problem & Analysis

• Redis Lua Script 도입으로 동시성 제어 문제는 해결했으나, 쿠폰 발급 성공 건에 대한 MySQL Insert 작업이 동기(Synchronous) 방식으로 처리되고 있어 전체 Latency가 DB 성능에 종속되는 현상 발생
• In-Memory(Redis) 처리 속도에 비해 Disk I/O(DB) 속도가 현저히 느려, 순간적인 트래픽 폭주 시 DB Connection Pool 고갈 및 Tomcat 스레드 대기 현상이 다시 발생

Solution

Kafka를 활용한 발급-저장 로직의 분리

• Producer (API Layer): 쿠폰 발급 요청 시, Redis에서 재고 검증 및 차감(Lua Script)만 수행한 뒤 즉시 발급 성공 이벤트를 Kafka Topic으로 전송하고 클라이언트에게 응답 반환. (Non-blocking I/O)
  → Kafka Producer의 linger.ms와 batch.size 설정을 튜닝하여, 즉시 전송하지 않고 메모리 버퍼에 일정량을 모아서 보내는 배치 전송 방식 적용
• Consumer (Worker Layer): 별도의 Worker 서버가 Kafka에서 메시지를 Polling하여 DB에 비동기적으로 적재.
  → Fetch해 온 메시지들을 단건 쿼리가 아닌, JDBC Bulk Insert(Batch Update) 방식을 사용하여 하나의 트랜잭션으로 묶어서 DB에 반영. DB 입장에서 비용이 큰 트랜잭션 커밋 횟수를 줄여 쓰기 처리량을 극대화(QPS 최대 175로 감소)

Result

• Latency 개선: 클라이언트 응답 과정에서 가장 느린 DB Insert 과정을 제거하여, Redis 연산 및 Kafka Produce 비용만으로 응답이 가능해짐.
• DB 보호 및 안정성 확보: 순간적으로 10,000명의 트래픽이 몰려도, Consumer가 DB가 처리 가능한 속도로 메시지를 조절하여 소비하므로 DB 서버의 부하를 일정하게 유지 가능.
• 시스템 리소스 효율화: WAS 스레드가 DB 커넥션을 기다리는 시간이 사라져, 더 적은 스레드로 더 많은 동시 접속자 처리가 가능해짐.
  지속적인 파라미터 튜닝을 시도했으나, 처리량이 급증함에 따라 CPU 리소스가 임계치(100%)에 도달하여 포화 상태가 지속

---

💬 기타 사항 or 추가 코멘트

남기고 싶은 말, 참고 블로그 등이 있다면 기록해주세요.

---