포스트

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 구성근거
MinIOS3처음부터 S3 호환 API로 맞춰 둔 부분. 설정만 바뀝니다
로컬 머신의 Docker ComposeEC2 위의 같은 composecompose 파일이 거의 그대로 갑니다
PostgreSQL 컨테이너PostgreSQL 컨테이너 유지관리형 DB(RDS)로 빼는 것이 정석이지만 이 편의 범위 밖입니다
localhost 접근security group으로 제한한 public IP 접근접근 제어가 처음 생깁니다

핵심 교체는 MinIO 하나이고, 나머지는 “같은 것을 어디서 돌리는가”의 변화입니다.

전환 순서

  1. S3 bucket 생성과 데이터 이전 (3편): 원본 parquet와 MLflow artifact용 bucket을 만들고 aws s3 sync로 올립니다
  2. EC2 준비 (4편): instance를 띄우고, S3와 ECR 권한이 있는 IAM role을 붙입니다. MLflow와 Airflow를 함께 돌리므로 t3.micro로는 부족하고 메모리 4GB 이상 type이 필요합니다
  3. 이미지 push와 pull (5편): 커스텀 이미지를 --platform linux/amd64로 빌드해 ECR에 올리고 EC2에서 받습니다
  4. 설정 전환: 아래의 .env 변경이 이 편의 중심입니다
  5. 구동과 접근 제어: 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 로그)도 같은 원리로 붙일 수 있습니다.

확인

전환이 끝났는지는 세 가지로 확인합니다.

  1. 로컬에서 tracking server 주소를 EC2 public IP로 바꿔 실험 하나를 기록하고, artifact가 S3 콘솔에 나타나는지
  2. Airflow UI에서 재학습 DAG를 수동 trigger해서 끝까지 도는지
  3. 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 라이센스를 따릅니다.