외부 애플리케이션 부하 분산기(이 개요의 제목)가 다양한 리전의 웹 프런트엔드 인스턴스 그룹 집합으로 인터넷의 트래픽을 분산합니다.
이러한 웹 프런트엔드는 리전 내부 애플리케이션 부하 분산기 집합으로 HTTP(S) 트래픽을 전송합니다. 외부 애플리케이션 부하 분산기에서 내부 애플리케이션 부하 분산기로 트래픽이 전달되도록 하려면 외부 애플리케이션 부하 분산기에서 내부 애플리케이션 부하 분산기의 프런트엔드로 트래픽을 라우팅하도록 구성된 웹 서버 소프트웨어(예: Netscaler 또는 NGINX)가 포함된 백엔드 인스턴스가 필요합니다.
내부 애플리케이션 부하 분산기는 미들웨어 인스턴스 그룹에 트래픽을 배포합니다.
이러한 미들웨어 인스턴스 그룹은 내부 애플리케이션 부하 분산기로 트래픽을 전송하여 트래픽 부하를 데이터 스토리지 클러스터에 분산합니다.
다중 계층 앱의 내부 계층을 위한 레이어 7 기반 라우팅(확대하려면 클릭)
멀티 리전 부하 분산
프리미엄 등급에서 외부 애플리케이션 부하 분산기를 구성하면 전역 외부 IP 주소를 사용하고 사용자의 요청을 근접성에 따라 가장 가까운 백엔드 인스턴스 그룹 또는 NEG로 지능적으로 라우팅할 수 있습니다. 예를 들어 북미, 유럽, 아시아에서 인스턴스 그룹을 설정하고 부하 분산기의 백엔드 서비스에 연결하면 전 세계의 사용자 요청이 자동으로 사용자와 가장 가까운 VM으로 전송됩니다. 여기서 VM은 상태 점검을 통과하고 용량(분산 모드로 정의됨)이 충분한 것으로 가정합니다.
가장 가까운 VM이 모두 비정상이거나 가장 가까운 인스턴스 그룹 용량은 충분하지만 다른 인스턴스 그룹 용량이 부족하면 부하 분산기는 자동으로 요청을 용량이 충분한 다음으로 가장 가까운 리전으로 보냅니다.
프리미엄 등급에서 외부 애플리케이션 부하 분산기는 여러 백엔드 서비스를 사용하여 여러 리전에 각각 백엔드 인스턴스 그룹 또는 NEG가 포함된 멀티 리전 부하 분산을 제공합니다.
멀티 리전 부하 분산의 표현(확대하려면 클릭)
관할권 규정 준수 워크로드
규제 또는 규정 준수 요구사항이 있는 일부 워크로드는 네트워크 구성 및 트래픽 종료가 특정 리전에 속해 있어야 합니다. 이러한 워크로드에서는 워크로드에 요구되는 관할권 제어를 제공하기 위해 리전 외부 애플리케이션 부하 분산기를 선호하는 경우가 많습니다.
고급 트래픽 관리
전역 외부 애플리케이션 부하 분산기 및 리전 외부 애플리케이션 부하 분산기의 경우 트래픽 처리 방법을 세부적으로 제어하는 고급 트래픽 관리 기능을 추가할 수 있습니다. 이러한 기능을 사용하면 가용성 및 성능 목표를 충족할 수 있습니다. 이러한 사용 사례에 외부 애플리케이션 부하 분산기를 사용할 때의 이점 중 하나는 애플리케이션 코드를 수정할 필요 없이 트래픽 관리 방법을 업데이트할 수 있다는 점입니다.
외부 애플리케이션 부하 분산기는 URL 맵을 사용하여 요청된 호스트 이름, 요청 경로 또는 둘 다에 따라 백엔드 서비스를 선택하여 요청 라우팅을 지원합니다. 예를 들어 인스턴스 그룹 또는 NEG 집합을 사용하여 동영상 콘텐츠를 처리하고 다른 집합을 사용하여 모든 항목을 처리할 수 있습니다.
Cloud Load Balancing은 Google Cloud외부에 있는 외부 백엔드로 트래픽을 프록시할 수 있습니다. 외부 백엔드에서 콘텐츠를 제공하려고 하지만 Google Cloud 부하 분산기를 프런트엔드로 지정하려는 경우 이 유형의 배포를 사용할 수 있습니다. 부하 분산기는 대부분의 과정에 Google의 안정성이 높은 백본 네트워크를 사용하여 트래픽을 외부 엔드포인트로 프록시하고 대상과 가까운 공개 인터넷으로만 전달합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# External Application Load Balancer use cases\n\nThe external Application Load Balancers address many use cases. This page provides some\nhigh-level examples.\n\nThree-tier web services\n-----------------------\n\nYou can use an external Application Load Balancer to support traditional\nthree-tier web services. The following example shows how you can use three types\nof Google Cloud load balancers to scale three tiers. At each tier, the\nload balancer type depends on your traffic type:\n\n- **Web tier:** Traffic enters from the internet and is load balanced by using\n an [external Application Load Balancer](/load-balancing/docs/https).\n\n- **Application tier:** The application tier is scaled by using a regional\n internal Application Load Balancer.\n\n- **Database tier:** The database tier is scaled by using an\n [internal passthrough Network Load Balancer](/load-balancing/docs/internal).\n\nThe diagram shows how traffic moves through the tiers:\n\n1. An external Application Load Balancer (the subject of this overview) distributes traffic from the internet to a set of web frontend instance groups in various regions.\n2. These web frontends send the HTTP(S) traffic to a set of regional, internal Application Load Balancers. For the external Application Load Balancer to forward traffic to an internal Application Load Balancer, the external Application Load Balancer must have backend instances with web server software (such as Netscaler or NGINX) configured to forward the traffic to the frontend of the internal Application Load Balancer.\n3. The internal Application Load Balancers distribute the traffic to middleware instance groups.\n4. These middleware instance groups send the traffic to internal passthrough Network Load Balancers, which load balance the traffic to data storage clusters.\n\n[](/static/load-balancing/images/ilb-l7-tiers.svg) Layer 7-based routing for internal tiers in a multitier app (click to enlarge).\n\nMulti-region load balancing\n---------------------------\n\nWhen you configure an external Application Load Balancer in Premium Tier, it uses a global\nexternal IP address and can intelligently route requests from users to the\nclosest backend instance group or NEG, based on proximity. For example, if you\nset up instance groups in North America, Europe, and Asia, and attach them to a\nload balancer's backend service, user requests around the world are\nautomatically sent to the VMs closest to the users, assuming the\nVMs pass health checks and have enough capacity (defined by the balancing mode).\nIf the closest VMs are all unhealthy, or if the closest instance group is at\ncapacity and another instance group is not at capacity, the load balancer\nautomatically sends requests to the next closest region with capacity.\n\nIn Premium Tier, the external Application Load Balancer provides\nmulti-region load balancing, using multiple backend services,\neach with backend instance groups or NEGs in multiple regions.\n[](/static/load-balancing/images/https-load-balancer-diagram.svg) Representation of multiregion load balancing (click to enlarge).\n\nWorkloads with jurisdictional compliance\n----------------------------------------\n\nSome workloads with regulatory or compliance requirements require that network\nconfigurations and traffic termination reside in a specific region. For these\nworkloads, a regional external Application Load Balancer is often the preferred\noption to provide the jurisdictional controls these workloads require.\n\nAdvanced traffic management\n---------------------------\n\nWith global external Application Load Balancers and regional external Application Load Balancers, you can add\nadvanced traffic management capabilities that give you fine-grained control over\nhow traffic is handled. These capabilities help you to meet your availability\nand performance objectives. One of the benefits of using\nexternal Application Load Balancers for these use cases is that you can update how\ntraffic is managed without needing to modify your application code.\n\nFor more details, see the following:\n\n- [Traffic management\n overview for global external Application Load Balancer](/load-balancing/docs/https/traffic-management-global).\n- [Traffic management\n overview for regional external Application Load Balancer](/load-balancing/docs/https/traffic-management-regional).\n\nLoad balancing with request routing\n-----------------------------------\n\nThe external Application Load Balancer supports request routing by using URL maps\nto select a backend service based on the requested host name, request path, or\nboth. For example, you can use a set of instance groups or NEGs to handle your\nvideo content and another set to handle everything else.\n\nYou can also use external Application Load Balancers with [Cloud Storage](/storage)\n[buckets](/storage/docs/json_api/v1/buckets). After you have your load balancer\nset up, you can [add Cloud Storage\nbuckets](/load-balancing/docs/https/ext-load-balancer-backend-buckets) to\nit.\n\nFor more information, see [URL map\nconcepts](/load-balancing/docs/url-map-concepts).\n\nLoad balancing for GKE applications\n-----------------------------------\n\nThere are two ways to deploy external Application Load Balancers for GKE clusters:\n\n- **[GKE Gateway\n controller](/kubernetes-engine/docs/concepts/gateway-api).** Supported by the global external Application Load Balancer and the classic Application Load Balancer. For setup instructions, see [Deploying\n gateways](/kubernetes-engine/docs/how-to/deploying-gateways).\n- **[GKE Ingress\n controller](/kubernetes-engine/docs/concepts/ingress-xlb).** Supported by the classic Application Load Balancer and the regional external Application Load Balancer. For setup instructions, see [Configuring Ingress for\n external Application Load Balancers](/kubernetes-engine/docs/how-to/load-balance-ingress).\n\nLoad balancing for Cloud Run, Cloud Run functions, and App Engine applications\n------------------------------------------------------------------------------\n\nYou can use a global external Application Load Balancer as the frontend for your\nCloud Run, Cloud Run functions, and\nApp Engine applications. To set this up, you use a serverless NEG for\nthe load balancer's backend.\n\nThis diagram shows how a serverless NEG fits into the external Application Load Balancer\nmodel.\n[](/static/load-balancing/images/lb-serverless-simple-ext-https.svg) HTTPS load balancing for serverless apps (click to enlarge).\n\nRelated documentation:\n\n- [Serverless NEGs overview](/load-balancing/docs/negs/serverless-neg-concepts)\n- [Setting up an external Application Load Balancer with\n Cloud Run, Cloud Run functions, or\n App Engine](/load-balancing/docs/https/setting-up-https-serverless)\n\nProxying traffic to external backends with internet connectivity\n----------------------------------------------------------------\n\nCloud Load Balancing supports proxying traffic to external backends\noutside Google Cloud. You can use this type of deployment when you want to serve\ncontent from an external backend, but you want your Google Cloud load\nbalancer to be the frontend. The load balancer proxies traffic to your external\nendpoint by using Google's highly reliable backbone network for most of its\njourney, and only hands off to the public internet close to the destination.\n[](/static/load-balancing/images/internet-neg-sample-arch.svg) Internet network endpoint groups in load balancing (click to enlarge).\n\nRelated documentation:\n\n- [Set up a global external Application Load Balancer with an internet\n NEG](/load-balancing/docs/https/setup-global-ext-https-external-backend)\n- [Set up a classic Application Load Balancer with an internet\n NEG](/load-balancing/docs/https/setting-up-https-external-backend-internet-neg)\n\nLoad balancing with hybrid connectivity\n---------------------------------------\n\nCloud Load Balancing supports load-balancing traffic to endpoints that extend\nbeyond Google Cloud, such as on-premises data centers and other public clouds\nthat you can use [hybrid connectivity](/hybrid-connectivity) to reach.\n\nThe following diagram demonstrates a hybrid deployment with a\nglobal external Application Load Balancer.\n[](/static/load-balancing/images/ext-https-hybrid.svg) Hybrid connectivity with an external Application Load Balancer (click to enlarge).\n\nRelated documentation:\n\n- [Hybrid connectivity NEGs overview](/load-balancing/docs/negs/hybrid-neg-concepts)\n- [Setting up an external Application Load Balancer with on-premises or other cloud\n backends](/load-balancing/docs/https/setting-up-ext-https-hybrid)\n\nLoad balancing with Private Service Connect\n-------------------------------------------\n\nYou can use a global external Application Load Balancer to access services that are\npublished using Private Service Connect.\n\nFor more information, see\n[About Private Service Connect backends](/vpc/docs/private-service-connect-backends)."]]
