서비스가 성장하면 반드시 마주치는 숙제가 있습니다.

바로 도메인 구조의 복잡성입니다.

처음엔 example.com 하나만 잘 관리하면 됐습니다.

하지만 시간이 지나면서 서비스가 분화되고 사용자 그룹이 나뉘다 보면 api.example.com, admin.example.com, user.example.com처럼 기능별 하위 도메인이 생겨나기 시작하죠.

문제는, 이렇게 늘어난 도메인 각각이 서로 다른 장비, 다른 서비스, 심지어는 다른 배포 전략을 갖고 운영되어야 할 때입니다. 단순한 DNS 설정만으로는 이런 유연한 라우팅이 어렵습니다.

도메인 기반 라우팅, Azure에서 어떻게 해결했을까?

저희 팀은 최근 해당 복잡성을 겪고 있는 서비스를 Azure로 전환하면서 Azure Traffic Manager를 적용했습니다.

이 글에서는 실제 사례를 바탕으로 다음 내용을 공유드릴까 합니다:

왜 Azure Traffic Manager를 선택했는지
써보니 좋았던 점과 아쉬웠던 점
필요 시 함께 고려할 수 있는 대안

사례 요약: 하위 도메인마다 다른 서비스, 다른 목적

해당 서비스는 10개 이상의 도메인을 운영하고 있었지만, 이해를 돕기 위해 간단히 정리하면 다음과 같습니다:

api.example.com → API Gateway/Management
admin.example.com → 내부 운영/관리 포털
user.example.com → 사용자 웹 프런트엔드

그리고 각 도메인에 대해 다음과 같은 요구사항이 있었습니다:

고가용성 확보를 위해 물리적으로 분리된 2개 이상의 인스턴스 운영
각 인스턴스는 Application Gateway를 통해 독립적인 서비스 엔드포인트 제공
DNS 쿼리 시, 정상 상태의 인스턴스 우선 라우팅, 장애 발생 시 자동 절체
운영자가 직접 도메인별 트래픽 제어 가능 (DNS 직접 수정 없이)

특히 api.example.com은 상황에 따라 같은 버전의 앱을 동시에 운영하거나, A/B 테스트, Blue/Green 배포처럼 다른 버전의 앱을 동시에 운영해야 하는 경우도 있었습니다.

문제는 무엇이었나?

가장 큰 고민은 이 모든 도메인을 하나의 DNS 체계 안에서 어떻게 유연하게 분기할 것인가였습니다.

단순한 로드 밸런싱으로는 부족했습니다. 이유는 다음과 같습니다:

각 도메인이 연결된 서비스가 서로 다른 목적과 성격을 가짐
인스턴스마다 서비스 트래픽이 다르기 때문에 물리 리소스(용량)가 다름
특정 인스턴스만 따로 점검하거나 버전 교체가 필요한 경우 발생

Azure Traffic Manager는?

Azure Traffic Manager는 DNS 기반의 글로벌 트래픽 라우팅 서비스입니다.쉽게 말해, 사용자의 위치나 서비스 상태, 운영자의 설정에 따라 어떤 엔드포인트로 연결할지를 결정해주는 역할을 합니다.

물리적인 인프라 뒤에 위치한 서비스 인스턴스들을 DNS 수준에서 똑똑하게 분기해 주기 때문에,서비스 가용성 향상, 트래픽 분산, 장애 대응에 효율적으로 활용할 수 있습니다.

Traffic Manager는 DNS 레벨에서 동작하므로 실제 트래픽을 전달하거나 SSL 처리하진 않습니다.

아래 흐름과 같이 사용자에게 도메인에 대한 쿼리 결과를 Traffic Manager를 통해 전달한 후, 실제 트래픽은 해당하는 서비스 엔드포인트와 진행됩니다.

Traffic Manager를 제대로 활용하려면, 라우팅 방법(Routing Method)을 이해하는 것이 중요합니다.

Traffic Manager는 다양한 목적에 맞춰 총 6가지 라우팅 방법을 제공합니다. 서비스의 요구사항에 맞게 적절한 방법을 적용하면 됩니다.

라우팅 방법	설명	주요 사용 사례	특징
Priority	우선순위 기반으로 트래픽을 전달	장애 시 백업 인프라 자동 절체	설정된 1순위 → 장애 시 다음 순위로 자동 전환
Weighted	설정한 가중치에 따라 트래픽 분산	A/B 테스트, Blue/Green 배포	트래픽 비율 조절 가능, 배포 실험에 적합
Performance	사용자에게 가장 빠른 응답을 제공하는 엔드포인트로 연결	글로벌 사용자 대상 서비스	네트워크 레이턴시 기준으로 최적 위치 자동 선택
Geographic	사용자의 위치(국가/대륙) 기반 라우팅	국가별 콘텐츠 제공, 규제 대응	지정한 지역별로 특정 엔드포인트 연결 가능
Multivalue	여러 IP 주소를 동시에 반환	간단한 로드밸런싱, 다중 노드 구성	클라이언트가 여러 IP 중 하나를 선택하여 접속
Subnet	클라이언트 IP 범위 기반으로 특정 엔드포인트 지정	사내망 분기, 고객사 전용 경로 구성	특정 IP 블록에만 연결되도록 설정 가능

Azure Traffic Manager 서비스 적용

저희는 Azure Traffic Manager를 아래 방식으로 구성했습니다:

각 하위 도메인(api.example.com 등)을 별도의 Traffic Manager의 Profile로 관리
각 인스턴스의 엔드포인트(Application Gateway)를 Traffic Manager에 등록
라우팅 방법으로는 Priority 를 선택
장애 감지 시, 자동으로 후순위 인스턴스로 절체
운영 중에도 Traffic Manager 포털에서 손쉽게 트래픽 비율 조정 가능

Domain	Traffic Manager 설정
Domain	Profile Name	DNS Name	Routing Methos	Endpoint 1 Name	Endpoint 1 Property	Endpoint 2 Name	Endpoint 2 Property
api.example.com	example-api	tm-api-example.trafficmanager.net	Priority	ep-api-exampe-01	Public IP : pip-appgw-az01-example-01 Priority : 1	ep-api-exampe-02	Public IP : pip-appgw-az01-example-02 Priority : 2
admin.example.com	example-admiin	tm-admin-example.trafficmanager.net	Priority	ep-admin-exampe-01	Public IP : pip-appgw-az01-example-01 Priority : 1	ep-admin-exampe-02	Public IP : pip-appgw-az01-example-02 Priority : 2
user.example.com	example-user	tm-user-example.trafficmanager.net	Priority	ep-user-exampe-01	Public IP : pip-appgw-az01-example-02 Priority : 1	ep-user-exampe-02	Public IP : pip-appgw-az01-example-01 Priority : 2

Endpoint로는 Azure의 여러 유형이 가능합니다. Cloud Service, App Service, App Service Slot, Public IP address가 가능한데 저희는 Application Gateway는 하위에는 WEB, WAS 등을 AKS(Azure Kubernetes Service) 환경으로 제공하고 있기 때문에 Applicaton Gateway의 Public IP address를 Endpoint로 지정합니다.

CNAME 레코드 설정은 필수!

Traffic Manager는 DNS 기반으로 동작하기 때문에, 도메인을 Traffic Manager 프로파일과 연결하는 과정이 필요합니다.이때 사용하는 것이 바로 CNAME 레코드입니다.

CNAME (Canonical Name) 레코드는 도메인 이름을 다른 도메인 이름에 매핑하는 DNS 레코드입니다.

즉, api.example.com을 실제 서비스 IP가 아닌, 다른 도메인 이름(Alias)에 연결할 수 있게 해 줍니다.

역할	도메인
사용자 요청 도메인	api.example.com
Traffic Manager 주소	tm-api-example.trafficmanager.net

위와 같이, DNS 서버에서 api.example.com에 대해 tm-api-example.trafficmanager.net을 CNAME으로 연결하여야 사용자 브라우저에서 도메인 쿼리시 Traffic Manager가 설정된 라우팅 방식(Priority 등)을 기준으로 적절한 서비스 인스턴스로 트래픽을 전달할 수 있습니다.

써보니 좋았던 점

DNS 수준에서 라우팅되므로, 사용자 관점에서 빠르게 절체됨
각 도메인별로 별도 라우팅 정책을 설정할 수 있어 운영 유연성 확보
A/B 테스트나 Blue/Green 배포도 Weighted 모드로 자연스럽게 구성 가능
트래픽 비율 조절, 절체 정책 수정 등이 운영중에도 Azure 포털/CLI로 실시간 조작 가능

아쉬웠던 점 & 고려할 대안

장애 감지는 헬스체크 기준에 따라 약간의 지연이 있음
DNS 캐시 영향으로 사용자 단에 즉각적인 반영이 어려울 수 있음
URI 기반의 복잡한 라우팅 정책이 필요한 경우, Azure Front Door로 병행 구성이 필요함

마무리하며

서비스의 복잡성이 늘어날수록, 그 복잡성을 기술적으로 어떻게 풀어낼지가 중요합니다.

Azure Traffic Manager는 하위 도메인 기반 트래픽 분기, 장애 대응, 배포 전략 분리 등 다양한 요구를 유연하게 처리할 수 있게 도와주는 도구였습니다.

물론 모든 상황에 정답은 아니지만, 글로벌 서비스, 복수 리전 운영, Blue/Green 전략 등을 고민하고 있다면 충분히 고려해볼 만한 선택지입니다.

레이블 추가

도메인 기반 라우팅 서비스를 위한 Azure TrafficManager 적용 사례