이 참조 아키텍처는 온-프레미스 및 Microsoft Azure에서 호스트되는 워크로드의 이름을 확인하도록 하이브리드 DNS(Domain Name System) 솔루션을 설계하는 방법을 보여 줍니다. 이 아키텍처는 온-프레미스 및 공용 인터넷에서 연결하는 사용자 및 기타 시스템에 적합합니다.
아키텍처
이 아키텍처의 Visio 파일을 다운로드합니다.
워크플로
이 아키텍처는 다음과 같은 구성 요소로 구성됩니다.
- 온-프레미스 네트워크. 온-프레미스 네트워크는 Azure ExpressRoute 또는 VPN(가상 사설망) 연결을 통해 Azure에 연결되는 단일 데이터 센터를 나타냅니다. 이 시나리오에서 다음 구성 요소는 온-프레미스 네트워크를 구성합니다.
- DNS 서버. 이러한 서버는 확인자/전달자 역할을 하는 DNS 서비스가 설치된 두 개의 서버를 나타냅니다. 이러한 DNS 서버는 DNS 서버로 사온-프레미스 네트워크의 모든 컴퓨터에 사용됩니다. 이러한 서버에서 Azure 및 온-프레미스의 모든 엔드포인트에 대한 레코드를 만들어야 합니다.
- 게이트웨이. 게이트웨이는 Azure에 연결하는 데 사용되는 VPN 디바이스 또는 ExpressRoute 연결을 나타냅니다.
- 허브 구독. 허브 구독은 여러 Azure 호스팅 워크로드에서 공유되는 연결, 관리 및 네트워킹 리소스를 호스트하는 데 사용되는 Azure 구독을 나타냅니다. 이러한 리소스는 엔터프라이즈 규모 아키텍처에서 설명한 대로 여러 구독으로 분할할 수 있습니다.
참고
허브 가상 네트워크는 가상 WAN(광역 네트워크) 허브로 대체할 수 있습니다. 이 경우 DNS 서버는 다른 Azure VNet(가상 네트워크)에서 호스트되어야 합니다. 엔터프라이즈 규모 아키텍처에서 해당 VNet은 ID 구독이라는 자체 구독에서 유지 관리됩니다.
- Azure Bastion 서브넷. 허브 가상 네트워크의 Azure Bastion 서비스는 유지 관리를 위해 공용 인터넷에서 허브 및 스포크 VNet의 VM(가상 머신)으로 원격으로 연결하는 데 사용됩니다.
- 프라이빗 엔드포인트 서브넷. 프라이빗 엔드포인트 서브넷은 허브에 피어링되지 않은 VNet의 Azure 호스팅 워크로드에 대한 프라이빗 엔드포인트를 호스트합니다. 이 유형의 연결이 끊긴 VNet에서는 해당 IP 주소가 Azure 및 온-프레미스에서 사용되는 다른 IP 주소와 충돌할 수 있습니다.
- 게이트웨이 서브넷. 게이트웨이 서브넷은 온-프레미스 데이터 센터에 대한 연결을 다시 제공하는 데 사용되는 Azure VPN 또는 ExpressRoute 게이트웨이를 호스트합니다.
- 공유 서비스 서브넷. 공유 서비스 서브넷은 여러 Azure 워크로드 간에 공유되는 서비스를 호스트합니다. 이 시나리오에서 이 서브넷은 DNS 서버로도 사용되는 Windows 또는 Linux를 실행하는 가상 머신을 호스트합니다. 이러한 DNS 서버는 온-프레미스 서버와 동일한 DNS 영역을 호스트합니다.
- 연결된 구독. 연결된 구독은 가상 네트워크와 온-프레미스 네트워크에 다시 연결해야 하는 워크로드 컬렉션을 나타냅니다.
- VNet 피어링. 이 구성 요소는 허브 VNet으로 다시 연결되는 피어링 연결입니다. 이 연결을 사용하면 온-프레미스 네트워크에서 연결하고 허브 VNet을 통해 다시 연결할 수 있습니다.
- 기본 서브넷. 기본 서브넷에는 샘플 워크로드가 포함됩니다.
- web-vmss. 이 샘플 가상 머신 확장 집합은 온-프레미스, Azure 및 공용 인터넷에서 액세스할 수 있는 Azure의 워크로드를 호스트합니다.
- 부하 분산 장치. 부하 분산 장치는 일련의 VM에서 호스트하는 워크로드에 대한 액세스를 제공합니다. 기본 서브넷에 있는 이 부하 분산 장치의 IP 주소는 Azure 및 온-프레미스 데이터 센터에서 워크로드에 액세스하는 데 사용해야 합니다.
- AppGateway 서브넷. 이 서브넷은 Azure Application Gateway 서비스에 필요한 서브넷입니다.
- AppGateway. Application Gateway는 공용 인터넷의 사용자에게 기본 서브넷의 샘플 워크로드에 대한 액세스를 제공합니다.
- wkld1-pip. 이 주소는 공용 인터넷에서 샘플 워크로드에 액세스하는 데 사용되는 공용 IP 주소입니다.
- 연결이 끊긴 구독. 연결이 끊긴 구독은 온-프레미스 데이터 센터로 다시 연결할 필요가 없고 프라이빗 링크 서비스를 사용하는 워크로드 컬렉션을 나타냅니다.
- PLSSubnet. 프라이빗 링크 서비스 서브넷(PLSSubnet)에는 연결된 구독에서 호스트되는 워크로드에 대한 연결을 제공하는 하나 이상의 프라이빗 링크 서비스 리소스가 포함됩니다.
- 기본 서브넷. 기본 서브넷에는 샘플 워크로드가 포함됩니다.
- web-vmss. 이 샘플 가상 머신 확장 집합은 온-프레미스, Azure 및 공용 인터넷에서 액세스할 수 있는 Azure의 워크로드를 호스트합니다.
- 부하 분산 장치. 부하 분산 장치는 일련의 VM에서 호스트하는 워크로드에 대한 액세스를 제공합니다. 이 부하 분산 장치는 프라이빗 링크 서비스에 연결되어 Azure 및 온-프레미스 데이터 센터에서 오는 사용자에게 액세스를 제공합니다.
- AppGateway 서브넷. 이 서브넷은 Application Gateway 서비스에 필요한 서브넷입니다.
- AppGateway. Application Gateway는 공용 인터넷의 사용자에게 기본 서브넷의 샘플 워크로드에 대한 액세스를 제공합니다.
- wkld2-pip. 이 주소는 공용 인터넷에서 샘플 워크로드에 액세스하는 데 사용되는 공용 IP 주소입니다.
- Azure Bastion 서브넷. 연결이 끊긴 가상 네트워크의 Azure Bastion 서비스는 유지 관리를 위해 공용 인터넷에서 허브 및 스포크 VNet의 VM으로 원격 이동하는 데 사용됩니다.
구성 요소
Virtual Network. Azure Virtual Network(VNet)는 Azure의 프라이빗 네트워크의 기본 구성 요소입니다. VNet을 사용하면 Azure VM(Virtual Machines)과 같은 다양한 형식의 Azure 리소스가 서로, 인터넷 및 특정 온-프레미스 네트워크와 안전하게 통신할 수 있습니다.
Azure Bastion. Azure Bastion은 공용 IP 주소를 통한 노출 없이 VM(가상 머신)에 대한 보다 안전하고 원활한 RDP(원격 데스크톱 프로토콜) 및 SSH(Secure Shell Protocol) 액세스를 제공하는 완전 관리형 서비스입니다.
VPN Gateway. VPN 게이트웨이에서 공용 인터넷을 통해 Azure 가상 네트워크와 온-프레미스 위치 간에 암호화된 트래픽을 보냅니다. VPN Gateway를 사용하여 Microsoft 네트워크를 통해 Azure 가상 네트워크 간에 암호화된 트래픽을 보낼 수도 있습니다. VPN Gateway는 특정 유형의 가상 네트워크 게이트웨이입니다.
Private Link. Azure Private Link는 가상 네트워크에서 Azure PaaS(Platform as a Service), 고객 소유 또는 Microsoft 파트너 서비스에 대한 프라이빗 연결을 제공합니다. 네트워크 아키텍처를 간소화하고 퍼블릭 인터넷에 대한 데이터 노출을 예방하여 Azure에서 엔드포인트 간 연결을 보호합니다.
Application Gateway. Azure Application Gateway는 웹 애플리케이션에 대한 트래픽을 관리할 수 있도록 하는 웹 트래픽 부하 분산 장치입니다. 기존 부하 분산 장치는 전송 계층(OSI 계층 4 - TCP 및 UDP)에서 작동하고 원본 IP 주소와 포트를 기반으로 대상 IP 주소와 포트에 트래픽을 라우팅합니다.
권장 사항
대부분의 시나리오의 경우 다음 권장 사항을 적용합니다. 이러한 권장 사항을 재정의하라는 특정 요구 사항이 있는 경우가 아니면 따릅니다.
참고
다음 권장 사항에서 워크로드 1은 연결된 워크로드이고, 워크로드 2는 연결이 끊긴 워크로드라고 합니다. 또한 이러한 워크로드에 액세스하는 사용자 및 시스템은 온-프레미스 사용자, 인터넷 사용자 및 Azure 시스템이라고 합니다.
AD DS를 Azure로 확장(선택 사항)
AD DS의 통합 DNS 영역을 사용하여 온-프레미스 데이터 센터 및 Azure에 대한 DNS 레코드를 호스트합니다. 이 시나리오에는 두 개의 AD DS DNS 서버 세트가 있습니다. 하나는 온-프레미스에 있고 다른 하나는 허브 VNet에 있습니다.
AD DS 도메인을 Azure로 확장하는 것이 좋습니다. 또한 Azure의 모든 VM에 대해 허브 VNet의 AD DS DNS 서버를 사용하도록 허브 및 스포크 VNet을 구성하는 것이 좋습니다.
참고
이 권장 사항은 이름 확인을 위해 Active Directory 통합 DNS 영역을 사용하는 조직에만 적용됩니다. 다른 사용자는 확인자/전달자로 작동하는 DNS 서버를 구현하는 것을 고려할 수 있습니다.
스플릿 브레인 DNS 구성
Azure 시스템, 온-프레미스 사용자 및 인터넷 사용자가 연결하는 위치에 따라 워크로드에 액세스할 수 있도록 스플릿 브레인 DNS가 제자리에 있어야 합니다.
DNS 확인을 위해 연결된 워크로드와 연결이 끊긴 워크로드 모두에서 권장되는 구성 요소는 다음과 같습니다.
- 인터넷 사용자를 위한 Azure DNS 영역
- 온-프레미스 사용자 및 Azure 시스템을 위한 DNS 서버
- Azure VNet 간 확인을 위한 Azure 프라이빗 DNS 영역
이 스플릿 브레인 권장 사항을 더 잘 이해하기 위해 wkld1.contoso.com FQDN(정규화된 도메인 이름)을 사용하는 워크로드 1을 사용하는 것이 좋습니다.
이 시나리오에서 인터넷 사용자는 해당 이름을 Application Gateway에서 Wkld1-pip를 통해 공개하는 공용 IP 주소로 확인해야 합니다. 이 확인은 연결된 구독에 대한 주소 레코드(A 레코드)를 Azure DNS에 만들어 수행됩니다.
온-프레미스 사용자는 연결된 구독의 부하 분산 장치에 대해 동일한 이름을 내부 IP 주소로 확인해야 합니다. 이 확인은 A 레코드를 허브 구독의 DNS 서버에 만들어 수행됩니다.
Azure 시스템은 A 레코드를 허브 구독의 DNS 서버에 만들거나 프라이빗 DNS 영역을 사용하여 동일한 이름을 연결된 구독의 부하 분산 장치에 대한 내부 IP 주소로 확인할 수 있습니다. 프라이빗 DNS 영역을 사용하는 경우 A 레코드를 프라이빗 DNS 영역에 수동으로 만들거나 자동 등록을 사용하도록 설정합니다.
프라이빗 링크에 프라이빗 DNS 영역 사용
이 시나리오에서 워크로드 2는 연결이 끊긴 구독에서 호스트되며, 허브 VNet의 프라이빗 엔드포인트를 통해 온-프레미스 사용자 및 연결된 Azure 시스템에 대한 이 워크로드에 액세스할 수 있습니다. 그러나 이 워크로드에 대한 세 번째 연결 가능성은 워크로드 2와 동일한 VNet에 있는 Azure 시스템입니다.
워크로드 2에 대한 DNS 권장 사항을 더 잘 이해하기 위해 wkld2.contoso.com FQDN을 사용하고 개별 권장 사항에 대해 설명합니다.
이 시나리오에서 인터넷 사용자는 해당 이름을 Application Gateway에서 Wkld2-pip를 통해 공개하는 공용 IP 주소로 확인해야 합니다. 이 확인은 연결된 구독에 대한 A 레코드를 Azure DNS에 만들어 수행됩니다.
허브 VNet 및 스포크 VNet에 연결된 온-프레미스 사용자 및 Azure 시스템은 허브 VNet의 프라이빗 엔드포인트에 대해 동일한 이름을 내부 IP 주소로 확인해야 합니다. 이 확인은 A 레코드를 허브 구독의 DNS 서버에 만들어 수행됩니다.
워크로드 2와 동일한 VNet에 있는 Azure 시스템은 이름을 연결이 끊긴 구독에 있는 부하 분산 장치의 IP 주소로 확인해야 합니다. 이 확인은 해당 구독의 Azure DNS에서 프라이빗 DNS 영역을 사용하여 수행됩니다.
다른 VNet을 워크로드 2에 대한 A 레코드를 호스트하는 프라이빗 DNS 영역과 연결하는 경우 해당 VNet에 있는 Azure 시스템은 여전히 워크로드 2의 IP 주소를 확인할 수 있습니다.
자동 등록 사용
프라이빗 DNS 영역을 사용하여 VNet 링크를 구성하는 경우 필요에 따라 모든 가상 머신에 대한 자동 등록을 구성할 수 있습니다.
참고
자동 등록은 가상 머신에 대해서만 작동합니다. VNet의 IP 주소로 구성된 다른 모든 리소스의 경우 DNS 레코드를 프라이빗 DNS 영역에 수동으로 만들어야 합니다.
AD DS DNS 서버를 사용하는 경우 Windows VM에서 Windows 컴퓨터에 대한 동적 업데이트를 사용하여 AD DS DNS 서버에서 사용자 고유의 DNS 레코드를 최신 상태로 유지할 수 있도록 구성합니다. 동적 업데이트를 사용하도록 설정하고 보안 업데이트만 허용하도록 DNS 서버를 구성하는 것이 좋습니다.
Linux VM은 안전한 동적 업데이트를 지원하지 않습니다. 온-프레미스 Linux 컴퓨터의 경우 DHCP(Dynamic Host Configuration Protocol)를 사용하여 DNS 레코드를 AD DS DNS 서버에 등록합니다.
Azure의 Linux VM의 경우 자동화된 프로세스를 사용합니다.
고려 사항
이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.
확장성
- Azure 지역 또는 온-프레미스 데이터 센터별로 각각 둘 이상의 DNS 서버를 사용하는 것이 좋습니다.
- 온-프레미스 및 허브 가상 네트워크에서 DNS 서버를 사용하는 이전 시나리오에서 수행된 방식을 확인합니다.
가용성
- DNS 서버의 배치를 고려합니다. 확장성 고려 사항 섹션에서 설명한 대로 DNS 서버는 액세스해야 하는 사용자 및 시스템에 가깝게 배치해야 합니다.
- Azure 지역당. 각 Azure 지역에는 자체 허브 VNet 또는 vWAN 허브가 있습니다. 이는 DNS 서버를 배포해야 하는 위치입니다.
- 온-프레미스 데이터 센터당. 해당 위치의 사용자 및 시스템을 위한 온-프레미스 데이터 센터당 한 쌍의 DNS 서버도 있어야 합니다.
- 격리된(연결이 끊긴) 워크로드의 경우 각 구독에 대한 프라이빗 DNS 영역과 퍼블릭 DNS 영역을 호스트하여 스플릿 브레인 DNS 레코드를 관리합니다.
관리 효율
- PaaS(Platform as a Service) 서비스에 대한 DNS 레코드의 필요성을 고려합니다.
- 프라이빗 엔드포인트를 사용하는 PaaS 서비스에 대한 DNS 확인도 고려해야 합니다. 이를 위해 프라이빗 DNS 영역을 사용하고, DevOps 파이프라인을 사용하여 레코드를 DNS 서버에 만듭니다.
보안
우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.
- DNSSEC를 사용해야 하는 경우 Azure DNS는 현재 이를 지원하지 않습니다.
- DNSSEC 유효성 검사를 위해 사용자 지정 DNS 서버를 배포하고 DNSEC 유효성 검사를 사용하도록 설정합니다.
- 애플리케이션 설계 모범 사례와 결합된 Azure DDoS Protection은 향상된 DDoS 완화 기능을 제공하여 DDoS 공격에 대한 방어력을 높입니다. 경계 가상 네트워크에서 Azure DDOS Protection을 사용하도록 설정해야 합니다.
DevOps
- 모든 리소스의 구성을 위해 Azure Resource Manager 템플릿을 결합하여 이 아키텍처의 구성을 자동화합니다. 프라이빗 및 퍼블릭 DNS 영역은 모두 Azure CLI, PowerShell, .NET 및 REST API에서 전체 관리를 지원합니다.
- CI/CD(연속 통합 및 지속적인 개발) 파이프라인을 사용하여 Azure 및 온-프레미스에서 워크로드를 배포하고 유지 관리하는 경우 DNS 레코드의 자동 등록을 구성할 수도 있습니다.
비용 최적화
비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.
- Azure DNS 영역 비용은 Azure에서 호스트되는 DNS 영역 수와 수신된 DNS 쿼리 수를 기반으로 합니다.
- Azure 가격 계산기를 사용하여 비용을 예측합니다. Azure DNS에 대한 가격 책정 모델은 여기에 설명되어 있습니다.
- Azure ExpressRoute에 대한 청구 모델은 아웃바운드 데이터 전송에 대해 기가바이트당 요금을 청구하는 하는 계량된 데이터 또는 모든 데이터 전송을 포함하여 월별 요금을 청구하는 무제한 데이터를 기반으로 합니다.
- ExpressRoute 대신 VPN을 사용하는 경우 비용은 가상 네트워크 게이트웨이의 SKU에 따라 달라지며 시간당 요금이 청구됩니다.
다음 단계
구성 요소 기술에 대해 자세히 알아보세요.
관련 참고 자료
관련 아키텍처 살펴보기: