국가 간 API 통신 이슈 해결하기
중국 내 지역 간 물리적 거리로 인한 API 통신 지연 문제를 프록시 서버와 가속화망으로 해결한 과정을 공유합니다.
서비스를 오픈하고 얼마 지나지 않아 고객에게 화면이 너무 늦게 뜬다는 CS가 들어왔습니다.
처음엔 서버 코드의 이슈인지 파악하기 위해 API들의 실행 시간을 체크했습니다. 하지만 API 상에는 문제가 없었고 DB slow query도 아니었습니다.
혹시 앱 페이지를 로드할 때 이미지를 가져오는 부분이 문제일지 모른다고 생각했습니다. 이미지들은 서울 리전의 스토리지에 업로드되어 있고 앱에선 그 스토리지를 직접 바라보고 있었기 때문입니다. HTTP/1.1 프로토콜을 사용하고 있어 Network 요청의 수도 제한되어 있었습니다.
CDN을 도입하고 HTTP/2 프로토콜을 사용하여 해결했다고 생각했습니다.
하지만 CS는 여전했다
문제의 원인을 고민하던 중 떠오른 부분이 있었습니다. 현재 API 서버는 상해 리전에서 운영 중이고, 요청한 유저의 위치는 광저우였습니다.
상해와 광저우 사이의 거리는 육지로 1467km입니다.
상해-광저우 간 거리
상해와 서울 간의 거리는 866km입니다.
상해-서울 간 거리
같은 국가 내 지역 간 거리가 국가 간 거리보다 먼 경우가 발생한 거죠.
해결 방안: 지역별 프록시 서버 + 가속화망
중국을 4등분하여 광저우, 베이징, 충칭, 상해에 프록시 서버를 세팅합니다.
중국 4개 주요 지역 분할
각 지역에서 오는 요청을 해당 리전의 프록시 서버로 보내고, 프록시 서버는 Tencent Cloud의 CCN(가속화망)을 통해 상해로 요청을 전달합니다.
프록시 서버 + 가속화망 아키텍처
Before:
1
2
사용자(광저우) → 공용 인터넷 → 상해 API 서버
(물리적 거리: 1467km, 높은 레이턴시)
After:
1
2
사용자(광저우) → 광저우 프록시 서버 → CCN 가속화망 → 상해 API 서버
(최적화된 경로, 낮은 레이턴시)
교훈
근본 원인 파악의 중요성: 표면적 해결책(CDN, HTTP/2)이 아닌 근본 원인(물리적 거리) 파악이 핵심이었어요.
CDN vs CCN:
- CDN: 정적 콘텐츠 캐싱에 효과적
- CCN: API 통신 같은 동적 요청에 효과적
지역적 특성 고려: 중국처럼 영토가 넓은 국가는 리전 전략이 중요해요.