AWS-ECS+S3로 MLFlow 구축해보기 1

Related to: AWS

시작에 앞서

이 글은 2부로 나뉘어져 있습니다.

aws에 mlflow를 올리기 위해 필요한 각 구성요소에 대한 설명
aws에 실제로 mlflow를 올리기 위한 과정들

시작하며

팀 내에서 모델을 사용하여 서비스를 배포하기 위해 여러 준비를 하고 있었습니다. 그 중 고민이 몇 가지 있었는데 다음과 같습니다.

모델 버전관리의 어려움

기존에는 사람이 진행했지만 B2B 서비스라 같은 모델이어도 회사 별로, 버전 별로 관리할 필요가 있기 때문에 시스템으로 관리하고 싶었습니다.
Docker Image와 분리

모델 업데이트 될 때 마다 이미지를 다시 배포하고 싶지 않았습니다. 모델이 아직 안정적으로 서비스 할 수 있는 상황이라는 것을 장담할 수 없기 때문에 자주 업데이트하고, 편하게 업데이트 하고 싶었습니다.

괜찮은 방법이 없나 찾아보던 중, MLFlow가 눈에 들어왔습니다. 마침 팀에서 공통적으로 사용할만한 tracking 툴도 없었겠다, 이 참에 구축해보자고 마음먹었습니다.

MLFlow는 실험, 재현성, 배포 및 중앙 모델 레지스트리를 포함한 ML 수명 주기를 관리하는 오픈 소스 플랫폼입니다. MLFlow에 대한 기본적인 정보는 아래에 정리해 놓았습니다.

ML Flow - 기본 사용

어떻게 구성할까

MLFlow 서비스를 구성하는 방법은 여러가지 있습니다. 당연하지만 On-premise로 구축하는 것이 가장 쉽고 저렴합니다. 하지만 관리 포인트를 줄이고 싶고, 모델 다운로드를 위해 사내 PC로 외부에서 접속하게 포트를 개방하는 것은 껄끄러운 부분이 있어 AWS에 구축하기로 했습니다.

마침 AWS에서 예제를 제공해줘서 따라하면서 구성할 수 있었습니다. AWS 예제를 통해 구성되는 모양은 아래와 같습니다.

이는 MLFlow 공식 문서의 시나리오 4에 해당하는 구성입니다.

flowchart TD
	A["Inference Server"] --"'Metric + Parameter Data'"--> C;
	subgraph AWS
	C["ALB"]-->D;
	D["ECS Instance(MLFlow Server)"]-->E;
	E[("MySQL (RDB)")]
	F[("s3 bucket")]
	end
	A--"Artifact(model weight, image, ..etc)"-->F

왜 저 구성일까

위와같이 구성한다면, local에서 logging을 수행할 때 s3 bucket에 데이터를 올리기 위한 접근 권한 설정이 필요합니다. 사용자 입장에서는 tacking server로 artifact를 넘기고 tracking server가 s3 bucket에 데이터를 넘기면 사용하기 더 편할 것입니다.

하지만 서버 입장에서는 artifact 같은 대형 데이터를 유저가 직접 업로드 해준다면, 부하가 매우 적어질 것입니다. 또한 위 그림처럼 중간에 ALB(Application Load Balancer)와 같이 이동한 데이터에 따라 과금이 되기 때문에 주의가 필요합니다.

Instance 하나를 Tracking Service겸 DB겸 Artifact Storage로 사용한다면?
- Instance가 날라 갈 경우 위 데이터들이 사라지지 않도록 설정이 필요합니다. 또한 Artifact의 사용량에 따라 볼륨을 더 크게 확장하고 마이그레이션을 수행해야 합니다.

→ 비용을 낼 것인가, 우리의 시간을 쓸 것 인가의 선택입니다.

AWS s3 Bucket

Untitled 20.png

s3 Bucket은 비정형 데이터를 저장하기 위한 서비스입니다. 저 Bucket은 크기가 정해져 있지 않습니다. 우리는 계속 데이터를 넣을 수 있으며, 넣은 만큼만 요금을 내면 됩니다. 더 자세한 설명은 공식 페이지를 참조해주세요.

s3의 장점은 ‘최대 크기에 제한이 없고 사용한 만큼 낸다’입니다. 따로 Storage를 잡는다면 artifact가 얼마나 생길지 예측해서 용량을 할당해야 합니다. 그러나 s3 Bucket을 쓰면 그럴 필요가 없습니다. 심지어 저렴합니다.

AWS RDS(RDB로 사용)

Untitled 1 15.png

RDS는 AWS가 제공하는 DB 서비스입니다. 물론, ec2를 사용하여 직접 DB 서버를 만들 수도 있습니다.


RDS	• AWS가 모든 권한과 책임을 가지고 있습니다. • AWS에서는 Oracle, MSSQL, MySQL, PostgreSQL, MariaDB 를 지원합니다. • 뿐만 아니라, 자체 DB인 Aurora 도 제공합니다. • Read Replica를 쉽게 만들고 각 AZ에 두고 사용할 수 있습니다. • 마그네틱 스토리지는 3,000IOPS 까지 지원합니다. • 프로비전된 SSD는 최대 10,000 IOPS 까지 지원합니다.
DB on EC2	• 완전한 권한이 AWS 사용자로 넘어옵니다. 모든 책임과 권한을 사용자가 가집니다. • DB를 잘 알고 있다면 RDS를 뛰어넘을 튜닝의 여지가 있습니다. • EC2 인스턴스의 프로비전된 SSD는 최대 8,000 IOPS를 지원합니다. • 여기서도 데이터 암호화를 지원합니다. EC2 → EBS 통신간에도요! • 모든 설정이 자유로우니, 포트도 원하는데로, 그리고 원하면 하나의 EC2에 여러개의 DB를 설치할 수 도 있습니다. • 딱딱한 RDS 비용체계에 비해 유연하기 때문에 잘 설계하면 비용면에서 더 유리 할 수 있습니다.

RDS

• AWS가 모든 권한과 책임을 가지고 있습니다.
• AWS에서는 Oracle, MSSQL, MySQL, PostgreSQL, MariaDB 를 지원합니다.
• 뿐만 아니라, 자체 DB인 Aurora 도 제공합니다.
• Read Replica를 쉽게 만들고 각 AZ에 두고 사용할 수 있습니다.
• 마그네틱 스토리지는 3,000IOPS 까지 지원합니다.
• 프로비전된 SSD는 최대 10,000 IOPS 까지 지원합니다.

DB on EC2

• 완전한 권한이 AWS 사용자로 넘어옵니다. 모든 책임과 권한을 사용자가 가집니다.
• DB를 잘 알고 있다면 RDS를 뛰어넘을 튜닝의 여지가 있습니다.
• EC2 인스턴스의 프로비전된 SSD는 최대 8,000 IOPS를 지원합니다.
• 여기서도 데이터 암호화를 지원합니다. EC2 → EBS 통신간에도요!
• 모든 설정이 자유로우니, 포트도 원하는데로, 그리고 원하면 하나의 EC2에 여러개의 DB를 설치할 수 도 있습니다.
• 딱딱한 RDS 비용체계에 비해 유연하기 때문에 잘 설계하면 비용면에서 더 유리 할 수 있습니다.

직접 만드는 것이 더 저렴합니다. 그러나 장기적으로 직접 유지보수를 해야 하므로 DB를 유지보수 할 인력이 없는 경우에는 RDS를 이용해보는 것도 괜찮다고 생각합니다.

더 세부적인 비교는 이 글을 참조해주세요.

AWS ECR

Untitled 2 11.png

ECR(Elastic Container Registry)은 AWS만의 Docker hub입니다. public과 private으로 나뉘어져 있으며, public은 모두가 사용할 수 있게 공개되고 private는 제한된 계정만 접근할 수 있게 됩니다.

ECR의 경우 금액은 public, private 모두 리포지토리 저장된 데이터로 계산되며 GB당 0.10$씩 월마다 청구됩니다.

다만 public의 경우, 월 50GB만큼은 요금을 부과하지 않습니다.

더 자세한 설명과 사용법은 공식 문서와 이 정리글을 참조하는 것이 좋습니다.

AWS ECS - Fargate

Untitled 3 10.png

예제는 AWS가 제공하는 ECS(Elastic Container Service)의 Fargate를 사용하여 MLFlow 서비스를 위한 Instance를 생성합니다. 기존에는 AWS에서 인스턴스를 생성하려면 ‘인스턴스 패밀리’ 테이블을 보고 목적에 맞는 HW 구성을 찾아야 했습니다.

AWS Fargate는 우리가 선정한 사양(cpu n개, RAM xGB)에 맞춰 알아서 Instance를 생성합니다. 또한 필요에 따라 Instance 숫자를 마음대로 조절할 수 있습니다. 즉, 서버 크기 조정, 패치, 보안 및 관리의 운영 부담을 없애줍니다.

실제로 사용하기 위해서는 2개의 과정이 필요합니다.

AWS ECR에 Docker Image 등록
AWS ECS에 Cluster 및 Service 생성

Fargate를 사용하면 ec2 instance 생성 → docker 설치 → image pull 등 의 작업을 할 필요 없습니다. 또한 만약 image를 업데이트했다면, ecs에서 자동으로 감지하고 instance를 업데이트합니다.

또한 computing power가 부족하다면, 간단한 숫자 변경으로 동일 service instance를 scale-up 할 수 있고, 그 반대도 마찬가지 입니다.(cpu사용률 등을 조건으로 한 trigger에 따라 자동으로 scale-up ~ down 하는 기능도 존재합니다.)

더 자세한 설명은 공식 문서1, 공식 문서2와 AWS Fargate 개념 및 사용법 정리 글을 보시는 것을 추천합니다. 또한 ECS 구성은 이 글을 참조하는 것이 좋습니다.