Site-to-Site VPN을 사용할 때 애플리케이션에 지연 시간 및 성능 문제가 발생하는 이유는 무엇입니까?

해결 방법

Site-to-Site VPN을 사용하여 리소스에 액세스할 때 성능 또는 지연 시간 문제가 발생하는 경우 다음 문제 해결 단계를 따르세요.

• 소스 및 대상 시스템을 한 번에 하나씩 격리합니다.
• 네트워크 경로에서 지연 시간을 유발할 수 있는 문제가 있는지 확인하세요.
• 애플리케이션에서 지연 시간 문제를 일으키는 일반적인 오류가 있는지 확인하세요.

소스 및 대상 시스템 격리

온프레미스 애플리케이션과 AWS 간의 성능 문제를 완화하려면 먼저 소스 및 대상 시스템을 격리해야 합니다. 그런 다음, 네트워크 도구를 사용하여 성능에 직접적인 영향을 미칠 수 있는 애플리케이션 외부의 손실 및 지연 시간을 확인합니다.

1.    소스 및 대상을 변경합니다. 다른 소스를 사용한 다음 다른 대상을 사용하여 변경할 때마다 문제가 지속되는지 확인합니다. 그런 다음, 디바이스를 검사하여 운영 체제(OS) 구성 문제나 다른 문제가 있는지 확인합니다.

2.    UDP 대역폭 기능 테스트를 수행합니다. 성능 문제는 처리량 문제가 있다는 것일 수 있으므로 iperf3 도구를 사용하여 프로비저닝된 대역폭을 확인하세요. 이 테스트를 양방향으로 수행하세요. 다음 UDP 테스트 예시는 iperf3 도구를 사용합니다.

참고: -i는 간격, -u는 UDP, -b는 대역폭(그에 맞춰 조정), -p는 UDP 포트, -v는 세부 정보를 나타냅니다.

Server: sudo iperf -s -u [-p 5001]
client: sudo iperf3 -i 1 -u -p 33344 -b 1.2G -c <private IP> -V

참고: 사용 중인 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 대역폭 크레딧을 사용할 수 있는지 확인하세요. 또는, 더 큰 인스턴스 크기를 사용한 다음 다시 테스트해 보세요.

3.    iperf3를 사용하여 Site-to-Site VPN에서 TCP 처리량 테스트를 수행하세요. 이 테스트를 양방향으로 수행하세요. 다음 예시를 참조하세요.

참고: 최적의 성능을 내려면 인스턴스 크기를 늘릴 때 다양한 TCP 수신 윈도우 크기를 사용하여 소스 및 대상 메모리 버퍼를 테스트해 보세요.

Server : iperf3 -s [-p 5001]
Client:
sudo iperf3 -c <Private IP> -P 10 -w 128K -V
sudo iperf3 -c <Private IP> -P 10 -w 512K -V
sudo iperf3 -c <Private IP> -P 10 -w 1024K -V  

네트워크 경로에 문제가 있는지 확인

네트워크 패치를 확인하여 네트워크에 문제를 일으키는 특정 홉 또는 디바이스를 식별하세요.

• Site-to-Site VPN 피어 간 경로를 따라 패킷 손실을 확인합니다.
• Site-to-Site VPN 터널 처리량을 확인합니다.
• 고객 게이트웨이 라우터 구성을 확인합니다.
• 경로에 있는 가장 낮은 MTU를 확인합니다.

Site-to-Site VPN 피어 간 경로를 따라 패킷 손실이 있는지 확인

Site-to-Site VPN 터널은 피어 간의 암호화된 통신입니다. 그러나 기본 네트워크에 암호화된 통신의 품질에 영향을 미치는 손실이 발생할 수 있습니다. 패킷 손실은 지연 시간을 늘리며 처리량에 직접적인 영향을 미칩니다.

다음 식 및 예시를 참조하세요.

Mathis Equation: Throughput = (MSS/RTT)*(1 / sqrt{p}):

Eg. 1375 MSS, 33ms latency, 0.001%= (1375B / 0.033 sec) * (1/𝑠𝑞𝑟𝑡{0.001})=  (41,666.6 * 31.6227)*8 <<< To go from Bps to bps= 10,540,925.5 bps (10.5 Mbps)

처리량 측정값은 **[TCP 창 크기(비트 단위)]/[지연 시간(RTT) (초)]**입니다. 다음 예시를 참조하세요.

Eg.  64K in receive Window, 33ms latency= 524288 bits / 0.033 = 15,887,515 = 15.8 Mbps MAX Possible Throughput

Site-to-Site VPN 피어 간의 공용 경로에서 패킷 손실을 확인하려면 MTR과 같은 ICMP 테스트를 사용하세요. MTR 설치 및 사용에 관한 자세한 내용은 VPC의 EC2 Linux 또는 Windows 인스턴스와 인터넷 게이트웨이를 통한 온프레미스 호스트 간의 네트워크 성능 문제를 해결하려면 어떻게 해야 하나요?를 참조하세요

다음 예시를 참조하세요.

참고: 이 예시의 MTR 출력에는 데이터가 없거나 100% 손실된 값이 포함됩니다. 이는 디바이스가 TTL이 0인 패킷을 삭제했으나 ICMP 시간 초과(유형 11, 코드 0) 메시지로 응답하지 않았음을 나타냅니다. 그러므로 이러한 값이 문제가 있다는 의미는 아닙니다.

 [ec2-user@ip-10-7-10-67 ~]$ sudo mtr --no-dns --report --report-cycles 20 18.189.121.166Start: 2023-04-07T16:28:28+0000HOST: ip-10-7-10-67.ec2.internalr Loss%   Snt   Last   Avg  Best  Wrst StDev  1.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  2.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  3.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0  4.|-- 241.0.12.14                0.0%    20    0.4   0.4   0.3   0.8   0.1  5.|-- 240.0.204.2                0.0%    20    0.4   0.4   0.3   0.5   0.0  6.|-- 240.0.204.17               0.0%    20    0.4   0.4   0.3   0.5   0.0  7.|-- 240.0.204.5                0.0%    20    0.4   0.4   0.4   0.5   0.0  8.|-- 242.2.74.145               0.0%    20    1.2   4.0   0.4  23.9   5.7  9.|-- 52.93.29.71                0.0%    20    0.8   2.3   0.7   9.2   2.8 10.|-- 100.100.8.66               0.0%    20   10.8   2.5   0.7  12.8   4.0 11.|-- 100.92.53.85               0.0%    20   26.0  13.3  11.0  26.0   4.4 12.|-- 52.93.239.5                0.0%    20   11.6  12.8  11.4  23.7   2.7 13.|-- 52.95.1.159                0.0%    20   11.0  12.0  11.0  18.3   1.7 14.|-- 52.95.1.186                0.0%    20   11.5  14.1  11.2  32.6   5.9 15.|-- 15.230.39.135              0.0%    20   11.6  11.9  11.1  15.5   1.1 16.|-- 15.230.39.124              0.0%    20   11.7  12.8  11.2  27.2   3.6 17.|-- 108.166.252.38             0.0%    20   11.2  11.2  11.1  11.3   0.0 18.|-- 242.0.102.17               0.0%    20   12.1  12.4  11.2  23.9   2.8 19.|-- 108.166.252.35             0.0%    20   11.3  11.3  11.2  12.3   0.2 20.|-- 241.0.12.207               0.0%    20   11.2  11.3  11.1  13.2   0.5 21.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 22.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 23.|-- ???                       100.0    20    0.0   0.0   0.0   0.0   0.0 24.|-- 100.65.30.129              0.0%    20   57.2  24.9  11.6  76.4  17.9 25.|-- 18.189.121.166             0.0%    20   11.3  11.8  11.2  17.6   1.6[ec2-user@ip-10-7-10-67 ~]$

Site-to-Site VPN 터널 처리량 확인

처리량이 1.2Gbps 한도를 초과하는지 확인하세요.

1.    Amazon CloudWatch 콘솔을 열어 Site-to-Site VPN 지표를 확인하세요.

2.    TunnelDataIn 및 TunnelDataOut에 대한 지표를 선택합니다.

3.    통계에서 합계를 선택한 다음 기간에서 5분을 선택합니다.

4.    최고점에 있는 데이터 포인트에 다음 계산을 적용합니다. 이 식에서 m1 = TunnelDataIn, m2 = TunnelDataOut입니다.

참고: 처리량이 지속적으로 1.2Gbps 이상인 경우 ECMP와 전환 게이트웨이가 있는 두 개의 BGP 터널을 구현하세요.

(((m1+m2)/300)*8)/1000000

고객 게이트웨이 라우터 구성 확인

고객 게이트웨이 디바이스에서 다음 구성을 확인하세요.

• 처리량을 제한하는 정책이나 조정 정책이 없어야 합니다.
• IP 패킷에서 Don't Fragment (DF) 플래그를 재설정합니다.
• IPsec 패킷을 암호화하기 전에 조각으로 나눠야 합니다.
• IP, TCP, UDP 또는 ESP 헤더 및 데이터 페이로드가 1,500을 초과하지 않도록 고객 게이트웨이에 MSS 구성이 있는지 확인합니다. 사용 중인 암호화 알고리즘에 대한 MTU 지침을 따르세요. 자세한 내용은 고객 게이트웨이 디바이스에 대한 모범 사례를 참조하세요.

경로의 가장 낮은 MTU 확인

경로를 테스트하여 경로의 최저 MTU가 예상과 일치하는지 확인하세요.

이 작업을 수행하려면 -s 1460을 핑합니다 <DESTINATION> -M은 다음을 수행합니다:

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1460 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1460(1488) bytes of data.1468 bytes from 1.1.1.1: icmp_seq=1 ttl=51 time=1.06 ms1468 bytes from 1.1.1.1: icmp_seq=2 ttl=51 time=1.04 ms1468 bytes from 1.1.1.1: icmp_seq=3 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=4 ttl=51 time=1.07 ms1468 bytes from 1.1.1.1: icmp_seq=5 ttl=51 time=1.10 ms1468 bytes from 1.1.1.1: icmp_seq=6 ttl=51 time=1.06 ms

경로에 있는 디바이스가 페이로드를 전송할 수 없는 경우 디바이스는 ICMP 경로 MTU 초과 메시지를 반환합니다.

[ec2-user@ip-10-7-10-67 ~]$ ping -s 1480 1.1.1.1 -M doPING 1.1.1.1 (1.1.1.1) 1480(1508) bytes of data.From 10.7.10.1 icmp_seq=1 Frag needed and DF set (mtu = 1500)ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500ping: local error: Message too long, mtu=1500

애플리케이션에 일반적인 오류가 있는지 확인

온프레미스 애플리케이션에서 가장 일반적인 문제를 확인하세요.

• 애플리케이션 구성 문제.
• 데이터 전송에 병렬 스레드 사용. 예상한 Site-to-Site VPN 처리량보다 느려 보이는 것이 확인되면 애플리케이션과 별도로 병렬 스레드를 사용하여 처리량을 확인합니다.
• 지수 백오프를 통한 재시도 알고리즘을 구현합니다. AWS 서비스를 호출할 때 제한 시간이 초과되면 지수 백오프를 통한 재시도 알고리즘을 사용하세요.

관련 정보

Linux의 향상된 네트워킹

AWS VPN FAQ