Day 3 - 로깅·감사·트러블슈팅: CloudTrail과 실패 복구

CloudTrail: 누가·언제·무엇을

파이프라인이 멈췄을 때 "무슨 일이 있었는가"를 재구성하는 능력이 운영의 절반이다. 그 재료 가운데 "사람과 시스템이 AWS 에 무엇을 시켰는가"를 담는 것이 CloudTrail 이다.

• 이벤트 기록(Event history) 은 아무 설정 없이 리전별로 지난 90일의 관리 이벤트를 보여 준다. 수정할 수 없는 기록이지만 90일이 지나면 볼 수 없고, 데이터 이벤트는 여기에 없다.
• 90일보다 길게 남기거나 데이터 이벤트를 남기려면 추적(trail) 을 만들어 S3 버킷으로 내보낸다. 추적은 CloudWatch Logs 와 EventBridge 로도 이벤트를 보낼 수 있다.
• S3 로의 전달은 즉시가 아니다. S3 문서 기준으로 데이터 이벤트는 5분, 관리 이벤트는 15분 간격으로 전달된다. "방금 일어난 일"을 실시간 알람으로 받으려면 EventBridge 규칙을 쓴다.
• 로그 파일 무결성 검증을 켜면 전달된 로그 파일이 변조·삭제됐는지 해시와 서명으로 확인할 수 있다. S3 서버 액세스 로그에는 이 기능이 없다.
• 조직 전체의 로그는 조직 추적으로 중앙 계정의 버킷에 모으고, 그 버킷은 운영 계정과 분리해 변경하지 못하게 둔다.
• CloudTrail Lake 는 이벤트를 이벤트 데이터 스토어에 넣어 SQL 로 조회하게 해 준다. 보존은 요금 옵션에 따라 최대 약 7년 또는 약 10년까지다.

질문: "어제 새벽 curated 테이블을 누가 DROP 했지?"
→ CloudTrail 에서 eventSource=glue.amazonaws.com, eventName=DeleteTable 을
  시간과 userIdentity 로 좁힌다

💡 관련 이론: CloudWatch Logs 는 애플리케이션이 쓴 로그, CloudTrail 은 AWS API 호출 기록이다. Athena 에서 실행된 DROP TABLE 문은 Athena 쿼리 이력에 남고, 그 결과로 호출된 glue:DeleteTable 은 CloudTrail 에 남는다. 한 사건이 두 곳에 다른 모습으로 남는다는 점을 기억하면 추적이 빨라진다.

닮은 로그 네 가지

• CloudTrail 은 자격 증명이 유효하지 않아 인증에 실패한 요청은 남기지 않는다. 권한 부족(AccessDenied)은 남긴다. 인증 실패까지 봐야 하면 서버 액세스 로그다.
• 수명 주기 규칙이 객체를 옮기거나 지운 기록은 서버 액세스 로그에만 남는다. "객체가 사라졌는데 CloudTrail 에 DeleteObject 가 없다"면 수명 주기 만료를 의심한다.

CloudTrail 로그를 Athena 로 조회하기

추적이 S3 에 쌓은 JSON 로그는 Athena 테이블로 만들어 SQL 로 뒤진다.

-- 지난 이틀간 Glue 카탈로그 테이블을 지우거나 바꾼 호출
SELECT eventtime, useridentity.arn AS who, eventname, sourceipaddress, requestparameters
FROM cloudtrail_logs
WHERE eventsource = 'glue.amazonaws.com'
  AND eventname IN ('DeleteTable', 'UpdateTable', 'BatchDeleteTable')
  AND eventtime >= '2026-06-25T00:00:00Z'
ORDER BY eventtime DESC;

• 로그 양이 많으므로 날짜 기준 파티션(또는 파티션 프로젝션)을 걸어 스캔량을 줄인다.
• 역할을 넘겨받아(AssumeRole) 한 호출은 userIdentity 에 역할 세션이 찍힌다. 실제 사람을 찾으려면 그 세션을 만든 AssumeRole 이벤트를 한 번 더 거슬러 올라간다.

파이프라인 디버깅 워크플로우

장애가 났을 때 코드부터 열지 말고 위에서 아래로 좁힌다.

1. 오케스트레이터부터: Step Functions 실행 그래프나 Airflow(MWAA) DAG 에서 어느 태스크가 실패했는지 본다.
2. 실패 태스크의 로그: 해당 Glue·EMR·Lambda 의 CloudWatch Logs 에서 예외 스택을 본다.
3. 입력 데이터 점검: 스키마 변경, 빈 파티션, 깨진 파일.
4. 권한·리소스 점검: IAM·Lake Formation 거부, KMS 키 권한, 스로틀링, 메모리 부족.
5. CloudTrail 로 변경 추적: 최근 누군가 테이블·정책·설정을 바꿨는지.

Step Functions 실행 → TransformJob 실패
  → CloudWatch Logs(Glue): "AnalysisException: cannot resolve 'email'"
  → 원인: 업스트림에서 email 컬럼명이 user_email 로 바뀜
  → 조치: 매핑 수정 + 스키마 검증 게이트 추가

• "어제까지 되던 잡이 코드 변경 없이 실패"하면 3번과 5번이다. 데이터가 바뀌었거나 누군가 설정을 바꿨다.

흔한 실패 유형: 증상 → 원인 → 조치

• Glue 잡의 자동 재시도 횟수는 0~10 으로 정한다. 타임아웃으로 끝난 잡은 재시작되지 않는다. 타임아웃을 재시도로 해결하려는 설계는 동작하지 않는다.
• Glue 5.0 으로 올린 뒤 장시간 잡이 8시간에서 끊긴다면 기본 타임아웃이 바뀐 것이다. 시험 자료에는 옛 기본값(48시간)으로 나올 수 있다.

재시도와 실패 복구: Step Functions 의 Retry 와 Catch

분산 시스템에서 일시적 오류는 정상이다. 핵심은 재시도할 오류와 영구 오류를 구분하는 것이다.

"Retry": [{
  "ErrorEquals": ["ThrottlingException", "Glue.ConcurrentRunsExceededException"],
  "IntervalSeconds": 5,
  "BackoffRate": 2.0,
  "MaxAttempts": 4,
  "MaxDelaySeconds": 60,
  "JitterStrategy": "FULL"
}],
"Catch": [{
  "ErrorEquals": ["States.ALL"],
  "ResultPath": "$.error",
  "Next": "QuarantineAndNotify"
}]

• 지터는 기본으로 꺼져 있다. 여러 실행이 같은 순간에 실패하면 같은 순간에 다시 몰려든다(thundering herd). FULL 을 직접 지정한다.
• States.ALL 은 모든 오류 이름과 맞지만, 배열에 단독으로, 그리고 마지막 항목에 와야 한다. States.TaskFailed 는 States.Timeout 을 뺀 모든 오류와 맞는다.
• States.Runtime(예: null 페이로드에 경로를 적용)은 재시도도 캐치도 되지 않고 실행을 실패시킨다. States.DataLimitExceeded 는 States.ALL 로는 안 잡히고 이름을 직접 적어야 잡힌다.
• 상태에 Retry 와 Catch 가 모두 있으면 Retry 가 먼저다. 재시도를 다 쓰고도 실패하면 Catch 로 넘어간다. 둘 다 없으면 상태 하나의 오류로 실행 전체가 실패한다.
• 재시도도 상태 전이로 계산된다. 표준 워크플로는 상태 전이 수로 과금되므로 무제한에 가까운 재시도는 비용이 된다.
• 실패한 실행을 고친 뒤에는 처음부터 다시 돌리지 않고 실패 지점부터 이어 가는 redrive 를 쓸 수 있다.

💡 관련 이론: 재시도는 멱등 작업에서만 안전하다. "잔액을 100 증가"처럼 비멱등한 작업을 무턱대고 재시도하면 두 번 적용된다. 멱등 키나 조건부 쓰기로 보호한다. 적재 잡이라면 append 대신 파티션 덮어쓰기·MERGE 가 같은 역할을 한다.

서비스마다 다른 재시도 기본 동작

• 기본값이 "무한에 가까운 재시도"인 쪽(스트림 매핑)과 "재시도 없음"인 쪽(Step Functions)이 섞여 있다. 문제에서 어느 서비스가 호출하는지부터 확인한다.

DLQ(데드레터 큐) 처리

처리에 계속 실패하는 메시지를 원래 큐에 두면 컨슈머가 같은 메시지를 받고 실패하기를 반복한다. DLQ 는 일정 횟수 넘게 실패한 메시지를 따로 빼 두는 큐다.

정상 큐 → 컨슈머 처리 실패 N회(maxReceiveCount) → DLQ
DLQ → 원인 분석 → 수정 → 원본 큐로 재투입(redrive)

• 표준 큐에서는 DLQ 의 보존 기간을 원본 큐보다 길게 잡는다. 원본 큐에서 하루를 보낸 메시지는 보존 4일짜리 DLQ 에서 3일 뒤에 사라진다. 분석하기도 전에 증거가 없어지는 원인이다.
• maxReceiveCount 를 1 처럼 낮게 잡으면 일시적 오류 한 번에 메시지가 DLQ 로 간다. 충분한 재시도 횟수를 준다.
• FIFO 큐에 DLQ 를 붙이면 실패 메시지가 빠져나가면서 순서가 바뀐다. 순서가 깨지면 안 되는 작업에는 DLQ 를 쓰지 않는다.
• DLQ 에 메시지가 한 건이라도 쌓이면 알람이 울리게 한다. 알람 없는 DLQ 는 조용한 데이터 유실 창고다.
• Lambda 비동기 호출에서 DLQ 는 폐기된 이벤트 자체를 받고, 실패 대상(on-failure destination) 은 실패한 호출의 기록을 받는다. 새 설계에서는 정보가 더 많은 대상 쪽을 쓴다.

지문 단서 → 정답 판별표

내일은 잘 도는 파이프라인이 돈을 얼마나 쓰는지, 비용 가시화와 사이징·자동 스케일링을 다룬다.

📖 용어

• 관리 이벤트 : 리소스를 만들고 바꾸고 지우는 API 호출 기록. CloudTrail 이 기본으로 남긴다.
• 데이터 이벤트 : 객체를 읽고 쓰는 것처럼 리소스 안의 데이터를 다루는 호출 기록. 직접 켜야 남는다.
• 추적(trail) : CloudTrail 이벤트를 S3 버킷 등으로 계속 내보내는 설정.
• 이벤트 기록 : 설정 없이 볼 수 있는 최근 90일의 관리 이벤트 목록.
• 지수 백오프 : 재시도할 때마다 기다리는 시간을 배수로 늘리는 방식.
• 지터(jitter) : 재시도 간격에 섞는 무작위 값. 여러 클라이언트가 동시에 몰려드는 것을 막는다.
• Catch : 재시도로도 해결되지 않은 오류를 받아 다른 상태로 보내는 Step Functions 설정.
• 가시성 타임아웃 : 컨슈머가 받은 SQS 메시지가 다른 컨슈머에게 안 보이는 시간.
• DLQ : 여러 번 처리에 실패한 메시지를 따로 모아 두는 큐.
• redrive : 원인을 고친 뒤 DLQ 의 메시지나 실패한 실행을 다시 처리 경로로 돌려보내는 것.