Google PCA: 운영, 관측 가능성 및 플랫폼 자동화 — 학습 가이드

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

개요

Google Cloud의 운영, 관측 가능성 및 플랫폼 자동화는 보안과 비용을 제어하면서 서비스가 진단 가능하고, 유지보수 가능하며, 지속적으로 개선되도록 보장합니다. 일관성 있는 설계는 로깅, 메트릭, 추적, 감사 기능, 런북, 인시던트 대응, 할당량 및 용량 거버넌스, 자동화를 포괄합니다. 목표는 서비스 수준 목표(SLO)와 연결된 실행 가능하고 노이즈가 적은 신호를 확보하고, 반복적인 수작업(toil)과 구성 드리프트를 줄이는 결정론적 자동화를 결합하는 것입니다.

로깅 및 감사 기능

Cloud Logging은 Google Cloud 서비스, GKE, VM의 로그를 중앙에서 수집합니다. request_id, user_id, service, version, latency_ms, severity와 같은 일관된 키를 사용하는 구조화된 로그(JSON)를 사용하는 것이 좋습니다. 구조화된 데이터는 정확한 쿼리, 로그 기반 메트릭, 정책 평가를 가능하게 합니다. VM 및 GKE 노드에서는 Ops Agent(권장) 또는 기존 로깅 에이전트를 설치하여 시스템 및 애플리케이션 로그를 수집하고, 파서가 프레임워크에 맞게 JSON을 출력하도록 해야 합니다.

• 로그 버킷 및 보관: 데이터 상주(data residency) 및 CMEK(고객 관리 암호화 키)를 위해 리전 단위 로그 버킷을 사용하세요. 기본 버킷에는 _Default와 _Required가 포함됩니다. 후자는 관리자 활동, 시스템 이벤트, 정책 거부 감사 로그를 고정된 장기 보관 기간으로 저장합니다. 데이터 클래스(예: 앱, 보안, 분석)별로 전용 버킷을 생성하고 맞춤형 보관 기간과 CMEK를 설정하세요. 보관 기간이 길어지면 포렌식 분석에 유리하지만 비용이 증가합니다. Logging에서의 보관이 필요하지 않은 경우 장기 보관을 위해 내보내기를 사용하세요.

• 로그 싱크 및 내보내기: 로그 라우터를 사용하여 싱크를 통해 BigQuery(분석), Pub/Sub(SIEM 또는 파이프라인), Cloud Storage(보관)로 로그를 라우팅하세요. 파티션 분할된 BigQuery 테이블을 사용하여 데이터 양과 비용을 관리하세요. 조용한 실패(silent failure)를 방지하기 위해 싱크 서비스 계정에는 대상에 대한 최소 권한의 쓰기 액세스 권한을 항상 부여해야 합니다. 내보낸 로그를 다시 Logging으로 수집하지 않음으로써 라우팅 루프를 방지하세요.

• 쿼리 및 로그 기반 메트릭: 로그 탐색기에서 logName, resource.type, severity, labels, jsonPayload 필드에 필터를 사용하여 쿼리하세요. 오류율 SLI 및 지연 시간 히스토그램을 위해 로그 기반 메트릭(카운터 또는 분포)을 생성하여 알림을 지원하세요. 변동성이 큰 필드를 정규화하여 카디널리티를 제어하세요.

• Cloud 감사 로그: 관리자 활동(제어 영역 쓰기), 데이터 액세스(사용자 데이터 읽기/쓰기), 시스템 이벤트, 정책 거부 로그는 관리적 관측 가능성을 제공합니다. 데이터 액세스 로그는 양이 많아 대부분의 서비스에서 기본적으로 비활성화되어 있습니다. 필요한 경우에만 활성화하고 적절한 보관 기간과 CMEK가 설정된 버킷으로 라우팅하세요. 정책 거부 로그는 권한 및 조직 정책 위반을 조기에 감지하는 데 도움이 됩니다. 관리상 분리를 보장하세요. 일반적으로 보안팀이 감사 로그를 소유하고 접근하며, 다른 팀에게는 제한된 보기만 제공됩니다.

• 장애 모드 및 절충안:

  • 너무 광범위한 싱크는 BigQuery 비용을 폭증시킵니다. 정확하게 필터링하고 파티션을 만료시키세요.
  • 고카디널리티 JSON 필드(예: 전체 URL)는 쿼리 성능을 저하시킵니다. 데이터를 정제하고 정규화된 라벨을 추출하세요.
  • 불충분한 보관 기간은 조사를 방해합니다. GCS나 BigQuery로 내보내면 이를 완화할 수 있습니다.
  • 에이전트 누락이나 파서 설정 오류는 조용한 로그 손실을 유발합니다. 에이전트 하트비트 및 수집 오류에 대해 알림을 설정하세요.

예시: 리전 로그 버킷을 커스텀 보관 기간으로 생성하고 필터링된 감사 싱크를 내보냅니다.

undefined

undefined

모니터링, 추적 및 애플리케이션 진단

Cloud Monitoring은 시스템 및 애플리케이션 메트릭을 수집하고, 대시보드, 알림, 가동 시간 확인, 알림 채널, 서비스 수준 목표를 지원합니다.

• 메트릭 및 대시보드: Google 서비스를 위한 내장 메트릭을 사용하고, Cloud Monitoring API 또는 OpenTelemetry를 통해 커스텀 메트릭을 생성하세요. 네 가지 골든 시그널인 지연 시간, 트래픽, 오류, 포화 상태를 강조하세요. 라벨은 신중하게 적용하고, 무한한(unbounded) 라벨 값은 피하세요. 측정항목 범위를 사용하여 여러 프로젝트의 뷰를 집계하세요. 필요할 때 표현력이 풍부한 쿼리를 위해 MQL을 사용하세요.

• 알림 및 알림 채널: 빠른 탐지와 노이즈 감소의 균형을 맞추기 위해 SLO에 대해 다중 기간, 다중 소진율 알림을 구현하세요. 알림 채널(이메일, SMS, Pub/Sub, 웹훅, 서드파티 인시던트 도구)을 정의하고, 알림 문서에 런북 링크와 컨텍스트를 포함하세요. 알림 폭풍(alert storm)을 방지하기 위해 알림 속도 제한과 인시던트 자동 종료를 사용하세요.

• 가동 시간 확인: 여러 리전에서 TLS 검증, DNS, 콘텐츠 일치 기능을 사용하여 중요한 엔드포인트를 프로빙하세요. 가동 시간 확인을 알림 및 서비스 SLO와 연결하세요. 가동 시간 확인은 내부 종속성을 검증하지 않는다는 점을 기억하세요. 합성 트랜잭션과 내부 상태 확인으로 보완해야 합니다.

• SLO 및 SLI: 가용성, 지연 시간, 정확성에 대한 SLI를 정의하세요. Cloud Monitoring의 서비스 모니터링에서 SLO를 구성하고 오류 예산을 추적하세요. 고객 영향에 맞춰 원시 오류가 아닌 예산 소진에 대해 알림을 설정하세요. 남은 오류 예산을 준수하기 위해 릴리스 게이트나 점진적 배포를 사용하세요.

• Cloud Trace, Error Reporting, Profiler: OpenTelemetry를 사용하여 서비스 전반에 걸쳐 분산 추적을 구현하고, 요청 및 종속성 메타데이터로 스팬(span)에 주석을 추가하세요. 비용을 제어하면서 중요한 흐름을 확실히 커버할 수 있도록 서비스별, 경로별로 샘플링을 동적으로 조정하세요. Error Reporting은 로그에서 예외를 자동으로 집계하고, 스택 트레이스별로 중복을 제거하며, 알림을 트리거합니다. Profiler는 프로덕션 환경에서 낮은 오버헤드로 지속적인 CPU, 힙, 벽 시간(wall-time) 프로필을 제공합니다. 이를 사용하여 핫 경로(hot path)를 제거하고 비용을 절감하세요.

• 장애 모드 및 절충안:

  • 과도한 메트릭 카디널리티는 비용을 증가시키고 쿼리를 느리게 합니다. 내보내기 전에 집계하세요.
  • 낮은 추적 샘플링 비율은 꼬리 지연 시간(tail latency) 문제를 숨길 수 있습니다. 느린 경로에 대해서는 더 높은 비율로 샘플링하세요.
  • 잘못 정렬된 SLO(예: 너무 엄격한)는 알림 피로를 유발합니다. 실제 트래픽 데이터로 반복하여 개선하세요.
  • 내부 종속성이 실패해도 가동 시간 확인은 통과할 수 있습니다. 종속성을 인지하는 SLO를 사용하세요.

플랫폼 운영, Runbook 및 인시던트 관리

운영의 엄격함은 평균 탐지 시간, 완화 시간, 학습 시간을 줄여줍니다.

• Runbook 및 에스컬레이션: 모든 알림은 사전 조건, 진단 단계, 롤백, 커뮤니케이션 템플릿을 포함하는 결정론적인 Runbook에 연결되어야 합니다. 명확한 온콜(on-call) 순환 및 에스컬레이션 정책을 정의하십시오. Runbook을 버전 제어 시스템에 저장하고 테스트하십시오.

• 인시던트 관리 및 사후 분석: 표준화된 심각도, 역할(인시던트 커맨더, 커뮤니케이션, 운영, SME), 채널을 사용하십시오. 광범위한 전파를 위해 ChatOps와 상태 페이지를 사용하는 것을 선호합니다. 타임라인, 기여 요인, 탐지 격차, 고객 영향, 담당자 및 날짜와 연결된 구체적인 후속 조치를 포함하는 비난 없는(blameless) 사후 분석을 작성하십시오.

• 할당량 관리 및 용량 신호: 사용량 비율에 대한 알림을 설정하여 Service Usage 및 serviceruntime 할당량 측정항목을 모니터링하십시오. 사전 예방적으로 할당량 증가를 요청하고 자동 확장(autoscaling) 한도를 할당량에 맞게 조정하십시오. CPU, 메모리, 파일 디스크립터, 연결 풀, 큐 깊이와 같은 용량 신호를 사용하십시오. GKE의 경우 HPA/VPA 및 클러스터 자동 확장 처리기(cluster autoscaler)를 조정하고, GCE MIG의 경우 적절한 경우 축소 대기 시간(cool-down)과 예측 자동 확장을 설정하십시오.

• 서비스 상태 및 문제 해결: Logs Explorer 라이브 테일, 로그 기반 측정항목, 대시보드, Trace를 결합하여 MTTD를 줄이십시오. 네트워크 분류를 위해 VPC Flow Logs 및 Firewall Rules Logging을 활성화하고, 부팅 실패 시 VM 직렬 콘솔을 사용하십시오. 패킷 캡처와 커널 추적은 Runbook에 비상 절차(break-glass procedure)로 유지하십시오.

• 장애 모드:

  • 할당량 소진은 서비스 중단처럼 보입니다. 80% 사용량에 대해 알림을 설정하고 업스트림의 비율을 제한하십시오.
  • 사전 준비(prewarming) 없는 자동 확장은 콜드 스타트(cold start)를 유발합니다. 중요 경로에는 최소 복제본을 사용하십시오.
  • SYNTHETIC 검사가 없으면 고객에게 보이는 장애가 가려질 수 있습니다. 카나리 트랜잭션을 구현하십시오.

자동화, 리소스 인벤토리, 정책 및 드리프트

최소 권한과 멱등성 원칙에 따라 반복 가능한 작업을 자동화합니다.

• 도구: 안전한 임시 관리 환경과 영구적인 $HOME을 위해 Cloud Shell을 사용하고, PATH 지속성을 위해 헬퍼 바이너리를 ~/bin에 배치합니다. gcloud, REST API, 클라이언트 라이브러리를 사용하여 자동화합니다. 서비스 계정과 워크로드 아이덴티티를 사용하여 수명이 긴 키를 제거합니다.

• 스케줄러 및 오케스트레이터: Cloud Scheduler를 사용하여 cron 스케줄에 따라 HTTP 및 Pub/Sub 작업을 트리거합니다. Workflows를 사용하여 재시도, 백오프, 보상, 타임아웃을 포함한 다중 서비스 자동화를 오케스트레이션합니다. 멱등성을 보장하고 로그에 상관관계 ID를 추가합니다.

• 일상적인 자동화 예시:

  • 인벤토리 및 드리프트 보고서를 위해 GCS 및 BigQuery로 매일 애셋을 내보냅니다.
  • 자동화된 SLO 소진율(burn-rate) 계산을 대시보드에 게시합니다.
  • 조직 정책 및 IAM 이상에 대한 주기적인 정책 평가를 수행합니다.

• 리소스 인벤토리 및 정책 평가: Cloud Asset Inventory는 리소스, IAM 바인딩, 조직 정책의 특정 시점(point-in-time) 및 실시간 변경 피드를 제공합니다. 과거 데이터 분석 및 드리프트 감지를 위해 BigQuery로 내보내고, 거의 실시간에 가까운 정책 위반 분류를 위해 Pub/Sub를 구독합니다. Policy Analyzer와 Recommender를 사용하여 과도하게 광범위한 IAM 및 미사용 권한을 탐지합니다. Organization Policy로 제약 조건을 강제하고, policy-as-code를 사용하여 배포 전 구성을 검증합니다.

• 구성 드리프트: 선언적 IaC(Infrastructure as Code)와 지속적인 검증으로 드리프트를 방지합니다. 탐지 시 자동으로 조정하거나 리소스를 격리합니다. 관리형 리소스와 임시 리소스를 구분하기 위해 리소스에 출처(예: deployment_id) 태그를 지정합니다.

• 보안, 신뢰성, 비용을 위한 관측 가능성 아키텍처:

  • 보안: 감사 로그를 CMEK로 보호되고 접근이 제한된 버킷으로 라우팅하고, 전용 보안 프로젝트로 내보냅니다. Pub/Sub를 통해 SIEM을 통합합니다.
  • 신뢰성: SLI와 트레이스를 기반으로 대시보드와 알림을 구동하고, 워크플로우를 사용하여 인시던트 자동화를 연습합니다.
  • 비용: 메트릭 카디널리티를 제어하고, 버킷별 로그 보존 기간을 조정하며, BigQuery 내보내기를 파티셔닝하고, Profiler를 사용하여 핫 경로(hot path)를 최적화합니다.

예시: 매일 애셋을 내보내고 워크플로우를 실행하도록 스케줄링합니다.

• gcloud asset export –content-type=resource –output-path=gs://ORG-SEC-BUCKET/daily/resources-$(date +%F).json
• gcloud scheduler jobs create http run-asset-scan –schedule=“0 3 * * *” –uri=“WORKFLOW_EXECUTIONS_API_ENDPOINT” –http-method=POST –oauth-service-account-email=scheduler-sa@PROJECT.iam.gserviceaccount.com

실용적인 문제 시나리오

Contoso Commerce는 다중 리전 GKE 기반 결제 플랫폼을 출시합니다. 요구사항: 감사 가능한 관리, 노이즈를 최소화한 SLO 기반 알림, 엔드투엔드 요청 추적, 자동화된 야간 규정 준수 인벤토리, 강력한 비용 관리.

접근 방식:

1. 로깅 및 감사 기반 구축

• 앱, 보안, 분석 로그를 위해 CMEK를 사용하는 리전별 로그 버킷을 생성합니다. 앱 로그는 30일, 보안 로그는 요구사항에 따라 400일 이상으로 설정합니다. Admin Activity, System Event, Policy Denied 로그를 보안 버킷으로 라우팅하고, 결제 서비스에 대해서만 Data Access 로그를 활성화합니다.
• 근거: 민감도에 따른 분리는 영향 반경과 비용을 줄입니다. CMEK는 규정 준수를 충족하며, Data Access 범위를 좁히면 로그 볼륨 급증을 방지할 수 있습니다.

2. 구조화된 애플리케이션 로깅 및 수집 구현

• GKE 노드에 Ops Agent를 배포하고, 사이드카/데몬셋 수집기를 사용하여 앱 로그를 상관관계 ID(trace_id, span_id)와 PII가 제거된 사용자/세션 레이블을 포함한 구조화된 JSON으로 전송합니다.
• 근거: 구조화된 로그는 정밀한 쿼리, 로그 기반 메트릭, 트레이스와의 조인을 가능하게 합니다. 상관관계 ID는 분산 환경에서의 진단을 지원합니다.

3. 분산 추적, 오류 집계, 프로파일링 배포

• OpenTelemetry SDK로 마이크로서비스를 계측하여 Cloud Trace로 내보냅니다. 결제 및 지불 경로에는 더 높은 샘플링 비율을 설정합니다. 모든 런타임에 Error Reporting을 활성화하고, CPU/메모리가 중요한 서비스에는 Profiler를 활성화합니다.
• 근거: 트레이스는 서비스 홉별로 지연 시간의 원인을 찾아냅니다. Error Reporting은 스택 트레이스를 그룹화하여 분류 속도를 높입니다. Profiler는 컴퓨팅 비용과 tail latency를 줄입니다.

4. SLI/SLO 정의 및 알림, 대시보드 구성

• SLI 정의: p90 및 p99 결제 지연 시간, 결제 API 가용성, 결제 성공률. SLO 설정(예: 99.9% 가용성, p99 지연 시간 800ms 미만). 런북 링크와 PagerDuty 채널을 포함한 소진율(burn-rate) 알림(1시간 동안 2%, 6시간 동안 1%)을 구성합니다. 골든 시그널과 오류 예산 추세를 표시하는 대시보드를 구축합니다.
• 근거: 오류 예산 기반 알림은 고객 영향과 연계되어 노이즈를 줄입니다. 대시보드는 운영 상황 인식을 제공합니다.

5. 외부 및 내부 상태 확인 추가

• 콘텐츠 검증을 포함한 다중 리전 가동 시간 확인(uptime check)을 결제 엔드포인트에 구성합니다. 장바구니에서 결제까지의 흐름에 대한 합성 트랜잭션 검사를 추가합니다. GCLB 및 GKE 준비성 프로브(readiness probe)를 통합합니다.
• 근거: 가동 시간 확인은 고객 대면 가용성을 검증합니다. 합성 흐름은 종속성 장애를 감지합니다.

6. 인벤토리, 정책 모니터링, 드리프트 감지 자동화

• Cloud Asset Inventory 내보내기를 GCS 및 BigQuery로 수신할 보안 프로젝트를 생성합니다. IAM 및 조직 정책 변경에 대한 실시간 Pub/Sub 피드를 활성화합니다. 매일 밤 Workflows를 실행하여 원하는 상태의 매니페스트와 현재 애셋을 비교하고, 티켓을 열거나 위험이 낮은 드리프트는 자동으로 조정합니다.
• 근거: 중앙 집중식 인벤토리는 감사를 지원합니다. 지속적인 정책 평가는 권한 상승을 방지합니다. 자동화는 드리프트를 억제합니다.

7. 할당량 및 용량 관리

• 컴퓨팅, 부하 분산기, API 할당량을 모니터링하고 사용량이 70%와 85%에 도달하면 알림을 보냅니다. 목표 부하에 맞춰 더 높은 할당량을 미리 요청합니다. GKE 클러스터 오토스케일러와 HPA 한도를 할당량에 맞게 조정합니다. 시작이 느린 MIG 기반 서비스에는 예측 자동 확장을 활성화합니다.
• 근거: 할당량 한도는 장애처럼 보일 수 있습니다. 사전 예방적 조정과 정렬된 자동 확장은 최대 부하 시 스로틀링을 방지합니다.

8. 관측 가능성 비용 최적화

• 버킷별로 로그 보존 기간에 상한을 설정하고, Log Router 필터를 통해 프로덕션 환경에서 상세한 디버그 로그를 제외하며, 파티션 만료와 함께 필요한 필드만 BigQuery로 내보냅니다. 메트릭 레이블 카디널리티를 제한하고, Profiler 분석 결과를 사용하여 사용량이 많은 서비스를 축소합니다.
• 근거: 관측 가능성은 비용 효율적이어야 합니다. 목표에 맞는 보존 및 내보내기는 통제 불가능한 비용 발생을 방지합니다.

9. 런북 및 인시던트 대응 훈련 준비

• 진단 쿼리, 트레이스 필터, 롤백 명령어, 커뮤니케이션 계획을 포함하여 각 알림 정책에 대한 버전 관리되는 런북을 작성합니다. 게임 데이를 실행하여 에스컬레이션 및 자동화를 검증합니다.
• 근거: 결정적이고 훈련된 대응은 MTTR을 줄이고 신뢰성을 향상시킵니다.

10. 검증 및 반복

• 알림 노이즈를 지속적으로 검토하고, 임계값을 조정하며, 실제 트래픽을 기반으로 SLO를 개선합니다. 사후 분석(postmortem) 조치 항목을 담당자 및 마감일과 함께 완료될 때까지 추적합니다.
• 근거: 측정된 피드백을 통해 관측 가능성과 운영이 개선되어, 불필요한 수작업(toil)을 줄이고 시간이 지남에 따라 서비스 품질을 향상시킵니다.

← 마이그레이션 · 모든 도메인 · DevOps →

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

Google 찾아보기 →