한계에 다다른 전시 서버와 우리의 해답

11번가 전시서비스개발팀은 전시 API 서버(DPWAS) 의 트래픽 증가와 버스트 트래픽에 대응하기 위해, 서버를 더 적게 쓰면서도 안정성을 유지하는 방향으로 구조를 손봤다.

인프라팀은 Scale-up + Scale-in 전략으로 서버를 110대에서 70대로 줄이고, 8코어에서 16코어로 증설했다. 개발팀은 줄어든 서버 환경에서도 병목 없이 버티도록 Tune Up + Fix in 방식으로 애플리케이션 레벨 최적화에 집중했다.

가장 먼저 드러난 문제는 트래픽이 없는 서버에서조차 2분마다 CPU Spike가 반복되는 현상이었다. 원인을 추적한 결과, 4개 MongoDB 인스턴스가 모두 같은 maxConnectionIdleTime = 1분 설정을 쓰고 있었고, MaintenanceTimer가 유휴 커넥션을 한꺼번에 재생성하면서 CPU가 집중적으로 치솟고 있었다.

이 문제는 커넥션 재생성 시점을 분산하는 방식으로 해결했다.

• 각 MongoDB 인스턴스의 maxConnectionIdleTime 을 50분, 55분, 60분, 65분으로 다르게 설정
• minPoolSize = maxPoolSize로 유지해 버스트 트래픽 시 커넥션 부족을 막음
• 결과적으로 노후 장비는 CPU Spike가 **25%에서 9%**로 내려갔고, 신규 장비는 8%에서 2~3% 수준으로 안정화됐다

두 번째 문제는 버스트 트래픽 시 발생한 지연 트랜잭션이었다. Top-Traffic Endpoint가 MongoDB 조회인 만큼, 커넥션 풀 사이즈를 충분히 확보했고, 서버사이드 DB의 maxIncomingConnections도 5K에서 10K로 늘려 클라이언트와 균형을 맞췄다.

또한 MongoDB SocketReadTimeout 예외와 함께 일부 요청이 겉보기엔 200 OK로 처리되는 상황도 확인해, 재시도 동작이 실제 응답 품질에 어떤 영향을 주는지 점검했다. 대량 조회 구간에서는 command 부하를 낮추도록 요청 단위도 조정했다.

세 번째 축은 서버 리소스 관리였다. 로컬 캐시 최대 사이즈를 제어하고, 캐시키 정렬과 대량 데이터 호출 로직을 손보며 메모리와 CPU 사용량을 함께 줄였다. 전시 서버가 ZGC를 사용해 힙 파편화 위험이 낮다는 점도 확인해, 메모리 안정성에 대한 판단 근거를 분리했다.

최종적으로 전시 API 서버는 더 적은 서버 수로도 더 높은 처리량을 달성했다. MAX TPS는 65.9K에서 87.9K로 상승했고, 대규모 트래픽 환경에서 비용 효율과 안정성을 동시에 확보하는 방향으로 운영 체계를 바꿨다.