Google ACE: 모니터링, 로깅 및 운영 문제 해결 — 학습 가이드

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

개요

Google Cloud에서의 운영 우수성은 원격 측정 데이터를 실행 가능한 조치로 전환하는 데 달려 있습니다. 모니터링, 로깅, 문제 해결은 서비스를 안정적으로 유지하는 신호, 가드레일, 워크플로를 함께 제공합니다. 이 섹션에서는 핵심 관측 가능성 서비스, 진단 도구, 안정성 관행, 인시던트 운영에 대해 설계 근거, 장단점, 일반적인 장애 모드와 함께 다룹니다.

모니터링 및 알림 기본

Cloud Monitoring은 Google Cloud 서비스, 에이전트, 커스텀 측정항목에서 시계열 데이터를 수집하여 대시보드, 업타임 체크, SLO, 알림을 제공합니다.

• 측정항목 및 카디널리티

  • 모니터링 리소스 유형(예: gce_instance, aws_ec2_instance, global)은 프로젝트, 리전, 인스턴스 ID와 같은 측정기준의 범위를 지정합니다.
  • 경계가 없는 라벨 값(예: user_id)을 최소화하여 쿼리 속도를 저하시키고 비용을 증가시키는 고카디널리티 폭증을 방지합니다.
  • 지연 시간(p50/p90/p99)에는 분포 측정항목을 선호하고, 일관된 롤업을 위해 정렬 기간을 사용합니다.

• 대시보드

  • 빠른 시작을 위해 내장된 서비스 대시보드를 사용합니다. 여러 프로젝트의 측정항목을 그룹화하려면 커스텀 대시보드를 만듭니다. 패널은 원인(CPU, 메모리)보다 증상(지연 시간, 오류, 포화)을 기준으로 구성합니다.
  • 플릿(fleet)에 대해 인스턴스별 차트를 사용하지 마십시오. 서비스, 영역 또는 MIG별로 집계하여 노이즈를 줄이고 신호를 강화합니다.

• 알림 정책

  • 사용자 경험과 연계된 증상 기반 알림을 설계합니다: 가용성 SLO 소진, 지연 시간 백분위수, 오류율. 다중 기간, 다중 소진율 알림을 사용하여 빠른 소진과 느린 소진을 모두 감지합니다(예: 1시간 동안 2%, 5분 동안 5%).
  • 합리적인 알림 빈도 제한과 자동 종료 동작을 설정합니다. 인시던트 자동 완화 주석을 사용하여 런북을 문서화합니다.
  • 엄격한 일정을 가진 중요한 배치 작업 및 데이터 파이프라인에는 측정항목 부재 알림을 사용합니다.
  • 로그 기반 측정항목은 애플리케이션 또는 보안 이벤트(예: 반복되는 permissionDenied)에 대한 알림을 지원합니다.

• 알림 채널

  • 심각도에 따라 채널을 구성합니다: SEV1은 페이징(온콜, SMS, 전화), SEV2/3는 채팅, 우선순위가 낮은 경우는 이메일 또는 웹훅. 티켓팅 또는 자동화 시스템과의 통합을 위해 Pub/Sub을 사용합니다.
  • 채널을 주기적으로 테스트하십시오. 오래되어 사용되지 않는 채널은 조용한 장애 모드입니다.

• 업타임 체크 및 합성 모니터링

  • 글로벌 측정 지점에서 보내는 HTTP(S) 및 TCP 체크는 외부 연결성을 확인합니다. 부분 장애를 감지하기 위해 체크를 콘텐츠 일치와 함께 사용합니다.
  • 내부 서비스의 경우 하이브리드 연결 또는 Private Service Connect를 통해 비공개 업타임 체크를 사용합니다.
  • 장애 모드: DNS TTL 지연, TLS 인증서 순환 문제 또는 리전 범위의 서비스 중단으로 인해 체크가 실패할 수 있습니다. 호출하기 전에 측정항목으로 교차 확인하십시오.

• 다중 프로젝트 모니터링

  • 단일 Monitoring 작업 공간을 사용하고 모든 프로젝트를 연결하여 대시보드와 알림을 통합합니다. 이는 전체 플릿(fleet)에 대한 SLO를 단순화하고 중복을 줄입니다.

로깅, 감사, 애플리케이션 진단

Cloud Logging은 플랫폼 및 애플리케이션 로그를 위한 로그 라우터, 스토리지, 쿼리 영역입니다. 보완적인 APM 도구(Error Reporting, Trace, Profiler)는 근본 원인 격리 속도를 높입니다.

• 로그 라우팅, 버킷, 싱크, 보관

  • 싱크를 사용하여 로그를 로그 버킷(기본 또는 커스텀), BigQuery(분석), Pub/Sub(스트림 처리) 또는 Cloud Storage(아카이브)로 라우팅합니다.
  • 데이터 상주 및 성능을 위해 리전 범위의 로그 버킷을 사용합니다. 규정 준수에 따라 필요한 경우 CMEK를 적용합니다.
  • 버킷별로 보관 기간을 설정합니다(예: 운영용 30~90일, 감사용 다년). 보관 기간이 길어지면 비용이 증가하므로, 비용을 제어하기 위해 적극적으로 필터링합니다.
  • 제외 기능을 사용하면 상세한 로그(예: 상태 확인)의 수집을 줄일 수 있습니다. 중요한 로그가 의도치 않게 누락되지 않도록 필터를 검증합니다.

  예시: 감사 로그를 위한 BigQuery 싱크 생성

undefined

예시: 제외 생성

undefined

• 쿼리 및 로그 탐색기

  • resource.type, severity, 라벨, JSON 페이로드에 고급 필터를 사용합니다. 일반적인 분류 경로(시작 실패, permissionDenied, quotaExceeded)에 대한 쿼리를 저장합니다.
  • 알림 및 대시보드를 위해 분포 및 카운터 유형의 로그 기반 측정항목을 생성합니다.

• Cloud Audit Logs

  • 관리자 활동 로그: 항상 활성화되어 있으며 수집 비용이 없습니다. 관리자 쓰기 작업(예: createInstance)을 기록합니다.
  • 데이터 액세스 로그: 데이터 영역의 읽기 및 쓰기 작업(예: storage.objects.get)을 기록합니다. 많은 서비스에서 기본적으로 비활성화되어 있습니다. 양과 비용이 높을 수 있으므로 선택적으로 활성화합니다.
  • 시스템 이벤트 로그: Google 시스템 작업(예: autoscaler, 유지보수 실시간 마이그레이션)을 기록합니다.
  • 정책 거부 로그: IAM 및 조직 정책 거부에 대한 명시적인 기록입니다. 액세스 문제 해결 및 보안 검토에 중요합니다.
  • 보관 및 조사를 위해 감사 로그를 BigQuery로 라우팅합니다. 귀속을 위해 authenticationInfo.principalEmail과 같은 라벨을 인덱싱합니다.

• Error Reporting, Trace, Profiler

  • Error Reporting은 스택 트레이스를 서비스 및 버전별로 자동 그룹화합니다. 새로운 오류 그룹 및 갑작스러운 급증에 대해 알림 채널과 통합합니다.
  • Cloud Trace는 요청 지연 시간 분포와 스팬을 수집합니다. 오버헤드와 충실도의 균형을 맞추기 위해 샘플링을 설정합니다(예: QPS가 높은 서비스의 경우 1000개 중 1개, OpenTelemetry 수집기를 사용하는 경우 tail-based 샘플링 사용).
  • Profiler는 프로덕션 환경에서 오버헤드가 낮은 지속적인 CPU/힙 프로파일링을 제공합니다. 데이터 볼륨과 오버헤드를 제어하기 위해 핫 패스(hot path) 또는 대표적인 워크로드로 제한합니다. 가독성 있는 호출 그래프를 위해 소스 매핑을 사용합니다.
  • 장단점: 샘플링 비율이 높을수록 진단 기능은 향상되지만 비용과 잠재적인 PII 노출이 증가합니다. 민감한 필드는 스크러빙하고 토큰화를 사용합니다.

서비스, 리소스, 네트워크 문제 해결

효율적인 문제 해결은 증상에서 시작하여 시스템 경계, 그리고 리소스와 종속성 순서로 진행됩니다.

• 관리형 서비스 상태, 서비스 상태, 할당량, 리전별 장애

  • 장애가 업스트림에서 발생했는지 확인합니다. 서비스 상태와 최근 리전별 공지를 확인하세요. 오류 급증, 지연 시간 증가 또는 할당량 오류를 찾아봅니다.
  • 할당량은 프로젝트별, 그리고 종종 리전별로 적용됩니다. 로그에 quotaExceeded 및 rateLimitExceeded가 표시되면 조절(throttling)이 발생했다는 의미입니다. 피크 이벤트 전에 할당량 증가를 요청하세요.
  • 장애 모드: 부분적인 리전 중단은 간헐적인 오류로 나타날 수 있습니다. 가능한 경우 다중 리전 장애 조치를 구성하세요.

• 리소스 상태 및 VM 진단

  • 인스턴스 작업, 유지보수 이벤트, 상태 확인을 사용합니다. MIG의 경우, 자동 복구 재시작 및 상태 확인 실패를 검사하여 잘못된 이미지나 구성을 격리합니다.
  • 부팅 및 커널 메시지를 위한 VM 직렬 콘솔:
    • gcloud compute connect-to-serial-port VM_NAME –zone=ZONE
    • 일반적인 원인: 커널 패닉, 부팅을 막는 잘못된 fstab 항목, 잘못된 네트워크 구성, SSH 실패를 유발하는 OS Login 설정 오류.
  • 사용자별 SSH 키와 IAM 역할(compute.osLogin 또는 compute.osAdminLogin)을 사용하는 OS Login으로 책임 추적이 가능한 액세스를 보장합니다.

• 장애 분석을 위한 로그 탐색기

  • 증상 로그(5xx, deadlineExceeded)에서 시작하여 리소스 라벨을 기준으로 피벗한 다음, 배포 변경 및 할당량 로그와 연관시킵니다. 히스토그램 뷰를 사용하여 변경 지점을 찾습니다.

• 네트워크 관측성

  • VPC Flow Logs: VNIC별 5-튜플 트래픽 샘플링. 서브넷에서 활성화합니다. 성능과 상세 정보 수준의 균형을 맞추기 위해 샘플링(예: 0.5) 및 메타데이터 옵션을 조정합니다.
    • gcloud compute networks subnets update SUBNET –region=REGION –enable-flow-logs –flow-sampling=0.5 –aggregation-interval=interval-5-min –metadata=include-all
  • 방화벽 로깅: 중요한 규칙에 대한 허용/거부 결정을 캡처하여 예상치 못한 차단이나 섀도잉(shadowing)을 진단합니다.
    • gcloud compute firewall-rules update RULE_NAME –enable-logging
  • Connectivity Tests: VPC, 피어링, Cloud VPN, Cloud Interconnect, 방화벽 규칙 전반의 연결성을 모델링하고 확인합니다. 변경 전 검증 및 장애 분류에 유용합니다.
    • gcloud network-management connectivity-tests create test-a –source-instance=projects/PRJ/zones/ZONE/instances/VM1 –destination-ip=10.0.3.21 –protocol=TCP –destination-port=443
  • 보완 신호: 이그레스(egress) 및 에지(edge) 문제에 대한 Cloud NAT 및 부하 분산기 로그. 장애 모드에는 비대칭 라우팅, 누락된 경로, 잘못된 순서의 방화벽 규칙, 정책 제약 조건 등이 포함됩니다.

신뢰성, SLO 및 인시던트 운영

운영 규율은 원격 측정(telemetry)을 사용자 영향 목표 및 일관된 인시던트 실행과 연결합니다.

• SLO, 오류 예산(error budget) 및 기준선(baseline)

  • 사용자 중심 SLI(가용성, 지연 시간, 정확성)에 대한 SLO를 정의합니다. 예: 30일 동안 읽기 요청의 99.9%가 200ms 미만으로 완료됩니다.
  • 서비스 및 릴리스 버전별로 오류 예산을 추적하고 롤업 대시보드를 설계합니다. 예산 소모량을 기준으로 롤아웃을 제어(gate)합니다.
  • 트래픽이 증가하기 전에 성능 기준선을 설정합니다. 성능 저하(regression)는 절대값이 아닌 편차로 감지됩니다.

• 알림 노이즈 감소

  • 인스턴스 수준 알림보다 서비스 수준 알림을 선호합니다. 변화율(rate-of-change) 및 백분위수 기반 조건을 사용합니다. 점검 기간(maintenance window)에는 알림 조절(throttling), 인시던트 자동 종료, 알림 음소거를 적용합니다.
  • 공통 레이블과 정책을 통해 알림을 중복 제거합니다. 동일한 인시던트에 대해 데이터베이스와 애플리케이션 모두에 호출(paging)하는 것을 피하기 위해 종속성 인식 라우팅을 사용합니다.

• 인시던트 대응 워크플로

  • 심각도를 분류(triage)하고 선언합니다. 역할(인시던트 커맨더, 운영, 커뮤니케이션, 서기)을 할당합니다.
  • 에스컬레이션 경로: 온콜 로테이션, 주제 전문가(SME), 벤더 지원(지원 티켓에 프로젝트 ID, 요청 ID, 타임스탬프, 리전 포함).
  • 커뮤니케이션: 단일 진실 공급원(채팅 채널 및 인시던트 문서)을 유지합니다. 영향, 완화 조치, 예상 해결 시간(ETA)을 포함하여 이해관계자에게 주기적으로 업데이트를 제공합니다.
  • 완화 플레이북: 롤백, 장애 조치(failover), 기능 플래그(feature flag) 비활성화, 용량 추가. 영향 범위(blast radius)가 좁고 되돌릴 수 있는 변경을 선호합니다.

• 인시던트 후 검토 및 RCA(근본 원인 분석)

  • 증거 기반: 측정항목, 로그, 추적, 변경 이벤트를 상호 연관시킵니다. 어떤 탐지 신호가 발생했는지, 그 이유는 무엇인지, 탐지/완화까지 걸린 시간을 포함합니다.
  • 직접적인 원인뿐만 아니라 기여 요인을 식별합니다. 담당자와 마감일이 있는 구체적인 실행 항목을 기록하고, 이에 따라 런북과 알림을 업데이트합니다.
  • 비난하지 않는(Blameless) 문화는 완전한 정보 공개와 시스템적인 수정을 장려합니다.

• 운영 런북

  • 구조: 트리거 및 탐지, 빠른 진단 트리, 안전한 완화 조치, 롤백/복원 단계, 검증, 종료 기준.
  • 명령어와 필터는 복사-붙여넣기할 수 있도록 준비합니다. 응답자를 위한 최소 권한 IAM을 확인합니다(예: 쓰기 전용 백업을 위한 storage.objectCreator, 워크로드 아이덴티티를 위한 전용 서비스 계정).
  • 변경 관리를 통해 런북을 버전 관리하고, 게임 데이(game day) 중에 테스트합니다.

실용적인 문제 시나리오

Northwind Outfitters는 Google Cloud에서 지역 이커머스 플랫폼을 운영하고 있습니다. 최근 트래픽 급증 이후, 사용자들이 간헐적으로 결제 시간 초과와 느린 상품 검색을 보고하고 있습니다. 운영팀은 신속하게 신뢰성을 복구하고, 알림 노이즈를 줄이며, 여러 프로젝트에 걸쳐 진단 기능을 강화해야 합니다.

접근 방식:

1. 여러 프로젝트의 모니터링 통합

• 조치: 단일 Monitoring 작업 공간을 만들고 prod, payments, search 프로젝트를 연결합니다. 결제 및 검색에 대한 가용성, 지연 시간, 오류율을 보여주는 ‘사용자 여정’ 대시보드를 구축합니다.
• 근거: 중앙 집중식 가시성은 서비스 수준의 분류를 지원하고 서비스 간 문제(예: 검색 지연 시간이 결제 시간 초과로 이어지는 경우)를 상호 연관시키는 데 도움이 됩니다.

2. SLO 및 소진율(burn-rate) 알림 구현

• 조치: SLO 정의: 결제 99.9%가 400ms 미만, 검색 99.95%가 250ms 미만. 지연 시간 및 오류율 SLI에 대해 다중 기간 소진율 알림(1시간 동안 2%, 5분 동안 5%)을 생성합니다. 온콜 담당자에게는 페이징으로, 이해관계자에게는 채팅으로 알립니다.
• 근거: 소진율 알림은 정상적인 변동에 대해 페이징하지 않으면서 빠른 성능 저하와 지속적인 느린 소진을 포착합니다.

3. 콘텐츠 일치 기능을 갖춘 합성 가동 시간 확인(synthetic uptime check) 추가

• 조치: 퍼블릭 엔트리포인트에 대한 TCP 및 HTTPS 가동 시간 확인과 내부 결제 API에 대한 비공개 가동 시간 확인을 구성하여 응답 본문에 “ok”가 포함되어 있는지 검증합니다.
• 근거: 도달 가능성과 잘못 라우팅된 백엔드 또는 성능이 저하된 업스트림과 같은 부분적인 장애를 탐지합니다.

4. 로깅 경로 및 보존 기간 강화

• 조치: 전용 로그 버킷 생성: ops(90일), security-audit(2년, CMEK). Admin Activity, Data Access, System Event, Policy Denied 로그를 싱크를 통해 BigQuery로 라우팅하여 분석합니다. 불필요하게 많은(chatty) 헬스 체크에 대한 제외 규칙을 추가합니다.
• 근거: 적절한 크기의 보존 기간은 비용을 제어합니다. BigQuery는 신속한 포렌식을 가능하게 합니다. 제외 규칙은 중요한 증거를 잃지 않으면서 노이즈를 줄입니다.

5. 애플리케이션 진단 활성화

• 조치: Trace를 위해 OpenTelemetry로 서비스를 계측(instrument)합니다. 백엔드와 프론트엔드에 Error Reporting을 활성화합니다. 보수적인 샘플링으로 CPU 및 힙 프로필을 사용하여 결제 서비스에 Profiler를 롤아웃합니다.
• 근거: Trace는 지연 시간 핫스팟을 식별하고, Error Reporting은 새로운 오류 그룹을 강조하며, Profiler는 낮은 오버헤드로 CPU 경합 및 메모리 누수를 드러냅니다.

6. 네트워크 관측 가능성 강화

• 조치: prod 서브넷에서 VPC Flow Logs를 활성화하고(0.5 샘플링, 모든 메타데이터 포함), search 및 payments로의 인그레스에 대한 허용/거부 규칙에 방화벽 로깅을 활성화합니다. 웹 티어에서 search로, payments에서 Cloud SQL로 Connectivity Tests를 생성합니다.
• 근거: 플로우 및 방화벽 로그는 패킷 손실(drop), 재전송, 섀도우 규칙(shadowed rule)을 노출합니다. Connectivity Tests는 도달 가능성을 검증하고 잘못된 구성을 식별합니다.

7. 리소스 수준 진단 및 안전한 접근

• 조치: 불안정한 VM의 경우 직렬 콘솔로 부팅 문제를 검사합니다:
  • gcloud compute connect-to-serial-port checkout-vm –zone=us-central1-a
  • SSH가 필요한 경우 OS Login을 강제하고 “ops-admins” 그룹에 compute.osAdminLogin 권한을 부여합니다. 각 관리자는 자신의 SSH 키를 사용합니다.
• 근거: 직렬 로그는 커널 및 초기화(init) 실패를 드러냅니다. 사용자별 키를 사용하는 OS Login은 책임 추적이 가능하고 최소 권한의 접근을 보장합니다.

8. 할당량 및 리전 상태 확인

• 조치: 로그에서 최근 quotaExceeded 이벤트를 검토합니다. search 오토스케일링을 위해 리전별 API 및 IP 할당량을 늘립니다. 영향을 받는 리전의 서비스 상태 권고를 확인하고, 로드 밸런서 가중치를 사용하여 일시적으로 트래픽을 전환합니다.
• 근거: 할당량 조절(throttling) 및 리전 장애는 일반적인 간헐적 장애 원인입니다. 선제적인 스케일링과 트래픽 조정은 영향을 완화합니다.

9. 노이즈 감소 및 런북 업데이트

• 조치: 인스턴스별 CPU 알림을 서비스 수준 포화도 알림으로 교체합니다. 조치가 필요 없는 알림을 음소거하기 위해 점검 기간을 추가합니다. 새로운 분류 쿼리, 추적 대시보드, 롤백 절차로 런북을 업데이트합니다.
• 근거: 페이징 피로를 줄이고 일관되고 안전한 대응을 가속화합니다.

10. 인시던트 후 검토 및 조치

• 조치: 비난 없는 검토를 수행합니다. 소진율 인시던트를 증가된 검색 tail latency 및 최근 인덱스 롤아웃과 연관시킵니다. 실행 항목: 검색을 위한 카나리 릴리스, 인덱스 크기 가드레일, 오토스케일러 헤드룸 추가, 주기적인 알림 채널 테스트 약속.
• 근거: 증거 기반 RCA는 재발을 방지하고 탐지, 완화 및 복원력을 향상시킵니다.

← 배포 · 모든 도메인 · 보안 →

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

Google 찾아보기 →