Azure DNS Microsoft Azure 인프라를 사용하여 이름 확인을 제공합니다. 이 문서에서는 일반적으로 사용자가 소유하고 있는 도메인에 대해 만들고 인터넷에서 사용할 수 있는 애플리케이션 및 서비스에 대한 레코드를 게시하는 데 사용하는 공용 DNS 영역에 중점을 둡니다. 확인하는 호스트 이름은 공개적으로 액세스할 수 있는 DNS 이름이며, 확인된 IP 주소는 일반적으로 인터넷에서 연결할 수 있는 공용 IP 주소입니다.
Azure DNS 특정 가용성 영역 또는 Azure 지역에 바인딩되지 않은 비연속 서비스입니다.
Azure를 사용하는 경우 안정성은 공유 책임입니다. Microsoft는 복원력 및 복구를 지원하는 다양한 기능을 제공합니다. 이러한 기능이 사용하는 모든 서비스 내에서 작동하는 방식을 이해하고 비즈니스 목표 및 가동 시간 목표를 충족하는 데 필요한 기능을 선택할 책임이 있습니다.
이 문서에서는 Azure DNS 공용 영역이 일시적인 오류, 가용성 영역 오류, 지역 전체 오류, 서비스 중단, 보안 위협 및 잘못된 구성, 포털 및 관리 도구 중단 및 서비스 유지 관리에 대응하는 방법을 설명합니다. 또한 영역 구성을 보호하고 복원하는 방법을 설명하고 주요 SLA(서비스 수준 계약) 요구 사항을 설명합니다.
안정성을 위한 프로덕션 배포 권장 사항
Azure DNS 공용 영역의 프로덕션 배포의 경우 다음 권장 사항에 따라 안정성을 향상시킵니다.
모든 이름 서버에 위임: Azure DNS 각 공용 DNS 영역에 네 개의 이름 서버를 할당합니다. 네 개의 이름 서버를 모두 사용하도록 도메인 위임을 구성합니다. 이 구성은 오류 격리를 제공하며 Azure DNS SLA를 한정하는 데 필요합니다.
적절한 TTL 값을 구성합니다. 클라이언트가 레코드 변경 내용을 받는 빈도와 쿼리 볼륨의 균형을 맞추는 TTL(Time-to-Live) 값을 설정합니다. TTL 값이 낮을수록 클라이언트는 변경 내용을 더 빨리 받을 수 있지만 쿼리 볼륨을 늘릴 수 있습니다. TTL 값이 높을수록 쿼리 볼륨이 줄어들지만 레코드를 변경한 후 장애 조치(failover)를 지연시킬 수 있습니다.
지원되는 Azure 리소스에 별칭 레코드 사용:별칭 레코드는 DNS 확인 중에 기본 Azure 리소스에 대한 변경 내용을 자동으로 반영하고 부실 DNS 레코드를 방지합니다.
안정성 아키텍처 개요
이 섹션에서는 안정성 관점에서 가장 관련성이 높은 서비스가 작동하는 방식의 몇 가지 중요한 측면을 설명합니다. 이 섹션에서는 배포하고 사용하는 일부 리소스 및 기능을 포함하는 논리 아키텍처를 소개합니다. 또한 서비스의 작동 방식에 대한 세부 정보를 제공하는 물리적 아키텍처에 대해서도 설명합니다.
논리 아키텍처
배포하는 기본 리소스는 도메인에 대한 DNS 레코드 집합을 포함하는 영역입니다. 레코드 집합은 DNS 이름을 IP 주소 또는 엔드포인트와 같은 값과 연결합니다. 공용 DNS 영역이 확인하는 이름은 인터넷을 통해 액세스할 수 있습니다.
도메인에 대해 Azure DNS 권한을 가지려면 영역을 만들 때 할당할 Azure 이름 서버에 도메인을 위임합니다. 위임이 준비되면 Azure DNS 지원하는 DNS 레코드 형식에 대한 레코드 집합을 만듭니다. DNS 레코드가 대상 리소스와 동기화된 상태로 유지되도록 공용 IP 주소, Traffic Manager 프로필 및 Azure Front Door 엔드포인트와 같은 Azure 리소스를 참조하는 별칭 레코드를 만들 수도 있습니다.
DNS 확인 중에 재귀 DNS 확인자는 DNS 계층 구조를 따라 영역에 대한 Azure DNS 신뢰할 수 있는 이름 서버에 연결합니다.
Important
Azure DNS 이름을 확인하지만 엔드포인트 상태를 모니터링하거나 애플리케이션 트래픽을 라우팅하지 않습니다. 전체 솔루션의 안정성은 가상 머신 및 부하 분산 장치와 같이 DNS 레코드가 참조하는 리소스의 구성에 따라 달라집니다.
이 문서에서는 이러한 리소스를 다루지 않지만 가용성 구성은 애플리케이션의 복원력에 직접적인 영향을 줍니다. 솔루션에서 Azure 서비스에 대한 안정성 가이드를 검토하여 각 서비스가 안정성 요구 사항을 지원하는 방법을 알아봅니다.
물리적 아키텍처
Azure DNS는 비지역 서비스로 운영되며, 전 세계 여러 Azure 지역에 걸쳐 있는 여러 가용성 영역에 인프라를 배포합니다. 이 디자인을 사용하면 다른 영역 또는 지역의 인프라가 해결 요청에 계속 응답하기 때문에 가용성 영역 또는 지역 중단 중에 Azure DNS 복원력을 유지할 수 있습니다.
Anycast, DNS 및 BGP와 같은 글로벌 인터넷 프로토콜은 들어오는 DNS 확인 요청을 가장 가까운 정상 Azure DNS 인프라로 자동으로 라우팅합니다.
Azure DNS 제공 평면은 Linux에서 실행되는 하나의 스택과 Windows에서 실행되는 하나의 스택으로 이루어진 두 개의 독립적인 제공 스택 전반에서 활성-활성 구성으로 운영됩니다. 이러한 스택은 코드를 공유하지 않으며 기본 하드웨어도 공유하지 않습니다. 독립적이므로 한 스택에 영향을 주는 버그, 취약성 또는 실패는 다른 스택에 영향을 주지 않습니다. 이러한 독립성을 통해 단일 실패 지점으로 인한 전체 서비스 중단의 위험을 줄이고 제로 데이 취약성의 특정 클래스로부터 보호하는 데 도움이 됩니다.
일시적인 오류에 대한 복원력
일시적인 오류는 구성 요소에서 짧고 간헐적인 오류입니다. 클라우드와 같은 분산 환경에서 자주 발생하며 작업의 일반적인 부분입니다. 일시적인 오류는 짧은 시간 후에 스스로 수정됩니다. 애플리케이션은 일반적으로 영향을 받는 요청을 다시 시도하여 일시적인 오류를 처리할 수 있는 것이 중요합니다.
모든 클라우드 호스팅 애플리케이션은 클라우드 호스팅 API, 데이터베이스 및 기타 구성 요소와 통신할 때 Azure 임시 오류 처리 지침을 따라야 합니다. 자세한 내용은 일시적 결함 처리를 위한 권장 사항을 참조하세요.
Azure DNS 글로벌 DNS 인프라를 통해 일시적인 오류를 처리합니다.
DNS 확인 중에 일시적인 오류가 발생하는 경우 클라이언트 또는 중간 확인자는 구성된 DNS 재시도 동작에 따라 다시 시도해야 합니다. 일반적으로 2~5초는 DNS 클라이언트에 충분한 시간 제한입니다.
각 DNS 레코드의 수명(TTL)도 솔루션이 장애를 처리하는 방식에 영향을 줍니다. TTL이 매우 낮은 경우 클라이언트는 Azure DNS 위해 더 많은 요청을 수행해야 하며 일시적인 오류가 발생할 가능성이 더 큽니다. TTL이 매우 높은 경우 다른 IP 주소로 리디렉션해야 하는 백 엔드 서버의 실제 오류가 발생하는 경우 클라이언트는 TTL이 만료될 때까지 장애 조치(failover)가 지연될 수 있습니다. 가용성, 대기 시간 및 응답성의 균형을 맞추기 위해 TTL을 신중하게 구성합니다.
가용성 영역 오류에 대한 복원력
가용성 영역은 Azure 지역 내에서 물리적으로 별도의 데이터 센터 그룹입니다. 한 영역이 실패하면 서비스가 나머지 영역 중 하나로 전환될 수 있습니다.
Azure DNS 비지정 서비스로 작동합니다. Microsoft 인프라를 여러 Azure 지역의 여러 가용성 영역에 분산하고 해당 인프라 전체에서 공용 DNS 영역에 변경 내용을 복제합니다. 가용성 영역을 선택하거나 영역 중복성을 구성하지 않습니다. 가용성 영역이 중단되는 동안 다른 영역 또는 지역의 인프라는 해결 요청에 계속 응답합니다.
VM(가상 머신)과 같은 단일 가용성 영역에 배포하는 리소스가 영역 실패 시 사용할 수 없게 되면 Azure DNS 엔드포인트 상태를 모니터링하지 않으므로 리소스의 구성된 IP 주소를 계속 반환합니다. 정상 상태인 영역의 리소스로 장애 조치한 경우 클라이언트가 해당 정상 리소스를 사용하도록 DNS 레코드를 업데이트할 책임은 사용자에게 있습니다. 또는 정상 영역의 VM으로 트래픽을 전송하는 영역 중복 부하 분산 장치 뒤에 리소스를 배치합니다.
지역 전체 오류에 대한 복원력
영역 데이터는 전역적으로 사용 가능하고 여러 Azure 지역에 배포되므로 DNS 영역은 지역 중단에 대해 복원력이 있습니다. 지역에 중단이 있는 경우 가상 네트워크 및 VM과 같은 해당 지역에 배포한 리소스를 사용할 수 없지만 Azure DNS 영역의 레코드를 계속 확인합니다.
재해 복구를 위해 여러 지역 간에 전환해야 하는 솔루션이 있는 경우 Azure Traffic Manager 또는 Azure Front Door 사용하는 것이 좋습니다. 이러한 서비스는 지역이 비정상인 경우 사용할 수 있는 자동화된 장애 조치 기능을 제공합니다.
보안 위협 및 잘못된 구성에 대한 복원력
보안 공격 및 구성 오류는 DNS 영역에 대한 가장 중요한 안정성 위험 중 두 가지입니다. 특히 DNS 확인을 대상으로 하는 여러 종류의 공격 및 우발적인 잘못된 구성은 워크로드를 심각하게 방해할 수 있습니다.
공용 DNS 영역과 관련된 포괄적인 보안 지침은 Azure DNS 배포 보안 및 DNS 영역 및 레코드 보호를 참조하세요.
서비스 중단에 대한 복원력
Azure DNS 애플리케이션이 특정 조건을 충족하는 경우 100% 가용성 SLA를 사용하는 매우 복원력 있는 서비스입니다. 서비스 중단은 매우 드문 일이지만 네트워크 문제 또는 다른 인프라의 문제로 인해 Azure DNS 서비스에 대한 연결이 중단됩니다.
Azure DNS 복원력은 부분적으로 전역적으로 분산된 활성 활성 서비스 평면 아키텍처 때문입니다.
여러 이름 서버 사용
Azure DNS 각 공용 DNS 영역에 네 개의 이름 서버를 할당합니다. 도메인을 위임할 때 네 개의 이름 서버를 모두 구성합니다. 해결 프로그램이 한 이름 서버에 연결할 수 없는 경우 다른 이름을 쿼리할 수 있습니다.
서비스 중단 모니터링
Azure Service Health 사용하여 Azure DNS 상태를 모니터링합니다. 서비스 인시던트에 대해 알리도록 Service Health 경고를 구성합니다.
서비스 중단 테스트
Azure Chaos Studio 일부 유형의 테스트 워크로드 내에서 DNS 확인 오류를 시뮬레이션하는 오류를 제공합니다. 이러한 오류는 Azure DNS 중단을 트리거하지 않습니다. Chaos Studio 에이전트는 DNS 오류 오류를 제공하고 AKS Chaos Mesh는 DNS 비정상 상황 기능을 제공합니다. 이러한 오류를 사용하여 부분 네트워크 오류와 같이 DNS 확인이 실패할 때 애플리케이션 및 인프라가 어떻게 반응하는지 테스트합니다.
포털 및 관리 도구 중단에 대한 복원력
Azure 포털에서 공용 DNS 영역을 관리하는 경우, 특히 중단 중에 영역을 다시 구성해야 하는 경우 포털에 액세스할 수 없는 시나리오에 대한 대체 관리 경로를 준비합니다.
Azure 포털을 사용할 수 없는 경우 Azure CLI, Azure PowerShell 또는 Bicep 또는Terraform과 같은 IaC(인프라)를 사용하여 공용 DNS 영역을 관리합니다. 이러한 도구는 Azure 포털의 성능이 저하된 경우에도 계속 작동합니다.
백업 및 복원
Azure DNS 상태 비저장 서비스입니다. 공용 DNS 영역에 대한 관리되는 백업 또는 특정 시점 복원을 제공하지 않습니다.
전체 Azure 리소스 구성을 유지하려면 Bicep 또는 Terraform과 같은 IaC를 사용하여 공용 DNS 영역을 정의하고 원본 제어에 정의를 저장합니다. 정의를 사용하여 구성을 다시 배포할 수 있도록 정기적으로 정의를 테스트합니다.
추가 레코드 수준 복구 옵션으로 BIND 호환 영역 파일을 내보냅니다. 영역 파일 가져오기에는 제한 사항이 있으며 모든 Azure 특정 리소스 설정을 유지하지 않으므로 내보낸 영역 파일을 유일한 복구 아티팩트로 사용하지 마세요. 문서화된 가져오기 제한을 검토하고 영역을 복원한 후 레코드를 확인합니다.
서비스 유지 관리에 대한 복원력
Microsoft는 정기적으로 서비스 업데이트를 적용하고 다른 유지 관리를 수행합니다. Azure 플랫폼은 이러한 활동을 자동으로 처리하여 유지 관리가 원활하고 투명하도록 합니다. Azure Service Health 계획된 유지 관리를 통해 조언을 받지 않는 한 유지 관리 이벤트 중에 가동 중지 시간이 예상되지 않습니다.
서비스 수준 약정
Azure 서비스에 대한 SLA(서비스 수준 계약)는 각 서비스의 예상 가용성과 솔루션이 가용성 기대치를 달성하기 위해 충족해야 하는 조건을 설명합니다. 자세한 내용은 온라인 서비스에 대한 SLA를 참조하세요.
Azure DNS 특정 조건이 충족되는 한 유효한 DNS 쿼리 응답에 대해 100% 가용성 SLA를 제공합니다. 이러한 조건에는 60초 이상 연속으로 실패한 요청을 반복적으로 다시 시도하고 Azure DNS 영역에 할당하는 모든 이름 서버를 사용하는 것이 포함됩니다. 자세한 조건은 SLA 문서를 검토하세요.