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