네트워크 성능 문제 해결
개요
Azure는 온-프레미스 네트워크를 Azure에 빠르고 안정적으로 연결하는 방법을 제공합니다. 사이트 간의 VPN 및 ExpressRoute와 같은 메서드는 모든 규모의 고객이 Azure에서 비즈니스를 실행하는 데 성공적으로 사용됩니다. 그러나 성능이 기대 또는 이전 경험을 충족하지 못하면 어떻게 되나요? 이 문서에서는 특정 환경을 테스트하고 기준을 설정하는 방법을 표준화합니다.
두 호스트 간의 네트워크 대기 시간 및 대역폭을 쉽고 일관되게 테스트하는 방법을 알아봅니다. 또한 문제 지점을 격리하는 데 도움이 되는 Azure 네트워크를 살펴보는 방법에 대한 조언을 받게 됩니다. 설명해 드린 PowerShell 스크립트 및 도구를 사용하려면 네트워크에 두 개 호스트가 필요합니다(테스트할 링크의 양쪽 끝에 하나씩). 한 호스트는 Windows Server 또는 데스크톱이어야 하고 다른 호스트는 Windows 또는 Linux일 수 있습니다.
네트워크 구성 요소
문제 해결 방법을 자세히 살펴보기 전에 일반적인 용어 및 구성 요소를 살펴보겠습니다. 이 토론을 통해 Azure에서 연결이 가능하게 해주는 엔드투엔드 체인의 각 구성 요소에 대해 알아볼 것입니다.
최상위 수준에는 세 가지 주요 네트워크 라우팅 도메인이 있습니다.
- Azure 네트워크(파란색 클라우드)
- 인터넷 또는 WAN(녹색 클라우드)
- 회사 네트워크(주황색 클라우드)
오른쪽에서 왼쪽으로 다이어그램을 살펴보면 각 구성 요소에 대해 간략하게 살펴보겠습니다.
가상 머신 - 서버에 여러 NIC가 있을 수 있습니다. 고정 경로, 기본 경로 및 운영 체제 설정이 개발자의 생각대로 트래픽을 주고 받도록 만들어야 합니다. 또한 각 VM SKU에는 대역폭 제한이 있습니다. 작은 VM SKU를 사용하는 경우 NIC에 제공되는 대역폭에 따라 트래픽이 제한됩니다. VM에서 적절한 대역폭을 보장하기 위해 테스트에 DS5v2를 사용하는 것이 좋습니다.
NIC - 의심스러운 NIC에 할당된 프라이빗 IP를 알아야 합니다.
NIC NSG - NIC 수준에서 특정 NSG가 적용될 수 있습니다. NSG 규칙 집합이 전달하려는 트래픽에 적합해야 합니다. 예를 들어 테스트 트래픽을 전달할 수 있도록 iPerf에 대한 5201, RDP에 대한 3389 또는 SSH에 대한 22를 열어야 합니다.
VNet 서브넷 - NIC가 특정 서브넷에 할당됩니다. 해당 서브넷과 연결된 하나 및 규칙을 알고 있는지 확인합니다.
서브넷 NSG - NIC와 마찬가지로 서브넷 수준에서도 NSG를 적용할 수 있습니다. NSG 규칙 집합이 전달하려는 트래픽에 적합해야 합니다. NIC에 대한 트래픽 인바운드의 경우 서브넷 NSG가 먼저 적용된 다음, NIC NSG가 적용됩니다. 트래픽이 VM에서 아웃바운드되는 경우 NIC NSG가 먼저 적용된 다음 서브넷 NSG가 적용됩니다.
서브넷 UDR - 사용자 정의 경로가 트래픽을 중간 홉(예: 방화벽 또는 부하 분산 장치)으로 보낼 수 있습니다. 트래픽에 대해 UDR이 있는지 알고 있어야 합니다. 있는 경우, 어디로 이동하는지와 다음 홉이 트래픽에 대해 수행할 작업에 대해 이해합니다. 예를 들어, 방화벽이 동일한 두 호스트 사이에서 일부 트래픽을 전달하고 다른 트래픽을 거부할 수 있습니다.
게이트웨이 서브넷/NSG/UDR - VM 서브넷과 마찬가지로, 게이트웨이 서브넷에 NSG와 UDR이 있을 수 있습니다. NSG와 UDR이 있는지 여부와 트래픽에 미치는 영향을 알아야 합니다.
VNet 게이트웨이(ExpressRoute) - 피어링(ExpressRoute) 또는 VPN을 사용하도록 설정되면 트래픽이 라우팅되는 방식 또는 그 여부에 영향을 줄 수 있는 설정은 그리 많지 않습니다. 여러 ExpressRoute 회로 또는 VPN 터널에 연결된 가상 네트워크 게이트웨이가 있는 경우, 연결 가중치 설정을 알고 있어야 합니다. 연결 가중치는 연결 기본 설정에 영향을 주며 트래픽이의 경로를 결정합니다.
경로 필터(표시되지 않음) - ExpressRoute를 통해 Microsoft 피어링을 사용하는 경우 경로 필터가 필요합니다. 경로를 수신하지 않는 경우 경로 필터가 구성되어 있으며 회로에 올바르게 적용되었는지 확인하세요.
현재 위치는 링크의 WAN 부분입니다. 이 라우팅 도메인은 서비스 공급자, 회사 WAN 또는 인터넷일 수 있습니다. 이러한 링크에는 여러 홉, 디바이스 및 회사가 관련되어 있어 문제를 해결하기 어려울 수 있습니다. Azure와 회사 네트워크 사이의 홉을 조사하려면 먼저 Azure와 회사 네트워크를 모두 제외해야 합니다.
이전 다이어그램에서 맨 왼쪽에 있는 것이 여러분의 회사 네트워크입니다. 회사 크기에 따라 이 라우팅 도메인은 여러분과 WAN 사이에 있는 몇 대의 네트워크 디바이스이거나 캠퍼스/엔터프라이즈 네트워크의 디바이스 레이어일 수 있습니다.
이러한 세 가지 고급 네트워크 환경의 복잡성을 감안할 때 가장자리에서 시작하여 성능이 좋은 위치와 성능이 저하되는 위치를 표시하는 것이 가장 좋습니다. 이 방법은 세 가지의 도메인을 라우팅하는 문제를 식별하는 데 도움이 됩니다. 그런 다음에는 해당 환경에서 문제 해결에 집중할 수 있습니다.
도구
대부분의 네트워크 문제는 ping 및 traceroute 같은 기본 도구를 사용하여 분석하고 격리할 수 있습니다. Wireshark와 같은 도구를 사용하여 패킷 분석을 할 정도로 깊이 들어가야 하는 경우는 드뭅니다.
문제 해결에 도움을 주기 위해 이러한 도구 중 일부를 간편한 패키지에 집어넣는 AzureCT(Azure 연결 도구 키트)가 개발되었습니다. 성능 테스트의 경우, iPerf 및 PSPing과 같은 도구에서 네트워크에 대한 정보를 제공할 수 있습니다. iPerf는 기본 성능 테스트에 일반적으로 사용되는 도구이며 매우 사용하기 쉽습니다. PSPing은 SysInternals에서 개발한 ping 도구입니다. PSPing은 ICMP 및 TCP ping을 모두 수행하여 원격 호스트에 연결할 수 있습니다. 이러한 두 도구는 모두 가볍고 호스트의 디렉터리에 파일을 복사하여 "설치"됩니다.
이러한 도구와 메서드는 사용자가 설치 및 사용할 수 있는 PowerShell 모듈(AzureCT)에 통합되었습니다.
AzureCT - Azure 연결 도구 키트
AzureCT PowerShell 모듈에는 가용성 테스트 및 성능 테스트라는 두 가지 구성 요소가 포함되어 있습니다. 이 문서에서는 성능 테스트, 특히 이 PowerShell 모듈의 두 가지 연결 성능 명령에 중점을 둡니다.
다음은 성능 테스트에 이 도구 키트를 사용하는 세 가지 기본 단계입니다.
PowerShell 모듈 설치
(new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression이 명령은 PowerShell 모듈을 로컬로 다운로드하고 설치합니다.
지원 애플리케이션 설치
Install-LinkPerformance이 AzureCT 명령은 새 디렉터리에
C:\ACTToolsiPerf 및 PSPing을 설치하고 Windows 방화벽 포트를 열어 ICMP 및 포트 5201(iPerf) 트래픽을 허용합니다.성능 테스트 실행
먼저 원격 호스트에서 서버 모드에서 iPerf를 설치하고 실행합니다. 원격 호스트가 3389(Windows용 RDP) 또는 22(linux용 SSH)에서 수신 대기하고 5201 포트에서 iPerf에 대한 트래픽을 허용해야 합니다. 원격 호스트가 Windows인 경우 AzureCT를 설치하고 Install-LinkPerformance 명령을 실행하여 iPerf 및 필요한 방화벽 규칙을 설정합니다.
원격 컴퓨터가 준비되면 로컬 컴퓨터에서 PowerShell을 열고 테스트를 시작합니다.
Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10이 명령은 일련의 동시 부하 및 대기 시간 테스트를 실행하여 네트워크 링크의 대역폭 용량 및 대기 시간을 예측합니다.
테스트 출력 검토
PowerShell 출력 형식은 다음과 비슷합니다.
모든 iPerf 및 PSPing 테스트의 자세한 결과는 AzureCT 도구 디렉터리의
C:\ACTTools개별 텍스트 파일에 저장됩니다.
문제 해결
성능 테스트 결과가 예상대로 되지 않는 경우 체계적인 접근 방식을 따라 문제를 식별합니다. 경로의 구성 요소 수를 감안할 때 단계별 프로세스는 임의 테스트보다 더 효과적입니다.
참고 항목
여기에 제시된 시나리오는 연결 문제가 아닌 성능 문제입니다. Azure 네트워크에 대한 연결 문제를 격리하려면 ExpressRoute 연결 확인 문서를 따릅니다.
가정에 도전
기대치가 합리적인지 확인합니다. 예를 들어 1Gbps ExpressRoute 회로와 100ms의 대기 시간으로 인해 긴 대기 시간 링크를 통해 TCP의 성능 특성으로 인해 전체 1Gbps의 트래픽을 예상하는 것은 비현실적입니다. 성능 가정에 대한 자세한 내용은 참조 섹션을 참조하세요.
네트워크의 가장자리에서 시작
라우팅 도메인 간의 에지에서 시작하여 단일 주요 라우팅 도메인으로 문제를 격리해 봅니다. 철저한 조사 없이 경로의 "블랙 박스"를 비난하지 마십시오. 이는 해결을 지연할 수 있기 때문에.
다이어그램 만들기
문제를 체계적으로 처리하고 격리하기 위해 해당 영역의 다이어그램을 그립니다. 영역을 지우거나 심층 분석할 때 테스트 지점을 계획하고 지도를 업데이트합니다.
분열과 정복
네트워크를 분할하고 문제를 좁힐 수 있습니다. 작동 위치와 작동하지 않는 위치를 식별하고, 테스트 지점을 계속 이동하여 잘못된 구성 요소를 격리합니다.
모든 OSI 계층 고려
네트워크 및 계층 1-3(물리적, 데이터 및 네트워크 계층)에 집중하는 것이 일반적이지만 계층 7(애플리케이션 계층)에서도 문제가 발생할 수 있습니다. 열린 마음을 유지하고 모든 가정을 확인합니다.
고급 ExpressRoute 문제 해결
클라우드의 가장자리가 어디에 있는지 확실하지 않은 경우 Azure 구성 요소를 격리하는 것이 어려울 수 있습니다. ExpressRoute를 사용하면 에지는 MSEE(Microsoft Enterprise Edge)라는 네트워크 구성 요소입니다. MSEE는 Microsoft의 네트워크에 대한 첫 번째 연락 지점이자 종료 시 마지막 홉입니다. 가상 네트워크 게이트웨이와 ExpressRoute 회로 간에 연결을 만들 때 MSEE에 연결합니다. MSEE를 첫 번째 또는 마지막 홉으로 인식하는 것은 Azure 네트워킹 문제를 격리하는 데 중요합니다. 트래픽 방향을 알면 문제가 Azure에 있는지 또는 WAN 또는 회사 네트워크의 추가 다운스트림에 있는지 확인하는 데 도움이 됩니다.
참고 항목
MSEE는 Azure 클라우드에 없습니다. ExpressRoute는 실제로 Azure가 아닌 Microsoft 네트워크의 가장자리에 있습니다. ExpressRoute와 MSEE에 연결되면 Microsoft의 네트워크에 연결되어 Microsoft 365(Microsoft 피어링 사용) 또는 Azure(프라이빗 및/또는 Microsoft 피어링 사용)와 같은 클라우드 서비스에 액세스할 수 있습니다.
두 VNet이 동일한 ExpressRoute 회로에 연결된 경우 테스트를 수행하여 Azure에서 문제를 격리할 수 있습니다.
테스트 계획
VM1 및 VM2 간의 Get-LinkPerformance 테스트를 실행합니다. 이 테스트는 문제가 로컬인지 여부에 대한 인사이트를 제공합니다. 테스트에서 허용 가능한 대기 시간 및 대역폭 결과를 생성하는 경우 로컬 가상 네트워크를 양선으로 표시할 수 있습니다.
로컬 가상 네트워크 트래픽이 양호하다고 가정하고 VM1 및 VM3 간의 Get LinkPerformance 테스트를 실행합니다. 이 테스트는 Microsoft 네트워크를 거쳐 MSEE까지 갔다가 다시 Azure로 돌아오는 연결을 실행합니다. 테스트에서 허용 가능한 대기 시간 및 대역폭 결과를 생성하는 경우 Azure 네트워크를 양수로 표시할 수 있습니다.
Azure가 제외된 경우 회사 네트워크에서 유사한 테스트를 수행합니다. 이러한 테스트도 좋은 경우 서비스 공급자 또는 ISP와 협력하여 WAN 연결을 진단합니다. 예를 들어 두 지점 간 또는 책상과 데이터 센터 서버 간에 테스트를 실행합니다. 테스트하는 경로를 실행할 수 있는 서버 및 클라이언트 PC와 같은 엔드포인트를 찾습니다.
Important
각 테스트에 대해 하루 중 시간을 표시하고 결과를 공통 위치에 기록합니다. 각 테스트 실행에는 일관된 데이터 비교를 위해 동일한 출력이 있어야 합니다. 여러 테스트의 일관성은 문제 해결을 위해 AzureCT를 사용하는 주된 이유입니다. 키는 매번 일관된 테스트 및 데이터 출력을 가져오는 것입니다. 시간을 기록하고 일관된 데이터를 갖는 것은 문제가 산발적인 경우에 특히 유용합니다. 동일한 시나리오를 재시도하는 시간을 방지하려면 데이터 수집을 선불로 사용하여 부지런히 해야 합니다.
문제를 격리한 후에는 어떻게 해야 할까요?
문제를 더 많이 격리할수록 솔루션을 빠르게 찾을 수 있습니다. 경우에 따라 문제 해결을 통해 더 이상 진행할 수 없는 지점에 도달할 수 있습니다. 예를 들어 아시아에 남아 있을 것으로 예상되는 경우 서비스 공급자가 유럽을 통해 홉을 사용하는 링크가 표시될 수 있습니다. 이 시점에서 문제를 격리한 라우팅 도메인에 따라 다른 사람에게 도움을 요청합니다. 특정 구성 요소로 축소하는 것이 더 좋습니다.
회사 네트워크 문제인 경우, 내부 IT 부서 또는 서비스 공급자가 디바이스 구성 또는 하드웨어 복구를 도와줄 수 있습니다.
WAN 문제의 경우 테스트 결과를 서비스 공급자 또는 ISP와 공유하여 작업을 돕고 중복 작업을 방지합니다. 신뢰 원칙 에 따라 결과를 확인하지만 확인할 수 있습니다.
Azure 문제의 경우 문제를 최대한 자세히 격리한 후 Azure 네트워크 설명서를 검토하고 필요한 경우 지원 티켓을 엽니다.
참조
대기 시간/대역폭 예상치
팁
엔드포인트 간 지리적 거리는 대기 시간의 가장 큰 요소입니다. 장비 대기 시간(물리적 및 가상 구성 요소, 홉 수 등)도 역할을 하지만 직선 거리가 아닌 파이버 실행의 거리가 주요 기여자입니다. 이 거리는 정확하게 측정하기 어렵기 때문에 대략적인 예측에 도시 거리 계산기를 사용하는 경우가 많습니다.
예를 들어 미국 워싱턴 주 시애틀에 ExpressRoute를 설정했습니다. 아래 표에서는 예상 거리와 함께 다양한 Azure 위치로 테스트할 때 관찰되는 대기 시간 및 대역폭을 보여 줍니다.
테스트 설정:
Windows Server 2016을 실행하고 10Gbps NIC를 사용하고 ExpressRoute 회로에 연결된 물리적 서버.
프라이빗 피어링을 사용하도록 설정된 10Gbps 프리미엄 ExpressRoute 회로입니다.
지정된 지역의 UltraPerformance 게이트웨이를 사용하는 Azure 가상 네트워크.
AzureCT가 설치된 기본 Azure 이미지를 사용하여 가상 네트워크에서 Windows Server 2016을 실행하는 DS5v2 VM입니다.
모든 테스트에서는 6개의 테스트 실행 각각에 대해 5분 부하 테스트와 함께 AzureCT Get-LinkPerformance 명령을 사용했습니다. 예시:
Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300각 테스트의 데이터 흐름은 온-프레미스 서버(시애틀의 iPerf 클라이언트)에서 Azure VM(나열된 Azure 지역의 iPerf 서버)으로 진행되었습니다.
"대기 시간" 열은 부하 없음 테스트(iPerf를 실행하지 않고 TCP 대기 시간 테스트)의 데이터를 표시합니다.
"최대 대역폭" 열은 16TCP 흐름 부하 테스트의 데이터를 1Mb 창 크기로 표시합니다.
대기 시간/대역폭 결과
Important
이러한 숫자는 일반 참조용일 뿐입니다. 많은 요인이 대기 시간에 영향을 주며 이러한 값은 일반적으로 시간에 따라 일관되지만 Azure 또는 서비스 공급자 네트워크 내의 조건이 변경되어 대기 시간 및 대역폭에 영향을 줄 수 있습니다. 일반적으로 이러한 변경으로 인해 큰 차이가 발생하지는 않습니다.
| ExpressRoute 위치 | Azure 지역 | 예상 거리(km) | 대기 시간 | 1 세션 대역폭 | 최대 대역폭 |
|---|---|---|---|---|---|
| Seattle | 미국 서부 2 | 191km | 5ms | 262.0Mbits/sec | 3.74Gbits/sec |
| Seattle | 미국 서부 | 1,094km | 18ms | 82.3Mbits/sec | 3.70Gbits/sec |
| Seattle | 미국 중부 | 2,357km | 40밀리초 | 38.8Mbits/sec | 2.55Gbits/sec |
| Seattle | 미국 중남부 | 2,877km | 51ms | 30.6Mbits/sec | 2.49Gbits/sec |
| Seattle | 미국 중북부 | 2,792km | 55밀리초 | 27.7Mbits/sec | 2.19Gbits/sec |
| Seattle | 미국 동부 2 | 3,769km | 73ms | 21.3Mbits/sec | 1.79Gbits/sec |
| Seattle | 미국 동부 | 3,699km | 74ms | 21.1Mbits/sec | 1.78Gbits/sec |
| Seattle | 일본 동부 | 7,705km | 106ms | 14.6Mbits/sec | 1.22Gbits/sec |
| Seattle | 영국 남부 | 7,708km | 146ms | 10.6Mbits/sec | 896Mbits/sec |
| Seattle | 서유럽 | 7,834km | 153ms | 10.2Mbits/sec | 761Mbits/sec |
| Seattle | 오스트레일리아 동부 | 12,484km | 165ms | 9.4Mbits/sec | 794Mbits/sec |
| Seattle | 동남 아시아 | 12,989km | 170ms | 9.2Mbits/sec | 756Mbits/sec |
| Seattle | 브라질 남부 * | 10,930km | 189ms | 8.2Mbits/sec | 699Mbits/sec |
| Seattle | 인도 남부 | 12,918km | 202ms | 7.7Mbits/sec | 634Mbits/sec |
* 브라질에 대한 대기 시간은 파이버 런 거리가 직선 거리와 크게 다른 예입니다. 예상 대기 시간은 약 160ms이지만 파이버 경로가 길기 때문에 실제로는 189ms입니다.
참고 항목
이러한 숫자는 PowerShell을 통해 Windows의 iPerf를 기반으로 AzureCT를 사용하여 테스트되었습니다. iPerf는 배율 인수에 대한 기본 Windows TCP 옵션을 적용하지 않으며 TCP 창 크기에 더 낮은 Shift Count를 사용합니다. iPerf 명령을 스위치와 더 큰 TCP 창 크기로 -w 튜닝하면 더 나은 처리량을 달성할 수 있습니다. 여러 컴퓨터에서 다중 스레드 모드로 iPerf를 실행하면 최대 링크 성능에 도달하는 데 도움이 될 수 있습니다. Windows에서 최상의 iPerf 결과를 얻으려면 "Set-NetTCPSetting -AutoTuningLevelLocal Experimental"을 사용합니다. 변경하기 전에 조직 정책을 확인합니다.
다음 단계
- Azure 연결 도구 키트 다운로드
- 링크 성능 테스트에 대한 지침 수행