MEP를 구하기 위해 3일: 3.15초에서 233ms

Source: Dev.to

컨텍스트

우리는 마이그레이션 프로그램의 핵심 API에서 심각한 레이턴시 문제로 인해 프로덕션 배포가 차단되는 상황을 다루었습니다:

• MongoDB CPU 사용량 150 % 포화
• 연결 피크가 400에서 1 500으로 증가
• 높은 오류율
• 30 초를 초과하는 요청

적용한 접근 방식

초기 검토

• 안티패턴 및 quick wins 를 식별하기 위한 코드 분석.
• 전체 코드베이스를 스캔하고 안티패턴을 찾아 MongoDB 컬렉션 구조를 문서화한 AI 가속기 사용.
• Cynefin 프레임워크: 문제는 Complex 영역에 해당 → Probe → Sense → Respond 접근법 적용.

1단계: 첫 번째 테스트 시리즈 (Probe)

• 부하 프로파일: 가상 사용자 500명까지 점진적으로 증가, 15분 플래토, 그 후 감소.
• 결과: 504 오류, MongoDB 불안정, 동일 ID를 재사용하는 시나리오(쓰기 충돌), 인덱스 없는 쿼리.
• 대응: 핵심 필드에 인덱스 생성, ID 무작위화, 파라미터 가중 분포 적용, 전용 프리‑프로덕션 환경 구축.
• AI: 무작위화 및 가중 분포가 적용된 테스트 스크립트 자동 생성.

2단계: 수정된 테스트 (Probe)

• 베이스라인: 101 req/s, 오류 2.56 %, P99 = 9.9 s, 평균 = 3.15 s.

쿠버네티스 자동 스케일링

• HPA 개선 및 레플리카 수 증가.
• 결과: 82 req/s, 오류 4.17 %, P99 = 12.3 s, 평균 = 4.09 s → 레플리카 증가가 MongoDB 동시 연결 수를 늘려 역효과 발생.

파드 리소스 확대

• CPU와 RAM 증설.
• 결과: 162 req/s, 오류 0.68 %, P99 = 5.86 s, 평균 = 1.58 s → 처리량 +60 %, 오류 -73 %, 하지만 레이턴시는 여전히 높음(코드 측 문제).

3단계: 코드 및 DB 최적화

• $lookup 을 동시 쿼리 + 애플리케이션 레벨 병합으로 교체.
• O(n²) 루프를 Map/딕셔너리를 활용한 O(n) 로 리팩터링.
• write concern 최적화 (w:1, primary only).
• N+1 패턴 수정($in을 사용한 배치 호출로 전환).
• AI: 특성 테스트 생성, $lookup 파이프라인 재작성, 루프 리팩터링 자동화.

최종 테스트 (Probe)

• 최종 결과: 200 req/s, 오류 ~0 %, P99 = 0.67 s, 평균 = 233 ms.
• 처리량이 베이스라인 대비 두 배 증가했으며, P99 레이턴시가 9.9 s에서 0.67 s로 크게 감소했습니다.

얻은 교훈

• 변경 전후 측정: 직관만으로는 충분하지 않음.
• 대표적인 테스트 시나리오: 비현실적인 시나리오는 오해를 불러일으킴.
• 계층 간 탐색: 인프라, 코드, 데이터베이스가 상호 연결된 시스템임을 인식.
• 적절한 도구: 부하 테스트, 관측성, 프로파일링은 필수.
• AI 에이전트: 사이클을 가속하지만 인간 전문가를 대체할 수는 없음.
• 중단 기준: SLO가 시스템이 “충분히 좋다”는 시점을 정의해 과도한 최적화를 방지함.

보너스

성숙한 Platform Engineering 조직은 최적화 효과가 지속적으로 실현되기 위한 필수 전제 조건입니다.