Google Professional Cloud DevOps Engineer

Cloud Trace는 분산 추적(distributed tracing)을 위한 것으로, 엔드투엔드 요청 latency와 서비스 전반에서 시간이 소비되는 위치를 보여줍니다. 느린 요청을 진단하고 병목을 찾는 데는 도움이 되지만, Cloud Run revision별 권위 있는 컨테이너 CPU 및 메모리 사용률 메트릭을 제공하지는 않습니다. Trace 데이터는 요청 샘플링 기반이며, 모든 revision에 대한 용량/적정화 의사결정에 적합한 소스가 아닙니다.

Cloud Profiler는 코드 수준 프로파일링(CPU time, heap, allocations)을 제공하며 애플리케이션 성능 최적화에 유용합니다. 하지만 Cloud Run revision 전반에서 컨테이너 리소스 사용률(CPU/메모리 사용량 vs limit) 메트릭을 위한 1차 도구는 아닙니다. 또한 Cloud Run fully managed는 VM 기반 워크로드처럼 런타임에 Ops Agent를 설치하는 방식에 의존하지 않으므로, 요구사항과 맞지 않는 선택지입니다.

Logs-based metrics는 로그 패턴 발생 횟수를 세거나 로그에서 숫자 필드를 추출할 수 있지만, 실제 컨테이너 CPU 및 메모리 사용률을 측정하는 신뢰할 수 있는 방법은 아닙니다. 또한 애플리케이션이 올바른 로그 데이터를 내보내는 것에 의존하는데, 문제에서 코드 변경을 금지하고 있습니다. 기존 로그가 있더라도 사용률을 추론하는 것은 간접적이고 오류가 발생하기 쉬우며, Cloud Monitoring의 네이티브 Cloud Run 메트릭에 비해 부적절합니다.

app-blue를 새 버전으로 업데이트하는 것은 blue/green 롤백의 목적을 무너뜨립니다. 새 릴리스가 장애를 유발한다면, 이를 blue로 승격하면 두 환경 모두가 문제 버전을 실행하게 되어 blast radius가 커질 가능성이 높습니다. 또한 마지막으로 검증된 정상 배포를 제거하여 복구를 더 어렵게 만들고 서비스 가용성 복구 시간을 증가시킵니다.

app-green을 이전 안정 버전으로 롤백하면 서비스를 복구할 수는 있지만, 가장 빠른 방법은 아니며 문제 Pod를 덮어써 버리기 때문에 개발자가 실패 릴리스를 디버깅할 수 있는 능력이 줄어듭니다. blue/green은 즉각적인 완화를 위해 트래픽을 안정 버전(blue)으로 되돌리는 동안, 실패 버전(green)은 배포된 상태로 유지하도록 설계되었습니다.

Service selector를 app: my-app만으로 변경하면(두 Deployment가 모두 app: my-app을 공유한다고 가정할 때) blue와 green Deployment의 Pod를 모두 선택하게 됩니다. 이는 사실상 통제되지 않은 canary/트래픽 분할 시나리오가 되어 사용자에게 보이는 오류가 계속 발생할 수 있고 동작이 일관되지 않게 됩니다. 또한 디버깅을 복잡하게 만들며 빠르게 가용성을 복구한다는 목표를 위반합니다.

pull request 트리거는 제안된 변경에 대해 테스트를 실행하는 데 유용할 수 있지만, 프로덕션 등급 이미지가 release/v1에서만 빌드되어야 한다는 요구사항을 충족하지 못합니다. PR 빌드는 종종 PR의 소스 브랜치 또는 임시 merge ref에서 실행되며, 결국 머지되지 않는 코드로부터 아티팩트를 생성할 수 있습니다. 이는 검증에는 좋지만, 통제된 프로덕션 이미지 생성에는 적합하지 않습니다.

included files 필터는 변경된 파일 경로를 기준으로 트리거 실행 시점을 제한할 뿐, 거버넌스 승인이나 브랜치 머지 정책을 다루지 않습니다. 또한 CODEOWNERS를 included files 필터에 추가하는 것은 개념적으로도 잘못입니다: CODEOWNERS는 리뷰 규칙을 위해 VCS에서 해석되며, 권한 부여를 위해 Cloud Build에서 해석되지 않습니다. 이는 거버넌스 승인 2건을 보장하지도, 빌드를 release/v1로 제한하지도 못합니다.

Cloud Build 트리거 승인(approvals)은 빌드 실행 전에 수동 게이트를 추가하지만, release/v1로의 머지가 거버넌스 승인 2건을 갖도록 강제하지는 못합니다. Cloud Build의 Approval은 일반적으로 배포 승격이나 민감한 단계에 사용되며, VCS 머지-승인 정책을 충족하기 위한 것이 아닙니다. 또한 자동화를 저해하며, 빌드가 다른 방식으로 트리거되면 우회될 수 있습니다.

프로덕션 서브넷에만 Flow Logs를 활성화하는 것은 범위가 적절하고 스테이징 노이즈를 피하지만, sample volume scale 0.5는 10초 미만으로 지속되는 짧고 간헐적인 비콘을 놓칠 수 있습니다. 포렌식 조사에서는 몇 개의 플로우라도 누락되면 귀속(attribution)이나 타임라인 재구성이 불가능해질 수 있습니다. 이 옵션은 증거 완전성을 희생하면서 비용/볼륨을 너무 이르게 최적화합니다.

스테이징에 먼저 롤아웃하면 프로덕션에서의 데이터 수집이 지연되어 “조사를 지연시키지 않고”라는 요구사항과 충돌합니다. 또한 스테이징에서 Flow Logs를 활성화해도 프로덕션에서 발생하는 비콘의 증거를 캡처하는 데 도움이 되지 않으며 로그 볼륨과 분석 노이즈만 증가시킵니다. 마지막으로 0.5 샘플링은 여전히 짧게 발생하는 플로우를 놓칠 위험이 있어 포렌식 목표를 약화시킵니다.

sample volume scale 1.0은 짧은 비콘을 캡처하는 데 적절하지만, 스테이징과 프로덕션 모두에 활성화하면 프로덕션 포렌식을 개선하지 못한 채 비용과 노이즈만 추가됩니다. 더 중요한 점은 스테이징 우선 롤아웃이 프로덕션 캡처를 지연시키며, 이는 조사를 지연시키지 말라는 요구사항에 의해 명시적으로 허용되지 않습니다.

CPU/memory 확인은 해당 region이 과부하인지 진단하는 데 도움이 될 수 있지만, 현재 502를 보는 사용자에 대한 가용성을 즉시 복구하지는 못합니다. 또한 region 전반에서 100% 502는 단순 리소스 포화보다는 더 광범위한 장애(health check, networking, ingress/proxy, endpoint readiness)를 시사하는 경우가 많습니다. SRE 대응에서는 심층 메트릭 분석보다 완화가 먼저입니다.

대규모 node pool 추가는 느리고 잠재적으로 비용이 큰 변경이며, 진행 중인 outage에서 1차 대응 조치가 아닙니다. 이는 capacity가 root cause라는 가정을 전제로 하지만, 증상(해당 region 전반의 HTTP 502)과는 부합하지 않습니다. scaling은 misconfiguration, network failure, load balancer/NEG health 문제를 해결하지 못할 수 있습니다. 먼저 traffic shift를 선호하고, 그 다음 표적화된 remediation을 수행하세요.

로그는 root cause 분석(예: ingress/controller 오류, upstream reset, TLS 이슈)에 유용하지만, regional outage가 전체 실패와 빠른 SLO burn을 유발하는 상황에서 첫 단계는 아닙니다. SRE 모범 사례는 먼저 사용자 영향을 완화(traffic reroute)한 뒤, logs/metrics/traces로 진단하고 영구적인 수정 사항을 구현하는 것입니다.

HTTP health check는 트래픽을 생성해 cold start를 줄일 수는 있지만, 근본 원인인 idle 상태에서의 CPU cycle 부족을 직접 해결하지는 못합니다. 인스턴스가 유지되더라도 Cloud Run이 요청 전용 CPU로 구성되어 있으면 요청 사이에 CPU를 여전히 제공하지 않을 수 있어, BatchSpanProcessor의 주기적 export timer가 안정적으로 실행되지 못합니다. 또한 trace flush를 보장하지 못한 채 인위적인 트래픽과 비용만 추가합니다.

CPU를 2 vCPU에서 4 vCPU로 늘리면 활성 요청 처리 중 처리량은 개선되지만, 낮은 트래픽에서 span이 누락되는 문제는 해결하지 못합니다. 이 문제는 요청이 없고 CPU가 아예 할당되지 않을 때 발생하므로, exporter의 예약된 flush가 실행될 수 없습니다. 요청 중 vCPU를 더 늘려도 idle 기간에 버퍼링된 span을 전송하려면 CPU 시간이 필요하므로 도움이 되지 않습니다.

Cloud Trace ingestion은 일시적인 네트워크 장애에 대해 재시도할 수 있지만, 여기서는 batch exporter가 주기적 flush를 실행할 CPU 시간을 받지 못해 span이 프로세스를 떠나지 못하는 경우가 많습니다. 인스턴스가 suspend 또는 종료될 때 span이 메모리에 버퍼링된 상태라면 재시도할 대상이 없습니다. 재시도에 의존하는 것은 애플리케이션 runtime에서 export되지 않은 텔레메트리에 대한 신뢰성 전략이 아닙니다.

Terraform을 실행하는 Cloud Build는 Git에서 인프라를 프로비저닝할 수 있지만 Kubernetes namespace 네이티브가 아닙니다. 엔지니어는 Kubernetes object로서 “Kubernetes namespace 내부에서” 리소스를 선언하는 것이 아니라 Terraform 변경을 제출하고 파이프라인 실행에 의존하게 됩니다. 10분 이내 드리프트 수정은 예약 실행이나 외부 드리프트 탐지를 추가하지 않는 한 자동이 아니며, Terraform은 보통 공유 credential과 state를 사용하므로 namespace별 최소 권한 구현이 더 어렵습니다.

Terraform을 실행하는 장기 실행 Pod는 프로덕션 GitOps 및 Autopilot 운영에서 안티패턴입니다. 이는 견고한 state 관리, 안전한 credential 처리, 거버넌스가 부족합니다. 또한 엔지니어가 namespace 내에서 리소스를 선언할 수 있는 Kubernetes 네이티브 CRDs를 제공하지 않으며, 지속적 reconciliation/드리프트 수정은 커스텀 로직이 필요합니다. Autopilot은 node 수준 작업을 제한하기도 하며, Pod에서 임시 인프라 도구를 실행하면 운영 리스크가 증가합니다.

Terraform을 실행하는 Kubernetes Job은 Pod보다 일회성 실행에는 낫지만, CronJob 또는 외부 스케줄러를 추가하지 않는 한 10분 이내의 지속적 reconciliation 요구사항을 충족하지 못합니다. 또한 Config Connector처럼 RBAC 경계를 가진 namespace 범위의 Kubernetes 네이티브 리소스 선언을 제공하지 않습니다. Terraform state, locking, credential은 멀티 팀, 멀티 클러스터 구성에서 여전히 복잡합니다.

오답. Cluster Autoscaler는 무제한 scaling을 보장하지 않습니다. node pool max size, regional quotas(vCPU, IP addresses 등)에 의해 제한되며 provisioning time 때문에 느려질 수도 있습니다. 또한 pod requests/limits와 HPA가 적절히 설정되지 않으면 시스템이 pods를 적절히 scale하지 못해 pending pods 또는 poor binpacking이 발생할 수 있습니다. 또한 존 장애에 대한 N+1 capacity를 검증하지도 않습니다.

오답. steady-state utilization 28%는 6개월 안전을 보장하지 않습니다. 10% month-over-month 성장은 6개월 동안 복리로 누적되어 약 77% 증가합니다. 더 중요한 것은 한 존을 잃어도 남은 존들이 부하를 흡수해야 한다는 점이며, overall utilization이 낮아 보여도 존별 capacity와 scheduling 제약으로 hotspots가 발생할 수 있습니다. 이 선택지는 quota 상한을 무시하고 load/failure testing을 통한 검증도 제공하지 않습니다.

틀렸습니다. 지금 60%의 추가 node capacity를 미리 프로비저닝하는 것은 최선의 접근 방식이 아닙니다. 6개월 동안 매월 10%씩 성장하면 복리로 약 77%가 되므로, 60%는 예측된 증가량과도 정확히 일치하지 않습니다. 더 중요한 점은 capacity를 미리 구매하면 즉시 비용이 증가하며, 실제 급증 상황이나 단일 zone 장애 동안 autoscaling limits, quotas, pod requests, scheduling behavior가 올바르게 작동하는지도 여전히 검증하지 못한다는 것입니다. 더 나은 방법은 node pool maximums와 quotas를 검증하고, HPA와 resource requests를 올바르게 구성하며, 대표적인 load 및 failure 테스트를 실행하여 capacity가 정적으로 과다 프로비저닝되는 대신 탄력적으로 확장될 수 있도록 하는 것입니다.

Compute Engine에서 자체 관리 Jenkins는 관리형 GCP 네이티브 접근이 아니며 상당한 운영 오버헤드(패치, 스케일링, 가용성, 보안 하드닝)를 유발합니다. 6시간마다 스케줄링하는 것은 모든 pull request 업데이트마다 실행하고 테스트가 통과할 때까지 merge를 차단해야 한다는 요구사항을 충족하지 못합니다. 또한 관련 파일 변경 여부와 무관하게 실행되어 리소스를 낭비하며, 추가 설정 없이는 GitHub required status checks와 본질적으로 통합되지 않습니다.

리뷰어가 수동으로 로컬에서 실행하는 방식은 신뢰할 수 없고 자동화할 수 없습니다. 일관된 환경, 재현성, 감사 가능성을 보장할 수 없으며, 모든 PR 업데이트마다 자동으로 테스트를 실행해야 한다는 요구사항을 충족하지 못합니다. 또한 PR에 첨부된 로그는 검증 가능한 CI 신호가 아니고 사람의 실수나 누락에 취약하므로, 강제된 status check를 기반으로 merge를 안정적으로 차단할 수 없습니다.

main으로의 push에서만 테스트를 실행하면 pull request가 merge된 이후에 테스트가 수행되므로, 테스트가 통과할 때까지 merge를 차단해야 한다는 요구사항을 위반합니다. 이 접근은 깨진 변경이 main에 반영되어 잠재적으로 후속 배포를 트리거할 수 있어 위험을 증가시킵니다. 또한 모든 PR 업데이트마다 실행해야 한다는 요구사항을 충족하지 못하고, PR-triggered CI에 비해 개발자에게 더 느린 피드백을 제공합니다.

Log-based metrics는 logs에서 발견되는 특정 error 패턴(예: 여러분의 서비스로 반환된 BigQuery API errors)을 정량화할 수 있습니다. 하지만 이는 여러분의 workloads가 기록한 내용을 반영할 뿐, Google Cloud에 기반 인시던트가 있었는지 여부를 보여주지는 않습니다. 또한 logging이 불완전하거나 sampling이 발생하면 이슈를 놓칠 수도 있습니다. 이는 증상 추적에는 도움이 되지만, Google이 관리하는 서비스 성능 저하로 스파이크가 발생했는지 신뢰성 있게 attribution하지는 못합니다.

logs widget은 troubleshooting 중 최근 errors와 stack traces를 빠르게 확인하는 데 유용합니다. 하지만 raw logs는 노이즈가 많고 수동 필터링이 필요하며, 여전히 애플리케이션이나 서비스가 출력한 내용만 보여줍니다. Google Cloud 서비스 health에 대한 권위 있고 큐레이션된 인시던트 컨텍스트를 제공하지 않습니다. 이 접근은 상관관계 분석이 느리고, Google Cloud 의존성이 성능 저하되었는지 여부에 직접 답하지 못합니다.

Alerting policies는 metric이 임계값을 넘을 때 알림을 보내므로 detection과 SLO 기반 paging에 유용합니다. 하지만 이 문제는 원인(여러분의 서비스 vs Google Cloud 의존성 outage)을 판단하기 위한 dashboard 구축에 관한 것입니다. Alerting만으로는 attribution을 제공하지 못하며, “system error metrics”는 여러분의 프로젝트에 영향을 주는 Google Cloud 서비스 인시던트와 상관관계를 만들기 위한 직접적인 메커니즘이 아닙니다.

Cloud Debugger는 지속적 CPU/heap 프로파일링이 아니라 애플리케이션 상태(snapshot) 검사와 재배포 없이 logpoint를 추가하는 용도입니다. 타이밍 데이터가 포함된 debug log를 내보내면 로깅 볼륨과 오버헤드가 증가하고, 통계적으로 의미 있는 함수 수준 CPU/heap attribution이 부족하며, 성능 분석을 위한 준(準) 커스텀 파이프라인이 됩니다. 또한 Cloud Profiler에 필적하는 시간 경과에 따른 집계 프로파일링 뷰를 자연스럽게 제공하지 않습니다.

/metrics endpoint를 노출하고 timing library를 사용하는 것은 관리형 프로파일링이라기보다 커스텀 메트릭 수집에 가깝습니다. Cloud Monitoring uptime check는 가용성/endpoint 확인을 위한 것이며, 여러 pod/namespace 및 on-prem server 전반에서 Prometheus 스타일 메트릭을 대규모로 스크레이프하도록 의도된 것이 아닙니다. Managed Service for Prometheus를 사용하더라도 CPU/heap 프로파일의 함수 수준 attribution이 아니라 메트릭을 수집하는 것이며, 더 많은 instrumentation 및 ingestion 구성요소를 운영하게 됩니다.

서드파티 APM agent는 프로파일링을 제공할 수 있지만, 자체 metrics pipeline을 구축/운영하지 않으려는 요구사항을 위반하고 운영 복잡성(agent 관리, 라이선스, 데이터 export, 저장, 시각화)을 추가합니다. 나중에 분석하기 위해 bucket/database로 export하는 것은 Google Cloud에서의 관리형 통합 프로파일링 경험이 아니며 비용과 유지보수를 증가시킵니다. 시험에서는 요구사항이 일치할 때 퍼스트파티 관리형 observability 서비스를 우선 선택하세요.

Slack을 30분마다 다음 업데이트 시간과 함께 업데이트하는 것은 내부 커뮤니케이션에 좋은 관행이지만, 수정(fix)을 찾을 때까지 고객 업데이트를 보류하는 것은 그렇지 않습니다. 트랜잭션 영향이 큰 SEV-1에서는 ETA가 없더라도 고객에게 즉각적인 인지(acknowledgement), 영향 범위, 지속적인 업데이트가 필요합니다. 외부 커뮤니케이션 지연은 티켓 볼륨을 증가시키고 신뢰를 훼손합니다.

내부 업데이트를 위임하는 것은 도움이 될 수 있지만, 고객 티켓에 애드혹 노트로 1:1 답변하는 것은 확장되지 않으며(10분에 120개 티켓) 메시징이 일관되지 않거나 부정확해질 위험이 있습니다. Communications Lead는 status page와 표준화된 템플릿을 통해 브로드캐스트 업데이트를 주도하고, 필요 시 티켓 응답에서 해당 업데이트를 참조해야 합니다.

모든 내부 문의를 Incident Commander로 전달하는 것은 역효과입니다. IC는 반복 질문 처리보다 조정과 의사결정에 집중해야 합니다. 이 옵션은 IC 부하를 증가시키고 완화(mitigation)를 지연시킵니다. Communications Lead의 목적은 질문을 통합하고 정기적이며 권위 있는 업데이트를 게시함으로써 대응자를 인터럽트로부터 보호하는 것입니다.

Cloud Run에서 canary 롤아웃은 새 revision으로 소량의 트래픽을 전환해 영향을 제한할 수 있습니다. 그러나 여전히 깨진 revision을 배포하며, 필수 환경 변수가 누락되었을 때 롤아웃을 방지해야 한다는 요구사항을 충족하지 못합니다. 또한 탐지가 결정적 사전 배포 점검이 아니라 런타임 동작과 트래픽 패턴에 의존하므로 CI/CD 파이프라인을 2분 내에 실패시키지 못할 수도 있습니다.

Static code analysis(linting, 스타일 점검, dependency scanning)는 CI에서 가치가 있지만 런타임 구성 주입(환경 변수와 secrets)을 검증하지는 않습니다. 오류는 시작 시점의 env var 누락이며, 이는 보통 배포 구성, Secret Manager 바인딩, 또는 build substitutions에서 비롯됩니다. 따라서 static analysis는 문제를 신뢰성 있게 잡아내거나 필요한 “없음 또는 비어 있음” 점검을 강제하지 못합니다.

Cloud Audit Logs는 IAM 또는 구성 변경이 배포에 영향을 주었는지 판단하는 데 도움이 되어 트러블슈팅에 유용합니다. 하지만 이는 사후 대응적이며 예방적이지 않고, env var가 누락되었을 때 릴리스를 차단하는 CI/CD 제어를 추가하지 않습니다. 또한 빠른 파이프라인 실패를 보장하지 못하며, 이 옵션에 설명되지 않은 수동 검토나 추가 자동화가 필요합니다.

이는 현재 관측된 성능보다 더 엄격합니다(70 ms p90 vs 85 ms, 180 ms p95 vs 210 ms). 게시하면 정상 조건에서도 서비스가 즉시 SLO를 위반하여 error budget을 빠르게 소모하고 불필요한 escalation 또는 릴리스 동결을 촉발할 것입니다. SLO를 더 타이트하게 하는 것은 사용자가 불만족하거나, 이미 성능을 개선했고 이를 지속할 수 있을 때에만 적절합니다.

이는 현재 성능보다 느슨하게 SLO를 설정합니다(110 ms p90, 240 ms p95). 충족하기는 더 쉽지만, 회귀에 대한 민감도를 낮추고 이해관계자에게 제공하는 신뢰성 약속을 약화시킵니다. 사용자가 이미 더 나은 성능에 만족하고 있으므로, SLO를 완화하는 것은 이점이 없고 점진적 성능 저하가 발생해도 조치를 트리거하지 못하게 할 수 있습니다.

이는 현재 성능보다 상당히 느슨하며, 특히 tail latency가 checkout 완료에 영향을 주는 글로벌 스파이크 이벤트 동안 의미 있는 latency 회귀를 가릴 가능성이 큽니다. 이런 관대한 SLO는 운영 제어 메커니즘으로서 SLO의 목적을 훼손하고, error budget이 너무 커져 feature 작업과 reliability 작업 간 우선순위 결정을 이끌지 못하게 만듭니다.

오답입니다. Organization Policy를 제거하면 즉각적인 오류는 해결되지만 컴플라이언스 및 거버넌스 요구사항을 깨뜨립니다. 규제 대상 핀테크 환경에서는 위치 제약이 보통 데이터 레지던시와 리스크 관리를 위해 의무화됩니다. 문제는 컴플라이언스를 유지하고 secret 데이터를 허용된 EU 리전에만 두어야 한다고 명시하므로, guardrail을 약화하거나 제거하는 것은 제시된 제약과 모범 사례를 위반합니다.

오답입니다. Automatic replication으로 secret을 생성하는 것이 바로 위반을 유발한 원인입니다. Automatic replication은 Google이 복제본 저장 위치를 제어하므로 global 위치로 취급되며, europe-west1과 europe-west3 외의 리전을 포함할 수 있습니다. constraints/gcp.resourceLocations 하에서는 global 리소스 또는 배치가 비결정적인 리소스가 생성에 실패하는 경우가 흔합니다.

오답입니다. 허용 목록에 global을 추가하면 automatic replication은 허용되겠지만, secret material이 europe-west1과 europe-west3에만 유지된다는 보장은 더 이상 할 수 없습니다. “Global”은 의도한 리전 범위를 넘어 확장될 수 있는 Google-managed 배치를 의미하므로, 엄격한 데이터 레지던시 요구사항을 약화시킵니다. 이 옵션은 또한 컴플라이언스 요구사항에 반하여 조직의 거버넌스 통제를 약화시킵니다.