CDN에 대하여 공부를 하던 중, 직접 한번 구현해보면 재밌겠다는 생각이 들었습니다. 물리적 거리에 따른 지연 시간(Latency) 문제가 얼마나 있는지, 이를 해결하기 위해 CDN을 왜 사용해야 하는지 알아보기 위해 Google Cloud Platform(GCP)을 활용하여 인프라를 구축한 과정을 기록해보고자 합니다.
1.개요
이번 인프라 구축의 핵심은 "지리적 제약을 극복하는 글로벌 확장성"입니다. 로컬 서버에 의존할 경우 해외 사용자에게 치명적인 네트워크 지연이 발생하므로, 이를 해결하기 위해 다음 기술 스택을 도입했습니다.
- Compute Engine: 각 리전별 VM 인스턴스 배포
- Managed Instance Groups (MIG): 인프라의 자동 확장성과 가용성 보장
- Global External Application Load Balancer: 전 세계 트래픽을 효율적으로 분산
- Cloud CDN: 정적 콘텐츠의 엣지 캐싱을 통한 성능 극대화
2. 단계별 구축 과정
1단계: 인프라의 표준화 (Instance Template)
먼저, 5개 국가(서울, 일본-도쿄, 미국-아이오와, 유럽-벨기에, 호주-시드니)에 배포할 서버의 표준 설계도를 작성했습니다. 인스턴스 템플릿은 전역(Global)으로 설정하여 리전에 구애받지 않고 동일한 사양의 VM을 생성하도록 구성했습니다.
Key Point: 템플릿은 머신 사양과 OS 이미지만 관리하며, 네트워크 및 배치 정보는 관리형 인스턴스 그룹(MIG) 생성 시 설정합니다.
2단계: 관리형 인스턴스 그룹(MIG) 배포
각 리전에 MIG를 생성하여 인프라를 배포했습니다. 각 VM에는 Nginx 웹 서버를 설치하여 로드밸런서가 정상적으로 상태를 체크(Health Check)할 수 있도록 했습니다.
# 각 VM 인스턴스에 접속하여 웹 서버 설치
sudo apt update && sudo apt install nginx -y3단계: 로드밸런서와 CDN 통합
글로벌 외부 애플리케이션 로드밸런서를 생성하여 하나의 고정 IP로 전 세계 트래픽을 처리하도록 했습니다.
- 백엔드 서비스: 5개 리전의 MIG를 백엔드로 등록했습니다.
- Cloud CDN: 반드시 '사용' 옵션을 체크하여 엣지 서버 캐싱 기능을 활성화했습니다.
- 방화벽 규칙: 로드밸런서의 상태 확인(Health Check) 트래픽이 허용되도록 130.211.0.0/22 및 35.191.0.0/16 대역을 허용했습니다.
3. 성능 측정 및 데이터 분석
구축 후 실제 지연 시간 개선율을 측정했습니다. 결과는 물리적 거리가 멀수록 극적인 성능 향상을 보였습니다.
| 접속 국가 | 직접 접속 (ms) | CDN 사용 (Cache Hit, ms) | 개선율 (%) |
| 대한민국 (서울) | 0.320 | 44 | - |
| 미국 (아이오와) | 172.186 | 44 | 74.45% |
| 유럽 (벨기에) | 252.648 | 44 | 82.58% |
데이터 해석: 서울처럼 원본 서버와 가까운 지역은 CDN 오버헤드가 발생할 수 있으나, 미국/유럽 등 원거리 사용자의 경우 지연 시간을 80% 이상 단축하여 사용자 경험을 크게 개선했습니다.
4. 트러블슈팅
- ERR_CONNECTION_TIMED_OUT: 초기 접속 불가 문제는 방화벽 규칙에서 80번 포트가 허용되지 않아 발생했습니다. allow-http 규칙을 추가하여 해결했습니다.
- CDN 캐싱 확인: 응답 헤더의 Via: 1.1 google 및 Server: nginx 헤더를 통해 요청이 로드밸런서와 CDN 인프라를 거쳐 정상 서빙됨을 확인했습니다.
5. 프로젝트 결론 및 향후 계획
이번 프로젝트를 통해 글로벌 네트워크 인프라의 동작 원리를 깊이 이해할 수 있었습니다. 로드밸런서의 Anycast IP가 어떻게 사용자를 가장 가까운 엣지 서버로 유도하는지, 그리고 Cloud CDN이 어떻게 원본 서버의 부하를 획기적으로 줄이는지 직접 체감했습니다.
향후에는 도메인 연결을 통한 HTTPS 적용으로 보안까지 강화해보고자 합니다.
단순한 서버 배포를 넘어, 사용자의 위치까지 고려한 진정한 클라우드 네이티브 아키텍처를 경험한 소중한 시간이었습니다.