AWS Lambda ML 모델 서빙용으로 사용하기

AWS Lambda

AWS Lambda

보통 어떤 경우에 사용할까요?

AWS Lambda는 서버리스 컴퓨팅 환경을 제공하여 인프라를 관리할 필요 없이 코드 실행이 가능하도록 합니다.

이를 통해 사용자는 서버 관리 부담 없이 특정 이벤트 발생 시 자동으로 실행되는 코드를 작성할 수 있습니다.

AWS 가이드에서는 ‘Lambda는 빠르게 스케일 업해야 하고 수요가 없을 때는 0으로 스케일 다운해야 하는 애플리케이션 시나리오에 이상적인 컴퓨팅 서비스’라고 소개하고 있습니다.

일반적으로는 다음과 같은 이유로 람다 사용을 고려하게 됩니다.

• 운영 비용 절감: Lambda는 사용한 만큼만 비용을 지불하는 구조이므로, 유휴 상태에서도 비용이 발생하는 서버 기반 인프라보다 경제적입니다. 특히 트래픽이 일정하지 않고, 간헐적으로 실행되는 작업에서는 매우 효과적인 비용 절감이 가능합니다.
• 자동 확장: Lambda는 요청 수에 따라 자동으로 확장되므로 트래픽 변화에 유연하게 대응할 수 있습니다. 트래픽이 갑자기 증가해도 별도의 설정 없이 자동으로 확장되며, 사용량이 줄어들면 다시 리소스를 축소하여 불필요한 비용 지출을 방지할 수 있습니다.
• 관리 부담 감소: 별도의 서버 인프라를 구축하거나 유지보수할 필요 없이 코드 배포 및 실행이 가능하여 운영 부담이 줄어듭니다. 이는 개발자가 인프라 관리보다 코드 로직 개발에 집중할 수 있도록 도와줍니다. 또한 AWS가 제공하는 다양한 서비스(S3, DynamoDB 등)과 쉽게 통합할 수 있어 서버리스 아키텍처를 효율적으로 구성할 수 있습니다.

 

ML 서빙 플랫폼이 갖춰지지 않은 환경에서 람다를 통해 모델 서빙하기

ML 모델을 서빙하기 위한 플랫폼(BentoML, MLflow, KFServing, …)이 갖춰지지 않은 경우, AWS Lambda를 활용하여 간단하게 모델 서빙이 가능합니다. 사내 환경에 따라 MLOps 기술이 발달하지 않았거나 아직 모델 서빙 파이프라인이 완벽히 구축되지 않은 경우를 생각해볼 수 있을 것 같습니다.

그 외에도 다음과 같은 경우 람다를 고려할 수 있습니다.

• 소규모 프로젝트: ML 모델을 서빙할 별도 인프라를 구축하기 어려운 경우
• 간헐적 요청 처리: 모델 호출 빈도가 낮아 서버를 상시 운영할 필요가 없는 경우
• 빠른 프로토타이핑: 간단한 모델을 빠르게 배포하여 실험하고 싶은 경우

하지만 Lambda 기반 모델 서빙에는 중요한 단점이 있습니다. 콜드 스타트 문제가 발생할 수 있다는 점입니다. Lambda 함수는 요청이 없을 경우 종료되며, 이후 첫 요청이 발생하면 다시 실행되는데, 이때 모델을 로드하는 데 시간이 소요될 수 있습니다. 따라서 모델이 무거운 경우 API 응답 시간이 길어질 수 있으며, 이 문제를 해결하기 위해 미리 Lambda를 호출하여 웜업을 유지하거나 모델 추론 결과를 캐싱하는 전략을 고려해야 합니다.

 

AWS Lambda 배포 방식

이제 Lambda를 활용하여 ML 모델을 배포하는 방법을 살펴보겠습니다.

1. zip 파일 기반 배포

Lambda의 기본적인 배포 방식으로, Python, Node.js 등의 코드와 필요한 패키지를 하나의 zip 파일로 압축하여 업로드하는 방식입니다.

다음은 zip 파일 기반으로 Lambda 함수를 배포하는 과정입니다.

1) 코드 작성 및 로컬 환경에서 테스트

• 모델 로드, 추론 등 필요한 코드를 작성합니다.
• 필요한 라이브러리를 requirements.txt 또는 package.json을 사용하여 설치합니다.
• 로컬 환경에서 실행하여 정상적으로 동작하는지 확인합니다.

2) 배포 패키지 생성

• 함수 코드와 라이브러리, 모델 바이너리를 포함하여 하나의 경로에 정리합니다.
• pip install -r requirements.txt -t . 명령어를 사용하여 필요한 패키지를 현재 경로에 설치합니다. (Python 기준)
• zip -r deployment_package.zip . 명령어를 사용하여 배포 패키지를 생성합니다.

3) Lambda에 업로드

• AWS 콘솔을 통해 직접 업로드하거나
• AWS CLI를 사용하여 aws lambda update-function-code --function-name <함수명> --zip-file fileb://deployment_package.zip 명령어를 실행합니다.

4) 테스트 및 모니터링

• Lambda 콘솔에서 테스트 이벤트를 실행해봅니다.
• Amazon CloudWatch를 통해 로그를 확인하고 성능을 모니터링합니다.

단점

• CI/CD 연동의 어려움: 코드 변경 시 수동으로 zip 파일을 업데이트해야 하며, CI/CD 파이프라인과의 연동이 어렵습니다.
• 패키지 크기 제한: Lambda 함수에 직접 업로드할 수 있는 zip 파일의 크기는 50MB로 제한되어 있으며, 이를 넘어가는 경우 Amazon S3 버킷에서 함수로 파일을 업로드해야 합니다.

 

2. 컨테이너 이미지 기반 배포

AWS Lambda는 컨테이너 이미지 기반 배포도 지원합니다.

Docker 이미지를 빌드한 후 Amazon Elastic Container Registry (ECR)에 업로드하여 Lambda에서 실행할 수 있습니다.

다음은 컨테이너 이미지 기반으로 AWS Lambda를 배포하는 과정입니다.

1) Dockerfile 생성

Lambda에서 실행할 코드를 포함한 Dockerfile을 생성합니다.

• 예제 (Python 기반)

FROM public.ecr.aws/lambda/python:3.8 
COPY app.py ./ 
CMD ["app.lambda_handler"]

2) Docker 이미지 빌드

터미널에서 다음 명령어를 실행하여 Docker 이미지를 빌드합니다.

docker build -t my-lambda-image .

3) AWS ECR에 로그인 및 이미지 푸시

Amazon ECR 리포지토리를 생성한 후, 로그인 및 이미지 푸시를 수행합니다.

aws ecr get-login-password --region <your-region> | docker login --username AWS --password-stdin <your-account-id>.dkr.ecr.<your-region>.amazonaws.com 
docker tag my-lambda-image <your-account-id>.dkr.ecr.<your-region>.amazonaws.com/my-lambda-image 
docker push <your-account-id>.dkr.ecr.<your-region>.amazonaws.com/my-lambda-image

4) AWS Lambda에서 컨테이너 이미지 기반 함수 생성

AWS Lambda 콘솔에서 새 함수를 생성하고 배포된 컨테이너 이미지를 선택합니다.

또는 AWS CLI를 통해 생성 가능합니다.

aws lambda create-function --function-name my-lambda-function \
	--package-type Image \
    --code ImageUri=<your-account-id>.dkr.ecr.<your-region>.amazonaws.com/my-lambda-image:latest \ 
    --role <your-lambda-execution-role>

 

5) CI/CD 파이프라인 구축 (AWS CodePipeline + CodeBuild)

GitHub 또는 AWS CodeCommit과 연동하여 자동화된 배포 설정이 가능합니다. CodeBuild를 사용하여 Docker 이미지를 빌드하고 ECR로 푸시 후 CodePipeline에서 Lambda를 업데이트하는 단계를 추가합니다.

• 예제 (AWS CLI)

aws lambda update-function-code --function-name my-lambda-function \
	--image-uri <your-account-id>.dkr.ecr.<your-region>.amazonaws.com/my-lambda-image:latest

이를 통해 Lambda의 컨테이너 이미지 기반 배포를 자동화하고 CI/CD 파이프라인을 활용하여 운영 효율성을 높일 수 있습니다.

단점

• 네트워크 설정 필요: ECR에서 이미지를 가져오기 위해 VPC 및 IAM 설정이 필요할 수 있습니다.

 

AWS API Gateway

배포한 람다 함수를 AWS API Gateway와 연동하면 Lambda 기반의 모델 서빙을 API 형태로 완성할 수 있습니다. Gateway를 사용하면 HTTP 엔드포인트를 통해 모델을 호출할 수 있으며, 인증 및 트래픽 관리 기능도 활용할 수 있습니다.

API Gateway와 Lambda를 연동하는 기본적인 과정은 다음과 같습니다.

1. API Gateway 생성: AWS 콘솔에서 API Gateway 서비스로 이동하여 REST API 또는 HTTP API를 생성합니다.
2. Lambda 함수 연결: 생성한 API의 리소스 및 메서드를 설정하고, 백엔드 통합으로 Lambda 함수를 선택합니다.
3. 배포 및 테스트: API Gateway에서 엔드포인트를 배포하고, Postman 또는 cURL을 사용하여 모델 호출을 테스트합니다.

이와 같이 API Gateway를 활용하면 모델 서빙을 위한 완전한 API 서비스를 구성할 수 있으며, IAM 인증, 요청 제한 등의 기능을 추가하여 보다 안정적이고 효율적인 서비스 운영이 가능합니다.

 

결론

 

AWS Lambda를 활용하면 별도의 ML 모델 서빙 인프라 없이도 손쉽게 모델을 배포할 수 있습니다. zip 파일 기반 배포는 간단하지만 패키지 크기 및 CI/CD 연동에 제한이 있으며, 컨테이너 이미지 기반 배포는 확장성이 뛰어나지만 관리가 더 복잡할 수 있습니다. 특히 컨테이너 이미지를 활용하면 서드파티 라이브러리를 포함한 환경을 쉽게 구성할 수 있으며, 모델 크기가 클 경우에도 배포가 비교적 용이합니다.

배포 방식	장점	단점
Zip 파일 기반	빠른 배포, 간단한 설정	패키지 크기 제한, CI/CD 어려움
컨테이너 기반	확장성, 다양한 언어 지원	네트워크 설정 필요, 관리 부담

 

하지만 Lambda 기반 서빙은 콜드 스타트 문제를 반드시 고려해야 합니다. 함수가 요청이 없을 때 종료되므로, 첫 번째 요청 시 모델 로딩 시간이 길어질 수 있습니다. 특히 모델 크기가 크거나 초기화 과정이 복잡한 경우, 응답 시간이 상당히 지연될 수 있습니다. 이를 예방하기 위해 웜업 요청을 보내거나, 추론 결과를 캐싱하는 전략을 함께 고려해야 합니다.

결국 프로젝트의 요구사항과 운영 환경에 따라 적절한 모델 서빙 방식을 선택하는 것이 중요합니다. Lambda가 모든 경우에 적합한 것은 아니므로, 소규모 프로젝트나 프로토타이핑 또는 비교적 긴 시간 캐싱이 가능할 경우 모델 서빙 방식으로 고려하면 좋을 것 같습니다.