GCP Load Balancer 완전 비교 가이드

Overview

클라우드 환경에서 로드밸런서는 애플리케이션의 가용성과 성능을 보장하는 핵심 구성 요소이다. Google Cloud Platform(GCP)은 다양한 로드밸런싱 솔루션을 제공하여 각기 다른 요구사항과 아키텍처에 최적화된 선택지를 제공한다.

 

최근 몇 년간 GCP의 로드밸런서 서비스들은 크게 발전했다. 특히 HTTP(S) Load Balancer의 경우 Certificate Manager를 통한 여러 도메인 지원이 강화되었고, SSL 인증서 관리 방식도 다양해졌다. Certificate Map 기능을 통해 도메인별로 다른 인증서를 할당할 수 있게 되어, 과거의 제약이 크게 완화되었다.

 

하지만 GKE 환경에서는 여전히 중요한 제약사항이 있습니다. GKE ManagedCertificate는 하나의 인증서당 하나의 도메인만 지원하며, AWS ALB Ingress Group과 같은 기능이 없어 하나의 Ingress가 하나의 Load Balancer를 생성한다.

 

이 글에서는 GCP의 주요 로드밸런서 유형들을 심층 분석하고, 각각의 특성과 적절한 사용 사례를 살펴보겠습니다. 또한 실제 운영 환경에서 활용할 수 있는 Terraform 코드와 GKE Ingress 구성 예제, 그리고 최적화 전략도 함께 제시하겠다.

 

 

 

 

📅 관련 글

2023.04.06 - [GCP] - GCP란? - 서비스 계정 & Project 생성 / SDK(gcloud) 설치

2023.04.06 - [GCP] - GCP IAM이란?

2023.04.12 - [GCP] - GCP - SDK(gcloud) 계정 2개 등록하기

2023.05.05 - [GCP] - GCP vs AWS 리소스 비교

2023.05.19 - [GCP] - GCP BigQuery란? & Data Warehouse

2023.09.23 - [GCP] - BigQuery와 DataFlow를 활용한 Data ETL(GCP)

2023.10.03 - [GCP] - Shared VPC를 사용하여 GKE 클러스터 생성시 IAM 설정

2023.12.18 - [GCP] - GCP를 활용한 데이터 자동화(MongoDB, CloudSQL, GA, Dune)

2024.01.20 - [GCP] - Terraform 으로 GCS 생성후 Cloud CDN 생성(GCP)

2024.03.04 - [GCP] - GCP에서 딥러닝을 위한 GPU VM 서버 만들기(GCP)

2024.04.24 - [Migration] - AWS에서 GCP로 마이그레이션하는 방법 및 고려사항

 

 

 

 

---

 

 

GCP Load Balancer 유형별 특성 분석

 

 

 

HTTP(S) Load Balancer

HTTP(S) Load Balancer는 GCP의 가장 강력하고 유연한 로드밸런싱 솔루션이다. 글로벌 범위에서 동작하며, 레이어 7(애플리케이션 계층)에서 트래픽을 처리한다.

 

 

주요 특징

• 글로벌 애니캐스트 IP: 전 세계 어디서나 가장 가까운 백엔드로 라우팅
• Cloud CDN 통합: 정적 콘텐츠 캐싱으로 성능 향상
• URL 기반 라우팅: 경로, 헤더, 쿠키에 따른 정교한 트래픽 분산
• SSL 터미네이션: Google-managed 또는 사용자 관리 인증서 지원

 

 

SSL 인증서 관리 옵션

 

 

1. Certificate Manager (권장 - 여러 도메인 가능)

# Certificate Manager를 통한 Google 관리형 인증서 (여러 도메인 지원)
resource "google_certificate_manager_certificate" "default" {
  name        = "example-cert"
  description = "Multi-domain certificate"
  scope       = "DEFAULT"

  managed {
    domains = [
      "example.com",
      "www.example.com", 
      "api.example.com"
    ]
    dns_authorizations = [
      google_certificate_manager_dns_authorization.example.id,
      google_certificate_manager_dns_authorization.www.id,
      google_certificate_manager_dns_authorization.api.id
    ]
  }
}

# DNS 승인 (각 도메인별)
resource "google_certificate_manager_dns_authorization" "example" {
  name   = "example-dns-auth"
  domain = "example.com"
}

resource "google_certificate_manager_dns_authorization" "www" {
  name   = "www-dns-auth"
  domain = "www.example.com"
}

resource "google_certificate_manager_dns_authorization" "api" {
  name   = "api-dns-auth"
  domain = "api.example.com"
}

# Certificate Map
resource "google_certificate_manager_certificate_map" "default" {
  name        = "cert-map"
  description = "Multi-domain certificate mapping"
}

resource "google_certificate_manager_certificate_map_entry" "default" {
  name         = "cert-map-entry"
  map          = google_certificate_manager_certificate_map.default.name
  certificates = [google_certificate_manager_certificate.default.id]
  hostname     = "example.com"
}

 

 

 

2. Compute Engine Managed SSL (여러 도메인 가능)

resource "google_compute_managed_ssl_certificate" "default" {
  name = "example-cert"
  managed {
    domains = [
      "example.com",
      "www.example.com",
      "api.example.com"
    ]
  }
}

 

 

 

3. GKE ManagedCertificate (도메인당 하나씩 제한)

# 각 도메인마다 별도의 ManagedCertificate 필요
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: main-cert
spec:
  domains:
    - example.com

---
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: api-cert
spec:
  domains:
    - api.example.com

 

 

 

4. GKE에서 Certificate Manager 사용 (새로운 방식)

 

Certificate Manager는 GKE에서도 사용할 수 있으며, 더 유연한 인증서 관리를 제공한다.

 

Certificate Manager 기반 GKE 인프라

# GKE용 Certificate Manager 인증서 생성
resource "google_certificate_manager_certificate" "gke_cert" {
  name        = "gke-certificate"
  description = "Certificate for GKE services"
  scope       = "DEFAULT"

  managed {
    domains = [
      "example.com",
      "api.example.com",
      "admin.example.com"
    ]
    dns_authorizations = [
      google_certificate_manager_dns_authorization.example.id,
      google_certificate_manager_dns_authorization.api.id,
      google_certificate_manager_dns_authorization.admin.id
    ]
  }
}

# Certificate Map 생성
resource "google_certificate_manager_certificate_map" "gke_cert_map" {
  name        = "gke-cert-map"
  description = "Certificate map for GKE"
}

# Certificate Map Entry
resource "google_certificate_manager_certificate_map_entry" "main_entry" {
  name         = "main-cert-entry"
  map          = google_certificate_manager_certificate_map.gke_cert_map.name
  certificates = [google_certificate_manager_certificate.gke_cert.id]
  hostname     = "example.com"
}

resource "google_certificate_manager_certificate_map_entry" "api_entry" {
  name         = "api-cert-entry"
  map          = google_certificate_manager_certificate_map.gke_cert_map.name
  certificates = [google_certificate_manager_certificate.gke_cert.id]
  hostname     = "api.example.com"
}

 

 

 

GKE Ingress에서 Certificate Manager 사용

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cert-manager-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "gke-static-ip"
    kubernetes.io/ingress.class: "gce"
    # Certificate Manager 사용 (ManagedCertificate 대신)
    networking.gke.io/certificate-map: "gke-cert-map"
    networking.gke.io/v1beta1.FrontendConfig: "frontend-config"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80
      - path: /static/*
        pathType: Prefix
        backend:
          service:
            name: static-service
            port:
              number: 80
  - host: api.example.com
    http:
      paths:
      - path: /v1/*
        pathType: Prefix
        backend:
          service:
            name: api-v1-service
            port:
              number: 8080
      - path: /v2/*
        pathType: Prefix
        backend:
          service:
            name: api-v2-service
            port:
              number: 8080

 

 

 

5. GKE Ingress에서 기존 ManagedCertificate 사용

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/managed-certificates: "main-cert,api-cert"
spec:
  rules:
  - host: example.com
    # 웹사이트 라우팅
  - host: api.example.com
    # API 라우팅

 

 

 

 

인증서 관리 방식 비교

방식	도메인 수	인증 방법	관리 방식	권장 사용처
Certificate Manager	여러 도메인	DNS 승인	Certificate Map	복잡한 도메인 구성
Compute Engine Managed SSL	여러 도메인	HTTP 승인	Terraform	Compute Engine 환경
GKE ManagedCertificate	도메인당 1개	HTTP 승인	Kubernetes	단순한 GKE 환경

 

 

 

 

 

 

Network Load Balancer (TCP/UDP)

Network Load Balancer는 레이어 4에서 동작하는 고성능 로드밸런서로, TCP 및 UDP 트래픽을 처리한다.

 

 

주요 특징

• 초고성능: 레이어 4 처리로 낮은 지연시간 제공
• 원본 IP 보존: 클라이언트의 실제 IP 주소를 백엔드에 전달
• 프로토콜 지원: TCP, UDP, ESP, GRE, ICMP 등 다양한 프로토콜
• 지역적 로드밸런싱: 리전 내에서만 동작

 

적합한 사용 사례

• 게임 서버
• IoT 디바이스 통신
• VPN 게이트웨이
• 실시간 스트리밍 서비스

 

 

 

 

 

Internal Load Balancer

Internal Load Balancer는 VPC 내부 트래픽을 위한 로드밸런서로, 외부에서 직접 접근할 수 없는 내부 서비스들 간의 통신을 담당한다.

 

 

주요 특징

• 내부 전용: VPC 내부에서만 접근 가능한 프라이빗 IP 사용
• 마이크로서비스 아키텍처 지원: 서비스 간 통신 최적화
• 고가용성: 여러 가용 영역에 걸친 백엔드 분산
• 비용 효율성: 외부 IP 사용료 없음

 

 

 

GKE와 GCP Load Balancer의 차이점

GCP에는 두 가지 주요 로드밸런싱 환경이 있다.

1. Compute Engine 기반 Load Balancer: Terraform으로 직접 관리
2. GKE Ingress: Kubernetes 리소스로 관리되며 내부적으로 GCP Load Balancer 생성

 

 

중요한 제약사항

• GKE ManagedCertificate: 하나의 인증서당 하나의 도메인만 가능
• AWS ALB Ingress Group과 같은 기능은 GKE에 없음: 하나의 Ingress = 하나의 Load Balancer
• 여러 서비스를 하나의 Load Balancer로 처리하려면: 하나의 Ingress에서 여러 rule 정의 필요

 

 

 

 

 

GKE Ingress 실전 예제

 

 

실제 운영 환경에서의 GKE Ingress 구성

# 1. 각 도메인별 ManagedCertificate 생성
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: somaz-main-cert
spec:
  domains:
    - somaz.link

---
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: somaz-api-cert
spec:
  domains:
    - api.somaz.link

---
# 2. FrontendConfig (선택적 - 보안 헤더, 리다이렉트 등)
apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: somaz-frontend-config
spec:
  redirectToHttps:
    enabled: true
    responseCodeName: MOVED_PERMANENTLY_DEFAULT
  sslPolicy: somaz-ssl-policy

---
# 3. 통합 Ingress 구성
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: somaz-ingress
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "somaz-gke-lb-ip"
    networking.gke.io/managed-certificates: "somaz-main-cert,somaz-api-cert"
    kubernetes.io/ingress.class: "gce"
    networking.gke.io/v1beta1.FrontendConfig: "somaz-frontend-config"
    cloud.google.com/backend-config: '{"default": "somaz-backend-config"}'
spec:
  rules:
  # 메인 웹사이트
  - host: somaz.link
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80
      - path: /static/*
        pathType: Prefix
        backend:
          service:
            name: static-service
            port:
              number: 80
  
  # API 서비스
  - host: api.somaz.link
    http:
      paths:
      - path: /v1/*
        pathType: Prefix
        backend:
          service:
            name: api-v1-service
            port:
              number: 8080
      - path: /v2/*
        pathType: Prefix
        backend:
          service:
            name: api-v2-service
            port:
              number: 8080
      - path: /health
        pathType: Exact
        backend:
          service:
            name: health-service
            port:
              number: 8080

---
# 4. BackendConfig for CDN and optimization
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: somaz-backend-config
spec:
  cdn:
    enabled: true
    cachePolicy:
      includeHost: true
      includeProtocol: true
      includeQueryString: false
    negativeCaching: true
    negativeCachingPolicy:
    - code: 404
      ttl: 120
  connectionDraining:
    drainingTimeoutSec: 60
  healthCheck:
    checkIntervalSec: 10
    timeoutSec: 5
    healthyThreshold: 2
    unhealthyThreshold: 3
    type: HTTP
    requestPath: /health
    port: 8080

 

 

 

 

 

Terraform으로 구현하는 GKE 지원 인프라

 

 

GKE Ingress를 위한 기반 인프라 구성

# GKE Ingress에서 사용할 글로벌 정적 IP
resource "google_compute_global_address" "gke_ingress_ip" {
  name = "somaz-gke-lb-ip"
}

# SSL Policy 정의 (TLS 버전 및 암호화 설정)
resource "google_compute_ssl_policy" "modern_tls" {
  name    = "somaz-ssl-policy"
  profile = "MODERN"
  min_tls_version = "TLS_1_2"
}

# 출력 값으로 Kubernetes에서 사용할 정보 제공
output "gke_ingress_ip" {
  description = "Static IP for GKE Ingress"
  value       = google_compute_global_address.gke_ingress_ip.address
}

output "ssl_policy_name" {
  description = "SSL Policy name for FrontendConfig"
  value       = google_compute_ssl_policy.modern_tls.name
}

 

 

Compute Engine 기반 완전한 Load Balancer 구현

# 글로벌 IP 주소
resource "google_compute_global_address" "main_lb_ip" {
  name = "main-lb-global-ip"
}

# SSL 인증서 (여러 도메인 지원)
resource "google_compute_managed_ssl_certificate" "main_ssl_cert" {
  name = "main-ssl-certificate"
  managed {
    domains = [
      "example.com",
      "www.example.com",
      "api.example.com",
      "admin.example.com"
    ]
  }
}

# 인스턴스 그룹
resource "google_compute_instance_group" "web_servers" {
  name        = "web-server-group"
  description = "Instance Group for web servers"
  zone        = "${var.region}-a"
  instances   = [google_compute_instance.web_server.self_link]

  named_port {
    name = "http"
    port = 80
  }

  named_port {
    name = "https"
    port = 443
  }

  named_port {
    name = "api"
    port = 8080
  }
}

# Health Check for Web Service
resource "google_compute_health_check" "web_health_check" {
  name               = "web-service-health-check"
  check_interval_sec = 5
  timeout_sec        = 3
  healthy_threshold  = 2
  unhealthy_threshold = 3

  http_health_check {
    port         = 80
    request_path = "/health"
  }
}

# Health Check for API Service
resource "google_compute_health_check" "api_health_check" {
  name               = "api-service-health-check"
  check_interval_sec = 5
  timeout_sec        = 3
  healthy_threshold  = 2
  unhealthy_threshold = 3

  http_health_check {
    port         = 8080
    request_path = "/api/health"
  }
}

# Backend Service for Web
resource "google_compute_backend_service" "web_backend_service" {
  name        = "web-backend-service"
  description = "Backend Service for Web Application"
  protocol    = "HTTP"
  port_name   = "http"
  timeout_sec = 30

  backend {
    group = google_compute_instance_group.web_servers.self_link
  }

  health_checks = [google_compute_health_check.web_health_check.self_link]

  # CDN 활성화 (정적 콘텐츠용)
  enable_cdn = true
  cdn_policy {
    cache_mode  = "CACHE_ALL_STATIC"
    default_ttl = 3600
    max_ttl     = 86400
  }
}

# Backend Service for API
resource "google_compute_backend_service" "api_backend_service" {
  name        = "api-backend-service"
  description = "Backend Service for API"
  protocol    = "HTTP"
  port_name   = "api"
  timeout_sec = 30

  backend {
    group = google_compute_instance_group.web_servers.self_link
  }

  health_checks = [google_compute_health_check.api_health_check.self_link]

  # API는 CDN 비활성화
  enable_cdn = false
}

# URL Map (메인 라우팅 설정)
resource "google_compute_url_map" "main_url_map" {
  name            = "main-url-map"
  description     = "Main URL map for multi-domain routing"
  default_service = google_compute_backend_service.web_backend_service.self_link

  # API 도메인 라우팅
  host_rule {
    hosts        = ["api.example.com"]
    path_matcher = "api-matcher"
  }

  path_matcher {
    name            = "api-matcher"
    default_service = google_compute_backend_service.api_backend_service.self_link

    path_rule {
      paths   = ["/v1/*"]
      service = google_compute_backend_service.api_backend_service.self_link
    }

    path_rule {
      paths   = ["/v2/*"]
      service = google_compute_backend_service.api_backend_service.self_link
    }
  }

  # Admin 도메인 라우팅
  host_rule {
    hosts        = ["admin.example.com"]
    path_matcher = "admin-matcher"
  }

  path_matcher {
    name            = "admin-matcher"
    default_service = google_compute_backend_service.web_backend_service.self_link
  }

  depends_on = [
    google_compute_backend_service.web_backend_service,
    google_compute_backend_service.api_backend_service
  ]
}

# HTTPS Target Proxy
resource "google_compute_target_https_proxy" "main_https_proxy" {
  name             = "main-https-proxy"
  description      = "HTTPS proxy for main load balancer"
  url_map          = google_compute_url_map.main_url_map.self_link
  ssl_certificates = [google_compute_managed_ssl_certificate.main_ssl_cert.self_link]
}

# HTTPS Global Forwarding Rule
resource "google_compute_global_forwarding_rule" "main_https_forwarding_rule" {
  name       = "main-https-forwarding-rule"
  target     = google_compute_target_https_proxy.main_https_proxy.self_link
  ip_address = google_compute_global_address.main_lb_ip.address
  port_range = "443"
}

# HTTP to HTTPS Redirect URL Map
resource "google_compute_url_map" "http_to_https_redirect" {
  name = "http-to-https-redirect"
  
  default_url_redirect {
    https_redirect         = true
    redirect_response_code = "MOVED_PERMANENTLY_DEFAULT"
    strip_query           = false
  }
}

# HTTP Target Proxy
resource "google_compute_target_http_proxy" "main_http_proxy" {
  name    = "main-http-proxy"
  url_map = google_compute_url_map.http_to_https_redirect.self_link
}

# HTTP Global Forwarding Rule (리다이렉트용)
resource "google_compute_global_forwarding_rule" "main_http_forwarding_rule" {
  name       = "main-http-forwarding-rule"
  target     = google_compute_target_http_proxy.main_http_proxy.self_link
  ip_address = google_compute_global_address.main_lb_ip.address
  port_range = "80"
}

# 출력값
output "load_balancer_ip" {
  description = "Load Balancer Global IP Address"
  value       = google_compute_global_address.main_lb_ip.address
}

output "ssl_certificate_status" {
  description = "SSL Certificate Status"
  value       = google_compute_managed_ssl_certificate.main_ssl_cert.managed
}

 

 

 

 

---

 

 

트러블슈팅 가이드

 

1. 일반적인 문제와 해결책

 

 

ManagedCertificate가 Provisioning 상태에서 멈춤

# 문제 진단
kubectl describe managedcertificate <cert-name>

# 일반적인 원인:
# 1. DNS가 Load Balancer IP를 가리키지 않음
# 2. 도메인 소유권 확인 실패
# 3. Ingress에서 올바르게 참조되지 않음

# 해결:
# 1. DNS 설정 확인
nslookup your-domain.com

# 2. Ingress 어노테이션 확인
kubectl get ingress -o yaml

 

 

Load Balancer가 생성되지 않음

# 이벤트 확인
kubectl describe ingress <ingress-name>

# 일반적인 원인:
# 1. 정적 IP가 다른 리소스에서 사용 중
# 2. 백엔드 서비스가 정상적이지 않음
# 3. Health Check 실패

# 해결:
# 1. 정적 IP 상태 확인
gcloud compute addresses list --global

# 2. 백엔드 서비스 상태 확인
kubectl get services

 

 

Health Check 실패

# Pod 상태 확인
kubectl get pods -o wide

# 서비스 상태 확인
kubectl describe service <service-name>

# Health Check 경로 테스트
kubectl exec -it <pod-name> -- curl localhost:8080/health

 

 

 

2. 성능 튜닝 팁

 

 

BackendConfig 최적화

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: performance-backend-config
spec:
  timeoutSec: 30
  connectionDraining:
    drainingTimeoutSec: 300
  sessionAffinity:
    affinityType: "CLIENT_IP"
    affinityCookieTtlSec: 3600
  healthCheck:
    checkIntervalSec: 5
    timeoutSec: 3
    healthyThreshold: 2
    unhealthyThreshold: 2
    type: HTTP
    requestPath: /health
    port: 8080

 

 

CDN 캐시 최적화

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: cdn-optimized-config
spec:
  cdn:
    enabled: true
    cachePolicy:
      includeHost: true
      includeProtocol: true
      includeQueryString: false
      queryStringBlacklist: ["utm_source", "utm_medium", "utm_campaign"]
    negativeCaching: true
    negativeCachingPolicy:
    - code: 404
      ttl: 300
    - code: 500
      ttl: 60

 

 

 

 

비용 최적화 전략

 

 

GKE Ingress 비용 구조

• Global Load Balancer: $18/월 (첫 5개 규칙)
• 추가 규칙: $7/월당
• 데이터 처리: $0.008/GB

 

 

최적화 방법

# 하나의 Ingress에 여러 서비스 통합
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: unified-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api/v1
        pathType: Prefix
        backend:
          service:
            name: api-v1-service
            port:
              number: 8080
      - path: /api/v2
        pathType: Prefix
        backend:
          service:
            name: api-v2-service
            port:
              number: 8080
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

 

 

 

 

 

Global vs Regional 로드밸런싱 전략

 

 

Global Load Balancing

글로벌 로드밸런싱은 전 세계 사용자에게 최적의 성능을 제공하기 위한 전략이다.

 

장점

• 지연시간 최소화: 사용자와 가장 가까운 백엔드로 자동 라우팅
• 장애 조치: 리전 장애 시 자동으로 다른 리전으로 트래픽 전환
• 스케일링: 글로벌 트래픽 증가에 유연하게 대응

 

 

Regional Load Balancing

리전별 로드밸런싱은 특정 지역에 집중된 사용자나 규정 준수 요구사항이 있는 경우에 적합하다.

 

적용 시나리오

• 데이터 주권 요구사항
• 지역별 서비스 제공
• 비용 최적화 (특정 리전만 사용)
• 내부 서비스 통신

 

 

 

Cloud CDN 통합 및 성능 최적화

 

Cloud CDN 설정

Cloud CDN을 HTTP(S) Load Balancer와 연동하면 정적 콘텐츠의 전송 속도를 크게 향상시킬 수 있다.

resource "google_compute_backend_service" "website" {
  name        = "website-backend"
  protocol    = "HTTP"
  timeout_sec = 10

  backend {
    group = google_compute_instance_group.web.id
  }

  health_checks = [google_compute_http_health_check.default.id]

  # Cloud CDN 활성화
  enable_cdn = true

  cdn_policy {
    cache_mode                   = "CACHE_ALL_STATIC"
    default_ttl                 = 3600
    max_ttl                     = 86400
    negative_caching            = true
    negative_caching_policy {
      code = 404
      ttl  = 120
    }
    
    # 캐시 키 설정
    cache_key_policy {
      include_host         = true
      include_protocol     = true
      include_query_string = false
      query_string_whitelist = ["version", "locale"]
    }
  }
}

 

 

 

 

---

 

 

 

마무리

GCP의 로드밸런서는 각각 고유한 특성과 장점을 가지고 있어, 적절한 선택과 구성이 매우 중요하다. 특히 SSL 인증서 관리에서는 다음과 같은 선택지가 있다.

1. Certificate Manager: 최신 방식으로 여러 도메인을 하나의 인증서에 포함 가능하며, DNS 승인을 통한 자동화된 관리
2. Compute Engine Managed SSL: Terraform으로 관리하기 쉽고 여러 도메인 지원
3. GKE ManagedCertificate: GKE 환경에서 간단하지만 도메인당 별도 인증서 필요

 

 

핵심 포인트

• 인증서 관리 전략: Certificate Manager를 활용하면 여러 도메인을 효율적으로 관리할 수 있으며, GKE에서는 도메인별 ManagedCertificate를 사용하거나 Certificate Manager를 통한 Certificate Map 방식을 선택할 수 있다.
• 목적에 맞는 선택: 웹 애플리케이션에는 HTTP(S) Load Balancer, 고성능 TCP/UDP 서비스에는 Network Load Balancer, 내부 서비스 통신에는 Internal Load Balancer를 선택하자.
• 글로벌 vs 리전별 전략: 사용자 분포와 규정 준수 요구사항을 고려하여 적절한 범위의 로드밸런싱을 구현하자.
• Cloud CDN 활용: 정적 콘텐츠가 많은 서비스라면 Cloud CDN을 적극 활용하여 성능과 비용을 동시에 최적화하자.
• 지속적인 모니터링: Cloud Monitoring을 통해 성능 지표를 추적하고, 임계값 기반 알림을 설정하여 문제를 사전에 예방하자.
• 비용 최적화: 백엔드 서비스 구성과 CDN 캐시 정책을 최적화하여 불필요한 비용을 절감하자.

 

 

GCP의 로드밸런서는 AWS와 달리 Ingress Group 같은 기능이 없어 하나의 Ingress가 하나의 Load Balancer를 생성하지만, Certificate Manager와 Certificate Map을 통해 복잡한 도메인 관리가 가능하다.

 

적절한 로드밸런서 아키텍처는 애플리케이션의 가용성, 성능, 그리고 비용 효율성을 크게 좌우하므로, 이 가이드에서 제시한 전략과 예제를 바탕으로 여러분의 서비스에 최적화된 로드밸런싱 솔루션을 구축하시기 바란다.

 

 

 

 

 

 

 

---

Reference

 

• GCP Load Balancing Documentation
• Certificate Manager Documentation
• GKE Ingress Documentation
• Cloud CDN Documentation
• GCP Networking Best Practices
• Terraform Google Cloud Provider
• GKE ManagedCertificate Guide
• Cloud Monitoring Documentation
• GCP Load Balancer Pricing
• Certificate Manager DNS Authorization Guide