Day 2 - Amazon Athena: 서버리스 쿼리와 비용 최적화

Athena 동작 모델

Amazon Athena 는 프로비저닝할 인프라가 없다. 쿼리를 던지면 Athena 가 Trino 기반 엔진(엔진 버전 3)을 대신 돌린다.

-- S3 경로를 가리키는 외부 테이블 정의
CREATE EXTERNAL TABLE orders (
  order_id BIGINT,
  amount   DOUBLE,
  status   STRING
)
PARTITIONED BY (dt STRING)
STORED AS PARQUET
LOCATION 's3://datalake-clean/orders/';

• 테이블은 Glue Data Catalog 의 메타데이터일 뿐이다. 데이터를 적재하지 않는다(schema-on-read). DROP TABLE 을 해도 S3 의 파일은 그대로 있다.
• 쿼리 결과는 지정한 S3 결과 위치에 파일로 저장된다. 결과 버킷에도 저장 요금이 쌓이므로 수명주기 만료 규칙을 건다.
• 쿼리는 계정의 동시 실행 쿼터 안에서 돌고, 넘치면 대기한다. DML 쿼리에는 실행 시간 제한이 있다.

과금 구조

• 실행 시간이 아니라 읽은 양이 요금이다. 10분 걸린 쿼리가 1초 걸린 쿼리보다 쌀 수 있다.
• 스캔량과 무관하게 예측 가능한 비용과 동시성 제어가 필요하면 프로비저닝된 용량을 워크그룹에 붙인다.

💡 관련 이론: Athena 에서는 비용 최적화와 성능 최적화가 같은 방향이다. 둘 다 "S3 에서 덜 읽기"로 귀결되기 때문이다. Redshift 처럼 컴퓨팅을 예약해 둔 서비스에서는 쿼리를 아무리 아껴도 요금이 그대로지만, Athena 는 쿼리를 고친 만큼 청구서가 줄어든다.

스캔량을 줄이는 세 층

같은 질문을 던져도 데이터의 형태에 따라 읽는 양이 크게 달라진다. 하루치 주문에서 두 컬럼의 합계를 구하는 쿼리를 예로 들면 이렇다.

① 파티션

-- 파티션 메타데이터 로드 (Hive 스타일 경로일 때)
MSCK REPAIR TABLE orders;
 
-- 또는 개별 파티션 추가
ALTER TABLE orders ADD PARTITION (dt='2026-06-26')
LOCATION 's3://datalake-clean/orders/dt=2026-06-26/';
 
-- 프루닝이 작동: dt 프리픽스만 스캔
SELECT status, COUNT(*) FROM orders
WHERE dt = '2026-06-26' GROUP BY status;

• MSCK REPAIR TABLE 은 S3 를 훑어 파티션을 추가만 한다. 지워진 파티션을 빼 주지 않고, 파티션이 많으면 오래 걸리다 타임아웃되어 일부만 등록된 상태로 끝날 수 있다. 매일 파티션 하나를 추가하는 용도로는 ALTER TABLE ADD PARTITION 이 맞다.
• 파티션이 수만 개면 카탈로그 조회가 병목이다. 파티션 프로젝션으로 등록 없이 규칙으로 계산한다.

ALTER TABLE orders SET TBLPROPERTIES (
  'projection.enabled' = 'true',
  'projection.dt.type' = 'date',
  'projection.dt.range' = '2024-01-01,NOW',
  'projection.dt.format' = 'yyyy-MM-dd',
  'storage.location.template' = 's3://datalake-clean/orders/dt=${dt}/'
);

• Athena 는 Glue 테이블의 파티션을 1,000만 개까지 다루지만 한 번의 스캔에서 읽을 수 있는 파티션은 100만 개까지다. 파티션 조건이 없는 쿼리가 초대형 테이블에서 실패하는 이유다.

② 포맷과 압축

• Parquet/ORC: 필요한 컬럼만 읽고, 파일 안 통계로 구간을 건너뛴다. 파일이 너무 작으면 포맷 오버헤드가 이점을 덮으므로 128MB 이상으로 맞춘다.
• 압축: 스캔량은 압축된 크기로 잡히므로 압축이 곧 할인이다. gzip 은 압축률이 좋고 호환성이 넓으며, zstd 는 속도와 압축률의 균형이 좋다.
• 텍스트(CSV·JSON)를 압축하면 대부분의 코덱에서 파일을 처음부터 읽어야 해 파일 하나를 병렬로 나눠 읽지 못한다. 이때는 파일 수가 병렬도의 상한이다. Parquet/ORC 는 내부 단위로 나뉘어 있어 압축해도 병렬로 읽힌다.

③ 쿼리 작성

-- 필요한 컬럼만 SELECT → 컬럼형 포맷에서 스캔량 절감
SELECT order_id, amount FROM orders WHERE dt = '2026-06-26';
-- SELECT * 는 모든 컬럼을 스캔하므로 피한다

• LIMIT 은 스캔량을 보장해 주지 않는다. 정렬이나 집계가 끼면 전체를 읽은 뒤에 자른다.
• 파티션 키에는 등호 조건이 가장 잘 듣는다. 모든 파티션 키에 등호가 걸리면 메타데이터를 직접 집어 온다.
• 실행 전 EXPLAIN 으로 어떤 파티션이 대상인지, 실행 후 EXPLAIN ANALYZE 나 쿼리 통계의 "스캔한 데이터"로 실제 읽은 양을 확인한다.

💡 관련 이론: CSV 를 Parquet + 압축으로 바꾸면 "컬럼 프로젝션(필요한 컬럼만)", "압축(같은 타입 값이 모여 잘 줄어듦)", "통계 기반 건너뛰기"가 한꺼번에 적용된다. 그래서 포맷 변환은 Athena 비용 문제에서 가장 먼저 꺼내는 카드다. 파티션은 그다음, 쿼리 수정은 그 위에 얹는다.

CTAS 와 INSERT INTO

CTAS(CREATE TABLE AS SELECT) 는 쿼리 결과를 새 S3 위치에 쓰고 테이블로 등록한다.

-- CSV 원본을 파티셔닝된 Parquet 로 변환
CREATE TABLE orders_parquet
WITH (
  format = 'PARQUET',
  write_compression = 'SNAPPY',
  partitioned_by = ARRAY['dt'],
  external_location = 's3://datalake-clean/orders_parquet/'
) AS
SELECT order_id, amount, status, dt   -- 파티션 컬럼은 SELECT 목록의 맨 끝
FROM orders_raw_csv
WHERE dt BETWEEN '2026-06-01' AND '2026-06-30';

• 파티션이 100개를 넘는 변환은 CTAS 로 첫 구간을 만들고 INSERT INTO ... SELECT 로 나머지를 구간별로 이어 붙인다.
• CTAS·INSERT INTO 가 실패하거나 취소되면 대상 위치에 쓰다 만 파일이 남을 수 있다. 다음 쿼리가 그 파일까지 읽으므로 정리해야 한다. 원자적 쓰기가 필요하면 Iceberg 테이블을 쓴다.
• CTAS 는 "변환 로직이 SQL 로 충분하고 일회성·주기적 배치"일 때 Glue 잡을 대신한다. 복잡한 변환, 대용량의 지속적 파이프라인, 세밀한 재시도가 필요하면 Glue·EMR 이다.

페더레이션 쿼리 (Federated Query)

데이터 소스 커넥터를 통해 S3 밖의 소스(RDS·Aurora, DynamoDB, Redshift, CloudWatch Logs, OpenSearch, 그 밖의 JDBC 소스 등)를 같은 SQL 로 조회·조인한다.

-- S3 의 주문 데이터와 RDS 의 고객 마스터를 조인
SELECT o.order_id, c.customer_name, o.amount
FROM awsdatacatalog.sales.orders o
JOIN rds_postgres.public.customers c
  ON o.customer_id = c.customer_id
WHERE o.dt = '2026-06-26';

• Athena 가 커넥터를 호출해 읽을 범위를 정하고, 병렬성을 관리하고, 필터 조건을 소스로 내려보낸다(조건 푸시다운).
• 커넥터는 전통적으로 사용자 계정의 Lambda 함수로 배포된다. 그래서 Lambda 호출 요금이 따로 들고 Lambda 의 한도 안에서 돈다. 최근에는 일부 소스에 대해 Lambda 없이 Glue 연결로 동작하는 커넥터도 제공되지만, 시험 자료는 Lambda 기반으로 설명한다.
• 읽기 전용이다. 페더레이션 소스에 INSERT INTO 는 지원되지 않는다. 다만 페더레이션으로 읽어 S3 에 CTAS 로 쓰는 것은 된다(소스 → 레이크 추출 파이프라인).
• 조인 대상 소스에 실제 쿼리가 나가므로 운영 DB 에 부하가 간다. 대량 조인을 반복하면 Read Replica를 가리키게 하거나 데이터를 레이크로 옮기는 편이 낫다.

워크그룹과 비용 통제

워크그룹은 쿼리 실행을 팀·용도별로 나누는 단위다. 결과 위치, 암호화, 엔진 버전, 비용 통제가 워크그룹에 붙는다.

• 쿼리당 한도는 워크그룹에 하나만 걸 수 있고, 워크그룹 전체 알림은 여러 임계값으로 걸 수 있다.
• 워크그룹 전체 한도에서 실제로 차단까지 하려면 SNS 알림에 Lambda 를 물려 워크그룹을 비활성화하는 식으로 직접 구성한다.
• 워크그룹 설정으로 클라이언트 설정을 덮어쓰게 하면 사용자가 결과 위치나 암호화를 바꾸지 못한다. 결과 암호화를 강제하는 방법이다.
• 워크그룹 단위로 IAM 권한을 나누고, CloudWatch 지표와 비용 할당 태그로 팀별 사용량을 본다.

# 쿼리당 스캔 한도를 10GB 로 설정한 워크그룹 생성
aws athena create-work-group \
  --name analysts \
  --configuration '{
    "ResultConfiguration": {"OutputLocation": "s3://acme-athena-results/analysts/"},
    "EnforceWorkGroupConfiguration": true,
    "PublishCloudWatchMetricsEnabled": true,
    "BytesScannedCutoffPerQuery": 10737418240
  }'

쿼리 결과 재사용

같은 쿼리가 반복되면 이전 결과를 다시 쓰게 할 수 있다. 재사용되면 스캔이 일어나지 않는다.

• 같은 워크그룹 안에서, 쿼리 문자열이 일치하고, 이전 결과가 만료되지 않았을 때 적용된다.
• 최대 수명을 지정하지 않으면 60분, 지정할 수 있는 최대는 7일이다.
• 원천 데이터가 바뀌었는지는 확인하지 않는다. 수명 안에서는 오래된 결과가 나올 수 있다.
• Lake Formation 에 등록된 위치의 테이블, 행·컬럼 권한이 걸린 테이블에는 적용되지 않는다.

증상 → 원인 → 조치

Athena 를 고를 때와 고르지 않을 때

지문 단서 → 정답 판별표

내일은 분석 엔진이 아닌 운영 스토어 DynamoDB 를, 데이터 엔지니어가 알아야 할 키 설계와 변경 캡처 관점에서 다룬다.

📖 용어

• 서버리스 : 서버를 미리 띄우거나 관리하지 않고 요청한 만큼만 자원이 쓰이는 방식.
• 스캔량 : 쿼리가 S3 에서 실제로 읽은 바이트 수. Athena 의 과금 기준이다.
• 외부 테이블 : 데이터는 S3 에 두고 위치와 스키마만 카탈로그에 등록한 테이블.
• 컬럼 프로젝션 : 쿼리에 필요한 컬럼만 읽는 것. 컬럼형 포맷에서만 효과가 있다.
• CTAS : CREATE TABLE AS SELECT. 쿼리 결과를 새 위치에 쓰고 테이블로 등록한다.
• 페더레이션 쿼리 : 데이터 소스 커넥터를 통해 S3 밖의 소스를 Athena SQL 로 조회하는 기능.
• 조건 푸시다운 : WHERE 조건을 소스 쪽으로 내려보내 소스가 미리 걸러서 돌려주게 하는 최적화.
• 워크그룹 : 쿼리 실행을 나누는 단위. 결과 위치·암호화·스캔 한도·지표가 여기에 붙는다.
• 쿼리 결과 재사용 : 같은 쿼리의 이전 결과를 일정 시간 동안 다시 돌려주는 기능.
• 프로비저닝된 용량 : 스캔량 대신 예약한 처리 용량(DPU)의 사용 시간으로 과금하는 Athena 요금제.