Google PCD: 클라우드 네이티브 애플리케이션 아키텍처 및 서비스 선택 — 학습 가이드

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

개요

Google Cloud의 클라우드 네이티브 애플리케이션 아키텍처는 수평적으로 확장되고, 운영 부담을 최소화하며, 적절한 경우 관리형 서비스를 활용하는 스테이트리스(stateless)하고 복원력 있는 서비스를 구축하는 데 중점을 둡니다. 효과적인 서비스를 선택하려면 제어, 이식성, 성능, 비용, 운영 책임 간의 장단점을 이해해야 합니다. 이 섹션에서는 예측 가능한 안정성으로 전 세계 사용자를 위한 애플리케이션을 설계, 현대화 및 운영하는 데 도움이 되는 원칙과 패턴을 제시합니다.

클라우드 네이티브 원칙 및 아키텍처 선택

• 12 요소(Twelve-factor) 및 스테이트리스(stateless) 설계

  • 코드베이스, 종속성, 빌드-릴리스-실행: 정확한 종속성을 고정하고, 불변의 아티팩트를 생성하며, 빌드와 릴리스를 분리합니다. 컨테이너 이미지와 Cloud Build 파이프라인은 재현 가능한 릴리스를 보장합니다.
  • 환경에 구성 저장: 환경 변수, Secret Manager, Kubernetes Secrets 또는 Compute Engine의 인스턴스 메타데이터를 사용하여 구성을 외부화합니다. 이미지에 인증 정보나 배포별 설정을 포함하지 마십시오. Compute Engine 관리형 인스턴스 그룹의 경우, 배포별 값에 인스턴스 템플릿 메타데이터를 사용합니다.
  • 백업 서비스: 데이터베이스, 큐, 캐시를 연결된 리소스로 취급합니다. 운영 부담을 줄이기 위해 관리형 서비스(Cloud SQL, Cloud Spanner, Firestore, Memorystore, Pub/Sub)를 사용하는 것이 좋습니다.
  • 스테이트리스(Stateless) 프로세스: 인스턴스를 추가하여 확장하고, 세션 상태는 외부(Memorystore for Redis, Firestore 또는 Spanner)에 저장합니다. 로그는 stdout/stderr 또는 Cloud Logging 에이전트가 수집하는 로그 파일에 기록합니다.
  • 폐기 가능성(Disposability): 빠른 시작/종료는 신속한 확장 및 롤링 업데이트를 가능하게 합니다. 정상적인 종료를 위해 SIGTERM을 처리합니다.
  • 이벤트 스트림으로서의 로그: 구조화된 로그를 내보내고, 수집에는 Cloud Logging을, 알림에는 Cloud Monitoring을 사용합니다.

• 아키텍처 장단점

  • 모놀리스(Monolith)
    • 장점: 개발/테스트 단순화, 더 적은 네트워크 경계, 단일 배포 단위.
    • 단점: 느린 독립적 배포, 확장 제약, 도메인 간의 강한 결합.
    • 장애 모드: 하나의 핫 패스(hot path)가 공유 리소스를 소모할 수 있으며, 회귀(regression)가 모든 기능에 영향을 미칩니다.
  • 모듈형 모놀리스(Modular monolith)
    • 장점: 명확한 내부 모듈 경계, 서비스로의 리팩토링 경로, 단일 배포 가능.
    • 단점: 여전히 모놀리식 배포 및 데이터베이스에 의해 제약을 받습니다.
    • 사용처: 서비스를 추출하기 전에 도메인 경계를 성숙시키는 팀에 사용합니다.
  • 마이크로서비스(Microservices)
    • 장점: 독립적인 배포, 목표에 맞춘 확장, 팀 자율성, 적절한 벌크헤드(bulkhead)를 통한 장애 격리.
    • 단점: 분산 시스템의 복잡성, 일관성, 관측 가능성 및 운영 오버헤드.
    • 장애 모드: 동기식 호출을 통한 연쇄 장애, 스키마 드리프트(schema drift), 채티(chatty)한 네트워크.
  • 이벤트 기반(Event-driven)
    • 장점: 느슨한 결합, 비동기 복원력, 자연스러운 버퍼링, 로그/스트림을 통한 감사 가능성.
    • 단점: 디버깅 복잡성, 최종 일관성(eventual consistency), 순서 보장 및 정확히 한 번(exactly-once) 의미 체계 구현의 어려움.
    • Pub/Sub은 최소 한 번(at-least-once) 전송을 제공하므로, 멱등성(idempotent) 있는 소비자를 설계해야 합니다.
  • 서버리스(Serverless) (Cloud Run, Cloud Functions, App Engine)
    • 장점: 최소한의 운영, 0으로 확장(scale to zero), 요청별 오토스케일링, 통합된 보안 및 원격 측정.
    • 단점: 실행 시간 및 동시성 제한, 콜드 스타트(cold start), 플랫폼별 제약 조건.
    • 사용처: 폭증하는(bursty) 워크로드, 모바일/웹 백엔드, 이벤트 처리에 사용합니다.

통신 패턴 및 서비스 선택

• 동기식 호출과 비동기식 호출

  • 동기식(Synchronous)
    • 즉각적인 결과가 필요한 요청/응답 API에 사용합니다.
    • 프로토콜: gRPC (HTTP/2, 스트리밍, 간결한 Protobuf, 모바일 대역폭 및 강력한 계약에 탁월), HTTP/JSON (넓은 호환성, 간단한 디버깅).
    • 위험: 강한 결합 및 지연 시간 증폭. 타임아웃, 지터(jitter)를 사용한 재시도, 서킷 브레이커(circuit breaker)를 사용합니다.
  • 비동기식(Asynchronous)
    • 작업을 지연시키거나 일괄 처리할 수 있을 때 Pub/Sub 또는 Cloud Tasks를 사용합니다.
    • 이점: 트래픽 급증을 완화하고, 장애를 격리하며, 최종 완료를 통해 사용자가 인지하는 지연 시간을 개선합니다.
    • 위험: 멱등성(idempotency)과 보상 조치가 필요하며, 진행 중인 작업에 대한 가시성을 구축해야 합니다.

• Google Cloud에서의 서비스 선택 기준

  • 제어 및 이식성
    • Compute Engine: 전체 VM 제어 및 커스텀 이미지, 높은 운영 부담.
    • GKE: 이식 가능한 컨테이너 및 서비스 메시 옵션, 강력한 오토스케일링, 공동 책임 모델.
    • Cloud Run: 최소한의 운영으로 높은 컨테이너 이식성, 0으로 확장(scale-to-zero), 요청 중심.
    • App Engine: 라우팅 및 확장이 내장된 독자적인(opinionated) PaaS, 특정 언어에 대한 가장 빠른 경로.
  • 확장성 및 지연 시간
    • 에지 가속화를 위한 Cloud CDN과 함께 사용하는 전역 HTTP(S) 부하 분산.
    • 데이터스토어:
      • Cloud Spanner: 전역 일관성, 수평 확장, 다중 리전 99.999% 가용성.
      • Cloud SQL: 관리형 관계형 DB, 리전별, 리전 간 복제를 포함한 읽기 복제본.
      • Firestore: 다중 리전에서 전역 가용성을 제공하는 문서 DB, 단일 문서에 대한 강력한 일관성.
      • Cloud Bigtable: 와이드 컬럼(wide-column) 사용 사례를 위한 짧은 지연 시간과 대규모 확장성.
      • Memorystore: 핫 패스(hot path) 및 세션을 위한 짧은 지연 시간의 캐시.
  • 운영 책임
    • 핵심적인 문제(가용성, 패치, 백업, 업그레이드)에 대해서는 관리형 서비스를 선호합니다.
    • 자체 관리는 유연성을 제공하지만, 수고와 장애 발생 가능 영역을 늘립니다(예: 자체 호스팅 Kafka vs Pub/Sub).
  • 데이터 이동 및 통합
    • 짧은 지연 시간의 비공개 액세스를 위해 VPC 네이티브 연결, Private Service Connect, 내부 HTTP(S) 부하 분산을 사용합니다.
    • 서비스 검색: 클러스터 내 Kubernetes Service 이름, VM을 위한 Compute Engine 내부 DNS.

Kubernetes Service 예시 (클러스터 내 이름 검색): apiVersion: v1 kind: Service metadata: name: image-resize spec: selector: app: image-resize ports:

• port: 80 targetPort: 8080 type: ClusterIP

경계, 호환성 및 안정성 패턴

• 도메인 경계 및 소유권

  • 도메인 주도 설계를 사용하여 경계 컨텍스트(bounded context)를 정의합니다. 각 서비스는 자체 데이터를 소유하고 API/이벤트를 계약으로 게시합니다.
  • 서비스 간 데이터베이스 공유를 피하고, 잘 정의된 인터페이스와 이벤트 전파를 사용합니다.
  • 소유권은 서비스별 온콜(on-call), SLO, 릴리스 주기 및 예산 책임을 의미합니다.

• API 계약 및 하위 호환성

  • API 버전을 명시적으로 관리합니다(예: 경로 또는 헤더에 v1). 추가적인 변경을 선호하고, 필드나 동작을 깨뜨리는 변경(breaking change)을 피합니다.
  • 소비자 주도 계약 테스트와 카나리 배포를 사용합니다. 사용량에 대한 원격 측정(telemetry)과 타임라인을 가지고 서비스를 중단(deprecate)합니다.
  • 모바일 클라이언트의 경우 롱테일 버전(오래된 버전)이 존재할 것을 예상하고, 여러 API 버전을 동시에 유지 관리합니다.

• 장애 격리 및 복원력

  • 벌크헤드(Bulkhead): 서비스 또는 우선순위 클래스별로 리소스를 격리합니다(별도의 노드 풀, 인스턴스 그룹, 할당량). 최선형(best-effort) 기능이 중요 경로(critical path)의 리소스를 고갈시키는 것을 방지합니다.
  • 서킷 브레이커(Circuit breaker): 종속성(dependency)에서 연속적인 실패가 발생한 후 트립(trip)되어 부하를 차단하고 복구 시간을 허용합니다. 서비스 메시(예: Envoy), 게이트웨이 정책 또는 라이브러리를 통해 구현합니다.
  • 타임아웃 및 재시도: 지터(jitter)가 포함된 잘린 지수 백오프(truncated exponential backoff)를 사용하고 핸들러가 멱등성(idempotent)을 갖도록 보장합니다.
  • 점진적 성능 저하(Graceful degradation): 타임아웃 시 중요하지 않은 UI 구성 요소를 생략하고, 오류 대신 캐시된 데이터나 근사치를 제공합니다.
  • 헬스 체크 및 준비 상태 프로브(readiness probe): 준비된 인스턴스에만 트래픽을 라우팅하고, 활성 상태 프로브(liveness probe)를 사용하여 자가 치유(self-healing)를 수행합니다.

잘린 지수 백오프 예시 (HTTP 429): retry = 0 max_retry = 5 base = 0.5 while retry < max_retry: resp = fetch_gcs_object() if resp.status_code == 200: break if resp.status_code in (429, 500, 503): sleep = min(8, base * (2 ** retry)) + random.uniform(0, 0.25) time.sleep(sleep) retry += 1 else: raise Exception(“Non-retryable error”)

전역 및 운영 고려사항

• 전역 사용자를 위한 다중 리전 패턴

  • 전역 프런트엔드: anycast IP를 사용하는 전역 외부 HTTP(S) 부하 분산과 정적 콘텐츠를 위한 Cloud CDN을 사용합니다. 오리진(origin) 부하를 줄이기 위해 네거티브 캐싱 및 유효성 검사를 구성합니다.
  • 데이터 영역:
    • 99.999% 데이터베이스 가용성과 최소화된 전역 읽기 지연 시간을 위해 다중 리전 Cloud Spanner 인스턴스(예: nam-asia-eur1)를 사용하고, 컴퓨팅 및 쿼럼(quorum)을 위해 충분한 노드를 프로비저닝합니다(프로덕션 환경 최소 3개 노드).
    • 엄격한 전역 일관성이 필요 없는 읽기 중심 패턴의 경우, 리전 기본(primary) 데이터베이스와 리전 간 읽기 복제본(read replica)을 고려합니다. 대륙 간 더 높은 쓰기 지연 시간은 감수해야 합니다.
  • 애플리케이션 영역:
    • 자동 확장이 가능한(GKE 또는 Cloud Run) 스테이트리스(stateless) 서비스를 여러 리전에 배포합니다. 리전별로 백엔드 서비스와 네트워크 엔드포인트 그룹을 사용합니다.
    • 데이터 상주 및 규정 준수 제약 조건을 지키면서 지연 시간을 기준으로 라우팅합니다.
  • 캐시: 읽기 트래픽을 흡수하고 오리진을 보호하기 위해 Memorystore 또는 엣지 캐시를 사용자 가까이에 배치합니다.

• 관리형과 자체 관리형 비교

  • 측정항목에는 Cloud Monitoring, 로그에는 Cloud Logging, 지연 시간 및 CPU/메모리 핫스팟에는 Cloud Trace/Profiler를 사용합니다. SLO 소진율에 대한 알림 정책과 외부 가용성에 대한 가동 시간 확인을 생성합니다.
  • 기존 관측 가능성 플랫폼이 공식 기록 시스템(system of record)으로 유지되어야 하는 경우, 낮은 지연 시간의 알림을 위해 먼저 Cloud Logging으로 수집한 다음, 싱크를 통해 외부 플랫폼으로 내보냅니다.

• 현대화 및 점진적 마이그레이션

  • 스트랭글러 패턴(Strangler pattern): 모놀리스(monolith) 앞에 게이트웨이를 두고 특정 엔드포인트를 새로운 서비스로 라우팅합니다. 점진적으로 기능을 교체합니다.
  • 추상화에 의한 분기(Branch by abstraction): 종속성 주위에 인터페이스를 도입하고 그 뒤에서 구현을 교체합니다(예: 데이터베이스 또는 스토리지).
  • 안티코럽션 레이어(Anti-corruption layer): 레거시 데이터 모델과 새로운 경계 컨텍스트(bounded context) 간에 변환합니다.
  • 데이터 마이그레이션: 검증을 통한 이중 쓰기(dual writes) 또는 이벤트 소싱(event sourcing)을 사용하여 백필(backfill)합니다. 역압력(backpressure) 제어를 포함하여 전환(cutover)을 계획합니다.
  • 단계적 배포: 비즈니스 리스크를 최소화하기 위해 기능을 단계적으로 교체하고, SLO를 지속적으로 측정합니다.

• 설계 검토 및 트레이드오프 평가

  • 보안: 위협 모델, IAM 최소 권한 원칙, 임베디드 키 대신 서비스 계정 사용(GCE/GKE/Cloud Run에서 Application Default Credentials 사용), 필요한 경우 CMEK, 비공개 연결, WAF 및 비율 제한, 취약점 및 웹 보안 스캔.
  • 안정성: SLO 및 오류 예산 정의, 다중 리전 장애 조치 계획, 용량 헤드룸, 카오스 드릴(chaos drills), 종속성 맵.
  • 성능: 테일 지연 시간(tail latency) 분석, 엣지 및 오리진에서의 부하 테스트, 연결 재사용(HTTP/2, gRPC), 압축, 캐싱 전략.
  • 비용: 리소스 용량 최적화(Right-sizing), 자동 확장 정책, 약정 사용 할인, 폭증하는(bursty) 워크로드를 위한 규모 축소(scale-to-zero), 이그레스(egress) 및 CDN 오프로드.
  • 운영: 런북(Runbook), 롤백, 점진적 배포(카나리, 블루/그린), 코드형 정책(policy as code), 백업 및 DR 테스트, 인시던트 대응 통합.

실제 문제 시나리오

Nimbus Retail은 개인화된 이미지, 전 세계 p95 기준 200ms 미만의 엄격한 지연 시간 목표, 주문 데이터베이스에 대한 99.999% 가용성 요구사항을 갖춘 글로벌 이커머스 플랫폼을 출시하려고 합니다. 또한 알림 속도를 개선하면서 기존 SIEM을 유지해야 합니다.

1. Cloud Spanner를 사용하여 전역 고가용성 데이터베이스 구축

• 조치: nam-asia-eur1에 최소 3개의 노드를 갖춘 다중 리전 Spanner 인스턴스를 생성하고, 지역성(locality)을 위해 테이블을 적절한 인터리브(interleaved) 스키마로 분할합니다.
• 근거: 다중 리전 Spanner는 3개 대륙의 복제본을 통해 99.999% 가용성과 낮은 읽기 지연 시간을 제공합니다. 3개 이상의 노드는 충분한 컴퓨팅 및 복제본 쿼럼 용량을 보장합니다.

예시: gcloud spanner instances create nimbus-orders
–config=nam-asia-eur1 –description=“Global orders” –nodes=3

2. 프런트엔드 및 API 전역 배포

• 조치: 정적 애셋에는 Cloud CDN을 사용하는 전역 외부 HTTP(S) 부하 분산을 사용하고, 리전 백엔드(us-central1, europe-west1, asia-east1의 GKE 서비스)로 동적 라우팅을 사용합니다.
• 근거: Anycast VIP는 RTT를 최소화하고, CDN은 사용자 가까이에 이미지를 캐시하며, 백엔드 서비스는 가장 가까운 정상 리전으로 요청을 분산합니다.

3. 클러스터 내 디스커버리를 사용하는 GKE 기반 스테이트리스 서비스

• 조치: 수평형 포드 자동 확장(horizontal pod autoscaling)을 사용하여 GKE에 이미지 크기 조정 및 API 서비스를 배포하고, 클러스터 내 이름 기반 액세스를 위해 ClusterIP 서비스를 사용합니다. Ingress를 통해 퍼블릭 엔드포인트를 노출합니다.
• 근거: 스테이트리스 포드는 탄력적인 확장을 가능하게 합니다. Kubernetes Service는 포드 IP를 추상화하고 안정적인 DNS를 제공하여 클라이언트 결합도를 줄입니다.

4. 이벤트 기반 이미지 처리

• 조치: 이미지 처리 작업을 Pub/Sub에 게시합니다. Cloud Storage에 저장된 객체를 처리하기 위해 푸시(push) 방식으로 구독하는 Cloud Run 서비스를 실행합니다. GCS 429/5xx 오류 발생 시 지터(jitter)를 포함한 잘린 지수 백오프(truncated exponential backoff)를 구현합니다.
• 근거: Pub/Sub는 트래픽 급증을 버퍼링하고 장애를 격리합니다. Cloud Run은 메시지 단위로 확장됩니다. 백오프는 오류 증폭을 줄이고 버킷이 점진적으로 워밍업(warm up)되도록 돕습니다.

5. 관측 가능성 및 신속한 알림

• 조치: Cloud Logging과 Cloud Monitoring을 사용하여 로그와 측정항목을 수집하고, API에 대한 가동 시간 확인을 정의하며, 오류율 및 지연 시간에 대한 알림 정책을 생성합니다. 기존 SIEM으로 내보내기 위한 로그 싱크를 구성합니다.
• 근거: 네이티브 원격 분석은 낮은 지연 시간의 알림과 관리형 가동 시간 확인을 제공합니다. 내보내기 기능은 알림 속도를 희생하지 않으면서 중앙 집중식 SIEM을 유지할 수 있게 합니다.

6. 외부화된 구성 및 보안 비밀

• 조치: 보안 비밀이 아닌 구성은 ConfigMaps에 저장하고, 보안 비밀과 API 키는 GKE용 Workload Identity와 함께 Secret Manager에 저장합니다. Compute Engine 기반 작업의 경우, 배포별 값에 인스턴스 메타데이터를 사용합니다.
• 근거: 외부화된 구성은 불변 이미지(immutable images)와 환경별 설정을 가능하게 합니다. 보안 비밀을 코드에 포함하는 것을 방지합니다. 메타데이터는 코드 변경 없이 VM의 가변성을 지원합니다.

7. 장애 격리 및 정상적인 기능 저하(Graceful Degradation)

• 조치: 최선 노력(best-effort) 개인화 워크로드를 위해 별도의 노드 풀로 벌크헤드(bulkhead)를 적용합니다. 개인화 서비스에 대해 요청 예산과 서킷 브레이커(circuit breaker)를 강제합니다. UI에서는 종속성 타임아웃 시 중요하지 않은 위젯을 생략합니다.
• 근거: 용량을 격리하면 최선 노력 기능이 결제 기능을 고갈시키는 것을 방지합니다. 서킷 브레이커는 장애 영향 범위(blast radius)를 제한합니다. 정상적인 기능 저하는 핵심 사용자 경험(core journey)을 보존합니다.

8. API 계약 및 호환성

• 조치: 웹용으로는 HTTP/JSON 트랜스코딩을 사용하는 모바일 클라이언트(v1)용 gRPC 계약을 정의합니다. 추가적인 변경 사항만 채택하고 모바일 출시 기간 동안 최소 두 가지 버전을 유지합니다.
• 근거: gRPC는 대역폭을 줄이고 강력한 타입(strong typing)을 제공합니다. 트랜스코딩은 브라우저 및 파트너 통합을 용이하게 합니다. 버전 관리는 이전 버전과의 호환성을 유지합니다.

9. 보안 및 ID

• 조치: 서비스별 Google 서비스 계정과 최소 권한 IAM을 사용하고, Application Default Credentials에 의존합니다. 엣지 보호를 위해 Cloud Armor를 활성화하고 모든 곳에서 TLS를 강제합니다.
• 근거: Workload Identity는 키 관리 위험을 제거합니다. WAF와 비율 제한은 악용을 완화합니다. 전송 중 암호화는 기본이며 필수입니다.

10. 지속적 배포 및 릴리스 안전성

• 조치: 부하 분산기에서 백분율 기반 트래픽 분할을 사용하는 카나리 릴리스를 구현하고, SLO 소진 알림 시 자동 롤백을 설정합니다. 리전별로 블루/그린 환경을 유지합니다.
• 근거: 점진적 배포는 위험을 제한합니다. 리전별 블루/그린은 롤백 속도를 높이고 버전 관리되는 API와 연계하여 안전한 스키마 마이그레이션을 가능하게 합니다.

모든 도메인 · 컴퓨트 →

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

Google 찾아보기 →