Google ACE: 컨테이너, 앱 호스팅 및 서버리스 플랫폼 — 학습 가이드

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

다음의 일부입니다: Google Associate Cloud Engineer — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Google Cloud는 완전 관리형 서버리스부터 구성 가능한 Kubernetes 클러스터에 이르기까지, 컨테이너와 애플리케이션을 실행하기 위한 다양한 플랫폼을 제공합니다. 올바른 플랫폼을 선택하고 운영하려면 컨트롤 플레인, 스케일링 모델, 릴리스 메커니즘, 네트워킹, 보안에 대한 이해가 필요합니다. 이 섹션에서는 Google Kubernetes Engine (GKE), Artifact Registry, Cloud Run, App Engine, Cloud Functions에 대한 운영 가이드라인과 함께 보안 비밀, 안전한 롤아웃, 진단을 위한 패턴을 통합하여 설명합니다.

Kubernetes Engine: 클러스터, 워크로드, 네트워킹

GKE 클러스터는 사용자가 크기를 조정하고 보안을 설정하는 노드 풀과 함께 관리형 Kubernetes 컨트롤 플레인을 제공합니다. 운영 오버헤드를 최소화하고 권장 기본값을 사용하려면 Autopilot을 선택하고, 노드, 네트워킹, 부가 기능에 대한 세부적인 제어가 필요하면 Standard를 선택하세요. 릴리스 채널과 노드 자동 업그레이드를 사용하여 예측 가능하고 안전한 업그레이드를 수행하고, 노드 자동 복구를 활성화하세요. 특정 패키지에 Ubuntu가 필요한 경우가 아니라면, 보안이 강화된 노드를 위해 Container-Optimized OS를 사용하는 것이 좋습니다.

• 노드 풀 및 스케줄링

  • 워크로드 클래스(예: 일반, GPU, 스팟)별로 노드 풀을 분리하고, taint/toleration을 사용하여 Pod를 특정 노드로 유도하세요.
  • 클러스터 자동 확장 처리를 활성화하고 풀별로 min/max를 구성하세요. PodDisruptionBudget과 리소스 요청이 스케일 인(축소)을 막거나, 요청량이 사용 가능한 노드 형태(shape)를 초과할 경우 Pod가 보류(pending) 상태로 남을 수 있다는 점에 유의해야 합니다.
  • 스팟/선점형 노드는 비용을 절감하지만 축출(eviction) 위험이 있습니다. 복원력을 높이려면 Deployment의 서지(surge) 예산 및 Pod 토폴로지 제약 조건과 함께 사용하세요.

• 네임스페이스 및 멀티테넌시

  • 네임스페이스를 사용하여 할당량, 정책, RBAC를 분리하세요. NetworkPolicy를 적용하여 이스트-웨스트(내부) 트래픽을 제한하세요. 네임스페이스 범위에서 Pod Security 표준을 적용하여 권한이 높은 워크로드를 방지하세요.

• 워크로드

  • Deployment는 롤링 업데이트, 서지/사용 불가 예산, 빠른 롤백 기능으로 상태 비저장(stateless) Pod를 관리합니다. readiness probe를 사용하여 트래픽 유입을 제어하고, liveness/startup probe를 사용하여 자동 복구를 수행하세요. readiness probe를 잘못 구성하면 트래픽이 블랙홀(blackhole) 현상을 겪을 수 있으니, 프로덕션 전에 테스트해야 합니다.
  • StatefulSet은 데이터베이스나 쿼럼 기반 시스템을 위해 안정적인 식별자와 순서가 보장된 스케일링을 제공합니다. 헤드리스(headless) Service와 동적 프로비저닝을 지원하는 StorageClass를 사용하고, 영역별 PV 지역성(locality)을 계획하세요.
  • DaemonSet은 노드당 하나의 Pod를 스케줄링합니다(예: 로깅/모니터링 에이전트). 자동 확장 및 드레이닝(drain) 이벤트를 존중하며, 노드 전체의 텔레메트리에 이상적입니다.

• 서비스 및 인그레스

  • ClusterIP는 클러스터 내 DNS와 로드 밸런싱을 노출합니다. NodePort는 주로 문제 해결용으로 사용됩니다. LoadBalancer는 Google Cloud 외부 또는 내부 TCP/UDP 로드 밸런서를 프로비저닝합니다. 비공개 서비스에는 내부 로드 밸런서를 사용하세요.
  • GKE Ingress는 관리형 인증서, URL 맵, Cloud Armor를 사용하여 글로벌 HTTP(S) 로드 밸런싱을 구성합니다. 최신 트래픽 관리를 위해서는 Pod별 상태 확인과 더 빠른 수렴(convergence)을 위해 컨테이너 네이티브 로드 밸런싱(NEG)을 사용하는 것이 좋습니다. readiness 엔드포인트가 실제 앱 상태를 반영하도록 해야 합니다. 그렇지 않으면 백엔드가 비정상(unhealthy) 상태가 되어 502 오류가 발생합니다.

• 자동 확장

  • Horizontal Pod Autoscaler는 CPU와 같은 메트릭 또는 Cloud Monitoring을 통한 커스텀 메트릭을 기반으로 레플리카 수를 조정합니다. Metrics Server가 정상 상태인지 확인하세요. Vertical Pod Autoscaler는 요청(request) 크기를 적절하게 조정할 수 있습니다. HPA와의 충돌을 피하려면 HPA로 관리되는 워크로드에 대해서는 VPA를 ‘권장(recommendation)’ 모드로 사용하거나, HPA+VPA 호환 모드를 신중하게 사용하세요.
  • 클러스터 자동 확장 처리기는 Pod에 맞게 노드를 추가/제거합니다. Pod가 어떤 노드 형태(shape)가 제공하는 것보다 더 많은 리소스를 요청하면 절대 스케줄링되지 않으므로, 요청/제한(requests/limits)을 노드 풀의 형태와 일치시켜야 합니다.

간단한 예시:

• 손상된 릴리스 롤백하기:
  • kubectl rollout undo deployment/web
• 다른 컨텍스트 빠르게 확인하기:
  • kubectl config use-context CONTEXT && kubectl config view

아티팩트 관리, 공급망 보안, 안전한 릴리스

Artifact Registry는 VPC Service Controls를 지원하며 리전별로 컨테이너 이미지를 호스팅합니다. 환경별로 별도의 리포지토리(또는 접두사)를 채택하고 불변(immutable) 태그를 강제하세요. 모호함을 없애기 위해 다이제스트(digest)로 배포하세요. Cloud Build 또는 자체 CI를 통합하여 출처(provenance) 메타데이터와 함께 빌드하고 푸시하세요.

• 취약점 관리

  • Artifact Analysis를 활성화하여 OS 및 언어 관련 CVE에 대해 이미지를 스캔하세요. 심각도가 높은 취약점이 발견되면 빌드를 중단하거나 프로모션을 차단하세요. Binary Authorization과 결합하여 GKE에 허용되기 전에 서명/증명(예: 취약점 정책 통과, SLSA 출처)을 요구하세요.

• 이미지 프로모션

  • 개발(dev) 리포지토리에서 스테이징/프로덕션(staging/prod) 리포지토리로 이미지 다이제스트를 복사하거나, 프로모션 리포지토리에서 태그를 다시 지정하여 프로모션하세요. 변경 가능한 “latest” 태그 사용은 피하세요. 테스트 및 스캔 결과를 조건으로 하는 Cloud Build 트리거로 자동화하세요.

• 보안 비밀 및 구성

  • 최소 권한 액세스 원칙에 따라 Secret Manager를 사용하는 것이 좋습니다. GKE에서는 Secret Manager CSI 드라이버를 Workload Identity와 함께 사용하여 노드가 장기 수명의 보안 비밀을 보지 못하도록 하세요. KRM 구성의 경우, ConfigMap(민감하지 않은 정보)과 Secret(민감 정보)을 분리하고 읽기 전용으로 마운트하세요.
  • 서버리스의 경우, 직접적인 Secret Manager 바인딩을 통해 보안 비밀을 마운트하세요. 꼭 필요한 경우가 아니면 환경 변수에 보안 비밀을 포함하지 마세요.

• 롤백 및 릴리스 패턴

  • Kubernetes: 무중단 배포를 위해 maxUnavailable=0으로 롤링 업데이트를 사용하고, maxSurge는 용량에 맞게 조정하세요. 카나리 배포는 하나의 Service 뒤에 두 개의 Deployment를 두거나 서비스 메시를 사용하여 점진적인 비율로 트래픽을 이전하세요. PodDisruptionBudget과 minReadySeconds로 중요한 워크로드를 보호하세요.
  • Cloud Run 및 App Engine: 리비전/버전과 트래픽 분할을 사용하여 카나리 및 블루/그린 배포를 수행하세요. 이전 리비전을 웜(warm) 상태로 유지하여 롤백 지연 시간을 줄이세요.
  • 장애 모드: 변경 가능한 태그의 불일치(drift), 스캔 시간의 공백, 잘못 지정된 readiness probe는 장애의 일반적인 원인입니다. 이미지 다이제스트, 배포 전 검사, 합성 상태 확인(synthetic health probe)을 사용하세요.

서버리스 애플리케이션 플랫폼

Cloud Run은 컨테이너 네이티브, 요청 기반 컴퓨팅을 제공하며, 자동으로 0으로 축소(scale-to-zero)되고 요청별 ID를 적용합니다.

• Cloud Run 서비스 및 작업(Job)

  • 서비스는 HTTP를 처리합니다. 동시성(concurrency) 설정으로 인스턴스당 동시 요청 수를 제어합니다(지연 시간과 효율성 사이에서 조정). 작업은 비(non)-HTTP 배치/cron을 처리하며 병렬화할 수 있습니다.
  • 리비전(Revision)은 불변(immutable) 스냅샷입니다. 트래픽 분할을 통해 백분율 기반의 카나리(canary) 배포가 가능합니다. 최소 인스턴스(min instances)를 설정하여 콜드 스타트(cold start)를 줄이고, 백그라운드 작업이 필요하면 유휴 상태(idle) 시 CPU 할당을 사용합니다.
  • ID: 서비스/리비전별로 최소 권한 원칙에 따라 전용 서비스 계정을 할당합니다. IAM(Cloud Run Invoker 역할)을 통해 호출을 제한하거나, 필요한 경우 공개(public)로 설정합니다. 최종 사용자 인증을 위해서는 서명된 IAP 토큰 또는 Identity Platform과 연동된 Cloud Run의 내장 인증을 사용합니다.

• 네트워킹

  • Serverless VPC 커넥터를 사용하여 비공개 VPC 리소스에 연결합니다. 이그레스(egress) 설정 선택: 모든 트래픽을 커넥터를 통하게 하거나, 비공개 RFC1918 범위만 통하게 합니다. 커넥터의 처리량 할당량에 유의하고, 커넥터 크기를 조정하고 서비스와 리전을 일치시킵니다. 비공개 IP만 있는 리소스에서 아웃바운드 인터넷을 사용하려면 Cloud NAT과 결합합니다.
  • Private Service Connect를 사용하여 생산자(producer) 서비스를 비공개로 사용하거나 내부 엔드포인트를 노출할 수 있습니다. 외부 HTTP(S)를 통한 인제스트(ingest)에는 서버리스 NEG와 함께 Cloud Load Balancing을 사용합니다.

App Engine은 두 가지 환경을 제공합니다:

• 표준(Standard)
  • 샌드박스 환경이며, 신속하게 확장되고, 자동, 기본 또는 수동 확장을 지원합니다. min_idle_instances를 사용한 자동 확장은 미리 준비된(pre-warmed) 용량을 제공합니다. 콜드 스타트가 빠르고 배포 모델이 단순합니다. OS 수준의 사용자 정의가 제한적이고 런타임 세트가 고정되어 있습니다.
• 가변형(Flexible)
  • Compute Engine VM에서 Docker를 실행하며 시스템 라이브러리 및 네트워킹에 대한 제어 수준이 더 높습니다. 인스턴스 수명 주기가 더 느리고 기본 비용이 더 높습니다. 사용자 정의 런타임이나 네이티브 라이브러리가 필요할 때 적합합니다.
• 서비스 및 버전
  • 버전별로 트래픽을 분할합니다(무작위, 쿠키 또는 IP 기준). 각 서비스는 독립적으로 확장할 수 있습니다. 점진적 출시(gradual rollout)를 사용하고 즉각적인 롤백을 위해 이전 버전을 유지합니다.

Cloud Functions는 이벤트 기반의 단일 목적 함수를 제공합니다.

• 트리거: Pub/Sub, Cloud Storage, HTTP, 다양한 소스를 위한 Eventarc.
• 핸들러를 멱등성(idempotent) 있게 만드세요. 일부 트리거는 실패 시 재시도하여 중복 처리를 유발할 수 있습니다.
• 런타임 구성: 환경 변수, Secret Manager 연동, 최대 인스턴스 수, 메모리/CPU.
• HTTP 함수의 동시성을 제어하여 지연 시간과 비용의 균형을 맞춥니다.
• 일반적인 함정: 제한 없는 동시성 또는 멱등성이 아닌 부수 효과(side effect)는 데이터 중복을 유발합니다. Pub/Sub에 DLQ를 설정하고 적절한 타임아웃을 설정해야 합니다.

플랫폼 선택, 네트워킹 및 운영 소유권

필요한 제어 수준, 확장 특성, 이식성 요구사항, 운영 예산을 기반으로 플랫폼을 선택합니다.

• 제어 수준과 오버헤드

  • 가장 높은 제어 수준: GKE Standard (노드 OS, 네트워킹, 보안 애드온)는 그에 상응하는 운영 오버헤드가 따릅니다.
  • 균형: GKE Autopilot (노드 관리 불필요, 보안에 대한 구글의 권장 방식 적용).
  • 가장 낮은 오버헤드: Cloud Run, App Engine, Cloud Functions (노드 없음, 관리형 확장)는 런타임 및 요청 모델에 제약이 있습니다.

• 확장 및 워크로드 적합성

  • 요청이 급증하는(Spiky) 워크로드: Cloud Run/App Engine Standard가 뛰어납니다. 이벤트 기반 핸들러에는 Functions가 적합합니다.
  • 상태 저장(Stateful) 또는 커스텀 네트워킹: StatefulSets 및 CNI 기능이 있는 GKE를 사용합니다.
  • 이식성: GKE/Cloud Run의 컨테이너는 이식성이 높습니다. Functions는 FaaS 모델의 특성상 이식성이 낮습니다.

• 서버리스 네트워킹, 이그레스(egress) 및 비공개 서비스

  • 비공개 액세스를 위해서는 VPC 커넥터를 사용하고, 스로틀링(throttling)을 방지하기 위해 커넥터 사용률을 모니터링합니다. 이그레스(egress)는 꼭 필요한 경우에만 “all”로 설정하고, 그 외에는 비용과 위험을 줄이기 위해 비공개 범위로 제한합니다.
  • 비공개 인그레스(ingress)의 경우, 서버리스 NEG 또는 Private Service Connect를 사용하는 내부 HTTP(S) 부하 분산을 고려합니다.
  • 데이터 무단 반출 제어를 위해, 지원되는 경우 VPC Service Controls와 함께 사용하고 방화벽 및 Cloud NAT를 통해 이그레스(egress) 경로를 제한합니다.

• 진단 및 운영 소유권

  • Cloud Logging을 표준으로 사용하고, 서비스 간 상관관계 분석을 위해 구조화된 로그(JSON)와 추적/스팬 ID를 사용합니다. Cloud Monitoring 대시보드, 업타임 체크, SLO, 알림 정책을 활용합니다.
  • GKE의 경우: Cloud Ops for GKE를 활성화하고, Prometheus 또는 Cloud Monitoring을 통해 앱 메트릭을 수집하며, 노드 수준의 원격 측정을 위해 DaemonSets를 사용합니다.
  • 서버리스의 경우: 내장된 요청 로그, Error Reporting, Trace, Profiler를 활용합니다. 지연 시간, 오류율, 포화도(동시 실행, 인스턴스 CPU)에 대해 서비스별 SLO 및 알림을 설정합니다.
  • 소유권 모델: 런타임 매개변수(확장, 동시 실행), IAM, 릴리스 파이프라인의 소유자를 정의합니다. 롤백 및 재해 시나리오를 정기적으로 테스트합니다.

실제 문제 시나리오

Acme Retail은 내부 서비스를 현대화하면서 새로운 결제 API를 외부에 공개할 계획입니다. 요구사항: 카나리(canary) 롤아웃이 가능한 저지연 퍼블릭 API, VPC 내부에 있는 내부 재고 데이터베이스에 대한 비공개 액세스, 공급망 보안 정책 강제, 최소한의 운영 오버헤드로 명확한 롤백 기능.

1. 퍼블릭 API에는 Cloud Run을, 내부 재고 서비스에는 GKE Autopilot을 선택합니다.

• 근거: Cloud Run은 상태 비저장(stateless) HTTP 서비스의 운영 오버헤드를 최소화하고, 리비전(revision) 및 트래픽 분할을 지원합니다. GKE Autopilot은 노드 관리 없이 상태 저장(stateful)/내부 서비스에 필요한 Kubernetes 기능을 제공합니다.

2. Artifact Registry에서 출처(provenance) 정보와 함께 이미지를 빌드, 스캔, 저장합니다.

• 근거: Cloud Build는 컨테이너 이미지를 생성하고, Artifact Analysis는 CVE를 스캔합니다. 다이제스트(digest)와 출처 정보를 저장하면 Binary Authorization을 통해 스캔되고 서명된 이미지만 실행되도록 강제할 수 있습니다.

3. 어드미션 정책을 강제합니다.

• 근거: GKE 클러스터에서 Binary Authorization을 활성화하여 서명 및 정책 증명을 요구합니다. Cloud Run의 경우, 배포 자동화가 취약점 정책을 통과해야만 프로모션되도록 게이트를 설정합니다.

4. Serverless VPC 커넥터와 Cloud NAT로 네트워킹을 구성합니다.

• 근거: Cloud Run API는 재고 서비스와 Cloud SQL에 비공개로 접근해야 합니다. VPC 커넥터는 비공개 RFC1918 이그레스(egress)를 허용하고, Cloud NAT는 비공개 리소스에 외부 IP 없이도 종속성 다운로드를 위한 아웃바운드 인터넷 액세스를 제공합니다. 커넥터와 서비스는 동일한 리전에 유지하고 처리량을 적절한 크기로 조정합니다.

5. ID 및 권한을 보호합니다.

• 근거: Cloud Run 서비스에 전용 서비스 계정을 할당하고 최소 권한(예: Cloud SQL 클라이언트, 필요한 경우 내부 엔드포인트 호출 권한)을 부여합니다. GKE의 경우, Workload Identity를 사용하여 Pod가 노드 수준의 사용자 인증 정보 없이 서비스 계정을 위임받도록 합니다.

6. 안전한 릴리스 및 롤백을 구현합니다.

• 근거: API를 새로운 Cloud Run 리비전으로 배포하고 카나리 테스트를 위해 5%의 트래픽을 분할합니다. 지연 시간, 오류율, 포화도를 모니터링한 후 100%로 늘리거나, 이전 리비전으로 트래픽을 되돌려 즉시 롤백합니다. GKE에서는 Deployment의 롤링 업데이트를 사용하며, 준비 상태 프로브(readiness probe)와 함께 동일한 Service 뒤에 작은 카나리 Deployment를 두어 전체 롤아웃 전에 검증합니다.

7. 관측 가능성 및 SLO를 구성합니다.

• 근거: 두 플랫폼 모두에서 추적 ID가 포함된 구조화된 JSON 로그를 Cloud Logging으로 전송합니다. p95 지연 시간 및 5xx 오류율에 대한 SLO를 생성하고 알림 정책을 연결합니다. 근본 원인 분석을 위해 Error Reporting과 Trace를 사용합니다. GKE의 경우, 노드 메트릭을 위해 DaemonSet을 배포하고 Cloud Ops for GKE를 활성화합니다.

8. 장애 모드 및 용량을 검증합니다.

• 근거: 부하 테스트를 통해 VPC 커넥터 처리량, Cloud Run 동시 실행, GKE HPA 동작을 검증합니다. 블랙홀링(blackholing)을 방지하기 위해 준비 상태 프로브의 정확성을 확인합니다. 공급망 보안 정책이 적용된 상태에서 복구 가능성을 보장하기 위해 Binary Authorization의 거부 경로와 다이제스트를 이용한 이미지 롤백을 테스트합니다.

이 접근 방식은 Google Cloud 운영 모범 사례에 따라 낮은 운영 부담의 보안 퍼블릭 API, 제어된 내부 서비스, 비공개 네트워킹, 강제 가능한 공급망 보안, 신속한 롤백을 제공합니다.

← Compute Engine 및 가상 머신 운영 · 모든 도메인 · VPC 네트워킹 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →

Google 찾아보기 →