AWS 해부 (7) 응용: NYC 택시 스택을 AWS로
로컬 Docker Compose로 돌리던 MinIO, MLflow, Airflow, FastAPI 스택을 AWS로 옮깁니다. MinIO를 S3로 바꾸는 설정 전환, EC2 위의 compose 구동, 접근 제어까지의 순서와 이 구성이 남겨 둔 것을 정리합니다.
AWS 해부 (7) 응용: NYC 택시 스택을 AWS로
AWS 해부 시리즈의 7편입니다. 전체 목차는 0편에 있습니다.
무엇을 무엇으로 바꾸나
NYC 택시 프로젝트 6편의 로컬 스택을 기준으로, 옮기는 것과 유지하는 것을 먼저 나눕니다.
| 로컬 구성 | AWS 구성 | 근거 |
|---|---|---|
| MinIO | S3 | 처음부터 S3 호환 API로 맞춰 둔 부분. 설정만 바뀝니다 |
| 로컬 머신의 Docker Compose | EC2 위의 같은 compose | compose 파일이 거의 그대로 갑니다 |
| PostgreSQL 컨테이너 | PostgreSQL 컨테이너 유지 | 관리형 DB(RDS)로 빼는 것이 정석이지만 이 편의 범위 밖입니다 |
| localhost 접근 | security group으로 제한한 public IP 접근 | 접근 제어가 처음 생깁니다 |
핵심 교체는 MinIO 하나이고, 나머지는 “같은 것을 어디서 돌리는가”의 변화입니다.
전환 순서
- S3 bucket 생성과 데이터 이전 (3편): 원본 parquet와 MLflow artifact용 bucket을 만들고
aws s3 sync로 올립니다 - EC2 준비 (4편): instance를 띄우고, S3와 ECR 권한이 있는 IAM role을 붙입니다. MLflow와 Airflow를 함께 돌리므로
t3.micro로는 부족하고 메모리 4GB 이상 type이 필요합니다 - 이미지 push와 pull (5편): 커스텀 이미지를
--platform linux/amd64로 빌드해 ECR에 올리고 EC2에서 받습니다 - 설정 전환: 아래의
.env변경이 이 편의 중심입니다 - 구동과 접근 제어:
docker compose up -d후, MLflow UI(5000)와 Airflow UI(8080) 포트를 security group에서 내 IP로만 엽니다
설정 전환: MinIO를 걷어낸다
MLflow 해부 6편의 compose 구성에서 바뀌는 것은 환경 변수와 서비스 목록뿐입니다.
1
2
3
4
5
6
7
8
# 로컬 (MinIO)
AWS_ACCESS_KEY_ID=minio
AWS_SECRET_ACCESS_KEY=minio123
MLFLOW_S3_ENDPOINT_URL=http://minio:9000
MLFLOW_ARTIFACT_ROOT=s3://mlflow-artifacts
# AWS (S3)
MLFLOW_ARTIFACT_ROOT=s3://my-mlops-artifacts-hoseung
세 줄이 지워지는 이유가 이 시리즈의 요약입니다.
MLFLOW_S3_ENDPOINT_URL삭제: endpoint를 지정하지 않으면 boto3가 진짜 S3로 갑니다 (3편)AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY삭제: EC2에 붙인 IAM role이 임시 자격 증명을 공급하므로 key를 서버에 두지 않습니다 (4편)
compose 파일에서는 minio 서비스와 그 volume 정의가 통째로 빠집니다. Airflow의 원격 로그 저장(Airflow 해부 6편에서 언급한 S3 로그)도 같은 원리로 붙일 수 있습니다.
확인
전환이 끝났는지는 세 가지로 확인합니다.
- 로컬에서 tracking server 주소를 EC2 public IP로 바꿔 실험 하나를 기록하고, artifact가 S3 콘솔에 나타나는지
- Airflow UI에서 재학습 DAG를 수동 trigger해서 끝까지 도는지
- instance를 재부팅해도 compose가 다시 올라오는지 (
restart: unless-stopped확인)
이 구성이 남겨 둔 것
한 대의 EC2와 security group 제한은 학습과 개인 프로젝트까지의 구성입니다. 다음 단계는 이 시리즈의 범위 밖이라 이름만 남깁니다.
- HTTPS와 도메인: 지금은 IP 직접 접근이고 통신이 암호화되지 않습니다. 도메인, 인증서, reverse proxy가 필요합니다
- 인증: MLflow와 Airflow 앞에 인증층이 없습니다. security group의 IP 제한이 유일한 방어입니다
- RDS: metadata DB가 instance와 운명을 같이합니다. 관리형 DB로 분리해야 instance를 부담 없이 갈아치울 수 있습니다
- 비용 최적화: 24시간 켜 두는 대신 필요할 때만 켜는 스케줄링, spot instance 같은 선택지가 있습니다
시리즈를 마치며
일곱 편의 요약입니다.
- 리소스는 region 소속이고, 과금은 시간, 용량, 전송의 세 축입니다 (1편)
- root user는 잠그고, 작업은 IAM user로, 서버는 role로 합니다 (2편, 4편)
- S3는 bucket과 object 두 단위이고, MinIO와의 호환이 로컬에서 클라우드로 가는 다리였습니다 (3편)
- instance는 중지해도 EBS 과금이 남고, 종료는 복구가 없습니다 (4편)
- 이미지는 ECR을 중계로 옮기고, 빌드와 실행의 아키텍처를 맞춥니다 (5편)
- Budgets 알람을 첫날 걸고, 지울 때는 부속 리소스까지 확인합니다 (6편)
같은 글감의 도구 편은 MLflow 해부 시리즈와 Airflow 해부 시리즈입니다.
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.