Google ACE: 배포, 구성 및 자동화 — 학습 가이드

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

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

개요

Google Cloud에서의 배포, 구성, 자동화는 반복 가능하고, 감사 가능하며, 안전한 변경사항 전달을 중심으로 합니다. 바람직한 관행은 코드형 인프라(IaC), 선언적 템플릿, 불변 아티팩트, 표준화된 파이프라인에 의존합니다. 운영 우수성은 멱등성을 고려한 설계, 변경사항 미리보기, 정책 적용, 명확한 롤백 경로를 포함한 통제된 롤아웃 계획에서 비롯됩니다. 다음 섹션에서는 일반적인 함정과 장단점을 포함하여 실용적인 패턴, 명령어 예시, 설계 결정의 근거를 제공합니다.

코드형 인프라 및 구성의 기초

원칙:

• 선언적 템플릿은 원하는 최종 상태를 기술하며, 도구는 실제 상태를 이에 맞게 조정합니다. 이는 멱등성, 반복성, 감사 가능성을 향상시킵니다.
• 불변 인프라스트럭처는 기존 리소스를 수정하는 대신 새로운 인스턴스나 리비전을 배포하여 롤백을 단순화하고 드리프트를 줄입니다.
• 관심사 분리: 공유 모듈이나 템플릿을 재사용하면서 환경별 값은 파라미터화합니다.

Google Cloud에서의 Terraform:

• 구성: HCL 파일은 리소스, 변수, 출력을 정의합니다. 모듈을 사용하여 VPC, 서비스 계정, GKE 클러스터 등을 캡슐화하고, 내부적으로 공유 모듈을 게시하여 패턴을 표준화합니다.
• 상태: 상태는 원격에 버전 관리하여 보관합니다. 객체 버전 관리 및 버킷 보존 기능이 있는 Cloud Storage 백엔드를 적절히 사용합니다.
  • 예시 백엔드 블록:

undefined

• 실패 모드: 로컬 상태나 버전 미관리 버킷은 데이터 손실 및 동시 쓰기 위험이 있습니다. 상태 버킷에 최소 권한 액세스를 강제하고, 키보다는 단기 수명 사용자 인증 정보와 서비스 계정 가장을 선호합니다.
• 계획 및 적용: terraform plan은 미리보기를 제공합니다. CI/CD에서는 프로덕션 적용 시 사람의 승인을 거치도록 게이트를 설정합니다. -target은 드물게 사용하며, 잦은 타겟팅은 드리프트 위험을 증가시킵니다.
• 모듈: 모듈은 시맨틱 버저닝을 따릅니다. 계획되지 않은 변경을 피하기 위해 버전을 고정합니다. 적용 전에 terraform validate 및 정책 검사로 유효성을 확인합니다.
• 가져오기 및 드리프트: terraform import는 기존 리소스를 관리 하에 둡니다. 이후 상태를 신중하게 검토해야 합니다. terraform plan을 정기적으로 실행하여 드리프트를 감지합니다.
• 원격 실행: 서비스 계정 키를 사용하지 않으려면 Workload Identity Federation을 사용하여 Cloud Build 또는 Cloud Run 작업에서 Terraform을 실행합니다. 빌드 시간을 줄이기 위해 프로바이더를 캐시합니다.

Deployment Manager:

• 많은 팀이 Terraform을 표준으로 사용하지만, Deployment Manager를 접할 수도 있습니다. 다운타임 없이 배포를 업데이트하려면 구성을 업데이트합니다:

undefined

구성 표준:

• 이름 지정: 환경, 리전, 목적, 순서를 포함하여 일관되고 파싱 가능한 이름을 적용합니다. 예: vpc-prod-usw1-core.
• 라벨: 모든 리소스에 env, cost_center, owner, app과 같은 라벨을 첨부하고, 정책이나 유효성 검사를 통해 이를 강제합니다.
• 태그: 방화벽 규칙의 범위를 지정하기 위해 네트워크 태그를 사용합니다. ID나 소유권을 위해 태그를 과도하게 사용하는 것을 피합니다(라벨이 더 적합합니다).
• 메타데이터: 시작 스크립트 및 구성에 인스턴스 메타데이터를 활용합니다. 재실행을 제어하기 위해 체크섬이나 버전 플래그가 있는 메타데이터를 선호합니다. 메타데이터에 보안 비밀을 두지 말고 Secret Manager를 사용합니다.

API, 서비스 활성화, 할당량, 서비스 계정:

• 자동화 초기에 필요한 서비스를 활성화합니다:

undefined

• 계획 단계에서 할당량 여유 공간을 확인합니다. 스케일 테스트에는 스로틀링을 피하기 위한 할당량 검사가 포함되어야 합니다.
• 워크로드 및 환경별로 전용 서비스 계정을 사용하고, 가장 좁은 범위에서 최소 권한 IAM 역할을 부여합니다. 사람의 액세스는 그룹 멤버십을, 자동화는 서비스 계정 가장을 선호합니다.

배포 파이프라인 및 아티팩트 승격

Cloud Build:

• 아티팩트를 빌드, 테스트, 패키징하는 Cloud Build 단계를 정의합니다. 동적 값에는 대체 변수를 사용하고, 사용자 인증 정보에는 Secret Manager를 사용합니다.
• 소스 변경 시 빌드를 트리거합니다. 리포지토리나 환경별로 빌드 서비스 계정을 격리하고 필요한 권한만 부여합니다.
• Docker 레이어와 언어 종속성을 캐시하여 빌드 시간을 줄입니다. 동시 빌드 제한과 임시 워커 할당량을 주시합니다.

아티팩트 승격:

• 컨테이너 이미지나 언어 패키지를 Artifact Registry에 저장합니다. 승격 방법:
  • 불변 다이제스트에 환경별 태그(예: :qa, :prod)를 다시 지정하거나
  • 환경별 리포지토리로 아티팩트를 복사합니다.
• 장단점: 태그를 사용하는 단일 리포지토리는 검색을 단순화하지만 엄격한 거버넌스가 필요합니다. 환경별 리포지토리는 격리 및 정책 적용을 강화합니다.

Cloud Deploy:

• 순서가 있는 대상(예: dev → qa → prod)으로 배포 파이프라인을 모델링합니다. 릴리스는 특정 아티팩트 다이제스트와 배포 매니페스트를 참조합니다.
• GKE 및 Cloud Run의 경우, Cloud Deploy는 Skaffold 구성을 사용하여 매니페스트를 렌더링하고 적용합니다. 승인, 확인, 게이트를 구성합니다.
• 롤아웃 및 롤백:
  • 점진적인 트래픽 전환을 사용하는 카나리 배포는 영향 반경을 줄입니다.
  • 블루/그린 배포는 추가 용량을 비용으로 빠른 전환 및 롤백을 가능하게 합니다.
  • 마지막 정상 릴리스로 고정하여 롤백합니다. 드리프트를 유발하는 인플레이스(in-place) 수정을 피합니다.
• 실패 모드: 클러스터 권한 불일치, 누락된 API, 매니페스트 스키마 오류. 빌드 중에 매니페스트를 렌더링하고 클러스터 정책에 대해 유효성을 검사하여 조기에 감지합니다.

안전한 변경 계획:

• 프로덕션 배포 시 미리보기(plan 또는 render), 자동화된 테스트, 정책 유효성 검사, 사람의 승인을 요구합니다.
• Compute Engine 관리형 인스턴스 그룹의 경우, 앱 준비 시간이 느릴 때 과도한 프로비저닝을 피하기 위해 업데이트 정책의 maxSurge/maxUnavailable 및 상태 확인 설정을 조정합니다.

명령줄 작업 및 환경 관리

Cloud Shell 및 gcloud 구성:

• Cloud Shell은 사전 인증된 gcloud와 영구적인 홈 디렉토리를 갖춘 관리형 관리자 환경을 제공합니다.
• 이름이 지정된 구성을 사용하여 계정, 프로젝트, 리전을 빠르게 전환할 수 있습니다: gcloud config configurations create prod gcloud config set project my-prod gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-a gcloud config configurations activate prod
• gcloud config list로 활성 구성을 확인합니다. GKE의 경우, 다음 명령어로 인증 정보를 획득합니다: gcloud container clusters get-credentials my-cluster –region us-central1

Compute 명령어 패턴:

• 예약된 내부 IP로 VM 생성: gcloud compute addresses create license-ip –region=us-central1 –subnet=default –addresses=10.0.3.21 gcloud compute instances create license-server –zone=us-central1-a –subnet=default –private-network-ip=10.0.3.21 –tags=license
• 커스텀 VPC, 서브넷, 방화벽 규칙 생성: gcloud compute networks create core –subnet-mode=custom gcloud compute networks subnets create core-us –network=core –range=10.0.0.0/20 –region=us-central1 gcloud compute firewall-rules create allow-https –network=core –allow=tcp:443 –target-tags=web

IAM 패턴:

• 프로젝트 범위에서 역할 부여: gcloud projects add-iam-policy-binding my-project –member=group:ops@example.com –role=roles/logging.viewer
• 프로젝트 간 커스텀 역할 복사: gcloud iam roles copy myCustomRole –source=my-dev –destination=my-prod

Storage 패턴:

• 버킷 생성 및 객체 업로드: gcloud storage buckets create gs://backups-prod –location=us-central1 –class=coldline –uniform-bucket-level-access gcloud storage cp ./backup.tar.gz gs://backups-prod/
• 파일을 통해 수명 주기를 구성하고 gcloud storage buckets update --lifecycle-file=policy.json으로 적용합니다.

API 활성화 및 확인:

• 앱을 위해 Pub/Sub 활성화: gcloud services enable pubsub.googleapis.com
• 활성화된 서비스 목록 보기: gcloud services list –enabled

거버넌스, 드리프트 및 자동화

구성 드리프트 및 정책 적용:

• 예약된 일정에 따라 terraform plan을 실행하여 드리프트를 감지하고, 예상치 못한 변경이 있을 경우 빌드를 실패시킵니다.
• 조직 정책 제약(예: 외부 IP 제한)을 강제하고, apply 전에 코드형 정책(policy-as-code)으로 리소스 구성을 검증합니다.
• Kubernetes의 경우, Config Sync와 Policy Controller를 사용하여 지속적으로 상태를 조정하고 규정을 준수하지 않는 변경을 차단합니다.
• 감사 가능성: Admin Activity 및 Data Access 로그에 의존하며, 분석을 위해 BigQuery로 라우팅합니다. 특정 시점 및 시간 이동 상태 쿼리를 위해 Cloud Asset Inventory를 사용합니다.

할당량 및 한도:

• 리전 및 프로젝트별 할당량을 검사하고, 오토스케일링 및 배포를 위한 여유 공간을 계획합니다: gcloud compute regions describe us-central1 –format=“yaml(quotas)”
• 계획된 성장이나 대규모 배포에 앞서 할당량 증가를 요청합니다.

자동화된 운영 작업:

• Cloud Scheduler는 cron 스케줄에 따라 HTTP 엔드포인트, Pub/Sub 토픽 또는 Workflows를 트리거합니다. 핸들러가 멱등성을 갖도록 보장하고, 재시도 및 데드-레터 토픽을 구성합니다.
• Workflows는 재시도, 병렬 단계, 보상 로직을 사용하여 여러 Google API에 걸친 다단계 자동화를 오케스트레이션합니다.
• Cloud Run jobs는 컨테이너화된 배치 또는 관리 작업을 온디맨드 또는 Scheduler를 통해 실행합니다. 일회성 또는 반복적인 워크로드에는 job을 사용하는 것을 선호하며, job의 서비스 계정에는 최소한의 권한을 사용합니다.

배포 안전성 및 관측 가능성:

• 상태 확인(health check) 및 준비 상태 프로브(readiness probe)를 서비스에 내장합니다. 시작이 느린 MIG의 경우, 섣부른 스케일링 조치를 방지하기 위해 초기 지연 시간을 늘립니다.
• 배포 측정항목과 오류 예산을 수집하고, SLO가 저하되면 배포를 일시 중지하거나 자동 중단합니다.

실용적인 문제 시나리오

Altostrat Media는 GKE 기반 서비스의 다중 환경 배포를 표준화하는 동시에 구성 드리프트를 제거하고 신속한 롤백을 보장해야 합니다. 또한 애플리케이션을 재구성하지 않고 레거시 라이선스 서버를 위해 고정된 내부 IP를 예약해야 합니다.

1. 기반 Terraform 모듈 및 원격 상태(remote state) 생성

• VPC, 서브넷, GKE, 서비스 계정, 방화벽 규칙을 위한 모듈을 구현합니다. 상태 버킷에 버전 관리 및 보존 정책이 적용된 Cloud Storage 백엔드를 구성합니다.
• 근거: 모듈화는 재사용성과 일관성을 높입니다. 버전 관리되는 원격 상태는 협업, 복구 가능성 및 잠금(locking)을 가능하게 합니다.

2. 필수 서비스 활성화 및 최소 권한 자동화 ID 설정

• compute.googleapis.com, container.googleapis.com, clouddeploy.googleapis.com, artifactregistry.googleapis.com을 활성화합니다.
• Terraform, Cloud Build, Cloud Deploy를 위해 환경별 서비스 계정을 생성하고, 최소한의 역할(예: 빌더가 아닌 배포자에게 roles/container.admin 부여)을 부여합니다.
• 근거: 사전 서비스 활성화 및 역할 범위 지정은 배포 실패를 줄이고 영향 반경을 제한합니다.

3. 네트워킹 프로비저닝 및 레거시 IP 예약

• Terraform을 사용하여 커스텀 VPC, 리전 서브넷, 네트워크 태그 기반의 방화벽 규칙을 생성합니다.
• 내부 IP 예약: gcloud compute addresses create license-ip –region=us-central1 –subnet=core-us –addresses=10.0.3.21
• 근거: 선언적 네트워킹은 반복성을 보장하며, IP 예약은 애플리케이션의 기존 가정을 유지합니다.

4. Cloud Build로 아티팩트 빌드 및 Artifact Registry에 게시

• 테스트 실행, 컨테이너 빌드, 스캔 후 불변 다이제스트를 Artifact Registry에 푸시하도록 cloudbuild.yaml을 정의합니다.
• 근거: 스캔된 불변 아티팩트는 안전한 프로모션과 출처(provenance) 추적의 기반이 됩니다.

5. dev → qa → prod 대상(target)을 갖는 Cloud Deploy 파이프라인 구성

• 전달 파이프라인과 대상을 정의하고, Skaffold 구성을 참조하여 매니페스트를 렌더링합니다. 프로덕션 환경에는 수동 승인을 요구하고 검증(verification)을 구성합니다.
• 근거: 구조화된 프로모션은 통제를 강제하며, 대상별 정책은 의도치 않은 프로덕션 배포를 방지합니다.

6. 카나리 전략 및 상태 게이트(health gate)를 사용한 GKE 업데이트 배포

• 카나리 배포 정책을 사용하여 SLO 및 오류율 확인에 따라 트래픽을 10%, 50%, 100% 순으로 전환합니다.
• 근거: 점진적 배포는 위험을 줄이고 자연스러운 롤백 지점을 제공합니다.

7. 예약된 plan 실행 및 정책 검사를 통해 드리프트 제거

• 야간 작업으로 terraform plan과 코드형 정책 검사기를 실행하고, 예상치 못한 차이나 위반 사항에 대해 알림을 보냅니다.
• 근거: 조기 감지는 드리프트가 누적되어 향후 apply 작업을 방해하는 것을 방지합니다.

8. 예약된 IP로 라이선스 서버 VM 운영화

• 예약된 주소와 적절한 태그에 바인딩된 VM을 생성합니다: gcloud compute instances create license-server –zone=us-central1-a –subnet=core-us –private-network-ip=10.0.3.21 –tags=license
• 근거: 애플리케이션 변경 없이 연결성을 보장하고, 태그는 방화벽 규칙의 범위를 좁게 유지합니다.

9. Scheduler, Workflows, job으로 반복 작업 자동화

• Cloud Scheduler가 Workflow를 트리거하여 불가피한 경우 서비스 계정 키를 순환시키고, 주간 데이터베이스 vacuum 작업을 위한 Cloud Run job을 시작합니다.
• 근거: 중앙 집중식 스케줄링과 오케스트레이션의 결합은 재시도 및 보상 로직을 통해 안정성과 관측 가능성을 제공합니다.

10. 롤백 계획 및 준비 상태 임계값 검증

• 마지막 정상 릴리스를 다시 프로모션하는 롤백 플레이북을 정의합니다. 준비 상태 프로브를 조정하고, MIG 기반 워크로드의 경우 앱 워밍업 시간에 맞춰 초기 상태 확인 지연 시간을 늘립니다.
• 근거: 사전 계획된 롤백과 조정된 상태 확인은 장애 발생 시 연쇄 장애와 과도한 프로비저닝을 방지합니다.

이 접근 방식은 불변 아티팩트, 선언적 인프라, 게이트가 있는 프로모션, 최소 권한 자동화를 결합하여 Google Cloud에서 안전하고 감사 가능하며 반복 가능한 운영을 제공합니다.

← 스토리지 · 모든 도메인 · 모니터링 →

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

Google 찾아보기 →