Google PCD: 관찰 가능성, 디버깅 및 사이트 신뢰성 운영 — 학습 가이드

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

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

개요

Google Cloud의 관측 가능성, 디버깅, 사이트 안정성 운영은 시스템을 측정 가능하고, 진단 가능하며, 복원력 있게 만드는 것을 중심으로 합니다. 강력한 관측 가능성을 위해서는 일관된 로깅 및 측정항목, 분산 추적, 실행 가능한 알림, 체계적인 인시던트 대응이 필요합니다. 안정성을 위해서는 서비스 수준 지표 및 목표에 대한 명확성, 엄격한 상태 신호, 프로덕션 환경에서 얻은 인사이트를 엔지니어링 개선으로 연결하는 피드백 루프가 필요합니다. 이 섹션에서는 Google Cloud에서 이러한 기능을 엔드투엔드로 구축하는 방법과 장단점 및 일반적인 장애 모드에 대해 판단하는 방법을 설명합니다.

로깅 및 모니터링 기본 사항

Cloud Logging

구조화된 로그를 내보냅니다. 릴리스 전반에 걸쳐 쿼리와 로그 기반 측정항목의 안정성을 유지할 수 있도록 안정적인 필드 이름을 가진 JSON 형식을 사용하는 것이 좋습니다. 심각도, 서비스 이름, 버전, 위치, 그리고 상관관계 분석을 위한 요청 ID 또는 추적 컨텍스트를 포함하세요.
다음 필드를 설정하여 로그와 추적을 연관시킵니다:
- logging.googleapis.com/trace: projects/PROJECT_ID/traces/TRACE_ID
- logging.googleapis.com/spanId: SPAN_ID
- logging.googleapis.com/trace_sampled: true
버킷 및 보관. _Default 버킷은 일반적으로 30일의 보관 기간(구성 가능)을 가집니다. _Required 버킷에는 더 길고 고정된 보관 기간을 가진 특정 감사 로그가 포함됩니다. 리전 버킷을 생성하여 데이터 상주 위치를 제어하고 버킷별로 맞춤 보관 기간을 설정하세요.
싱크. 분석을 위해 로그를 BigQuery로, 스트리밍 소비자를 위해 Pub/Sub으로, 또는 아카이브를 위해 Storage로 라우팅합니다. 폴더나 조직 수준에서 집계 싱크를 사용하여 하위 프로젝트들을 포괄하세요.
쿼리. Logging 쿼리 언어를 사용하여 resource.type, labels, jsonPayload, httpRequest 또는 textPayload로 필터링합니다.

예시:

구조화된 로그 항목 (축약):

undefined

보관 기간 업데이트:

undefined

오류 로그를 위한 BigQuery 싱크 생성:

undefined

Cloud Run의 최근 5xx 오류 읽기:

undefined

Cloud Monitoring

측정항목. Google Cloud 측정항목, 커스텀 측정항목, 로그 기반 측정항목을 사용합니다. 낮은 카디널리티의 라벨을 선호하세요. 라벨 카디널리티가 폭발적으로 증가하면 비용 및 쿼리 지연 시간 문제가 발생할 수 있습니다.
대시보드. 서비스별 및 종속성(데이터베이스, 캐시, 큐)별로 대시보드를 구성합니다. RED(요청, 오류, 기간) 및 USE(사용률, 포화도, 오류) 신호를 시각화하세요.
알림 정책. 임계값, 측정항목 부재, 비율, SLO 소진율 또는 가동 시간 확인 실패 시 트리거합니다. 알림 채널(이메일, SMS, PagerDuty, Pub/Sub, 웹훅)을 구성하세요. 윈도잉 및 정렬기를 통해 플래핑(상태 변경 반복)을 억제합니다.
가동 시간 확인. 여러 리전에서 프로브를 실행합니다. 내부 엔드포인트에는 비공개 가동 시간 확인을 사용하거나 VPC 내에서 신서틱(synthetic) 테스트를 실행하세요.

로그 기반 측정항목

카운터는 발생 횟수를 요약합니다 (예: /api/alpha/* 요청 수).
분포는 지연 시간이나 페이로드 크기를 캡처합니다.
예시:

undefined

운영 분석

애드혹(ad hoc) 분석을 위해 싱크를 통해 BigQuery로 라우팅합니다. 비용을 제어하기 위해 스키마를 설계하고 타임스탬프별로 파티셔닝하세요.
해당하는 경우, 내보내기 없이 집계하기 위해 Logging 버킷의 Log Analytics를 사용하세요.
CPU, 메모리, 큐 깊이, Cloud SQL 연결 수, Spanner 고우선순위 CPU, Pub/Sub 미확인 메시지 수, Cloud Storage 429/5xx 비율과 같은 측정항목으로부터 용량 신호를 구축하세요.

일반적인 함정과 장단점

과도한 로깅은 수집 비용을 증가시키고 신호를 모호하게 만듭니다. 샘플링과 심각도 수준에 따른 로깅을 선호하세요.
상관관계 ID가 없으면 인시던트 분류가 어려워집니다. 추적 ID를 엔드투엔드로 전파하세요.
핫 버킷에 장기간 보관하면 비용이 증가합니다. 장기 보관이 필요한 경우 아카이브나 BigQuery로 내보내세요.

추적, 오류, 심층 진단

분산 추적

추적 컨텍스트. W3C trace-context(traceparent, tracestate)를 사용하는 것이 좋습니다. Cloud Trace와의 상호 운용성을 위해 x-cloud-trace-context도 계속 지원합니다: x-cloud-trace-context: TRACE_ID/SPAN_ID;o=1
전파. 서비스, 메시지 큐, 비동기 경계 전반에 걸쳐 추적 헤더를 전달합니다. RPC 또는 SQL 호출 시 새로운 하위 스팬을 캡처합니다. 컨텍스트가 유실되면 서비스 맵이 깨지고 ‘알 수 없는 서비스’ 노드가 증가합니다.
샘플링. 비용과 충실도 간의 균형을 맞춥니다. 인그레스에서 동적 헤드 기반 샘플링을 사용하고, 드물게 발생하는 느린 요청에 대해 테일 기반 샘플링을 사용하면 유용성을 높일 수 있습니다.

Cloud Trace

지연 시간 히스토그램, 스팬 워터폴, 서비스 맵을 제공합니다. 중요한 하위 작업(RPC, DB 쿼리)에는 주석(annotation)을 사용하세요.
p95/p99 추적을 사용하여 이상점을 진단하고, 팬아웃, N+1 쿼리, 잠금 경합을 주시하세요.
추적-로그 상관관계를 활성화하여 추적을 클릭하면 해당 로그가 표시되도록 하세요.

Error Reporting

서비스/버전별로 스택 서명에 따라 예외를 자동으로 집계합니다. 서비스 간 혼동을 피하기 위해 서비스 컨텍스트를 구성하세요. 노이즈가 많은 알려진 오류는 표시하지 않거나 우선순위가 낮은 알림으로 보내세요.
예외 메시지에서 개인 식별 정보(PII)를 삭제하고, 대신 안정적인 오류 코드와 상관관계 ID를 로그에 기록하세요.

Cloud Profiler

지원되는 런타임에 대해 오버헤드가 적은 지속적인 CPU/힙 프로파일링을 제공합니다. 버전 및 트래픽 수준별 프로필을 비교하여 성능 저하(regression)를 찾아내세요. 샘플링 아티팩트를 정확한 수치로 해석하지 않도록 주의하세요.

Cloud Debugger

스냅샷은 프로세스를 중지하지 않고 코드 위치의 변수를 캡처합니다. 로그포인트는 임시 로깅 구문을 삽입합니다. 접근을 제한하고, 민감한 변수를 삭제하며, 개인 식별 정보(PII)가 아닌 표현식으로 범위를 지정하세요.

간단한 예시: W3C traceparent 추가 및 로그 상관관계 설정

HTTP 전파: traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Cloud Trace에 연결하기 위한 로그 필드: “logging.googleapis.com/trace”: “projects/myproj/traces/4bf92f3577b34da6a3ce929d0e0e4736”

신뢰성 엔지니어링, 알림, 상태 신호

SLI, SLO, SLA, 오류 예산

SLI는 사용자 만족도를 측정합니다: 가용성, 지연 시간, 정확성. 중요한 엔드포인트 및 사용자 여정별로 정의하세요.
SLO는 목표를 설정합니다. 예: 30일 동안 요청의 99.9%를 300ms 미만으로 처리.
오류 예산은 허용 가능한 비신뢰성을 정량화합니다. 예산은 릴리스, 실험, 마이그레이션에 사용하고, 소진율이 너무 높으면 변경을 동결하세요.
SLA는 외부와의 약속입니다. 마진을 확보하기 위해 SLO를 SLA보다 더 엄격하게 유지하세요.

고품질 알림 설계

가능한 경우 원인 기반 알림보다 SLO 및 증상 기반 알림을 선호하세요.
다중 기간, 다중 소진율 알림(예: 5분 동안 14배, 1시간 동안 2배)을 사용하여 노이즈를 줄이면서 빠른 소진과 느린 소진을 모두 감지하세요.
워치독을 위해 측정항목 부재 알림을 추가하세요(예: 장기 실행 작업의 하트비트).
심각도에 따라 라우팅하고, 알림 속도를 제한하며, 런북 및 대시보드 링크를 제공하세요.

상태 확인 및 프로브

준비성(Readiness) 확인은 종속 항목이 준비될 때까지 트래픽을 차단하고, 활성(Liveness) 확인은 교착 상태에 빠진 프로세스를 재시작하며, 시작(Startup) 프로브는 느리게 시작하는 애플리케이션이 조기에 재시작되는 것을 방지합니다.
부하 분산된 VM의 경우, 상태 확인 소스 범위를 허용해야 백엔드로 트래픽이 도달할 수 있습니다: gcloud compute firewall-rules create allow-lb
–network prod –allow tcp
–source-ranges 130.211.0.0/22,35.191.0.0/16 –direction INGRESS
Kubernetes 예시: readinessProbe: httpGet: { path: /ready, port: 8080 } periodSeconds: 5 failureThreshold: 3 livenessProbe: httpGet: { path: /healthz, port: 8080 } initialDelaySeconds: 30 periodSeconds: 10
합성 테스트. Cloud Scheduler + Cloud Run/Functions를 통해 가동 시간 확인 및 맞춤형 엔드투엔드 플로우를 사용하여 로그인, 결제 또는 기타 중요한 경로를 검증하세요.
종속성 모니터링. 데이터베이스 연결 포화도, RPC 오류율, 큐 백로그, 이그레스 오류, 서드파티 SLI를 추적하세요. 일시적인 429/5xx 오류에 대해서는 잘린 지수 백오프(truncated exponential backoff)를 사용한 재시도를 설정하고, 안전을 위해 멱등성 키를 사용하세요.

인시던트 대응, 보안을 고려한 디버깅 및 근본 원인 분석

인시던트 대응 수명 주기

트리아지(Triage): 심각도 분류, 인시던트 커맨더(incident commander) 지정, 정의된 채널을 통해 온콜(on-call) 호출.
격리(Contain): 알려진 완화 조치 및 트래픽 제어(롤백, 카나리, 서킷 브레이커, 비율 제한기) 적용.
소통(Communicate): 내부 워룸(war-room) 유지, 이해관계자에게 정기적으로 업데이트, 필요 시 사용자 대상 상태 게시.
해결 및 복구: SLI를 통해 상태 확인, 성급한 “이상 없음(all clear)” 선언 지양.
사후 분석(Postmortem): 비난 없이 타임라인, 탐지 격차, 기여 요인, 담당자 및 기한이 명시된 조치 항목 분석. 해결될 때까지 추적.

런북(Runbooks)

트리거, 필요한 컨텍스트, 진단 명령어, 안전한 완화 조치, 롤백 단계, 에스컬레이션 경로 포함. 특정 장애 모드에 대한 대시보드, 로그, 플레이북으로 연결.

할당량 및 용량 모니터링

Cloud Monitoring 측정항목을 통해 서비스 할당량 모니터링. 70~80% 사용률에서 알림 자동화 및 계획된 부하 테스트나 출시에 대비해 사전 증가 요청.
추적해야 할 용량 신호: CPU, 메모리, 파일 디스크립터, 스레드 풀, DB 연결, 오토스케일러 한도, 요청 큐 깊이.

민감한 정보 노출 없이 디버깅하기

소스에서 비밀 정보와 PII(개인 식별 정보) 수정, Secret Manager에서 비밀 정보 중앙 관리. 사용자 식별자에는 해싱 또는 토큰화 사용. 로깅 미들웨어에서 필드 수준 수정 기능 활성화.
IAM을 통해 로그, 트레이스, 디버그 도구에 대한 접근 제한, 해당되는 경우 CMEK 및 VPC Service Controls 사용.
Debugger에서 대규모 객체 그래프 수집 비활성화 및 민감한 프레임을 캡처하지 않도록 조건 추가.

계층별 근본 원인 분석

런타임: Profiler를 통해 GC, 스레드 풀 또는 CPU 급증과 Trace의 p99 지연 시간의 상관관계 분석.
네트워크: 부하 분산기 로그, VPC Flow Logs, 방화벽 로그, Connectivity Tests를 검사하여 경로 유효성 검증. 상태 확인 실패는 주로 방화벽 규칙 누락이나 잘못된 포트로 인해 발생.
IAM: Cloud Audit Logs에서 권한 거부 또는 정책 변경 검토, 서비스 계정 역할 및 토큰 범위 확인.
데이터: Cloud SQL Insights, Spanner 쿼리 통계, Bigtable CPU 및 핫 태블릿(hot tablets), Storage 오류율을 사용하여 핫스팟(hotspot) 찾기. 일시적인 오류에 대해 백오프를 사용한 재시도 적용 및 테일 레이턴시(tail latency)를 증폭시키는 팬아웃(fan-out) 감소.
상관관계가 있는 트레이스 ID 및 로그 기반 측정항목으로 함께 연결, 인시던트 후 분석 중에 여러 소스를 조인하여 실행하기 위해 BigQuery로 내보내기.

실제 문제 시나리오

Fjord Retail은 Cloud Run, Cloud SQL, Pub/Sub 및 외부 세금 API를 사용하여 다중 서비스 결제 시스템을 Google Cloud로 마이그레이션합니다. 플래시 세일 동안 사용자들이 간헐적인 타임아웃과 급증하는 오류율을 보고하며, 온콜(on-call) 담당자는 노이즈가 많고 신호가 약한 알림을 받습니다.

접근 방식:

트레이스 상관관계를 포함한 구조화된 로깅 계측

모든 서비스에 W3C traceparent 전파를 추가하고 모든 로그에 logging.googleapis.com/trace를 포함. 근거: 엔드투엔드 상관관계를 통해 엔지니어는 느린 사용자 요청에서부터 정확히 느린 RPC나 쿼리 및 해당 로그로 신속하게 전환할 수 있음.

Logging 버킷, 보존 기간 및 내보내기 생성

_Default 보존 기간을 90일로 늘리고 EU 워크로드를 위한 리전 버킷 생성. ERROR 및 WARNING 로그를 위해 BigQuery로 집계 싱크 추가:

undefined

근거: 충분한 핫(hot) 보존 기간은 디버깅에 도움이 되며, BigQuery는 핫 스토리지 비용을 증가시키지 않으면서 신속한 인시던트 분석을 가능하게 함. 3) SLI/SLO 및 SLO 기반 알림 정의

가용성 SLI: 성공한 요청 수 / 전체 요청 수. 지연 시간 SLI: POST /checkout에 대한 p95 지속 시간.
SLO: 월별 99.9% 가용성, 결제의 95%가 300ms 미만.
다중 기간(multi-window) 소진율(burn-rate) 알림과 결제 하트비트(heartbeat)에 대한 측정항목 부재 알림 구성. 근거: 증상 기반 알림은 노이즈를 줄이고 사용자에게 영향이 있을 때만 호출함.

상태 프로브 및 합성 확인(synthetic check) 설정

Cloud Run 서비스는 /ready 및 /healthz를 노출. /checkout에 대한 전역 업타임 체크(uptime check)와 테스트 자격 증명으로 전체 결제를 수행하는 VPC 내 비공개 합성 작업(synthetic job) 추가. 근거: 준비성(readiness) 프로브는 콜드(cold) 백엔드가 트래픽을 수신하는 것을 방지하고, 합성 확인은 엔드투엔드 문제와 서드파티의 성능 저하를 포착함.

Cloud Trace 및 Profiler 활성화, 백오프를 사용한 재시도 채택

해당되는 경우 Trace/Profiler 에이전트 설치, 자동 HTTP 클라이언트 계측 및 SQL 스팬 주석 활성화. 세금 API 호출에 대해 멱등성 키(idempotency keys)를 사용하여 잘린 지수 백오프(truncated exponential backoff) 구현. 근거: 트레이싱은 지연 시간 기여 요인을 분리하고, 백오프는 429/5xx 증폭을 줄이고 오류 예산을 보호함.

용량 및 할당량 모니터링

Cloud SQL 연결, CPU, InnoDB 버퍼 풀, Pub/Sub 미확인 메시지, Cloud Run 동시성, 서비스 할당량 사용량에 대한 대시보드 및 알림 추가. 근거: 용량 포화는 테일 레이턴시(tail latency)의 일반적인 숨겨진 원인이며, 조기 알림은 장애를 예방함.

개인 정보 보호를 위한 디버깅 강화

해시된 사용자 ID를 사용하고 오류 메시지에서 PII 제외. Debugger를 수정 규칙 및 로그포인트(logpoint)만 사용하도록 프로덕션으로 제한. 근거: 데이터 최소화 원칙을 준수하면서 관측 가능성 유지.

종속성 모니터 및 서킷 브레이커(circuit breaker) 구축

커스텀 측정항목을 통해 외부 세금 API의 성공률 및 지연 시간 추적, 실패가 임계값을 초과하면 캐시된 세금 요율로 전환하는 서킷 브레이커 작동. 근거: 서드파티 종속성의 실패를 격리하고 핵심 결제 가용성 유지.

런북 및 에스컬레이션 경로 준비

단계 문서화: SLO 대시보드 확인, Trace 서비스 맵에서 핫 엣지(hot edge) 확인, Cloud SQL Insights에서 느린 쿼리 검사, 방화벽 및 상태 확인 검증, 할당량 여유 공간 평가. 롤백 및 카나리 절차 포함. 근거: 일관되고 빠른 대응은 MTTR을 줄이고 임시방편적인 위험한 변경을 방지함.