1. Google Cloud 로드 밸런서 이해: 정의, 구성 요소, 구성 방법
클라우드 인프라를 구축하거나 API Gateway를 배포하는 과정에서 반드시 만나게 되는 개념이 있습니다. 바로 로드 밸런서(Load Balancer)입니다. 이 글에서는 로드 밸런서란 무엇인지, Google Cloud에서는 어떤 구성 요소로 이루어져 있는지, 그리고 실제로 HTTPS 로드 밸런서를 어떻게 구성하는지를 비유와 명확한 단계별 설명, 실제 명령어 및 참고 링크와 함께 정리합니다.
(이 글은 구글 클라우드의 “API 게이트웨이용 부하 분산 시작하기”, https://cloud.google.com/api-gateway/docs/gateway-serverless-neg?hl=ko에 바탕하여 작성되었습니다. 좀 더 자세히 알고 싶으시면 위의 링크 내용을 참고하시기 바랍니다.)
로드 밸런서가 필요한 이유는 아래와 같습니다.
1. 여러 서버에 트래픽을 고르게 분산하기 위해
· 사용자가 몰리면 한 서버에만 요청이 집중되어 과부하가 발생할 수 있습니다. (여러 백엔드 인스턴스에 자동으로 부하 분산)
· 로드 밸런서는 요청을 여러 서버로 자동으로 나눠 부하를 분산시킵니다. (백엔드를 수평 확장하면 로드 밸런서가 자동 분산)
2. 서비스 가용성을 높이기 위해
· 서버 하나가 다운되더라도 다른 서버가 계속 동작하도록 하여 중단 없는 서비스를 제공합니다.
· 로드 밸런서는 정상 상태의 백엔드만 사용합니다 (헬스 체크 기반).
3. 글로벌 사용자에게 빠른 응답 제공
· 사용자와 가까운 리전의 서버로 트래픽을 유도해 **지연(latency)**을 줄일 수 있습니다.
· Google Cloud에서는 글로벌 로드 밸런서가 지원됩니다.
4. SSL 종료 및 보안 처리
· HTTPS 암호화를 **로드 밸런서 앞단에서 처리(SSL 종료)**함으로써 백엔드의 부담을 줄이고, 관리도 단순화됩니다.
5. 도메인 기반, 경로 기반 라우팅 지원
· /api는 Cloud Run, /static은 Cloud Storage 등 다양한 백엔드에 세분화된 라우팅이 가능합니다.
1.1 Google Cloud의 로드 밸런서 구성 요소
Google Cloud에서 로드 밸런서는 다음과 같은 요소들로 구성됩니다:
구성 요소
|
설명
|
Global Forwarding Rule
|
외부 IP와 포트를 설정하고, 프록시로 요청을 전달합니다
|
Target HTTPS Proxy
|
SSL 인증서로 HTTPS 요청을 해독하고, URL 맵으로 전달합니다
|
SSL Certificate
|
도메인의 신원을 증명하고 암호화 통신을 지원합니다
|
URL Map
|
요청의 Host/Path에 따라 백엔드 서비스로 라우팅합니다
|
Backend Service
|
실제로 요청을 처리할 Cloud Run, App Engine 등으로 연결됩니다
|
NEG (Network Endpoint Group)
|
백엔드와 연결되는 실질적인 엔드포인트입니다
|
이 모든 요소가 하나로 모여 하나의 로드 밸런서를 구성합니다. 위의 구성요소들을 그림으로 표현하면 아래와 같습니다.

1.2 로드 밸런서에 대한 비유적 설명
아래는 해당 로드 밸런서의 각 구성 요소에 대해서 사무실의 직원을 찾아가는 경우로 비유한 설명입니다:
구성 요소 (Component)
|
역할 (비유적 설명)
|
Forwarding Rule
|
거리 주소 (IP + 포트) — 어디로 오는지 지정하는 위치
|
Target HTTPS Proxy
|
보안 게이트 — TLS 핸드셰이크를 처리하는 입구 보안요원
|
SSL Certificate
|
출입증 — 암호화된 입장을 허용하는 보안 인증 키
|
URL Map
|
안내 데스크 — 어디 부서로 가야 할지 알려주는 리셉션
|
Backend Service
|
부서 — 실제 요청을 담당할 API, 저장소 등의 기능 단위
|
NEG (Cloud Run 등)
|
실제 직원 — 사용자의 요청을 실제로 처리하는 시스템
|
2. 각 구성 요소에 대한 설명
위에서 각 구성요소들에 대해서 대략적으로 역할을 알아보았으니, 지금부터는 좀 더 자세히 알아보겠습니다.
2.1 전역 포워딩 룰(Global Forwarding Rule)이란?
전역(Global) 포워딩 룰은 전 세계 어디서 들어오는 요청이든, 어떤 IP와 포트로 들어왔는지를 기준으로 요청을 어떤 프록시(HTTPS/HTTP/SSL/UDP 등) 에 전달할지를 정의하는 구성 요소입니다. 포워딩 룰의 구성요소는 아래와 같습니다.
IP 주소
|
35.241.13.99 (Google에서 자동 할당되거나 사용자 예약 가능)
|
포트 번호
|
443 (HTTPS), 80 (HTTP) 등
|
프로토콜
|
HTTPS / HTTP / TCP / UDP
|
대상(Target)
|
Target HTTPS Proxy, Target HTTP Proxy, Target SSL Proxy 등
|
로드 밸런서의 위치
|
전역(Global) – 전 세계에서 동일한 IP로 접근 가능
|
2.2 HTTPS 프록시란?
HTTPS 프록시(Target HTTPS Proxy) 는 클라이언트(브라우저 등)가 보낸 HTTPS 요청을 처리하는 중간 서버로서,
1. SSL 인증서를 이용해 TLS 연결을 처리하고 (SSL 종료)
2. URL 맵을 기반으로 요청을 백엔드 서비스로 라우팅합니다.
그럼 여기서 SSL종료란 무엇인가 알아보겠습니다. HTTPS 해독(SSL 종료)란,
클라이언트와 서버 사이의 암호화된 HTTPS 통신을 중간 서버(예: 로드 밸런서 또는 HTTPS 프록시)에서 복호화(decrypt) 하는 것을 의미합니다.
서버와 클라이언트 간의 요청 흐름을 아래의 예시로 들어보겠습니다.
1. 클라이언트(브라우저 등)가 https://example.com에 접속
2. 클라이언트는 먼저 서버의 SSL 인증서를 받아서 그 안에 들어있는 공개키 로 전송을 암호화하고 이후 전송부터 암호화된 연결(TLS)을 시도
3. HTTPS 프록시는 이 요청을 받아서, 자신이 보유한 SSL 인증서 + 개인키를 사용하여 암호화된 데이터를 복호화 (이를 SSL 종료라고 합니다.)
4. 복호화된 평문 HTTP 요청을 백엔드 서비스로 전달
그럼 이때 인증서는 어떤 역할을 할까요?
공개키 인증서 (certificate)
|
클라이언트에 제공됨, 서버의 신원을 보장함
|
개인키 (private key)
|
서버(또는 프록시)만 보유, 클라이언트가 보낸 암호를 해독할 수 있음
|
둘의 조합
|
TLS 핸드셰이크 후, 암호화된 데이터를 복호화 가능
|
2.3 URL 맵이란?
URL 맵(URL Map)은 특정 조건(도메인, 경로 등)에 따라 요청을 어떤 백엔드 서비스로 보낼지 정의하는 경로 설정입니다.
작동 방식을 요약하면 아래와 같습니다. 예를 들어 서버에 backend-service-A와 backend-service-B라는 두 개의 서비스가 있고, 각각을 /hello와 /images/에 연결하고 싶다면,
1. 클라이언트 요청 발생
→ 예: https://example.com/hello
2. 로드 밸런서가 URL 맵을 참조
o 이 요청이 어느 도메인인지 (host 기반, example.com)
o 어느 경로인지 (path 기반, /hello 또는 /images/*)
3. URL 맵의 규칙에 따라 백엔드 결정
o /hello → backend-service-A
o /images/** → backend-service-B
o 나머지 → 기본 백엔드 (defaultService)
2.4 DNS 설정이란?
도메인의 이름(example.com)을 특정 IP 주소(Google Cloud에서 발급된 외부 IP) 로 연결하는 설정입니다.
필요한 DNS 레코드 종류
레코드 종류
|
설명
|
A 레코드
|
example.com → 35.241.13.99 같은 IPv4 주소로 연결
|
AAAA 레코드 (선택)
|
example.com → IPv6 주소로 연결 (일반적으론 생략 가능)
|
CNAME 레코드
|
www.example.com → example.com에 연결 (서브도메인 설정에 유용, 예를 들어 hello.example.com 등도 가능)
|
DNS 설정은 google cloud가 아니라 도메인을 관리하는 도메인 제공업체의 홈페이지에서 가능합니다. (DNS 설정 방법은 별도의 글로 좀 더 상세히 설명합니다.)
2.5 NEG는 무엇인가?
Network Endpoint Group (NEG)는 IP 주소 + 포트 쌍의 집합입니다. 로드 밸런서는 NEG를 통해 Cloud Run, App Engine, Cloud Functions, GCE 인스턴스 등의 백엔드 리소스에 요청을 전달합니다. NEG는 단순히 백엔드 리소스를 직접 가리키지 않고, 그 자원에 접근할 수 있는 "접점" 리스트를 정의한 것입니다.
NEG의 종류에는 아래와 같은 것들이 있습니다.
유형
|
설명
|
Zonal NEG
|
Google Compute Engine의 Virtual Machine의 IP/포트를 직접 지정하는 방식
|
Internet NEG
|
외부 IP 주소를 포함하는 NEG (Google 외부 자원)
|
Serverless NEG
|
Cloud Run, Cloud Functions, App Engine 등 서버리스 백엔드
|
Hybrid NEG (프리뷰)
|
온프레미스 리소스와 연결 (Network Connectivity Center와 통합)
|
NEG가 필요한 이유는 아래와 같습니다.
Google Cloud의 HTTPS Load Balancer는 IP와 포트를 가지는 전통적인 백엔드(인스턴스 그룹) 외에도 다음을 백엔드로 지원합니다:
· Cloud Run
· Cloud Functions
· App Engine
· 외부 HTTP 서비스
이러한 백엔드는 IP/포트가 없으므로, NEG를 통해 추상화된 연결 지점을 생성하는 것입니다.
3. 로드 밸런서 구성하기 (HTTPS 기준)
이제 위의 구성 요소를 바탕으로 구글 클라우드에서 실제 로드 밸런서를 설정하는 방법을 단계별로 설명합니다. 아래의 명령들은 구글 클라우드의 터미널 화면에서 실행합니다. 각 단계에서 생성된 구성요소들은 굵게(bold체) 표시하였습니다.
🔹 1단계: Serverless NEG 생성 (API Gateway용)
gcloud beta compute network-endpoint-groups create api-gateway-neg \
--region=us-central1 \
--network-endpoint-type=serverless \
--serverless-deployment-platform=apigateway.googleapis.com \
--serverless-deployment-resource=projects/PROJECT_ID/locations/global/apis/API_NAME/gateways/GATEWAY_NAME
위의 명령에서 사용자가 구글 클라우드에서 PROJECT_ID, API_NAME, GATEWAY_NAME 등을 이미 만들었다고 가정합니다. 위의 명령으로 생성한 NEG의 이름은 api-gateway-neg입니다.
🔹 2단계: 백엔드 서비스 생성 및 NEG 연결
gcloud compute backend-services create api-backend --global
gcloud compute backend-services add-backend api-backend \
--global \
--network-endpoint-group=api-gateway-neg \
--network-endpoint-group-region=us-central1
그런 다음 위의 명령으로 api-backend라는 이름의 backend service를 생성하여 NEG(api-gateway-neg)와 연결합니다.
🔹 3단계: URL 맵 생성
gcloud compute url-maps create api-url-map \
--default-service=api-backend
그런 다음, api-url-map이라는 url map을 생성하고 api-backend와 연결합니다.
이후 path나 host 규칙을 추가합니다.
gcloud compute url-maps add-path-matcher api-url-map \
--default-service= api-backend \
--path-matcher-name=example-path-matcher \
--path-rules="/hello=my-backend-hello, /images/*=my-backend-images"
위의 명령으로 api-url-map이라는 url map에 example-path-matcher라는 이름의 path matcher를 만듭니다. 이 때 example-path-matcher에는 두 개의 규칙이 있습니다. /hello 경로에는 my-backend-hello라는 서비스를, /images/* 경로에는 my-backend-images라는 서비스로 연결합니다.
🔹 4단계: SSL 인증서 생성 (Google-managed)
gcloud compute ssl-certificates create ssl-certificate-example \
--domains="example.com, www.example.com" \
--global
그 다음 프록시에서 사용할 인증서를 만듭니다. 여기서 인증서의 이름은 ssl-certificate-exmple입니다.
📌 DNS에서 위의 두 도메인이 Google Cloud의 외부 IP를 가리키도록 A 레코드 설정이 되어 있어야 합니다.
인증서가 만들어지는 데에는 시간이 걸리는데 인증서 작성 상태를 확인하려면 아래의 명령을 사용합니다.
gcloud compute ssl-certificates describe ssl-certificate-example --global
✅ status: ACTIVE가 되면 성공입니다.
🔹 5단계: Target HTTPS Proxy 생성
gcloud compute target-https-proxies create api-https-proxy \
--url-map=api-url-map \
--ssl-certificates=ssl-certificate-example
그 다음 https proxy를 생성하여 url map(api-url-map)에 연결하고, 앞에서 만든 인증서를 추가해 줍니다.
🔹 6단계: 글로벌 포워딩 룰 생성
gcloud compute forwarding-rules create api-forwarding-rule \
--address=YOUR_EXTERNAL_IP \
--global \
--target-https-proxy=api-https-proxy \
--ports=443
그런 다음 포워딩 룰을 작성하고, 이것을 https proxy (api-https-proxy)에 연결해 줍니다. 이 때 YOUR_EXTERNAL_IP는 사용자가 https 프록시를 만들 때 자동 생성된 외부 IP주소이며, 외부에서 https://example.com 접속 시 이 주소로 요청이 도착합니다..
'GreenTam의 생각' 카테고리의 다른 글
직장인으로서의 단상 3 (4) | 2025.07.03 |
---|---|
Do-It-Yourself (DIY) 전자회로 1: 라즈베리 파이 3 (3) | 2025.06.30 |
안드로이드 & iOS 앱 제작 1 (3) | 2025.06.27 |
Do-It-Yourself (DIY) 전자회로 1: 라즈베리 파이 2 (1) | 2025.05.17 |
Do-It-Yourself (DIY) 전자회로 1: 라즈베리 파이 1 (4) | 2025.05.11 |