Day 4 - 비용·성능 운영: 모니터링, 사이징, 자동 스케일링

비용 가시화: 할당 태그와 세 가지 도구

데이터 파이프라인은 잘 돌아가도 비용이 통제되지 않으면 지속할 수 없다. 비용을 줄이려면 먼저 "무엇이 얼마를 쓰는가"를 봐야 한다.

• 비용 할당 태그(Cost Allocation Tags) 는 두 종류다. AWS 가 붙여 주는 AWS 생성 태그(aws:createdBy 등)와 사용자가 다는 사용자 정의 태그(Project, Environment, Team)다.
• 두 종류 모두 Billing 콘솔에서 따로 활성화해야 Cost Explorer 와 비용 보고서에 나타난다. 태그가 콘솔에 보이기까지 최대 24시간이 걸린다.
• 조직(Organizations)에서는 관리 계정만 비용 할당 태그를 활성화할 수 있다. 멤버 계정의 엔지니어가 태그를 달아도 관리 계정이 활성화하지 않으면 비용에 반영되지 않는다.

태그 전략 예:
  Project=orders-pipeline
  Environment=prod
  CostCenter=data-eng
→ Cost Explorer 에서 "data-eng 가 prod 의 orders-pipeline 에 쓴 비용"으로 분해

💡 관련 이론: 비용 할당 태그는 오랫동안 "활성화한 시점 이후의 비용에만 적용되고 소급되지 않는다"고 알려졌고 시험 자료에도 그렇게 나올 수 있다. 현행 문서에는 관리 계정이 최대 12개월까지 백필(backfill) 을 요청하는 기능이 있다. 다만 백필은 활성화 상태를 과거로 넓힐 뿐이어서, 그 기간에 리소스에 태그가 실제로 달려 있지 않았다면 값은 채워지지 않는다. 태그 정책을 초기에 정해 일관되게 다는 것이 여전히 답이다.

• Budgets 는 내가 정한 숫자를 넘을 때만 운다. 평소 월 100 을 쓰던 팀이 300 을 쓰게 돼도 예산이 500 이면 조용하다. 그 구간을 잡는 것이 Anomaly Detection 이다.

서비스별 과금 단위: 무엇을 줄여야 돈이 줄어드나

• 과금 단위가 "시간"인 서비스는 유휴 시간이 낭비이고, "데이터량"인 서비스는 불필요하게 읽은 바이트가 낭비다. 문제의 서비스가 어느 쪽인지 보면 답의 방향이 정해진다.

Glue 사이징

DPU 하나는 vCPU 4개와 메모리 16GB 에 해당하는 상대 단위다.

• 기존 자료에 나오는 Standard 워커 타입은 Glue 1.0 이하의 옛 구성이다. 2.0 이상은 워커 타입과 워커 수로 지정하며, Standard 는 Auto Scaling 도 지원하지 않는다.
• Spark 가 필요 없는 작은 작업은 Python shell 잡(0.0625 DPU 또는 1 DPU)이 훨씬 싸다. 파일 몇 개 옮기고 API 한 번 부르는 일에 Spark 클러스터를 띄우지 않는다.
• Flex 실행 클래스는 급하지 않은 잡(테스트, 일회성 적재, 야간 배치)에 쓴다. 시작이 늦어질 수 있는 대신 싸다. Glue 3.0 이상, G.1X·G.2X 에서만 된다.
• Auto Scaling(--enable-auto-scaling)은 Glue 3.0 이상에서 스테이지·마이크로배치의 병렬도에 따라 워커를 넣고 뺀다. 이때 지정한 워커 수는 "고정 수"가 아니라 상한이 된다.
• 잡은 실행 시간으로 과금되므로 타임아웃이 비용 안전장치다. 멈춰 버린 잡이 기본 타임아웃까지 돌면 그 시간이 전부 청구된다.

# Auto Scaling 을 켜고 최대 20 워커로 실행
aws glue start-job-run \
  --job-name orders-transform \
  --worker-type G.2X --number-of-workers 20 \
  --arguments '{"--enable-auto-scaling":"true"}'

• 사이징 근거는 Day 1 의 두 지표다. numberMaxNeededExecutors(필요한 수)가 numberAllExecutors(실제 수)를 계속 웃돌면 워커가 부족하고, 한참 밑돌면 과하다.

과소 프로비저닝: OOM·스로틀·지연 → SLA 위반
과대 프로비저닝: 유휴 리소스 → 낭비
목표: 워크로드 프로파일에 맞춘 베이스라인 + 변동분은 자동 스케일링

EMR 사이징과 Managed Scaling

• Managed Scaling 은 EMR 이 클러스터 지표를 보고 코어·태스크 노드를 자동으로 늘리고 줄인다. 사용자는 한계만 정한다.

{
  "ComputeLimits": {
    "UnitType": "Instances",
    "MinimumCapacityUnits": 2,
    "MaximumCapacityUnits": 100,
    "MaximumOnDemandCapacityUnits": 10,
    "MaximumCoreCapacityUnits": 17
  }
}

• 위 설정은 "인스턴스 100대까지, 그중 온디맨드는 10대까지, 코어는 17대까지"다. 나머지는 스팟 태스크 노드로 늘어난다.
• Managed Scaling 은 YARN 기반 애플리케이션(Spark, Hadoop, Hive, Flink)에서만 동작한다. Presto·HBase 처럼 YARN 을 쓰지 않는 워크로드는 대상이 아니다.
• Spark 의 동적 리소스 할당을 끄면 Managed Scaling 이 필요 이상으로(최대치까지) 늘릴 수 있다. 기본값인 켜진 상태로 둔다.
• 스팟은 크게 싸지만 회수될 수 있다. 코어 노드를 스팟으로 두면 회수 때 HDFS 데이터가 함께 사라진다. 데이터를 S3 에 두고(EMRFS) 클러스터를 일시적으로 쓰면 이 위험과 유휴 비용이 함께 줄어든다.
• 일이 끝난 클러스터가 켜져 있는 것이 EMR 최대의 낭비다. 자동 종료 정책이나 스텝 완료 후 종료 설정을 쓴다.

Redshift, Kinesis, Lambda 의 변동 흡수

• Concurrency Scaling 클러스터의 기본 개수는 1 이고 max_concurrency_scaling_clusters 로 조절한다. 메인 클러스터 사용에 따라 무료 크레딧이 쌓이므로 짧은 피크는 추가 비용 없이 넘어갈 수 있다.
• Concurrency Scaling 은 대기열을 줄이는 기능이지 느린 쿼리를 빠르게 하는 기능이 아니다. 쿼리 하나가 느리면 분산 키·정렬 키·노드 사양 문제다.
• Lambda 는 메모리 설정이 CPU 할당도 함께 정한다. 메모리를 올려 실행 시간이 줄면 총비용이 오히려 내려가는 구간이 있다. 여러 메모리 값으로 실측해 고른다.

💡 관련 이론: 자동 스케일링은 "변동"을 흡수할 뿐 "잘못된 베이스라인"을 고치지 못한다. 평소 비용이 높다면 스케일링 상한을 만질 것이 아니라 베이스라인 사이징을 다시 잡는다. 순서는 항상 사이징 → 스케일링이다.

구매 옵션

스토리지·쿼리 운영 최적화

• Athena 워크그룹의 쿼리당 한도: 쿼리 하나가 스캔할 수 있는 양의 상한이다. 넘으면 쿼리가 취소되고, 취소되기 전까지 스캔한 만큼은 과금된다. 최솟값은 10MB 이고 워크그룹당 하나만 둔다.
• 워크그룹 전체 사용량 알림: 일정 기간의 누적 스캔량이 임계값을 넘으면 SNS 로 알린다. 이쪽은 쿼리를 자동으로 취소하지 않는다. 막으려면 알림을 받아 Lambda 로 워크그룹을 비활성화하는 식으로 직접 잇는다.
• 컬럼 포맷·압축·파티셔닝: 스캔한 바이트로 과금되므로 Parquet + 압축 + 파티션 프루닝이 곧 비용 절감이다. SELECT * 는 컬럼 포맷의 이점을 버린다.
• 작은 파일 compaction: 파일이 많으면 요청 비용과 목록 조회·메타데이터 부담이 는다.
• S3 수명 주기: 오래된 raw 데이터를 저빈도·아카이브 클래스로 옮기고, 미완료 멀티파트 업로드를 정리한다. 자주 읽는 데이터를 아카이브로 보내면 꺼낼 때 비용과 시간이 든다.

-- 나쁜 예: 전체 컬럼, 파티션 조건 없음 → 테이블 전체 스캔
SELECT * FROM orders WHERE order_status = 'PAID';
 
-- 좋은 예: 필요한 컬럼만, 파티션 컬럼으로 범위 제한
SELECT order_id, amount FROM orders
WHERE dt BETWEEN '2026-06-01' AND '2026-06-07' AND order_status = 'PAID';

증상 → 원인 → 조치

지문 단서 → 정답 판별표

내일은 이번 주의 네 주제(모니터링·품질·트러블슈팅·비용)를 하나의 운영 흐름으로 묶어 복습한다.

📖 용어

• 비용 할당 태그 : 비용을 프로젝트·팀별로 나눠 보기 위해 리소스에 붙이고 Billing 에서 활성화하는 태그.
• 백필(backfill) : 태그의 활성화 상태를 과거 기간까지 넓혀 지난 비용 데이터에 반영하도록 요청하는 것.
• DPU : Glue 의 처리 용량 단위. 하나가 vCPU 4개와 메모리 16GB 에 해당한다.
• Flex 실행 클래스 : 시작이 늦어질 수 있는 대신 싼 Glue 잡 실행 방식.
• Managed Scaling : EMR 이 지표를 보고 노드 수를 알아서 조절하는 기능. 한계만 정해 주면 된다.
• 코어 노드 / 태스크 노드 : 코어는 HDFS 데이터를 갖고, 태스크는 계산만 한다. 그래서 태스크만 스팟으로 돌린다.
• Concurrency Scaling : Redshift 가 동시 쿼리가 몰릴 때 임시 클러스터를 붙여 대기열을 줄이는 기능.
• 스팟 인스턴스 : 남는 EC2 용량을 싸게 쓰되 AWS 가 필요하면 회수해 가는 구매 옵션.
• 워크그룹 : Athena 쿼리를 묶어 설정·한도·비용을 따로 관리하는 단위.
• 베이스라인 사이징 : 평상시 부하에 맞춘 기본 용량. 자동 스케일링보다 먼저 맞춰야 한다.