이 문서에서는 Azure NAT 게이트웨이에 대한 모범 사례를 제공합니다. 이 가이드는 다음과 같이 뛰어난 아키텍처의 5가지 핵심 요소를 기반으로 합니다. 즉, 비용 최적화, 운영 효율성, 성능 효율성, 안정성 및 보안입니다.
Azure NAT Gateway에 대한 실무 지식이 있고 해당 기능에 정통한 것으로 가정합니다. 새로 고침으로 Azure NAT Gateway 설명서의 전체 집합을 검토합니다.
NAT는 네트워크 주소 변환을 의미합니다. 네트워크 주소 번역 소개를 참조하세요.
비용 최적화
NAT 게이트웨이를 사용하지 않도록 하려면 Azure Private Link 또는 서비스 엔드포인트(스토리지 포함)를 통해 PaaS 서비스에 액세스해야 합니다. Private Link 및 서비스 엔드포인트는 PaaS 서비스에 액세스하기 위해 NAT 게이트웨이를 트래버스할 필요가 없습니다. 이 방법은 NAT 게이트웨이의 비용을 Private Link 또는 서비스 엔드포인트와 비교할 때 처리되는 데이터 GB당 요금을 줄여줍니다. Private Link 또는 서비스 엔드포인트를 사용하는 경우 추가적인 보안 이점이 있습니다.
성능 효율성
각 NAT 게이트웨이 리소스는 최대 50Gbps의 처리량을 제공합니다. 배포를 여러 서브넷으로 분할한 다음 각 서브넷 또는 서브넷 그룹에 NAT 게이트웨이를 할당하여 스케일 아웃할 수 있습니다.
각 NAT Gateway 공용 IP 주소는 64,512개의 SNAT 포트를 제공합니다. NAT 게이트웨이에 최대 16개의 IP 주소를 할당할 수 있습니다. IP 주소는 개별 표준 공용 IP 주소, 공용 IP 접두사 또는 둘 다일 수 있습니다. 동일한 대상 엔드포인트로 이동하는 연결의 경우 NAT 게이트웨이는 할당된 아웃바운드 IP 주소당 TCP 및 UDP에 대해 각각 최대 50,000개의 동시 흐름을 지원할 수 있습니다. 자세한 내용은 SNAT(Source Network Address Translation)에서 다음 섹션을 검토하세요. TCP는 Transmission Control Protocol을 의미하며 UDP는 사용자 데이터그램 프로토콜을 의미합니다.
SNAT 소모
- NAT 게이트웨이 리소스의 기본 TCP 유휴 시간 제한은 4분이며 최대 120분까지 구성할 수 있습니다. 이 설정이 기본값보다 높은 값으로 변경되면 NAT 게이트웨이가 더 오래 흐르도록 유지되고 SNAT 포트 인벤토리에 불필요한 압력이 발생할 수 있습니다.
- 원자성 요청(연결당 하나의 요청)은 크기 조정을 제한하고 성능을 줄이며 안정성을 감소시키기 때문에 디자인 선택이 좋지 않습니다. 그 대신, HTTP/S 연결을 다시 사용하여 연결의 수 및 연결된 SNAT 포트의 수를 줄입니다. 연결을 재사용하면 애플리케이션을 더 잘 스케일링할 수 있습니다. TLS를 사용하면 핸드셰이크, 오버헤드 및 암호화 작업 비용이 감소하므로 애플리케이션 성능이 향상됩니다.
- 수행기본 DNS(이름 시스템) 조회는 클라이언트가 DNS 확인자 결과를 캐시하지 않을 때 볼륨에서 많은 개별 흐름을 도입할 수 있습니다. DNS 캐싱을 사용하여 흐름 볼륨을 줄이고 SNAT 포트 수를 줄입니다. DNS는 인터넷 또는 개인 네트워크에 연결된 리소스의 IP 주소에 이름 기본 매핑하는 명명 시스템입니다.
- DNS 조회와 같은 UDP 흐름은 유휴 시간 제한 동안 SNAT 포트를 사용합니다. UDP 유휴 시간 제한 타이머는 4분으로 고정되며 변경할 수 없습니다.
- 연결 풀을 사용하여 연결 볼륨을 셰이핑하세요.
- 절대로 TCP 흐름을 자동으로 중단하고 TCP 타이머를 사용하여 흐름을 정리하지 마세요. TCP가 연결을 명시적으로 닫지 못하게 하면 TCP 연결이 열린 상태로 유지됩니다. 중간 시스템 및 엔드포인트는 이 연결을 계속 사용하므로 SNAT 포트를 다른 연결에 사용할 수 없게 됩니다. 이 안티 패턴은 애플리케이션 실패 및 SNAT 고갈을 트리거할 수 있습니다.
- 영향에 대한 전문 지식이 없으면 OS 수준 TCP 닫기 관련 타이머 값을 변경하지 마세요. TCP 스택이 복구되는 동안 연결의 엔드포인트에 예상과 다른 부분이 있으면 애플리케이션 성능에 부정적인 영향을 미칠 수 있습니다. 타이머 값을 변경하는 것은 일반적으로 디자인에 근본적인 문제가 있다는 신호입니다. 기본 애플리케이션에 다른 안티 패턴이 있는 경우 타이머 값이 변경되면 SNAT 고갈도 증폭될 수 있습니다.
다음 지침을 검토하여 서비스의 규모와 안정성을 개선합니다.
- TCP 유휴 시간 제한을 더 낮은 값으로 줄이는 것의 효과를 살펴봅니다. 기본 유휴 시간 제한인 4분으로 설정하면 SNAT 포트 인벤토리 공간을 더 일찍 확보할 수 있습니다.
- 비동기 폴링 패턴을 장기 실행 작업에 사용하여 다른 작업에 대한 연결 리소스를 확보하는 것이 좋습니다.
- 수명이 긴 흐름(예: 재사용된 TCP 연결)은 중간 시스템 시간 초과를 방지하기 위해 TCP KeepAlive 또는 애플리케이션 KeepAlive를 사용해야 합니다. 유휴 시간 제한을 늘리는 것은 마지막 수단이며 근본 원인은 해결되지 않을 수 있습니다. 시간 제한이 길면 시간 제한이 만료될 때 오류 시간이 짧아지고 시간 지연과 불필요한 오류가 발생할 수 있습니다. TCP keepalive는 양쪽에서 연결을 유지하기 위해 연결의 한쪽에서 사용하도록 설정할 수 있습니다.
- UDP 트래픽을 사용하는 수명이 긴 흐름의 경우 UDP keepalive를 사용하도록 설정하여 연결을 활성 상태로 유지할 수 있습니다. 연결의 한쪽에서 사용 설정된 UDP keepalive는 연결을 한쪽에서만 활성 상태로 유지합니다. 연결을 유지하기 위해서는 연결의 양쪽에서 UDP keepalive를 사용 설정해야 합니다.
- 일시적 실패 또는 오류 복구 중에 공격적인 다시 시도/버스트를 방지하기 위해 정상적인 다시 시도 패턴을 사용해야 합니다. 원자성 연결이라고 하는 안티패턴은 모든 HTTP 작업에 대해 새 TCP 연결을 만드는 경우입니다. 원자성 연결은 애플리케이션의 크기가 효율적으로 조정되지 못하도록 하며 리소스를 낭비합니다. 항상 여러 작업을 동일한 연결로 파이프라인합니다. 애플리케이션은 트랜잭션 속도 및 리소스 비용에서 이점을 활용할 수 있습니다. 애플리케이션에서 전송 계층 암호화(예: TLS)를 사용하는 경우 새 연결의 처리와 관련하여 상당한 비용이 발생합니다. 더 많은 모범 사례 패턴은 Azure 클라우드 디자인 패턴을 참조하세요.
운영 우수성
NAT 게이트웨이는 AKS(Azure Kubernetes Service)와 함께 사용할 수 있지만 AKS의 일부로 관리되지는 않습니다. CNI(컨테이너 네트워킹 인터페이스) 서브넷에 NAT 게이트웨이를 할당하는 경우 AKS Pod가 NAT 게이트웨이를 통해 송신되도록 설정합니다.
영역 또는 지역 간에 여러 NAT 게이트웨이를 사용하는 경우 Azure 공용 IP 접두사 또는 BYOIP 접두사를 사용하여 아웃바운드 IP 자산을 관리할 수 있도록 유지합니다. 16개 IP 주소(/28개 접두사 크기)보다 큰 IP 접두사 크기는 NAT 게이트웨이에 할당할 수 없습니다.
Azure Monitor 경고를 사용하여 SNAT 포트 사용량, 처리되거나 삭제된 패킷 및 전송된 데이터의 양을 모니터링하고 경고합니다. NSG 흐름 로그를 사용하여 NAT 게이트웨이가 구성된 서브넷의 가상 머신 인스턴스에서 아웃바운드 트래픽 흐름을 모니터링합니다.
서브넷이 NAT 게이트웨이로 구성된 경우 NAT 게이트웨이는 해당 서브넷의 모든 VM에 대해 공용 인터넷에 대한 다른 모든 아웃바운드 연결을 대체합니다. NAT 게이트웨이는 아웃바운드 규칙이 있거나 없는 부하 분산 장치보다, 그리고 VM에 직접 할당된 공용 IP 주소보다 우선합니다. Azure는 흐름의 방향을 추적하며 비대칭 라우팅은 발생하지 않습니다. 인바운드 원본 트래픽은 부하 분산 장치 프런트 엔드 IP와 같이 올바르게 변환되며 NAT 게이트웨이를 통해 아웃바운드 원본 트래픽과 별도로 변환됩니다. 이러한 분리를 통해 인바운드 및 아웃바운드 서비스가 원활하게 공존할 수 있습니다.
NAT 게이트웨이는 가상 네트워크에 아웃바운드 연결을 사용하도록 설정하기 위한 기본값으로 권장됩니다. NAT 게이트웨이는 Azure의 다른 아웃바운드 연결 기술보다 효율적이고 운영상 복잡하지 않습니다. NAT 게이트웨이는 주문형 SNAT 포트를 할당하고 보다 효율적인 알고리즘을 사용하여 SNAT 포트 재사용 충돌을 방지합니다. 자산에 대햐 기본 아웃바운드 연결(안티 패턴)에 의존하지 마세요. 대신 NAT 게이트웨이 리소스를 사용하여 명시적으로 정의합니다.
안정성
NAT 게이트웨이 리소스는 하나의 가용성 영역에서 고가용성이며 여러 장애 도메인에 걸쳐 있습니다. NAT 게이트웨이는 Azure가 NAT 게이트웨이를 배치할 영역을 자동으로 선택하는 "영역 없음"에 배포할 수 있습니다. NAT 게이트웨이는 사용자에 의해 특정 영역으로 격리될 수도 있습니다.
각 서브넷에 특정 영역 내의 리소스만 있는 경우가 아니라면 가용성 영역 격리를 제공할 수 없습니다. 대신 VM이 배포되는 각 가용성 영역에 대해 서브넷을 배포하고, 영역 VM을 일치하는 영역 NAT 게이트웨이와 정렬하고, 별도의 영역 스택을 빌드합니다. 예를 들어 가용성 영역 1의 가상 머신은 마찬가지로 다른 리소스를 가용성 영역 1에만 둔 서브넷에 있습니다. NAT 게이트웨이는 가용성 영역 1에서 해당 서브넷을 제공하도록 구성됩니다. 다음 다이어그램을 참조하세요.
가상 네트워크 및 서브넷은 지역의 모든 가용성 영역에 걸쳐 있습니다. 영역 리소스를 수용하기 위해 가용성 영역으로 나눌 필요가 없습니다.
보안
NAT 게이트웨이를 사용하면 개별 가상 머신(또는 기타 컴퓨팅 리소스)에 공용 IP 주소가 필요하지 않으며 완전히 프라이빗하게 유지될 수 있습니다. 공용 IP 주소가 없는 리소스는 여전히 가상 네트워크 외부의 외부 원본에 연결할 수 있습니다. 공용 IP 접두사를 연결하여 연속된 IP 집합이 아웃바운드 연결에 사용되도록 할 수 있습니다. 이 예측 가능한 IP 목록을 기반으로 대상 방화벽 규칙을 구성할 수 있습니다.
일반적인 방법은 타사 방화벽 또는 프록시 서버를 사용하여 아웃바운드 전용 NVA(네트워크 가상 어플라이언스) 시나리오를 설계하는 것입니다. NAT 게이트웨이가 NVA의 가상 머신 확장 집합을 사용하여 서브넷에 배포되는 경우 해당 NVA는 부하 분산 장치 또는 개별 IP의 IP가 아닌 아웃바운드 연결에 NAT 게이트웨이 주소를 사용합니다. Azure Firewall에 이 시나리오를 사용하려면 Azure 표준 Load Balancer에 Azure Firewall 통합을 참조하세요.
클라우드용 Microsoft Defender NAT 게이트웨이를 통해 의심스러운 아웃바운드 연결을 모니터링할 수 있습니다. 클라우드용 Microsoft Defender의 경고 기능입니다.
참가자
Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.
보안 주체 작성자:
- Ethan Haslett | 선임 클라우드 솔루션 설계자
비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.