수평 확장, 캐시, 큐 등 실제로 설계하고 검증한 구조를 중심으로 설명한다
캡스톤 프로젝트에서 동시 사용자 1만 명 이상을 가정한 데이터 파이프라인 아키텍처를 설계했습니다. 직접 운영한 것은 아니었지만 부하 시뮬레이션까지 검증했습니다.
설계의 핵심은 세 가지였습니다. 첫째, 입력 레이어에 메시지 큐(Kafka)를 두어 트래픽 급증 시 소비자 속도에 맞게 흘려보내는 구조, 둘째, 자주 조회되는 집계 결과는 Redis 캐시에 30분 TTL로 올려두는 패턴, 셋째, 분석 쿼리용 DB는 쓰기 DB와 분리해 읽기 전용 레플리카에서 처리하는 구조였습니다. 이 세 요소가 없을 때와 있을 때를 로컬 부하 테스트로 비교했는데, p99 응답 지연이 8.2초에서 0.9초로 줄었습니다.
실패는 Kafka 컨슈머 그룹 파티션 수를 처음에 너무 작게 잡아서 소비 속도가 느려진 구간이 생긴 것이었는데, 파티션을 4개에서 12개로 늘리고 나서야 해소되었습니다. 이론은 알아도 파라미터 하나가 전체 처리량을 좌우한다는 것을 수치로 확인하는 경험이 컸습니다. 실제 운영 스케일은 경험해봐야 알겠지만, 설계 원칙을 먼저 검증하는 방법을 이 프로젝트에서 체득했습니다.