편집

다음을 통해 공유


가상 허브 확장 패턴

Azure Private Link
Azure DNS
Azure Firewall
Azure 가상 WAN

자체 네트워킹사용하는 기존 허브-스포크 토폴로지에서 허브 가상 네트워크를 완전히 조작할 수 있습니다. 허브에 공통 서비스를 배포하고 워크로드 스포크에서 사용할 수 있도록 할 수 있습니다. 이러한 공유 서비스에는 종종 DNS 리소스, 사용자 지정 NVA 및 Azure Bastion과 같은 항목이 포함됩니다. 그러나 Azure Virtual WAN을 사용하는 경우 가상 허브에 설치할 수 있는 항목에 대한 액세스 및 제한 사항이 제한됩니다.

예를 들어 기존 허브-스포크 네트워크 아키텍처에서 Private Link 및 DNS 통합을 구현하려면 프라이빗 DNS 영역을 만들어 허브 네트워크에 연결합니다. 가상 머신 원격 액세스 계획에는 Azure Bastion을 지역 허브의 공유 서비스로 포함할 수 있습니다. 허브의 Active Directory VM과 같은 사용자 지정 컴퓨팅 리소스를 배포할 수도 있습니다. Virtual WAN에서는 이러한 접근 방식을 사용할 수 없습니다.

이 문서에서는 가상 허브에 직접 배포할 수 없는 스포크에 공유 서비스를 안전하게 노출하는 방법에 대한 지침을 제공하는 가상 허브 확장 패턴을 설명합니다.

아키텍처

가상 허브 확장은 워크로드 스포크에 단일 공유 서비스를 노출하는 가상 허브에 연결된 전용 스포크 가상 네트워크입니다. 가상 허브 확장을 사용하여 여러 워크로드 스포크에 공유 리소스에 대한 네트워크 연결을 제공할 수 있습니다. DNS 리소스는 이 사용의 예입니다. 확장을 사용하여 스포크에서 많은 대상에 연결해야 하는 중앙 집중식 리소스를 포함할 수도 있습니다. 중앙 집중식 Azure Bastion 배포가 이 사용의 예입니다.

허브 확장 패턴을 보여 주는 다이어그램

그림 1: 허브 확장 패턴

이 아키텍처의 Visio 파일을 다운로드합니다.

  1. Azure Bastion에 대한 가상 허브 확장. 이 확장을 사용하면 스포크 네트워크의 가상 머신에 연결할 수 있습니다.
  2. DNS에 대한 가상 허브 확장입니다. 이 확장을 사용하면 스포크 네트워크의 워크로드에 프라이빗 DNS 영역 항목을 노출할 수 있습니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일련의 기본 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

안정성

가상 허브 확장은 네트워크 내에서 핵심 기능을 제공하기 때문에 비즈니스에 중요한 것으로 간주되는 경우가 많습니다. 확장은 비즈니스 요구 사항에 맞게 조정되고, 오류 완화 전략이 있으며, 스포크 요구 사항에 맞게 확장해야 합니다.

표준 운영 절차에는 모든 확장에 대한 복원력 테스트 및 안정성 모니터링이 포함되어야 합니다. 이러한 절차는 액세스 및 처리량 요구 사항의 유효성을 검사해야 합니다. 각 확장에는 의미 있는 상태 모델이 있어야 합니다.

이 확장에 대한 SLO(서비스 수준 목표)를 명확히 하고 이에 대한 안정성을 정확하게 측정합니다. 확장의 각 개별 구성 요소에 대한 Azure SLA(서비스 수준 계약) 및 지원 요구 사항을 이해합니다. 이 지식은 대상 SLO의 최대값을 설정하고 지원되는 구성을 이해하는 데 도움이 됩니다.

보안

네트워크 제한. 확장은 종종 많은 스포크에서 사용되거나 많은 스포크에 액세스해야 하지만 모든 스포크에서 또는 모든 스포크에 액세스할 필요가 없을 수 있습니다. 가능한 경우 네트워크 보안 그룹 사용 및 보안 가상 허브를 통한 트래픽 송신과 같은 사용 가능한 네트워크 보안 컨트롤을 사용합니다.

데이터 및 컨트롤 평면 액세스 제어. 확장에 배포된 모든 리소스에 대한 모범 사례를 따르며 리소스의 제어 평면 및 데이터 평면에 대한 최소 권한 액세스를 제공합니다.

비용 최적화

모든 워크로드와 마찬가지로 비용을 제어하는 데 도움이 되는 확장 리소스에 적절한 SKU 크기가 선택되어 있는지 확인합니다. 업무 시간 및 기타 요인으로 인해 일부 확장에 대해 예측 가능한 사용 패턴이 발생할 수 있습니다. 패턴을 이해하고 패턴을 수용할 수 있는 탄력성과 확장성을 제공합니다.

공유 서비스로서 워크로드 리소스는 일반적으로 엔터프라이즈 아키텍처에서 비교적 긴 업무 주기를 갖습니다. Azure Reservations, 예약된 용량 가격 및 Azure 절감 계획과 같은 사전 예약 제품을 통해 비용 절감을 사용하는 것이 좋습니다.

운영 우수성

SRP(단일 책임 원칙)를 준수하도록 가상 허브 확장을 빌드합니다. 각 확장은 단일 제품용이어야 하므로 관련 없는 서비스를 단일 스포크로 결합하지 마세요. 각 확장이 전용 리소스 그룹에 있도록 리소스를 구성하여 Azure 정책 및 역할을 보다 쉽게 관리할 수 있습니다.

인프라를 코드로 사용하여 이러한 확장을 프로비전하고 각 확장의 요구 사항과 수명 주기를 지원하는 빌드 및 릴리스 프로세스가 있어야 합니다. 확장은 본질적으로 비즈니스에 중요한 경우가 많기 때문에 각 확장에 대해 엄격한 테스트 방법과 안전한 배포 사례를 마련하는 것이 중요합니다.

명확한 변경 제어 및 엔터프라이즈 통신 계획을 수립하는 것이 중요합니다. 실행 중인 DR(재해 복구) 훈련 또는 계획되거나 예기치 않은 가동 중지 시간에 대해 관련자(워크로드 소유자)와 통신해야 할 수 있습니다.

이러한 리소스에 대해 견고한 운영 상태 시스템이 있는지 확인합니다. 모든 확장 리소스에서 적절한 Azure Diagnostics 설정을 사용하도록 설정하고 워크로드의 상태를 이해하는 데 필요한 모든 원격 분석 및 로그를 캡처합니다. 공유 서비스 확장의 예기치 않은 동작 중에 고객 지원 상호 작용을 지원하려면 작업 로그 및 메트릭의 장기 스토리지를 고려합니다.

성능 효율성

확장은 중앙 집중식 서비스입니다. 부하 변경을 처리하도록 배율 단위를 디자인하려면 다음을 이해해야 합니다.

  • 조직에서 확장에 대해 요구하는 사항입니다.
  • 용량 계획에 대한 요구 사항입니다.
  • 스포크는 시간이 지남에 따라 어떻게 증가할 것인가.

배율 단위를 디자인하려면 현재 사용 중인 메트릭 및 서비스 확장 제한에 따라 확장의 각 구성 요소가 개별적으로 스케일링되는 방식을 테스트하고 문서화합니다. 일부 확장은 필요한 처리량을 달성하기 위해 여러 인스턴스 간에 부하 분산이 필요할 수 있습니다.

구현 예제

Private Link DNS 확장: DNS 용 가상 허브 확장 설정은 Private Link 시나리오에 대한 단일 지역 DNS 조회를 지원하도록 설계된 가상 허브 확장을 설명합니다.

다음 단계