Azure Virtual Machine에 대한 네트워크 처리량 최적화

Azure VM(가상 머신)에는 처리량 및 일관성을 개선하기 위해 최적화할 수 있는 기본 네트워크 설정이 있습니다. 이 문서에서는 Windows 및 Linux VM에 대한 네트워크 성능을 최적화하는 방법을 설명합니다.

Important

이 문서에 설명된 많은 최적화(예: 정체 제어, 큐 분야, 버퍼 크기 및 NIC 튜닝)는 시스템 간의 트래픽 흐름 방식에 영향을 줍니다.

최상의 결과를 위해 다음을 포함하여 워크로드에 참여하는 모든 가상 머신에 이러한 설정을 일관되게 적용합니다.

클라이언트 시스템
서버 시스템

가상 머신의 하위 집합에만 이러한 구성을 적용하면 다음이 발생할 수 있습니다.

일관되지 않은 처리량
패킷 재전송 증가
비최적 혼잡 동작

항상 전체 데이터 경로에서 변경 내용의 유효성을 검사하고 엔드 투 엔드 성능을 테스트합니다.

Windows 가상 머신

Windows VM에서 가속화된 네트워킹을 지원하는 경우 최적의 처리량을 위해 해당 기능을 사용하도록 설정합니다. 자세한 내용은 가속화된 네트워킹을 사용하여 Windows VM 만들기를 참조하세요.

다른 모든 Windows VM의 경우 RSS(수신측 크기 조정)는 RSS가 없는 VM보다 더 높은 최대 처리량을 제공할 수 있습니다. RSS는 기본적으로 사용하지 않도록 설정될 수 있습니다. RSS가 사용하도록 설정되어 있는지 확인하고 사용하도록 설정하려면 다음 단계를 수행합니다.

Get-NetAdapterRss PowerShell 명령을 사용하여 네트워크 어댑터에 RSS를 사용할 수 있는지 확인합니다. 다음 예제에서 Get-NetAdapterRss 출력은 RSS가 활성화되지 않음을 보여 줍니다.
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : False
```
RSS를 사용하도록 설정하려면 다음 명령을 입력합니다.
```
Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}
```
이 명령에는 출력이 없습니다. NIC(네트워크 인터페이스 카드) 설정을 변경하고 약 1분 동안 일시적으로 연결이 끊깁니다. 연결이 끊긴 동안 다시 연결 중 대화 상자가 나타납니다. 일반적으로 세 번째 시도 후 연결이 복원합니다.
Get-NetAdapterRss 명령을 다시 입력하여 VM에서 RSS가 사용되도록 설정되어 있는지 확인합니다. 성공하면 다음 예제 출력이 반환됩니다.
```
Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Enabled                 : True
```

Linux 가상 머신

RSS는 기본적으로 Azure Linux VM(가상 머신)에서 사용하도록 설정됩니다. 2017년 10월 이후 릴리스된 Linux 커널에는 Linux VM이 더 높은 처리량을 달성하는 데 도움이 되는 추가 네트워크 최적화 옵션이 포함되어 있습니다.

최적의 처리량을 위해 Azure 가속 네트워킹 사용

Azure 가속화된 네트워킹은 처리량을 크게 향상시키고 대기 시간과 지터를 줄일 수 있습니다. VM 크기 및 플랫폼 생성에 따라 Azure 널리 사용 가능한 Mellanox와 Microsoft 개발한 MANA의 두 가지 기술 중 하나를 사용합니다.

Azure 튜닝 커널

Ubuntu(정식) 및 SUSE와 같은 일부 배포판은 Azure 조정된 커널을 제공합니다.

다음 명령을 사용하여 커널 이름에 일반적으로 포함된 azure Azure 커널을 사용하고 있는지 확인합니다.

uname -r

# Sample output for an Azure kernel on an Ubuntu Linux VM
6.8.0-1017-azure

기타 Linux 배포

최신 배포에는 최신 커널의 주요 네트워킹 개선 사항이 포함됩니다. 커널 버전을 확인하고 가능하면 4.19 이상을 사용합니다. 최신 커널에는 더 나은 네트워킹 동작이 포함되며 BBR과 같은 최신 정체 제어 옵션을 지원합니다.

Azure의 Linux VM에서 일관된 전송 속도 달성

Linux VM은 특히 대규모 지역 전송 중에 일관되지 않은 전송 속도를 표시할 수 있습니다(예: 서유럽과 미국 서부 간 1GB~50GB). 일반적인 원인으로는 구형 커널, 기본 버퍼 크기, 그리고 최적화되지 않은 혼잡 제어 또는 큐 규율 설정이 있습니다.

더 일관된 처리량을 얻으려면 다음 기본 튜닝을 적용한 다음 워크로드에 맞는 혼잡 제어/qdisc 조합을 테스트하세요.

기본 sysctl 튜닝 (복사/붙여넣기)

다음 기준 sysctl 설정을 적용합니다.

sudo tee /etc/sysctl.d/99-azure-network-tuning.conf > /dev/null <<'EOF'
# Buffer and memory tuning
# Overall TCP memory pressure thresholds (min, pressure, max pages)
net.ipv4.tcp_mem = 4096 87380 67108864
# Overall UDP memory pressure thresholds (min, pressure, max pages)
net.ipv4.udp_mem = 4096 87380 33554432
# Per-socket TCP read buffer limits (min, default, max bytes)
net.ipv4.tcp_rmem = 4096 87380 67108864
# Per-socket TCP write buffer limits (min, default, max bytes)
net.ipv4.tcp_wmem = 4096 65536 67108864
# Default socket receive buffer size in bytes
net.core.rmem_default = 33554432
# Default socket send buffer size in bytes
net.core.wmem_default = 33554432
# Minimum UDP send buffer per socket in bytes
net.ipv4.udp_wmem_min = 16384
# Minimum UDP receive buffer per socket in bytes
net.ipv4.udp_rmem_min = 16384
# Maximum socket send buffer size in bytes
net.core.wmem_max = 134217728
# Maximum socket receive buffer size in bytes
net.core.rmem_max = 134217728
# Busy polling time in microseconds for low-latency packet receive
net.core.busy_poll = 50
# Busy read time in microseconds when polling sockets
net.core.busy_read = 50

# Extra TCP and networking settings
# Enable TCP timestamps for RTT measurement and PAWS protection
net.ipv4.tcp_timestamps = 1
# Allow safer TIME-WAIT socket reuse for outbound connections
net.ipv4.tcp_tw_reuse = 1
# Expand available ephemeral source port range
net.ipv4.ip_local_port_range = 1024 65535
# Increase packets processed per NAPI polling cycle
net.core.netdev_budget = 1000
# Increase per-socket ancillary/option memory limit in bytes
net.core.optmem_max = 65535
# Disable F-RTO (typically unnecessary on stable wired paths)
net.ipv4.tcp_frto = 0
# Increase maximum listen backlog for pending connections
net.core.somaxconn = 32768
# Increase ingress packet backlog queue length
net.core.netdev_max_backlog = 32768
# Increase per-CPU packet processing quota per softirq cycle
net.core.dev_weight = 64
EOF

sudo sysctl --system

혼잡 제어 및 qdisc 테스트 (sysctl)

워크로드가 다르게 동작합니다. 이러한 조합을 테스트하고 대기 시간, 처리량 및 재전송 프로필에 가장 적합한 결과를 제공하는 조합을 유지합니다.

BBR + FQ (종종 높은 처리량 및 장거리 전송에 대한 강력한 기본값)

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq

BBR + PFIFO_FAST (버스트 또는 혼합 트래픽에서 큐 동작을 비교하는 데 유용)

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=pfifo_fast

CUBIC + PFIFO_FAST (호환성 및 비교를 위한 일반적인 레거시 기준선)

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic
sudo sysctl -w net.core.default_qdisc=pfifo_fast

대표 트래픽을 사용하여 각 옵션을 측정한 다음 사용자 환경에 가장 적합한 조합을 사용합니다.

비고

pfifo_fast 가용성은 배포판/커널에 따라 달라질 수 있습니다. 사용할 수 없는 경우 사용자 환경에서 가장 가까운 지원되는 qdisc 옵션을 사용하고 벤치마킹을 계속합니다.

NIC 링 버퍼에 대한 UDEV 규칙(TX/RX)

네트워크 인터페이스에 /etc/udev/rules.d/99-azure-ring-buffer.rules 링 버퍼 설정을 적용하는 udev 규칙을 만듭니다.

가속 네트워킹 인터페이스(hv_pci)에는 rx 4096 tx 4096를 사용하고, 합성 hv_netvsc 인터페이스에는 rx 1024 tx 1024를 유지합니다.

링 버퍼 튜닝에 대한 대화형 방법을 선호하는 경우 이 도우미 도구인 Azure Linux NIC 설정(bash)을 사용할 수도 있습니다.

비고

이 GitHub 도구는 선택적 도우미이며 Microsoft Learn 제품 설명서에 포함되지 않습니다. 광범위한 롤아웃 전에 비프로덕션 환경에서 스크립트를 검토하고 변경 내용을 테스트합니다.

# Setup Accelerated Interface ring buffers (Mellanox / Mana) 
SUBSYSTEM=="net", DRIVERS=="hv_pci", ACTION=="add",  RUN+="/usr/sbin/ethtool -G $env{INTERFACE} rx 4096 tx 4096"

# Setup Synthetic interface ring buffers (hv_netvsc)
SUBSYSTEM=="net", DRIVERS=="hv_netvsc*", ACTION=="add",  RUN+="/usr/sbin/ethtool -G $env{INTERFACE} rx 1024 tx 1024"

인터페이스 이벤트 시 qdisc용 UDEV 규칙

벤치마킹을 완료하고 원하는 qdisc를 선택한 후 네트워크 인터페이스가 추가되거나 변경될 때 해당 qdisc를 적용하는 udev 규칙을 /etc/udev/rules.d/99-azure-qdisc.rules 만듭니다.

테스트 중에 선택한 qdisc(예: fq 또는 pfifo_fast)로 <qdisc_choice>를 바꾸십시오:

ACTION=="add|change", SUBSYSTEM=="net", KERNEL=="enp*", PROGRAM="/sbin/tc qdisc replace dev \$env{INTERFACE} root noqueue"
ACTION=="add|change", SUBSYSTEM=="net", KERNEL=="eth*", PROGRAM="/sbin/tc qdisc replace dev \$env{INTERFACE} root <qdisc_choice>"

NIC 전송 큐 길이에 대한 UDEV 규칙

전송 큐 길이를 늘리려면 다음 규칙을 /etc/udev/rules.d/99-azure-txqueue-len.rules 만듭니다.

SUBSYSTEM=="net", ACTION=="add|change", KERNEL=="eth*", ATTR{tx_queue_len}="10000"

IRQ 스케줄링(irqbalance)

워크로드에 따라 irqbalance 서비스가 특정 노드에서 IRQ를 예약하지 못하도록 제한할 수 있습니다. IRQBalance를 사용하는 경우 IRQ가 할당되지 않아야 하는 CPU를 지정하도록 /etc/default/irqbalance를 업데이트합니다. 이러한 CPU를 제외하는 마스크 를 결정해야 합니다.

마스크를 계산하는 방법에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

SR-IOV 이중 인터페이스 동작 및 부작용

Linux 고성능 네트워킹에서 Azure SR-IOV(예: mlx4mlx5Mellanox 드라이버 등)를 사용합니다. 이 모델에서는 동일한 VM 네트워킹 경로에 대한 가상 인터페이스와 VF(가상 함수) 인터페이스를 모두 볼 수 있습니다. 자세히알아보세요.

이 디자인은 예상되지만 두 인터페이스가 모두 독립적인 데이터 경로로 처리되는 경우 튜닝 및 문제 해결 중에 혼동을 일으킬 수 있습니다.

가능한 부작용은 다음과 같습니다.

설정이 한 인터페이스에 적용되지만 트래픽이 다른 인터페이스를 사용하는 경우 일치하지 않는 벤치마크 결과입니다.
합성 경로와 VF 경로 간 장애 조치 중 예기치 않은 지연 시간 급증 또는 재전송
잘못된 인터페이스에서 카운터 및 패킷 캡처가 수집되는 경우 잘못된 진단입니다.

위험을 줄이려면 다음을 수행합니다.

튜닝하기 전에 워크로드 트래픽을 전달하는 인터페이스의 유효성을 검사합니다.
udev 및 sysctl 튜닝을 인터페이스 전략과 일관되게 유지합니다.
다시 부팅, 드라이버 업데이트 또는 가속화된 네트워킹 상태 변경 후 처리량 및 대기 시간을 다시 테스트합니다.

추가 참고 사항

시스템 관리자는 구성 파일(예: /etc/sysctl.d//etc/modules-load.d/, 및 /etc/udev/rules.d/)을 편집하여 이러한 권장 사항을 구현할 수 있습니다. 회귀를 방지하기 위해 커널 및 드라이버 업데이트를 주의 깊게 검토합니다.

특정 구성 및 문제 해결에 대한 자세한 내용은 네트워킹 성능에 대한 Azure 설명서를 참조하세요.

짧은 대기 시간을 위해 근접 배치 그룹을 사용하여 VM을 서로 가깝게 배포합니다.
시나리오에 맞는 대역폭/처리량 테스트를 통해 최적화된 결과를 확인합니다.
가상 머신에 대역폭이 할당되는 방법에 대해 알아봅니다.
Azure Virtual Network 질문과 대답을 읽어보세요.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-06-20