Azure의 중요 업무용 워크로드에 대한 네트워킹 및 연결

네트워킹은 전역적으로 분산된 활성-활성 디자인 접근 방식을 권장하므로 중요 업무용 애플리케이션의 기본 영역입니다.

이 디자인 영역에서는 필수 연결 및 중복 트래픽 관리를 고려하여 애플리케이션 수준에서 다양한 네트워크 토폴로지 항목을 살펴봅니다. 보다 구체적으로, 중요 업무용 애플리케이션에 대한 안전하고 확장 가능한 글로벌 네트워크 토폴로지의 설계를 알리기 위한 중요한 고려 사항 및 권장 사항을 강조합니다.

Important

이 문서는 Azure 잘 설계된 중요 업무용 워크로드 시리즈의 일부입니다. 이 시리즈에 익숙하지 않은 경우 중요 업무용 워크로드로 시작하는 것이 좋습니다.

글로벌 트래픽 라우팅

여러 활성 지역 배포 스탬프를 사용하려면 전역 라우팅 서비스가 각 활성 스탬프에 트래픽을 분산해야 합니다.

Azure Front Door, Azure Traffic Manager 및 Azure 표준 Load Balancer 다중 지역 애플리케이션에서 글로벌 트래픽을 관리하는 데 필요한 라우팅 기능을 제공합니다.

또는 타사 전역 라우팅 기술을 고려할 수 있습니다. 이러한 옵션은 Azure 네이티브 글로벌 라우팅 서비스의 사용을 대체하거나 확장하기 위해 거의 원활하게 교환될 수 있습니다. 인기 있는 선택 항목에는 CDN 공급자의 라우팅 기술이 포함됩니다.

이 섹션에서는 Azure 라우팅 서비스가 서로 다른 시나리오를 최적화하는 데 사용할 수 있는 방법을 정의하는 주요 차이점을 살펴봅니다.

디자인 고려 사항

• 단일 지역에 바인딩된 라우팅 서비스는 단일 실패 지점 및 지역 중단과 관련된 중대한 위험을 나타냅니다.

• 애플리케이션 워크로드가 모바일 또는 데스크톱 클라이언트 애플리케이션과 같은 클라이언트 제어를 포함하는 경우 클라이언트 라우팅 논리 내에서 서비스 중복도를 제공할 수 있습니다.

  • Azure Front Door 및 Azure Traffic Manager와 같은 여러 글로벌 라우팅 기술은 중복도를 위해 병렬로 고려할 수 있으며, 클라이언트는 특정 오류 조건이 충족될 때 대체 기술로 장애 조치(failover)하도록 구성됩니다. 여러 글로벌 라우팅 서비스가 도입되면 에지 캐싱 및 웹 애플리케이션 방화벽 기능과 SSL 오프로드에 대한 인증서 관리 및 수신 경로에 대한 애플리케이션 유효성 검사와 관련하여 상당한 복잡성이 발생합니다.
  • 타사 기술을 고려할 수도 있으며, 모든 수준의 Azure 플랫폼 오류에 대한 글로벌 라우팅 복원력을 제공합니다.

• Azure Front Door와 Traffic Manager 간의 기능 차이는 두 기술이 중복성을 위해 서로 나란히 배치되는 경우 일관되고 허용 가능한 서비스 수준을 유지하기 위해 다른 수신 경로 또는 디자인 변경이 필요하다는 것을 의미합니다.

• Azure Front Door 및 Azure Traffic Manager는 기본 제공 다중 지역 중복 및 가용성을 갖춘 전역적으로 분산된 서비스입니다.

  • 이러한 복원력 있는 라우팅 서비스의 글로벌 가용성을 위협할 만큼 큰 규모의 가상 오류 시나리오는 연계 및 상관 관계 오류 측면에서 애플리케이션에 더 광범위한 위험을 제공합니다.
    • 이 규모의 오류 시나리오는 거의 모든 Azure 서비스에 대한 글로벌 플랫폼 종속성 역할을 하는 Azure DNS 또는 Microsoft Entra ID와 같은 공유 기본 서비스에 의해서만 가능합니다. 중복 Azure 기술이 적용되는 경우 보조 서비스에 사용할 수 없거나 서비스가 저하될 수 있습니다.
    • 글로벌 라우팅 서비스 오류 시나리오는 서비스 간 종속성을 통해 주요 애플리케이션 구성 요소에 사용되는 다른 많은 서비스에 큰 영향을 미칠 가능성이 높습니다. 타사 기술을 사용하더라도 기본 문제의 광범위한 영향으로 인해 애플리케이션이 비정상 상태가 될 수 있습니다. 즉, Azure의 애플리케이션 엔드포인트로 라우팅하면 아무런 가치가 없습니다.

• 글로벌 라우팅 서비스 중복성은 글로벌 중단의 영향이 라우팅 서비스 자체에 제한되는 매우 적은 수의 가상 오류 시나리오에 대한 완화를 제공합니다.

  글로벌 중단 시나리오에 더 광범위한 중복성을 제공하기 위해 다중 클라우드 활성-활성 배포 접근 방식을 고려할 수 있습니다. 다중 클라우드 활성-활성 배포 접근 방식은 상당한 운영 복잡성을 도입하여 상당한 복원력 위험을 초래하며, 이는 글로벌 중단의 가상 위험을 훨씬 능가할 수 있습니다.

• 클라이언트 제어가 불가능한 시나리오의 경우 단일 글로벌 라우팅 서비스에 대한 종속성을 가져와 모든 활성 배포 지역에 대한 통합 진입점을 제공해야 합니다.

  • 격리에서 사용되는 경우 기본 제공 다중 지역 중복 및 가용성이 제공되더라도 전역 종속성으로 인해 서비스 수준에서 단일 실패 지점을 나타냅니다.
  • 선택한 글로벌 라우팅 서비스에서 제공하는 SLA는 고려되는 배포 지역 수에 관계없이 달성 가능한 최대 복합 SLO를 나타냅니다.

• 클라이언트 제어가 불가능한 경우 전역 중단으로 주 서비스를 사용하지 않도록 설정하는 경우 운영 완화를 고려하여 보조 전역 라우팅 서비스로 마이그레이션하는 프로세스를 정의할 수 있습니다. 한 글로벌 라우팅 서비스에서 다른 전역 라우팅 서비스로 마이그레이션하는 것은 일반적으로 몇 시간 동안 지속되는 긴 프로세스이며, 특히 DNS 전파가 고려됩니다.

• 일부 타사 글로벌 라우팅 서비스는 100% SLA를 제공합니다. 그러나 이러한 서비스에서 제공하는 기록적이고 달성 가능한 SLA는 일반적으로 100%보다 낮습니다.

  • 이러한 서비스는 사용 불가에 대한 재정적 배상을 제공하지만, 인간의 생명이 궁극적으로 위험에 처한 안전에 중요한 시나리오와 같이 사용 불가의 영향이 중요할 때는 거의 의미가 없습니다. 따라서 보급된 법적 SLA가 100%인 경우에도 기술 중복성 또는 충분한 운영 완화를 고려해야 합니다.

Azure Front Door

• Azure Front Door는 분할 TCP가 있는 Anycast 프로토콜을 사용하여 글로벌 HTTP/S 부하 분산 및 최적화된 연결을 제공하여 Microsoft 글로벌 백본 네트워크를 이용합니다.

  • 각 백 엔드 엔드포인트에 대해 여러 연결이 유지됩니다.
  • 들어오는 클라이언트 요청은 원래 클라이언트와 가장 가까운 에지 노드에서 먼저 종료됩니다.
  • 필요한 트래픽 검사 후 요청은 기존 연결을 사용하여 Microsoft 백본을 통해 적절한 백 엔드로 전달되거나 에지 노드의 내부 캐시에서 제공됩니다.
  • 이 방법은 백 엔드 연결을 통해 높은 트래픽 볼륨을 분산하는 데 효율적입니다.

• 에지 노드의 정적 콘텐츠를 제공하는 기본 제공 캐시를 제공합니다. 대부분의 사용 사례에서는 전용 CDN(Content Delivery Network)이 필요하지 않습니다.

• Azure Front Door에서 WAF(Azure Web Application Firewall)를 사용할 수 있으며, 전 세계 Azure 네트워크 에지 위치에 배포되기 때문에 Front Door에서 들어오는 모든 요청이 네트워크 에지에서 검사됩니다.

• Azure Front Door는 Azure DDoS Protection Basic을 사용하여 DDoS 공격으로부터 애플리케이션 엔드포인트를 보호합니다. Azure DDoS Standard는 추가적인 고급 보호 및 검색 기능을 제공하며 Azure Front Door에 추가 계층으로 추가할 수 있습니다.

• Azure Front Door는 완전 관리형 인증서 서비스를 제공합니다. 인증서 수명 주기를 관리할 필요 없이 엔드포인트에 대한 TLS 연결 보안을 사용하도록 설정합니다.

• Azure Front Door Premium은 프라이빗 엔드포인트를 지원하므로 트래픽이 인터넷에서 Azure 가상 네트워크로 직접 흐를 수 있습니다. 이렇게 하면 Azure Front Door Premium을 통해 백 엔드에 액세스할 수 있도록 VNet에서 공용 IP를 사용할 필요가 없습니다.

• Azure Front Door는 정상 상태를 반영하는 HTTP 200(정상) 응답과 함께 백 엔드가 정상적으로 작동하는 경우를 반영하는 HTTP 상태 코드를 반환하기 위해 간격별로 호출되는 상태 프로브 및 백 엔드 상태 엔드포인트(URL)를 사용합니다. 백 엔드가 비정상 상태를 반영하는 즉시 특정 에지 노드의 관점에서 해당 에지 노드는 요청 전송을 중지합니다. 따라서 비정상 백 엔드는 지연 없이 트래픽 순환에서 투명하게 제거됩니다.

• HTTP/S 프로토콜만 지원합니다.

• Azure Front Door WAF 및 Application Gateway WAF는 약간 다른 기능 집합을 제공하지만 기본 제공 규칙과 사용자 지정 규칙을 모두 지원하며 검색 모드 또는 방지 모드에서 작동하도록 설정할 수 있습니다.

• Front Door 백 엔드 IP 공간은 변경될 수 있지만 Microsoft는 Azure IP 범위 및 서비스 태그와의 통합을 보장합니다. Azure IP 범위 및 서비스 태그를 구독하여 변경 내용 또는 업데이트에 대한 알림을 받을 수 있습니다.

• Azure Front Door는 다양한 부하 분산 구성을 지원합니다.

  • 대기 시간 기반: 클라이언트에서 "가장 가까운" 백 엔드로 트래픽을 라우팅하는 기본 설정입니다. 요청 대기 시간에 기반합니다.
  • 우선 순위 기반: 활성-수동 설정에 유용하며, 트래픽을 사용할 수 없는 한 항상 기본 백 엔드로 전송해야 합니다.
  • 가중치: 특정 트래픽 비율이 특정 백 엔드로 전송되는 카나리아 배포에 적용됩니다. 여러 백 엔드에 동일한 가중치가 할당된 경우 대기 시간 기반 라우팅이 사용됩니다.

• 기본적으로 Azure Front Door는 클라이언트가 시작된 위치에 따라 일부 백 엔드가 다른 백 엔드보다 훨씬 더 많은 들어오는 트래픽을 가져오는 상황으로 이어질 수 있는 대기 시간 기반 라우팅을 사용합니다.

• 동일한 백 엔드에서 일련의 클라이언트 요청을 처리해야 하는 경우 프런트 엔드 에서 세션 선호도 를 구성할 수 있습니다. 백 엔드를 계속 사용할 수 있는 경우 클라이언트 쪽 쿠키를 사용하여 첫 번째 요청과 동일한 백 엔드에 후속 요청을 보냅니다.

Azure Traffic Manager

• Azure Traffic Manager는 DNS 리디렉션 서비스입니다.

  • 실제 요청 페이로드는 처리되지 않지만 Traffic Manager는 선택한 트래픽 라우팅 방법에 대해 구성된 규칙에 따라 풀에 있는 백 엔드 중 하나의 DNS 이름을 반환합니다.
  • 그런 다음 백 엔드 DNS 이름이 클라이언트에서 직접 호출되는 최종 IP 주소로 확인됩니다.

• DNS 응답은 지정된 TTL(Time To Live) 기간 동안 클라이언트에서 캐시되고 다시 사용되며, 이 기간 동안 수행된 요청은 Traffic Manager 상호 작용 없이 백 엔드 엔드포인트로 직접 이동합니다. Front Door에 비해 비용 이점을 제공하는 추가 연결 단계를 제거합니다.

• 요청은 클라이언트에서 백 엔드 서비스로 직접 이루어지므로 백 엔드에서 지원하는 모든 프로토콜을 활용할 수 있습니다.

• Azure Front Door와 마찬가지로 Azure Traffic Manager는 상태 프로브를 사용하여 백 엔드가 정상이고 정상적으로 작동하는지 파악합니다. 다른 값이 반환되거나 아무것도 반환되지 않으면 라우팅 서비스는 진행 중인 문제를 인식하고 해당 특정 백 엔드에 대한 요청 라우팅을 중지합니다.

  • 그러나 Azure Front Door와 달리 클라이언트는 DNS TTL이 만료되고 Traffic Manager 서비스에서 새 백 엔드 엔드포인트가 요청될 때까지 비정상 백 엔드에 대한 연결을 계속 만들기 때문에 비정상 백 엔드 제거는 즉시 수행되지 않습니다.
  • 또한 TTL이 만료되더라도 공용 DNS 서버가 이 값을 적용한다는 보장은 없으므로 DNS 전파가 실제로 발생하는 데 훨씬 더 오래 걸릴 수 있습니다. 즉, 트래픽이 일정 기간 동안 비정상 엔드포인트로 계속 전송될 수 있습니다.

Azure 표준 Load Balancer

Important

지역 간 표준 Load Balancer 기술적 제한 사항과 함께 미리 보기로 제공됩니다. 이 옵션은 중요 업무용 워크로드에는 권장되지 않습니다.

디자인 권장 사항

• HTTP/S 시나리오에 대한 기본 글로벌 트래픽 라우팅 서비스로 Azure Front Door를 사용합니다. Azure Front Door는 최적화된 트래픽 라우팅, 투명한 장애 조치( failover), 프라이빗 백 엔드 엔드 엔드포인트(프리미엄 SKU 사용), 에지 캐싱 및 WAF(웹 애플리케이션 방화벽)와의 통합을 제공하므로 HTTP/S 워크로드를 강력하게 옹호합니다.

• 클라이언트 제어가 가능한 애플리케이션 시나리오의 경우 클라이언트 쪽 라우팅 논리를 적용하여 기본 글로벌 라우팅 기술이 실패하는 장애 조치(failover) 시나리오를 고려합니다. 단일 서비스 SLA가 충분하지 않은 경우 중복성을 추가하기 위해 두 개 이상의 글로벌 라우팅 기술을 병렬로 배치해야 합니다. 글로벌 서비스 장애가 발생할 경우 중복 기술로 라우팅하려면 클라이언트 논리가 필요합니다.

  • 장애 조치(failover)에 대한 전체 인증서 관리 환경 및 라우팅 논리를 간소화하기 위해 서로 다른 각 글로벌 라우팅 서비스에 각각 적용되는 두 개의 고유 URL을 사용해야 합니다.
  • 가장 많은 수의 글로벌 오류 시나리오를 완화하고 업계 최고의 CDN 공급자가 제공하는 기능을 통해 일관된 디자인 접근 방식을 허용하므로 타사 라우팅 기술을 보조 장애 조치(failover) 서비스로 사용하는 우선 순위를 지정합니다.
  • 또한 별도의 라우팅 서비스가 아닌 단일 지역 스탬프로 직접 라우팅할 때도 고려해야 합니다. 이로 인해 서비스 수준이 저하되지만 훨씬 더 간단한 디자인 접근 방식을 나타냅니다.

이 이미지는 Azure Front Door를 기본 글로벌 부하 분산 장치로 사용하는 클라이언트 장애 조치(failover)를 사용하는 중복 글로벌 부하 분산 장치 구성을 보여줍니다.

Important

Azure 플랫폼 내에서 글로벌 오류의 위험을 진정으로 완화하려면 둘 이상의 클라우드 공급자에서 호스트되는 활성 배포 스탬프와 글로벌 라우팅에 사용되는 중복 타사 라우팅 기술을 사용하여 다중 클라우드 활성-활성 배포 접근 방식을 고려해야 합니다.

Azure는 다른 클라우드 플랫폼과 효과적으로 통합될 수 있습니다. 그러나 여러 클라우드 플랫폼에서 다양한 배포 스탬프 정의 및 운영 상태를 표현하여 상당한 운영 복잡성을 도입하기 때문에 다중 클라우드 접근 방식을 적용하지 않는 것이 좋습니다. 이러한 복잡성은 애플리케이션의 정상적인 작동 내에서 수많은 복원력 위험을 발생시킵니다. 이는 글로벌 플랫폼 중단의 가상 위험보다 훨씬 큽니다.

• 권장되지는 않지만 Azure Front Door에 대한 글로벌 라우팅 중복성을 위해 Azure Traffic Manager를 사용하는 HTTP 워크로드의 경우 Azure Front Door를 통해 흐르는 허용 가능한 트래픽을 위해 WAF(웹 애플리케이션 방화벽)를 Application Gateway로 오프로드하는 것이 좋습니다.
  • 이렇게 하면 표준 수신 경로에 대한 추가 오류 지점, 관리 및 크기를 조정하는 추가 중요 경로 구성 요소가 도입되며 글로벌 고가용성을 보장하기 위해 추가 비용이 발생합니다. 그러나 WAF 실행뿐만 아니라 프라이빗 애플리케이션 엔드포인트 측면에서도 Azure Front Door 및 Azure Traffic Manager를 통해 허용 가능한 수신 경로와 허용되지 않는 수신 경로 간에 일관성을 제공하여 오류 시나리오를 크게 간소화합니다.
  • 오류 시나리오에서 에지 캐싱이 손실되면 전반적인 성능에 영향을 미치며, 이는 허용 가능한 서비스 수준 또는 완화 디자인 접근 방식과 일치해야 합니다. 일관된 서비스 수준을 보장하려면 두 경로 모두에 대해 타사 CDN 공급자로 에지 캐싱을 오프로드하는 것이 좋습니다.

두 개의 Azure 글로벌 라우팅 서비스 대신 타사 글로벌 라우팅 서비스를 고려하는 것이 좋습니다. 대부분의 업계 최고의 CDN 공급자가 Azure Front Door에서 제공하는 것과 거의 일치하는 에지 기능을 제공하므로 이는 최대 수준의 오류 완화와 보다 단순한 디자인 방식을 제공합니다.

Azure Front Door

• Azure Front Door 관리 인증서 서비스를 사용하여 TLS 연결을 사용하도록 설정하고 인증서 수명 주기를 관리할 필요가 없습니다.

• Azure Front Door WAF(웹 애플리케이션 방화벽)를 사용하여 SQL 삽입과 같은 일반적인 웹 악용 및 취약성으로부터 에지에서 보호를 제공합니다.

• Azure Front Door 기본 제공 캐시를 사용하여 에지 노드의 정적 콘텐츠를 제공합니다.

  • 대부분의 경우 이렇게 하면 전용 CDN(Content Delivery Network)이 필요하지 않습니다.

• X-Azure-FDID를 사용하여 헤더 기반 필터링을 통해 들어오는 요청의 유효성을 검사하도록 애플리케이션 플랫폼 수신 지점을 구성하여 구성된 Front Door 인스턴스를 통해 모든 트래픽이 흐르는지 확인합니다. 또한 Azure Front Door 백 엔드 IP 주소 공간 및 Azure 인프라 서비스에서 발생하는 트래픽의 유효성을 검사하기 위해 Front Door 서비스 태그를 사용하여 IP ACL을 구성하는 것이 좋습니다. 이렇게 하면 서비스 수준에서 Azure Front Door를 통해 트래픽이 흐르지만 구성된 Front Door 인스턴스를 사용하려면 헤더 기반 필터링이 계속 필요합니다.

• 기본 참조 구현에서 제공하는 예제에서 Azure Cosmos DB와 같은 데이터 플랫폼 복제본을 포함하여 지역 배포 스탬프 내에서 중요한 다운스트림 종속성 유효성을 검사하는 사용자 지정 TCP 상태 엔드포인트를 정의합니다. 하나 이상의 종속성이 비정상이 되면 상태 프로브는 전체 지역 스탬프를 순환에서 제거할 수 있도록 반환된 응답에 이를 반영해야 합니다.

• 상태 프로브 응답이 기록되고 Azure Front Door에 의해 노출된 모든 운영 데이터를 전역 Log Analytics 작업 영역으로 수집하여 전체 애플리케이션에서 통합 데이터 싱크 및 단일 운영 보기를 용이하게 합니다.

• 워크로드가 대기 시간이 매우 중요한 경우가 아니면 배포된 리소스를 가장 효과적으로 사용하기 위해 고려되는 모든 지역 스탬프에 트래픽을 균등하게 분산합니다.

  • 이렇게 하려면 "대기 시간 민감도(추가 대기 시간)" 매개 변수를 백 엔드의 서로 다른 지역 간의 대기 시간 차이에 맞게 충분히 높은 값으로 설정합니다. 전체 클라이언트 요청 대기 시간과 관련하여 애플리케이션 워크로드에 허용되는 허용 오차를 확인합니다.

• 애플리케이션에서 요구하지 않는 한 세션 선호도는 트래픽 분산의 균형에 부정적인 영향을 미칠 수 있으므로 사용하도록 설정하지 마세요. 완전히 상태 비저장 애플리케이션을 사용하면 권장되는 중요 업무용 애플리케이션 디자인 접근 방식을 따르는 경우 모든 요청을 지역 배포에서 처리할 수 있습니다.

Azure Traffic Manager

• Azure Front Door의 대체로 HTTP/S가 아닌 시나리오에 Traffic Manager를 사용합니다. 기능 차이로 인해 캐시 및 WAF 기능, TLS 인증서 관리에 대한 다양한 디자인 결정이 이루어집니다.

• WAF 기능은 Azure 애플리케이션 게이트웨이를 사용하여 Traffic Manager 수신 경로에 대한 각 지역 내에서 고려해야 합니다.

• 백 엔드가 비정상 상태가 되는 경우 비정상 백 엔드 엔드 엔드포인트를 순환에서 제거하는 데 필요한 시간을 최적화하도록 적절하게 낮은 TTL 값을 구성합니다.

• Azure Front Door와 마찬가지로 상태 엔드포인트에서 제공하는 응답에 반영되어야 하는 지역 배포 스탬프 내에서 중요한 다운스트림 종속성 유효성을 검사하도록 사용자 지정 TCP 상태 엔드포인트를 정의해야 합니다.

  그러나 Traffic Manager의 경우 서비스 수준 지역 장애 조치(failover)에 대한 추가 고려 사항을 제공해야 합니다. 'dog legging'과 같이 종속성 오류로 인한 비정상 백 엔드 제거와 관련된 잠재적 지연을 완화하기 위해, 특히 DNS 레코드에 대해 낮은 TTL을 설정할 수 없는 경우

• Azure Traffic Manager를 기본 글로벌 라우팅 서비스로 사용할 때 에지 캐싱을 달성하려면 타사 CDN 공급자에게 고려해야 합니다. 타사 서비스에서도 에지 WAF 기능을 제공하는 경우 수신 경로를 간소화하고 Application Gateway의 필요성을 제거하기 위해 고려해야 합니다.

애플리케이션 전달 서비스

중요 업무용 애플리케이션의 네트워크 수신 경로는 안전하고 안정적이며 확장 가능한 수신 트래픽을 보장하기 위해 애플리케이션 배달 서비스도 고려해야 합니다.

이 섹션은 Azure 표준 Load Balancer, Azure 애플리케이션 Gateway 및 Azure API Management와 같은 관련 서비스를 고려하여 주요 애플리케이션 배달 기능을 탐색하여 글로벌 라우팅 권장 사항을 기반으로 합니다.

디자인 고려 사항

• TLS 암호화는 중요 업무용 애플리케이션에 대한 인바운드 사용자 트래픽의 무결성을 보장하는 데 중요하며, 들어오는 트래픽의 암호를 해독하기 위해 스탬프 수신 지점에서만 TLS 오프로드가 적용됩니다. TLS 오프로드 트래픽을 해독하려면 TLS 인증서의 프라이빗 키가 필요합니다.

• 웹 애플리케이션 방화벽은 SQL 삽입 또는 사이트 간 스크립팅과 같은 일반적인 웹 악용 및 취약성에 대한 보호를 제공하며 중요 업무용 애플리케이션의 최대 안정성 포부를 달성하는 데 필수적입니다.

• Azure WAF는 관리형 규칙 집합을 사용하여 상위 10개의 OWASP 취약성에 대한 기본 제공 보호를 제공합니다.

  • 사용자 지정 규칙을 추가하여 관리되는 규칙 집합을 확장할 수도 있습니다.
  • Azure WAF는 Azure Front Door, Azure 애플리케이션 Gateway 또는 Azure CDN(현재 공개 미리 보기)에서 사용하도록 설정할 수 있습니다.
    • 각 서비스에서 제공되는 기능은 약간 다릅니다. 예를 들어 Azure Front Door WAF는 Application Gateway WAF 내에서 아직 제공되지 않는 속도 제한, 지역 필터링 및 봇 보호를 제공합니다. 그러나 모두 기본 제공 규칙과 사용자 지정 규칙을 모두 지원하며 검색 모드 또는 방지 모드에서 작동하도록 설정할 수 있습니다.
    • Azure WAF에 대한 로드맵은 모든 서비스 통합에서 일관된 WAF 기능 집합이 제공되도록 합니다.

• NVA 및 Kubernetes 내의 고급 수신 컨트롤러와 같은 타사 WAF 기술도 필수 취약성 보호를 제공하는 것으로 간주될 수 있습니다.

• 최적의 WAF 구성에는 일반적으로 사용되는 기술에 관계없이 미세 조정이 필요합니다.

  Azure Front Door

• Azure Front Door는 HTTP 및 HTTPS 트래픽만 허용하며 알려진 Host 헤더를 사용하여 요청만 처리합니다. 이 프로토콜 차단은 프로토콜 및 포트에 분산된 대량 공격, DNS 증폭 및 TCP 중독 공격을 완화하는 데 도움이 됩니다.

• Azure Front Door는 전역 Azure 리소스이므로 구성은 모든 에지 위치에 전역적으로 배포됩니다.

  • 리소스 구성을 대규모로 배포하여 초당 수십만 개의 요청을 처리할 수 있습니다.
  • 경로 및 백 엔드 풀을 비롯한 구성 업데이트는 원활하며 배포 중에 가동 중지 시간이 발생하지 않습니다.

• Azure Front Door는 클라이언트 쪽 SSL 인증서에 대해 완전 관리형 인증서 서비스와 사용자 고유의 인증서 가져오기 방법을 모두 제공합니다. 완전 관리형 인증서 서비스는 간소화된 운영 방식을 제공하며 솔루션의 단일 영역 내에서 인증서 관리를 수행하여 전체 디자인의 복잡성을 줄이는 데 도움이 됩니다.

• Azure Front Door는 만료된 인증서 위험으로부터 보호하기 위해 인증서 만료 최소 60일 전에 "관리되는" 인증서를 자동으로 회전합니다. 자체 관리형 인증서를 사용하는 경우 기존 인증서가 만료되기 24시간 전에 업데이트된 인증서를 배포해야 합니다. 그렇지 않으면 클라이언트가 만료된 인증서 오류를 받을 수 있습니다.

• 인증서 업데이트는 Azure Front Door가 "관리됨"과 "사용자 고유의 인증서 사용" 간에 전환되는 경우에만 가동 중지 시간이 발생합니다.

• Azure Front Door는 기본적으로 Front Door에 통합된 Azure DDoS Protection Basic으로 보호됩니다. 이를 통해 항상 트래픽 모니터링, 실시간 완화를 제공하고 일반적인 계층 7 DNS 쿼리 홍수 또는 계층 3/4 볼륨 공격도 방어합니다.

  • 이러한 보호 기능은 DDoS 공격에 직면한 경우에도 Azure Front Door 가용성을 유지하는 데 도움이 됩니다. DDoS(분산 서비스 거부) 공격은 불법 트래픽으로 인해 대상 리소스를 사용할 수 없게 만들 수 있습니다.

• 또한 Azure Front Door는 전역 트래픽 수준에서 WAF 기능을 제공하지만 Application Gateway WAF는 각 지역 배포 스탬프 내에 제공되어야 합니다. 기능에는 일반적인 공격, 지역 필터링, 주소 차단, 속도 제한 및 서명 일치로부터 보호하기 위한 방화벽 규칙 집합이 포함됩니다.

  Azure Load Balancer

• Azure Basic Load Balancer SKU는 SLA에서 지원되지 않으며 표준 SKU에 비해 몇 가지 기능 제약 조건이 있습니다.

디자인 권장 사항

• 인증서 관리 수명 주기를 간소화하는 동시에 보안을 유지하기 위해 가능한 한 적은 위치에서 TLS 오프로드를 수행합니다.

• TLS 오프로드가 발생하는 지점에서 실제 애플리케이션 백 엔드로 암호화된 연결(예: HTTPS)을 사용합니다. 애플리케이션 엔드포인트는 최종 사용자에게 표시되지 않으므로 관리되는 인증서와 같은 azurewebsites.net Azure 관리형 도메인을 cloudapp.net사용할 수 있습니다.

• HTTP(S) 트래픽의 경우 WAF 기능이 공개적으로 노출된 모든 엔드포인트의 수신 경로 내에 적용되는지 확인합니다.

• 구성 미세 조정을 간소화하고 성능 및 비용을 최적화하므로 Azure Front Door를 사용하여 전역적으로 또는 Azure 애플리케이션 Gateway를 사용하여 지역적으로 단일 서비스 위치에서 WAF 기능을 사용하도록 설정합니다.

  공격을 직접 차단하려면 예방 모드에서 WAF를 구성합니다. 예방 모드의 성능 저하가 너무 높을 경우 검색 모드(즉, 로깅만 하고 의심스러운 요청은 차단하지 않음)에서만 WAF를 사용합니다. 내재된 추가 위험을 완전히 이해하고 워크로드 시나리오의 특정 요구 사항에 맞게 조정해야 합니다.

• Azure Front Door WAF는 가장 풍부한 Azure 네이티브 기능 집합을 제공하고 글로벌 에지에서 보호를 적용하여 전체 디자인을 간소화하고 효율성을 향상시키므로 사용 우선 순위를 지정합니다.

• 많은 수의 API를 외부 클라이언트 또는 다른 애플리케이션 팀에 노출하는 경우에만 Azure API Management를 사용합니다.

• 마이크로 서비스 워크로드 내의 내부 트래픽 분산 시나리오에는 Azure 표준 Load Balancer SKU를 사용합니다.

  • 가용성 영역 배포할 때 99.99%의 SLA를 제공합니다.
  • 진단 또는 아웃바운드 규칙과 같은 중요한 기능을 제공합니다.

• Azure DDoS 네트워크 보호를 사용하여 각 애플리케이션 가상 네트워크 내에서 호스트되는 퍼블릭 엔드포인트를 보호합니다.

캐싱 및 정적 콘텐츠 배달

이미지, JavaScript, CSS 및 기타 파일과 같은 정적 콘텐츠를 특별하게 처리하면 전체 사용자 환경과 솔루션의 전체 비용에 큰 영향을 미칠 수 있습니다. 에지에서 정적 콘텐츠를 캐싱하면 클라이언트 로드 시간이 단축되어 사용자 환경이 향상될 수 있으며, 관련된 백 엔드 서비스에서 트래픽, 읽기 작업 및 컴퓨팅 성능에 대한 비용을 줄일 수도 있습니다.

디자인 고려 사항

• 솔루션을 인터넷을 통해 사용할 수 있는 모든 콘텐츠가 동적으로 생성되는 것은 아닙니다. 애플리케이션은 정적 자산(이미지, JavaScript, CSS, 지역화 파일 등)과 동적 콘텐츠를 모두 제공합니다.
• 자주 액세스하는 정적 콘텐츠가 있는 워크로드는 백 엔드 서비스의 부하를 줄이고 최종 사용자의 콘텐츠 액세스 대기 시간을 줄이므로 캐싱을 통해 큰 이점을 얻을 수 있습니다.
• 캐싱은 Azure Front Door 또는 Azure CDN(Content Delivery Network)을 사용하여 Azure 내에서 기본적으로 구현할 수 있습니다.
  • Azure Front Door 는 정적 및 동적 콘텐츠를 분할하는 Azure 네이티브 에지 캐싱 기능 및 라우팅 기능을 제공합니다.
    • Azure Front Door /static/* 에서 적절한 라우팅 규칙을 만들면 트래픽을 정적 콘텐츠로 투명하게 리디렉션할 수 있습니다.
  • Azure CDN 서비스를 사용하여 보다 복잡한 캐싱 시나리오를 구현하여 중요한 정적 콘텐츠 볼륨에 대한 본격적인 콘텐츠 배달 네트워크를 설정할 수 있습니다.
    • Azure CDN 서비스는 비용 효율적일 수 있지만 애플리케이션 디자인의 다른 영역에 권장되는 것과 동일한 고급 라우팅 및 WAF(웹 애플리케이션 방화벽) 기능을 제공하지는 않습니다. 그러나 Akamai 및 Verizon과 같은 타사 솔루션의 유사한 서비스와 통합할 수 있는 유연성을 제공합니다.
  • Azure Front Door 및 Azure CDN 서비스를 비교할 때 다음 의사 결정 요소를 탐색해야 합니다.
    • 규칙 엔진을 사용하여 필요한 캐싱 규칙을 수행할 수 있습니다.
    • 저장된 콘텐츠의 크기 및 관련 비용입니다.
    • 규칙 엔진 실행에 대한 월별 가격입니다(Azure Front Door의 요청당 청구됨).
    • 아웃바운드 트래픽 요구 사항(가격은 대상마다 다릅니다).

디자인 권장 사항

• 변경되지 않거나 거의 변경되지 않는 이미지 파일의 크기가 큰 복사본과 같은 정적 콘텐츠가 생성되면 캐싱의 이점을 얻을 수 있습니다. 캐싱은 URL 매개 변수 및 다양한 캐싱 기간에 따라 구성할 수 있습니다.
• 사용자에게 정적 콘텐츠와 동적 콘텐츠를 분리하고 캐시에서 관련 콘텐츠를 제공하여 백 엔드 서비스의 로드를 줄이고 최종 사용자를 위한 성능을 최적화합니다.
• 글로벌 라우팅 및 WAF(웹 애플리케이션 방화벽)를 위해 Azure Front Door를 사용하는 강력한 권장 사항(네트워크 및 연결 디자인 영역)을 고려할 때, 간격이 없는 한 Azure Front Door 캐싱 기능의 사용 우선 순위를 지정하는 것이 좋습니다.

가상 네트워크 통합

중요 업무용 애플리케이션은 일반적으로 Azure, 다른 퍼블릭 클라우드 또는 온-프레미스 데이터 센터에서 호스팅될 수 있는 다른 애플리케이션 또는 종속 시스템과의 통합 요구 사항을 포함합니다. 이 애플리케이션 통합은 네트워크 수준 통합을 통해 공용 엔드포인트 및 인터넷 또는 프라이빗 네트워크를 사용하여 수행할 수 있습니다. 궁극적으로 애플리케이션 통합을 달성하는 방법은 솔루션의 보안, 성능 및 안정성에 상당한 영향을 미치며 다른 디자인 영역 내의 디자인 결정에 큰 영향을 줍니다.

중요 업무용 애플리케이션은 네트워크 수준에서 애플리케이션 통합이 발생할 수 있는 방법을 결정하는 세 가지 가장 중요한 네트워크 구성 중 하나 내에 배포할 수 있습니다.

1. 회사 네트워크 연결이 없는 공용 애플리케이션입니다.
2. 회사 네트워크 연결이 있는 공용 애플리케이션입니다.
3. 회사 네트워크 연결이 있는 프라이빗 애플리케이션.

주의

Azure 랜딩 존 내에 배포하는 경우 구성 1. 는 온라인 랜딩 존 내에 배포되어야 하며, 2) 및 3) 네트워크 수준 통합을 용이하게 하기 위해 Corp. 연결된 랜딩 존 내에 배포해야 합니다.

이 섹션에서는 통합 요구 사항을 최적으로 충족할 수 있도록 Azure Virtual Networks 및 주변 Azure 네트워킹 서비스를 적절히 사용하여 계층화하여 이러한 네트워크 통합 시나리오를 살펴봅니다.

디자인 고려 사항

가상 네트워크 없음

• 가장 간단한 디자인 방법은 가상 네트워크 내에 애플리케이션을 배포하지 않는 것입니다.

  • 고려되는 모든 Azure 서비스 간의 연결은 퍼블릭 엔드포인트와 Microsoft Azure 백본을 통해 전적으로 제공됩니다. Azure에서 호스트되는 퍼블릭 엔드포인트 간의 연결은 Microsoft 백본만 트래버스하고 공용 인터넷을 통해 이동하지 않습니다.
  • Azure 외부의 모든 외부 시스템에 대한 연결은 공용 인터넷에서 제공됩니다.

• 이 디자인 접근 방식은 다양한 서비스 구성 요소와 종속 솔루션 간에 액세스 제어를 제공하기 위해 "ID를 보안 경계로"채택합니다. 이는 보안에 덜 민감한 시나리오에 적합한 솔루션일 수 있습니다. 모든 애플리케이션 서비스 및 종속성은 퍼블릭 엔드포인트를 통해 액세스할 수 있으므로 권한 없는 액세스 권한을 얻는 데 중심이 되는 추가 공격 벡터에 취약합니다.

• AKS와 같은 많은 서비스에는 기본 가상 네트워크에 대한 하드 요구 사항이 있으므로 이 디자인 접근 방식은 일부 Azure 서비스에도 적용되지 않습니다.

격리된 가상 네트워크

• 불필요한 퍼블릭 엔드포인트와 관련된 위험을 완화하기 위해 애플리케이션을 다른 네트워크에 연결되지 않은 독립 실행형 네트워크 내에 배포할 수 있습니다.

• 들어오는 클라이언트 요청은 여전히 퍼블릭 엔드포인트를 인터넷에 노출해야 하지만 모든 후속 통신은 프라이빗 엔드포인트를 사용하여 가상 네트워크 내에 있을 수 있습니다. Azure Front Door Premium을 사용하는 경우 에지 노드에서 프라이빗 애플리케이션 엔드포인트로 직접 라우팅할 수 있습니다.

• 애플리케이션 구성 요소 간의 프라이빗 연결은 가상 네트워크를 통해 발생하지만 외부 종속성을 사용하는 모든 연결은 여전히 퍼블릭 엔드포인트에 의존합니다.

  • 지원되는 경우 프라이빗 엔드포인트를 사용하여 Azure 플랫폼 서비스에 대한 연결을 설정할 수 있습니다. 다른 다운스트림 애플리케이션과 같은 다른 외부 종속성이 Azure에 있는 경우 퍼블릭 엔드포인트 및 Microsoft Azure 백본을 통해 연결이 제공됩니다.
  • Azure 외부의 모든 외부 시스템에 대한 연결은 공용 인터넷에서 제공됩니다.

• 외부 종속성에 대한 네트워크 통합 요구 사항이 없는 시나리오의 경우 격리된 네트워크 환경 내에서 솔루션을 배포하면 디자인 유연성이 극대화됩니다. 광범위한 네트워크 통합과 관련된 주소 지정 및 라우팅 제약 조건이 없습니다.

• Azure Bastion은 가상 네트워크에 배포할 수 있고 Azure VM에 대한 보안 RDP/SSH 연결을 제공하는 완전 플랫폼 관리 PaaS 서비스입니다. Azure Bastion을 통해 연결하는 경우 가상 머신에 공용 IP 주소가 필요하지 않습니다.

• 애플리케이션 가상 네트워크를 사용하면 애플리케이션 배포를 용이하게 하기 위해 프라이빗 네트워크에서 호스트되는 리소스에 대한 데이터 평면 및 제어 평면 액세스가 모두 필요하기 때문에 CI/CD 파이프라인 내에서 상당한 배포 복잡성이 발생합니다.

  • CI/CD 도구가 필수 작업을 수행할 수 있도록 보안 프라이빗 네트워크 경로를 설정해야 합니다.
  • 프라이빗 빌드 에이전트는 애플리케이션 가상 네트워크 내에 배포하여 가상 네트워크에서 보호되는 리소스에 대한 프록시 액세스를 수행할 수 있습니다.

연결된 가상 네트워크

• 외부 네트워크 통합 요구 사항이 있는 시나리오의 경우 다양한 연결 옵션을 사용하여 애플리케이션 가상 네트워크를 Azure 내의 다른 가상 네트워크, 다른 클라우드 공급자 또는 온-프레미스 네트워크에 연결할 수 있습니다. 예를 들어 일부 애플리케이션 시나리오에서는 온-프레미스 회사 네트워크 내에서 비공개로 호스트되는 다른 LOB(기간 업무) 애플리케이션과의 애플리케이션 수준 통합을 고려할 수 있습니다.

• 애플리케이션 네트워크 디자인은 특히 주소 지정 및 라우팅과 같은 항목과 관련된 광범위한 네트워크 아키텍처와 일치해야 합니다.

• Azure 지역 또는 온-프레미스 네트워크에서 IP 주소 공간이 겹치면 네트워크 통합이 고려될 때 주요 경합이 발생합니다.

  • 추가 주소 공간을 고려하도록 가상 네트워크 리소스를 업데이트할 수 있지만 피어링된 네트워크의 가상 네트워크 주소 공간이 변경 되면 피어링 링크의 동기화가 필요하므로 일시적으로 피어링을 사용하지 않도록 설정합니다.
  • Azure는 각 서브넷 내에 5개의 IP 주소를 예약합니다. 이 주소는 애플리케이션 가상 네트워크 및 포괄 서브넷에 적절한 크기를 결정할 때 고려해야 합니다.
  • 일부 Azure 서비스에는 Azure Bastion, Azure Firewall 또는 Azure Virtual Network Gateway와 같은 전용 서브넷이 필요합니다. 이러한 서비스 서브넷의 크기는 향후 확장 요구 사항을 고려하여 서비스의 모든 현재 인스턴스를 지원할 만큼 충분히 커야 하지만 불필요하게 주소를 낭비할 만큼 크지는 않기 때문에 매우 중요합니다.

• 온-프레미스 또는 클라우드 간 네트워크 통합이 필요한 경우 Azure는 보안 연결을 설정하는 두 가지 솔루션을 제공합니다.

  • ExpressRoute 회로의 크기를 조정하여 최대 100Gbps의 대역폭을 제공할 수 있습니다.
  • VPN(가상 사설망)의 크기를 조정하여 허브 및 스포크 네트워크에서 최대 10Gbps, Azure Virtual WAN에서 최대 20Gbps까지 집계된 대역폭을 제공할 수 있습니다.

참고 항목

Azure 랜딩 존 내에 배포할 때는 랜딩 존 구현을 통해 온-프레미스 네트워크에 필요한 모든 연결을 제공해야 합니다. 이 디자인은 Virtual WAN 또는 허브 및 스포크 네트워크 디자인을 사용하여 Azure의 ExpressRoute 및 기타 가상 네트워크를 사용할 수 있습니다.

• 추가 네트워크 경로 및 리소스를 포함하면 상태를 유지하기 위해 애플리케이션에 대한 추가 안정성 및 운영 고려 사항이 도입됩니다.

디자인 권장 사항

• 불필요한 공용 엔드포인트를 제거하고 애플리케이션 공격 표면을 제한하여 보안과 안정성을 최대화할 수 있는 경우 Azure Virtual Network 내에 중요 업무용 솔루션을 배포하는 것이 좋습니다.

  • Azure 플랫폼 서비스에 연결하려면 프라이빗 엔드포인트를 사용합니다. 데이터 반출 위험이 허용되거나 대체 제어를 통해 완화되는 경우 Private Link를 지원하지 않는 서비스에 대해 서비스 엔드포인트를 고려할 수 있습니다.

• 회사 네트워크 연결이 필요하지 않은 애플리케이션 시나리오의 경우 모든 가상 네트워크를 새 지역 배포가 수행될 때 바뀌는 임시 리소스로 처리합니다.

• 다른 Azure 또는 온-프레미스 네트워크에 연결할 때 애플리케이션 가상 네트워크는 가상 네트워크 피어링 및 가상 네트워크 게이트웨이 리소스와 관련된 중대한 복잡성을 야기하므로 임시로 취급해서는 안 됩니다. 가상 네트워크 내의 모든 관련 애플리케이션 리소스는 업데이트된 지역 배포 스탬프의 청록색 배포를 용이하게 하는 데 사용되는 병렬 서브넷을 사용하여 계속해서 삭제되어야 합니다.

• 개인 네트워크를 통한 애플리케이션 통합을 촉진하기 위해 회사 네트워크 연결이 필요한 시나리오에서는 지역 애플리케이션 가상 네트워크에 사용되는 IPv4 주소 공간이 연결된 다른 네트워크와 겹치지 않고, 가상 네트워크 리소스를 업데이트하거나 가동 중지 시간을 발생시키지 않고도 필요한 규모를 쉽게 확장할 수 있도록 크기가 적절하게 지정되었는지 확인합니다.

  • 개인 인터넷(RFC 1918)에 대한 주소 할당의 IP 주소만 사용하는 것이 좋습니다.
    • 개인 IP 주소(RFC 1918)의 가용성이 제한된 환경의 경우 IPv6을 사용하는 것이 좋습니다.
    • 공용 IP 주소를 사용해야 하는 경우 소유된 주소 블록만 사용해야 합니다.
  • 애플리케이션 네트워크 IP 주소 공간이 온-프레미스 위치 또는 Azure 지역의 다른 네트워크와 겹치지 않도록 Azure의 IP 주소 지정에 대한 조직 계획에 맞춥니다.
  • IP 주소 공간이 낭비되지 않도록 불필요하게 큰 애플리케이션 가상 네트워크를 만들지 마세요.

• 보다 풍부한 기능 집합을 지원하므로 AKS 네트워크 통합에 Azure CNI를 사용하는 우선 순위를 지정합니다.

  • 제한된 주소 공간 내에서 애플리케이션에 맞게 사용 가능한 IP 주소가 제한된 시나리오의 경우 Kubenet을 고려합니다.

  • AKS 네트워크 통합을 위해 Azure CNI 네트워크 플러그 인의 사용 우선 순위를 지정하고 사용 가능한 IP 주소 범위가 제한된 시나리오의 경우 Kubenet을 고려합니다. 자세한 내용은 마이크로 세분화 및 kubernetes 네트워크 정책을 참조하세요.

• 온-프레미스 네트워크 통합이 필요한 시나리오의 경우 Express Route를 사용하여 안전하고 확장 가능한 연결을 보장하는 데 우선 순위를 지정합니다.

  • Express Route 또는 VPN에 적용된 안정성 수준이 애플리케이션 요구 사항을 완전히 충족하는지 확인합니다.
  • 여러 네트워크 경로는 교차 연결된 ExpressRoute 회로 또는 장애 조치(failover) 연결 메커니즘으로 VPN 사용과 같이 필요한 경우 추가 중복성을 제공하는 것으로 간주되어야 합니다.

• 중요한 네트워크 경로의 모든 구성 요소가 이러한 경로 및 관련 구성 요소의 관리가 중앙 IT 팀의 애플리케이션 팀에서 제공하는지 여부에 관계없이 연결된 사용자 흐름의 안정성 및 가용성 요구 사항에 부합하는지 확인합니다.

  참고 항목

  Azure 랜딩 존 내에 배포하고 더 광범위한 조직 네트워크 토폴로지와 통합하는 경우 네트워크 지침을 고려하여 기본 네트워크가 Microsoft 모범 사례에 부합하는지 확인합니다.

• Azure Bastion 또는 프록시된 프라이빗 연결을 사용하여 Azure 리소스의 데이터 평면에 액세스하거나 관리 작업을 수행합니다.

인터넷 송신

인터넷 송신은 다음과 같은 컨텍스트에서 외부 통신을 용이하게 하기 위한 중요 업무용 애플리케이션의 기본 네트워크 요구 사항입니다.

1. 직접 애플리케이션 사용자 상호 작용.
2. Azure 외부의 외부 종속성과 애플리케이션 통합
3. 애플리케이션에서 사용하는 Azure 서비스에 필요한 외부 종속성에 대한 액세스입니다.

이 섹션에서는 보안, 안정성 및 지속 가능한 성능을 유지하면서 인터넷 송신을 달성하는 방법을 살펴보고 중요 업무용 컨텍스트에서 권장되는 서비스에 대한 주요 송신 요구 사항을 강조합니다.

디자인 고려 사항

• 많은 Azure 서비스에서는 다양한 관리 및 제어 평면 함수가 의도한 대로 작동하도록 공용 엔드포인트에 액세스해야 합니다.

• Azure는 가상 네트워크의 가상 머신 또는 컴퓨팅 인스턴스에 대해 Azure NAT 게이트웨이 또는 Azure Load Balancer와 같은 다양한 직접 인터넷 아웃바운드 연결 방법을 제공합니다.

• 가상 네트워크 내부의 트래픽이 인터넷으로 이동하면 NAT(네트워크 주소 변환)가 발생해야 합니다. 이는 네트워킹 스택 내에서 발생하므로 시스템 성능에 영향을 미칠 수 있는 컴퓨팅 작업입니다.

• NAT가 소규모로 발생하는 경우 성능 영향은 무시할 수 있지만, 아웃바운드 요청이 많은 경우 네트워크 문제가 발생할 수 있습니다. 이러한 문제는 일반적으로 '원본 NAT(또는 SNAT) 포트 고갈' 형식으로 제공됩니다.

• Azure 앱 Service와 같은 다중 테넌트 환경에서는 각 인스턴스에서 사용할 수 있는 제한된 수의 아웃바운드 포트가 있습니다. 이러한 포트가 부족하면 새 아웃바운드 연결을 시작할 수 없습니다. 이 문제는 프라이빗/퍼블릭 에지 순회 수를 줄이거나 Azure NAT 게이트웨이와 같은 확장성 있는 NAT 솔루션을 사용하여 완화할 수 있습니다.

• NAT 제한 사항 외에도 아웃바운드 트래픽은 필수 보안 검사의 대상이 될 수 있습니다.

  • Azure Firewall은 네트워크 송신을 보호하기 위한 적절한 보안 기능을 제공합니다.

  • Azure Firewall (또는 동등한 NVA)을 사용하여 아웃바운드 트래픽 흐름에 대한 세부적인 제어를 제공하여 Kubernetes 송신 요구 사항을 보호할 수 있습니다.

• 대량의 인터넷 송신에는 데이터 전송 요금이 발생 합니다.

Azure NAT 게이트웨이

• Azure NAT Gateway는 할당된 아웃바운드 IP 주소당 TCP 및 UDP에 대해 64,000개의 연결을 지원합니다.

  • 단일 NAT 게이트웨이에 최대 16개의 IP 주소를 할당할 수 있습니다.
  • 기본 TCP 유휴 시간 제한(4분)입니다. 유휴 시간 제한이 더 높은 값으로 변경되면 흐름이 더 오래 유지되므로 SNAT 포트 인벤토리에 대한 압력이 증가합니다.

• NAT 게이트웨이는 영역 격리를 기본 제공으로 제공할 수 없습니다. 영역 중복성을 얻으려면 영역 리소스를 포함하는 서브넷을 해당 영역 NAT 게이트웨이에 맞춰야 합니다.

디자인 권장 사항

• NAT 성능에 영향을 주기 때문에 나가는 인터넷 연결 수를 최소화합니다.

  • 많은 수의 인터넷 바인딩 연결이 필요한 경우 Azure NAT Gateway를 사용하여 아웃바운드 트래픽 흐름을 추상화하는 것이 좋습니다.

• 아웃바운드 인터넷 트래픽을 제어하고 검사하기 위한 요구 사항이 있는 경우 Azure Firewall을 사용합니다.

  • Azure Firewall이 Azure 서비스 간의 트래픽을 검사하는 데 사용되지 않는지 확인합니다.

참고 항목

Azure 랜딩 존 내에 배포할 때 기본 플랫폼 Azure Firewall 리소스(또는 동등한 NVA)를 사용하는 것이 좋습니다. 인터넷 송신을 위해 중앙 플랫폼 리소스에서 종속성을 사용하는 경우 해당 리소스 및 관련 네트워크 경로의 안정성 수준이 애플리케이션 요구 사항에 밀접하게 맞춰져야 합니다. 실패 시나리오에서 잠재적인 운영 작업을 알리기 위해 리소스의 운영 데이터도 애플리케이션에서 사용할 수 있어야 합니다.

아웃바운드 트래픽과 관련된 대규모 요구 사항이 있는 경우 중요 업무용 애플리케이션에 대한 전용 Azure Firewall 리소스에 고려 사항을 부여하여 시끄러운 인접 시나리오와 같은 중앙 공유 리소스 사용과 관련된 위험을 완화해야 합니다.

• Virtual WAN 환경 내에서 배포되는 경우, 전 세계 방화벽 정책을 통해 조직의 보안 상태를 관찰할 수 있도록 전용 애플리케이션 Azure Firewall 인스턴스의 중앙 집중식 관리를 제공하기 위해 Firewall Manager에 고려해야 합니다.
• 증분 방화벽 정책이 애플리케이션 정책의 자율성을 허용하도록 역할 기반 액세스 제어를 통해 애플리케이션 보안 팀에 위임되었는지 확인합니다.

영역 간 및 지역 간 연결

애플리케이션 디자인은 독립적인 지역 배포 스탬프를 강력하게 옹호하지만, 많은 애플리케이션 시나리오에서는 성능이 저하된 서비스 상황에서만 다른 영역 또는 Azure 지역 내에 배포된 애플리케이션 구성 요소 간에 네트워크 통합이 필요할 수 있습니다. 영역 간 통신과 지역 간 통신이 이루어지는 방법은 전반적인 성능 및 안정성에 상당한 영향을 줍니다. 이 섹션에서는 고려 사항 및 권장 사항을 통해 살펴봅니다.

디자인 고려 사항

• 중요 업무용 애플리케이션에 대한 애플리케이션 디자인 접근 방식은 단일 지역 내의 모든 구성 요소 수준에서 영역 중복성이 적용된 독립적인 지역 배포 사용을 보증합니다.

• AZ(가용성 영역)는 Azure 지역 내에서 물리적으로 분리된 데이터 센터 위치로, 단일 데이터 센터 수준까지 물리적 및 논리적 오류 격리를 제공합니다.

  영역 간 통신에는 2ms 미만의 왕복 대기 시간이 보장됩니다. 영역 간의 다양한 거리와 파이버 경로에 따라 영역의 대기 시간 차이는 작습니다.

• 가용성 영역 연결은 지역 특성에 따라 달라지므로 에지 위치를 통해 지역으로 들어오는 트래픽은 대상에 도달하기 위해 영역 간에 라우팅되어야 할 수 있습니다. 이렇게 하면 영역 간 라우팅 및 '빛의 속도' 제약 조건이 지정된 경우 최대 1ms-2ms의 대기 시간이 추가되지만 하이퍼 중요한 워크로드에만 영향을 주어야 합니다.

• 가용성 영역 단일 구독의 컨텍스트 내에서 논리 엔터티로 처리되므로 다른 구독에 동일한 지역에 대해 다른 영역 매핑이 있을 수 있습니다. 예를 들어 구독 A의 영역 1은 구독 B의 영역 2와 동일한 실제 데이터 센터에 해당할 수 있습니다.

• 애플리케이션 구성 요소 간에 매우 수다스러운 애플리케이션 시나리오를 사용하면 여러 영역에 애플리케이션 계층을 분산하면 상당한 대기 시간과 비용이 증가할 수 있습니다. 배포 스탬프를 단일 영역으로 제한하고 여러 영역에 여러 스탬프를 배포하여 디자인 내에서 이를 완화할 수 있습니다.

• 서로 다른 Azure 지역 간의 통신에는 GB 대역폭당 더 큰 데이터 전송 요금이 발생 합니다.

  • 적용 가능한 데이터 전송 속도는 고려되는 Azure 지역의 대륙에 따라 달라집니다.
  • 대륙을 횡단하는 데이터는 훨씬 더 높은 요금으로 청구됩니다.

• Express Route 및 VPN 연결 방법을 사용하여 특정 시나리오 또는 다른 클라우드 플랫폼을 위해 서로 다른 Azure 지역을 직접 연결할 수도 있습니다.

• 서비스 간 통신 Private Link는 프라이빗 엔드포인트를 사용하는 직접 통신에 사용할 수 있습니다.

• 트래픽은 Azure 지역 내의 가상 네트워크와 동일한 지역 내의 다른 Azure 지역 간에 라우팅을 용이하게 하기 위해 온-프레미스 연결에 사용되는 Express Route 회로를 통해 고정될 수 있습니다.

  • Express Route를 통한 헤어 고정 트래픽은 가상 네트워크 피어링과 관련된 데이터 전송 비용을 우회하므로 비용을 최적화하는 방법으로 사용할 수 있습니다.
  • 이 방법을 사용하려면 Azure 내에서 애플리케이션 통합을 위한 추가 네트워크 홉이 필요하므로 대기 시간 및 안정성 위험이 발생합니다. Azure/온-프레미스에서 Express 경로 및 연결된 게이트웨이 구성 요소의 역할을 확장하여 Azure/Azure 연결도 포함합니다.

• 서비스 간에 하위 밀리초 대기 시간이 필요한 경우 사용된 서비스에서 지원되는 경우 근접 배치 그룹을 사용할 수 있습니다.

디자인 권장 사항

• 가상 네트워크 피어링을 사용하여 한 지역 내에서 그리고 여러 지역에 걸쳐 네트워크를 연결합니다. Express Route 내에서는 헤어핀을 피하는 것이 좋습니다.

• Private Link를 사용하여 동일한 지역 또는 지역 간 서비스 간에 직접 통신을 설정합니다(지역 A의 서비스는 지역 B의 서비스와 통신합니다.

• 구성 요소 간에 매우 빈번한 애플리케이션 워크로드의 경우 배포 스탬프를 단일 영역으로 제한하고 여러 영역에 걸쳐 여러 스탬프를 배포하는 것이 좋습니다. 이를 통해 단일 애플리케이션 구성 요소가 아닌 캡슐화된 배포 스탬프 수준에서 영역 중복성이 유지됩니다.

• 가능한 경우 각 배포 스탬프를 독립적이고 다른 스탬프와 연결이 끊긴 것으로 처리합니다.

  • 직접 네트워크 경로를 사용하여 애플리케이션 수준에서 일관성을 달성하는 대신 데이터 플랫폼 기술을 사용하여 지역 간에 상태를 동기화합니다.
  • 오류 시나리오에서도 필요 없는 한 다른 지역 간의 '개 레깅스' 트래픽을 방지합니다. 글로벌 라우팅 서비스 및 엔드 투 엔드 상태 프로브를 사용하여 해당 결함이 있는 구성 요소 수준에서 다른 지역으로 트래픽을 라우팅하는 대신 단일 중요 구성 요소 계층이 실패하는 경우 전체 스탬프를 순환에서 제외합니다.

• 하이퍼 대기 시간이 중요한 애플리케이션 시나리오의 경우 지역 네트워크 게이트웨이가 있는 영역의 사용 우선 순위를 지정하여 수신 경로에 대한 네트워크 대기 시간을 최적화합니다.

마이크로 세분화 및 Kubernetes 네트워크 정책

마이크로 구분은 제로 트러스트 모델을 기반으로 워크로드 간 네트워크 트래픽을 제한하는 정책을 적용하여 개별 애플리케이션 워크로드를 격리하고 보호하는 데 사용되는 네트워크 보안 디자인 패턴입니다. 일반적으로 네트워크 공격 노출 영역을 줄이고, 위반 억제를 개선하고, 정책 기반 애플리케이션 수준 네트워크 제어를 통해 보안을 강화하기 위해 적용됩니다.

중요 업무용 애플리케이션은 AKS(Azure Kubernetes Service)를 사용할 때 서브넷 또는 네트워크 인터페이스 수준, ACL(서비스 액세스 제어 목록) 및 네트워크 정책 중 하나에서 NSG(네트워크 보안 그룹)를 사용하여 애플리케이션 수준 네트워크 보안을 적용할 수 있습니다.

이 섹션에서는 애플리케이션 수준 마이크로 세분화를 달성하기 위한 주요 고려 사항 및 권장 사항을 제공하여 이러한 기능을 최적으로 사용하는 방법을 살펴봅니다.

디자인 고려 사항

• AKS는 다음과 같은 두 가지 네트워킹 모델에 배포할 수 있습니다.

  • Kubenet 네트워킹: AKS 노드는 기존 가상 네트워크 내에 통합되지만 Pod는 각 노드의 가상 오버레이 네트워크 내에 존재합니다. 서로 다른 노드의 Pod 간 트래픽은 kube 프록시를 통해 라우팅됩니다.
  • Azure CNI(Container Networking Interface) 네트워킹: AKS 클러스터는 기존 가상 네트워크 내에 통합되고 클러스터 노드가 연결된 동일한 가상 네트워크에서 IP 주소를 받은 노드, Pod 및 서비스 내에 통합됩니다. 이는 Pod 간 직접 연결이 필요한 다양한 네트워킹 시나리오와 관련이 있습니다. 다른 노드 풀을 다른 서브넷에 배포할 수 있습니다.

  참고 항목

  Azure CNI에는 Kubenet에 비해 더 많은 IP 주소 공간이 필요합니다. 네트워크의 적절한 선행 계획 및 크기 조정이 필요합니다. 자세한 내용은 Azure CNI 설명서를 참조 하세요.

• 기본적으로 Pod는 격리되지 않으며 모든 원본의 트래픽을 허용하며 트래픽을 대상으로 보낼 수 있습니다. Pod는 지정된 Kubernetes 클러스터의 다른 모든 Pod와 통신할 수 있습니다. Kubernetes는 네트워크 수준 격리를 보장하지 않으며 클러스터 수준에서 네임스페이스를 격리하지 않습니다.

• 네트워크 정책을 사용하여 Pod와 네임스페이스 간의 통신을 격리할 수 있습니다. 네트워크 정책은 Pod 간의 통신에 대한 액세스 정책을 정의하는 Kubernetes 사양입니다. 네트워크 정책을 사용하여 트래픽이 전송/수신되는 방식을 제어하기 위해 정렬된 규칙 집합을 정의하고 하나 이상의 레이블 선택기와 일치하는 Pod 컬렉션에 적용할 수 있습니다.

  • AKS는 네트워크 정책, Azure 및 Calico를 구현하는 두 개의 플러그 인을 지원합니다. 두 플러그 인 모두 Linux IPTable을 사용하여 지정된 정책을 적용합니다. 자세한 내용은 Azure와 Calico 정책 간의 차이점과 해당 기능을 참조 하세요 .
  • 네트워크 정책은 가산적이므로 충돌하지 않습니다.
  • 두 Pod 간의 네트워크 흐름을 허용하려면 원본 Pod의 송신 정책과 대상 Pod의 수신 정책 모두 트래픽을 허용해야 합니다.
  • 네트워크 정책 기능은 클러스터 인스턴스화 시간에만 사용하도록 설정할 수 있습니다. 기존 AKS 클러스터에서 네트워크 정책을 사용하도록 설정할 수 없습니다.
  • 네트워크 정책의 전달은 Azure 또는 Calico 사용 여부에 관계없이 일관됩니다.
  • Calico는 Windows 노드에 대한 지원을 포함하여 더 풍부한 기능 집합을 제공하고 Azure CNI와 Kubenet을 지원합니다.

• AKS는 GPU 기능 유무에 관계없이 노드와 같이 하드웨어 및 소프트웨어 특성이 다른 노드를 사용하여 다른 워크로드를 구분하는 다른 노드 풀 만들기를 지원합니다.

  • 노드 풀을 사용하면 네트워크 수준 격리가 제공되지 않습니다.
  • 노드 풀은 동일한 가상 네트워크 내에서 다른 서브넷을 사용할 수 있습니다. NSG를 서브넷 수준에서 적용하여 노드 풀 간에 마이크로 분할을 구현할 수 있습니다.

디자인 권장 사항

• 수신 경로를 보호하고 제로 트러스트 모델을 기반으로 애플리케이션 구성 요소를 격리하는 IP ACL을 제공하도록 고려되는 모든 서브넷에서 NSG를 구성합니다.

  • Azure Front Door 내에 정의된 애플리케이션 백 엔드를 포함하는 모든 서브넷에서 NSG 내의 Front Door 서비스 태그를 사용합니다. 이 태그는 합법적인 Azure Front Door 백 엔드 IP 주소 공간에서 발생하는 트래픽의 유효성을 검사하기 때문에 사용됩니다. 이렇게 하면 트래픽이 서비스 수준에서 Azure Front Door를 통해 흐르지만 특정 Front Door 인스턴스의 사용을 보장하고 'IP 스푸핑' 보안 위험을 완화하기 위해 헤더 기반 필터링이 여전히 필요합니다.

  • 적용 가능한 모든 NSG의 RDP 및 SSH 포트에서 공용 인터넷 트래픽을 사용하지 않도록 설정해야 합니다.

  • Azure CNI 네트워크 플러그 인 사용의 우선 순위를 지정하고 제한된 주소 공간 내에서 애플리케이션에 맞게 사용 가능한 IP 주소 범위가 제한된 시나리오의 경우 Kubenet을 고려합니다.

    • AKS는 Azure CNI와 Kubenet의 사용을 모두 지원합니다. 이 네트워킹 선택은 배포 시 선택됩니다.
    • Azure CNI 네트워크 플러그 인은 보다 강력하고 확장 가능한 네트워크 플러그 인이며 대부분의 시나리오에 권장됩니다.
    • Kubenet은 좀 더 간단한 네트워크 플러그 인이며 사용 가능한 IP 주소 범위가 제한된 시나리오에 권장됩니다.
    • 자세한 내용은 Azure CNI를 참조하세요.

• Kubernetes의 네트워크 정책 기능은 클러스터의 Pod 간 수신 및 송신 트래픽에 대한 규칙을 정의하는 데 사용해야 합니다. Pod 간 통신을 제한하고 제한하기 위해 세분화된 네트워크 정책을 정의합니다.

  • 배포 시 Azure Kubernetes Service에 대한 네트워크 정책을 사용하도록 설정합니다.
  • Calico는 보다 광범위한 커뮤니티 채택 및 지원을 통해 보다 풍부한 기능 집합을 제공하기 때문에 Calico 사용의 우선 순위를 지정합니다.

다음 단계

애플리케이션 상태를 수량화하고 관찰하기 위한 고려 사항을 검토합니다.

상태 모델링 및 관찰 가능성