GCP Cloud Load Balancing 기본 구조 정리: 종류, 구성 요소, 동작 원리

GCP Cloud Load Balancing 기본 구조 정리: 종류, 구성 요소, 동작 원리

2026. 5. 30. 09:28ㆍCloud/GCP

Cloud Load Balancing은 단일 IP 주소 뒤에 여러 백엔드를 배치하고, 트래픽을 분산하는 Google Cloud의 관리형 서비스입니다. 인스턴스 기반이 아니라 소프트웨어 정의 방식이라 사전 워밍업 없이 확장되고, 하나의 글로벌 IP로 여러 리전의 백엔드를 묶을 수 있다는 점이 핵심입니다.

핵심 요약

Cloud Load Balancing은 크게 Application Load Balancer(L7) 와 Network Load Balancer(L4) 두 종류로 나뉩니다.
Network Load Balancer는 다시 Proxy(프록시) 와 Passthrough(통과) 로 나뉩니다.
모든 로드 밸런서는 External/Internal(외부/내부), Global/Regional(글로벌/리전) 축으로 다시 구분됩니다.
구성 요소는 트래픽 진입부(Forwarding Rule, Target Proxy, URL Map)와 처리부(Backend Service, Health Check, 백엔드)로 나눠 이해하면 쉽습니다.
HTTP(S) 트래픽이면 Application Load Balancer, 원본 IP 보존이나 UDP/기타 프로토콜이 필요하면 Passthrough Network Load Balancer를 우선 검토합니다.

1. 왜 로드 밸런서가 필요한가

웹 서비스를 단일 VM 하나로 운영한다고 가정해 보겠습니다. 처음에는 문제가 없지만, 트래픽이 늘면 두 가지 문제가 동시에 발생합니다.

이 VM이 죽으면 서비스 전체가 중단됩니다 (단일 장애점).
VM 한 대의 처리량을 넘는 트래픽은 받을 수 없습니다 (확장 한계).

로드 밸런서는 여러 백엔드 앞에 단일 진입점을 두고, 들어온 요청을 정상 상태인 백엔드로 분산합니다. 백엔드 한 대가 죽으면 Health Check가 이를 감지해 트래픽에서 제외하고, 트래픽이 늘면 백엔드를 추가해 수평 확장합니다.

GCP의 Cloud Load Balancing은 여기에 한 가지를 더합니다. 전 세계에 분산된 Google Front End(GFE)와 단일 Anycast IP를 사용해, 사용자가 어느 지역에서 접속하든 가장 가까운 백엔드로 라우팅하고, 한 리전이 장애가 나면 다른 리전으로 자동 failover합니다. 이 글에서는 이 구조를 종류 → 구성 요소 → 동작 원리 순서로 정리합니다.

2. Cloud Load Balancing이란

Cloud Load Balancing은 Google Cloud의 관리형 로드 밸런싱 서비스입니다. 물리 장비나 VM에 설치하는 방식이 아니라, Google 네트워크에 내장된 소프트웨어 정의 서비스입니다.

핵심 특성을 정리하면 다음과 같습니다.

특성	설명
단일 Anycast IP	하나의 글로벌 IP가 여러 리전의 백엔드를 대표합니다 (글로벌 로드 밸런서)
소프트웨어 정의	인스턴스/장비 기반이 아니므로 사전 워밍업 없이 0에서 풀 트래픽까지 수초 내 확장
자동 멀티 리전 failover	기본 백엔드가 비정상이면 트래픽을 다른 리전 백엔드로 이동
L4 / L7 지원	네트워크·전송 계층(L4)부터 애플리케이션 계층(L7)까지 분산
Google 백본 활용	Premium Tier에서 사용자 트래픽을 Google 글로벌 백본으로 전달

여기서 가장 중요한 개념이 단일 Anycast IP입니다. AWS의 ALB나 Azure의 Load Balancer는 기본적으로 리전 단위 리소스이지만, GCP의 글로벌 로드 밸런서는 하나의 IP로 전 세계 리전의 백엔드를 묶을 수 있습니다. 이 차이가 GCP 로드 밸런싱 설계의 출발점입니다.

Tip
"글로벌 IP 하나로 멀티 리전"은 Premium Network Service Tier에서 동작합니다. Standard Tier는 공용 인터넷을 사용하고 리전 단위로 동작하므로 비용은 낮지만 글로벌 분산 이점은 줄어듭니다. 성능을 우선하면 Premium, 비용을 우선하면 Standard를 검토합니다.

3. 로드 밸런서 종류

Cloud Load Balancing은 처리하는 트래픽 계층에 따라 두 종류로 나뉩니다.

3.1 Application Load Balancer (L7)

HTTP(S) 트래픽을 다루는 프록시 기반 L7 로드 밸런서입니다. URL 경로나 호스트명 같은 애플리케이션 계층 정보로 라우팅을 결정할 수 있습니다.

External: 인터넷에서 들어오는 트래픽을 처리. 배포 모드는 global, regional, classic이 있습니다.
Internal: VPC 내부 또는 연결된 네트워크의 클라이언트만 접근. 배포 모드는 regional, cross-region이 있습니다.

경로 기반 라우팅(예: /api는 API 백엔드로, /static은 버킷으로)이 필요하거나, Cloud CDN·Cloud Armor 연동이 필요하면 Application Load Balancer를 선택합니다.

3.2 Network Load Balancer (L4)

TCP, UDP 등 IP 프로토콜 트래픽을 다루는 L4 로드 밸런서입니다. 다시 두 가지로 나뉩니다.

구분	동작 방식	주요 특징
Proxy Network LB	연결을 로드 밸런서에서 종료 후 백엔드로 재연결	TLS offload 가능, 외부 백엔드(온프레미스 등) 지원, global/regional
Passthrough Network LB	패킷을 그대로 백엔드에 전달 (프록시 아님)	원본 IP 보존, DSR(Direct Server Return), UDP·ESP·ICMP 등 지원, 항상 regional

Passthrough Network LB의 핵심은 원본 클라이언트 IP가 그대로 보존된다는 점입니다. 응답도 로드 밸런서를 거치지 않고 백엔드에서 클라이언트로 직접 나갑니다(DSR). 클라이언트 IP가 중요한 워크로드(예: IP 기반 접근 제어, 게임 서버)나 TCP 외 프로토콜이 필요하면 Passthrough를 선택합니다.

3.3 분류를 정리하는 두 개의 축

종류가 많아 보이지만, 결국 두 개의 축으로 정리됩니다.

축	선택지	판단 기준
External vs Internal	외부(인터넷) / 내부(VPC)	클라이언트가 인터넷에 있는가, VPC 안에 있는가
Global vs Regional	글로벌(여러 리전) / 리전(단일 리전)	백엔드를 여러 리전에 둘 것인가, 단일 리전인가

Tip
classic 모드는 과거 호환을 위해 유지되는 모드입니다. 신규 구성에서는 global external Application Load Balancer(EXTERNAL_MANAGED)를 사용하는 것이 권장됩니다. 기존 classic 리소스도 글로벌 모드로 마이그레이션할 수 있습니다.

4. 핵심 구성 요소

Cloud Load Balancing은 단일 리소스가 아니라 여러 리소스가 조합된 구조입니다. 트래픽이 들어오는 Frontend와 트래픽을 처리하는 Backend로 나눠 보면 이해가 쉽습니다.

4.1 Frontend 구성 요소

구성 요소	역할
Forwarding Rule	IP 주소와 포트를 정의하고, 일치하는 트래픽을 Target Proxy(또는 Backend Service)로 전달
Target Proxy	클라이언트 연결을 종료하고, URL Map을 참조해 요청을 라우팅 (프록시 기반 LB에만 존재)
URL Map	호스트명/경로 기반 라우팅 규칙 (Application Load Balancer에만 존재)

요청 흐름은 Forwarding Rule → Target Proxy → URL Map → Backend Service 순서입니다. Forwarding Rule이 IP/포트의 진입점이라면, URL Map은 "어떤 경로를 어느 백엔드로 보낼지" 결정하는 라우팅 테이블입니다.

4.2 Backend 구성 요소

구성 요소	역할
Backend Service	백엔드 그룹, 분산 방식(balancing mode), 세션 어피니티, Health Check를 묶는 핵심 리소스
Health Check	백엔드의 상태를 주기적으로 점검해 정상 백엔드에만 트래픽 전달
Instance Group / NEG	실제 트래픽을 처리하는 백엔드 (VM 그룹 또는 Network Endpoint Group)

Backend Service가 백엔드 구성의 중심입니다. 어떤 백엔드 그룹에, 어떤 기준(CPU 사용률, 초당 요청 수 등)으로 트래픽을 나눌지, 어떤 Health Check로 상태를 판단할지를 모두 Backend Service가 묶습니다.

NEG(Network Endpoint Group) 는 VM 인스턴스 그룹 외의 백엔드를 추상화한 것입니다. 예를 들어 Serverless NEG는 Cloud Run·App Engine을, Internet NEG는 외부 엔드포인트를 백엔드로 연결합니다.

# gcloud로 본 구성 요소 생성 순서 (global external Application LB 예시)
# 1) Health Check
gcloud compute health-checks create http web-hc --port 80

# 2) Backend Service + Health Check 연결
gcloud compute backend-services create web-backend \
  --protocol HTTP --health-checks web-hc --global

# 3) 인스턴스 그룹을 Backend Service에 추가
gcloud compute backend-services add-backend web-backend \
  --instance-group web-ig --instance-group-zone asia-northeast3-a --global

# 4) URL Map (기본 라우팅)
gcloud compute url-maps create web-map --default-service web-backend

# 5) Target Proxy
gcloud compute target-http-proxies create web-proxy --url-map web-map

# 6) Forwarding Rule (글로벌 IP + 포트)
gcloud compute forwarding-rules create web-fr \
  --global --target-http-proxy web-proxy --ports 80

생성 순서가 백엔드(Health Check → Backend Service)부터 프론트엔드(Forwarding Rule) 방향인 점에 주목합니다. 앞단 리소스가 뒷단 리소스를 참조하기 때문에, 참조 대상을 먼저 만들어야 합니다.

4.3 Health Check의 중요성

Health Check는 부가 기능이 아니라 로드 밸런싱의 전제 조건입니다. 로드 밸런서는 "정상" 판정을 받은 백엔드에만 트래픽을 보냅니다. Health Check 설정이 잘못되면 정상 백엔드가 트래픽에서 제외되거나, 비정상 백엔드로 트래픽이 가는 문제가 생깁니다.

주의
Health Check는 정해진 IP 대역에서 백엔드로 프로브를 보냅니다. 방화벽 규칙에서 이 프로브 대역을 허용하지 않으면 모든 백엔드가 비정상으로 판정되어 트래픽이 전혀 분산되지 않습니다. "로드 밸런서를 만들었는데 503이 나온다"는 문제의 흔한 원인입니다.

5. 동작 원리: 글로벌 External Application LB

가장 대표적인 구성인 글로벌 External Application Load Balancer의 요청 흐름을 보겠습니다.

흐름을 단계별로 설명하면 다음과 같습니다.

서로 다른 지역의 사용자가 동일한 Anycast IP로 접속합니다.
요청은 사용자와 가장 가까운 GFE(Google Front End) 엣지로 라우팅됩니다. GFE는 전 세계 80곳 이상의 위치에 있습니다.
GFE는 Forwarding Rule → Target Proxy에서 연결을 종료하고, URL Map 규칙으로 어느 Backend Service로 보낼지 결정합니다.
Backend Service는 Health Check 결과와 분산 방식을 기준으로, 보통 사용자와 가까운 리전의 정상 백엔드로 요청을 전달합니다.
특정 리전 백엔드가 모두 비정상이 되면, 트래픽은 자동으로 다른 리전의 백엔드로 failover됩니다.

이 구조 덕분에 아시아 사용자는 서울 리전 백엔드로, 유럽 사용자는 벨기에 리전 백엔드로 자동 분산되며, 한 리전이 장애가 나도 단일 IP를 유지한 채 다른 리전이 트래픽을 받습니다. 클라이언트는 어느 백엔드가 응답했는지 알 필요가 없습니다.

6. 어떤 로드 밸런서를 선택할까

선택은 보통 다음 순서로 좁혀집니다.

질문	선택 방향
HTTP(S) 트래픽인가?	예 → Application LB / 아니오 → Network LB
(Network LB) 원본 IP 보존이나 UDP·ESP가 필요한가?	예 → Passthrough / 아니오(TLS offload 등) → Proxy
클라이언트가 인터넷에 있는가?	예 → External / 아니오 → Internal
백엔드를 여러 리전에 둘 것인가?	예 → Global(또는 cross-region) / 아니오 → Regional

대표적인 선택 예시는 다음과 같습니다.

전 세계 사용자 대상 웹/API: global external Application Load Balancer + Cloud CDN + Cloud Armor
단일 리전 내부 마이크로서비스 간 L7 라우팅: regional internal Application Load Balancer
클라이언트 IP 보존이 필요한 TCP/UDP 서비스: external passthrough Network Load Balancer
VPC 내부 DB·내부 API의 L4 분산: internal passthrough Network Load Balancer

Tip
"무엇이 더 좋은가"가 아니라 "트래픽 유형과 클라이언트 위치가 무엇인가"로 접근하는 것이 핵심입니다. HTTP 라우팅·CDN·WAF가 필요하면 Application LB, 원본 IP·저지연·비-HTTP 프로토콜이 핵심이면 Passthrough Network LB로 출발점을 잡습니다.

7. 실무 사용 사례

사례 1: 글로벌 SaaS 웹 서비스 (Global External Application LB)

전 세계 사용자를 대상으로 하는 SaaS를 운영한다고 가정합니다.

global external Application Load Balancer로 단일 IP/도메인을 노출합니다.
Cloud CDN을 연동해 정적 콘텐츠를 엣지에서 캐싱하면, 로드 밸런서를 통과하는 트래픽과 비용이 줄어듭니다.
Cloud Armor를 붙여 DDoS와 애플리케이션 공격(예: SQL Injection 시그니처)을 백엔드 앞단에서 차단합니다.
URL Map으로 /api는 GKE 백엔드로, /는 Cloud Run 서비스(Serverless NEG)로 라우팅합니다.

이 구조를 선택한 이유는 명확합니다. 멀티 리전 백엔드를 단일 IP로 묶어 사용자에게 가까운 곳에서 응답하게 하고, 한 리전 장애 시 자동 failover로 가용성을 확보하기 위해서입니다. CDN과 WAF를 로드 밸런서 계층에 통합하면 백엔드는 비즈니스 로직에만 집중할 수 있습니다.

사례 2: 내부 마이크로서비스 통신 (Internal Application LB)

VPC 내부에서 여러 서비스가 서로 호출하는 환경입니다.

regional internal Application Load Balancer로 서비스 간 L7 라우팅을 제공합니다.
인터넷에 노출되지 않으므로 내부 IP로만 접근 가능합니다.
클라이언트가 다른 리전에도 있다면 forwarding rule에서 global access를 활성화하거나 cross-region 모드를 검토합니다.

사례 3: IP 보존이 필요한 L4 서비스 (Passthrough Network LB)

원본 클라이언트 IP를 백엔드에서 그대로 봐야 하는 경우(예: IP 기반 레이트 리밋, 감사 로그)입니다. Passthrough Network LB는 패킷을 변형하지 않고 전달하므로 백엔드 애플리케이션이 실제 클라이언트 IP를 직접 확인할 수 있습니다. 자세한 백엔드 구성과 세션 어피니티는 별도 글에서 다룹니다.

8. 보안 고려사항

Security Note
로드 밸런서는 인터넷과 백엔드 사이의 경계입니다. 이 계층에서 차단·검사·인증을 처리하면 백엔드를 직접 노출하지 않고도 방어 깊이를 확보할 수 있습니다.

백엔드 직접 노출 금지: 백엔드 VM에 외부 IP를 부여하지 말고, 로드 밸런서를 통해서만 접근하도록 방화벽을 구성합니다. 백엔드는 로드 밸런서/Health Check 프로브 대역만 허용합니다.
Cloud Armor 연동: global external Application Load Balancer와 일부 Network LB는 Cloud Armor로 DDoS 완화와 WAF 정책(IP 차단, 시그니처 기반 필터링)을 적용할 수 있습니다.
TLS 종료와 인증서 관리: HTTPS 로드 밸런서에서 TLS를 종료하고, Google-managed 인증서를 사용하면 갱신 부담을 줄일 수 있습니다.
IAP(Identity-Aware Proxy): External Application Load Balancer 앞단에 IAP를 두면, 네트워크 위치가 아니라 사용자 신원 기반으로 접근을 통제할 수 있습니다 (Zero Trust 접근).
Health Check 방화벽: 프로브 대역을 허용하되, 그 외 소스는 차단해 불필요한 노출을 줄입니다.

9. 비용/운영 고려사항

주의
아래 가격은 us-central1(아이오와) 기준이며 리전별로 다를 수 있습니다. 최신 가격은 Google Cloud 공식 Pricing 페이지에서 확인해야 합니다.

로드 밸런싱 비용은 크게 Forwarding Rule 시간 요금 + 데이터 처리 요금으로 구성됩니다.

항목	요금 (us-central1 기준)
Forwarding Rule (처음 5개)	시간당 $0.025 (5개까지 합산)
Forwarding Rule (추가분)	개당 시간당 $0.01
데이터 처리 (regional, 인바운드/아웃바운드 각각)	GB당 $0.008
Internal Application LB 프록시 인스턴스	인스턴스당 시간당 $0.025 (최소 3개 = 시간당 $0.075)
Health Check (internal fast / premium)	개당 월 $0.50 / $2.00

비용 관점에서 알아둘 점:

대부분의 로드 밸런서는 Forwarding Rule 1개면 충분합니다. 5개까지는 합산 $0.025/시간이므로, 규칙 수보다 데이터 처리량이 비용을 좌우하는 경우가 많습니다.
Internal Application LB는 트래픽이 없어도 리전당 최소 3개의 프록시 인스턴스(시간당 $0.075)가 할당되어 기본 요금이 발생합니다. 소규모 내부 서비스에서는 이 고정비를 고려해야 합니다.
Cloud CDN/Cloud Armor로 캐시 히트나 차단된 트래픽은 로드 밸런서를 통과하지 않으므로, 아웃바운드 데이터 처리 비용을 줄일 수 있습니다.
단일 리전으로 충분하다면 regional external Application Load Balancer + Standard Tier가 아웃바운드 데이터 전송 비용 측면에서 더 저렴한 선택지가 될 수 있습니다.

운영 관점:

리소스가 여러 개로 분리되어 있어(Forwarding Rule, Proxy, URL Map, Backend Service, Health Check) 삭제 시 역순으로 정리해야 의존성 오류가 나지 않습니다.
Health Check 실패는 가장 흔한 운영 이슈입니다. 방화벽 프로브 대역 허용, 백엔드 포트/경로 일치를 먼저 확인합니다.

10. 자주 하는 실수

Health Check 프로브 대역을 방화벽에서 막는 것: 모든 백엔드가 비정상으로 판정되어 트래픽이 분산되지 않습니다. 503/502의 흔한 원인입니다.
트래픽 유형을 고려하지 않고 로드 밸런서를 고르는 것: UDP나 원본 IP 보존이 필요한데 Application Load Balancer를 선택하면 요구사항을 충족할 수 없습니다. 먼저 L4/L7과 프로토콜을 확정해야 합니다.
글로벌이 항상 좋다고 가정하는 것: 단일 리전 서비스에 글로벌 구성을 쓰면 불필요한 복잡도와 비용이 생깁니다. 백엔드가 한 리전이면 regional 구성이 더 단순하고 저렴할 수 있습니다.
백엔드 VM에 외부 IP를 직접 부여하는 것: 로드 밸런서를 우회한 직접 접근 경로가 생겨 보안이 약해집니다. 백엔드는 로드 밸런서를 통해서만 접근하도록 구성합니다.
Internal Application LB의 최소 프록시 비용을 간과하는 것: 트래픽이 거의 없어도 리전당 최소 3개 프록시 인스턴스 요금이 발생합니다.
classic 모드로 신규 구성하는 것: 신규 기능은 global(EXTERNAL_MANAGED) 모드에서 제공됩니다. 새로 구성한다면 글로벌 모드를 우선 검토합니다.

11. 정리

Cloud Load Balancing은 Application(L7)과 Network(L4) 두 종류로 나뉘고, Network LB는 다시 Proxy와 Passthrough로 갈립니다.
모든 로드 밸런서는 External/Internal, Global/Regional 축으로 구분됩니다.
구성은 Frontend(Forwarding Rule → Target Proxy → URL Map)와 Backend(Backend Service → Health Check → 백엔드)로 나눠 이해합니다.
글로벌 External Application LB는 단일 Anycast IP와 GFE로 멀티 리전 분산과 자동 failover를 제공합니다.
선택은 트래픽 유형(L4/L7) → 프로토콜·IP 보존 → 클라이언트 위치 → 리전 범위 순으로 좁혀갑니다.
비용은 Forwarding Rule 시간 요금과 데이터 처리 요금이 중심이며, Internal Application LB의 최소 프록시 요금에 주의합니다.

AWS VPC란 무엇인가: Subnet, Route Table, Internet Gateway 개념 정리

참고 문서

'Cloud > GCP' 카테고리의 다른 글

GCP GKE 기본 구조: Autopilot vs Standard, Node Pool, Networking (0)	2026.06.08
GCP Cloud Storage 종류와 선택 기준: Standard, Nearline, Coldline, Archive (0)	2026.06.07
GCP Cloud Run vs Cloud Functions 차이: 서버리스 컴퓨팅 선택 기준 (0)	2026.06.06
GCP IAM 기본 개념: Role, Principal, Policy 이해하기 (0)	2026.05.30
GCP VPC란 무엇인가: Subnet, Firewall Rule, Route 개념 정리 (0)	2026.05.30

wero90