파이프라인을 만들었다고 끝이 아닙니다. 잘 돌아가고 있는지 지속적으로 확인해야 합니다. 데이터 처리 작업이 실패했는데 6시간 후에야 알게 된다면, 그 사이에 잘못된 데이터가 보고서에 반영될 수 있습니다. 모니터링은 문제를 빠르게 발견하는 것이고, 데이터 품질 관리는 애초에 잘못된 데이터가 파이프라인을 통과하지 못하게 막는 것입니다. DEA-C01 시험에서 이 주제는 운영 안정성과 데이터 신뢰성 문제로 자주 출제됩니다.
CloudWatch — AWS의 중앙 모니터링 서비스
CloudWatch는 AWS에서 발생하는 거의 모든 것을 관찰할 수 있는 모니터링 플랫폼입니다. 건강 검진 기계처럼 서비스의 상태를 숫자로 측정하고, 이상이 생기면 알림을 보냅니다.
메트릭(Metrics): 수치로 표현되는 측정값입니다. Lambda 함수의 실행 횟수, Glue 작업의 실행 시간, Kinesis 스트림의 지연 시간 등이 메트릭입니다. CloudWatch에 자동으로 수집되는 메트릭도 있고, 코드에서 직접 발행하는 커스텀 메트릭도 있습니다.
알람(Alarms): 메트릭이 임계값을 초과하면 알림을 보내는 설정입니다. 예를 들어 Lambda 오류율이 5%를 넘으면 SNS로 이메일을 발송하거나, Auto Scaling 정책을 트리거할 수 있습니다.
로그(Logs): CloudWatch Logs는 각 서비스에서 발생하는 텍스트 로그를 수집합니다. Lambda 함수의 출력, Glue 작업의 오류 메시지, EMR 클러스터의 시스템 로그가 모두 CloudWatch Logs에 저장됩니다.
Logs Insights: CloudWatch Logs에 저장된 로그를 SQL과 유사한 언어로 쿼리합니다. 대량의 로그 중에서 특정 오류 메시지를 찾거나, 시간대별 오류 빈도를 집계하는 데 사용합니다.
서비스별 모니터링
각 AWS 서비스는 고유한 메트릭을 CloudWatch에 발행합니다.
Glue 모니터링: : Glue 작업이 읽은 데이터 양 : 실패한 태스크 수 : JVM 힙 메모리 사용률 작업 실행 이력은 Glue 콘솔에서 직접 확인 가능
EMR 모니터링: : 클러스터가 아무 작업 없이 유휴 상태인지 여부 : 리소스 부족으로 대기 중인 컨테이너 비율 YARN ResourceManager UI로 개별 작업 진행 상황 확인
Redshift 모니터링: : 현재 연결 수 , : 디스크 읽기/쓰기 지연 : CPU 사용률 Query Execution Plans(실행 계획)으로 느린 쿼리 분석
Kinesis IteratorAge: 가장 중요한 Kinesis 메트릭입니다. IteratorAge는 스트림에서 가장 오래된 미처리 레코드의 나이(밀리초)입니다. 이 값이 0에 가까우면 소비자가 실시간으로 처리하고 있는 것이고, 값이 계속 커지면 소비 속도가 생산 속도를 따라가지 못하고 있다는 신호입니다.
성능 트러블슈팅
각 서비스에서 성능 문제가 생겼을 때 확인해야 할 점들입니다.
Glue 성능: DPU(Data Processing Unit)는 Glue 작업의 컴퓨팅 단위입니다. DPU가 부족하면 처리가 느립니다. 하지만 무조건 늘리면 비용이 증가합니다. 최적 DPU는 데이터 크기와 변환 복잡도에 따라 다릅니다. 과 메모리 메트릭을 함께 보고 병목 지점을 파악합니다.
EMR 성능: 작업이 느리다면 먼저 인스턴스 타입을 확인합니다. 메모리 집약적 Spark 작업은 메모리 최적화 인스턴스(r 시리즈)가, 컴퓨팅 집약적 작업은 컴퓨팅 최적화 인스턴스(c 시리즈)가 적합합니다. 스팟 인스턴스를 혼합하면 비용을 줄일 수 있지만 중단 위험이 있습니다.
Kinesis 샤드: Kinesis Data Streams의 처리량이 한계에 달하면 IteratorAge가 증가합니다. 각 샤드는 초당 1MB 쓰기, 초당 2MB 읽기를 처리합니다. 처리량이 부족하면 샤드를 추가(리샤딩)합니다.
데이터 품질의 다섯 가지 차원
데이터 품질은 단순히 "맞다/틀리다"가 아닙니다. 여러 차원에서 평가합니다.
| 차원 | 의미 | 예시 | |------|------|------| | 완전성(Completeness) | 필수 값이 있는가 | 이메일 필드가 NULL인 레코드 비율 | | 유일성(Uniqueness) | 중복이 없는가 | 같은 주문 ID가 두 번 나타나는 경우 | | 유효성(Validity) | 형식과 범위가 맞는가 | 날짜가 2099년인 레코드, 나이가 -5인 레코드 | | 일관성(Consistency) | 여러 시스템 간 값이 일치하는가 | CRM의 고객 수와 웨어하우스의 고객 수가 다름 | | 시의성(Timeliness) | 데이터가 제때 도착하는가 | 매시간 도착해야 할 데이터가 2시간 지연 |
!데이터 품질의 5가지 차원
DataBrew 품질 규칙
AWS Glue DataBrew는 데이터 품질 규칙을 시각적으로 정의하고 자동으로 검사합니다.
규칙 설정 예시: 컬럼 의 값은 0~150 사이여야 한다 컬럼 에 NULL이 없어야 한다 컬럼 는 고유해야 한다 컬럼 는 "pending", "completed", "cancelled" 중 하나여야 한다
DataBrew는 이 규칙들을 데이터셋 전체에 자동으로 적용하고, 규칙을 위반한 레코드의 비율과 샘플을 보고합니다. 규칙 위반율이 임계값을 초과하면 작업을 실패로 처리하거나 경고를 발생시킵니다.
샘플링 기법
수억 건의 레코드를 모두 검사하는 것은 시간과 비용이 너무 많이 듭니다. 샘플링은 일부만 검사해 전체 품질을 추정하는 방법입니다.
무작위 샘플링(Random Sampling): 전체 데이터에서 임의로 일부를 선택합니다. 구현이 간단하고 편향 없는 결과를 얻을 수 있습니다. 데이터 분포가 균일한 경우에 적합합니다.
층화 샘플링(Stratified Sampling): 데이터를 그룹(층)으로 나누고 각 그룹에서 일정 비율로 샘플링합니다. 예를 들어 지역별 주문 데이터에서 각 지역을 대표하도록 샘플링합니다. 그룹 간 비율이 크게 다를 때 무작위 샘플링보다 정확한 결과를 얻습니다.
계통 샘플링(Systematic Sampling): 고정된 간격으로 샘플을 선택합니다. 예를 들어 100만 건 중 매 100번째 레코드를 선택합니다. 데이터가 시계열 순서로 정렬된 경우 주기적 패턴을 탐지하기 좋습니다.
데이터 스큐
데이터 스큐(Data Skew)는 분산 처리 시스템에서 데이터가 특정 노드나 파티션에 불균등하게 몰리는 현상입니다. 대부분의 노드가 빠르게 끝나도 데이터가 몰린 노드 하나 때문에 전체 작업이 늦어집니다.
예시: Spark에서 고객 ID를 기준으로 주문 데이터를 집계할 때, 특정 대형 고객의 주문이 수백만 건이고 나머지 고객은 수십 건이라면 해당 파티션이 과부하가 걸립니다.
스큐 해결 방법: 솔트(Salt) 추가: 스큐된 키에 랜덤 접미사를 붙여 여러 파티션에 분산 파티션 재조정: 또는 로 파티션 수 조정 브로드캐스트 조인: 작은 테이블을 모든 노드에 복제해 조인 비용 절감
시험 핵심 정리
"AWS 서비스 메트릭 수집, 알람 설정" → CloudWatch "로그에서 특정 오류 쿼리" → CloudWatch Logs Insights "Kinesis 소비 지연 감지" → IteratorAge 메트릭 "Glue 처리 속도 느림" → DPU 조정 "EMR 메모리 부족" → 메모리 최적화 인스턴스로 변경 "Kinesis 처리량 부족" → 샤드 추가 "데이터에 NULL 없는지, 범위 검사" → DataBrew 품질 규칙 "전체 데이터를 검사하기 어려울 때" → 샘플링 "분산 처리에서 일부 노드만 과부하" → 데이터 스큐