Day 5 - Week 8 종합: 데이터 운영 및 지원 복습

네 질문으로 보는 운영 지도

이번 주는 파이프라인이 "구축"된 뒤 "운영"되는 단계를 다뤘다. 나흘의 주제는 따로 떨어진 것이 아니라, 운영자가 장애 한 건을 겪으며 차례로 던지는 네 질문이다.

                     운영 중인 파이프라인
                            │
   ┌──────────────┬─────────┴────────┬───────────────┐
 지금 정상인가?   데이터가 맞는가?   왜·누가 깨뜨렸나?   얼마를 쓰는가?
   (Day 1)          (Day 2)            (Day 3)           (Day 4)
   │                │                  │                 │
 CloudWatch       Glue Data          CloudWatch Logs   비용 할당 태그
 지표·알람         Quality            CloudTrail        Cost Explorer
 EMF·복합 알람     DQDL·이상 탐지      Retry/Catch·DLQ   Budgets·이상 탐지

• 왼쪽 두 질문은 탐지, 셋째는 진단과 복구, 넷째는 지속 가능성이다. 문제를 읽을 때 지문이 넷 중 무엇을 묻는지 먼저 정하면 보기를 좁힐 수 있다.
• 흔한 오답 구조는 "질문과 다른 칸의 도구"다. "누가 삭제했나"에 CloudWatch Logs, "비용 급증 탐지"에 CloudTrail 을 고르게 만든다.

신호 → 도구 매핑

• "잡이 성공했다"와 "데이터가 맞다"는 다른 사실이다. 잡은 빈 파일을 읽고도 성공한다. 모니터링(Day 1)이 품질 검증(Day 2)을 대신하지 못하는 이유다.

닮은 것끼리 구분하기

기록·로그

"평소와 다름"을 잡는 세 기능

• 셋 모두 "임계값을 사람이 정하기 어렵다"는 같은 문제를 푼다. 보기에 셋이 함께 나오면 무엇의 이상인지로 고른다.

실패를 다루는 네 장치

• 앞의 셋은 실행이 실패했을 때, 넷째는 실행은 성공했는데 결과가 틀렸을 때의 장치다.

용량을 자동으로 맞추는 기능

Week 8 숫자·기본값 한 장

• 최근 바뀐 값이 둘 있다. Glue 잡 기본 타임아웃(48시간 → 5.0 부터 8시간)과 비용 할당 태그의 소급 여부(불가 → 백필 가능)다. 시험 자료에는 옛 값으로 나올 수 있다.

통합 시나리오: 야간 주문 ETL 운영

00:00 EventBridge 스케줄 → Step Functions 파이프라인 시작
  1) Glue 수집 잡 (실시간 로그 + Auto Scaling + 잡 지표)
  2) Glue Data Quality 평가 (DQDL + 이상 탐지)
       └─ 치명 규칙 실패 또는 점수 < 0.95 → 격리 버킷 + SNS + 중단
  3) EMR 변환 (코어 온디맨드, 태스크 스팟, Managed Scaling)
  4) curated 적재 + Athena 검증 쿼리
 
비용 운영:
  - 모든 리소스에 Project/Environment 태그, 관리 계정에서 활성화
  - Budgets 80% 알림, Cost Anomaly Detection 으로 급증 감지
  - 월간 Cost Explorer 리뷰로 사이징 재조정

장애 한 건을 네 질문으로 따라가기

같은 파이프라인에서 새벽에 일이 났다고 가정한다. 나흘의 내용이 시간 순서로 이어진다.

• 02:10 에 알람이 울린 것은 처리 건수 지표에 누락 처리를 걸어 두었기 때문이다. 기본값이었다면 아침에 사람이 발견했다.
• 02:15 에 curated 가 오염되지 않은 것은 게이트가 적재 앞에 있었기 때문이다. 게이트가 없었다면 02:30 이후의 일은 "오염 범위 조사"가 됐을 것이다.
• 03:00 의 재처리가 중복을 만들지 않은 것은 적재가 파티션 덮어쓰기였기 때문이다.

자주 틀리는 함정

• 알람이 조용한 것은 정상의 증거가 아니다. 지표가 끊기면 기본 설정의 알람은 울리지 않는다.
• 품질 점수는 행 비율이 아니다. 통과한 규칙의 비율이므로 치명 규칙은 점수와 따로 판정한다.
• 이상 탐지는 첫날부터 동작하지 않는다. 통계가 쌓여야 하고, 한 번 잡힌 이상값은 제외하지 않으면 정상으로 학습된다.
• CloudTrail 이 켜져 있어도 객체 접근은 안 남는다. 데이터 이벤트는 별도 설정이다.
• Step Functions 의 지터는 기본으로 꺼져 있다. 백오프만으로는 동시 재시도가 흩어지지 않는다.
• 표준 큐의 DLQ 는 보존 기간이 새로 시작되지 않는다. DLQ 보존을 원본 큐보다 길게 둔다.
• 태그는 달아도 활성화하지 않으면 비용에 안 보인다. 조직에서는 관리 계정의 일이다.
• Athena 워크그룹 알림은 쿼리를 멈추지 않는다. 멈추는 것은 쿼리당 한도뿐이다.
• 스케일링 상한을 올려도 평소 비용은 줄지 않는다. 베이스라인을 다시 잡는다.

지문 단서 → 정답 판별표

다음 주는 데이터 보안과 거버넌스다. IAM 과 Lake Formation 의 접근 제어에서 시작한다.

📖 용어

• 관측성(observability) : 지표·로그·추적으로 시스템 안에서 무슨 일이 벌어지는지 밖에서 알아낼 수 있는 정도.
• 증상 기반 알람 : CPU 같은 자원 수치가 아니라 지연·실패율처럼 사용자가 겪는 현상에 거는 알람.
• 검증 게이트 : 품질이 기준에 못 미친 데이터를 다음 단계로 넘기지 않는 지점.
• 격리 버킷 : 게이트를 통과하지 못한 데이터를 실패 사유와 함께 모아 두는 곳.
• 멱등 재처리 : 같은 구간을 몇 번 다시 돌려도 결과가 한 번 돌린 것과 같은 재처리.
• redrive : 실패한 메시지나 실행을 원인 수정 후 다시 처리 경로에 올리는 것.
• 베이스라인 : 평상시 부하에 맞춘 기본 용량. 스케일링이 흡수하는 변동분과 구분한다.
• 런북(runbook) : 특정 장애가 났을 때 무엇을 어떤 순서로 확인하고 조치할지 적어 둔 절차서.