피크 타임 Pod 245개를 100여개로 — DynamoDB SDK v2 전환으로 Go 서버 CPU 절반 줄이기

버즈빌 Supply 그룹이 저녁 피크 타임마다 Pod가 245개로 치솟는 문제를 Pyroscope 프로파일링으로 추적해 DynamoDB wrapper 라이브러리 내부의 AWS SDK v1 unmarshal이 CPU 병목임을 밝히고, guregu/dynamo v2 전환으로 요청당 CPU를 59% 줄이고 월 비용을 약 4,000달러 절감한 사례다.

핵심 포인트

Pyroscope flame graph에서 guregu/dynamo가 전체 CPU의 절반 가까이를 차지했으며, 원인은 내부 AWS SDK v1의 reflection 기반 JSON unmarshal이었다.
AWS SDK v2는 타입별로 struct를 나눈 union 형태와 생성된 serializer를 사용해 reflection 비용이 대폭 감소한다.
코드 변경은 import 경로 교체 수준으로 단순했으나 효과는 극적이었다.
요청당 CPU -59%, 피크 타임 Pod 245개→109개(-55.3%), 일 비용 약 400달러→250달러 수준으로 절감.
핵심 교훈: 문제 인식과 원인 파악은 여전히 엔지니어링이 필요한 영역이다.

상세 정리

배경: Supply 그룹 Go 앱이 저녁 피크마다 Pod 200여 개 이상으로 확장. 시간당 7천만 건 처리량이 원인으로 의심됐으나 Pyroscope로 확인하니 DynamoDB 클라이언트가 진짜 원인이었다.
Pyroscope 발견: flame graph에서 guregu/dynamo가 CPU의 절반 가까이 점유. 네트워크 I/O나 DynamoDB latency·throttling은 관측되지 않았다.
원인 파악: guregu/dynamo v1은 HTTP 요청·응답 파싱을 AWS SDK v1에 위임. SDK v1의 reflection 기반 JSON unmarshal 비용이 wrapper로 집계된 것.
AWS SDK v1 구조: AttributeValue를 하나의 큰 struct에 모든 타입을 포인터 필드로 포함. 값 읽을 때마다 어떤 필드가 채워졌는지 reflection으로 확인하는 비용이 반복된다.
AWS SDK v2 구조: 타입별로 struct를 분리한 union 형태(AttributeValueMemberS/N/M 등). switch문 기반 타입 분기로 reflection 없이 처리하며, 서비스 모델 기반 생성된 serializer를 사용한다.
코드 변경: import 경로를 github.com/guregu/dynamo에서 github.com/guregu/dynamo/v2로 교체, AllWithContext를 All(ctx)로 변경, 초기화는 v2 DynamoDB 클라이언트로 교체. 카나리 배포로 점진 적용.
즉시 효과(배포 전후 30분 비교): Pyroscope CPU 샘플 18h→7h(-61%), 요청당 CPU 2.149ms→0.876ms(-59.2%), AWS SDK v1 JSON unmarshal 비중 46.97%→2.55%.
장기 효과(4일 비교): CPU avg -46.6%, p95 -44.4%, HPA desired p95 245→109개(-55.3%). 요일 통제 비교에서도 Pod 217개→96개, CPU 401.1→203.7 cores 확인.
비용 절감: 일 비용 400달러대→250달러 수준, 월 기준 약 3,500~4,500달러 절감.