Google PCD: API 설계, 통합 및 이벤트 기반 개발 — 학습 가이드
다음의 일부입니다: Google Professional Cloud Developer — 학습 가이드. 검증된 답안으로 연습하기: Google 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.
개요
Google Cloud에서의 최신 애플리케이션 통합은 잘 설계된 동기식 API와 복원력 있는 비동기 및 이벤트 기반 패턴을 결합합니다. 목표는 명확한 명세, 강력한 ID, 일관된 오류 처리, 그리고 장애, 확장 또는 변경 상황에서도 지연 시간을 낮고 가용성을 높게 유지하는 운영 제어 기능을 제공하는 것입니다. 이 섹션에서는 프로토콜 및 API 선택, 게이트웨이 및 인증, 메시징 및 이벤트 라우팅, 백그라운드 작업, 오케스트레이션, 서비스 간 ID 및 신뢰, 안정성 패턴, 보안 웹훅, 안전한 스키마 진화에 대해 다룹니다.
API 설계 및 관리
올바른 프로토콜 선택:
- REST: 사람이 읽기 쉬우며, HTTP를 통해 캐시할 수 있어 퍼블릭 및 파트너 API에 적합합니다. 리소스 지향 설계, 표준 메서드, ETags를 사용하고, HATEOAS는 가치가 있을 때만 사용합니다. 단점: protobuf보다 명세가 덜 정밀하고, 오버/언더 페칭 가능성이 있습니다.
- gRPC: Protobuf 명세, 양방향 스트리밍, 효율적인 바이너리 전송을 사용하며, 지연 시간이 짧은 내부 서비스 간 호출에 매우 적합합니다. 단점: 브라우저 지원에 gRPC-Web이 필요하며, 퍼블릭 클라이언트에 대한 관측성 및 호환성 확보가 더 어려울 수 있습니다.
- GraphQL: 복합 뷰에 대한 라운드 트립을 줄여주는 유연한 쿼리 방식입니다. 단점: 복잡한 리졸버, N+1 문제 위험, 캐싱 문제, 접근 제어의 미묘한 차이 등이 있습니다.
버전 관리 및 페이지네이션:
- 추가적이고 하위 호환성을 갖춘 변경을 선호합니다. URI 기반 주 버전(예: /v1)을 사용하고, 필드와 기능 플래그를 통해 부 버전을 관리합니다. 명확한 일정을 가지고 지원을 중단합니다.
- 데이터 변경 시 일관성 없는 페이지가 생기는 것을 방지하기 위해 안정적인 커서나 nextPageToken으로 페이지네이션을 구현합니다. 대규모 데이터셋에는 오프셋 사용을 피합니다.
유효성 검사 및 오류:
- REST 요청/응답 스키마에는 OpenAPI를, gRPC에는 protobuf 유효성 검사 규칙을 사용합니다.
- 일관된 오류 모델을 채택합니다. 표준 HTTP 상태 코드로 매핑하고, gRPC의 경우 google.rpc.Status(코드, 메시지, 세부정보)를 사용합니다. 기계가 파싱할 수 있는 오류 원인과 상관관계 ID를 포함합니다. 내부 정보 유출을 방지합니다.
API 관리 선택지:
- API Gateway: OpenAPI/gRPC 백엔드(Cloud Run, Cloud Functions, GKE, Compute Engine)를 위한 경량의 관리형 게이트웨이입니다. 인증, API 키, JWT 유효성 검사, 할당량을 지원합니다. 서버리스 및 간단한 제어 플레인에 적합합니다.
- Cloud Endpoints (ESPv2): 서비스와 함께 배포되며, OpenAPI 또는 gRPC 트랜스코딩, 인증, 할당량, 측정항목을 지원합니다. 워크로드와 프록시를 함께 배치하는 것이 선호될 때 좋습니다.
- Apigee: 고급 정책(스파이크 방지, 할당량, 중재, 변환, OAuth 제공자, 수익화, 개발자 포털)을 갖춘 전체 수명 주기 API 관리 솔루션입니다. 복잡한 파트너 생태계와 남-북 트래픽 제어에 가장 적합합니다.
인증 및 할당량:
- 최종 사용자에게는 OAuth 2.0 또는 Firebase Authentication을, 서비스에는 Google 서명 ID 토큰(OIDC) 또는 OAuth 서비스 계정 토큰(2-legged)을 사용합니다.
- 백엔드를 보호하기 위해 클라이언트에 가까운 위치(Apigee)에서, 그리고 소비자별(API 키 또는 클라이언트 자격 증명)로 할당량 및 스파이크 방지를 적용합니다.
Cloud Run 백엔드 및 OIDC를 사용하는 최소한의 API Gateway OpenAPI 예시:
openapi: 3.0.0
info: {title: orders, version: 1.0.0}
paths:
/v1/orders:
get:
security: [{firebase: []}]
x-google-backend: {address: https://orders-xyz-uc.a.run.app}
responses: {"200": {description: OK}}
components:
securitySchemes:
firebase:
type: http
scheme: bearer
bearerFormat: JWT
x-google-issuer: https://securetoken.google.com/PROJECT_ID
x-google-audiences: PROJECT_ID
비동기 메시징 및 이벤트 처리
Pub/Sub 기본 사항:
- Topic과 Subscription은 게시자와 소비자를 분리합니다. 전달은 최소 한 번(at-least-once) 보장되며, 중복 및 순서 변경이 발생할 수 있습니다.
- 처리가 길어지면 확인(ack)을 사용하고 ack 마감 시간을 연장합니다. 메모리 압박을 피하기 위해 클라이언트 흐름 제어를 적용합니다.
- 순서 지정: 메시지 순서 지정을 활성화하고 순서 지정 키를 제공하여 키별 순서 보장 전달을 구현합니다. 가능하면 키당 단일 활성 게시자를 유지합니다.
- 데드 레터: 포이즌 메시지를 담고 무한 재시도를 방지하기 위해 데드 레터 토픽을 구성합니다. 이를 모니터링하고 분류합니다.
Topic, Subscription, DLQ 생성:
gcloud pubsub topics create orders
gcloud pubsub topics create orders-dlq
gcloud pubsub subscriptions create orders-sub \
--topic=orders \
--dead-letter-topic=orders-dlq \
--max-delivery-attempts=5 \
--ack-deadline=30
소비자 측 고려사항: 멱등성 핸들러와 중복 제거(예: messageId 또는 애플리케이션 수준 멱등성 키 사용)를 구현합니다. 일시적인 오류는 백오프를 적용하여 재시도하고, 복구 불가능한 메시지는 DLQ로 이동시킨 후 알림을 보냅니다.
Eventarc 및 CloudEvents:
- Eventarc는 Google Cloud 서비스, 커스텀 소스, 감사 로그의 이벤트를 Cloud Run, Cloud Functions 또는 GKE로 라우팅합니다. 이벤트는 CloudEvents 봉투(envelope)(id, source, type, subject, time)를 사용합니다.
- 트리거에서 속성(type, subject, location)으로 필터링하여 노이즈와 비용을 줄입니다. 최소 권한 원칙에 따라 전용 서비스 계정을 사용합니다.
Cloud Storage 객체 생성 완료에 대한 Eventarc 트리거 생성:
gcloud eventarc triggers create index-new-objects \
--destination-run-service=media-indexer \
--destination-run-region=us-central1 \
--event-filters="type=google.cloud.storage.object.v1.finalized" \
--event-filters="bucket=my-assets-bucket" \
--service-account=eventarc-router@PROJECT_ID.iam.gserviceaccount.com
장단점:
- Pub/Sub는 풀(pull) 방식에 최적화되어 있으며 높은 처리량에 대해 복원력이 뛰어납니다. Eventarc는 제어할 수 없는 생산자로부터의 라우팅을 단순화하고 표준화된 메타데이터와 함께 서비스로 푸시(push)합니다.
- 엄격한 순서 보장이나 비용에 대한 엄격한 상한선이 필요한 경우, 게시자 측에서 파티셔닝 및 속도 제한을 고려합니다. 매우 낮은 지연 시간의 팬아웃을 위해서는 구독자 동시성을 신중하게 조정합니다.
오케스트레이션, 백그라운드 작업 및 장기 실행 프로세스
Cloud Tasks:
- 안정적인 백그라운드 HTTP 호출을 위한 푸시(push) 큐입니다. 백엔드를 보호하기 위해 큐별 전달 속도와 동시성을 설정합니다. 지수 백오프와 최대 시도 횟수를 포함한 재시도를 구성합니다.
- 결정론적 작업 이름이나 Idempotency-Key 헤더를 사용하여 멱등성을 보장하고 서버 측에서 중복을 제거합니다. 빠르게 응답(2xx)하고, 필요한 경우 무거운 작업은 비동기적으로 수행합니다.
속도 제한 및 재시도가 설정된 큐 생성:
gcloud tasks queues create payments-queue \
--max-dispatches-per-second=50 \
--max-concurrent-dispatches=200 \
--max-attempts=10 \
--min-backoff=5s \
--max-backoff=300s
Workflows:
- HTTP 및 Google Cloud 커넥터를 통해 다단계 비즈니스 프로세스를 오케스트레이션합니다. 부분적 실패에 대비해 보상 작업(사가 패턴)을 모델링하고, 분산 트랜잭션은 피합니다.
- 단계별 타임아웃 및 재시도 정책을 사용합니다. 중단 후 재개할 수 있도록 재시도 간 상태를 유지합니다. 장기 실행 작업을 폴링하고 마감 시간에 취소합니다.
보상 로직 스케치:
main:
params: [orderId]
steps:
- charge:
call: http.post
args: {url: ${paymentsUrl}/charge, auth: {type: OIDC}, body: {orderId: ${orderId}}}
result: chargeRes
- reserveInventory:
try:
steps:
- reserve:
call: http.post
args: {url: ${inventoryUrl}/reserve, auth: {type: OIDC}, body: {orderId: ${orderId}}}
except:
as: e
steps:
- refund:
call: http.post
args: {url: ${paymentsUrl}/refund, auth: {type: OIDC}, body: {paymentId: ${chargeRes.body.id}}}
- raise: ${e}
운영 가이드:
- 단일 서비스에 대해 정밀한 속도 제어가 필요한 ‘실행 후 망각(fire-and-forget)’ 방식의 백그라운드 HTTP 작업에는 Cloud Tasks를 선호합니다. 팬아웃 및 다중 소비자를 위해서는 Pub/Sub를 사용합니다. 분기 로직과 보상 작업이 포함된 여러 호출을 조정해야 할 때는 Workflows를 사용합니다.
ID, 안정성 및 통합
서비스 간 ID 및 토큰 전파:
- Cloud Run/Functions/Compute Engine/GKE 워크로드는 최소 권한의 서비스 계정을 사용해야 합니다. GKE에서는 노드 수준의 자격 증명을 피하기 위해 Workload Identity를 사용합니다.
- Cloud Run에서 다른 Cloud Run을 호출할 때는 대상 URL과 일치하는 audience를 가진 ID 토큰을 사용해 호출합니다. 다운스트림이 호출자를 대신하여 작동해야 할 때만 ID를 전파하고, 그렇지 않은 경우에는 피호출자의 서비스 계정을 사용합니다.
Cloud Run에서 ID 토큰 가져오기:
AUD="https://inventory-xyz-uc.a.run.app"
TOKEN=$(curl -s -H "Metadata-Flavor: Google" \
"http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUD}")
curl -H "Authorization: Bearer ${TOKEN}" "${AUD}/v1/check"
동기식 종속성과 복원력:
- 클라이언트 타임아웃을 업스트림 타임아웃보다 낮게 설정하고, 홉(hop)당 예산을 할당합니다. 멱등성(idempotent) 작업에 대해서만 잘린 지수 백오프(truncated exponential backoff) 및 지터(jitter)를 사용하여 재시도합니다. 총 재시도 시간을 제한하여 재시도 폭풍(retry storm)을 방지합니다.
- 업스트림이 비정상일 때 서킷 브레이커를 사용하여 빠르게 실패(fail fast)하도록 합니다. GKE/Apigee/Envoy에서는 최대 보류 요청, 실패 시 축출, 상태 프로브를 구성할 수 있습니다. 합리적인 폴백(fallback)을 제공하거나 정상적으로 성능을 저하(gracefully degrade)시킵니다.
- 일시적인 오류(429, 408, 500–503)는 재시도 가능한 동작으로 매핑하고, 4xx(408/429 제외)는 재시도 불가능한 것으로 처리합니다.
웹훅 및 서드파티 통합:
- 공유 비밀키 또는 서명된 JWT를 사용하는 HMAC 서명 헤더로 인바운드 요청을 확인합니다. 더 높은 보증 수준이 필요하면 mTLS를 사용합니다. 비밀번호는 Secret Manager에 저장하고 정기적으로 순환시킵니다.
- 신속하게 확인 응답(acknowledge)하고, 무거운 처리를 분리(decouple)하기 위해 Cloud Tasks에 큐로 보내거나 Pub/Sub에 게시합니다. 백엔드를 보호하기 위해 인바운드 IP 또는 키에 대한 비율 제한(rate-limit)을 적용합니다.
- 아웃바운드 웹훅: 안전한 재시도를 허용하기 위해 Idempotency-Key를 포함하고, 원격 TLS 인증서 및 호스트 이름을 확인합니다.
스키마 진화 및 호환성:
- REST/JSON: 필드를 추가하는 것은 안전합니다. 기존 필드의 용도를 변경하거나 타입/의미를 바꾸지 마십시오. 더 이상 사용되지 않는(deprecated) 필드는 표시하고 일정 기간 동안 계속 제공합니다.
- Protobuf/gRPC: 필드 번호를 재사용하지 말고, 예약된(reserved) 태그를 사용하며, 선택적(optional) 필드를 선호합니다. 기본값 설정 및 존재 여부 시맨틱은 호환성에 중요합니다.
- 이벤트: dataVersion을 포함하고 CloudEvents 속성을 안정적으로 유지하며, 확장을 위한 공간을 예약합니다. Pub/Sub에서는 게시 시점에 검증하기 위해 Pub/Sub Schema(Avro/Protobuf)를 고려합니다.
- 테스트: 소비자 주도 계약 테스트, 에뮬레이터(Pub/Sub, Datastore/Firestore) 또는 격리된 프로젝트, 그리고 카나리 출시를 사용합니다. 임시(ephemeral) 환경과 현실적인 할당량을 사용하여 CI에서 통합 테스트를 실행하여 잠재적 장애를 노출시킵니다.
스택 전반의 보안 및 할당량:
- 에지(API Gateway/Apigee/Endpoints)와 서비스에서 인증을 강제합니다. 소비자별 할당량과 스파이크 방지(spike arrest)를 적용합니다. 401/403 급증 및 429 비율을 모니터링하여 클라이언트 백오프 및 할당량을 조정합니다.
- 구성 요소 전반에 걸쳐 요청 ID를 로깅하고, 엔드투엔드 가시성을 위해 추적 헤더(Traceparent 또는 X-Cloud-Trace-Context)를 전파합니다.
실용적인 문제 시나리오
AcmeRetail은 Google Cloud에서 클릭 앤 콜렉트(click-to-collect) 서비스를 구축하고 있습니다. React 웹 앱이 공개 API를 호출하여 주문을 하면, 백엔드 서비스는 재고를 예약하고, 결제를 청구하며, 매장에 알려야 합니다. 이 팀은 짧은 지연 시간의 API, 안정적인 백그라운드 처리, 이벤트 기반 업데이트, 부분 실패 시 안전한 롤백이 필요합니다.
접근 방식:
- Cloud Run 주문 서비스 앞에 API Gateway를 통해 공개 REST API를 노출합니다.
- 근거: JSON을 사용하는 REST는 브라우저에 간단합니다. API Gateway는 Firebase Auth의 JWT를 검증하고, 클라이언트별 API 키와 할당량을 강제하며, 에지에서 연결을 종료합니다. Cloud Run은 트래픽 급증에 따라 자동 확장됩니다.
- 내부 핫패스(hot path, 주문에서 재고, 가격 책정)에 대한 서비스 간 호출은 gRPC로 구현합니다.
- 근거: gRPC는 직렬화 오버헤드를 줄이고 엄격한 계약을 제공합니다. 서비스 간에는 Workload Identity(GKE) 또는 서비스 계정(Cloud Run)과 OIDC를 사용합니다. 멱등성 읽기 작업에 대해 타임아웃은 300ms로 설정하고, 2번의 재시도와 지터를 적용합니다.
- Workflows를 사용하여 주문 사가(saga)를 오케스트레이션합니다: 결제 청구, 재고 예약, 픽업 작업 생성, 실패 시 보상 트랜잭션 실행.
- 근거: 중앙 집중식 오케스트레이션은 장기 실행 단계와 보상 트랜잭션을 관리합니다. 재고 예약이 실패하면 Workflows는 환불을 트리거하고 클라이언트에게 409를 반환합니다.
- 다운스트림 소비자(분석, 매장 알림)를 위해 Pub/Sub의
orders및inventory토픽에 도메인 이벤트를 게시합니다.
- 근거: 강한 결합 없는 팬아웃(Fanout) 방식입니다. 구독자는
orderId를 키로 하는 멱등성을 구현합니다. 구독에는max-delivery-attempts=10으로 설정된 데드 레터 토픽(DLQ)이 있으며, DLQ 증가 시 알림이 발생합니다.
- 관련된 Cloud Storage 및 Firestore 변경 시 Eventarc를 통해 Cloud Run 알림 서비스로 매장 알림을 트리거합니다.
- 근거: Eventarc는 속성 필터를 사용하여 필요한 이벤트만 라우팅합니다. CloudEvents는 일관된 메타데이터를 보장합니다. 알림 서비스는 Cloud Tasks를 사용하여 비율과 재시도를 제어하면서 서드파티 SMS/이메일 제공업체에 게시합니다.
- API Gateway를 앞에 둔 전용 Cloud Run 엔드포인트로 결제 제공업체 웹훅을 처리하고, HMAC 서명을 확인하며, 처리를 위해 Cloud Tasks를 사용합니다.
- 근거: 신속한 200 OK 확인 응답은 제공업체의 재시도를 줄입니다. Tasks는 백오프를 통한 재시도를 보장합니다. 비밀 정보는 Secret Manager에 저장되고, 요청 본문은 OpenAPI 스키마에 대해 검증됩니다.
- 안정성 패턴을 강제합니다: 결제 제공업체로의 아웃바운드 호출에 대해 Apigee 또는 Envoy에서 서킷 브레이커 사용, 클라이언트 타임아웃을 제공업체 SLA보다 낮게 설정, 429/5xx에 대해 잘린 지수 백오프를 사용한 재시도.
- 근거: 연쇄 장애와 재시도 폭풍을 방지하고, 서드파티의 제한을 존중하며, 일시적인 과부하를 정상적인 성능 저하로 전환합니다.
- 스키마 진화 제어를 채택합니다: 내부 gRPC에는 예약된 필드가 있는 Protobuf 사용, REST 응답에는 추가적인 JSON 변경 사용, Pub/Sub는 게시 시점에 Protobuf 스키마 유효성 검사 사용.
- 근거: 소비자 호환성을 유지합니다. 계약 및 통합 테스트는 각 병합 시 Cloud Build에서 실행되며, 카나리 배포는 실제 트래픽을 안전하게 검증합니다.
- 관찰 및 운영: API Gateway와 서비스 간에 추적 헤더를 전파하고, 오류율 및 DLQ 크기에 대한 Cloud Logging 메트릭을 내보내며, SLO 소진 및 429/5xx 이상 징후에 대해 알림을 설정합니다.
- 근거: 회귀(regression), 할당량 문제 또는 제공업체 인시던트를 신속하게 감지합니다. SRE는 할당량과 백오프 정책을 신속하게 조정할 수 있습니다.
← 컴퓨트 · 모든 도메인 · 애플리케이션 데이터 →
이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
시험 합격하기 →