대규모 트래픽 처리 시스템의 실운영 병목: vCPU 할당량, 네트워크 PPS, Node.js GC 문제 해결 사례

핵심 기술: 초당 5만 건의 요청 처리를 목표로 하는 대규모 트래픽 시스템에서 마주치는 실운영상의 병목 현상들을 데이터 기반으로 분석하고 해결하는 과정을 상세히 다룹니다.

기술적 세부사항:
* 초기 아키텍처: NLB, MSK, ClickHouse(읽기/쓰기 분리)를 활용하여 수평 확장 및 데이터 파이프라인 안정화를 시도했습니다.
* vCPU 할당량 문제: Auto Scaling Group(ASG)에서 c6i.xlarge 인스턴스 타입으로 프로듀서 ASG를 확장하려 했으나, AWS 계정의 vCPU 한도(64 vCPU) 초과로 인스턴스 시작 실패. Service Quotas에서 Running On-Demand Standard instances 할당량을 256 vCPU로 상향 신청하여 해결 시도했으나, 96 vCPU까지만 상향되어 추가적인 제약 확인의 중요성을 인지했습니다.
* 네트워크 PPS 병목: c6i.xlarge 인스턴스에서 CPU 사용률이 낮음에도 불구하고 RPS가 기대치에 미달하는 현상 발생. 네트워크 PPS 그래프가 급등하고 전송량은 대역폭의 5% 미만이어서 CPU나 대역폭이 아닌 초당 패킷 처리량(PPS)이 병목임을 확인. 네트워크 최적화 인스턴스(c6in.xlarge)로 교체 필요성을 인지했습니다.
* Node.js GC 문제: 5,000 RPS 이상 유지 후 RPS가 급락하는 패턴을 관찰. 이는 Node.js의 가비지 컬렉션(GC) 중 발생하는 Stop-the-World 현상으로 판단. 다량의 요청 처리로 인한 메모리 축적 → GC 발생 → 작업 일시 중지 → 서버 응답 불가 → NLB 타임아웃 및 요청 실패로 이어지는 메커니즘을 분석했습니다.

개발 임팩트:
* 대규모 트래픽 시스템 설계 시 이론적 설계와 실제 운영 간의 괴리를 이해하고, 발생 가능한 병목 지점을 사전에 예측하고 대비하는 능력 향상.
* AWS Service Quotas 관리의 중요성과 잠재적 제약 사항을 파악하고, 리소스 확장 시 필요한 절차 및 검토 사항 습득.
* 네트워크 집약적인 워크로드에 대한 인스턴스 타입 선정 기준 명확화 (컴퓨팅 vs. 네트워크 최적화).
* Node.js 애플리케이션의 GC 메커니즘과 성능 저하의 연관성을 이해하고, 메모리 관리 및 GC 튜닝에 대한 인사이트 획득.

커뮤니티 반응: (원문에서 별도의 커뮤니티 반응은 언급되지 않았습니다.)