1. 개요
이번에 학원에서 미니프로젝트 2를 진행하면서 API 응답 속도가 계속 3초 이상 걸리는 기이한 현상을 겪었다.
코드 상의 문제인가 싶어 쿼리를 최적화하고, 인덱스를 재점검하는 등 할 수 있는 방법은 다 시도해 보았지만 속도는 전혀 개선되지 않았다.
대체 왜 이렇게 느린 걸까 고민하던 중... 원인은 상상도 못 한 곳에 있었다.
2. 문제 원인 분석
어이없게도 문제는 Azure 리전(Region) 설정이었다.
- Azure App Service (웹 앱): Korea Central (한국 중부)
- Azure DocumentDB (DB): Brazil South (브라질 남부)
아무 생각 없이 DB 인스턴스를 생성할 때 리전 설정을 확인하지 못해 지구 반대편에 생성되어 있던 것이었다.
왜 3초나 걸렸을까?
- 빛의 속도 한계 (RTT): 한국(Korea Central)에서 브라질(Brazil South) 데이터센터까지 네트워크 패킷이 왕복하는 데만 물리적으로 약 300ms ~ 350ms가 소요된다.
- 지연시간의 누적: API 하나를 처리할 때 Azure DocumentDB 조회가 3~4번만 일어나도, 다른 로직을 제외하고 오직 네트워크 대기시간으로만 1초~1.5초 이상이 순식간에 누적된다.
- 여기에 애플리케이션의 비즈니스 로직과 데이터 처리 시간까지 합쳐지면서 최종 응답 시간이 3초를 훌쩍 넘어버렸던 것이다.
💡 아무리 백엔드 코드나 쿼리를 최적화해도, 물리적 거리가 만들어내는 네트워크 레이턴시(Network Latency)의 벽은 넘을 수 없다!
3. 해결 과정
- 기존 브라질 리전에 있던 Azure DocumentDB의 데이터를 정리/백업.
- App Service가 위치한 Korea Central (한국 중부) 리전에 맞춰 DocumentDB를 새로 생성하고 마이그레이션 진행.
결과 비교
- 기존 (Korea Central - Brazil South): DB 네트워크 Latency 약 300ms~350ms ➔ API 평균 응답시간 3초 이상
- 개선 (Korea Central - Korea Central): 동일 리전 내 Latency 1ms~5ms ➔ API 평균 응답시간 0.x초대 (정상 복구)
4. 회고
- 인프라 기본의 중요성: Azure에서 자원을 생성할 때 Resource Group이나 Region 배치가 서비스 전체 성능에 얼마나 치명적인 영향을 주는지 몸소 체감했다.
- 디버깅 시야 확장: 성능 문제가 발생했을 때 애플리케이션 내부(코드, DB)만 파고들 것이 아니라, 인프라 간 통신 경로와 물리적 위치도 반드시 주요 체크리스트에 포함해야 함을 배웠다.
