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

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 주소 공용 엔드포인트를 여러 프라이빗 엔드포인트와 공유합니다. Azure는 PAT에 대해 퍼블릭 엔드포인트의 임시 포트를 사용합니다.	예	예
3. 독립 실행형 VM	포트 주소 변환이 있는 SNAT (PAT)	TCP, UDP	Azure는 SNAT에 대한 공용 IP 주소를 자동으로 지정하고, 이 공용 IP 주소를 전체 배포와 공유하며, PAT에 대한 퍼블릭 엔드포인트 IP 주소의 임시 포트를 사용합니다. 이는 이전 시나리오에 대한 대체 시나리오입니다. 가시성과 제어가 필요한 경우 권장하지 않습니다.	예	예

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

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

클래식 배포	사용 가능한 기능
가상 머신	시나리오 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 포트 소모가 발생하는 경우 SNAT 제약 조건을 완화하기 위해 ILPIP를 할당하는 것이 좋습니다. 전체 SNAT 고갈 관리를 검토합니다.

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

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

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

부하 분산 장치의 공용 IP 주소 프런트 엔드의 임시 포트는 VM에서 시작된 개별 흐름을 구분하는 데 사용됩니다. SNAT는 아웃바운드 흐름을 만들 때 미리 할당된 임시 포트 를 동적으로 사용합니다. 이 컨텍스트에서 SNAT에 사용되는 임시 포트를 SNAT 포트라고 합니다.

SNAT 포트는 SNAT 및 PAT 이해 섹션에 설명된 대로 미리 할당됩니다. 모두 소진될 수 있는 유한한 리소스입니다. 소비 방법을 이해하는 것이 중요 합니다. 이 사용을 위해 디자인하고 필요에 따라 완화하는 방법을 이해하려면 SNAT 고갈 관리를 검토하세요.

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

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

이 시나리오에서 VM 또는 Web Worker ROle은 부하 분산된 공용 엔드포인트의 일부가 아닙니다. 또한 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 포트 및 해당 흐름은 영향을 받지 않습니다.

클라우드 서비스가 다시 배포되거나 변경된 경우 인프라는 백 엔드 풀을 실제보다 최대 2배까지 크게 보고할 수 있으며, Azure는 인스턴스당 SNAT 포트를 예상보다 적게 사전 할당합니다. 이렇게 하면 일시적으로 SNAT 포트 소모 가능성이 증가할 수 있습니다. 결국 풀 크기는 실제 크기로 전환되고 Azure는 위의 표에 따라 미리 할당된 SNAT 포트를 예상 수로 자동으로 증가합니다. 이 동작은 의도적으로 수행되며 구성할 수 없습니다.

SNAT 포트 할당은 IP 전송 프로토콜별(TCP 및 UDP는 별도로 유지 관리됨)이며 다음 조건에 따라 릴리스됩니다.

TCP SNAT 포트 릴리스

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

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를 할당하면 시나리오가 인스턴스 수준 공용 IP로 VM으로 변경됩니다. 각 VM에 사용되는 공용 IP의 모든 임시 포트는 VM에서 사용할 수 있습니다. (공용 IP의 임시 포트가 해당 배포와 연결된 모든 VM과 공유되는 시나리오와는 달리) 많은 수의 개별 IP 주소를 허용 목록에 포함할 경우 발생할 수 있는 영향과 같이 고려해야 할 절충안이 있습니다.

비고

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

Keepalive를 사용하여 아웃바운드 유휴 시간 제한을 재설정

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

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 배포에서 사용할 수 있는 아웃바운드 연결 시나리오에 대한 모드를 알아봅니다.