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

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

부하 분산 옵션

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

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

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

프리미엄 네트워크 서비스 계층을 사용하는 경우에만 글로벌 부하 분산이 가능하므로 이 문서에서는 모든 측정에 프리미엄 네트워크 서비스 계층을 사용했습니다.

지연 시간 측정

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

  • : 서버의 연결 가능성을 측정할 때 사용되는 일반적인 방법이지만 ICMP 핑으로는 최종 사용자의 지연 시간을 정확하게 알 수 없습니다. 자세한 내용은 HTTP(S) 부하 분산의 추가 지연 시간 효과 섹션을 참조하세요.
  • 첫 바이트 소요 시간(TTFB): curl 명령어를 반복적으로 서버에 전송해 웹 서버의 응답을 얻어 첫 번째 HTTP 응답을 받을 때까지 소요되는 시간을 측정하는 데 유용한 방법입니다.

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

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

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

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

지연 시간 비교

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

  • 부하 분산 없음
  • 네트워크 부하 분산
  • HTTP 부하 분산 또는 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_total}\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이 있는 리전에서 트래픽은 먼저 Adlev 부하 분산기를 통과합니다. 그리고 나서 대상 백엔드 VM에 그대로 전달됩니다. Maglev 부하 분산기가 안정적인 해싱 알고리즘을 기반으로 트래픽을 분산합니다. 이 알고리즘은 소스 및 대상 포트, 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_total}\n" -o /dev/null -s net-lb
 

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

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

HTTP(S)/TCP/SSL 프록시 부하 분산

HTTP 부하 분산을 사용할 경우 일반적으로 Google 글로벌 네트워크 에지에 위치한 GFE를 통해 트래픽이 프록시 처리됩니다. GFE는 TCP 세션을 종료하고 트래픽 처리 용량을 갖춘 가장 가까운 리전의 백엔드에 연결합니다.

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

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

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

 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_total}\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 부하 분산의 결과는 다른 옵션과 상당히 다릅니다. HTTP 부하 분산기를 핑할 때 왕복 지연 시간은 1ms를 약간 초과합니다. 하지만 이 결과는 이 경우 사용자와 동일한 도시에 있는 가장 가까운 GFE에 대한 지연 시간을 나타냅니다. 이 결과는 us- central1 리전에 호스팅되는 애플리케이션에 액세스하려고 할 때 사용자가 경험하는 실제 지연 시간과 관련이 없습니다. 실험에서 애플리케이션 통신 프로토콜(HTTP)과 다른 프로토콜(ICMP)을 사용할 경우 오해의 소지가 있음을 알 수 있습니다.

TTFB를 측정할 경우 초기 요청에서는 거의 동일한 응답 지연 시간이 발생합니다. 요청이 진행되면서 추가 요청에서는 다음 그래프와 같이 123ms의 낮은 최소 지연 시간을 달성합니다.

ms 그래프의 HTTP 부하 분산기 지연 시간(확대하려면 클릭)
ms 그래프의 HTTP 부하 분산기 지연 시간(확대하려면 클릭)

완벽한 직선 광섬유를 사용해도 클라이언트와 VM 간의 2회 왕복에 123ms 이상이 걸립니다. 여기서 지연 시간이 짧아진 이유는 백엔드 VM에 대한 지속적인 연결을 유지하는 GFE를 통해 트래픽이 프록시 처리되기 때문입니다. 따라서 특정 백엔드에 대한 특정 GFE의 첫 번째 요청에 한해 3방향 핸드셰이크가 필요합니다.

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

각 위치에는 여러 개의 GFE가 있습니다. 지연 시간 그래프에서 트래픽이 처음으로 각 GFE 백엔드 쌍에 도달함에 따라 변동이 심한 여러 급증 현상이 나타납니다. 이는 요청 해시가 다름을 나타냅니다. 모든 GFE에 도달하면 후속 요청의 지연 시간이 단축됩니다.

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

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

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

정상적인 애플리케이션에서 특정 리전의 사용자에게 정기적으로 서비스를 제공하는 경우 해당 리전의 모든 GFE가 일반적으로 제공 중인 모든 백엔드에서 지속적인 연결을 유지해야 합니다. 따라서 해당 리전의 사용자가 애플리케이션 백엔드와 멀리 떨어져 있는 경우 첫 번째 HTTP 요청의 지연 시간이 크게 줄어듭니다. 애플리케이션 백엔드와 가까이 있는 사용자는 근접도 때문에 지연 시간이 개선되지 않는 것으로 관찰되었습니다.

페이지 링크를 클릭하는 것과 같은 후속 요청의 경우 최신 브라우저는 명령줄에서 실행되는 curl 명령어와 달리 재사용할 서비스에 대한 지속적인 연결을 유지하기 때문에 지연 시간이 개선되지 않습니다.

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

트래픽 패턴에 의존하는 HTTP(S) 부하 분산에는 관찰 가능한 효과가 몇 가지 더 있습니다.

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

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

  • 또한 HTTP(S) 부하 분산기를 사용하면 사용자용 세션을 HTTP/2로 자동 업그레이드할 수 있어 바이너리 프로토콜, 헤더 압축, 연결 다중화 기능의 개선을 통해 필요한 패킷 수를 줄일 수 있습니다. 그러면 HTTP 부하 분산으로만 전환할 때보다 관찰되는 지연 시간이 훨씬 줄어듭니다. HTTP/2는 SSL/TLS를 사용하는 현재 브라우저와 함께 사용해야 합니다. 독일 사용자의 경우 일반적인 HTTPS 대신 HTTP/2를 사용할 경우 최소 지연 시간이 201ms에서 145ms로 더욱 단축되었습니다.

HTTP(S) 부하 분산 최적화

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

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

  • GCP와 함께 CDN 파트너를 이용할 수 있습니다. Google의 CDN Interconnect 파트너 중 하나를 이용하면 이그레스 비용을 할인 받을 수 있습니다.

  • 정적 콘텐츠인 경우 HTTP/S 부하 분산기를 통해 Google Cloud Storage에서 직접 콘텐츠를 제공하여 웹 서버의 부하를 줄일 수 있습니다. 이 옵션은 앞서 언급한 CDN 옵션과 완벽하게 결합됩니다.

  • HTTP(S), SSL 프록시, TCP 프록시 부하 분산 시 자동으로 사용자가 가장 가까운 리전으로 연결되므로 사용자 근처의 여러 리전에 웹 서버를 배치하면 지연 시간을 줄일 수 있습니다. 하지만 애플리케이션이 부분적으로 중앙 집중화된 경우에는 리전 간 왕복을 최소화하도록 설계해야 합니다.

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

  • TCP 및 SSL 프록시 역시 GFE를 사용하므로 지연 시간에 미치는 영향이 HTTP 부하 분산에서 관찰된 결과와 동일합니다. HTTP(S) 부하 분산에는 TCP/SSL 프록시보다 많은 기능이 있으므로 항상 HTTP(S) 트래픽에 HTTP(S) 부하 분산을 사용하는 것이 좋습니다.

다음 단계

대부분의 사용자 가까이에 애플리케이션을 배포하고 용도에 가장 적합한 구성을 선택하는 것이 좋습니다. GCP의 다양한 부하 분산 옵션에 대한 자세한 내용은 다음 문서를 참조하세요.