[AWS] Glue : 서버리스 ETL 서비스

[AWS] Glue : 서버리스 ETL 서비스

 

현재 저는 고객사에서 Airflow를 다루고 있습니다. 제가 입사하기 이전에는 AWS의 Glue를 사용했다고합니다.

Airflow로 이관한 이유는 역시 비용때문이였는데요 .. 😅

 

Glue 또한 ETL을 동작하는 서비스이기때문에 Glue에서는 어떤방식으로 동작하는지 궁금하기도 했고,

EMR을 공부하다보니 자연스럽게 Glue랑 비교되는 포스트들도 많이 보이더라구요

 

이번 포스팅에서는 Glue에 대해 정리해보았습니다.

 

Glue

Glue는 AWS에서 제공하는 서버리스 ETL(Extract-Transform-Load) 서비스 입니다.

즉, 사용자가 직접 인프라를 구성할 필요 없이, Cloud에서 자동으로 리소스를 할당해 데이털르 변환하고 로딩해주는 구조입니다.

 

주요 기능은 다음과 같습니다.

•  데이터 카탈로그(Data Catalog) : S3, RDS, Redshift 등의 데이터 구조를 자동으로 분석해 테이블 스키마 정의를 저장합니다.
• 크롤러(Crawler) : 데이터 저장소를 스캔해 스키마를 자동 인식하고 Data Catalog를 갱신합니다.
• ETL Job : PySpark나 Scala 기반 스크립트를 실행해 데이터를 추출, 변환, 로딩합니다.
• Visual ETL Canvas : Glue Studio에서 GUI 방식으로 작업 흐름을 구성하고, 자동으로 코드를 생성할 수 있습니다.
• Trigger & Scheduler : 일회성 또는 스케줄 기반, 이벤트 기반 실행 워크플로우 설정이 가능합니다.

 

Glue의 실행 흐름

Glue는 서버리스이기 때문에, 사용자가 클러스터를 구성하거나 인프라를 따로 신경 쓸 필요는 없습니다.

대신, 실행 시점에 다음과 같은 동작을 합니다.

• 1. Job 실행 요청 
• 2. Glue가 자동으로 적절한 컴퓨팅 환경 구성
• 3. 스크립트 실행 
• 4. S3/RDS 등 데이터 소스에서 읽고 변환
• 5. Catalog 갱신 또는 목적지 저장소로 적재
• 6. Cloud Watch에 로그 기록

 

Glue는 어떤 상황에 적합할까요?

Glue는 특히 다음과 같은 경우에 유용합니다.

• 다양한 포맷(CSV, JSON, Parquet 등)의 데이터를 주기적으로 처리해야 할 때
• 데이터 구조가 자주 바뀌는 환경에서 자동으로 스키마를 추론하고 관리하고 싶을 때
• 복잡한 클러스터 운영 없이 간단한 전처리, 가공 작접을 자동화하고 싶을 때
• ETL 스크립트를 코드 또는 시각적 도구로 손쉽게 구성하고 싶을 때

즉, ETL 자동화와 관리 편의성이 중요한 프로젝트에서 클러스터 운영이 중심인 EMR보다 Glue가 더 매끄럽게 작동합니다. 

 

vs EMR

개인적으로 EMR과 비교해서 Glue의 장점이 가장 크게 느껴졌던 부분은

정형, 반정형 데이터를 대상으로 단순한 ETL 흐름을 반복적으로 구성할 때 입니다.

 

예를 들어, 

• 매일 새벽에 S3로 들어오는 CSV 데이터를 자동으로 스캔하고
• 날짜별 폴더로 나눠서 Parquet 포맷으로 변환하고
• 이를 다시 Athena/Redshift에서 조회 가능하게 만들어야 한다면?

이런 작업을 직접 스크립트로 작성하려면 꽤 번거롭지만, Glue에서는 크롤러 + Job + 트리거만 설정해두면 반복 실행이 가능합니다. 무엇보다도 서버가 없기 때문에 유지보수나 비용 적인 부담도 줄어듭니다.

 

🧩 마무리하며

Glue는 처음에는 약간 추상적이고 복잡하게 느껴질 수 있지만, 데이터 파이프라인을 반복적으로 운영하는 상황에서는 굉장히 매끄러운 도구라는 인상을 받았습니다.

 

특히 크롤러와 카탈로그, 서버리스 Spark 환경을 조합해서 복잡한 작업을 몇 줄의 코드 혹은 GUI 조직만으로 자동화할 수 있다는 점은 정말 매력적이였습니다.

EMR이 인프라를 유연하게 커스터마이징하며 사용하는 쪽이라면, Glue는 빠르게 구성하고 자동으로 돌리는 쪽에 훨씬 어울리는 서비스라는 느낌이었습니다.

 

얼마전, 고객사들이 최근에 Glue와 EMR을 걷어내고 데이터브릭스로 이관하거나 EC2에다 직접 플랫폼을 설치한다고 합니다.

전자의 경우는 지금의 Databicks가 너무 매끄럽죠. 후자의 경우는 비용 문제였습니다. (실제로 10분의 1에서 20분의 1 가량이 줄어들었다고 합니다..)

 

지금은 각 도구의 장단점을 경험해보며 팀이나 조직에 맞는 방향을 탐색해가는 시기인 것 같습니다.

누가 더 좋다가 아니라, "우리 한테 맞는 건 뭘까?"를 고민하게 되는 계기가 되었습니다.