Overview
Google Cloud에서 컨테이너 기반 애플리케이션을 운영할 때 선택할 수 있는 주요 플랫폼은 GKE Standard, GKE Autopilot, 그리고 Cloud Run이다. 각각은 서로 다른 운영 복잡도와 비용 구조를 가지고 있으며, 워크로드의 특성에 따라 최적의 선택이 달라진다.
GKE Standard는 전통적인 Kubernetes 클러스터로 최대한의 제어권을 제공하지만 운영 부담이 크다.
GKE Autopilot은 Google이 노드 관리를 대신해주는 서버리스 Kubernetes 솔루션이며, Cloud Run은 완전 관리형 서버리스 컨테이너 플랫폼이다. 이 글에서는 각 플랫폼의 특징과 적합한 사용 사례를 분석하여 최적의 컨테이너 전략 수립을 도와주겠다.
플랫폼 비교 개요
| 플랫폼 | 관리 수준 | 운영 복잡도 | 비용 모델 | 최적 사용 사례 |
| Cloud Run | 완전 관리형 | 낮음 | 사용량 기반 | 웹 API, 스테이트리스 앱 |
| GKE Autopilot | 노드 관리형 | 중간 | 파드 리소스 기반 | 마이크로서비스, 일반 앱 |
| GKE Standard | 사용자 관리 | 높음 | 노드 기반 | 엔터프라이즈, GPU 워크로드 |
GKE Standard: 최대 제어권과 유연성
특징 및 장점
GKE Standard는 완전한 Kubernetes 환경을 제공하는 관리형 서비스다. 사용자가 직접 노드 풀을 구성하고 클러스터의 모든 측면을 제어할 수 있다. 노드 타입, 스케일링 정책, 네트워킹 구성 등을 세밀하게 조정할 수 있어 복잡한 엔터프라이즈 워크로드에 적합하다.
특히 GPU 워크로드, 특수한 하드웨어 요구사항, 복잡한 네트워킹 구성이 필요한 경우 GKE Standard가 유일한 선택일 수 있다. 또한 기존 Kubernetes 생태계의 모든 도구와 완벽히 호환되며, 멀티클라우드 전략을 고려한다면 표준 Kubernetes API를 그대로 사용할 수 있다는 장점이 있다.
운영 복잡도와 비용
GKE Standard는 가장 높은 운영 복잡도를 요구한다. 클러스터 업그레이드, 노드 패치, 보안 설정, 모니터링 구성 등을 직접 관리해야 한다. 또한 노드가 항상 실행되고 있어야 하므로 리소스 사용률이 낮더라도 지속적인 비용이 발생한다.
비용 구조는 사용하는 노드의 컴퓨팅 리소스에 기반한다. 클러스터 관리 수수료는 무료이지만, 효율적인 리소스 활용을 위해서는 적절한 노드 스케일링과 파드 스케줄링 전략이 필요하다. 장기간 안정적으로 높은 사용률을 유지할 수 있다면 가장 비용 효율적인 선택이 될 수 있다.
GKE Standard 테라폼 예시
# GKE Standard 클러스터 생성
resource "google_container_cluster" "standard" {
name = "standard-cluster"
location = "asia-northeast3-a"
# 초기 노드 풀 제거 후 별도 관리
remove_default_node_pool = true
initial_node_count = 1
# 네트워크 구성
network = "default"
subnetwork = "default"
# 마스터 인증된 네트워크
master_authorized_networks_config {
cidr_blocks {
cidr_block = "10.0.0.0/8"
display_name = "private-network"
}
}
# 워크로드 아이덴티티 활성화
workload_identity_config {
workload_pool = "${var.project_id}.svc.id.goog"
}
# 로깅 및 모니터링
logging_service = "logging.googleapis.com/kubernetes"
monitoring_service = "monitoring.googleapis.com/kubernetes"
}
# 노드 풀 생성
resource "google_container_node_pool" "standard_pool" {
name = "standard-node-pool"
location = "asia-northeast3-a"
cluster = google_container_cluster.standard.name
node_count = 2
node_config {
preemptible = true
machine_type = "e2-medium"
# 서비스 계정
service_account = google_service_account.gke_sa.email
oauth_scopes = [
"https://www.googleapis.com/auth/cloud-platform"
]
# 메타데이터
metadata = {
disable-legacy-endpoints = "true"
}
}
# 자동 스케일링
autoscaling {
min_node_count = 1
max_node_count = 10
}
# 노드 관리 정책
management {
auto_repair = true
auto_upgrade = true
}
}
GKE Autopilot: 서버리스 Kubernetes의 균형점
서버리스 Kubernetes 개념
GKE Autopilot은 Google이 노드 관리를 완전히 대신해주는 서버리스 Kubernetes 플랫폼이다. 사용자는 파드 리소스 요청량에 대해서만 비용을 지불하며, 노드 프로비저닝, 스케일링, 업그레이드 등은 Google이 자동으로 처리한다.
이는 Kubernetes의 유연성과 서버리스의 편의성을 결합한 접근법이다. 표준 Kubernetes API를 그대로 사용할 수 있지만, 인프라 관리 부담은 크게 줄어든다. 보안 모범 사례가 기본적으로 적용되어 있어 보안 설정에 대한 고민도 덜 수 있다.
제약사항과 적용 사례
Autopilot은 보안과 안정성을 위해 일부 제약사항을 두고 있다. 권한있는 컨테이너 실행이 제한되고, 특정 볼륨 타입 사용에 제약이 있으며, 노드에 직접 접근할 수 없다. 또한 DaemonSet 사용에 제한이 있어 모든 워크로드에 적합하지는 않다.
하지만 일반적인 웹 애플리케이션, 마이크로서비스, 배치 작업, CI/CD 파이프라인 등에는 매우 적합하다. 특히 개발팀이 Kubernetes에 익숙하지만 인프라 운영 부담을 줄이고 싶은 경우에 이상적인 선택이다. 트래픽 패턴이 불규칙하거나 개발 환경처럼 간헐적으로 사용되는 워크로드에서 비용 효율성이 높다.
| 기능 | GKE Standard | GKE Autopilot | 제약사항 |
| 권한있는 컨테이너 | 지원 | 제한적 | 보안 정책 적용 |
| DaemonSet | 완전 지원 | 제한적 | Google 관리 제외 |
| 노드 접근 | SSH 가능 | 불가능 | 완전 관리형 |
| 볼륨 타입 | 모든 타입 | 제한적 | 승인된 타입만 |
| GPU 지원 | 완전 지원 | 지원 | 특정 타입만 |
GKE Autopilot 테라폼 예시
# GKE Autopilot 클러스터 생성
resource "google_container_cluster" "autopilot" {
name = "autopilot-cluster"
location = "asia-northeast3"
# Autopilot 모드 활성화
enable_autopilot = true
# 네트워크 구성
network = google_compute_network.vpc.self_link
subnetwork = google_compute_subnetwork.subnet.self_link
# IP 할당 정책
ip_allocation_policy {
cluster_secondary_range_name = "pods"
services_secondary_range_name = "services"
}
# 워크로드 아이덴티티
workload_identity_config {
workload_pool = "${var.project_id}.svc.id.goog"
}
# 프라이빗 클러스터 구성
private_cluster_config {
enable_private_nodes = true
enable_private_endpoint = false
master_ipv4_cidr_block = "172.16.0.0/28"
}
# 릴리스 채널
release_channel {
channel = "STABLE"
}
}
# VPC 네트워크
resource "google_compute_network" "vpc" {
name = "autopilot-vpc"
auto_create_subnetworks = false
}
# 서브넷
resource "google_compute_subnetwork" "subnet" {
name = "autopilot-subnet"
ip_cidr_range = "10.0.0.0/16"
region = "asia-northeast3"
network = google_compute_network.vpc.id
secondary_ip_range {
range_name = "pods"
ip_cidr_range = "192.168.0.0/18"
}
secondary_ip_range {
range_name = "services"
ip_cidr_range = "192.168.64.0/18"
}
}
Cloud Run: 완전 관리형 서버리스 컨테이너
서버리스 컨테이너 플랫폼의 장점
Cloud Run은 완전 관리형 서버리스 컨테이너 플랫폼으로, 코드를 컨테이너로 패키징하여 배포하면 나머지는 모두 Google이 관리한다. 요청이 없을 때는 인스턴스가 0으로 스케일다운되어 비용이 발생하지 않으며, 트래픽 증가 시 자동으로 스케일업된다.
HTTP/gRPC 기반의 스테이트리스 애플리케이션에 최적화되어 있으며, 콜드 스타트 시간이 매우 빠르다. 개발자는 애플리케이션 로직에만 집중할 수 있고, 인프라 관리는 전혀 필요하지 않다. CI/CD 파이프라인과의 통합도 간단하여 빠른 배포와 롤백이 가능하다.
제약사항과 사용 사례
Cloud Run은 요청-응답 패턴의 워크로드에 특화되어 있어 장시간 실행되는 배경 작업이나 복잡한 상태 관리가 필요한 애플리케이션에는 적합하지 않다. 또한 15분의 최대 실행 시간 제한이 있어 장시간 처리가 필요한 작업에는 부적절하다.
REST API, 웹 애플리케이션, 마이크로서비스, 이벤트 기반 처리 등에 이상적이다. 특히 트래픽이 불규칙하거나 스파이크가 있는 워크로드에서 비용 효율성이 뛰어나다. 스타트업이나 사이드 프로젝트처럼 초기 단계에서 운영 복잡도를 최소화하고 싶을 때도 좋은 선택이다.
Cloud Run 제약사항 및 한계
| 제약사항 | 값 | 설명 |
| 최대 실행 시간 | 15분 | 장시간 배치 작업 불가 |
| 최대 메모리 | 32GB | 메모리 집약적 워크로드 제한 |
| 최대 CPU | 8 vCPU | 고성능 컴퓨팅 제한 |
| 동시 요청 | 1000개/인스턴스 | 높은 동시성 제한 |
| 파일 시스템 | 읽기 전용 | 임시 파일만 /tmp에 저장 |
Cloud Run 테라폼 예시
# Cloud Run 서비스 배포
resource "google_cloud_run_v2_service" "api_service" {
name = "api-service"
location = "asia-northeast3"
template {
# 스케일링 설정
scaling {
min_instance_count = 0
max_instance_count = 100
}
containers {
image = "gcr.io/${var.project_id}/api-service:latest"
# 리소스 제한
resources {
limits = {
cpu = "2"
memory = "4Gi"
}
}
# 환경 변수
env {
name = "DATABASE_URL"
value = var.database_url
}
env {
name = "SECRET_KEY"
value_source {
secret_key_ref {
secret = google_secret_manager_secret.api_secret.secret_id
version = "latest"
}
}
}
# 포트 설정
ports {
container_port = 8080
}
# 헬스체크
startup_probe {
http_get {
path = "/health"
}
initial_delay_seconds = 10
timeout_seconds = 5
period_seconds = 3
failure_threshold = 3
}
}
# 서비스 계정
service_account = google_service_account.cloud_run_sa.email
# VPC 액세스
vpc_access {
connector = google_vpc_access_connector.connector.id
egress = "ALL_TRAFFIC"
}
}
# 트래픽 설정
traffic {
percent = 100
type = "TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST"
}
}
# IAM 설정
resource "google_cloud_run_service_iam_member" "public_access" {
service = google_cloud_run_v2_service.api_service.name
location = google_cloud_run_v2_service.api_service.location
role = "roles/run.invoker"
member = "allUsers"
}
# VPC 커넥터
resource "google_vpc_access_connector" "connector" {
name = "api-connector"
region = "asia-northeast3"
ip_cidr_range = "10.8.0.0/28"
network = "default"
}
워크로드별 최적 플랫폼 선택 가이드
워크로드의 특성에 따른 최적 플랫폼 선택을 위한 의사결정 플로우는 다음과 같다.
플랫폼별 적합 워크로드
| 워크로드 유형 | Cloud Run | GKE Autopilot | GKE Standard | 추천 이유 |
| REST API | ⭐⭐⭐ | ⭐⭐ | ⭐ | 간편한 배포와 자동 스케일링 |
| 웹 애플리케이션 | ⭐⭐⭐ | ⭐⭐ | ⭐ | 트래픽 기반 스케일링 최적 |
| 마이크로서비스 | ⭐⭐ | ⭐⭐⭐ | ⭐⭐ | 서비스 간 통신과 네트워킹 |
| 배치 처리 | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ | 장시간 실행과 리소스 제어 |
| 실시간 처리 | ❌ | ⭐⭐ | ⭐⭐⭐ | WebSocket, 스트리밍 지원 |
| GPU 워크로드 | ❌ | ⭐ | ⭐⭐⭐ | 특수 하드웨어 요구사항 |
| 레거시 앱 | ❌ | ⭐ | ⭐⭐⭐ | 기존 구성 유지 필요 |
| 개발/테스트 | ⭐⭐⭐ | ⭐⭐ | ⭐ | 낮은 비용과 빠른 배포 |
웹 애플리케이션 및 API 서비스
단순한 웹 애플리케이션이나 RESTful API의 경우 Cloud Run이 가장 적합하다. 개발과 배포가 간단하고 비용 효율적이며, 자동 스케일링으로 트래픽 변화에 유연하게 대응할 수 있다. 다만 복잡한 상태 관리나 백그라운드 작업이 필요하다면 GKE Autopilot을 고려해야 한다.
마이크로서비스 아키텍처
마이크로서비스 아키텍처에서는 서비스 간 복잡한 통신과 상태 관리가 필요할 수 있어 GKE Autopilot이 적합하다. Kubernetes의 풍부한 네트워킹 기능과 서비스 디스커버리를 활용하면서도 인프라 관리 부담을 줄일 수 있다. 각 서비스의 특성에 따라 일부는 Cloud Run으로, 일부는 GKE로 하이브리드 구성도 가능하다.
배치 처리 및 데이터 파이프라인
대용량 데이터 처리나 ETL 작업의 경우 GKE Autopilot이나 Standard가 적합하다. 장시간 실행되는 작업이 많고, GPU 리소스가 필요한 경우도 있기 때문이다. Cloud Run Jobs를 사용하면 단발성 배치 작업도 처리할 수 있지만, 복잡한 워크플로우에는 제한이 있다.
레거시 애플리케이션 마이그레이션
기존 온프레미스나 VM 기반 애플리케이션을 컨테이너로 마이그레이션할 때는 GKE Standard가 적합할 수 있다. 기존 애플리케이션의 특수한 요구사항을 수용할 수 있는 유연성이 필요하기 때문이다. 점진적으로 애플리케이션을 현대화하면서 Autopilot이나 Cloud Run으로 이전할 수 있다.
Knative와 Cloud Run의 서버리스 패턴
Knative 서버리스 프레임워크
Knative는 Kubernetes 위에서 동작하는 오픈소스 서버리스 프레임워크다. GKE에서 Knative를 사용하면 Kubernetes 환경에서도 서버리스 패턴을 구현할 수 있다.
이는 복잡한 워크로드를 서버리스로 실행하고 싶지만 Cloud Run의 제약사항에 부딪힐 때 유용한 대안이다.
Knative Serving은 자동 스케일링과 트래픽 기반 라우팅을 제공하고, Knative Eventing은 이벤트 기반 아키텍처를 구현할 수 있게 해준다. 하지만 설정과 관리가 복잡하여 상당한 Kubernetes 전문성이 필요하다.
Cloud Run과의 비교 및 선택 기준
Cloud Run은 Knative를 기반으로 구축된 완전 관리형 서비스다. 따라서 Knative의 핵심 기능을 더 간단하게 사용할 수 있지만, 커스터마이징 옵션은 제한적이다. 표준 HTTP/gRPC 워크로드라면 Cloud Run이 훨씬 편리하고, 복잡한 이벤트 처리나 커스텀 스케일링 로직이 필요하다면 GKE에서 Knative를 직접 사용하는 것을 고려해야 한다.
또한 멀티클라우드나 온프레미스 환경으로의 이식성을 고려한다면 Knative가 더 나은 선택일 수 있다. Cloud Run은 Google Cloud에 종속적이지만, Knative는 표준 Kubernetes 환경에서 실행할 수 있기 때문이다.
비용 최적화 전략
비용 효율성을 극대화하기 위한 플랫폼별 전략과 비교 분석이다.
플랫폼별 비용 구조 비교
| 비용 요소 | Cloud Run | GKE Autopilot | GKE Standard |
| 기본 과금 | 사용 시간 기반 | 파드 리소스 요청 | 노드 시간 기반 |
| 관리 수수료 | 없음 | 없음 | 없음 (100노드 초과시 유료) |
| 최소 비용 | $0 (요청 없을 시) | $0 (파드 없을 시) | 노드 최소 개수 × 시간 |
| 스케일링 | 자동 (0까지 가능) | 자동 (파드 단위) | 수동/자동 (노드 단위) |
| 예약 할인 | 지원 안함 | 지원 안함 | 지원 (1-3년) |
| Spot/Preemptible | 지원 안함 | 지원 안함 | 지원 (최대 80% 할인) |
플랫폼별 비용 구조 이해
각 플랫폼의 비용 구조를 정확히 이해하는 것이 최적화의 첫걸음이다. GKE Standard는 노드 시간당 과금, Autopilot은 파드 리소스 요청량 기반 과금, Cloud Run은 실제 사용 시간과 리소스 기반 과금이다.
GKE Standard에서는 노드 사용률을 높이는 것이 핵심이다. Horizontal Pod Autoscaler와 Vertical Pod Autoscaler를 적절히 활용하고, 노드 어피니티 규칙을 통해 리소스 활용도를 극대화해야 한다. 또한 Spot VM을 사용하면 비용을 크게 절감할 수 있다.
비용 최적화 테라폼 설정
# 비용 최적화된 GKE Standard 구성
resource "google_container_node_pool" "cost_optimized_pool" {
name = "cost-optimized-pool"
location = "asia-northeast3-a"
cluster = google_container_cluster.standard.name
node_count = 1
node_config {
# Spot VM 사용으로 최대 80% 비용 절감
spot = true
machine_type = "e2-standard-2"
disk_size_gb = 50
disk_type = "pd-standard"
# 리소스 효율성을 위한 라벨
labels = {
workload-type = "batch"
cost-optimized = "true"
}
# 테인트 설정으로 특정 워크로드만 스케줄
taint {
key = "spot-instance"
value = "true"
effect = "NO_SCHEDULE"
}
}
# 공격적인 스케일링 정책
autoscaling {
min_node_count = 0
max_node_count = 20
}
# 빠른 스케일업을 위한 관리 정책
management {
auto_repair = true
auto_upgrade = false # 비용 예측성을 위해 수동 관리
}
}
# Cloud Run 비용 최적화 설정
resource "google_cloud_run_v2_service" "cost_optimized_service" {
name = "cost-optimized-service"
location = "asia-northeast3"
template {
scaling {
min_instance_count = 0 # 트래픽 없을 때 완전 스케일다운
max_instance_count = 10
}
containers {
image = "gcr.io/${var.project_id}/app:latest"
# 최소 리소스로 시작하여 비용 절약
resources {
limits = {
cpu = "1" # 필요에 따라 조정
memory = "512Mi" # 최소 메모리 설정
}
}
# 동시성 최대화로 인스턴스 수 최소화
env {
name = "CONCURRENT_REQUESTS"
value = "1000"
}
}
# 최대 실행 시간 설정으로 비용 제한
timeout = "300s"
# 서비스 계정 최소 권한 원칙
service_account = google_service_account.minimal_sa.email
}
}
워크로드 특성에 따른 최적화
트래픽 패턴이 불규칙한 워크로드는 Cloud Run이나 Autopilot이 비용 효율적이다. 반면 안정적이고 예측 가능한 트래픽을 가진 워크로드는 GKE Standard에서 예약 인스턴스나 약정 사용 할인을 활용하는 것이 유리할 수 있다.
배치 작업의 경우 Preemptible 인스턴스를 활용하여 비용을 대폭 절감할 수 있다. Cloud Run Jobs나 GKE의 Job 리소스를 사용하여 필요할 때만 리소스를 사용하도록 구성하는 것도 좋은 전략이다.
비용 최적화 시나리오별 전략
# GKE Standard - 예약 인스턴스 활용
resource "google_compute_reservation" "production_reservation" {
name = "production-reservation"
zone = "asia-northeast3-a"
specific_reservation {
count = 10
instance_properties {
machine_type = "n2-standard-4"
min_cpu_platform = "Intel Cascade Lake"
local_ssds {
disk_size_gb = 375
interface = "NVME"
}
}
}
}
# Autopilot - 리소스 요청 최적화 예시
resource "kubernetes_manifest" "cost_optimized_deployment" {
manifest = {
apiVersion = "apps/v1"
kind = "Deployment"
metadata = {
name = "web-app"
namespace = "default"
}
spec = {
replicas = 3
selector = {
matchLabels = {
app = "web-app"
}
}
template = {
metadata = {
labels = {
app = "web-app"
}
}
spec = {
containers = [{
name = "web-app"
image = "gcr.io/project/web-app:latest"
# Autopilot 비용 최적화를 위한 정확한 리소스 요청
resources = {
requests = {
cpu = "250m" # 실제 필요량에 맞춤
memory = "512Mi" # 메모리 낭비 최소화
}
limits = {
cpu = "500m"
memory = "1Gi"
}
}
# 효율적인 헬스체크
livenessProbe = {
httpGet = {
path = "/health"
port = 8080
}
periodSeconds = 30 # 체크 주기 최적화
}
}]
}
}
}
}
}
운영 복잡도 관리
각 플랫폼의 운영 복잡도와 관리 포인트를 체계적으로 분석해본다.
운영 복잡도 비교표
| 운영 영역 | Cloud Run | GKE Autopilot | GKE Standard | 설명 |
| 인프라 관리 | 사용자 | 노드, 네트워크, 업데이트 | ||
| 보안 패치 | 자동 | 자동 | 수동 | OS, 런타임 보안 업데이트 |
| 모니터링 설정 | 기본 제공 | 대부분 자동 | 수동 구성 | 로그, 메트릭, 알림 |
| 스케일링 | 완전 자동 | 파드 레벨 자동 | 수동/반자동 | 트래픽 기반 확장 |
| 네트워킹 | 단순 | 중간 | 복잡 | LB, 서비스메시, 보안 |
| 백업/복구 | 불필요 | 부분적 필요 | 완전 수동 | 데이터 지속성 관리 |
| 컴플라이언스 | 기본 적용 | 대부분 기본 | 수동 설정 | 보안 정책, 감사 |
모니터링 및 로깅
각 플랫폼마다 모니터링과 로깅 설정의 복잡도가 다르다. Cloud Run은 기본적으로 Cloud Logging과 Cloud Monitoring과 통합되어 있어 별도 설정이 거의 필요 없다. GKE Autopilot도 대부분의 모니터링이 자동 구성되지만, 커스텀 메트릭이 필요한 경우 추가 설정이 필요하다.
GKE Standard에서는 로깅 에이전트, 모니터링 에이전트 설치와 구성을 직접 관리해야 한다. 하지만 그만큼 세밀한 제어와 커스터마이징이 가능하다. Prometheus, Grafana 같은 오픈소스 도구를 자유롭게 사용할 수 있어 복잡한 모니터링 요구사항도 충족할 수 있다.
통합 모니터링 테라폼 구성
# 모든 플랫폼을 위한 통합 모니터링 대시보드
resource "google_monitoring_dashboard" "container_overview" {
dashboard_json = jsonencode({
displayName = "Container Platform Overview"
mosaicLayout = {
tiles = [
{
width = 6
height = 4
widget = {
title = "Cloud Run Request Rate"
xyChart = {
dataSets = [{
timeSeriesQuery = {
timeSeriesFilter = {
filter = "resource.type=\"cloud_run_revision\""
aggregation = {
alignmentPeriod = "60s"
perSeriesAligner = "ALIGN_RATE"
}
}
}
}]
}
}
},
{
width = 6
height = 4
widget = {
title = "GKE Pod CPU Usage"
xyChart = {
dataSets = [{
timeSeriesQuery = {
timeSeriesFilter = {
filter = "resource.type=\"k8s_pod\""
aggregation = {
alignmentPeriod = "60s"
perSeriesAligner = "ALIGN_MEAN"
}
}
}
}]
}
}
}
]
}
})
}
# 알림 정책 설정
resource "google_monitoring_alert_policy" "high_error_rate" {
display_name = "High Error Rate Alert"
combiner = "OR"
conditions {
display_name = "Cloud Run High Error Rate"
condition_threshold {
filter = "resource.type=\"cloud_run_revision\""
duration = "300s"
comparison = "COMPARISON_GREATER_THAN"
threshold_value = 0.1
aggregations {
alignment_period = "60s"
per_series_aligner = "ALIGN_RATE"
}
}
}
notification_channels = [
google_monitoring_notification_channel.email.id
]
}
# 이메일 알림 채널
resource "google_monitoring_notification_channel" "email" {
display_name = "DevOps Team Email"
type = "email"
labels = {
email_address = "devops@company.com"
}
}
보안 및 컴플라이언스
Cloud Run과 GKE Autopilot은 Google의 보안 모범 사례가 기본적으로 적용되어 있어 보안 설정 부담이 적다. 하지만 특수한 컴플라이언스 요구사항이 있다면 GKE Standard에서 세밀한 보안 정책을 구성해야 할 수 있다.
네트워크 보안, Pod Security Standards, RBAC 설정 등을 직접 관리해야 하는 복잡도가 있지만, 엔터프라이즈 환경에서 요구되는 엄격한 보안 요구사항을 충족할 수 있다. Binary Authorization, Policy Controller 같은 고급 보안 기능도 활용할 수 있다.
보안 강화 테라폼 설정
# 통합 보안 정책
resource "google_binary_authorization_policy" "container_policy" {
admission_whitelist_patterns {
name_pattern = "gcr.io/${var.project_id}/*"
}
default_admission_rule {
evaluation_mode = "REQUIRE_ATTESTATION"
enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
require_attestations_by = [
google_binary_authorization_attestor.build_attestor.name
]
}
# Cloud Run 전용 규칙
cluster_admission_rules {
cluster = "projects/${var.project_id}/locations/*/cloudrun"
evaluation_mode = "REQUIRE_ATTESTATION"
enforcement_mode = "ENFORCED_BLOCK_AND_AUDIT_LOG"
require_attestations_by = [
google_binary_authorization_attestor.build_attestor.name
]
}
}
# 서비스 계정 최소 권한 설정
resource "google_service_account" "secure_workload_sa" {
account_id = "secure-workload"
display_name = "Secure Workload Service Account"
}
# 필요한 최소 권한만 부여
resource "google_project_iam_member" "workload_permissions" {
for_each = toset([
"roles/cloudsql.client",
"roles/secretmanager.secretAccessor"
])
project = var.project_id
role = each.value
member = "serviceAccount:${google_service_account.secure_workload_sa.email}"
}
실제 구현 시나리오
실무에서 활용할 수 있는 구체적인 구현 예시들을 살펴보자.
시나리오 1: 스타트업 MVP 구축
MVP를 위한 완전 서버리스 구성
# API Gateway
resource "google_cloud_run_v2_service" "api_gateway" {
name = "api-gateway"
location = "asia-northeast3"
template {
containers {
image = "gcr.io/${var.project_id}/api-gateway:latest"
env {
name = "USER_SERVICE_URL"
value = google_cloud_run_v2_service.user_service.uri
}
env {
name = "AUTH_SERVICE_URL"
value = google_cloud_run_v2_service.auth_service.uri
}
}
scaling {
min_instance_count = 0
max_instance_count = 100
}
}
}
# User Service
resource "google_cloud_run_v2_service" "user_service" {
name = "user-service"
location = "asia-northeast3"
template {
containers {
image = "gcr.io/${var.project_id}/user-service:latest"
env {
name = "DB_CONNECTION"
value_source {
secret_key_ref {
secret = google_secret_manager_secret.db_connection.secret_id
version = "latest"
}
}
}
}
# 내부 서비스이므로 외부 접근 차단
annotations = {
"run.googleapis.com/ingress" = "internal"
}
}
}
시나리오 2: 엔터프라이즈 마이크로서비스
마이크로서비스를 위한 GKE Autopilot 구성
# Istio 서비스 메시 활성화
resource "google_container_cluster" "microservices_cluster" {
name = "microservices-cluster"
location = "asia-northeast3"
enable_autopilot = true
# Istio 서비스 메시 활성화
service_external_ips_config {
enabled = true
}
addons_config {
istio_config {
disabled = false
auth = "AUTH_MUTUAL_TLS"
}
}
# 워크로드 아이덴티티
workload_identity_config {
workload_pool = "${var.project_id}.svc.id.goog"
}
}
# 서비스메시 게이트웨이
resource "kubernetes_manifest" "istio_gateway" {
manifest = {
apiVersion = "networking.istio.io/v1beta1"
kind = "Gateway"
metadata = {
name = "microservices-gateway"
namespace = "default"
}
spec = {
selector = {
istio = "ingressgateway"
}
servers = [{
port = {
number = 80
name = "http"
protocol = "HTTP"
}
hosts = ["api.company.com"]
}]
}
}
}
시나리오 3: 하이브리드 아키텍처
대규모 엔터프라이즈에서는 각 서비스의 특성에 따라 다른 플랫폼을 조합하여 사용한다.
하이브리드 구성 관리
# 프로젝트 수준 공통 설정
locals {
common_labels = {
environment = "production"
team = "platform"
managed_by = "terraform"
}
}
# 공통 VPC
resource "google_compute_network" "shared_vpc" {
name = "shared-vpc"
auto_create_subnetworks = false
}
# Cloud Run을 위한 VPC 커넥터
resource "google_vpc_access_connector" "cloud_run_connector" {
name = "cloud-run-connector"
region = "asia-northeast3"
network = google_compute_network.shared_vpc.name
ip_cidr_range = "10.8.0.0/28"
}
# GKE 클러스터용 서브넷
resource "google_compute_subnetwork" "gke_subnet" {
name = "gke-subnet"
ip_cidr_range = "10.0.0.0/16"
region = "asia-northeast3"
network = google_compute_network.shared_vpc.id
secondary_ip_range {
range_name = "pods"
ip_cidr_range = "192.168.0.0/18"
}
secondary_ip_range {
range_name = "services"
ip_cidr_range = "192.168.64.0/18"
}
}
# 통합 로드 밸런서
resource "google_compute_global_address" "main_ip" {
name = "main-lb-ip"
}
resource "google_compute_managed_ssl_certificate" "main_cert" {
name = "main-ssl-cert"
managed {
domains = ["api.company.com", "app.company.com"]
}
}
마무리
Google Cloud의 컨테이너 플랫폼 선택은 워크로드의 특성, 팀의 기술 역량, 비용 목표, 운영 복잡도 허용 수준을 종합적으로 고려해야 한다.
Cloud Run은 간단한 웹 애플리케이션과 API에 최적화되어 있고,
GKE Autopilot은 Kubernetes의 유연성과 서버리스의 편의성을 균형있게 제공한다.
GKE Standard는 최대한의 제어권이 필요한 복잡한 엔터프라이즈 워크로드에 적합하다.
플랫폼 선택 의사결정 매트릭스
| 고려사항 | Cloud Run | GKE Autopilot | GKE Standard |
| 개발 속도 | 매우 빠름 | 빠름 | 보통 |
| 운영 부담 | 매우 낮음 | 낮음 | 높음 |
| 비용 예측성 | 변동적 | 중간 | 높음 |
| 확장성 | 자동 | 자동 | 수동/반자동 |
| 커스터마이징 | 제한적 | 중간 | 완전 자유 |
| 멀티클라우드 | 불가능 | 제한적 | 가능 |
| 학습 곡선 | 낮음 | 중간 | 높음 |
단계적 도입 전략
대부분의 조직은 하나의 플랫폼만 사용하는 것이 아니라, 각 워크로드의 특성에 맞게 하이브리드 접근법을 취하는 것이 현실적이다.
초기에는 Cloud Run으로 시작하여 빠르게 프로토타입을 구축하고, 복잡도가 증가하면 GKE Autopilot으로 마이그레이션하며, 특수한 요구사항이 생기면 GKE Standard로 확장하는 점진적 접근법을 권장한다.
성공적인 컨테이너 전략의 핵심은 기술적 우수성보다는 비즈니스 목표와의 정렬이다. 빠른 시장 진입이 우선인지, 안정적인 운영이 중요한지, 비용 최적화가 핵심인지에 따라 플랫폼 선택과 아키텍처 설계가 달라져야 한다.
또한 팀의 역량과 조직 문화도 중요한 고려사항이다.
마지막으로 컨테이너 플랫폼은 수단이지 목적이 아니라는 점을 명심해야 한다. 사용자에게 가치를 전달하는 것이 최우선이며, 기술 스택은 이를 효율적으로 달성하기 위한 도구일 뿐이다.
Reference
- Google Kubernetes Engine Documentation
- Cloud Run Documentation
- GKE Autopilot vs Standard Comparison
- Knative Documentation
- Google Cloud Container Services Pricing
- Container Optimization Best Practices
- Kubernetes Cost Optimization Guide
- Terraform Google Cloud Provider
- Istio Service Mesh on GKE
- Binary Authorization for Container Security
Somaz | DevOps Engineer | Kubernetes & Cloud Infrastructure Specialist
'GCP' 카테고리의 다른 글
| GCP 데이터베이스 선택 완전 가이드: Cloud SQL vs Spanner vs Firestore vs BigQuery (1) | 2026.03.10 |
|---|---|
| GCP 네트워크 연결 완전 가이드: VPC Peering vs Cloud Interconnect vs VPN (0) | 2026.03.03 |
| GCP Load Balancer 완전 비교 가이드 (0) | 2026.01.08 |
| GCP에서 딥러닝을 위한 GPU VM 서버 만들기(GCP) (0) | 2024.03.04 |
| Terraform 으로 GCS 생성후 Cloud CDN 생성(GCP) (0) | 2024.01.22 |