Azure Traffic Manager 우선순위 라우팅: 장애 전환이 바로 보이지 않는 이유

주 서비스가 멈추면 보조 서비스로 넘어가도록 Azure Traffic Manager의 Priority 라우팅을 설정했다. 그런데 한 사용자는 이미 보조 사이트를 보고, 다른 사용자는 한동안 주 사이트로 향한다. “장애 전환이 실패했나?”라고 단정하기 전에 두 단계를 나눠 봐야 한다. Traffic Manager가 어떤 엔드포인트를 정상으로 판단했는지, 그리고 사용자의 DNS 조회 결과가 언제 새로 반영되는지다.

Priority는 어떤 엔드포인트를 고를까?

도식의 상태 검사는 Traffic Manager가 어느 엔드포인트를 DNS 응답으로 고를지 결정한다. 이미 받은 DNS 응답의 캐시 만료와 보조 서비스의 실제 준비 상태는 그 선택 뒤에 별도로 확인해야 한다.

Priority 방식은 정상인 엔드포인트 가운데 우선순위가 가장 높은 곳을 선택하는 주·보조 구성에 맞다. 예를 들어 주 서비스의 우선순위를 1, 보조 서비스를 2로 두고 둘 다 정상이라면 주 서비스가 선택된다. 주 서비스가 모니터링에서 비정상으로 판단되면 보조 서비스가 선택 대상이 된다. 숫자는 설명용이며 특정 운영 설정을 재현한 것이 아니다.

이 표는 순서를 이해하기 위한 간단한 예다. 실제 응답에는 엔드포인트의 활성화 여부와 모니터링 설정이 함께 영향을 준다. 보조 서비스 자체가 준비되지 않았다면 우선순위만 낮게 배정해 두어도 안전한 복구 경로가 생기지 않는다.

정상 판정과 DNS 반영은 같은 시각에 일어나지 않는다

Traffic Manager는 애플리케이션 요청을 직접 중계하는 로드 밸런서가 아니라 DNS 기반 라우팅 서비스다. 엔드포인트의 정상 여부를 감시한 뒤 DNS 응답에서 적절한 대상을 안내한다. 그래서 장애가 일어난 순간의 사용자 연결을 강제로 다른 곳으로 옮기는 기능으로 이해하면 안 된다.

이 DNS 응답·기존 연결의 경계는 Microsoft의 엔드포인트 모니터링 설명에서도 확인할 수 있다.

점검할 때는 먼저 Traffic Manager가 주 엔드포인트를 비정상으로 판단했는지 확인한다. 그다음 새 DNS 조회가 어느 대상을 받는지, 사용자의 기존 DNS 캐시가 여전히 이전 대상을 가리키는지 나눠 본다. 두 사용자가 다른 화면을 보는 것만으로 모니터링이 고장 났다고 단정할 수는 없다. 기존 연결이나 클라이언트 쪽 캐시도 관찰 결과에 영향을 준다.

DNS TTL을 지나치게 짧게 잡으면 더 빨리 바뀔 것 같지만, 모든 클라이언트의 동작을 한 값으로 보장할 수는 없다. 모니터링 간격, 장애 판정 조건, DNS TTL, 애플리케이션의 실제 준비 시간을 함께 측정해야 한다. 교육 자료의 우선순위 개념만으로 특정 초 단위 전환 시간을 약속할 수 없으므로, 이 글도 고정 시간을 제시하지 않는다.

보조 사이트가 선택돼도 어떤 준비가 필요할까?

DNS가 보조 사이트로 향해도 보조 사이트에 필요한 데이터와 의존 서비스가 준비되지 않았다면 사용자 입장에서는 여전히 장애다. 주·보조가 같은 데이터를 읽는지, 로그인 세션은 어떻게 이어지는지, 쓰기 요청을 어느 쪽에서 받는지 별도로 설계해야 한다. Traffic Manager의 라우팅은 이런 애플리케이션 상태를 자동 복제하지 않는다.

검증은 정상 상태에서 주 서비스가 선택되는지 확인하는 것부터 시작한다. 그다음 통제된 테스트에서 주 서비스의 모니터링 상태가 비정상으로 바뀌었는지, 새 DNS 조회가 보조 서비스를 가리키는지, 보조 애플리케이션의 핵심 요청이 실제로 성공하는지 차례로 기록한다. 마지막에는 주 서비스 복귀 시 다시 어느 쪽이 선택되는지도 확인한다. 테스트 전에는 장애 영향과 복귀 절차를 정해야 한다.

핵심 요약: 라우팅 전환과 서비스 복구를 따로 본다

Priority는 정상인 엔드포인트 중 가장 높은 우선순위를 선택한다. 그러나 정상 판정, DNS 캐시 반영, 보조 애플리케이션의 준비는 각각 다른 문제다. 장애 전환이 느려 보일 때는 모니터링 상태 → 새 DNS 응답 → 사용자 연결과 애플리케이션 동작 순서로 나누어 확인하자.