Google Cloud에서 Event-Driven Architecture 재정의
I’m ready to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you specify.
Eventarc와 Direct Pub/Sub 선택하기
| Feature | Eventarc | Direct Pub/Sub |
|---|---|---|
| 추천 용도 | GCP‑native events (GCS, Firestore, Audit Logs) → GCP 기본 이벤트 (GCS, Firestore, 감사 로그) | Custom inter‑service messaging → 맞춤형 서비스 간 메시징 |
| 설정 | Managed wrapper, high convenience → 관리형 래퍼, 높은 편의성 | Manual configuration, high control → 수동 설정, 높은 제어권 |
| 필터링 | Built‑in attribute filtering → 내장 속성 필터링 | Fine‑grained policies & custom attributes → 세밀한 정책 및 맞춤 속성 |
| IAM | Uses eventarc.eventReceiver → eventarc.eventReceiver 사용 | Uses pubsub.subscriber → pubsub.subscriber 사용 |
팁: Google Cloud 이벤트의 “배관” 역할을 위해서는 Eventarc를 사용하세요. 맞춤형 이벤트 버스나 특정 재시도/정렬 로직이 필요할 때는 Direct Pub/Sub를 사용하세요.
전달 보장 및 멱등성
- Pub/Sub는 기본적으로 최소 1회 전달을 보장합니다.
- 정확히 한 번 전달은 선택적 기능으로 제공되지만, 소비자는 여전히 중복이 발생할 수 있다고 가정해야 합니다.
- 핸들러가 멱등하지 않으면 사용자를 이중 청구하거나 상태가 손상될 위험이 있습니다.
비협상적 멱등성 흐름
- 이벤트에서 고유 멱등성 키(UUID/Hash)를 추출합니다.
- 빠른 접근 캐시(Memorystore 또는 Firestore)에서 키를 확인합니다.
- 존재한다면, 중복 메시지로 간주하고 폐기합니다.
- 존재하지 않으면, 이벤트를 처리하고 TTL과 함께 키를 저장합니다.
콜드 스타트 및 지연
- Cloud Run의 “scale to zero”(제로 스케일링)는 예산을 절감하지만 첫 번째 요청에 2–8 seconds의 지연을 추가합니다.
- Fix: 지연에 민감한 경로에
min‑instances를 설정합니다(비용이 발생합니다). - Alternative: 시작 시간 오버헤드가 덜 중요한 비동기 배치 처리에는 Cloud Run Jobs를 사용합니다.
배포 고려 사항
- Terraform 또는 CLI를 통해 Eventarc 트리거를 배포할 때, 필터링 규칙이 Google 네트워크 전역에 전파되는 데 60–120 초가 걸릴 수 있습니다.
- 프로덕션 해결책: CI/CD 파이프라인에 “워밍‑업” 지연을 삽입하십시오. 배포가 성공한 직후에 통합 테스트를 바로 트리거하지 않으면 간헐적인 오탐(거짓 양성) 실패를 방지할 수 있습니다.
규모에 따른 비용
| 구성 요소 | 예상 비용 |
|---|---|
| Pub/Sub (수집 + 전송) | 0.286 TiB × $40 × 2 ≈ $23/월 |
| Cloud Run (3억 호출, 1 초, 512 MiB) | $150–$200/월 |
| 총합 | ≈ $175–$225/월 |
가정: 하루 1,000만 이벤트 (≈ 3억/월), 최소 메시지 크기 1 KB, 실행 시간 1 초, RAM 512 MiB.
메시지 크기와 호출 지속 시간을 모니터링하면 비용을 예측 가능하게 유지할 수 있습니다.
Region Mapping & Egress
- 멀티‑리전 서비스(예: Firestore
nam5)에 대한 Eventarc 트리거는 종종 특정 리전(예:us-central1)에 고정됩니다. - Cloud Run 서비스가 다른 리전에 있으면 cross‑region egress charges가 발생하고 지연 시간이 증가합니다.
- GCP 문서의 리전 매핑 표를 항상 확인하십시오.
고급 Eventarc: CEL 변환
Eventarc Advanced를 사용하면 **Common Expression Language (CEL)**을 이용해 페이로드를 소비자에게 전달되기 전에 변환하거나 민감 정보를 삭제할 수 있습니다—PII(개인 식별 정보) 준수를 위해 필수적입니다.
// Example: Redacting an email address in‑flight
message.setField("data.email",
re.extract(message.data.email, "(^.).*@(.*)", "\\1***@\\2"));신뢰성 패턴
- Dead‑Letter Topics (DLTs): 모든 구독에는 데드레터 토픽이 있어야 합니다.
- Alerting:
subscription/dead_letter_message_count메트릭을 모니터링하세요; 카운트가 증가하면 로직 버그나 스키마 불일치를 나타냅니다. - Tracing: OpenTelemetry를 사용해 Trace ID를 이벤트 속성에 주입하면, 프로듀서에서 버스를 거쳐 컨슈머 로그까지 단일 요청을 추적할 수 있습니다.
이 아키텍처를 사용하면 안 되는 경우
Skip Eventarc + Cloud Run if:
- 강력한 일관성 및 즉시 트랜잭션이 필요합니다.
- 엔드‑투‑엔드 지연 시간 요구사항이 100 ms 미만입니다.
- 분산 트레이스 디버깅의 오버헤드가 확장성 이점을 능가합니다.
In these cases, consider synchronous gRPC/HTTP or Cloud Workflows for structured orchestration.
결론
Cloud Run과 Eventarc의 조합은 2026년에도 가장 견고한 패턴 중 하나로 남아 있습니다. 플랫폼 경계를 존중하고—전파 지연을 고려하며, 멱등성을 보장하고, 지역을 동일하게 배치함으로써—시스템을 제로에서 수백만 개의 이벤트까지 손쉽게 확장할 수 있습니다.