GCP 정적 IP와 VPN 속도: 세 가지 변수, 하나의 테스트

주소를 예약한 뒤 전송이 빨라졌고, 결론은 저절로 써졌다. 다만 같은 변경이 터널을 UDP에서 TCP로 바꾸었고, 테스트를 다른 저녁으로 옮겼으며, 어쩌면 다른 영역의 VM에 착륙시켰다. 외부 주소를 예약하는 것은 재시작을 거쳐도 엔드포인트를 같게 유지함으로써 수명 주기 문제를 고친다. 패킷을 가속할 메커니즘은 없으므로 그 실험의 속도 차이는 다른 변수의 몫이고, 앞에 놓인 결정은 다음에 무엇을 시험할지다.

예약된 주소가 실제로 사 주는 것

Compute Engine은 인스턴스와 함께 할당되고 해제되는 임시 주소와, 직접 예약해 유지하는 정적 주소를 구분한다. 그 차이는 보존과 과금에 관한 것이지 패킷이 지나는 경로에 관한 것이 아니다. 안정적인 엔드포인트는 DNS 레코드, 원격 접속 프로필, 파트너 허용 목록, VM 재시작 시 바뀌지 않아야 하는 방화벽 규칙에 정말 유용하다.

그것들은 하나를 예약할 좋은 이유다. 어느 것도 처리량의 이유는 아니다.

등급, 주소, 전송을 세 변수로 유지하라

Google Cloud는 Premium과 Standard 네트워크 서비스 등급도 판매하며, 둘은 기능 가용성이 다른 서로 다른 경로로 인터넷에 나간다. 정적 주소 지정은 둘 모두에 직교하므로 정적과 Premium을 VM에 관한 무관한 사실로 다루고 동의어로 보지 말라. 실제 등급과 리전, 관련된 상호 연결이나 첨부를 기록하면 주소 라벨이 결코 하지 못하는 방식으로 경로를 설명할 수 있다.

세 변수, 세 개의 별도 실험, 그렇지 않으면 결과는 측정이 아니라 이야기다.

한 가지 질문에 답하는 테스트를 설계하라

승인된 UDP와 TCP 프로필을 비교하는 동안 VM, 주소, 클라이언트 위치, 목적지, 워크로드를 고정하라. 전송별 서버 리스너와 그에 맞는 방화벽 규칙이 모두 필요하다. 클라이언트 키워드를 고치고 리스너를 그대로 두면 당신의 인내심만 시험된다.

VM의 CPU도 지켜보라, 작은 인스턴스는 암호화나 softirq 작업에서 네트워크보다 훨씬 먼저 포화되며 그 한계는 제공자 제한과 똑같이 보일 것이다.

VM과 클라이언트의 재전송 및 손실 카운터는 경로 문제와 전송 문제를 구분하지만 진행 표시줄은 그러지 못한다. iperf3를 쓴 실행 가능한 순서는 전송당 약 십 분이 걸린다. 서버를 먼 쪽에서 시작하고, 각 방향으로 클라이언트를 삼십 초씩 돌리고, 각 방향을 세 번 반복하라. 각 계열의 첫 실행은 버리고, 그다음 TCP 실행이 출력하는 재전송 수와 함께 송신자와 수신자 속도를 비교하라.

UDP와 TCP가 기계적으로 다른 이유

UDP 위의 OpenVPN는 데이터그램을 운반하고 손실 처리를 애플리케이션 자체의 전송에 맡긴다. TCP 위에서는 터널의 신뢰할 수 있는 스트림이 이미 신뢰할 수 있는 애플리케이션 스트림 아래에 앉으므로, 잃어버린 세그먼트 하나가 그 뒤의 모든 것을 멈추고 바깥 연결은 자기 일정대로 재전송한다. 이 선두 정체 동작은 TCP를 TCP 안에 터널링하는 성질이지 제공자 정책이 아니다. MTU와 MSS 처리도 두 모드에서 달라 같은 경로의 단편화 동작을 바꾼다.

따라서 더 빠른 TCP 시험은 그날 그 경로에서 TCP가 더 빨랐음을 증명할 뿐, 더 일반적인 것은 아무것도 아니다.

검토를 견디도록 결과를 쓰라

방어 가능한 결론에는 형태가 있다. 이 프로필이, 이 머신 크기에서, 이 네트워크 등급에서, 이 측정된 워크로드를 이 방향으로 이 조건에서 유지했다는 형태다. 그보다 넓은 것은 하룻밤이 제공할 수 있는 것보다 많은 실행을 요구하므로, 느린 사례가 설명되지 않은 채 남는다면 어떤 제공자 문서도 기술하지 않는 제한을 지어내는 대신 패킷과 자원 증거를 붙여 관찰로 남겨라.

주소 안정성과 전송 속도는 같은 배포에 둘 다 중요할 수 있고, 유용한 결정은 각 변경에서 둘 중 무엇을 사는가다.