부하 분산으로 애플리케이션 지연 최적화

이 문서는 부하 분산 옵션에 대해 설명하고 Google Cloud에서 특정 부하 분산기 선택이 엔드 투 엔드 지연 시간에 미치는 영향을 보여줍니다.

부하 분산 옵션

애플리케이션에 전송되는 트래픽 유형에 따라 여러 가지 부하 분산 옵션이 있습니다. 다음은 옵션을 요약한 표입니다.

옵션 설명 트래픽 흐름 범위
HTTP(S) 부하 분산 HTTP(S) 트래픽과 URL 매핑 및 SSL 오프로드
(특정 포트의 HTTP 외 트래픽에 대한 TCP 프록시 부하 분산 또는 SSL 프록시 부하 분산) 등의 고급 기능을 지원합니다.
TCP 또는 SSL(TLS) 세션은 Google 네트워크 에지의 Google 프런트엔드(GFE)에서 종료되고 트래픽이 백엔드로 프록시 처리됩니다. 전역
네트워크 부하 분산 포트를 사용하는 TCP/UDP 트래픽이 부하 분산기를 통과하도록 허용합니다. Google의 Maglev 기술을 사용해 트래픽을 백엔드에 배포합니다. 리전

내부 부하 분산기와 Traffic Director는 사용자 대상 트래픽을 지원하지 않으므로 이 문서에서는 다루지 않습니다.

전역 부하 분산에 이 서비스 등급이 필요하므로 이 문서의 측정에서는 네트워크 서비스 등급의 프리미엄 등급을 사용합니다.

지연 시간 측정

독일의 한 사용자가 us-central1에서 호스팅되는 웹사이트에 액세스할 때 다음과 같은 방법으로 지연 시간을 테스트합니다.

  • : ICMP 핑은 일반적인 서버 연결 가능성을 측정하는 일반적인 방법이지만 ICMP 핑은 최종 사용자 지연 시간을 측정하지 않습니다. 자세한 내용은 HTTP(S) 부하 분산의 추가 지연 시간 효과를 참조하세요.
  • Curl: Curl은 첫 바이트 소요 시간(TTFB)을 측정합니다. curl 명령어를 서버에 반복해서 실행하세요.

결과를 비교해 보면 광섬유 링크의 지연 시간은 주로 광섬유의 거리와 광신호 속도의 제한을 받으며 약 200,000km/초(또는 124,724마일/초)라는 사실을 알 수 있습니다.

독일의 프랑크푸르트와 아이오와의 카운슬 블러프스(us-central1 리전) 사이의 거리는 약 7,500km입니다. 두 위치 간에 직선 광섬유를 사용할 경우 왕복 지연 시간은 다음과 같습니다.

7,500 km * 2 / 200,000 km/s * 1000 ms/s = 75 milliseconds (ms)

광섬유 케이블은 사용자와 데이터 센터 간의 직선 경로를 따르지 않습니다. 이 경로를 따라 광섬유의 광신호가 능동 및 수동 장비를 통과합니다. 이상적인 지연 시간의 약 1.5배 또는 112.5ms에 해당하는 지연 시간이 관찰되었으며 이는 이상적인 구성에 가깝습니다.

지연 시간 비교

이 섹션에서는 다음 구성의 부하 분산을 비교합니다.

  • 부하 분산 없음
  • 네트워크 부하 분산
  • HTTP(S) 부하 분산 또는 TCP 프록시 부하 분산

이 시나리오의 애플리케이션은 HTTP 웹 서버의 리전 관리형 인스턴스 그룹으로 구성되어 있습니다. 이 애플리케이션에서는 지연 시간이 짧은 중앙 데이터베이스 호출을 사용하기 때문에 웹 서버를 한 위치에서 호스팅해야 합니다. 애플리케이션은 us-central1 리전에 배포되며 사용자는 전 세계에 분산됩니다. 이 시나리오에서는 독일 사용자에게 발생한 지연 시간을 전 세계 사용자가 경험할 수 있음을 보여줍니다.

지연 시간 시나리오 다이어그램(확대하려면 클릭)
지연 시간 시나리오 다이어그램(확대하려면 클릭)

부하 분산 없음

사용자가 HTTP 요청을 하면 부하 분산이 구성되지 않는 한 트래픽이 사용자의 네트워크에서 Compute Engine에 호스팅된 가상 머신(VM)으로 직접 이동합니다. 프리미엄 등급의 경우 트래픽은 사용자의 위치와 가까운 에지 지점(PoP)의 Google 네트워크로 들어갑니다. 표준 등급의 경우 사용자 트래픽이 대상 리전과 가까운 PoP의 Google 네트워크로 들어갑니다. 자세한 내용은 네트워크 서비스 등급 문서를 참조하세요.

부하 분산이 없는 아키텍처(확대하려면 클릭)
부하 분산이 없는 아키텍처(확대하려면 클릭)

다음 표에서는 독일 사용자가 부하 분산 없이 시스템의 지연 시간을 테스트한 결과를 보여줍니다.

메서드 결과 최소 지연 시간
VM IP 주소 핑(웹 서버에서 직접 응답)

  ping -c 5 compute-engine-vm
  

  PING compute-engine-vm (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=111 ms
  64 bytes from compute-engine-vm (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=110 ms
  [...]
  --- compute-engine-vm ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4004ms
  rtt min/avg/max/mdev = 110.818/110.944/111.265/0.451 ms
  
110ms
TTFB

  for ((i=0; i < 500; i++)); do curl -w  /
  "%{time_starttransfer}\n" -o /dev/null -s compute-engine-vm; done
  

  0.230
  0.230
  0.231
  0.231
  0.230
  [...]
  0.232
  0.231
  0.231
  
230ms

처음 500개의 요청을 보여주는 다음 그래프에서 알 수 있듯이 TTFB 지연 시간은 안정적입니다.

ms 그래프에서 VM에 대한 지연 시간(확대하려면 클릭)
ms 그래프에서 VM에 대한 지연 시간(확대하려면 클릭)

VM IP 주소를 핑하면 웹 서버에서 직접 응답합니다. 웹 서버로부터의 응답 시간은 네트워크 지연 시간(TTFB)에 비해 매우 짧습니다. 모든 HTTP 요청에 새 TCP 연결이 열려 있기 때문입니다. 다음 다이어그램과 같이 HTTP 응답이 전송되기 전에 초기 3방향 핸드셰이크가 필요합니다. 따라서 관찰된 지연 시간은 핑 지연 시간의 약 두 배입니다.

클라이언트-서버 HTTP 요청 다이어그램(확대하려면 클릭)
클라이언트-서버 HTTP 요청 다이어그램(확대하려면 클릭)

네트워크 부하 분산

네트워크 부하 분산기를 사용하면 사용자 요청이 여전히 가장 가까운 에지 PoP의 Google 네트워크로 들어갑니다(프리미엄 등급). 프로젝트의 VM이 위치한 리전에서 트래픽은 먼저 네트워크 부하 분산기를 통과합니다. 그리고 나서 대상 백엔드 VM에 그대로 전달됩니다. 네트워크 부하 분산기는 안정적인 해싱 알고리즘을 기반으로 트래픽을 분산합니다. 이 알고리즘은 소스 및 대상 포트, IP 주소, 프로토콜의 조합을 사용합니다. VM에서 부하 분산기 IP를 수신 대기하고 변경되지 않은 트래픽을 허용합니다.

네트워크 부하 분산이 있는 아키텍처(확대하려면 클릭)
네트워크 부하 분산이 있는 아키텍처(확대하려면 클릭)

다음 표에서는 독일 사용자가 네트워크 부하 분산 옵션의 지연 시간을 테스트한 결과를 보여줍니다.

메서드 결과 최소 지연 시간
네트워크 부하 분산기 핑

  ping -c 5 net-lb
  

  PING net-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=44 time=110 ms
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=44 time=110 ms
  [...]
  64 bytes from net-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=44 time=110 ms
  --- net-lb ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4007ms
  rtt min/avg/max/mdev = 110.658/110.705/110.756/0.299 ms
  
110ms
TTFB

 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s net-lb
 

 0.231
 0.232
 0.230
 0.230
 0.232
 [...]
 0.232
 0.231
 
230ms

부하 분산은 리전 내에서 발생하며 트래픽은 단순히 전달되므로 부하 분산기가 없는 것에 비해 지연 시간 영향이 미미합니다.

외부 부하 분산

HTTP(S) 부하 분산을 사용하면 GFE가 트래픽을 프록시 처리합니다. 이러한 GFE는 Google의 전역 네트워크 에지에 있습니다. GFE는 TCP 세션을 종료하고 트래픽을 처리할 수 있는 가장 가까운 리전의 백엔드에 연결합니다.

HTTP(S) 부하 분산 시나리오 다이어그램(확대하려면 클릭)
HTTP(S) 부하 분산 시나리오 다이어그램(확대하려면 클릭)

다음 표에서는 독일 사용자가 HTTP 부하 분산 옵션의 지연 시간을 테스트한 결과를 보여줍니다.

메서드 결과 최소 지연 시간
HTTP(S) 부하 분산 핑

 ping -c 5 http-lb
 

 PING http-lb (xxx.xxx.xxx.xxx) 56(84) bytes of data.
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=1 ttl=56 time=1.22 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=2 ttl=56 time=1.20 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=3 ttl=56 time=1.16 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=4 ttl=56 time=1.17 ms
 64 bytes from http-lb (xxx.xxx.xxx.xxx): icmp_seq=5 ttl=56 time=1.20 ms
 --- http-lb ping statistics ---
 5 packets transmitted, 5 received, 0% packet loss, time 4005ms
 rtt min/avg/max/mdev = 1.163/1.195/1.229/0.039 ms
 
1ms
TTFB

 for ((i=0; i < 500; i++)); do curl -w /
    "%{time_starttransfer}\n" -o /dev/null -s http-lb; done
 

 0.309
 0.230
 0.229
 0.233
 0.230
 [...]
 0.123
 0.124
 0.126
 
123ms

HTTP(S) 부하 분산 결과는 매우 다릅니다. HTTP(S) 부하 분산을 핑할 경우 왕복 지연 시간은 1 ms를 약간 넘습니다. 이 결과는 사용자와 같은 도시에 있는 가장 가까운 GFE의 지연 시간을 나타냅니다. 이 결과에는 us-central1 리전에서 호스팅되는 애플리케이션에 액세스하려고 할 때 사용자가 경험하는 실제 지연 시간이 반영되지 않습니다. 애플리케이션 통신 프로토콜(HTTP)과 다른 프로토콜(ICMP)을 사용하는 실험은 오해의 소지가 있을 수 있습니다.

TTFB를 측정할 경우 초기 요청에서는 거의 비슷한 응답 지연 시간이 발생합니다. 일부 요청은 다음 그래프와 같이 123ms의 낮은 최소 지연 시간을 보입니다.

ms 그래프에서 HTTP(S) 부하 분산에 대한 지연 시간(확대하려면 클릭)
ms 그래프에서 HTTP(S) 부하 분산에 대한 지연 시간(확대하려면 클릭)

직선 광섬유를 사용해도 클라이언트와 VM 간의 2회 왕복에 123ms 넘게 걸립니다. GFE가 트래픽을 프록시 처리하므로 지연 시간이 줄어듭니다. GFE는 백엔드 VM에 대한 지속적인 연결을 유지합니다. 따라서 특정 백엔드에 대한 특정 GFE의 첫 번째 요청에 한해 3방향 핸드셰이크가 필요합니다.

GFE 다이어그램을 통한 초기 HTTP 요청(확대하려면 클릭)
GFE 다이어그램을 통한 초기 HTTP 요청(확대하려면 클릭)

각 위치에는 GFE가 여러 개 있습니다. 지연 시간 그래프에서는 트래픽이 각 GFE-백엔드 쌍에 처음 도달할 때 급격하게 증가하는 여러 형태를 보여줍니다. 그런 다음 GFE는 백엔드에 대한 새 연결을 설정해야 합니다. 이러한 급증은 요청 해시 차이를 반영합니다. 이후 요청에서는 지연 시간이 짧습니다.

GFE 다이어그램을 통한 후속 HTTP 요청(확대하려면 클릭)
GFE 다이어그램을 통한 후속 HTTP 요청(확대하려면 클릭)

이 시나리오는 사용자가 프로덕션 환경에서 경험할 수 있는 감소된 지연 시간을 보여줍니다. 다음은 그 결과를 요약한 표입니다.

옵션 TTFB
부하 분산 없음 웹 서버까지 110ms 230ms
네트워크 부하 분산 리전 내 네트워크 부하 분산기까지 110ms 230ms
HTTP(S) 부하 분산 가장 가까운 GFE까지 1ms 123ms

정상적인 애플리케이션에서 특정 리전의 사용자에게 서비스를 제공하는 경우 해당 리전의 GFE는 모든 제공 중인 백엔드에 지속적인 연결을 유지합니다. 따라서 해당 리전의 사용자가 애플리케이션 백엔드와 멀리 떨어져 있는 경우 첫 번째 HTTP 요청의 지연 시간이 줄어듭니다. 사용자가 애플리케이션 백엔드 근처에 있는 경우 사용자는 지연 시간 개선을 알아채지 못합니다.

페이지 링크 클릭과 같은 후속 요청의 경우 최신 브라우저에서 서비스에 대한 영구 연결을 유지하므로 지연 시간이 개선되지 않습니다. 이는 명령줄에서 실행된 curl 명령어와 다릅니다.

HTTP(S) 부하 분산의 추가 지연 시간 효과

HTTP(S) 부하 분산의 관찰 가능한 추가 효과는 트래픽 패턴에 따라 다릅니다.

  • HTTP(S) 부하 분산에서는 네트워크 부하 분산에 비해 응답이 완료되기 전에 필요한 왕복 횟수가 적으므로 복잡한 애셋에 대한 지연 시간이 짧습니다. 예를 들어 독일 사용자가 10MB 파일을 반복적으로 다운로드하여 동일한 연결에서 지연 시간을 측정하는 경우 HTTP(S) 부하 분산의 평균 지연 시간이 1341ms인 반면 네트워크 부하 분산의 평균 지연 시간은 1911ms입니다. 이렇게 하면 요청당 왕복 횟수가 5회 정도 절약됩니다. GFE와 제공 백엔드 간의 영구 연결은 TCP 느린 시작의 효과를 감소시킵니다.

  • HTTP(S) 부하 분산은 SSL 오프로드를 사용하고 에지 PoP의 지연 시간만 관련이 있으므로 TLS 핸드셰이크(일반적으로 1-2회의 추가 왕복)의 추가 지연 시간을 크게 줄여줍니다. 독일 사용자의 경우 네트워크 부하 분산을 통해 HTTP(S)를 사용할 경우 525ms가 기록된 것에 반해 HTTP(S) 부하 분산을 사용할 경우에는 최소 지연 시간이 201ms입니다.

  • HTTP(S) 부하 분산을 사용하면 사용자 대상 세션을 HTTP/2로 자동 업그레이드할 수 있으므로 바이너리 프로토콜, 헤더 압축, 연결 멀티플렉싱을 사용하여 필요한 패킷 수를 줄일 수 있습니다. 이렇게 하면 HTTP(S) 부하 분산으로 전환하여 관찰된 지연 시간을 관찰 이상으로 줄일 수 있습니다. HTTP/2는 SSL/TLS를 사용하는 현재 브라우저에서 지원됩니다. 독일 사용자의 경우 HTTPS 대신 HTTP/2를 사용할 경우 최소 지연 시간이 201ms에서 145ms로 더욱 단축되었습니다.

HTTP(S) 부하 분산 최적화

다음과 같이 외부 HTTP(S) 부하 분산기를 사용하면 애플리케이션 지연 시간을 최적화할 수 있습니다.

  • 제공하는 트래픽 중 일부를 캐시할 수 있으면 Cloud CDN과 통합할 수 있습니다. Cloud CDN은 Google의 네트워크 에지에서 애셋을 직접 제공하여 지연 시간을 줄여줍니다. Cloud CDN은 HTTP(S) 부하 분산의 추가 지연 시간 효과 섹션에 언급된 HTTP/2의 TCP 및 HTTP 최적화도 사용합니다.

  • Google Cloud에서 모든 CDN 파트너를 사용할 수 있습니다. Google의 CDN Interconnect 파트너 중 하나를 이용하면 이그레스 비용을 할인 받을 수 있습니다.

  • 콘텐츠가 정적인 경우 HTTP(S) 부하 분산을 통해 Cloud Storage에서 직접 콘텐츠를 제공하여 웹 서버의 로드를 줄일 수 있습니다. 이 옵션은 Cloud CDN과 결합됩니다.

  • HTTP(S) 부하 분산, SSL 프록시 부하 분산, TCP 프록시 부하 분산은 자동으로 사용자를 가장 가까운 리전에 연결하므로 사용자와 가까운 리전 여러 개에 웹 서버를 배포하면 지연 시간이 단축될 수 있습니다. 하지만 애플리케이션이 부분적으로 중앙 집중화된 경우 리전 간 왕복 횟수가 줄어들도록 설계해야 합니다.

  • 애플리케이션 내부의 지연 시간을 줄이려면 VM 간에 통신하는 RPC(리모트 프로시저 콜)를 검사하세요. 일반적으로 애플리케이션에서 계층 또는 서비스 간에 통신할 때 이러한 지연 시간이 발생합니다. Cloud Trace와 같은 도구를 사용하면 애플리케이션 제공 요청으로 인한 지연 시간을 줄일 수 있습니다.

  • TCP 프록시 부하 분산과 SSL 프록시 부하 분산은 GFE를 기반으로 하므로 지연 시간 효과는 HTTP(S) 부하 분산에서 관찰된 효과와 같습니다. HTTP(S) 부하 분산에는 TCP 프록시 부하 분산과 SSL 프록시 부하 분산보다 많은 기능이 있으므로 HTTP(S) 트래픽에는 HTTP(S) 부하 분산을 사용하는 것이 좋습니다.

다음 단계

대부분의 사용자와 가까운 애플리케이션을 배포하는 것이 좋습니다. Google Cloud의 다양한 부하 분산 옵션에 대한 자세한 내용은 다음 문서를 참조하세요.