티스토리 뷰
[구글 클라우드 플랫폼] GCP : Load Balancing and Autoscailing
로또_ 2020. 12. 18. 02:40Load Balancing and Autoscailing
목차:
0. Load Balancer
1. Managed Instance groups
2. HTTP(s) Load Balancing
3. SSL Proxy/TCP Proxy Load Balancing
4. Network Load Balancing
5. Internal Load Balancing
6. Choosing a Load Balancer
0. Load Balancer
- GCP는 Global 및 Regional의 두 가지 카테고리로 나눌 수 있는 다양한 유형의 Load Balancing을 제공합니다.
- Global Load Balancers는 HTTP (S), SSL 프록시, TCP 프록시 부하 분산기입니다. 이러한 Load Balancing은 Google의 접속 지점에 있고 전 세계에 배포되는 소프트웨어 정의 분산 시스템 인 Google 프런트 엔드를 활용합니다. 따라서 사용자와 인스턴스가 global로 분산되고 사용자가 동일한 애플리케이션과 콘텐츠에 액세스 해야 하며 단일 애니 캐스트 IP 주소를 사용하여 액세스를 제공하려는 경우 Global Load Balancer를 사용해야 합니다.
- Regional Load Balancers는 내부 및 네트워크 부하 분산기이며 단일 GCP region에 있는 인스턴스에 트래픽을 분산합니다. Regional Load Balancer는 GCP의 소프트웨어 정의 네트워크 가상화 스택 인 Andromeda를 사용하고 네트워크 부하 분산기는 대규모 분산 소프트웨어 시스템 인 Maglev를 사용합니다.
- HTTP(S) 트래픽을 위한 또 다른 내부 부하 분산기가 있지만 현재까지는 베타 버전으로 존재합니다. 이 6번째 부하 분산기는 프록시 기반의 지역 Layer7 부하 분산기로, VPC 네트워크의 부하 분산기 지역에서만 액세스 할 수 있는 비공개 부하 분산 IP 주소 뒤에서 서비스를 실행하고 확장할 수 있습니다.
1. Managed Instance groups
- Managed instance group은 인스턴스 템플릿을 사용하여 단일 항목으로 제어하는 동일한 VM 인스턴스의 모음입니다. 지속적 업데이트에서 새 템플릿을 지정하여 그룹의 모든 인스턴스를 쉽게 업데이트할 수 있습니다. 또한 애플리케이션에 추가 컴퓨팅 리소스가 필요한 경우 Managed instance group은 그룹의 인스턴스 수를 자동으로 확장할 수 있습니다.
- Managed instance group은 load balance 서비스와 함께 작동하여 그룹의 모든 인스턴스에 네트워크 트래픽을 분산할 수 있습니다. 그룹의 인스턴스가 중지, 비정상 종료되거나 인스턴스 그룹의 명령어 이외의 작업에 의해 삭제되는 경우 관리형 인스턴스 그룹은 처리 작업을 재개할 수 있도록 인스턴스를 자동으로 다시 만듭니다. 다시 생성된 인스턴스는 이전 인스턴스와 동일한 이름과 동일한 인스턴스 템플릿을 사용합니다. 관리형 인스턴스 그룹은 그룹에서 비정상 인스턴스를 자동으로 식별하고 다시 생성하여 모든 인스턴스가 최적으로 실행되도록 할 수 있습니다.
- Regional managed instance groups은 일반적으로 zonal managed instance groups보다 권장됩니다. 애플리케이션을 단일 zone으로 제한하거나 여러 zone에서 여러 인스턴스 그룹을 관리해야 하는 대신 여러 zones에 애플리케이션 부하를 분산할 수 있기 때문입니다. 이 복제는 단일 zone에 있는 전체 인스턴스 그룹이 오작동하는 예기치 않은 시나리오와 영역 장애로부터 보호합니다. 이 경우 애플리케이션은 동일한 지역의 다른 zone에서 실행 중인 인스턴스의 트래픽을 계속 제공할 수 있습니다.
- 앞서 언급했듯이 Managed instance group은 부하 증가 또는 감소에 따라 관리 형 인스턴스 그룹에서 인스턴스를 자동으로 추가하거나 제거할 수 있는 자동 확장 기능을 제공합니다. 자동 확장은 애플리케이션이 트래픽 증가를 정상적으로 처리하고 리소스 필요성이 낮을 때 비용을 줄이는 데 도움이 됩니다. 자동 확장 정책을 정의하기 만하면 자동 확장 처리가 측정된 부하에 따라 자동 확장을 수행합니다. 적용 가능한 자동 확장 정책에는 CPU 사용률, 부하 분산 용량, 모니터링 측정 항목 또는 Cloud Pub / Sub와 같은 대기열 기반 워크로드에 따른 확장이 포함됩니다.
- 예를 들어 위 그림에 표시된 것처럼 CPU 사용률이 100 % 및 85 % 인 2 개의 인스턴스가 있다고 가정해 보겠습니다. 대상 CPU 사용률이 75 % 이면 자동 확장 처리가 진행됩니다. 그리고 다른 인스턴스를 추가하여 CPU 부하를 분산하고 대상 CPU 사용률 75 % 미만을 유지합니다. 마찬가지로 전체 부하가 목표보다 훨씬 낮으면 전체 사용률이 목표 미만으로 유지되는 한 자동 확장 처리가 인스턴스를 제거합니다.
- Managed instance group 및 load balancer에 대한 또 다른 중요한 구성은 health check입니다. health checks는 Stackdriver의 uptime check와 매우 유사합니다. 이 스크린 샷에 표시된 대로 프로토콜, 포트 및 상태 기준을 정의하기 만하면 됩니다. 이 구성을 기반으로 GCP는 각 인스턴스의 상태를 계산합니다.
상태 기준은 인스턴스가 정상인지 확인하는 빈도 (확인 간격)를 정의합니다. 응답을 기다리는 시간 (시간 초과) 얼마나 많은 성공 시도가 결정적인지 (healthy 임계 값) 실패한 시도 횟수가 결정적인 요소입니다.(unhealthy 임계 값). 위 그림의 예에서 heal check는 인스턴스가 비정상으로 간주되기 전에 총 15 초 동안 두 번 실패해야 합니다.
2. HTTP(s) Load Balancing
- GCP의 HTTP (S) 부하 분산은 인스턴스로 향하는 HTTP (S) 요청에 대한 global load balancing을 제공합니다. 즉, 단일 애니 캐스트 IP 주소에서 고객이 애플리케이션을 사용할 수 있으므로 DNS 설정이 간소화됩니다. HTTP (S) 부하 분산은 여러 백엔드 인스턴스와 여러 지역에서 HTTP 및 HTTPS 트래픽의 균형을 유지합니다. HTTP 요청은 포트 80 또는 8080에서 로드 밸런싱 되고 HTTPS 요청은 포트 443에서 로드 밸런싱 됩니다. 이 로드 밸런서는 IPv4 및 IPv6 클라이언트를 모두 지원하고 확장 가능하며 사전 준비가 필요하지 않습니다. 또한 콘텐츠 기반 및 교차 지역 로드를 지원합니다.
- 일부 URL은 한 인스턴스 세트로 라우팅하고 다른 URL은 다른 인스턴스로 라우팅 하는 URL 맵을 구성 할 수 있습니다. 요청은 일반적으로 사용자에게 가장 가까운 인스턴스 그룹으로 라우팅 됩니다. 가장 가까운 인스턴스 그룹에 충분한 용량이 없는 경우 요청은 용량이 있는 다음으로 가장 가까운 인스턴스 그룹으로 전송됩니다.
- 위 다이어그램을 사용하여 HTTP (S) 부하 분산기의 전체 아키텍처를 살펴보겠습니다.
- Global Forwarding Rule은 인터넷에서 들어오는 요청을 target HTTP 프록시로 보냅니다.
- target HTTP 프록시는 URL 맵에 대해 각 요청을 확인하여 요청에 적합한 백엔드 서비스를 결정합니다. 예를 들어 www.example.com/audio에 대한 요청을 오디오 파일을 전달하도록 구성된 인스턴스가 포함된 하나의 백엔드 서비스로, www.example.com/video에 대한 요청을 전달하도록 구성된 인스턴스가 포함된 다른 백엔드 서비스로 보낼 수 있습니다.
- 백엔드 서비스는 연결된 백엔드의 제공 용량, 영역, 인스턴스 상태에 따라 각 요청을 적절한 백엔드로 보냅니다.
- 백엔드 서비스에는 health check, session affinity, 시간제한 설정 및 하나 이상의 백엔드가 포함됩니다. health check는 구성된 간격으로 백엔드 서비스에 연결된 인스턴스를 폴링 합니다. health check를 통과 한 인스턴스는 새 요청을 받을 수 있습니다. 비정상 인스턴스는 다시 정상 상태가 될 때까지 요청이 전송되지 않습니다. 일반적으로 HTTP (S) load balancing은 라운드 로빈 알고리즘을 사용하여 사용 가능한 인스턴스 간에 요청을 분산합니다. 이는 session affinity로 재정의 될 수 있습니다. session affinity는 동일한 클라이언트의 모든 요청을 동일한 가상 머신 인스턴스로 보내려고 합니다.
- 백엔드 서비스에는 기본적으로 30초로 설정된 시간제한 설정도 있습니다. 요청을 실패로 간주하기 전에 백엔드 서비스가 백엔드에서 대기하는 시간입니다. 이것은 유휴 제한 시간이 아니라 고정 제한 시간입니다. 수명이 더 긴 연결이 필요한 경우가 값을 적절하게 설정해야 합니다.(변경해야 합니다)
- 백엔드 자체에는 instance group, balancing mode 및 capacity scaler가 포함됩니다.
-
인스턴스 그룹에는 가상 머신 인스턴스가 포함됩니다. 인스턴스 그룹은 자동 확장이 있거나 없는 관리 형 인스턴스 그룹 또는 비 관리 형 인스턴스 그룹 일 수 있습니다.
-
balancing mode는 부하 분산 시스템에 백엔드가 완전히 사용되는 시기를 결정하는 방법을 알려줍니다. 한 지역의 백엔드 서비스에 대해 모든 백엔드가 완전히 사용되는 경우 새 요청은 요청을 처리할 수 있는 가장 가까운 지역으로 자동 라우팅 됩니다. 균형 조정 모드는 CPU 사용률 또는 초당 요청 (RPS)을 기반으로 할 수 있습니다.
-
용량 설정은 balancing mode setting과 상호 작용하는 추가 제어입니다. 예를 들어 일반적으로 인스턴스가 최대 80 % CPU 사용률로 작동하도록 하려면 분산 모드를 80 % CPU 사용률로 설정하고 용량을 100 %로 설정합니다. 인스턴스 사용률을 절반으로 줄이려면 분산 모드를 CPU 사용률 80 %로 유지하고 용량을 50 %로 설정할 수 있습니다.
-
백엔드 서비스에 대한 변경 사항은 즉시 적용되지 않습니다. 따라서 변경 사항이 네트워크 전체에 전파되는 데 몇 분이 걸릴 수 있습니다.
- 작동 중인 HTTP로드 밸런서를 살펴보겠습니다 위 그림의 프로젝트에는 단일 글로벌 IP 주소가 있지만 사용자는 북미와 EMEA의 서로 다른 두 위치에서 Google Cloud 네트워크에 접속합니다. 먼저 Global forwarding rule은 수신 요청을 대상 HTTP 프록시로 보냅니다. 프록시는 URL 맵을 확인 하여 요청에 적합한 백엔드 서비스를 결정합니다. 이 경우 백엔드 서비스가 하나만 있는 방명록 애플리케이션을 제공합니다.
- 백엔드 서비스에는 us-central1-a와 europe-west1-d에 하나씩 두 개의 백엔드가 있습니다. 각 백엔드는 관리 형 인스턴스 그룹으로 구성됩니다. 이제 사용자 요청이 들어오면 로드 밸런싱 서비스가 source IP 주소에서 요청의 대략적인 출처를 결정합니다. 또한 load balance 서비스는 백엔드 서비스가 소유 한 인스턴스의 위치, 전체 용량 및 전체 현재 사용량을 알고 있습니다. 따라서 사용자에게 가장 가까운 인스턴스에 사용 가능한 용량이 있는 경우 가장 가까운 인스턴스 집합으로 요청이 전달됩니다.
- 예시에서 북미 사용자의 트래픽은 us-central1-a의 관리 형 인스턴스 그룹으로 전달되고 EMEA 사용자의 트래픽은 europe-west1-d의 관리 형 인스턴스 그룹으로 전달됩니다. 각 지역에 여러 명의 사용자가 있는 경우 지정된 지역으로 들어오는 요청이 해당 지역의 사용 가능한 모든 백엔드 서비스 및 인스턴스에 균등하게 분산됩니다.
- 지정된 region에 사용 가능한 용량이 있는 정상 인스턴스가 없는 경우 로드 밸런서는 대신 사용 가능한 용량이 있는 다음으로 가장 가까운 region에 요청을 보냅니다. 따라서 europe-west1 d 백엔드에 용량이 없거나 상태 검사기가 확인한 정상 인스턴스가 없는 경우 EMEA 사용자의 트래픽이 us-central1-a 백엔드로 전달될 수 있습니다. 이를 region 간 부하 분산이라고 합니다.
- HTTP 부하 분산기의 또 다른 예는 콘텐츠 기반 부하 분산기입니다. 이 경우 웹 또는 비디오 트래픽을 처리하는 두 개의 별도 백엔드 서비스가 있습니다. 트래픽은 URL 맵에 지정된 URL 헤더를 기반으로 로드 밸런서에 의해 분할됩니다. 사용자가 /video로 이동하는 경우, 트래픽이 백엔드 비디오 서비스로 전송되고 사용자가 다른 곳으로 이동하는 경우 트래픽이 웹 서비스 백엔드로 전송됩니다. 이 모든 것은 단일 글로벌 IP 주소로 이루어집니다.
- HTTP(S) 부하 분산기는 HTTP 부하 분산기와 기본 구조가 동일하지만 다음과 같은 점이 다릅니다.
-
HTTP(S) 부하 분산기는 target HTTP 프록시 대신 target HTTPS 프록시를 사용합니다.
-
HTTP(S) 부하 분산기에는 부하 분산기의 target HTTPS 프록시에 설치된 하나 이상의 서명된 SSL 인증서가 필요합니다.
-
클라이언트 SSL 세션은 로드 밸런서에서 종료됩니다.
-
HTTP(S) 부하 분산기는 QUIC 전송 계층 프로토콜을 지원합니다.
- QUIC는 더 빠른 클라이언트 연결 시작을 가능하게 하고 멀티 플렉스 스트림에서 헤드 오브 라인 차단을 제거하며 클라이언트의 IP 주소가 변경될 때 연결 마이그레이션을 지원하는 전송 계층 프로토콜입니다.
- HTTPS를 사용하려면 로드 밸런서의 target 프록시에서 사용할 수 있는 SSL 인증서를 하나 이상 만들어야 합니다. 최대 10 개의 SSL 인증서로 target 프록시를 구성할 수 있습니다. 각 SSL 인증서에 대해 먼저 SSL 인증서 정보가 포함된 SSL 인증서 리소스를 만듭니다. SSL 인증서 리소스는 taregt HTTPS 프록시 또는 target SSL 프록시와 같은 부하 분산 프록시에서만 사용됩니다.
3. SSL Proxy/TCP Proxy Load Balancing
SSL 프록시는 HTTP가 아닌 암호화된 트래픽을 위한 Global load balancing 서비스입니다. 이 load balancer는 부하 분산 레이어에서 사용자 SSL 연결을 종료한 다음 SSL 또는 TCP 프로토콜을 사용하여 인스턴스 간의 연결 균형을 조정합니다. 이러한 인스턴스는 여러 Region에 있을 수 있으며 로드 밸런서는 수용량이 있는 가장 가까운 region으로 트래픽을 자동으로 보냅니다.
-
SSL proxy load balancing은 클라이언트 트래픽에 대해 IPv4 및 IPv6 주소를 모두 지원하고 지능형 라우팅, 인증서 관리, 보안 패치 및 SSL 정책을 제공합니다.
-
지능형 라우팅은 이 load balancer가 용량이 있는 백엔드 위치로 요청을 라우팅 할 수 있음을 의미합니다.
-
인증서 관리 관점에서 인증서를 전환해야 할 때 한 곳에서 고객 대면 인증서를 업데이트하기 만하면 됩니다. 또한 인스턴스에서 자체 서명된 인증서를 사용하여 가상 머신 인스턴스의 관리 오버 헤드를 줄일 수 있습니다.
-
또한 SSL 또는 TCP 스택에서 취약점이 발생하면 GCP는 인스턴스를 안전하게 유지하기 위해 부하 분산기에 자동으로 패치를 적용합니다.
위 네트워크 다이어그램은 SSL 프록시 load balancing을 보여줍니다. 이 예에서 Iowa 및 Boston에 있는 사용자의 트래픽은 글로벌 부하 분산 계층에서 종료됩니다. 거기에서 가장 가까운 백엔드 인스턴스에 대한 별도의 연결이 설정됩니다. 즉, 보스턴의 사용자는 미국 동부 지역에 도달하고 아이오와의 사용자는 충분한 용량이 있는 경우 미국 중부 지역에 도달합니다.
이제 프록시와 백엔드 간의 트래픽은 SSL 또는 TCP를 사용할 수 있습니다. 하지만 SSL을 사용하는 것이 좋습니다.
TCP 프록시는 암호화되지 않은 비 HTTP 트래픽을 위한 글로벌 부하 분산 서비스입니다. 이 부하 분산기는 부하 분산 레이어에서 고객의 TCP 세션을 종료 한 다음 TCP 또는 SSL을 사용하여 트래픽을 가상 머신 인스턴스로 전달합니다. 이러한 인스턴스는 여러 지역에 있을 수 있으며 로드 밸런서는 용량이 있는 가장 가까운 지역으로 트래픽을 자동으로 보냅니다.
TCP 프록시 부하 분산은 클라이언트 트래픽에 대해 IPv4 및 IPv6 주소를 모두 지원합니다. SSL 프록시로드 밸런서와 유사하게 TCP 프록시로드 밸런서는 지능형 라우팅 및 보안 패치를 제공합니다.
이 네트워크 다이어그램은 TCP 프록시 load balancing을 보여줍니다. 이 예에서 Iowa 및 Boston에 있는 사용자의 트래픽은 글로벌 부하 분산 계층에서 종료됩니다. 거기에서 가장 가까운 백엔드 인스턴스에 대한 별도의 연결이 설정됩니다. SSL 프록시 부하 분산 예에서와 같이 보스턴의 사용자는 미국 동부 지역에 도달하고 아이오와의 사용자는 충분한 용량이 있는 경우 미국 중부 지역에 도달합니다.
이제 프록시와 백엔드 간의 트래픽은 SSL 또는 TCP를 사용할 수 있습니다. 하지만 SSL을 사용을 권장합니다.
4. Network Load Balancing
네트워크 load balance는 프록시 되지 않은 지역 부하 분산 서비스입니다. 즉, 모든 트래픽은 프록시 되지 않고 부하 분산기를 통해 전달되며 global 부하 분산기와 달리 동일한 지역에 있는 VM 인스턴스 간에만 트래픽을 분산할 수 있습니다.
이 부하 분산 서비스는 전달 규칙을 사용하여 주소, 포트 및 프로토콜 유형과 같은 수신 IP 프로토콜 데이터를 기반으로 시스템의 부하를 분산합니다. 이를 사용하여 UDP 트래픽의 부하를 분산하고 TCP 프록시 및 SSL 프록시 부하 분산기에서 지원하지 않는 포트에서 TCP 및 SSL 트래픽의 부하를 분산할 수 있습니다.
네트워크 load balancer의 백엔드는 템플릿 기반 인스턴스 그룹 또는 target pool 리소스 일 수 있습니다. target pool 리소스는 무엇일까요?
target pool 리소스는 forwarding rule에서 들어오는 트래픽을 수신하는 인스턴스 그룹을 정의합니다. Forwarding rule이 트래픽을 target pool로 보낼 때 load balance는 source IP 및 포트의 해시와 대상 IP 및 포트를 기반으로 이러한 target pool에서 인스턴스를 선택합니다. 이러한 대상 풀은 TCP 및 UDP 트래픽을 처리하는 forwarding rule에만 사용할 수 있습니다.
이제 각 프로젝트에는 최대 50 개의 target pool이 있을 수 있으며 각 target pool에는 하나의 Health check만 있을 수 있습니다. 또한 target pool의 모든 인스턴스는 동일한 지역에 있어야 합니다. 이는 네트워크 부하 분산기와 동일한 제한을 가지고 있습니다.
5. Internal Load Balancing
내부 load balancing은 TCP 및 UDP 기반 트래픽을 위한 region 비공개 load balance서비스입니다. 즉, 이 로드 밸런서를 사용하면 프라이빗 로드 밸런싱 IP 주소 뒤에서 서비스를 실행하고 확장할 수 있습니다. 즉, 동일한 지역에 있는 가상 머신 인스턴스의 내부 IP 주소를 통해서만 액세스 할 수 있습니다.
따라서 내부 부하 분산을 사용하여 비공개 백엔드 인스턴스의 프런트 엔드 역할을 할 내부 부하 분산 IP 주소를 구성합니다. 부하 분산 서비스에 공개 IP 주소가 필요하지 않기 때문에 내부 클라이언트 요청은 VPC 네트워크 및 지역 내부에 유지됩니다. 모든 부하 분산 트래픽이 Google 네트워크 내에 유지되어 구성이 훨씬 간단 해 지므로 지연 시간이 단축되는 경우가 많습니다. 이제 소프트웨어 정의 내부 load balance 서비스 사용의 이점에 대해 자세히 알아보겠습니다.
GCP 내부 load balance는 device 또는 VM 인스턴스를 기반으로 하지 않는 소프트웨어 정의의 완전 분산형 로드 밸런싱 솔루션입니다.
내부 load balance의 기존 프록시 모델에서 왼쪽에 표시된 것처럼 부하 분산 장치 또는 인스턴스에 내부 IP 주소를 구성하면 클라이언트 인스턴스가 이 IP 주소에 연결됩니다. IP 주소로 들어오는 트래픽은 부하 분산기에서 종료되고 부하 분산기는 새 연결을 설정할 백엔드를 선택합니다. 기본적으로 두 개의 연결이 있습니다. 하나는 클라이언트와 로드 밸런서 사이이고 다른 하나는 로드 밸런서와 백엔드 사이입니다.
GCP 내부 load balance는 오른쪽에 표시된 것처럼 다른 접근 방식을 사용하여 클라이언트 인스턴스 요청을 백엔드로 분산합니다. Andromeda (Google의 네트워크 가상화 스택) 위에 구축된 경량 부하 분산을 사용하여 클라이언트 인스턴스에서 백엔드 인스턴스로 직접 트래픽을 전달하는 소프트웨어 정의 부하 분산을 제공합니다.
이제 내부 load balance를 통해 기존의 3 계층 웹 서비스와 같은 사용 사례를 지원할 수 있습니다.
이 예에서 웹 계층은 샌프란시스코, 아이오와, 싱가포르 등의 사용자에게 단일 global IP 주소를 제공하는 외부 HTTP(S) load balancer를 사용합니다. 이 부하 분산기의 백엔드는 global load balancer이므로 us-central1 및 asia east1 지역에 있습니다.
그런 다음 이러한 백엔드는 애플리케이션 또는 내부 계층으로 각 지역의 내부 load balancer에 액세스 합니다. 이 내부 계층의 백엔드는 us-central1-a, us-central1-b 및 asia-east1-b에 있습니다. 마지막 계층은 각 영역의 데이터베이스 계층입니다. 이 3 계층 접근 방식의 이점은 데이터베이스 계층이나 애플리케이션 계층이 외부에 노출되지 않는다는 것입니다. 이는 보안 및 네트워크 가격을 단순화합니다.
6. Choosing a Load Balancer
다른 GCP load balancer의 한 가지 차이점은 IPv6 클라이언트 지원입니다. HTTP(S), SSL 프록시 및 TCP 프록시 load balance 서비스만 IPv6 클라이언트를 지원합니다. 이러한 부하 분산기에 대한 IPv6 종료를 사용하면 사용자의 IPv6 요청을 처리하고 IPv4를 통해 백엔드로 프록시 할 수 있습니다.
예를 들어 위 다이어그램에는 Cloud DNS에서 IPv4 및 IPv6 주소로 변환된 웹 사이트 www.example.com 이 있습니다. 이를 통해 뉴욕의 데스크톱 사용자와 아이오와의 모바일 사용자가 각각 IPv4 및 IPv6 주소를 통 해로드 밸런서에 액세스 할 수 있습니다. 그러나 트래픽은 어떻게 백엔드와 IPv4 주소로 이동할까요?
load balancer는 reverse 프록시 역할을 하고 IPv6 클라이언트 연결을 종료하고 요청을 백엔드에 대한 IPv4 연결에 배치합니다. 역방향 경로에서 로드 밸런서는 백엔드로부터 IPv4 응답을 수신하여 원래 클라이언트에 대한 IPv6 연결에 다시 배치합니다. 즉, 부하 분산기에 IPv6 종료를 구성하면 백엔드 인스턴스가 IPv6 클라이언트에 IPv6 애플리케이션으로 표시됩니다.
이제 GCP 구현에 가장 적합한 부하 분산기를 결정하려면 Cloud Load Balancing의 여러 측면을 고려해야 합니다. global load balance와 regional load balance, 외부 load balance과 내부 load balance, 트래픽 유형. 외부 load balace 서비스가 필요한 경우가 순서도의 왼쪽 상단에서 시작하시면 됩니다.
먼저 로드 밸런서가 처리해야 하는 트래픽 유형을 선택합니다. HTTP 또는 HTTPS 트래픽인 경우 HTTP (S) 부하 분산 서비스를 Layer 7 부하 분산기로 사용하는 것이 좋습니다. 그렇지 않으면이 순서도의 TCP 및 UDP 트래픽 경로를 사용하여 SSL 프록시, TCP 프록시 또는 네트워크 부하 분산 서비스가 요구 사항을 충족하는지 확인합니다.
내부 load balance 서비스가 필요한 경우 내부 load balance 서비스를 사용할 수 있으며 TCP 및 UDP 트래픽을 모두 지원합니다. 이 모듈의 시작 부분에서 언급했듯이 실제로 HTTP(S) 트래픽을 위한 또 다른 내부 load balancer가 있지만 현재는 베타 버전입니다. 이 6번째 부하 분산기는 HTTP 또는 HTTPS 트래픽 용이며 지역적이며 IPv4 클라이언트를 의미합니다.
위 표는 트래픽 유형, 백엔드 배포 (global 또는 region), 백엔드의 IP 주소 유형 (외부 또는 내부)에 따라 올바른 load balancer를 식별하는 데 도움이 됩니다. 이 표에는 로드 밸런싱에 사용할 수 있는 포트도 나열되어 있으며 글로벌 로드 밸런서만 IPv4 및 IPv6 클라이언트를 모두 지원한다는 점을 강조하고 있습니다.