Integration Services 랜딩 존 가속기를 위한 네트워크 토폴로지 및 연결 고려 사항
이 문서에서는 AIS(Azure Integration Services) 랜딩 존 가속기를 사용할 때 적용할 수 있는 네트워크 토폴로지 및 연결에 대한 디자인 고려 사항 및 권장 사항을 제공합니다. 네트워킹은 랜딩 존에 있는 거의 모든 항목의 중심입니다.
이 아키텍처에 대한 네트워크 토폴로지 및 연결 고려 사항은 호스트되는 워크로드의 요구 사항과 조직의 보안 및 규정 준수 요구 사항에 따라 달라집니다.
디자인 고려 사항
조직인 경우 Virtual WAN을 기반으로 네트워크 토폴로지를 사용합니다.
여러 Azure 지역에 리소스를 배포할 계획이며 이러한 Azure 지역의 VNet과 여러 온-프레미스 위치 간의 글로벌 연결이 필요합니다.
SD-WAN(소프트웨어 정의 WAN) 배포를 통해 대규모 분기 네트워크를 Azure에 직접 통합하거나 네이티브 IPsec 종료를 위해 30개 이상의 분기 사이트가 필요합니다.
사이트 간 VPN을 통해 연결된 원격 분기 또는 지점 및 사이트 간 VPN을 통해 연결된 원격 사용자와 같이 VPN과 ExpressRoute 간의 전이적 라우팅이 필요하므로 Azure를 통해 ExpressRoute에 연결된 DC에 연결해야 합니다.
조직에서 Virtual WAN을 사용하여 대규모 상호 연결 요구 사항을 충족합니다. Microsoft는 전체 네트워크 복잡성을 줄이고 조직의 네트워크를 현대화하는 데 도움이 되는 이 서비스를 관리합니다.
조직인 경우 허브 및 스포크 아키텍처를 기반으로 하는 기존 Azure 네트워크 토폴로 지를 사용합니다.
선택한 Azure 지역에만 리소스를 배포할 계획입니다.
상호 연결된 글로벌 네트워크가 필요 없습니다.
지역별 원격 또는 분기 위치가 거의 없으며 30개 미만의 IP 보안(IPsec) 터널이 필요합니다.
구성을 완전히 제어해야 하거나 Azure 네트워크의 수동 사용자 지정 구성이 필요합니다.
참조 네트워크 토폴로지
다음 아키텍처 다이어그램은 AIS 엔터프라이즈 배포에 대한 참조 아키텍처를 보여 줍니다.
IP 주소 지정 계획
AIS의 엔터프라이즈 배포에는 프라이빗 엔드포인트 및 가상 네트워크 사용이 포함되어야 합니다. IP 주소 지정을 계획할 때는 다음 디자인 고려 사항을 고려해야 합니다.
일부 AIS 서비스에는 전용 서브넷이 필요합니다 .
지정된 서브넷 t0을 지정된 서비스로 지정하여 서브넷 내에서 해당 서비스의 인스턴스를 만들 수 있습니다. 예를 들어 시간이 지남에 따라 앱을 더 추가할 수 있도록 앱 서비스 계획에 서브넷을 지정할 수 있습니다.
Azure VPN Gateway는 NAT(네트워크 주소 변환) 기능을 통해 겹치는 IP 주소 공간과 겹치는 온-프레미스 사이트를 연결할 수 있습니다.
사용자 지정 DNS
대부분의 AIS 서비스를 사용하면 고객이 자신의 DNS 서버를 사용하거나 Azure DNS 제품을 통해 퍼블릭 엔드포인트에 고유한 DNS 이름을 사용할 수 있습니다. 이러한 구성은 리소스별로 수행되지만 지원되는 리소스는 다음과 같습니다.
API Management는 사용자 지정 기본 지원합니다.
Function Apps 및 Logic Apps는 App Service 계획 또는 App Service Environment에서 호스트되는 경우 사용자 지정 do기본s를 지원합니다.
스토리지 계정은 Blob Storage 엔드포인트에 대한 사용자 지정 do기본s를 지원합니다.
Data Factory, Service Bus 및 Event Grid는 사용자 지정 작업을 지원하지 기본.
프라이빗 DNS
Azure Private DNS는 가상 네트워크에 안정적이고 안전한 DNS 서비스를 제공합니다. Azure Private DNS는 사용자 지정 DNS 솔루션을 구성할 필요 없이 가상 네트워크의 도메인 이름을 관리하고 확인합니다.
가상 네트워크에서 프라이빗 DNS 영역의 레코드를 확인하려면 가상 네트워크를 영역과 연결해야 합니다. 연결된 가상 네트워크에는 모든 액세스 권한이 있으며 프라이빗 영역에 게시된 모든 DNS 레코드를 확인할 수 있습니다.
디자인 고려 사항
프라이빗 엔드포인트 IP 주소를 리소스의 FQDN(정규화된 do기본 이름)으로 확인하도록 DNS 설정을 올바르게 구성하는 것이 중요합니다.
기존 Microsoft Azure 서비스에는 공용 엔드포인트에 대한 DNS 구성이 이미 있을 수 있습니다. 이 구성은 프라이빗 엔드포인트를 사용하여 연결하도록 재정의해야 합니다.
암호화 및 인증서 인증
네트워크 디자인에 전송 중인 트래픽 및/또는 인증서 기반 인증의 암호화가 필요한 경우 이 암호화/인증이 수행되는 위치와 방법을 고려해야 할 수 있습니다. 예를 들어 TLS 종료를 수행하는 서비스를 식별해야 합니다.
디자인 고려 사항
디자인에서 Azure 서비스 간의 트래픽을 암호화해야 합니까? Azure Front Door에서 암호화를 종료한 다음 Azure 백본을 트래버스하는 동안 또는 VNet 내에서 암호화되지 않을 수 있나요?
여러 위치에서 암호화를 종료해야 합니까?
여러 위치에서 인증을 처리해야 합니까, 아니면 외부 요청에 대해 한 번 수행할 수 있나요?
디자인 권장 사항
엔터프라이즈 허브 및 스포크 디자인을 사용하는 경우 인터넷 기반 요청의 진입점으로 Azure Front Door를 사용하는 것이 좋습니다.
인증서 인증 및/또는 SSL 종료를 위해 외부 TLS 기반 요청 또는 API Management의 종료 지점으로 Azure 애플리케이션 Gateway를 사용하는 것이 좋습니다.
온-프레미스 리소스에 대한 커넥트ivity
많은 엔터프라이즈 통합 시나리오에서는 온-프레미스 시스템을 Azure에 연결해야 합니다. 이 연결을 제공하기 위해 권장되는 모델을 고려하는 것이 중요합니다.
디자인 고려 사항
Azure ExpressRoute 는 온-프레미스 위치에서 Azure IaaS(Infrastructure as a Service) 및 PaaS(Platform as a Service) 리소스에 대한 전용 프라이빗 연결을 제공합니다.
Azure VPN Gateway 는 공용 인터넷을 통해 온-프레미스 위치에서 Azure IaaS(Infrastructure as a Service) 가상 네트워크 리소스에 대한 S2S(사이트 간) 공유 연결을 제공합니다.
Azure ExpressRoute 및 Azure VPN Gateway에는 다양한 기능, 비용 및 성능이 있습니다.
온-프레미스 OPDG(데이터 게이트웨이) 또는 Azure 하이브리드 커넥트은 ExpressRoute 또는 VPN Gateway가 실용적이지 않은 경우 사용할 수 있습니다. OPDG/하이브리드 커넥트 모두 Service Bus를 활용하여 외부 방화벽/네트워크에서 포트를 열지 않고도 온-프레미스 네트워크에서 아웃바운드로 연결을 만들어 Azure에서 요청을 수신하도록 하는 예제입니다.
OPDG는 지원하는 분당 요청 수(제한 제한)로 제한되며 특정 데이터 크기 제한이 있으며 제한된 Azure 리소스(Logic Apps, Power BI, Power Apps, Power Automate, Analysis Services)에서만 작동합니다.
하이브리드 연결은 App Services(Function Apps 또는 Web Apps)에서 작동하며 자체 제한 및 크기 조정 제한이 있습니다.
Azure Relay 하이브리드 커넥트은 App Services 또는 OPDG 외부에서 릴레이를 허용하는 Service Bus의 핵심 부분입니다.
디자인 권장 사항
온-프레미스 네트워크를 Azure 에 연결하기 위한 기본 연결 채널로 Azure ExpressRoute 를 사용합니다.
대역폭 및 성능 요구 사항에 따라 ExpressRoute 및/또는 VPN Gateway에 적합한 SKU를 사용하고 있는지 확인합니다.
Azure VPN Gateway 를 사용하여 분기 또는 원격 위치를 Azure에 연결합니다.
ExpressRoute 또는 VPN Gateway를 사용할 수 없고 처리량 제한이 문제가 되지 않으며 지원 Azure 리소스(예: Logic Apps, Function Apps)를 사용하는 경우 OPDG 및/또는 하이브리드 커넥트을 사용합니다.
AIS PaaS 서비스에 대한 커넥트ivity
Azure AIS PaaS 서비스는 일반적으로 퍼블릭 엔드포인트를 통해 액세스됩니다. Azure 플랫폼은 이러한 엔드포인트를 보호하거나 완전히 비공개로 만드는 기능을 제공합니다.
프라이빗 엔드포인트를 사용하여 이러한 엔드포인트를 보호합니다.
대상 리소스에 대한 모든 인터넷 트래픽을 차단하려면 프라이빗 엔드포인트를 사용합니다.
VNet 리소스에 대한 특정 하위 리소스를 보호하려면 프라이빗 엔드포인트를 사용합니다.
VNet 리소스에 대한 특정 스토리지 계정을 보호하려는 경우 프라이빗 엔드포인트를 사용할 수 있습니다.
Azure Private Link 를 사용하면 가상 네트워크의 프라이빗 엔드포인트를 통해 Azure AIS Services (예: Service Bus 및 API Management) 및 Azure 호스팅 고객 소유/파트너 서비스에 액세스할 수 있습니다.
Private Link를 사용하는 경우 가상 네트워크와 서비스 간의 트래픽이 Microsoft 백본 네트워크를 트래버스하므로 더 이상 공용 인터넷에 서비스를 노출할 필요가 없습니다. 가상 네트워크에 자체 프라이빗 링크 서비스를 만들어서 고객에게 제공할 수도 있습니다. Azure Private Link를 사용한 설치 및 소비는 Azure PaaS, 고객 소유 및 공유 파트너 서비스에서 일관적입니다.
디자인 고려 사항
가상 네트워크 주입은 지원되는 서비스의 전용 비공개 배포를 제공합니다. 관리 평면 트래픽은 여전히 공용 IP 주소를 통해 이동합니다.
Azure Private Link는 개인 IP 주소를 사용하여 Azure PaaS 인스턴스에 대한 또는 Azure Load Balancer 표준 계층을 기반으로 하는 사용자 지정 서비스에 대한 전용 액세스를 제공합니다.
기업 고객은 적절하게 완화해야 하는 PaaS 서비스의 퍼블릭 엔드포인트에 대한 우려가 있는 경우가 많습니다.
디자인 권장 사항
지원되는 Azure 서비스에 가상 네트워크 삽입을 사용하여 가상 네트워크 내에서 사용 가능하도록 설정합니다.
가상 네트워크에 삽입된 Azure PaaS 서비스는 계속해서 서비스 관련 공용 IP 주소를 사용하여 관리 평면 작업을 수행합니다. 서비스가 올바르게 작동하려면 연결을 보장해야 합니다.
개인 피어링을 사용하는 ExpressRoute를 통해 온-프레미스에서 Azure PaaS 서비스에 액세스합니다. 전용 Azure 서비스에 가상 네트워크 삽입을 사용하거나 사용 가능한 공유 Azure 서비스에 Azure Private Link를 사용합니다.
가상 네트워크 삽입 또는 Private Link를 사용할 수 없는 경우 온-프레미스에서 Azure PaaS 서비스에 액세스하려면 공용 인터넷을 트래버스하지 않도록 하는 Microsoft 피어링과 함께 ExpressRoute를 사용합니다.
Microsoft 피어링을 사용하는 ExpressRoute를 통해 온-프레미스에서 Azure PaaS 서비스에 액세스해도 PaaS 서비스의 퍼블릭 엔드포인트에 대한 액세스가 방지되지 않습니다. 필요에 따라 별도로 구성하고 제한해야 합니다.
모든 서브넷에서 기본적으로 가상 네트워크 서비스 엔드포인트를 사용하도록 설정하지 마세요.
AIS PaaS 서비스에 대한 공용 액세스를 사용하지 않도록 설정합니다.
API Management용 네트워크 디자인
디자인 고려 사항
API가 외부에서 액세스할 수 있는지, 내부적으로 액세스할 수 있는지 또는 둘 다의 하이브리드인지 결정합니다.
내부 API Management 게이트웨이를 기본 엔드포인트로 사용할지 또는 Azure 애플리케이션 게이트웨이 또는 Azure Front Door와 같은 WAF(웹 애플리케이션 방화벽) 서비스를 사용할지 여부를 결정합니다.
여러 게이트웨이를 배포해야 하는지와 부하 분산 방법을 결정합니다(예: API Management 게이트웨이 앞에서 Application Gateway 사용).
온-프레미스 또는 다중 클라우드 환경에 대한 연결이 필요한지 여부를 결정합니다.
디자인 권장 사항
네트워크의 백 엔드 서비스에 대한 액세스를 허용하도록 VNet에 API Management 인스턴스를 배포합니다.
API Management 인스턴스가 내부 모드에서 VNet에 배포될 때 API Management에 대한 외부 액세스에 Application Gateway를 사용합니다.
API Management 인스턴스에 대한 프라이빗 엔드포인트를 사용하여 프라이빗 네트워크의 클라이언트가 Azure Private Link를 통해 인스턴스에 안전하게 액세스할 수 있도록 합니다.
스토리지 계정에 대한 네트워크 디자인
Azure Storage는 Azure Logic Apps 및 Azure Functions에 대한 스토리지 솔루션으로 사용됩니다.
디자인 권장 사항
최상의 성능을 위해 논리 앱/함수 앱은 동일한 지역의 스토리지 계정을 사용해야 하므로 대기 시간이 줄어듭니다.
Azure Storage 계정에 프라이빗 엔드포인트를 사용하여 VNet(가상 네트워크)의 클라이언트가 Private Link를 통해 데이터에 안전하게 액세스할 수 있도록 합니다.
각 테이블, 큐 및 Blob Storage 서비스에 대해 서로 다른 프라이빗 엔드포인트를 만들어야 합니다.
App Service Environment에 대한 네트워크 디자인
ASE(App Service Environment)는 웹앱, 함수 앱 및 Logic Apps(표준)를 실행하기 위한 격리된 전용 환경입니다. VNet에 배포되며, 각각 앱 서비스를 호스트하는 데 사용되는 여러 App Service 계획을 포함합니다.
디자인 고려 사항
ASE는 VNet 내의 단일 서브넷에 배포됩니다. 외부 연결에서 공용 DNS 레코드에 추가할 수 있는 공개적으로 표시되는 IP 주소를 사용할 수 있도록 하는 VIP(가상 IP 주소)를 사용하여 ASE를 배포할 수 있습니다.
ASE 내의 애플리케이션은 네트워크 액세스 규칙에 따라 Virtual Network 내의 다른 모든 리소스에 액세스할 수 있습니다. Virtual Network 피어링을 사용하여 다른 VNet의 리소스에 액세스할 수 있습니다.
ASE 내의 애플리케이션은 VNet에 속하도록 구성할 필요가 없습니다. ASE에 배포되므로 VNet 내에 자동으로 포함됩니다. 즉, 리소스별로 네트워크 액세스를 구성하는 대신 ASE 수준에서 한 번 구성할 수 있습니다.
디자인 권장 사항
- 가능한 경우 ASE v3를 사용하면 네트워크 유연성이 극대화되는 동시에 ASE 내의 개별 리소스에 필요한 구성을 줄일 수 있습니다. ASE v3는 영역 중복도 지원합니다.
App Service 계획에 대한 네트워크 디자인
다중 테넌트 환경의 App Services는 프라이빗 또는 퍼블릭 엔드포인트를 사용하여 배포할 수 있습니다. 프라이빗 엔드포인트를 사용하여 배포하면 App Service의 공개 노출이 제거됩니다. App Service의 프라이빗 엔드포인트도 인터넷을 통해 연결할 수 있어야 하는 요구 사항이 있는 경우 App Gateway를 사용하여 앱 서비스를 노출하는 것이 좋습니다.
필요한 IP 주소 수를 고려하여 아웃바운드 VNet 통합을 위해 서브넷을 신중하게 계획합니다. VNet 통합에는 전용 서브넷이 필요합니다. 서브넷 크기를 계획할 때 Azure 는 각 서브넷에 5개의 IP 주소를 예약합니다 . 또한 각 계획 인스턴스에 대한 통합 서브넷에서 하나의 주소가 사용됩니다. 앱을 4개의 인스턴스로 스케일링하면 4개의 주소가 사용됩니다. 크기를 스케일 업 또는 스케일 다운하면, 짧은 시간 동안 필요한 주소 공간이 2배가 됩니다. 이는 서브넷에서 지원되는 실제 인스턴스에 영향을 줍니다.
App Service에서 온-프레미스, 프라이빗 또는 IP 제한 서비스에 연결해야 하는 경우 다음을 고려합니다.
다중 테넌트 환경에서 실행하는 경우 App Service 호출은 광범위한 IP 주소에서 시작될 수 있으며 네트워킹 요구 사항을 충족하기 위해 VNet 통합이 필요할 수 있습니다.
API Management(APIM)와 같은 서비스는 네트워킹 경계 간의 호출을 프록시하는 데 사용할 수 있으며 필요한 경우 고정 IP를 제공할 수 있습니다.
디자인 권장 사항
- 할당 후에는 서브넷 크기를 변경할 수 없으므로 앱이 도달할 수 있는 규모에 맞게 충분히 큰 서브넷을 사용합니다. 서브넷 용량 문제를 방지하려면 VNet 통합에 /26 접미사(64개 주소)를 사용해야 합니다.
Azure Data Factory의 네트워크 디자인
디자인 고려 사항
Data Factory를 온-프레미스 네트워크에 있는 데이터 원본 또는 특별히 허용되지 않는 한 모든 Azure 서비스의 액세스를 차단하도록 구성된 Azure 서비스에 연결하려면 데이터 팩터리를 대상 데이터 원본에 대한 네트워크 액세스를 제공하는 가상 네트워크와 통합하는 것이 좋습니다.
Data Factory는 통합 런타임이라는 별도의 환경을 사용합니다. 기본 Data Factory 런타임인 Azure 통합 런타임은 VNet과 연결되지 않으므로 가장 제한적인 방화벽으로 보호되는 데이터 원본에 연결하는 데 사용할 수 없습니다. 이러한 런타임 중 요구 사항을 가장 잘 충족하는 런타임을 고려합니다.
관리되는 VNet은 시작하는 데 다소 시간이 걸리지만 일반 Azure 런타임은 거의 즉시 사용할 수 있습니다. 파이프라인을 예약하고 디버깅할 때 유의해야 할 사항입니다.
VNet 통합 런타임을 사용하는 SSIS 런타임을 시작하는 데 최대 30분이 걸립니다.
자체 호스팅 통합 런타임은 한 원본에서 다른 원본으로 데이터를 있는 그대로 복사하는 복사 작업만 실행할 수 있습니다. 데이터에 대한 변환을 수행하려는 경우 Data Factory의 데이터 흐름을 사용하여 변환을 수행할 수 없습니다.
관리형 프라이빗 엔드포인트는 Azure 리소스(일반적으로 ADF의 데이터 원본)에 대한 프라이빗 링크를 설정하는 Azure Data Factory Managed Virtual Network에서 만든 프라이빗 엔드포인트 입니다. Azure Data Factory는 사용자 대신 이러한 프라이빗 엔드포인트를 관리합니다.
프라이빗 엔드포인트는 자체 호스팅 통합 런타임에서만 Data Factory에 연결할 수 있습니다.
Logic Apps(표준)용 네트워크 디자인 - VNet 통합 앱
디자인 고려 사항
논리 앱에 대한 인바운드 트래픽은 프라이빗 엔드포인트를 통해 제공됩니다. Logic Apps 네트워킹 디자인을 계획할 때 프라이빗 엔드포인트 설명서를 통해 인바운드 트래픽에 대한 고려 사항을 참조하세요.
논리 앱의 아웃바운드 트래픽은 VNet을 통해 흐릅니다. Logic Apps 네트워킹 디자인을 계획할 때 가상 네트워크 통합 설명서를 통해 아웃바운드 트래픽에 대한 고려 사항을 참조하세요.
Service Bus에 대한 네트워크 디자인
디자인 고려 사항
프라이빗 DNS 영역 또는 자체 DNS 서버(DNS 전달 포함)를 사용하여 프라이빗 링크 리소스로 확인합니까?
IP 필터링 및 VNet은 Service Bus에 대한 프리미엄 SKU 계층에서만 지원됩니다. 프리미엄 계층이 실용적이지 않은 경우 네임스페이스에 대한 액세스를 잠그는 기본 방법으로 SAS 토큰을 사용하는 방법을 살펴보세요.
디자인 권장 사항
지원되는 모든 프로토콜(예: AMQP 및 HTTPS)에 적용되는 IP 필터링을 사용하여 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.
이 네임스페이스에 대한 트래픽은 공용 네트워크 액세스를 제한하여(IP 필터링 사용) 프라이빗 엔드포인트에 대해서만 제한되어야 합니다.
프라이빗 엔드포인트를 Service Bus용으로 예약된 전용 서브넷에 배치합니다.
프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다. Azure 내에서 신뢰할 수 있는 서비스를 사용하도록 설정하여 네임스페이스에 직접 액세스하여 방화벽을 우회하여 통합 디자인 문제를 방지합니다.
Function Apps에 대한 네트워크 디자인
디자인 고려 사항
- 프라이빗 DNS 영역 또는 자체 DNS 서버(DNS 전달 포함)를 사용하여 프라이빗 링크 리소스로 확인합니까?
디자인 권장 사항
공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.
이 네임스페이스에 대한 트래픽은 프라이빗 엔드포인트에서만 제한되어야 합니다.
프라이빗 엔드포인트를 Functions용으로 예약된 전용 서브넷에 배치합니다.
프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다.
Azure Key Vault에 대한 네트워크 디자인
디자인 권장 사항
공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.
VNet의 유일한 액세스를 제한하기 위한 프라이빗 엔드포인트를 만듭니다.
프라이빗 엔드포인트를 Key Vault용으로 예약된 전용 서브넷에 배치합니다.
프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다.
Event Grid에 대한 네트워크 디자인
디자인 고려 사항
- 프라이빗 DNS 영역 또는 자체 DNS 서버(DNS 전달 포함)를 사용하여 프라이빗 링크 리소스로 확인합니까?
디자인 권장 사항
IP 필터링을 사용하여 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.
토픽 및 할 일로의 트래픽은 프라이빗 엔드포인트에서만 제한되어야 기본.
Event Grid용으로 예약된 자체 전용 서브넷에 프라이빗 엔드포인트를 배치합니다.
프라이빗 엔드포인트에 대한 프라이빗 DNS 영역을 사용하여 DNS 레코드를 추가합니다.
Event Hubs에 대한 네트워크 디자인
디자인 고려 사항
- 네트워크 액세스 제한은 Event Hubs의 기본 SKU 계층에서 작동하지 않습니다.
디자인 권장 사항
IP 필터링을 사용하여 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다.
서비스 엔드포인트를 사용하여 공용 네트워크 액세스를 사용하지 않도록 설정해야 합니다. VNet에서 Virtual Network 서비스 엔드포인트를 만들고 가상 네트워크 규칙을 사용하여 Event Hubs 네임스페이스에 바인딩합니다.
Azure 리소스를 선택하여 네임스페이스에 액세스할 수 있도록 신뢰할 수 있는 서비스 옵션을 사용하도록 설정합니다.
다음 단계
중요한 디자인 영역을 검토하여 아키텍처에 대한 전체 고려 사항 및 권장 사항을 확인합니다.