BookVoyage

📊 핵심 아키텍처

개요

도서 기록과 리뷰를 공유하는 소셜 플랫폼입니다. Neo4j 그래프 기반 협업 필터링(CF)과 Elasticsearch 콘텐츠 기반 필터링(CB)을 결합한 하이브리드 추천 파이프라인을 직접 설계했습니다. Kafka로 수집한 사용자 행동 이벤트를 Redis ZSET에 즉시 반영하여 다음 추천 요청부터 실시간으로 정렬에 영향을 주는 구조를 구현했습니다. Gatling으로 4단계 부하 시뮬레이션(Baseline → Batch ON → Spike → Cooldown)을 진행했고, HikariCP 단일 커넥션 풀 고갈(waiting 131개)이 근본 원인임을 확인했습니다. Primary 풀(30)과 Outbox 배치 전용 풀(5)로 분리하고 외부 API 타임아웃과 Redis 캐싱을 추가하여 p99를 60,002ms에서 106ms로 개선하고 실패를 완전히 제거했습니다.

핵심 성과

• ✓Neo4j 그래프 CF + Elasticsearch CB 하이브리드 추천 파이프라인 설계 (Graph×0.4 + Semantic×0.3 + Popularity×0.1 + Freshness×0.05)
• ✓Kafka + Redis ZSET(ZINCRBY) 기반 사용자 행동 실시간 반영 구조 구현
• ✓윈도우 샘플링으로 추천 상위 품질 유지하면서 다양성 확보
• ✓OpenAI 기반 사용자 독서 페르소나 자동 생성 및 추천 설명 생성
• ✓HikariCP 단일 풀 고갈(10개) 원인 분석, Primary(30) / Outbox(5) 이중 풀 분리로 API-배치 커넥션 경합 제거
• ✓Kakao → Google Books 폴백 + Redis 캐싱(TTL 1시간) + 타임아웃(Connect 3s + Read 5s)으로 외부 API 장애 전파 차단
• ✓Gatling 4단계 시뮬레이션: p99 60,002ms → 106ms, 실패율 4.5% → 0%, 처리량 16.26 → 21.59 RPS
• ✓AWS EC2 + RDS + S3 + CloudFront + Route53 + Docker 기반 배포

회고

• —Gatling 테스트 전에는 커넥션 풀 설정이 그냥 숫자 하나라고 생각했다. 테스트 결과를 보고 나서야 커넥션 풀이 동시성 제어 장치이며, 풀 크기는 트래픽 패턴과 배치 작업을 함께 고려해서 설계해야 한다는 걸 이해했다.
• —외부 API(Kakao Books)가 느려지면 내 서버의 DB 커넥션도 같이 고갈된다는 연쇄 장애 패턴을 직접 경험했다. 시스템 경계에서는 항상 타임아웃과 폴백을 설정해야 한다는 것을 깨달았다.
• —Neo4j + Elasticsearch + Redis를 조합한 추천 파이프라인은 원하는 방향으로 만들었지만, 추천 품질을 객관적으로 측정하는 체계를 갖추지 못했다. 시스템을 만들면서 동시에 평가 지표도 설계했어야 했다는 아쉬움이 남는다.
• —추천 시스템을 스스로 평가하면서 내가 구현한 것과 구현하지 않은 것을 명확히 정리할 수 있었다. 내 주분야가 아닌 영역에서 적절한 선을 그을 수 있는 것도 중요한 판단이라는 걸 배웠다.

기술 스택

관련 블로그 글