ML 데이터를 위해 자동 크기 조절이 가능한 EC2를 구축한 방법

페인 포인트 (The Pain Point)

저는 ML(머신러닝) 학습 여정 중에 있습니다. 이는 많은 데이터, 많은 처리 과정, 그리고 정말 낭비해서는 안 될 많은 AWS 프리 티어 크레딧을 의미합니다.

저의 전형적인 하루는 다음과 같았습니다:

데이터 파이프라인을 실행하기 위해 t3.large 인스턴스를 생성합니다. 데이터셋을 로드하고, 처리하고, 저장합니다. 파이프라인은 몇 시간 동안 실행되는데, 때로는 정확히 얼마나 걸릴지조차 모를 때가 있었습니다. 그러고 나서 잠자리에 들었습니다.

다음 날 아침 CloudWatch를 확인하면, VM(가상 머신)이 새벽 3시부터 아무것도 하지 않은 채 켜져 있는 것을 발견하곤 했습니다. 실행 중이지만 아무 일도 하지 않으면서 크레딧만 태우고 있었던 것이죠.

이것이 문제입니다. 데이터 로딩을 위해서는 큰 사양의 머신이 필요하지만, 그 이후에는 필요하지 않습니다.

첫 번째 생각: AWS ML이 결정하게 하자

저의 첫 번째 본능은 AWS Compute Optimizer를 사용하는 것이었습니다. 이는 EC2 사용 패턴을 분석하여 적절한 인스턴스 유형을 추천해 주는 관리형 ML 서비스입니다. 똑똑하죠?

활성화하고 기다렸습니다. 그리고 또 기다렸습니다.

알고 보니 Compute Optimizer는 권장 사항을 생성하기 전에 최소 30시간 연속의 사용 데이터가 필요했습니다. 파이프라인 실행을 위해 가끔씩 생성하는 VM의 경우 이는 실용적이지 않았습니다.

그래서 다음 단계로 넘어갔습니다.

두 번째 생각: Bedrock Agent

다음 아이디어는 Amazon Bedrock을 에이전트로 사용하여 언제 어떻게 크기를 조절할지 추론하게 하는 것이었습니다. LLM(대규모 언어 모델)이 결정하게 하는 것이죠.

하지만 생각하면 할수록 과하다는 느낌이 들었습니다. 결정 과정은 복잡하지 않습니다:

"파이프라인이 완료되었는가? 예 → 크기 축소. 아니오 → 유지."

이것은 추론의 문제가 아니라 자동화의 문제입니다. 여기서 Bedrock을 사용하는 것은 가치를 더하지 않으면서 복잡성만 더하는 AI 워싱 (AI washing)에 불과했습니다.

그래서 단순하게 유지하기로 했습니다.

해결책: 이벤트 기반 VM 크기 조절 (Event-Driven VM Resize)

제가 구축한 것은 파이프라인이 완료되는 것을 감지한 다음, 자동으로 VM의 크기를 줄이는 가벼운 에이전트입니다.

스택 (Stack):

emit_event.py: VM에서 실행되며, 파이프라인이 종료될 때 이벤트를 발생시킵니다.
Amazon EventBridge: 이벤트를 수신합니다.
AWS Lambda: 크기 조절 로직을 처리합니다.
Amazon SNS: 이메일 알림(성공 또는 실패)을 보냅니다.

Pipeline finishes (파이프라인 종료)
      ↓
emit_event.py → EventBridge
...

ML도, LLM도 아닙니다. 그저 작업에 딱 맞는 도구일 뿐입니다.

Architecture (아키텍처)

Your VM (사용자 VM)                        AWS Cloud (AWS 클라우드)
──────────────────             ─────────────────────
run_pipeline.sh                EventBridge (custom bus)
...

모든 AWS 리소스는 단 한 번의 CloudFormation 명령으로 배포됩니다. 콘솔에서 수동으로 클릭할 필요가 없습니다.

Setup 3 Steps (설정 3단계)

Step 1 Deploy AWS infrastructure (1단계: AWS 인프라 배포)

git clone https://github.com/Harivelu0/vm-resize-agent
cd vm-resize-agent

...

이메일을 확인하세요 → AWS 구독(subscription) 링크를 승인합니다.

Step 2 Copy agent to your VM (2단계: VM으로 에이전트 복사)

scp -i your-key.pem -r agent/ pipeline/ \
  ec2-user@your-vm-ip:~/vm-resize-agent/

...

Step 3 Add your pipeline steps (3단계: 파이프라인 단계 추가)

pipeline/steps.conf 파일을 편집합니다:

python3 /home/user/myproject/fetch_data.py
python3 /home/user/myproject/transform.py
python3 /home/user/myproject/load_db.py

실행:

bash pipeline/run_pipeline.sh

끝입니다. 파이프라인이 종료되면 → VM 크기가 조정되고 → 이메일이 도착합니다.

The Key Design Decision: steps.conf (핵심 설계 결정: steps.conf)

제가 특별히 신경 썼던 한 가지는 이 도구가 제 파이프라인뿐만 아니라 누구의 파이프라인에서도 작동해야 한다는 점이었습니다.

그래서 run_pipeline.sh는 절대 변경되지 않습니다. 사용자는 오직 steps.conf만 편집하면 되며, 한 줄에 하나의 명령, 한 줄에 하나의 단계(step)를 작성합니다.

# steps.conf
python3 /home/user/fetch_gdelt.py
python3 /home/user/build_forecasts.py
...

래퍼(wrapper)가 각 줄을 읽어 순서대로 실행하고, 성공/실패를 추적하며, 마지막에 이벤트를 발생(emit)시킵니다. 설계 단계부터 범용적(Generic)으로 만들어졌습니다.

The Email Alert (이메일 알림)

성공 시:

Pipeline: data-loader
Status:   SUCCESS
Steps:    3/3
...

실패 시:

Pipeline:  data-loader
Status:    FAILURE
Steps:     2/3
...

실패 케이스가 중요합니다. 실패 시에는 VM 크기를 의도적으로 크게 유지하여, 상태를 잃지 않고 SSH로 접속하여 디버깅(debug)할 수 있도록 했습니다.

겪었던 어려움 (Difficulties I Faced)

1. 크기 조정 후 IP 변경 (IP changes after resize)

Lambda가 EC2를 중지(stop)하고 다시 시작(restart)하면 새로운 공인 IP 주소를 받습니다. SSH 접속이 안 될 때서야 이 사실을 깨달았습니다. 해결책: 데모 실행 전에 Elastic IP를 할당하세요.

aws ec2 allocate-address --region us-east-1
aws ec2 associate-address \
  --instance-id i-xxx \
...

2. 크기 조정 후 Docker 중단 (Docker goes down after resize)

EC2의 크기 조정은 재부팅(reboot)을 의미합니다. 실행 중인 모든 Docker 컨테이너가 중지됩니다. 따라서 서비스가 자동으로 다시 시작되도록 VM의 /etc/rc.local에 다음 내용을 추가하세요:

sudo service docker start
cd /home/ec2-user/myproject && docker-compose up -d

실시간 데모 (Live Demo)

데모를 위해 EC2에서 Docker로 실행되는 Postgres에 로드된 실제 날씨 데이터셋을 사용했습니다.

EC2: t3.large (이전)
       ↓
파이프라인 실행: 다운로드 → 파싱 → Postgres에 로드
...

비용 현실성 (Cost Reality)

리소스 (Resource)	월간 비용 (Monthly Cost)
EventBridge	~$0 (프리 티어 (free tier))
...

절감액은 사용 중인 인스턴스에 따라 달라집니다. t3.large 인스턴스를 하루 20시간 동안 유휴 상태로 두면 매달 약 $25를 낭비하게 됩니다. c5.4xlarge와 같은 더 큰 인스턴스의 경우, 매달 $200 이상의 비용을 절감할 수 있습니다.

사용 시점 (When to Use This)

다음과 같은 경우에 이 방식이 적합합니다:

EC2에서 데이터 파이프라인 (data pipelines)을 수동으로 또는 스케줄에 따라 실행하는 경우
파이프라인 완료까지 걸리는 시간이 예측 불가능한 경우
데이터 로드 완료 후 고사양 인스턴스가 필요하지 않은 경우
아직 EMR이나 Glue를 도입할 준비가 되지 않은 경우 (파이프라인 구축 전 단계)

다음과 같은 경우에는 적합하지 않습니다:

이미 EMR Serverless 또는 Glue를 사용 중인 경우 (해당 서비스들은 자동 종료됨)
파이프라인 실행 시간이 30분 미만인 경우 (수동으로 크기를 조정해도 무방함)
수평 확장 (horizontal scaling)이 필요한 경우 (대신 Auto Scaling Groups를 사용하세요)

왜 Glue나 EMR이 아닌 VM인가?

솔직한 답변을 드리자면, 당시에는 결정을 내릴 만큼 제 데이터에 대해 충분히 알지 못했습니다.

Glue와 EMR은 훌륭한 서비스입니다. 하지만 사전에 답변해야 할 질문들이 따릅니다:

데이터 형식 (data format)은 무엇인가?
어떤 변환 (transformations) 작업이 필요한가?
데이터의 양 (volume)은 어느 정도인가?
Spark가 필요한가?

학습 단계에서는 이러한 질문에 대한 답을 아직 가지고 있지 않습니다. 그저 데이터를 로드하고, 어떤 데이터를 다루고 있는지 확인하며, 파이프라인이 작동한다는 것을 증명해야 할 뿐입니다.

VM (가상 머신)을 사용하면 인프라에 대한 결정 없이도 이를 수행할 수 있습니다. 오직 Python 스크립트만 있으면 됩니다. 파이프라인이 검증되고 데이터에 대한 이해가 생기면, 그때 적절한 관리형 서비스 (managed service)로 마이그레이션하면 됩니다.

지금이 바로 그 단계입니다. 어떤 서비스가 필요한지 알기 전 단계 말입니다.

사실 이것이 실제 팀들이 일하는 방식이기도 합니다. 새로운 데이터 프로젝트의 첫날부터 EMR로 시작하는 사람은 아무도 없습니다. 먼저 탐색하고, 작동함을 증명한 뒤, 규모를 키웁니다.

1단계: 탐색 (Explore)         → VM + Python 스크립트
2단계: 작동 증명 (Prove it works)  → VM + vm-resize-agent
3단계: 확장 (Scale)           → Glue / EMR / Spark

리포지토리 (Repo)

모든 것은 오픈 소스입니다. 클론(Clone)하고, steps.conf를 편집한 뒤 배포하세요.

GitHub: https://github.com/Harivelu0/vm-resize-agent

다음 단계 (What's Next)

추가하고 싶은 몇 가지 사항이 있습니다:

다음 예정된 실행(cron 기반) 전 자동 크기 조정 백업 (back up)
이메일과 병행하는 Slack 알림
Azure VM 지원 (동일한 패턴, 다른 SDK 사용)

아이디어가 있거나 문제에 직면하면 GitHub issue를 생성해 주세요. 기꺼이 도와드리겠습니다.

저의 ML 학습 여정의 일환으로 공개적으로 구축(Building in public)하고 있습니다. 더 많은 실무적인 AWS 패턴을 위해 계속 지켜봐 주세요.