Azure VM의 TCP/IP 성능 튜닝
이 문서에서는 일반적인 TCP/IP 성능 튜닝 기술과 Azure에서 실행되는 가상 머신에서 이러한 기술을 사용할 때 고려해야 하는 사항을 설명합니다. 기술의 기본적인 개요를 설명하고 기술을 튜닝하는 방법을 살펴봅니다.
일반적인 TCP/IP 튜닝 기술
MTU, 조각화 및 Large Send Offload
MTU
MTU(최대 전송 단위)는 네트워크 인터페이스를 통해 전송할 수 있는 최대 프레임(패킷) 크기이며 바이트 단위로 지정합니다. MTU는 구성 가능한 설정입니다. Azure VM에서 사용되는 기본 MTU와 전역적으로 대부분의 네트워크 디바이스에 대한 기본 설정은 1,500바이트입니다.
조각화
조각화는 네트워크 인터페이스의 MTU를 초과하는 패킷을 보낼 때 발생합니다. TCP/IP 스택은 패킷을 인터페이스의 MTU를 따르는 더 작은 조각으로 나눕니다. 조각화는 IP 계층에서 발생하며 TCP와 같은 기본 프로토콜과 상관이 없습니다. MTU가 1500인 네트워크 인터페이스를 통해 2000바이트 패킷을 보내면 패킷이 1500바이트 패킷 하나와 500바이트 패킷 하나로 분할됩니다.
원본과 대상 간의 경로에 있는 네트워크 디바이스는 MTU를 초과하는 패킷을 삭제하거나 패킷을 더 작은 조각으로 조각화할 수 있습니다.
IP 패킷의 Don't Fragment 비트
DF(Don't Fragment) 비트는 IP 프로토콜 헤더의 플래그입니다. DF 비트는 발신자와 수신자 간의 경로에 있는 네트워크 디바이스에서 패킷을 조각화하면 안 된다는 것을 나타냅니다. 여러 가지 이유로 이 비트를 설정할 수 있습니다. (그 중 한 가지 예제는 이 문서의 “경로 MTU 검색” 섹션에서 확인할 수 있습니다.) 네트워크 디바이스에서 Don’t Fragment 비트가 설정된 패킷을 수신하고 해당 패킷이 디바이스의 인터페이스 MTU를 초과하는 경우 디바이스에서 패킷을 삭제하는 것이 표준 동작입니다. 디바이스는 ICMP Fragmentation Needed 메시지를 패킷의 원래 원본으로 다시 보냅니다.
조각화가 성능에 미치는 영향
조각화는 성능에 부정적인 영향을 미칠 수 있습니다. 성능에 영향을 미치는 기본 이유 중 하나는 패킷의 조각화 및 재조립의 CPU/메모리에 미치는 영향입니다. 네트워크 디바이스가 패킷을 조각화해야 하는 경우 조각화를 수행하기 위해 CPU/메모리 리소스를 할당해야 합니다.
패킷을 다시 어셈블하는 경우에도 마찬가지입니다. 네트워크 디바이스는 모든 조각이 수신되어 원래 패킷으로 다시 어셈블할 수 있을 때까지 모든 조각을 저장해야 합니다.
Azure 및 조각화
Azure의 조각화된 패킷은 가속화된 네트워킹에서 처리하지 않습니다. VM이 조각화된 패킷을 받으면 비가속 경로를 통해 처리됩니다. 즉, 조각화된 패킷은 가속화된 네트워킹(짧은 대기 시간, 지터 감소 및 초당 더 높은 패킷)의 이점을 얻을 수 없습니다. 이러한 이유로 가능한 경우 조각화를 방지하는 것이 좋습니다.
기본적으로 Azure는 뒤죽박죽된 조각, 즉 원본 엔드포인트에서 전송된 순서대로 VM에 도착하지 않는 조각화된 패킷을 삭제합니다. 이 문제는 패킷이 인터넷 또는 기타 대형 WAN을 통해 전송될 때 발생할 수 있습니다. 경우에 따라 순서가 다른 조각의 순서를 재정렬하도록 설정할 수 있습니다. 애플리케이션에 이 설정이 필요한 경우 지원 사례를 엽니다.
MTU 튜닝
고객은 VM NIC에서 MTU를 늘리지 않는 것이 좋습니다. VM이 비슷한 MTU 집합이 있고 Virtual Network에 없는 대상과 통신해야 하는 경우 조각화가 발생하여 성능이 저하될 수 있습니다.
Large Send Offload
LSO(Large Send Offload)는 패킷의 조각화를 이더넷 어댑터에 오프로드하여 네트워크 성능을 향상할 수 있습니다. LSO를 사용하도록 설정하면 TCP/IP 스택은 큰 TCP 패킷을 만들어 이더넷 어댑터에 보내 조각화한 후 전달합니다. LSO의 이점은 CPU가 패킷을 MTU에 맞는 크기로 분할하고 해당 처리를 하드웨어에서 수행되는 이더넷 인터페이스로 오프로드할 수 있다는 것입니다. LSO의 이점에 대한 자세한 내용은 Large Send Offload 지원을 참조하세요.
LSO를 사용하면 Azure 고객이 패킷을 캡처할 때 큰 프레임이 발생할 수 있습니다. 이렇게 프레임이 크면 일부 고객은 조각화가 진행 중이라고 생각하거나 조각화가 진행 중이 아니라면 큰 MTU가 사용되고 있다고 생각할 수 있습니다. LSO를 사용하면 이더넷 어댑터가 더 큰 TCP 패킷을 만들기 위해 더 큰 MSS(최대 세그먼트 크기)를 TCP/IP 스택에 보급할 수 있습니다. 이렇게 분할되지 않은 전체 프레임은 이더넷 어댑터로 전달되고 VM에서 수행된 패킷 캡처에 표시됩니다. 그러나 패킷은 이더넷 어댑터의 MTU에 따라 이더넷 어댑터에 의해 더 작은 여러 프레임으로 분할됩니다.
TCP MSS 창 크기 조정 및 PMTUD
TCP 최대 세그먼트 크기
TCP MSS(최대 세그먼트 크기)는 TCP 세그먼트의 크기를 제한하는 설정으로, TCP 패킷의 조각화를 방지합니다. 운영 체제는 일반적으로 이 수식을 사용하여 MSS를 설정합니다.
MSS = MTU - (IP header size + TCP header size)
IP 헤더와 TCP 헤더는 각각 20바이트이거나 총 40바이트입니다. 따라서 MTU가 1500인 인터페이스의 MSS는 1,460이 됩니다. 그러나 MSS는 구성 가능합니다.
원본과 대상 간에 TCP 세션이 설정될 때 TCP 3방향 핸드셰이크에서 이 설정에 대한 동의가 이루어집니다. 양쪽 모두 MSS 값을 보내고, 둘 중 낮은 값이 TCP 연결에 사용됩니다.
원본 및 대상의 MTU는 MSS 값을 결정하는 유일한 요소가 아닙니다. Azure VPN Gateway를 비롯한 VPN 게이트웨이와 같은 중간 네트워크 디바이스는 네트워크 성능을 최적화하기 위해 원본 및 대상과 독립적으로 MTU를 조정할 수 있습니다.
경로 MTU 검색
MSS가 협상되었지만 사용할 수 있는 실제 MSS가 아닐 수도 있습니다. 원본과 대상 간의 경로에 있는 다른 네트워크 디바이스의 MTU 값이 원본 및 대상보다 작을 수 있기 때문입니다. 이 경우 MTU가 패킷보다 작은 디바이스의 패킷이 삭제됩니다. 디바이스는 해당 MTU를 포함하고 있는 ICMP Fragmentation Needed(유형 3, 코드 4) 메시지를 다시 보냅니다. 이 ICMP 메시지를 통해 원본 호스트는 해당 경로 MTU를 적절하게 줄일 수 있습니다. 이 프로세스를 PMTUD(경로 MTU 검색)라고 합니다.
PMTUD 프로세스는 비효율적이며 네트워크 성능에 영향을 줍니다. 네트워크 경로의 MTU를 초과하는 패킷이 전송되면 MSS를 낮춰서 패킷을 다시 전송해야 합니다. (예를 들어 경로의 네트워크 방화벽 때문에) 발신자가 ICMP Fragmentation Needed 메시지를 받지 못하는 경우(일반적으로 이것을 PMTUD 블랙홀이라고 함) 발신자는 MSS를 낮춰야 한다는 것을 알지 못하므로 지속적으로 패킷을 재전송합니다. 이러한 이유로 Azure VM MTU를 늘리지 않는 것이 좋습니다.
VPN 및 MTU
캡슐화를 수행하는 VM(예: IPsec VPN)을 사용하는 경우 패킷 크기 및 MTU와 관련된 몇 가지 추가 고려 사항이 있습니다. VPN은 패킷에 더 많은 헤더를 추가하므로 패킷 크기가 커지고 더 작은 MSS가 필요합니다.
Azure의 경우 TCP MSS 고정을 1350바이트로 설정하고 터널 인터페이스 MTU를 1400으로 설정하는 것이 좋습니다. 자세한 내용은 VPN 디바이스 및 IPSec/IKE 매개 변수 페이지를 참조하세요.
대기 시간, 왕복 시간 및 TCP 창 크기 조정
대기 시간 및 왕복 시간
네트워크 대기 시간은 파이버 광 네트워크를 통과하는 빛의 속도에 따라 결정됩니다. 또한 TCP의 네트워크 처리량은 두 네트워크 디바이스 간의 RTT(왕복 시간)에 의해 효과적으로 관리됩니다.
| 경로 | 거리 | 단방향 시간 | RTT |
|---|---|---|---|
| 뉴욕-샌프란시스코 | 4,148km | 21ms | 42ms |
| 뉴욕-런던 | 5,585km | 28밀리초 | 56ms |
| 뉴욕-시드니 | 15,993km | 80ms | 160ms |
다음 표에서는 두 위치 간의 직선 거리를 보여줍니다. 네트워크의 거리는 일반적으로 직선 거리보다 깁니다. 다음은 광속의 영향을 받는 최소 RTT를 계산하는 간단한 수식입니다.
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
전파 속도는 200을 사용하면 됩니다. 빛이 1밀리초 동안 이동하는 거리(킬로미터)입니다.
예를 들어 뉴욕-샌프란시스코를 살펴보겠습니다. 직선 거리는 4,148km입니다. 이 값을 방정식에 대입하면 다음과 같은 식이 됩니다.
Minimum RTT = 2 * (4,148 / 200)
방정식의 출력은 밀리초 단위입니다.
최상의 네트워크 성능을 얻기 위한 논리적 선택은 거리가 가장 짧은 대상을 선택하는 것입니다. 또한 트래픽 경로를 최적화하고 대기 시간을 줄이도록 가상 네트워크를 디자인해야 합니다. 자세한 내용은 이 문서의 "네트워크 디자인 고려 사항" 섹션을 참조하세요.
대기 시간 및 왕복 시간이 TCP에 미치는 영향
왕복 시간은 최대 TCP 처리량에 직접적인 영향을 줍니다. TCP 프로토콜에서 창 크기는 발신자가 수신자의 승인을 받아야 할 때까지 TCP 연결을 통해 전송할 수 있는 최대 트래픽 양입니다. TCP MSS가 1,460으로 설정되고 TCP 창 크기가 65,535로 설정된 경우 발신자는 패킷 45개를 보낸 후 수신자의 승인을 받아야 합니다. 발신자는 승인을 받지 못하면 데이터를 다시 전송합니다. 수식은 다음과 같습니다.
TCP window size / TCP MSS = packets sent
이 예제에서는 65,535/1,460을 반올림하여 45입니다.
안정적인 데이터 전송을 보장하는 메커니즘인 "승인 대기 중" 상태 때문에 RTT가 TCP 처리량에 영향을 주는 것입니다. 발신자가 승인을 기다리는 시간이 길수록 더 많은 시간을 기다렸다가 더 많은 데이터를 전송해야 합니다.
다음은 단일 TCP 연결의 최대 처리량을 계산하는 수식입니다.
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
이 표에서는 단일 TCP 연결의 최대 초당 처리량(메가바이트)을 보여 줍니다. (가독성을 위해 측정 단위로 메가바이트를 사용합니다.)
| TCP 창 크기(바이트) | RTT 대기 시간(ms) | 최대 초당 처리량(메가바이트) | 최대 초당 처리량(메가비트) |
|---|---|---|---|
| 65,535 | 1 | 65.54 | 524.29 |
| 65,535 | 30 | 2.18 | 17.48 |
| 65,535 | 60 | 1.09 | 8.74 |
| 65,535 | 90 | 0.73 | 5.83 |
| 65,535 | 120 | .55 | 4.37 |
패킷이 손실되면 발신자가 이미 보낸 데이터를 재전송할 때 TCP 연결의 최대 처리량이 감소합니다.
TCP 창 크기 조정
TCP 창 크기 조정은 승인이 필요할 때까지 더 많은 데이터를 전송할 수 있도록 TCP 창 크기를 동적으로 늘리는 기술입니다. 이전 예제에서는 승인이 필요할 때까지 45개 패킷이 전송됩니다. 승인이 필요할 때까지 전송할 수 있는 패킷 수를 늘리면 발신자가 승인을 대기하는 시간이 감소하고 TCP 최대 처리량이 증가합니다.
다음 표에서는 이러한 관계를 보여줍니다.
| TCP 창 크기(바이트) | RTT 대기 시간(ms) | 최대 초당 처리량(메가바이트) | 최대 초당 처리량(메가비트) |
|---|---|---|---|
| 65,535 | 30 | 2.18 | 17.48 |
| 131,070 | 30 | 4.37 | 34.95 |
| 262,140 | 30 | 8.74 | 69.91 |
| 524,280 | 30 | 17.48 | 139.81 |
그러나 TCP 창 크기의 TCP 헤더 값은 2바이트 길이입니다. 즉, 수신 창의 최댓값은 65,535입니다. 최대 창 크기를 늘리기 위해 TCP 창 배율 인수가 도입되었습니다.
배율 인수는 운영 체제에서 구성할 수 있는 설정이기도 합니다. 배율 인수를 사용하여 TCP 창 크기를 계산하는 수식은 다음과 같습니다.
TCP window size = TCP window size in bytes * (2^scale factor)
다음은 창 배율 인수가 3이고 창 크기가 65,535일 때의 계산 식입니다.
65,535 * (2^3) = 524,280 bytes
배율 인수가 14이면 TCP 창 크기는 14(허용되는 최대 오프셋)입니다. TCP 창 크기는 1,073,725,440바이트(8.5기가비트)입니다.
TCP 창 크기 조정 지원
Windows는 서로 다른 연결 형식에 대해 서로 다른 배율 인수를 설정할 수 있습니다. (연결 클래스로는 데이터 센터, 인터넷 등이 있습니다.) 다음과 같이 Get-NetTCPConnection PowerShell 명령을 사용하여 창 크기 조정 연결 유형을 볼 수 있습니다.
Get-NetTCPConnection
다음과 같이 Get-NetTCPSetting PowerShell 명령을 사용하여 각 클래스의 값을 볼 수 있습니다.
Get-NetTCPSetting
Set-NetTCPSetting PowerShell 명령을 사용하여 Windows의 초기 TCP 창 크기 및 TCP 크기 조정 인수를 설정할 수 있습니다. 자세한 내용은 Set-NetTCPSetting을 참조하세요.
Set-NetTCPSetting
다음은 AutoTuningLevel에 유효한 TCP 설정입니다.
| AutoTuningLevel | 배율 인수 | 크기 조정 승수 | 최대 창 크기를 계산하는 수식 |
|---|---|---|---|
| 사용 안 함 | 없음 | 없음 | 창 크기 |
| Restricted | 4 | 2^4 | 창 크기 * (2^4) |
| 매우 제한적 | 2 | 2^2 | 창 크기 * (2^2) |
| 일반 | 8 | 2^8 | 창 크기 * (2^8) |
| 실험적 | 14 | 2^14 | 창 크기 * (2^14) |
이러한 설정은 TCP 성능에 영향을 미칠 가능성이 높지만, Azure의 제어를 받지 않는 인터넷의 다른 여러 요소 역시 TCP 성능에 영향을 줄 수 있습니다.
가속화된 네트워킹 및 수신측 크기 조정
가속된 네트워킹
가상 머신 네트워크 기능은 이전부터 게스트 VM과 하이퍼바이저/호스트 모두에서 CPU 집약적이었습니다. 호스트를 통해 전송되는 모든 패킷은 모든 가상 네트워크 캡슐화 및 캡슐화 해제를 포함하여 호스트 CPU에 의해 소프트웨어에서 처리됩니다. 따라서 호스트를 통과하는 트래픽이 많을수록 CPU 부하가 높아집니다. 또한 호스트 CPU가 다른 작업을 수행 중인 경우 네트워크 처리량 및 대기 시간에도 영향을 줍니다. Azure는 가속화된 네트워킹을 통해 이 문제를 해결합니다.
가속화된 네트워킹은 Azure의 사내 프로그래밍 가능 하드웨어 및 SR-IOV와 같은 기술을 통해 일관적으로 매우 낮은 네트워크 대기 시간을 제공합니다. 가속화된 네트워킹은 Azure 소프트웨어 정의 네트워킹 스택의 대부분을 CPU에서 FPGA 기반 SmartNIC로 이동합니다. 이러한 변경을 통해 최종 사용자 애플리케이션은 컴퓨팅 주기를 회수할 수 있으며, 이로 인해 VM에 대한 부하가 줄어들고 지터와 대기 시간의 불일치가 줄어듭니다. 즉, 성능이 더 결정적일 수 있습니다.
가속화된 네트워킹을 사용하면 게스트 VM이 호스트를 우회하여 호스트의 SmartNIC와 직접 데이터 경로를 설정할 수 있으므로 성능이 향상됩니다. 다음은 가속화된 네트워킹의 몇 가지 이점입니다.
낮은 대기 시간/높은 초당 패킷 수(pps): 데이터 경로에서 가상 스위치를 제거하면 패킷이 정책 처리를 위해 호스트에서 소요하는 시간이 사라지고 VM 내에서 처리할 수 있는 패킷 수가 늘어납니다.
지터 감소: 가상 스위치 처리는 적용해야 하는 정책의 양과 처리를 수행하는 CPU의 워크로드에 따라 달라집니다. 정책 적용을 하드웨어로 오프로드하면 패킷이 VM으로 직접 전달되고, 호스트-VM 통신과 모든 소프트웨어 인터럽트 및 컨텍스트 전환이 제거되어 이러한 가변성이 해소됩니다.
CPU 사용률 감소: 호스트의 가상 스위치를 무시하면 네트워크 트래픽 처리에 사용되는 CPU가 감소됩니다.
가속화된 네트워킹을 사용하려면 해당하는 각 VM에서 명시적으로 가속화된 네트워킹을 사용하도록 설정해야 합니다. 가속화된 네트워킹을 사용하는 Linux 가상 머신 만들기 지침을 참조하세요.
수신측 크기 조정
RSS(수신측 크기 조정)는 수신 처리를 다중 프로세서 시스템의 여러 CPU에 분산하여 네트워크 트래픽 수신을 보다 효율적으로 분산하는 네트워크 드라이버 기술입니다. 간단히 말해서, RSS는 CPU 하나가 아닌 모든 가용 CPU를 사용하기 때문에 시스템에서 더 많은 수신 트래픽을 처리할 수 있습니다. RSS에 대한 자세한 기술 설명은 수신측 크기 조정 소개를 참조하세요.
VM에서 가속화된 네트워킹을 사용할 때 최상의 성능을 얻으려면 RSS를 사용하도록 설정해야 합니다. 또한 RSS는 가속화된 네트워킹을 사용하지 않는 VM에 도움이 될 수 있습니다. RSS가 사용되는지 확인하는 방법 및 사용하도록 설정하는 방법의 개요는 Azure 가상 머신의 네트워크 처리량 최적화를 참조하세요.
TCP TIME_WAIT 및 TIME_WAIT assassination
TCP TIME_WAIT는 네트워크 및 애플리케이션 성능에 영향을 주는 또 다른 공통 설정입니다. TCP가 정상적으로 작동하는 동안 클라이언트 또는 서버(원본 IP: 원본 포트 + 대상 IP: 대상 포트)로써 많은 소켓을 열고 닫는 사용 중인 VM에서, 특정 소켓이 결국 오랫동안 TIME_WAIT 상태가 될 수 있습니다. TIME_WAIT 상태는 소켓을 닫기 전에 소켓에서 추가 데이터가 전송되는 것을 허용한다는 뜻입니다. 따라서 TCP/IP 스택은 일반적으로 클라이언트의 TCP SYN 패킷을 자동으로 삭제하여 소켓 재사용을 방지합니다.
소켓이 TIME_WAIT 상태가 되는 시간을 구성할 수 있습니다. 30~240초 사이에서 구성할 수 있습니다. 소켓은 유한한 리소스이며, 특정 시간에 사용 가능한 소켓 수를 구성할 수 있습니다. (사용 가능한 소켓 수는 일반적으로 약 30,000개입니다.) 사용 가능한 소켓이 사용되거나 클라이언트와 서버의 TIME_WAIT 설정이 일치하지 않는 경우 VM이 TIME_WAIT 상태인 소켓을 다시 사용하려고 시도하면 TCP SYN 패킷이 자동으로 삭제되므로 새 연결이 실패합니다.
아웃바운드 소켓의 포트 범위 값은 일반적으로 운영 체제의 TCP/IP 스택 내에서 구성할 수 있습니다. TCP TIME_WAIT 설정 및 소켓 재사용의 경우에도 마찬가지입니다. 이러한 숫자를 변경하면 확장성이 향상될 수 있습니다. 그러나 상황에 따라 이러한 변경으로 인해 상호 운용성 문제가 발생할 수 있습니다. 이러한 값을 변경할 때에는 주의해야 합니다.
TIME_WAIT assassination을 사용하여 이러한 크기 조정 제한을 해결할 수 있습니다. TIME_WAIT assassination을 사용하면 새 연결의 IP 패킷에 있는 시퀀스 번호가 이전 연결의 마지막 패킷 시퀀스 번호를 초과하는 경우와 같은 상황에서 소켓을 다시 사용할 수 있습니다. 이 경우 운영 체제는 새 연결을 설정할 수 있도록 허용하고(새 SYN/ACK를 수락함) TIME_WAIT 상태인 이전 연결을 강제로 종료합니다. 이 기능은 Azure의 Windows VM에서 지원됩니다. 다른 VM의 지원에 대한 자세한 내용은 OS 공급업체에 문의하세요.
TCP TIME_WAIT 설정 및 원본 포트 범위 구성에 대한 자세한 내용은 네트워크 성능 향상을 위해 수정할 수 있는 설정을 참조하세요.
성능에 영향을 줄 수 있는 가상 네트워크 요소
VM 최대 아웃바운드 처리량
Azure는 다양한 VM 크기 및 유형을 제공하며, 각각 다양한 성능 기능 조합이 가능합니다. 이러한 기능 중 하나는 네트워크 처리량(또는 대역폭)이며 Mbps(초당 메가비트)로 측정됩니다. 가상 머신은 공유 하드웨어에 호스트되므로 동일한 하드웨어를 사용하는 가상 머신 간에 네트워크 용량을 균등하게 공유해야 합니다. 용량이 큰 가상 머신은 작은 가상 머신보다 더 많은 대역폭이 할당됩니다.
각 가상 머신에 할당된 네트워크 대역폭은 가상 머신에서의 송신(아웃바운드) 트래픽으로 측정됩니다. 가상 컴퓨터에서 나가는 모든 네트워크 트래픽은 대상에 관계없이 할당된 제한에 대해 계산됩니다. 예를 들어 가상 머신에 1,000Mbps 제한이 있는 경우 해당 제한은 송신 트래픽이 동일한 가상 네트워크의 다른 가상 머신을 대상으로 하는지 또는 Azure 외부의 다른 가상 머신을 대상으로 하는지에 관계없이 적용됩니다.
수신은 측정되거나 직접 제한되지 않습니다. 그러나 들어오는 데이터를 처리하는 가상 머신의 기능에 영향을 줄 수 있는 다른 요인(예: CPU 및 스토리지 제한)이 있습니다.
가속화된 네트워킹은 대기 시간, 처리량 및 CPU 사용률을 포함하여 네트워크 성능을 향상하도록 설계되었습니다. 가속화된 네트워킹은 가상 머신의 처리량을 향상할 수 있지만, 가상 머신에 할당된 최대 대역폭까지만 향상할 수 있습니다.
Azure 가상 머신에는 하나 이상의 네트워크 인터페이스가 연결됩니다. 여러 개를 연결할 수도 있습니다. 가상 머신에 할당된 대역폭은 가상 머신에 연결된 모든 네트워크 인터페이스의 전체 아웃바운드 트래픽 합계입니다. 즉, 대역폭은 가상 머신에 연결된 네트워크 인터페이스 수에 관계없이 가상 머신 단위로 할당됩니다.
각 VM 크기에 지원되는 예상 아웃바운드 처리량 및 네트워크 인터페이스 수는 Azure의 Windows 가상 머신 크기에 자세히 설명되어 있습니다. 최대 처리량을 확인하려면 유형(예: 범용)을 선택한 다음, 결과 페이지에서 크기 시리즈에 대한 섹션을 찾습니다(예: "Dv2 시리즈"). 각 시리즈의 마지막 열에는 네트워킹 사양을 제공하는 "최대 NIC/예상 네트워크 대역폭(Mbps)"이라는 테이블이 있습니다.
처리량 제한은 가상 컴퓨터에 적용됩니다. 처리량은 다음 요인의 영향을 받지 않습니다.
네트워크 인터페이스 수: 대역폭 제한은 가상 머신의 모든 아웃바운드 트래픽 합계에 적용됩니다.
가속화된 네트워킹: 이 기능은 게시된 제한까지 활용하는 데 도움이 되지만 제한을 변경하지는 않습니다.
트래픽 대상: 모든 대상이 아웃바운드 제한에 대해 계산됩니다.
프로토콜: 모든 프로토콜을 통한 모든 아웃바운드 트래픽이 제한에 대해 계산됩니다.
자세한 내용은 가상 머신 네트워크 대역폭을 참조하세요.
인터넷 성능 고려 사항
이 문서 전체에서 설명했듯이, Azure의 제어 범위를 벗어나는 인터넷의 요소는 네트워크 성능에 영향을 줄 수 있습니다. 다음은 이러한 요소 중 일부입니다.
대기 시간: 두 대상 간의 왕복 시간은 중간 네트워크에서 발생하는 문제, "최단" 거리 경로를 사용하지 않는 트래픽 및 최적이 아닌 피어링 경로에 의해 영향을 받을 수 있습니다.
패킷 손실: 패킷 손실은 네트워크 정체, 물리적 경로 문제 및 성능이 부족한 네트워크 디바이스 때문에 발생할 수 있습니다.
MTU 크기/조각화: 경로를 따라 조각화하면 데이터 도착이 지연되거나 순서 없이 도착하는 패킷에 영향을 줄 수 있으며, 이는 패킷 전송에 영향을 미칠 수 있습니다.
Traceroute는 원본 디바이스와 대상 디바이스 간의 모든 네트워크 경로를 따라 네트워크 성능 특성(예: 패킷 손실 및 대기 시간)을 측정하는 데 유용한 도구입니다.
네트워크 디자인 고려 사항
이 문서의 앞부분에서 설명한 고려 사항과 함께 가상 네트워크의 토폴로지는 네트워크의 성능에 영향을 줄 수 있습니다. 예를 들어 트래픽을 단일 허브 가상 네트워크에 전역적으로 백홀하는 허브 및 스포크 디자인은 네트워크 대기 시간을 유발하며, 이는 전반적인 네트워크 성능에 영향을 줍니다.
네트워크 트래픽이 통과하는 네트워크 디바이스 수도 전체 대기 시간에 영향을 줄 수 있습니다. 예를 들어 허브 및 스포크 디자인에서 트래픽이 스포크 네트워크 가상 어플라이언스와 허브 가상 어플라이언스를 통과한 후 인터넷에 전송되는 경우 네트워크 가상 어플라이언스에서 대기 시간이 발생할 수 있습니다.
Azure 지역, 가상 네트워크 및 대기 시간
Azure 지역은 일반적인 지역에 존재하는 여러 데이터 센터로 구성됩니다. 이러한 데이터 센터는 물리적으로 서로 붙어 있지 않을 수 있습니다. 경우에 따라 10킬로미터 떨어져 있기도 합니다. 가상 네트워크는 Azure 물리적 데이터 센터 네트워크 상에 있는 논리적 오버레이입니다. 가상 네트워크는 데이터 센터 내의 특정 네트워크 토폴로지를 의미하지 않습니다.
예를 들어 동일한 가상 네트워크 및 서브넷에 있는 두 VM이 서로 다른 랙, 행 또는 데이터 센터에 있을 수 있습니다. 수미터의 광섬유 케이블 또는 수킬로미터의 광섬유 케이블을 사용하여 분리할 수 있습니다. 이러한 변형으로 인해 서로 다른 VM 간에 가변 대기 시간(밀리초 단위의 차이)이 발생할 수 있습니다.
VM의 지리적 배치와 두 VM 간의 잠재적 대기 시간은 가용성 집합 및 가용성 영역의 구성에 의해 영향을 받을 수 있습니다. 그러나 한 지역에 있는 데이터 센터 간의 거리는 지역에 따라 다르며 주로 해당 지역의 데이터 센터 토폴로지의 영향을 받습니다.
원본 NAT 포트 소진
Azure에 배포되는 솔루션은 공용 인터넷 및/또는 공용 IP 공간에 있는 Azure 외부의 엔드포인트와 통신할 수 있습니다. 한 인스턴스에서 아웃바운드 연결을 시작하면 Azure는 개인 IP 주소를 공용 IP 주소에 동적으로 매핑합니다. Azure에서 이 매핑을 만들면 이 아웃바운드에서 시작된 흐름에 대한 반환 트래픽도 흐름이 시작된 개인 IP 주소에 연결할 수 있습니다.
모든 아웃바운드 연결에 대해 Azure Load Balancer는 일정 기간 동안 이 매핑을 유지해야 합니다. Azure의 다중 테넌트 특성 때문에 모든 VM의 모든 아웃바운드 흐름에 대해 이 매핑을 유지하려면 많은 리소스가 소모될 수 있습니다. 따라서 Azure Virtual Network의 구성에 따라 설정되는 제한이 있습니다. 보다 정확하게 말해서, Azure VM은 특정 시간에 특정 수의 아웃바운드 연결만 만들 수 있습니다. 이러한 제한에 도달하면 VM에서 더 이상 아웃바운드 연결을 만들 수 없습니다.
하지만 이 동작을 구성할 수 있습니다. SNAT 및 SNAT 포트 소진에 대한 자세한 내용은 이 문서를 참조하세요.
Azure에서 네트워크 성능 측정
이 문서의 다양한 성능 최댓값은 두 VM 간의 네트워크 대기 시간/RTT(왕복 시간)와 관련이 있습니다. 이 섹션에서는 대기 시간/RTT를 테스트하는 방법과 TCP 성능 및 VM 네트워크 성능을 테스트하는 방법에 대한 몇 가지 권장 사항을 제공합니다. 이 섹션에 설명된 기술을 사용하여 앞에서 설명한 TCP/IP 및 네트워크 값을 튜닝하고 성능을 테스트할 수 있습니다. 대기 시간, MTU, MSS 및 창 크기 값을 이전에 제공한 계산에 대입하고 이론적 최댓값을 테스트 중에 관찰되는 실제 값과 비교할 수 있습니다.
왕복 시간 및 패킷 손실 측정
TCP 성능은 RTT 및 패킷 손실에 크게 좌우됩니다. Windows 및 Linux에서 사용할 수 있는 PING 유틸리티는 RTT 및 패킷 손실을 측정하는 가장 쉬운 방법을 제공합니다. PING의 출력에는 원본과 대상 간의 최소/최대/평균 대기 시간이 표시됩니다. 패킷 손실도 표시됩니다. PING은 기본적으로 ICMP 프로토콜을 사용합니다. PsPing을 사용하여 TCP RTT를 테스트할 수 있습니다. 자세한 내용은 PsPing을 참조하세요.
가상 머신의 실제 대역폭 측정
Azure VM의 대역폭을 정확하게 측정하려면 이 지침을 따르세요.
다른 시나리오 테스트에 대한 자세한 내용은 다음 문서를 참조하세요.
비효율적인 TCP 동작 탐지
패킷 캡처에서 Azure 고객은 네트워크 성능 문제를 의미할 수 있는 TCP 플래그(SACK, DUP ACK, RETRANSMIT 및 FAST RETRANSMIT)가 있는 TCP 패킷을 볼 수 있습니다. 이러한 패킷은 특히 패킷 손실의 결과로 나타나는 네트워크 비효율성을 나타냅니다. 하지만 패킷 손실은 반드시 Azure 성능 문제 때문에 발생하지는 않습니다. 애플리케이션 문제, 운영 체제 문제 또는 Azure 플랫폼과 직접적인 관련이 없을 수 있는 기타 문제 때문에 성능 문제가 발생할 수 있습니다.
또한 일부 재전송 및 중복 ACK는 네트워크에서 정상입니다. TCP 프로토콜은 안정적으로 작동하도록 빌드되었습니다. 패킷 캡처에서 이러한 TCP 패킷의 증거는 과도한 경우를 제외하고 반드시 시스템 네트워크 문제를 의미하지는 않습니다.
그럼에도 불구하고, 이러한 패킷 유형은 이 문서의 다른 섹션에 설명된 이유로 TCP 처리량이 최대 성능을 달성하지 못하고 있다는 것을 나타냅니다.
다음 단계
Azure VM의 TCP/IP 성능 튜닝에 대해 알아보았으므로, 이제 가상 네트워크 계획에 대한 기타 고려 사항 또는 가상 네트워크 연결 및 구성에 대해 자세히 알아볼 수 있습니다.