Azure Spring Apps 랜딩 존 가속기를 위한 네트워크 토폴로지 및 연결
이 문서에서는 Spring Boot 워크로드가 배치되는 네트워크에 대한 디자인 고려 사항 및 권장 사항을 설명합니다. 대상 디자인은 워크로드의 요구 사항과 organization 보안 및 규정 준수 요구 사항에 따라 달라집니다.
중앙 집중식 플랫폼 팀과 애플리케이션 팀은 네트워킹 디자인 영역의 책임을 공유합니다. 플랫폼 팀은 기존 허브-스포크 모델 또는 Virtual WAN 네트워크 토폴로지(Microsoft 관리형)일 수 있는 네트워킹 토폴로지를 선택합니다. 애플리케이션 팀은 스포크 네트워크의 디자인 선택을 담당합니다. 워크로드에는 플랫폼에서 관리하는 공유 서비스에 대한 종속성이 있어야 합니다. 애플리케이션 팀은 이러한 종속성의 의미를 이해하고 요구 사항을 전달하여 워크로드의 전반적인 목표를 충족해야 합니다.
플랫폼 디자인에 대한 자세한 내용은 네트워크 토폴로지 및 연결을 참조하세요.
서브넷, 수신 및 송신 컨트롤에 대한 모범 사례로 이러한 디자인 고려 사항 및 권장 사항을 따릅니다.
디자인 고려 사항
격리. 중앙 팀은 애플리케이션 팀이 워크로드를 실행할 수 있도록 가상 네트워크를 제공할 수 있습니다. Spring Boot 워크로드가 다른 워크로드와 분리된 경우 Spring App Service 런타임 및 애플리케이션에 대한 자체 가상 네트워크를 프로비전하는 것이 좋습니다.
서브넷. 서브넷의 크기와 애플리케이션 수를 선택할 때 애플리케이션의 확장성을 고려합니다.
기존 서브넷을 사용하거나 고유한 경로 테이블을 가져오는 경우 Azure Spring Apps에서 추가한 규칙이 업데이트되거나 삭제되지 않도록 정책을 적용합니다.
또 다른 측면은 보안입니다. 서브넷에 대한 트래픽을 허용하거나 거부하는 규칙을 고려합니다.
송신(아웃바운드) 트래픽. 가상 네트워크에서 나가는 트래픽은 Azure Firewall 또는 NVA(네트워크 가상 어플라이언스)를 통해 라우팅되어야 합니다.
Azure Spring Apps에서 제공하는 기본 제공 부하 분산 장치의 제한 사항을 고려합니다. 요구 사항에 따라 instance NVA를 통해 모든 트래픽을 라우팅하기 위해 UDR(사용자 정의 라우팅)을 사용하여 송신 경로를 사용자 지정해야 할 수 있습니다.
수신(인바운드) 트래픽입니다. Azure Spring Apps로 가는 트래픽에 역방향 프록시를 사용하는 것이 좋습니다. 요구 사항에 따라 Azure Application Gateway 및 Front Door와 같은 네이티브 옵션 또는 APIM(API Management)과 같은 지역 서비스를 선택합니다. 이러한 옵션이 워크로드의 요구 사항을 충족하지 않는 경우 비 Azure 서비스를 고려할 수 있습니다.
디자인 권장 사항
이러한 권장 사항은 이전 고려 사항 집합에 대한 규범적인 지침을 제공합니다.
가상 네트워크 및 서브넷
Azure Spring Apps에는 가상 네트워크에 대한 소유자 권한이 필요합니다. 이 역할은 배포 및 유지 관리를 위해 전용 및 동적 서비스 주체를 부여하는 데 필요합니다. 자세한 내용은 가상 네트워크에 Azure Spring Apps 배포를 참조하세요.
프라이빗 네트워크에 배포된 Azure Spring Apps는 프라이빗 네트워크 내에서만 액세스할 수 있는 FQDN(정규화된 도메인 이름)을 제공합니다. Spring 앱의 IP 주소에 대한 Azure 프라이빗 DNS 영역을 만듭니다. Azure Spring Apps 내에서 프라이빗 FQDN을 할당하여 프라이빗 DNS를 가상 네트워크에 연결합니다. 단계별 지침은 프라이빗 네트워크에서 애플리케이션 액세스를 참조하세요.
Azure Spring Apps에는 두 개의 전용 서브넷이 필요합니다. 한 서브넷에는 서비스 런타임이 있고 다른 서브넷은 Spring Boot 애플리케이션용입니다.
이러한 각 서브넷의 최소 CIDR 블록 크기는 /28입니다. 런타임 서브넷과 애플리케이션 서브넷에는 최소 주소 공간 /28이 필요합니다. 그러나 배포할 수 있는 Spring 앱 수는 서브넷의 크기에 영향을 미칩니다. 서브넷 범위별 최대 앱 인스턴스에 대한 자세한 내용은 더 작은 서브넷 범위 사용을 참조하세요.
Azure Spring Apps 앞에서 Azure Application Gateway 역방향 프록시로 사용하는 경우 해당 instance 다른 서브넷이 필요합니다. 자세한 내용은 역방향 프록시로 Application Gateway 사용을 참조하세요.
서브넷에서 NSG(네트워크 보안 그룹)를 사용하여 동서 트래픽을 필터링하여 트래픽을 서비스 런타임 서브넷으로 제한합니다.
Azure Spring Apps 배포에서 관리하는 리소스 그룹 및 서브넷은 수정해서는 안 됩니다.
송신 트래픽
기본적으로 Azure Spring Apps에는 무제한 아웃바운드 인터넷 액세스가 있습니다. Azure Firewall 같은 NVA를 사용하여 남북 트래픽을 필터링합니다. 중앙 집중식 허브 네트워크의 Azure Firewall 활용하여 관리 오버헤드를 줄입니다.
참고
서비스 인스턴스를 지원하려면 Azure Spring 구성 요소에 대한 송신 트래픽이 필요합니다. 특정 엔드포인트 및 포트에 대한 자세한 내용은 Azure Spring Apps 네트워크 요구 사항을 참조하세요.
Azure Spring Apps는 송신 트래픽 경로를 완전히 제어할 수 있는 UDR(사용자 정의 경로) 아웃바운드 형식을 제공합니다.
OutboundType는 새 Azure Spring Apps 서비스 instance 만들 때 정의되어야 합니다. 나중에 업데이트할 수 없습니다.OutboundType는 가상 네트워크로만 구성할 수 있습니다. 자세한 내용은 사용자 정의 경로를 사용하여 Azure Spring Apps 송신 사용자 지정을 참조하세요.애플리케이션은 솔루션의 다른 Azure 서비스와 통신해야 합니다. 애플리케이션에 프라이빗 연결이 필요한 경우 지원되는 서비스에 Azure Private Link 사용합니다.
수신 트래픽
역방향 프록시를 사용하여 악의적인 사용자가 WAF(웹 애플리케이션 방화벽)를 우회하거나 제한 제한을 우회하지 못하도록 합니다. 통합 WAF를 사용하는 Azure Application Gateway 것이 좋습니다.
엔터프라이즈 계층을 사용하는 경우 Spring Cloud Gateway 앱의 할당된 엔드포인트를 Application Gateway 백 엔드 풀로 사용합니다. 이 엔드포인트는 Azure Spring Apps 서비스 런타임 서브넷의 개인 IP 주소로 확인됩니다.
Application Gateway 서브넷, Azure Spring Apps 서브넷 및 Azure Load Balancer 트래픽만 허용하는 서비스 런타임 서브넷에 NSG를 추가합니다.
참고
Azure Front Door 또는 비 Azure 서비스와 같은 역방향 프록시에 대한 대안을 선택할 수 있습니다. 구성 옵션에 대한 자세한 내용은 역방향 프록시를 통해 Azure Spring Apps 노출을 참조하세요.
Azure Spring Apps는 VNet 삽입 또는 네트워크 외부를 통해 가상 네트워크에 배포할 수 있습니다. 자세한 내용은 구성 요약을 참조하세요.