모니터링 및 로깅 완전 정복

DOP-C02 모니터링 도메인(15%)의 핵심인 CloudWatch 수집 파이프라인, X-Ray 분산 추적, EventBridge 이벤트 자동화, Lambda 기반 자동 복구 아키텍처를 실전 시나리오로 정리합니다.

DOP-C02 시험에서 모니터링 및 로깅 도메인은 전체 15%를 차지합니다. 단순히 "어떤 서비스가 어떤 데이터를 수집하는가"를 묻는 것이 아니라, 수집-분석-자동화가 연결된 완전한 파이프라인을 설계할 수 있는지를 평가합니다. 실무에서 온콜 엔지니어가 새벽 장애를 대응하는 것처럼, 시험도 "이 상황에서 어떤 조합이 가장 적합한가"를 물어봅니다.

 

로그 수집 파이프라인 설계

모니터링의 첫 단계는 데이터를 올바르게 수집하는 것입니다. CloudWatch는 단일 에이전트로 로그와 커스텀 메트릭을 동시에 수집할 수 있는 강력한 플랫폼입니다.

CloudWatch Agent와 커스텀 메트릭

기본 CloudWatch 메트릭에는 EC2 인스턴스의 메모리 사용률과 디스크 I/O 상세 정보가 포함되지 않습니다. 이를 수집하려면 반드시 CloudWatch Agent를 설치해야 합니다. 에이전트는 EC2(Linux/Windows)와 온프레미스 서버 모두에서 동일한 방식으로 동작합니다.

수천 대 EC2 인스턴스를 운영하는 게임 기업 시나리오를 생각해보겠습니다. 자체 개발한 로그 수집 데몬을 유지보수하던 중, 신규 인스턴스 배포 시 설정 누락이 빈번하게 발생했습니다. 해결책은 CloudWatch Agent + AWS Systems Manager State Manager 조합입니다. State Manager는 원하는 상태를 정의하면 신규 인스턴스에 에이전트를 자동 배포하고, SSM Parameter Store에 저장된 에이전트 구성 파일을 중앙에서 버전 관리합니다.

| 수집 방식 | 대상 | 주요 특징 | |---------|------|---------| | CloudWatch Agent | EC2, 온프레미스 | 메모리/디스크 커스텀 메트릭, 로그 파일 수집 | | CloudWatch Embedded Metric Format (EMF) | Lambda, ECS, EC2 | JSON 로그로 메트릭 임베드, PutMetricData 직접 호출 없음 | | AWS Distro for OpenTelemetry (ADOT) | 컨테이너, 서버리스 | OpenTelemetry 표준 기반, X-Ray/CloudWatch 동시 전송 |

EMF는 API 비용 절감에 효과적입니다. 여러 메트릭 데이터 포인트를 개별적으로 PutMetricData로 전송하면 API 호출당 요금이 발생하지만, EMF는 구조화된 JSON 로그를 CloudWatch Logs로 전송하면 AWS가 자동으로 메트릭을 추출합니다. PutMetricData 배치 전송보다 비용이 낮고, 추출된 메트릭은 일반 CloudWatch 메트릭과 동일하게 알람을 설정할 수 있습니다.

 

Kinesis Data Firehose와 Lambda 변환 파이프라인

IoT 플랫폼에서 수천 개 디바이스로부터 서로 다른 형식의 로그를 수신하고 S3에 저장한 뒤 Athena로 분석해야 하는 시나리오가 자주 출제됩니다. 정답은 Kinesis Data Firehose + Lambda 변환 조합입니다.

Kinesis Data Firehose는 완전 관리형 서비스로 서버 관리가 불필요하며, Lambda 함수를 데이터 변환 프로세서로 연결해 다양한 형식의 로그를 JSON으로 변환한 후 S3에 적재합니다. 버퍼 크기(1~128MB)와 버퍼 시간(60~900초) 설정으로 배치 전달이 이루어져 준실시간 처리가 가능합니다.

Kinesis Data Streams와 혼동하기 쉬운데 차이점이 명확합니다. Data Streams는 샤드 관리와 체크포인팅 구현이 필요해 운영 복잡도가 높습니다. Firehose는 소비자 코드 없이 S3, Redshift, OpenSearch로 자동 전달합니다. 비용도 Firehose가 더 낮습니다.

변환 실패 레코드는 별도 S3 버킷에 보존되어 데이터 유실이 없습니다. 이 "오류 레코드 보존" 동작은 시험에서 "데이터 유실 없어야 한다"는 조건과 함께 출제됩니다.

 

계정 수준 구독 정책과 크로스 계정 로그 집계

수백 개의 로그 그룹이 수시로 추가되는 환경에서 각각 구독 필터를 설정하는 것은 현실적으로 불가능합니다. CloudWatch Logs 계정 수준 구독 정책은 한 번 설정하면 해당 계정의 모든 현재 및 미래 로그 그룹에 자동 적용됩니다. 이것이 시험에서 "운영 오버헤드 최소화"와 함께 나오는 정답 패턴입니다.

멀티 계정 로그 중앙 집계 아키텍처:

각 멤버 계정: CloudWatch Logs 계정 수준 구독 정책 설정 중앙 Audit 계정: Kinesis Data Firehose 수신 대기 멤버 계정 구독 필터 → 중앙 Firehose → S3 버킷 (크로스 계정 전달) S3 Lifecycle Policy: 90일 후 S3 Glacier 자동 전환

Export Task와 구독 필터의 차이도 중요합니다. Export Task는 배치/수동 방식으로 최대 12시간 지연이 발생합니다. 구독 필터는 스트리밍/자동 방식으로 준실시간 전달이 가능합니다. 장기 보관 비용 최적화를 위해서는 S3 Standard에서 Glacier 계열로 자동 전환하는 Lifecycle Policy가 필수입니다.

 

ALB 액세스 로그의 타이밍 필드 분석

ALB(Application Load Balancer) 액세스 로그에는 요청 처리 시간이 세 가지 필드로 나뉩니다. 이 세부 내용은 시험에서 정확히 구분해 물어봅니다.

| 필드 | 의미 | 지연 원인 분석 | |------|------|-------------| | request_processing_time | 클라이언트 요청을 받아 대상에 전달하기까지 | ALB 자체 처리 지연 | | target_processing_time | 대상(EC2/컨테이너)이 요청을 처리한 시간 | 애플리케이션 성능 병목 | | response_processing_time | 대상의 응답을 클라이언트에 반환하기까지 | 네트워크/ALB 반환 지연 |

target_processing_time이 높으면 애플리케이션 코드나 데이터베이스 쿼리 성능 문제입니다. request_processing_time이 높으면 ALB 용량 문제입니다. 이 필드들은 CloudWatch Logs Insights나 Athena로 분석합니다.

 

분산 추적과 하이브리드 모니터링

X-Ray 분산 추적

마이크로서비스 아키텍처에서 특정 API 호출이 느릴 때 어느 서비스가 병목인지 파악하기 어렵습니다. X-Ray는 요청이 여러 서비스를 거치는 전체 경로를 시각화합니다.

X-Ray의 핵심 개념: 트레이스(Trace): 단일 요청의 전체 실행 경로 세그먼트(Segment): 각 서비스에서 처리한 단위 서브세그먼트(Subsegment): 외부 API 호출, DB 쿼리 등 세부 작업 서비스 맵: 서비스 간 의존성과 응답 시간을 시각적으로 표시

Lambda, ECS, EC2, API Gateway, Elastic Beanstalk에서 X-Ray SDK를 사용해 계측할 수 있습니다. Lambda는 X-Ray Active Tracing 옵션을 활성화하면 별도 코드 수정 없이 기본 트레이싱이 가능합니다.

Amazon Managed Grafana + Prometheus — 하이브리드 환경

EKS, ECS, 온프레미스가 혼재하는 하이브리드 환경의 통합 모니터링에는 Amazon Managed Grafana + Amazon Managed Service for Prometheus 조합이 출제됩니다. 이 조합은 Prometheus 에코시스템과 호환되면서도 서버 관리가 불필요한 완전 관리형 솔루션입니다.

CloudWatch와의 차이점은 메트릭 수집 모델입니다. CloudWatch는 푸시(push) 방식이고, Prometheus는 풀(pull) 방식으로 타겟에서 메트릭을 스크래핑합니다. Grafana는 두 데이터 소스를 모두 지원해 단일 대시보드로 CloudWatch 메트릭과 Prometheus 메트릭을 통합 시각화할 수 있습니다.

 

CloudWatch Logs 분석 도구

Logs Insights와 Metric Filter

CloudWatch Logs Insights는 SQL과 유사한 쿼리 언어로 로그를 대화형으로 분석합니다. 준실시간 검색이 가능하며 Elastic Beanstalk, ECS 등의 애플리케이션 로그를 실시간 조회할 수 있습니다. Athena는 배치 쿼리 방식으로 S3에 저장된 데이터를 분석하는 데 적합합니다.

CloudWatch Logs Metric Filter는 로그 스트림에서 정규식 패턴을 실시간으로 감지해 CloudWatch 사용자 지정 메트릭으로 변환합니다. 별도 코딩 없이 콘솔에서 구성할 수 있어 운영 오버헤드가 낮습니다.

보안 운영 센터 시나리오: 방화벽 로그에서 심각도 CRITICAL 이벤트 발생 시 즉시 알림을 받아야 할 때, 추가 보안 서비스 없이 CloudWatch Logs Metric Filter + CloudWatch Alarm + SNS 조합으로 구현합니다. 이 패턴은 "코드 없이", "운영 오버헤드 최소화", "기존 CloudWatch Logs 기반"이라는 조건이 함께 나올 때의 정답입니다.

Metric Filter vs Subscription Filter 구분: Metric Filter: 패턴 매칭 → 카운트 메트릭 생성 → Alarm 트리거 (알람용) Subscription Filter: 로그 이벤트를 Lambda/Kinesis/Firehose로 실시간 스트리밍 (데이터 파이프라인용)

 

이벤트 기반 자동화와 자동 복구

EventBridge 이벤트 패턴

EventBridge는 AWS 서비스들이 발행하는 이벤트를 감지해 자동화 체인을 구성하는 허브입니다. 시험에서 중요한 이벤트 패턴들:

| 서비스 | source 값 | 주요 이벤트 | |--------|----------|-----------| | EC2 Auto Scaling | aws.autoscaling | EC2_INSTANCE_LAUNCH_UNSUCCESSFUL (시작 실패) | | AWS Trusted Advisor | aws.trustedadvisor | 서비스 한도 80% 경고 이벤트 | | AWS Health | aws.health | 인스턴스 retirement, 서비스 장애 | | Amazon Cognito | aws.cognito-idp | 사용자 인증 이벤트 (Post Authentication Trigger는 Lambda 트리거 방식) |

Auto Scaling 인스턴스 시작 실패 감지 시나리오: 프로모션 이벤트 중 Auto Scaling이 인스턴스 시작에 실패했을 때 수 시간 후에야 인지하는 문제를 해결하려면 EventBridge 규칙에서 EC2_INSTANCE_LAUNCH_UNSUCCESSFUL 이벤트를 감지하고 SNS로 즉시 알림을 전송합니다. 추가 인프라 구축 없이 EventBridge + SNS만으로 구성됩니다.

수명 주기 후크(Lifecycle Hook)와 혼동하지 마세요. 수명 주기 후크는 인스턴스가 시작 성공 후 Pending 상태에서 추가 작업을 실행하는 것으로, 시작 실패 자체를 감지하는 데는 사용할 수 없습니다.

 

CloudWatch Alarms + Lambda 자동 복구

CloudWatch Alarm은 단순한 알림 전송을 넘어 Lambda 함수를 트리거해 자동 복구 조치를 실행할 수 있습니다.

SSH 직접 로그인 감지 및 자동 격리 시나리오: Session Manager만 허용하고 SSH를 금지했으나 일부 인스턴스에서 SSH 로그인 기록이 발견되었습니다. 구현 방법:

CloudWatch Agent로 /var/log/secure (Linux) 수집 CloudWatch Logs Metric Filter로 SSH 로그인 패턴 정규식 감지 CloudWatch Alarm이 임계값(1 이상) 초과 시 Lambda 트리거 Lambda가 해당 인스턴스의 보안 그룹을 격리 그룹으로 교체하거나 인스턴스 종료 SNS로 보안팀에 즉시 알림

CloudTrail로 SSH 로그인을 감지할 수 없습니다. CloudTrail은 AWS API 호출을 기록하는 서비스이므로 OS 레벨의 SSH 세션은 추적 대상이 아닙니다.

AWS Config 규칙과 자동 복구 조치

AWS Config Rules는 리소스의 규정 준수 상태를 지속적으로 평가합니다. 규칙 위반 감지 시 Remediation Action을 연결해 SSM Automation 런북을 자동으로 실행할 수 있습니다. 예를 들어 S3 버킷 퍼블릭 액세스 활성화 감지 시 자동으로 차단 설정을 복원하는 워크플로우를 구성할 수 있습니다.

 

Route 53 헬스 체크와 ALB 헬스 체크 통합

헬스 체크 계층도 시험에 자주 출제됩니다.

블로그 목록으로 돌아가기