Amazon Athena

로그나 이벤트 파일은 S3에 쌓였는데 확인할 때마다 별도 분석 클러스터를 준비하면 간단한 질문 하나도 무거워집니다. 파일 위에서 바로 조회하지 못하면 분석의 첫걸음 자체가 늦어집니다.

예전에는 로그나 데이터 레이크를 확인하려면 ETL 파이프라인을 먼저 구성하거나 EMR 같은 전용 분석 클러스터를 띄워야 했습니다. 클러스터 하나를 시작하는 데 30분에서 1시간 정도 걸리고, 간단한 조회를 위해서도 인프라를 준비하는 비용과 시간이 분석 자체보다 커졌습니다. 저장된 파일을 추가 준비 없이 바로 쿼리하는 서버리스 방식이 등장한 배경입니다.

Athena에 SQL을 제출하면, 먼저 Glue Data Catalog에서 테이블 스키마와 파티션 정보를 조회합니다. 파티션이 설정돼 있으면 조건에 맞는 파티션의 S3 경로만 골라 병렬로 스캔하고, 없으면 전체 경로를 훑습니다. 스캔이 끝나면 결과를 다시 S3에 저장합니다. 파티셔닝이 비용과 속도에 직접 영향을 줍니다. Athena는 스캔한 데이터양만큼 과금하기 때문에, 날짜나 리전 같은 파티션 키로 범위를 좁히면 읽는 양이 줄어 비용이 내려가고 쿼리도 빨라집니다. ETL(Extract-Transform-Load, 원천 데이터를 꺼내서 변환하고 다른 저장소에 적재하는 과정) 파이프라인을 먼저 만들지 않아도 바로 질의를 시작할 수 있으며, BI(Business Intelligence, 데이터를 시각화하고 리포트로 만드는 도구) 도구로 결과를 이어받을 수도 있습니다.

Athena와 Redshift는 둘 다 SQL 분석이 가능하지만 사용 방식이 다릅니다. Athena는 서버리스로 파일을 바로 읽는 질의 엔진이고, Redshift는 데이터를 적재해 두고 반복 분석하는 웨어하우스입니다. S3 파일을 적재 없이 바로 조회하는 게 핵심이면 Athena를 보고, 데이터를 정리해 반복 리포트와 집계를 돌리는 게 핵심이면 Redshift를 보면 됩니다.

보안팀이 CloudTrail 로그에서 특정 IAM 사용자의 권한 변경 이벤트를 SQL로 추적하거나, 데이터 엔지니어가 새로 적재된 S3 파일의 스키마와 값 분포를 빠르게 확인하는 데 적합합니다. 배치 보고서의 초기 검증이나 비용 보고서 분석처럼, 저장된 파일에 바로 질문을 던져야 하는 탐색성 작업에 강합니다. 반복적이고 무거운 집계를 빠르게 처리해야 하는 경우에는 맞지 않습니다.