아웃바운드 연결(클래식)

  • 아티클

Azure는 여러 메커니즘을 통해 고객 배포에 대한 아웃바운드 연결을 제공합니다. 이 문서에서는 시나리오, 적용 시기, 작동 방식 및 관리 방법을 설명합니다.

참고

이 문서에서는 클래식 배포 모델에 대해서만 설명합니다. Azure의 모든 Resource Manager 배포 시나리오에 대한 아웃바운드 연결을 검토합니다.

Azure에 배포되는 솔루션은 공용 IP 주소 공간에 있는 Azure 외부의 엔드포인트와 통신할 수 있습니다. 인스턴스가 공용 IP 주소 공간에서 대상에 대한 아웃바운드 흐름을 시작하면 Azure는 개인 IP 주소를 공용 IP 주소에 동적으로 매핑합니다. 이 매핑이 생성되면 이 아웃바운드에서 시작된 흐름에 대한 반환 트래픽도 흐름이 시작된 개인 IP 주소에 연결할 수 있습니다.

Azure에서는 SNAT(원본 네트워크 주소 변환)를 사용하여 이 기능을 수행합니다. 단일 공용 IP 주소 뒤에서 여러 개인 IP 주소가 가장하는 경우 Azure는 PAT(포트 주소 변환)를 사용하여 개인 IP 주소를 가장합니다. 삭제 포트는 PAT에 사용되고 풀 크기에 따라 미리 할당됩니다.

여러 개의 아웃바운드 시나리오가 있습니다. 필요에 따라 이러한 시나리오를 결합할 수 있습니다. 주의 깊게 살펴보고 배포 모델 및 애플리케이션 시나리오에 적용되는 기능, 제약 조건 및 패턴을 이해합니다. 시나리오 관리 지침을 검토합니다.

시나리오 개요

Azure에서는 아웃바운드 연결 클래식 배포를 달성하기 위한 별도의 세 가지 방법을 제공합니다. 모든 클래식 배포에서 세 가지 시나리오를 모두 사용할 수 있는 것은 아닙니다.

시나리오 방법 IP 프로토콜 설명 웹 작업자 역할 IaaS
1. 인스턴스 수준 공용 IP 주소가 있는 VM SNAT, 포트 가장 사용 안 함 TCP, UDP, ICMP, ESP Azure에서 공용 IP가 할당된 Virtual Machine을 사용합니다. 인스턴스에 있는 모든 삭제 포트를 사용할 수 있습니다. 아니요 예
2. 부하 분산된 공용 엔드포인트 공용 엔드포인트에 대한 포트 가장(PAT)을 사용하는 SNAT TCP, UDP Azure에서 공용 IP 주소 공용 엔드포인트를 여러 프라이빗 엔드포인트와 공유합니다. PAT에 대한 공용 엔드포인트의 사용 후 삭제 포트를 사용합니다. Yes Yes
3. 독립 실행형 VM 포트를 가장하는(PAT) SNAT TCP, UDP Azure에서 자동으로 SNAT에 대한 공용 IP 주소를 지정하고, 이 공용 IP 주소를 전체 배포와 공유하고, PAT에 대한 공용 엔드포인트의 사용 후 삭제 포트를 사용합니다. 이 시나리오는 이전 시나리오의 대체 시나리오입니다. 가시성 및 제어 기능이 필요한 경우에는 권장되지 않습니다. Yes Yes

이는 Azure의 Resource Manager 배포에 사용할 수 있는 아웃바운드 연결 기능의 하위 집합입니다.

클래식의 다양한 배포에는 다음과 같은 다양한 기능이 있습니다.

클래식 배포 사용할 수 있는 기능
Virtual Machine 1, 2 또는 3 시나리오
웹 작업자 역할 2, 3 시나리오만

완화 전략의 차이점도 똑같습니다.

클래식 배포의 PAT에 대한 사용 후 삭제 포트를 미리 할당하는 데 사용되는 알고리즘은 Azure Resource Manager 리소스 배포와 동일합니다.

시나리오 1: 인스턴스 수준 공용 IP 주소가 있는 VM

이 시나리오에서 VM에는 ILPIP(인스턴스 수준 공용 IP)가 할당되어 있습니다. 아웃바운드 연결에 관한 한 VM에 부하 분산 엔드포인트가 있는지 여부는 중요하지 않습니다. 이 시나리오는 다른 시나리오에 우선합니다. ILPIP가 사용되면 VM은 모든 아웃바운드 흐름에 ILPIP를 사용합니다.

VM에 할당된 공용 IP는 1:다가 아니라 1:1 관계이며 상태 비저장 1:1 NAT로 구현됩니다. 포트 가장(PAT)은 사용되지 않으며 VM에는 사용 가능한 모든 삭제 포트가 있습니다.

애플리케이션이 아웃바운드 흐름을 시작하고 SNAT 포트 소모가 발생하는 경우 ILPIP를 할당하여 SNAT 제약 조건을 완화하는 방안을 고려해야 합니다. SNAT 고갈 관리를 전체적으로 검토합니다.

시나리오 2: 부하 분산된 공용 엔드포인트

이 시나리오에서 VM 또는 웹 작업자 역할은 부하 분산된 엔드포인트를 통해 공용 IP 주소와 연결됩니다. VM에는 할당된 공용 IP 주소가 없습니다.

부하 분산된 VM에서 아웃바운드 흐름을 만드는 경우 Azure에서 아웃바운드 흐름의 프라이빗 원본 IP 주소를 부하 분산된 공용 엔드포인트의 공용 IP 주소로 변환합니다. Azure는 SNAT을 사용하여 이 기능을 수행합니다. 또한 Azure는 PAT를 사용하여 공용 IP 주소 뒤에서 여러 개인 IP 주소를 가장합니다.

Load Balancer의 공용 IP 주소 프런트 엔드에 있는 삭제 포트는 VM에서 발생하는 개별 흐름을 구별하는 데 사용됩니다. SNAT은 아웃바운드 흐름이 생성될 때 동적으로 삭제 포트를 미리 할당합니다. 이 컨텍스트에서 SNAT에 사용되는 임시 포트를 SNAT 포트라고 부릅니다.

SNAT 포트는 SNAT 및 PAT 이해 섹션에 설명된 대로 미리 할당되며 고갈될 수 있는 한정된 리소스입니다. 어떻게 소비되는지 이해하는 것이 중요합니다. 이 소비를 설계하고 필요에 따라 완화하는 방법을 알아보려면 SNAT 고갈 관리를 검토하세요.

여러 공용 부하 분산 엔드포인트가 있는 경우 이러한 공용 IP 주소는 아웃바운드 흐름의 후보이며, 하나는 임의로 선택됩니다.

시나리오 3: 연결된 공용 IP 주소 없음

이 시나리오에서 VM 또는 웹 작업자 역할은 부하 분산된 공용 엔드포인트에 속하지 않습니다. 그리고 VM에는 할당된 ILPIP 주소가 없습니다. VM이 아웃바운드 흐름을 만든 경우 Azure에서는 아웃바운드 흐름의 프라이빗 원본 IP 주소를 공용 원본 IP 주소로 변환합니다. 이 아웃바운드 흐름에 사용된 공용 IP 주소는 구성할 수 없으며 구독의 공용 IP 리소스 제한에 불리하게 작용하지 않습니다. 이 주소는 Azure에서 자동으로 할당합니다.

Azure는 포트 가장(PAT)과 함께 SNAT을 사용하여 이 기능을 수행합니다. 이 시나리오는 사용되는 IP 주소를 제어할 수 없다는 점을 제외하고 시나리오 2와 비슷합니다. 시나리오 1 및 2가 없을 때를 대비한 시나리오입니다. 아웃바운드 주소를 제어해야 하는 경우에는 이 시나리오를 사용하지 않는 것이 좋습니다. 아웃바운드 연결이 애플리케이션의 중요한 부분인 경우 다른 시나리오를 선택해야 합니다.

SNAT 포트는 SNAT 및 PAT 이해 섹션에 설명된 대로 미리 할당되며 공용 IP 주소를 공유하는 VM 또는 웹 작업자 역할의 수에 따라 미리 할당되는 사용 후 삭제 포트 수가 결정됩니다. 어떻게 소비되는지 이해하는 것이 중요합니다. 이 소비를 설계하고 필요에 따라 완화하는 방법을 알아보려면 SNAT 고갈 관리를 검토하세요.

SNAT 및 PAT 이해

포트 가장 SNAT(PAT)

배포에서 아웃바운드 연결을 만드는 경우 각 아웃바운드 연결 원본이 다시 작성됩니다. 원본은 개인 IP 주소 공간에서 배포와 관련된 공용 IP로 다시 작성됩니다(위에서 설명한 시나리오에 따라). 공용 IP 주소 공간에서 흐름의 5튜플(원본 IP 주소, 원본 포트, IP 전송 프로토콜, 대상 IP 주소, 대상 포트)은 고유해야 합니다.

여러 흐름이 단일 공용 IP 주소에서 시작되므로 삭제 포트(SNAT 포트)는 프라이빗 원본 IP 주소를 다시 작성한 후 이 목적에 사용됩니다.

단일 대상 IP 주소, 포트 및 프로토콜에 대한 흐름 당 하나의 SNAT 포트가 사용됩니다. 동일한 대상 IP 주소, 포트 및 프로토콜에 대한 여러 흐름의 경우 각 흐름은 단일 SNAT 포트를 사용합니다. 이렇게 하면 흐름이 동일한 대상 IP 주소에서 시작하여 동일한 대상 IP 주소, 포트 및 프로토콜로 이동하는 경우 흐름의 고유성이 보장됩니다.

서로 다른 대상 IP 주소, 포트 및 프로토콜에 대한 여러 흐름은 단일 SNAT 포트를 공유합니다. 대상 IP 주소, 포트 및 프로토콜은 공용 IP 주소 공간에서 흐름을 구분하는 추가 원본 포트를 사용하지 않고도 흐름을 고유하게 만들어줍니다.

SNAT 포트 리소스가 고갈되면 기존 흐름에서 SNAT 포트를 릴리스할 때까지 아웃바운드 흐름이 실패합니다. Load Balancer는 흐름이 닫히면 SNAT 포트를 회수하고 유휴 흐름에서 SNAT 포트를 회수하기 위해 4분 유휴 시간 제한을 사용합니다.

흔히 SNAT 포트 고갈로 이어지는 조건을 완화하는 패턴은 SNAT 관리 섹션을 검토하세요.

포트 가장 SNAT(PAT)에 대한 삭제 포트 미리 할당

Azure는 포트 가장 SNAT(PAT)을 사용할 때 백 엔드 풀의 크기에 따라 사용 가능한 미리 할당 SNAT 포트 수를 결정하는 알고리즘을 사용합니다. SNAT 포트는 특정 공용 IP 원본 주소에 사용할 수 있는 삭제 포트입니다.

Azure에서 지정된 공용 IP 주소를 공유하는 VM 또는 웹 작업자 역할 인스턴스의 수에 따라 인스턴스가 배포될 때 SNAT 포트를 미리 할당합니다. 아웃바운드 흐름이 생성되면 PAT는 흐름이 닫히거나 유휴 제한 시간에 도달하는 경우 이러한 포트를 동적으로 소비(미리 할당된 제한까지)하거나 해제합니다.

다음 표는 백 엔드 풀 크기 계층의 SNAT 포트 미리 할당을 보여줍니다.

인스턴스 미리 할당되는 인스턴스당 SNAT 포트 수
1-50 1,024
51-100 512
101-200 256
201-400 128

사용 가능한 SNAT 포트 수는 연결 수에 직접 반영되지 않습니다. 여러 고유한 대상에 단일 SNAT 포트를 재사용할 수 있습니다. 포트는 흐름을 고유하게 만드는 데 필요한 경우에만 사용됩니다. 디자인 및 완화 지침은 고갈 가능한 리소스를 관리하는 방법에 대한 섹션과 PAT에 대해 설명하는 섹션을 참조하세요.

배포 크기를 변경하면 설정된 흐름 중 일부에 영향을 줄 수 있습니다. 백 엔드 풀 크기가 증가하여 그 다음 계층으로 전환되면 그 다음으로 큰 백 앤드 풀 계층으로 전환되는 동안 미리 할당된 SNAT 포트의 절반이 회수됩니다. 회수된 SNAT 포트와 연결된 흐름은 시간이 초과되며 다시 설정해야 합니다. 미리 할당된 포트를 사용할 수 있는 한, 새 흐름이 즉시 성공합니다.

배포 크기가 줄고 더 낮은 계층으로 전환되면 사용 가능한 SNAT 포트 수가 늘어납니다. 이 경우 기존에 할당된 SNAT 포트와 각각의 흐름은 영향을 받지 않습니다.

클라우드 서비스를 다시 배포하거나 변경하는 경우 인프라는 실제와 같이 많은 최대 두 번까지 백 엔드 풀을 일시적으로 보고할 수 있습니다. Azure는 차례로 예상보다 적은 인스턴스당 SNAT 포트를 미리 할당합니다. 그러면 SNAT 포트 소모의 확률을 일시적으로 증가시킬 수 있습니다. 결국 풀 크기는 실제 크기로 전환되고 Azure는 미리 할당된 SNAT 포트를 위의 테이블에 따라 예상된 수로 자동으로 증가시킵니다. 이 동작은 의도적이며 구성할 수 없습니다.

SNAT 포트 할당은 IP 전송 프로토콜과 관련이 있으며(TCP 및 UDP가 별도로 유지 관리됨), 다음 조건에서 해제됩니다.

TCP SNAT 포트 해제

  • 서버/클라이언트가 둘 다 FIN/ACK를 보내는 경우 240초 후에 SNAT 포트가 해제됩니다.
  • RST가 표시되는 경우 15초 후에 SNAT 포트가 해제됩니다.
  • 유휴 시간 제한에 도달함

UDP SNAT 포트 해제

  • 유휴 시간 제한에 도달함

문제 해결

이 섹션은 Azure의 아웃바운드 연결에서 발생할 수 있는 SNAT 소모 및 기타 시나리오를 완화하는 데 사용됩니다.

SNAT(PAT) 포트 고갈 관리

PAT에 사용된 사용 후 삭제 포트는 연결된 공용 IP 없음 및 부하 분산된 공용 엔드포인트에서 설명한 대로 소모성 리소스입니다.

동일한 대상 IP 주소 및 포트에 대해 많은 아웃바운드 TCP 또는 UDP 연결을 시작할 것인지 알고 있는 경우 실패하는 아웃바운드 연결을 확인하고, 지원 서비스에서 SNAT 포트(PAT에서 사용하는 미리 할당된 삭제 포트)가 고갈될 것이라는 알림을 받는 경우 몇 가지 일반적인 완화 옵션을 사용할 수 있습니다. 다음 옵션을 검토하고 시나리오에 가장 적합한 옵션을 결정합니다. 한 가지 이상의 옵션이 이 시나리오를 관리하는 데 도움이 될 수 있습니다.

아웃바운드 연결 동작을 이해하는 데 어려움이 있는 경우 IP 스택 통계(netstat)를 사용할 수 있습니다. 또는 패킷 캡처를 사용하여 연결 동작을 관찰하면 도움이 될 수 있습니다.

연결을 다시 사용하도록 애플리케이션 수정

애플리케이션에서 연결을 다시 사용하여 SNAT에서 사용되는 사용 후 삭제 포트에 대한 수요를 줄일 수 있습니다. 이러한 효과는 연결 재사용이 기본 옵션인 HTTP/1.1 같은 프로토콜에서 특히 두드러집니다. 또한 전송으로 HTTP를 사용하는 다른 프로토콜(예: REST)도 이점을 얻을 수 있습니다.

재사용은 언제나 각 요청에 대한 개별 원자성 TCP 연결보다 좋은 방법입니다. 재사용은 TCP 트랜잭션의 성능과 효율성을 높입니다.

연결 풀링을 사용하도록 애플리케이션 수정

애플리케이션에서 연결 풀링 체계를 사용할 수 있습니다. 이 경우 요청이 고정된 연결 집합에서 내부적으로 분산됩니다(가능한 경우 각 연결이다 시 사용됨). 이 체계는 사용 중인 삭제 포트의 수를 제한하고 보다 예측 가능한 환경을 구축합니다. 또한 단일 연결이 작업에 회신하느라 사용 가능하지 않을 때 여러 동시 작업을 허용하여 요청 처리량을 늘릴 수 있습니다.

연결 풀링은 애플리케이션을 개발하는 데 사용하는 프레임워크 또는 애플리케이션에 대한 구성 설정에 이미 존재할 수 있습니다. 연결 풀링을 연결 재사용과 결합할 수 있습니다. 그러면 여러 요청이 동일한 대상 IP 주소 및 포트에 고정되고 예측 가능한 수의 포트를 사용합니다. 또한 TCP 트랜잭션을 효율적으로 사용하여 대기 시간 및 리소스 사용량이 감소하기 때문에 요청에도 이득입니다. 여러 UDP 흐름을 관리하면 고갈 조건을 피하고 SNAT 포트 활용도를 관리할 수 있으므로 UDP 트랜잭션이 도움이 될 수 있습니다.

덜 적극적인 재시도 논리를 사용하도록 애플리케이션 수정

PAT에 사용되는 미리 할당된 삭제 포트가 고갈되거나 애플리케이션 오류가 발생하면 지연 및 백오프 논리 없는 적극적인 또는 무차별 대입 재시도로 인해 고갈 상태가 발생하거나 지속됩니다. 덜 적극적인 재시도 논리를 사용하여 사용 후 삭제 포트에 대한 수요를 줄일 수 있습니다.

삭제 포트의 유휴 시간 제한은 4분입니다(조정 불가능). 다시 시도 횟수가 너무 엄격하면 고갈이 스스로 지울 수 있는 기회가 없습니다. 따라서 디자인할 때 애플리케이션이 트랜잭션을 어떤 방식으로 얼마나 자주 다시 시도하는지 고려하는 것이 중요합니다.

각 VM에 인스턴스 수준 공용 IP 할당

ILPIP를 할당하면 시나리오가 VM에 대한 인스턴스 수준 공용 IP로 변경됩니다. 각 VM에 사용되는 공용 IP의 모든 삭제 포트를 VM에 사용할 수 있습니다. (공용 IP의 임시 포트가 해당 배포와 연결된 모든 VM과 공유되는 시나리오와는 대조적입니다.) 많은 수의 개별 IP 주소를 허용 목록에 추가할 때 발생할 수 있는 잠재적 영향과 같이 고려해야 할 절충안이 있습니다.

참고

이 옵션은 웹 작업자 역할에는 사용할 수 없습니다.

keepalive를 사용하여 아웃바운드 유휴 시간 제한 다시 설정

아웃바운드 연결에는 4분의 유휴 시간 제한이 적용됩니다. 이 시간 제한은 조정할 수 없습니다. 그러나 필요한 경우 전송(예: TCP keepalive) 또는 애플리케이션 레이어 keepalive를 사용하여 유휴 흐름을 새로 고치고 이 유휴 시간 제한을 다시 설정할 수 있습니다. 지원 여부 또는 사용하도록 설정하는 방법에 대해 패키지된 소프트웨어의 공급 업체에 문의하세요. 일반적으로 한 쪽에서만 유휴 시간 제한을 다시 설정하기 위해 keepalive를 생성해야 합니다.

VM에서 사용하는 공용 IP 검색

여러 가지 방법으로 아웃바운드 연결의 공용 원본 IP 주소를 확인할 수 있습니다. OpenDNS는 VM의 공용 IP 주소를 표시할 수 있는 서비스를 제공합니다.

nslookup 명령을 사용하여 OpenDNS 확인자에 myip.opendns.com이라는 이름에 대한 DNS 쿼리를 전송할 수 있습니다. 서비스는 쿼리를 보내는 데 사용된 원본 IP 주소를 반환합니다. VM에서 다음 쿼리를 실행하는 경우 응답은 해당 VM에 사용되는 공용 IP입니다.

nslookup myip.opendns.com resolver1.opendns.com

다음 단계

  • Resource Manager 배포에 사용되는 Load Balancer에 대해 자세히 알아봅니다.
  • Resource Manager 배포에서 사용할 수 있는 아웃바운드 연결 시나리오에 대해 자세히 알아봅니다.