문제 배경
SpeakNote를 GCP 환경에서 운영하던 중,
GCP Billing 리포트에서 Network egress 비용이 비정상적으로 급증한 것을 확인했다.
트래픽이 갑자기 폭증한 것도 아니고,
기능을 대규모로 추가한 시점도 아니었기 때문에 단순 사용량 증가로 보기에는 이상한 상황이었다.
조사를 진행하면서 egress 비용 증가의 원인은 하나가 아니라 여러 개라는 것을 알게 되었다.
- Docker 이미지 빌드 시 캐시 없이 반복 빌드되던 문제
- 외부 AI API 연동 구조
- 그리고 GCP 네트워크 아키텍처 자체의 문제
이 글에서는
아직 해결 중인 빌드/코드 레벨 이슈는 제외하고, GCP 아키텍처 재배포로 실제 비용을 줄인 과정만 정리한다.
초기 상황: “같은 서버끼리 통신하는데 왜 egress가 나가지?”
SpeakNote는 다음과 같은 구성으로 배포되어 있었다.
- GCP Load Balancer
- 단일 VM 인스턴스
- VM 내부에서 Docker Compose로
- Frontend
- Spring Boot
- FastAPI
- Redis / DB 컨테이너 실행
겉보기에는 단순한 구조였지만,
문제는 네트워크 트래픽 경로에 있었다.
서비스 간 통신이 모두 Load Balancer를 기준으로 구성되어 있었고,
이로 인해 다음과 같은 일이 발생했다.
같은 VM 내부 컨테이너 간 통신임에도
트래픽이 외부 → LB → 다시 VM 으로 돌아오는 구조
즉, 논리적으로는 내부 통신이지만
GCP 입장에서는 egress + ingress 트래픽으로 계산되는 구조였다.
원인 정리: egress는 “트래픽 양” 문제?
이슈를 분석하면서 가장 크게 느낀 점은 이것이었다.
egress 비용은
“데이터를 많이 보내서” 생기는 게 아니라
“어디로 보내느냐”에 따라 발생한다
기존 구조에서는
- 내부 서비스 호출
- 헬스체크
- WebSocket 연결 유지 트래픽
같은 것들조차
외부 네트워크 경로를 타고 다시 들어오는 구조였고,
이 트래픽들이 모두 비용으로 누적되고 있었다.
해결 전략: 아키텍처 구조 수정
이 문제는 코드 최적화만으로는 해결할 수 없다고 판단했다.
- 요청 수를 줄여도 근본 원인은 그대로
- API 호출을 줄여도 내부 통신 egress는 계속 발생
그래서 선택한 방법은 아키텍처 재배포였다.
핵심 전략은 단순했다
- 내부 통신은 무조건 internal/private 경로로
- 외부 노출이 필요한 엔드포인트만 Load Balancer에 연결
- VM 내부 서비스 간 호출은
- localhost
- docker network
- private IP 기준으로 통일
즉,
“외부 공개용 트래픽”과
“내부 서비스 간 트래픽”을 명확히 분리
핵심 전환점: Global Load Balancer → Regional Load Balancer
egress 비용을 본격적으로 분석하면서,
가장 먼저 의심하게 된 지점은 Load Balancer의 스코프였다.
기존 SpeakNote는 Global HTTP(S) Load Balancer를 사용하고 있었다.
기존 구성의 문제점
Global Load Balancer는 이름 그대로 전 세계 엣지(Edge)를 기준으로 동작한다.
이 자체는 글로벌 서비스를 운영할 때는 매우 강력한 장점이지만,
현재 SpeakNote의 상황에는 과한 선택이었다.
기존 구조에서는 다음과 같은 문제가 있었다.
- 트래픽이 글로벌 엣지 → 리전 → VM 경로를 탑
- 같은 리전에 있는 서비스 간 통신임에도
cross-region / global routing으로 인식될 여지 - 결과적으로 내부 통신 성격의 요청까지
egress 비용으로 잡히는 구조
즉,
“글로벌 확장을 고려한 인프라”가
“단일 리전 서비스”에는 오히려 비용 리스크가 된 상황
변경 결정: Global LB를 버리고 Regional LB로
SpeakNote의 실제 사용 시나리오는 다음과 같았다.
- 단일 리전(GCP 한 리전)에서만 서비스 운영
- 글로벌 트래픽 분산, Anycast 라우팅 필요 없음
- 지연(latency)보다 비용 안정성이 더 중요한 단계
구조 변화 한눈에 보기
Before (Global LB 기반)
상단을 보면 Asia / America / Europe 등
글로벌 엣지(Edge) 위치에서 트래픽이 유입되고 있다.
- 실제 사용자는 대부분 Asia 리전에 있음
- 그럼에도 Global LB 특성상
- 글로벌 엣지를 기준으로 라우팅
- 리전 간 개념이 개입될 여지 존재
즉,
단일 리전 서비스임에도 글로벌 네트워크 비용 구조를 그대로 안고 있는 상태였다.
- Client → Global Edge
- Edge → Region → VM
- 내부 통신도 LB 경유
- egress 발생 지점이 불명확
After (Regional LB 기반)
- Client → Regional LB → VM
- 내부 서비스 간 통신은 private 경로
- 외부/내부 트래픽 역할 분리
- egress 발생 지점 명확
이 결정을 통해 얻은 교훈
- Global LB는 항상 좋은 선택은 아니다
- 서비스 규모·운영 단계에 맞는 인프라 선택이 중요
- GCP egress 비용은
트래픽 양보다 라우팅 구조의 문제인 경우가 많다
SpeakNote에서는
Global → Regional LB 전환이
egress 비용 문제를 해결할 가장 큰 분기점..이었음 좋겠다...