VPC의 EC2 Linux 또는 Windows 인스턴스와 인터넷 게이트웨이를 통한 온프레미스 호스트 간의 네트워크 성능 문제를 해결하려면 어떻게 해야 하나요?

간략한 설명

패킷 손실 또는 대기 시간과 같은 네트워크 문제를 진단하려면 먼저 네트워크를 테스트하여 문제의 원인을 격리해야 합니다. 다음 해결 방법에 따라 문제의 원인이 네트워크와 애플리케이션 중 어디에 있는지를 확인할 수 있습니다. 성능 문제를 관찰할 때 결과를 비교할 수 있도록 성능 결과를 벤치마킹하는 것이 좋습니다.

문제 해결을 시작하기 전에 다음을 확인하세요.

• 양쪽 엔드포인트(EC2 인스턴스와 온프레미스 호스트) 모두에 네트워크 유틸리티가 설치되어 있는지 확인합니다.
• 향상된 네트워킹을 지원하는 EC2 인스턴스를 사용하고, 최신 드라이버가 설치되어 있는지 확인합니다. 향상된 네트워킹은 낮은 CPU 사용률로 향상된 I/O를 제공하므로 성능 테스트를 실행할 때 인스턴스 수준의 문제를 방지하는 데 도움이 됩니다. 향상된 네트워킹이 켜져 있지 않으면 Linux에서 향상된 네트워킹 사용 또는 Windows에서 향상된 네트워킹 사용을 참조하세요.
• EC2 인스턴스에 연결하여 인스턴스에 액세스하고, EC2 인스턴스와 온프레미스 호스트 간에 엔드 투 엔드 연결이 있는지 확인합니다.

해결 방법

네트워크를 간편하게 테스트하고 문제를 해결할 수 있도록 다음 도구를 설치합니다.

• AWSSupport-SetupIPMonitoringFromVPC는 패킷 손실, 지연 시간, MTR, tcptraceroute, tracepath 등의 네트워크 지표를 수집합니다.
• MTR을 사용하여 ICMP 또는 TCP 패킷 손실과 지연 문제를 확인합니다.
• traceroute를 사용하여 지연 시간 또는 라우팅 문제를 파악합니다.
• Hping3를 사용하여 엔드 투 엔드 TCP 패킷 손실 및 지연 문제를 확인합니다.
• Tcpdump를 사용하여 패킷 캡처 샘플을 분석합니다.

상향식으로 traceroute 또는 MTR 보고서의 홉을 검토합니다. 예를 들어 마지막 홉 또는 대상의 손실을 확인한 후 다음 홉을 검토합니다. 패킷 손실 또는 지연 시간 문제가 마지막 홉까지 계속될 경우 네트워크 또는 라우팅 문제가 발생한 것일 수 있습니다. 해당 노드의 컨트롤 플레인 속도 제한에 문제가 있는 경우 경로의 홉 하나에서 패킷 손실 또는 지연 시간 문제가 발생할 수 있습니다. 보고된 마지막 홉이 명령에 명시된 대상인지 확인합니다. 그렇지 않은 경우 제한적인 보안 그룹 때문에 문제가 발생했을 수 있습니다.

AWSSupport-SetupIPMonitoringFromVPC를 사용한 성능 테스트

이 내장 도구는 네트워크 문제를 해결하는 데 필요한 다양한 지표를 수집합니다. 자세한 내용은 Amazon VPC에서의 네트워크 연결에 대한 디버깅 도구를 참조하세요.

Linux 인스턴스의 성능 문제 해결

Linux 성능 통계 확인

소스 인스턴스 또는 대상 인스턴스에 액세스할 수 있는 경우 CPU, 메모리 사용률 및 로드 평균과 관련된 문제를 확인합니다.

MTR을 사용한 성능 테스트

Linux MTR 명령은 지속적으로 업데이트되는 출력을 제공합니다. 이 출력을 통해 네트워크 성능을 분석할 수 있습니다. 이 진단 도구는 traceroute 유틸리티와 ping 유틸리티의 기능을 통합한 것입니다. 대부분의 Linux 배포판에는 traceroute 및 MTR이 사전 설치되어 있습니다. 배포판의 소프트웨어 패키지 관리자에서 다운로드할 수도 있습니다.

다음 명령을 실행하여 MTR을 설치합니다.

Amazon Linux:

sudo yum install mtr

Ubuntu:

sudo apt-get install mtr-tiny

MTR을 사용하여 네트워크의 성능을 테스트하려면 EC2 인스턴스와 온프레미스 호스트의 퍼블릭 IP 주소 간에 양방향으로 이 테스트를 실행합니다. 방향이 반전되면 TCP/IP 네트워크의 노드 간 경로가 바뀔 수 있습니다. 따라서 양방향의 MTR 결과를 얻는 것이 중요합니다. 대부분의 인터넷 장치는 ICMP 기반의 추적 요청을 낮은 우선 순위로 취급하기 때문에, ICMP 대신 TCP 기반의 추적을 사용할 수 있습니다.

패킷 손실을 검토합니다. 일반적으로 단일 홉의 패킷 손실은 문제가 되지 않습니다. 이 손실은 "ICMP time exceeded" 메시지가 삭제되도록 하는 컨트롤 플레인 정책 때문일 수 있습니다. 대상 홉에 이를 때까지 패킷 손실이 계속되거나 여러 홉에 걸쳐 패킷 손실이 나타날 경우에는 손실이 문제가 될 수 있습니다.

참고: 몇 개의 요청이 시간 초과되는 것은 흔한 현상입니다.

ICMP 기반 MTR:

mtr -n -c 200 <Public IP EC2 instance/on-premises host> --report

TCP 기반 MTR:

mtr -n -T -c 200 <Public IP EC2 instance/on-premises host> --report

-T 인수는 TCP 기반 MTR을 수행하고 --report 옵션은 MTR을 보고서 모드로 전환합니다. MTR은 -c 옵션을 사용하여 지정한 횟수의 주기 동안 실행됩니다. 통계 데이터를 인쇄하고 종료합니다.

참고: TCP 기반 MTR은 대상 TCP 포트 80을 테스트합니다. 특정 대상 TCP 포트를 MTR로 테스트하려면 -P를 추가한 다음 포트 번호를 입력합니다. 다음은 MTR 대상 TCP 포트 443에 대한 예입니다.

mtr -n -T -c 200 <Public IP EC2 instance/on-premises host> -P 443 --report

traceroute를 사용한 성능 테스트

Linux traceroute 유틸리티는 클라이언트 노드에서 대상 노드로 연결된 경로를 식별합니다. 이 유틸리티는 각 라우터가 요청에 응답하는 시간을 밀리초 단위로 기록합니다. 또한 이 유틸리티는 각 홉이 대상 주소에 도달하기까지 걸리는 총시간을 계산합니다.

traceroute를 설치하려면 다음 명령을 실행합니다.

Amazon Linux:

sudo yum install traceroute

Ubuntu:

sudo apt-get update

sudo apt-get install traceroute

참고: MTR 보고서를 실행하는 경우에는 traceroute가 필요하지 않습니다. MTR은 대상에 대한 지연 시간 및 패킷 손실 통계를 제공합니다.

포트 22 또는 테스트할 포트가 양방향으로 열려 있는지 확인합니다. traceroute를 사용하여 네트워크 연결 문제를 해결하려면 클라이언트에서 서버로, 서버에서 클라이언트로 명령을 실행합니다. 방향이 반전되면 TCP/IP 네트워크의 노드 간 경로가 바뀔 수 있습니다. 대부분의 인터넷 장치는 ICMP 기반의 추적 요청을 낮은 우선 순위로 취급하기 때문에, (애플리케이션 포트에서) ICMP 대신 TCP 기반의 추적을 사용합니다.

ICMP 기반 traceroute:

sudo traceroute -I <Public IP of EC2 instance/on-premises host>

TCP 기반 traceroute:

sudo traceroute -n -T -p 22 <Public IP of EC2 instance/on-premises host>

-T -p 22 -n 인수는 포트 22에서 TCP 기반 추적을 수행합니다.

참고: 애플리케이션별 포트를 테스트에 사용할 수 있습니다. 특정 포트를 사용하여 애플리케이션 트래픽을 감소시키는 중간 디바이스가 경로에 있는지 파악합니다.

hping3를 사용한 성능 테스트

Hping3는 TCP 연결의 엔드 투 엔드 패킷 손실과 대기 시간을 측정하는 명령줄 지향 TCP/IP 패킷 어셈블러/분석기입니다. hping3는 ICMP 에코 요청 외에도 TCP, UDP 및 RAW-IP 프로토콜을 지원합니다. Hping3에는 커버링된 채널 간에 파일을 보낼 수 있는 traceroute 모드도 포함되어 있습니다. Hping3는 호스트를 스캔하고 침입 테스트를 지원하고 침입 탐지 시스템을 테스트하며 호스트 간에 파일을 전송하도록 설계되었습니다.

MTR과 traceroute는 홉당 지연 시간을 캡처합니다. 하지만 hping3는 패킷 손실 외에 TCP를 통한 최소/평균/최대 엔드 투 엔드 지연 시간까지 보여 줍니다. 다음 명령을 실행하여 hping3를 설치합니다.

Amazon Linux 2 RHEL 7용 EPEL 릴리스 패키지를 설치하고 EPEL 리포지토리를 활성화합니다.

sudo amazon-linux-extras install epel -y

Amazon Linux 2:

sudo yum --enablerepo=epel install hping3

Ubuntu:

sudo apt-get install hping3

다음 명령은 포트 0를 통해 50개의 TCP SYN 패킷을 전송합니다. hping3는 기본적으로 어떠한 TCP 플래그도 지정하지 않고 창 크기 64의 TCP 헤더를 대상 호스트의 포트 0으로 보냅니다.

sudo hping3 -S -c 50 -V <Public IP of EC2 instance/on-premises host>

다음 명령은 포트 22를 통해 50개의 TCP SYN 패킷을 전송합니다.

sudo hping3 -S -c 50 -V <Public IP of EC2 instance/on-premises host> -p 22

참고: 포트 22 또는 테스트하는 포트가 열려 있는지 확인하세요.

tcpdump를 사용한 패킷 캡처 샘플 테스트

패킷 손실/대기 시간 문제를 진단할 때에는 EC2 인스턴스와 온프레미스 호스트의 패킷을 동시에 캡처하는 것이 좋습니다. 이렇게 하면 요청 및 응답 패킷을 식별하여 네트워킹 및 애플리케이션 계층에서 문제를 격리하는 데 도움이 됩니다. 우선 패킷 캡처를 시작한 다음 트래픽을 시작하는 것이 좋습니다. 이렇게 하면 흐름에 대한 모든 패킷을 캡처하는 데 도움이 됩니다. 다음 명령을 실행하여 tcpdump를 설치합니다.

Amazon Linux:

sudo yum install tcpdump

Ubuntu:

sudo apt-get install tcpdump

tcpdump를 설치한 후 다음 명령을 실행하여 tcp 포트 22 트래픽을 캡처하고 pcap 파일에 저장할 수 있습니다.

sudo tcpdump -i eth0 port 22 -s0 -w samplecapture.pcap

참고: tcpdump 플래그 -i는 tcpdump가 트래픽을 캡처하는 인스턴스의 인터페이스를 지정합니다. 인터페이스를 eth0에서 사용자의 환경에 구성된 인터페이스로 변경해야 할 수 있습니다.

Windows에서의 성능 문제 해결

ECN 기능 확인

1.    다음 명령을 실행하여 ECN(명시적 혼잡 알림) 기능이 켜져 있는지 확인합니다.

netsh interface tcp show global

2.    ECN 기능이 활성화된 경우 다음 명령을 실행하여 비활성화합니다.

- netsh interface tcp set global ecncapability=disabled

3.    성능 개선이 보이지 않으면 다음 명령을 사용하여 ECN 기능을 다시 활성화할 수 있습니다.

netsh interface tcp set global ecncapability=enabled

홉 검토 및 TCP 포트 연결 문제 해결

먼저 MTR 또는 tracert를 사용하여 홉을 검토합니다.

MTR 메서드:

1.    WinMTR을 다운로드하여 설치합니다.

2.    [Host] 섹션에 대상 IP를 입력한 다음 [Start]를 선택합니다.

3.    테스트를 1분 동안 실행한 후 [Stop]을 선택합니다.

4.    **클립보드로 텍스트 복사(Copy text to clipboard)**를 선택하고 출력을 텍스트 파일에 붙여 넣습니다.

5.    대상으로 전파되는 % 열에서 손실을 찾습니다.

참고:  호스트에서 응답 없음(No response from host) 메시지가 있는 홉을 무시합니다. 이 메시지는 이러한 특정 홉이 ICMP 프로브에 응답하지 않음을 나타냅니다.

6.    상향식 접근 방식을 사용하여 MTR 보고서의 홉을 검토합니다. 예를 들어 마지막 홉 또는 대상에서 손실이 있는지 확인하고 그 앞의 홉을 검토합니다.

Tracert 메서드:

MTR을 설치하지 않으려는 경우 tracert 명령 유틸리티 도구를 사용할 수 있습니다.

1.    대상 URL 또는 IP 주소에 대한 tracert를 수행합니다.

2.    왕복 시간(RTT)의 갑작스러운 스파이크를 보여주는 홉을 찾습니다. RTT의 갑작스러운 증가는 부하가 높은 노드가 있다는 의미일 수 있으며, 이로 인해 트래픽에 지연 시간 또는 패킷 손실이 유발될 수 있습니다.

참고: -d 옵션은 IP 주소를 호스트 이름으로 확인하지 않습니다. IP를 호스트 이름으로 확인해야 하는 경우 -d를 제거하세요.

tracert -d <Public IP of EC2 instance/on-premises host>

그런 다음 TCP 포트 연결을 확인합니다.

참고: WinMTR과 tracert 모두 ICMP 기반이므로 tracetcp를 사용하여 TCP 포트 연결 문제를 해결할 수 있습니다.

1.    WinPcap 및 tracetcp를 다운로드합니다.

2.    Tracetcp ZIP 파일의 압축을 풉니다.

3.    tracetcp.exe를 C 드라이브에 복사합니다.

4.    WinPcap을 설치합니다.

5.    명령 프롬프트를 열고 *C:\Users\username>cd* 명령을 사용하여 C 드라이브에 WinPcap을 루트로 지정합니다.

6.    tracetcp.exehostname: port 또는 tracetcp.exe ip: port 명령을 사용하여 tracetcp를 실행합니다.

Windows 작업 관리자 확인

원본 인스턴스 또는 대상 인스턴스에 액세스할 수 있는 경우 Windows 작업 관리자를 확인합니다. CPU 및 메모리 사용률 또는 평균 로드 문제를 찾습니다.

패킷 캡처

참고: 패킷 손실 또는 지연 시간 문제를 진단할 때는 EC2 인스턴스와 온프레미스 호스트의 패킷을 동시에 캡처하는 것이 좋습니다. 이렇게 하면 요청 및 응답 패킷을 식별하여 네트워킹 및 애플리케이션 계층에서 문제를 격리하는 데 도움이 됩니다. 또한 먼저 패킷 캡처를 시작한 다음 트래픽을 시작하는 것이 좋습니다. 이렇게 하면 흐름에 대한 모든 패킷을 캡처하는 데 도움이 됩니다.

1.    Wireshark를 설치하고 패킷 캡처를 수행합니다.

2.    (ip.addr eq source_IP) &&(tcp.flags.syn == 1) 필터를 사용하여 패킷 캡처에서 특정 소스 간의 트래픽을 격리합니다. 출력에는 해당 소스 IP에서 시작된 모든 tcp 스트림이 표시됩니다.

3.    관련 소스 IP 및 대상 IP가 있는 행을 선택합니다.

4.    컨텍스트(마우스 오른쪽 버튼 클릭) 메뉴를 선택한 다음 Follow, TCP Stream을 선택합니다. 그러면 소스 IP와 대상 IP 간에 TCP 흐름이 발생하여 조사를 수행할 수 있습니다.

5.    재전송, 중복 패킷 또는 TCP 창 크기 알림(예: TCP 창 가득 참 또는 창 크기 0)을 찾습니다. 이러한 알림은 TCP 버퍼에 공간이 부족함을 나타내는 것일 수 있습니다.

패킷 손실이 발견되거나 홉 수가 벤치마크와 크게 달라지는 경우 네트워킹 장비 공급업체의 설명서를 참조하세요. 멀티홈 네트워크 환경에서 작업하는 경우 다른 ISP를 사용하여 해당 테스트를 수행하세요.

---

관련 정보

Linux에서 향상된 네트워킹

Windows에서 향상된 네트워킹