Amazon DOP-C02: 모니터링, 로깅 및 옵저버빌리티 — 학습 가이드

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

개요

AWS에서의 모니터링, 로깅 및 가시성(observability)은 지표, 로그, 추적, 이벤트 및 상태 원격 측정(telemetry)을 실행 가능한 신호로 결합하는 것을 필요로 합니다. 효과적인 아키텍처는 지표, 경보, 대시보드를 위해 Amazon CloudWatch를, 로그 수집 및 분석을 위해 CloudWatch Logs 및 Logs Insights를, 분산 추적을 위해 AWS X-Ray를, 감사 및 무결성을 위해 AWS CloudTrail을, 이벤트 기반 탐지 및 자동화를 위해 Amazon EventBridge를, 계정별 서비스 이벤트를 위해 AWS Health를, 그리고 대규모 검색 및 상관관계 분석을 위한 중앙 집중식 파이프라인(Kinesis Data Firehose 및 OpenSearch)을 사용합니다. 아래 패턴들은 노이즈 감소, 정확한 신호 라우팅, 자동화, 멀티 계정/멀티 리전 운영을 강조합니다.

CloudWatch 지표, 경보, 대시보드 및 복합 경보

CloudWatch 지표는 SLO, 스케일링, 경보의 기반입니다. 신호를 분리하기 위해 세분화된 차원(dimension)을 가진 사용자 지정 지표를 게시합니다(예: apiOperation, appVersion, statusCode). 구조화된 로그와 함께 CloudWatch Embedded Metric Format(EMF)을 사용하여 Lambda, 컨테이너, EC2에서 고유 카디널리티(high-cardinality) 차원을 효율적으로 내보내 PutMetricData API 오버헤드를 피합니다.

강력한 평가 로직으로 경보를 구성합니다:

데이터 세분성 및 SLO 기간에 맞춰 기간을 선택합니다.
일시적인 노이즈에 대한 복원력을 위해 datapointsToAlarm(n개 중 m개)을 설정합니다.
배포 또는 일시 중지 중 거짓 양성(false positive)을 방지하기 위해 TreatMissingData를 사용합니다.
기준선이 계절에 따라 변동할 때는 이상 탐지 밴드를 활용하고, 파생 지표(p95 지연 시간, 오류 백분율, 포화 비율)에는 지표 수학(metric math)을 사용합니다.
경보에 조치를 연결합니다: SNS를 통해 알림, OpsCenter OpsItems 생성, SSM Automation 실행 또는 EC2 인스턴스 복구. 스케일링 정책은 조치를 위해 경보 상태를 참조할 수 있지만, 복합 경보는 직접 스케일링을 트리거할 수 없습니다.

복합 경보는 여러 기본 경보를 AND/OR 논리로 결합하여 경보 피로도를 줄입니다. 예를 들어, p95 지연 시간이 높고 AND 5xx 비율이 임계값을 초과하고 AND CPU 포화 상태가 지속될 때만 경보를 발생시켜 사용자 영향에 맞춰 조정합니다. 복합 경보는 교차 계정 가시성 또는 중앙 계정으로의 지표 스트림을 통해 여러 리전/계정에 걸친 하위 경보로부터 상태 업데이트를 수신합니다.

대시보드는 여러 서비스에 걸친 핵심 지표를 시각화합니다. 지표, Logs Insights 쿼리 결과 및 경보 상태를 위한 위젯을 사용합니다. 대시보드 규칙(이름 지정, 시간 범위, SLO 오버레이)을 표준화하고 CloudWatch Observability Access Manager(OAM)를 사용하여 교차 리전/교차 계정 보기를 활용합니다. 임시 상관관계 분석을 위해 Logs Insights 및 X-Ray ServiceLens 위젯을 서비스 맵 위젯 및 Kinesis Firehose 오류율과 나란히 고정합니다.

CloudWatch Logs: 로그 그룹, 지표 필터, 구독 필터 및 Logs Insights

애플리케이션/구성 요소 및 수명 주기 단계별로 로그 그룹을 구성합니다. 명시적인 보존 정책을 설정하고(‘만료되지 않음’에 의존하지 말 것) 필요한 경우 KMS 암호화를 활성화합니다. 리소스 정책과 세분화된 IAM을 사용하여 생산자(producer)와 구독자(subscriber)를 제어합니다. 처리량이 많은 수집의 경우, 적절한 로그 스트림 동시성과 배치를 보장합니다.

지표 필터는 로그 패턴을 지표로 변환합니다. 추출된 토큰(JSON 또는 공백으로 구분)으로 필터 패턴을 정의하고 토큰을 지표 차원에 매핑합니다. 이를 통해 생산자를 수정하지 않고도 로그에서 직접 게시되는 API별, 버전별, 응답 코드별 지표와 같은 사용 사례를 지원합니다. 단위와 기본값이 올바른지 확인하고, 이벤트당 1을 선호하며 지표 수학을 통해 비율을 도출합니다. 이 지표들을 SLO 경보 및 대시보드에 사용합니다.

구독 필터는 거의 실시간으로 로그를 다음 대상으로 스트리밍합니다:

변환 및 S3/OpenSearch로의 전송을 위한 Kinesis Data Firehose.
사용자 지정 소비자를 위한 Kinesis Data Streams.
사용자 지정 라우팅, PII 편집 또는 이벤트 기반 알림을 위한 Lambda. 교차 계정 구독을 위해 IAM 역할을 가진 CloudWatch Logs 대상을 사용합니다. 재시도 및 역압(backpressure)을 계획합니다. Lambda와 Firehose는 각각 내장된 재시도 및 DLQ/오류 S3 버킷을 제공합니다.

CloudWatch Logs Insights는 로그에 대한 대화형 서버리스 쿼리를 제공합니다. 핵심 연산자에는 fields, filter, parse, stats, sort, limit, dedup, 그리고 시간 버킷팅을 위한 bin이 포함됩니다. JSON 필드를 파싱하거나 텍스트 로그에 대해 grok과 유사한 파싱을 사용합니다. 예시:

filter status >= 500 | stats count() by apiOperation, appVersion
parse @message /duration=(?<ms>\d+)/ | stats pct(@ms,95) by service 자주 사용하는 쿼리는 팀 재사용을 위해 QueryDefinition으로 저장하고 쿼리 위젯으로 대시보드에 포함합니다. 자동화를 위해 EventBridge를 통해 Lambda를 예약하여 StartQuery/GetQueryResults를 실행하고 요약 정보를 SNS 또는 OpsCenter에 게시합니다. 비용을 제어하기 위해 쿼리 범위를 특정 로그 그룹 및 시간 창으로 제한합니다.

AWS X-Ray: 추적, 샘플링 규칙, 서비스 맵, 주석

X-Ray는 서비스 전반의 분산 추적을 캡처하여 지연 시간의 원인과 장애 경계를 찾습니다. AWS Distro for OpenTelemetry(ADOT) 또는 X-Ray SDK로 서비스를 계측(instrument)하고, 추적 헤더(예: X-Amzn-Trace-Id)를 전파하며, 필요한 곳(ECS/EKS/EC2)에서 X-Ray 데몬/에이전트를 실행합니다. 많은 관리형 서비스가 기본적으로 통합됩니다(API Gateway, 액세스 로그 프록시 추적을 통한 ALB, 활성 추적이 설정된 Lambda, 하위 세그먼트를 통한 Step Functions).

샘플링 규칙은 데이터 볼륨과 신호 충실도를 제어합니다. 중앙 샘플링 규칙 세트를 다음과 같이 사용합니다:

서비스별 기준 추적을 위한 초당 고정 리저버(reservoir).
처리량에 따라 확장되는 비율 기반 샘플링 백분율.
핫 경로 및 오류 시나리오에 대한 규칙 우선순위 및 서비스/URL 매칭. 비용을 관리하면서 관측 가능성을 확보하기 위해, 인시던트 발생 시와 카나리 트래픽에 대해 샘플링을 늘립니다.

서비스 맵은 호출 그래프를 시각화하여 지연 시간, 오류율, 스로틀(throttle) 표시기가 있는 엣지(edge)를 보여줍니다. 추적을 드릴다운하여 다운스트림 종속성에 대한 세그먼트와 하위 세그먼트를 검사합니다. customerTier, apiOperation, appVersion 또는 AWS 요청 ID와 같은 고유성(high-cardinality)이 높은 필터링을 위해 주석(인덱싱된 키-값 페어)을 사용합니다. 인덱스 폭증을 피하기 위해, 인덱싱되지 않는 상세한 컨텍스트에는 메타데이터를 사용합니다. X-Ray 추적 그룹을 CloudWatch ServiceLens와 결합하여 로그, 메트릭, 추적을 단일 뷰에서 연관시킵니다. 필터 표현식(예: annotation.appVersion = “2.3.1” and fault = true)을 생성하여 회귀(regression)를 격리하고, 대상 로그 검색을 위해 추적 ID를 내보냅니다.

거버넌스 및 이벤트: CloudTrail, EventBridge, AWS Health

CloudTrail은 거버넌스 및 포렌식 분석을 위해 API 활동을 기록합니다. 모든 계정과 모든 리전에 걸쳐 조직 추적(organization trail)을 활성화하고, SSE-KMS로 암호화된 중앙 S3 버킷으로 전송하며, 로그 파일 검증을 활성화하고, 거의 실시간 탐지를 위해 CloudWatch Logs와 통합합니다. 이벤트 클래스를 구분합니다:

관리 이벤트: 컨트롤 플레인(예: CreateUser, RunInstances). 필요에 따라 읽기 전용 및 쓰기 전용을 포함하도록 구성합니다.
데이터 이벤트: S3 객체 수준 액세스, Lambda Invoke, DynamoDB 항목 API, EKS API 서버 호출과 같은 대용량 데이터 플레인 작업. 비용을 제어하기 위해 데이터 이벤트의 범위를 선택적으로(버킷/함수/테이블별로) 지정합니다. CloudTrail Insights를 사용하여 비정상적인 API 급증을 탐지하고, 자동 복구를 위해 CloudTrail 이벤트를 EventBridge로 전송합니다. 감사 중에는 다이제스트 파일과 AWS CLI cloudtrail validate-logs 명령을 사용하여 로그 무결성을 검증합니다.

EventBridge는 탐지 및 자동화를 위한 이벤트 패브릭을 제공합니다. AWS 서비스 이벤트에는 기본 이벤트 버스를 사용하고, 애플리케이션 도메인 이벤트에는 사용자 지정 버스를 생성합니다. 소스, detail-type, 세부 정보 필드, 접두사, 숫자 범위, “anything-but"과 일치하는 이벤트 패턴을 정의합니다. 입력 변환기를 적용하여 이벤트를 재구성하고, 계정 간 게시를 위해 리소스 기반 정책을 연결하며, 대상에 재시도/DLQ를 구성합니다. 일반적인 대상에는 Lambda(복구), Step Functions(오케스트레이션), SQS(디커플링), Systems Manager Automation(운영 작업), CodePipeline(CI 트리거), SNS(알림)가 포함됩니다. 소비자 중단으로부터 복구하기 위해 이벤트를 아카이브하고 재생하며, 스키마 레지스트리를 사용하여 강력한 형식의 이벤트 모델을 생성합니다.

AWS Health는 계정별 서비스 이벤트, 예정된 변경 사항, 운영 문제를 알려줍니다. source가 aws.health이고 detail-type이 AWS Health Event인 EventBridge를 통해 통합하여 인시던트 채널로 라우팅하거나, OpsCenter OpsItems를 열거나, 유지 관리 기간 동안 안전한 종료/확장 작업을 트리거합니다. 위임된 관리자 계정과 함께 조직 보기(Organizational View)를 사용하여 모든 계정의 Health 이벤트를 집계하고, AWS Health API 또는 AWS Health Aware 솔루션을 사용하여 선별된 알림을 온콜 시스템으로 푸시하는 것을 고려합니다.

Kinesis Data Firehose와 OpenSearch를 사용한 중앙 집중식 로깅

다중 계정, 다중 리전 로깅 전략은 수집 및 검색을 표준화합니다. 각 프로듀서 계정에서 중앙 Kinesis Data Firehose가 지원하는 교차 계정 로그 대상으로 CloudWatch Logs 구독 필터를 구성합니다. Firehose 기능을 활성화합니다:

정규화(JSON), PII(개인 식별 정보) 수정, AWS 계정, 리전, VPC 및 서비스 메타데이터 보강을 위한 Lambda를 통한 데이터 변환.
Athena에서의 쿼리 성능 최적화를 위해 S3로 전송 시 압축(GZIP) 및 동적 파티셔닝.
프라이빗 엔드포인트를 위한 KMS 암호화 및 VPC 전송. 짧은 지연 시간의 검색과 Kibana/OpenSearch Dashboards 시각화를 위해 Amazon OpenSearch Service로 전송합니다. 인덱스 템플릿, 롤오버 및 보존을 위한 ILM/ISM 정책, 사용자를 인덱스 패턴(예: 계정/팀/서비스)에 매핑하는 세분화된 액세스 정책을 사용합니다. 실패한 문서에 대한 오류 출력을 S3로 구성하고 Firehose 전송 및 OpenSearch 수집 지표(DeliveryToElasticsearch.Success, ElasticsearchFailedRequests)를 모니터링합니다. 트래픽 양이 매우 많은 경우, 비용을 제어하기 위해 Firehose를 통해 모든 로그를 S3에 저장하고 일부 서브셋만 OpenSearch로 스트리밍하며, 장기적인 조사를 위해 S3에 대한 온디맨드 Athena 쿼리를 사용하는 것을 고려합니다.

빠르고 저렴한 카운터를 위해 이 파이프라인을 CloudWatch 지표 필터와 결합하고, 임시 심층 조사를 위해 Logs Insights와 결합합니다. Firehose/OpenSearch 이상 또는 CloudWatch 경보에 의해 트리거되는 EventBridge 규칙을 사용하여 해결 조치를 시작하거나 인시던트를 발생시킵니다.

실제 문제 시나리오

Airbnb는 EKS 및 Lambda에 배포된 마이크로서비스 전반에서 간헐적으로 API 오류 및 지연 시간 급증을 경험하며, 여러 버전의 모바일 앱이 사용되고 있습니다. 운영팀은 API 작업, 응답 코드, 앱 버전별 거의 실시간 탐지, 추적 및 로그 전반에 걸친 신속한 근본 원인 분석, 알려진 실패 패턴에 대한 자동화된 해결, 거버넌스 수준의 감사 추적이 필요합니다.

구조화된 로깅 표준화

서비스(EKS, Lambda)에서 apiOperation, statusCode, appVersion, tenantId, latencyMs 필드를 포함하는 EMF 구조의 JSON 로그를 구현합니다.
이유: EMF를 사용하면 낮은 오버헤드로 CloudWatch에서 직접 지표를 추출하고, 정확한 경보를 위해 고유 카디널리티 차원을 사용할 수 있습니다.

CloudWatch Logs 지표 필터 생성

각 서비스 로그 그룹에 대해 apiOperation, statusCode, appVersion별로 카운터를 증가시키는 지표 필터를 정의합니다.
이유: 추가 코드 경로 없이 차원별 지표를 생성하여 API 및 클라이언트 버전별 대시보드와 실행 가능한 경보를 활성화합니다.

계층화된 CloudWatch 경보 및 복합 경보 구축

p95 지연 시간, 5xx 비율, 포화 상태(CPU, 메모리, 동시성/스로틀)에 대해 경보를 설정합니다. 복합 경보 생성: 3회 연속 기간 중 2회 동안 LatencyHigh AND ErrorsHigh.
이유: 노이즈를 줄이고 사용자에게 영향을 미치는 인시던트에 집중합니다.

대상 샘플링을 사용한 X-Ray 추적 배포

EKS에서는 ADOT 수집기를 사용하고 Lambda에서는 활성 추적을 사용합니다. 모든 오류 추적과 성공적인 호출의 대표 샘플을 캡처하도록 샘플링 규칙을 정의하며, 새 앱 버전에는 더 높은 샘플링을 적용합니다.
이유: 비용을 제어하면서 실패에 대한 가시성을 보장하고 성능 병목 지점에 대한 충분한 커버리지를 확보합니다.

ServiceLens 및 Logs Insights와 연관 분석

지표 위젯, X-Ray 서비스 맵, Logs Insights 쿼리(예: filter status >= 500 | stats count() by apiOperation, appVersion)를 결합한 대시보드를 생성합니다.
이유: 단일 창에서의 연관 분석을 통해 어떤 작업과 클라이언트 버전에서 성능 저하가 발생했는지 신속하게 진단할 수 있습니다.

Firehose를 통해 OpenSearch 및 S3로 로그 중앙 집중화

정규화, PII 수정, 계정/리전 정보 보강을 위한 Lambda 변환 기능이 있는 중앙 Firehose로 구독 필터를 구성합니다. 7일간의 핫 검색을 위해 OpenSearch로, 영구 보존 및 Athena 쿼리를 위해 S3로 전송합니다.
이유: 현재 문제에 대한 빠른 교차 팀 검색과 저비용의 과거 데이터 분석이 가능합니다.

EventBridge를 사용한 탐지 및 해결 자동화

CloudWatch 경보 상태 변경 및 선택된 CloudTrail 쓰기 API 이벤트(예: 보안 그룹 수정)에 대한 EventBridge 규칙을 생성합니다. 대상: 안전한 롤백(예: 기능 플래그 되돌리기)을 위한 Lambda 및 다단계 해결을 위한 Step Functions.
이유: 이벤트 기반 제어 루프는 MTTR(평균 해결 시간)을 단축하고 가드레일을 강제합니다.

AWS Health 및 유지 관리 처리 통합

EC2, EKS 또는 네트워킹에 영향을 미치는 aws.health 이벤트에 대한 EventBridge 규칙을 추가합니다. 노드를 차단/드레이닝하거나 트래픽을 전환하기 위해 SSM Automation을 대상으로 지정합니다.
이유: 예약되거나 운영상의 문제에 대한 사전 예방적 완화 조치는 다운타임을 줄입니다.

CloudTrail 조직 추적 및 무결성으로 거버넌스 강화

S3 및 Lambda에 대한 데이터 이벤트, SSE-KMS 암호화, 로그 파일 검증 기능이 있는 조직의 다중 리전 추적을 활성화합니다. 이상 탐지 및 조사를 위해 CloudWatch Logs 및 OpenSearch로 스트리밍합니다.
이유: 완전하고 변조 방지된 감사는 규정 준수를 충족하고 RCA(근본 원인 분석)를 가속화합니다.

알림 및 운영 통합

중요한 이벤트를 SNS 및 온콜 시스템으로 라우팅하고, 런북이 첨부된 OpsCenter OpsItems를 열고, 소유권 및 심각도에 대한 경보 태그를 첨부합니다.
이유: 명확한 소유권과 자동화된 런북은 대응 품질과 속도를 향상시킵니다.

이 설계는 짧은 지연 시간과 풍부한 차원의 지표(CloudWatch + EMF), 심층 추적 연관 분석(X-Ray + ServiceLens), 대규모 검색(OpenSearch + S3/Athena), 이벤트 기반 해결(EventBridge + Lambda/SSM/Step Functions), 감사 가능한 거버넌스(무결성이 보장된 CloudTrail)를 결합하기 위해 선택되었습니다. 샘플링, 보존 계층, 실제 사용자 영향을 반영하는 대상 지정 경보를 통해 비용과 충실도의 균형을 맞춥니다.

← 코드형 인프라 및 구성 관리 · 모든 도메인 · 보안 →

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