분류
실무
실무
방송 연계 대국민 투표 시스템
방송 중 순간적으로 몰리는 대규모 트래픽을 견디는 고가용성 투표 시스템. 부하테스트에서 Vote API 1,800 TPS를 100% 성공률로 처리하고, 실서비스는 c6i.4xlarge 8대로 수평 스케일아웃했습니다.
NestJSAWSMongoDB AtlasKafkaRedisAngular
// 01
문제
문제
방송 연계 투표는 진행자가 멘트를 던지는 순간 수십 초 안에 트래픽이 폭발한다. 평소엔 한가하다가 특정 순간에만 수천 건의 요청이 동시에 몰리는 전형적인 Spike Traffic 패턴이라, 그 짧은 구간에 DB가 버티지 못하면 표가 유실되고 곧바로 방송 사고로 이어진다. 일반적인 평균 부하 기준 설계로는 이 정점을 감당할 수 없었다.
// 02
접근
접근
AWS 기반 클라우드 인프라(VPC·EC2·ELB)를 설계하고, 쓰기 경로 앞단에 Kafka를 두어 트래픽 폭주 시 DB 쓰기 부하를 비동기로 흡수했다. 조회 경로는 Decorator 패턴 기반 Redis 캐싱으로 분리해 읽기와 쓰기를 독립적으로 확장할 수 있게 만들었다. 백엔드 API(NestJS)부터 운영 관리자(Angular/TailwindCSS)까지 전 구간을 직접 설계·구현했고, 외부 의존 없이 동작하는 자체 구조로 운영했다.
// 03
결과
결과
Artillery 부하테스트로 한계를 검증했다. Vote API 단일 엔드포인트는 c6i.2xlarge 3대 환경에서 1,800 TPS를 MongoDB Atlas 병목 없이 100% 성공률로 처리했고, 댓글·투표·퀴즈를 섞은 혼합 시나리오는 c6i.4xlarge 1대에서 약 1,300 RPS를 median 2ms·p95 40ms·p99 54ms로 견뎠다. 실서비스는 c6i.4xlarge 8대 수평 스케일아웃으로 운영해, 방송 정점 트래픽을 표 유실 없이 집계했다.
// 04
배운 것
배운 것
고가용성은 평균이 아니라 최악의 순간으로 결정된다. 평상시 부하가 아니라 'Spike의 정점'을 기준으로 쓰기 경로를 설계한 것이 핵심이었고, 쓰기를 Kafka로 비동기화한 단 하나의 결정이 전체 가용성을 좌우했다.
배경
특정 방송 프로그램의 실시간 시청자 투표를 처리하는 시스템입니다. 방송 흐름에 맞춰 투표 구간이 열리고 닫히며, 그 구간에 트래픽이 집중되는 구조라 “얼마나 큰 트래픽이냐”보다 “얼마나 짧은 시간에 몰리느냐”가 설계의 출발점이었습니다.
설계 포인트
- 쓰기 흡수 — 투표 요청을 Kafka로 받아 DB 쓰기를 비동기화. 정점 트래픽을 큐가 흡수하고 DB는 일정한 속도로 소비합니다.
- 읽기 분리 — 집계·조회는 Redis 캐싱으로 분리해, 투표가 몰리는 동안에도 결과 조회 성능이 흔들리지 않도록 했습니다.
- 전 구간 자체 운영 — API부터 관리자 화면까지 직접 구현해, 방송 당일 운영 중 발생하는 변수에 빠르게 대응할 수 있게 했습니다.
부하 테스트
Artillery로 한계와 여유를 함께 측정했습니다.
- Vote API 단일 엔드포인트 — c6i.2xlarge 3대 환경에서 1,800 TPS 달성. MongoDB Atlas에 병목 없이 100% 성공률을 유지했습니다.
- 혼합 시나리오(댓글·투표·퀴즈) — c6i.4xlarge 1대 기준 ~1,300 RPS 처리, 응답시간 median 2ms · p95 40ms · p99 54ms.
- 실 서비스 운영 — c6i.4xlarge 8대 수평 스케일아웃으로 방송 정점 트래픽을 여유 있게 흡수합니다.