NestJS App deploy with lambda docker container support and Serverless Framwork

강하마·2021년 11월 8일

NestJS Serverless Framwork docker lambda

해당 포스트에서는 NestJS 백엔드 어플을 AWS Lambda위에 Docker image로 배포하고 어느정도 기간동안 운영을 해본 경험을 소개합니다. ~~오피셜 내용이 아닌 개인적인 소견임을 참고 바랍니다.~~

람다는 함수 단위의 코드를 배포하기 위한 서비스 아닌가요?

네! 람다는 우리에게 비동기식 호출 방식으로 접하게 되었을것 같은데요. 예를 들어 S3에 업로드한 이미지를 이벤트 트리거로 리사이징 하는것 같이요. Serverless 생태계와 기술의 성장으로 API Gateway와 Lambda를 사용해 API서버를 만드는 것이 관심을 받기 시작 한것 같아요.
s3 triger

NestJS는 NodeJs 백엔드 Framwork 아닌가요?

맞습니다. Nestjs는 효율적이고, 안정적이며, 확장에 용이한 서버 어플리케이션을 구축하기 위한 Nodejs 프레임워크입니다. 하지만 Nestjs도 Nodejs runtime 임으로 aws-serverless-express 모듈을 사용 한다면 Lambda 함수 하나에 배포해 사용할수 있습니다.

기존의 Lambda 패턴과는 다른 것 같아요.

우리가 많이 봐온 Lambda 코드 패턴은 API Gateway 라우터 하나에 하나 혹은 3의 역할을 하는 람다 함수가 붙어 있는 구조를 많이 생각 합니다.

해당 구조는 각각의 람다 함수들이 매우 느슨해 독립적인 배포 또는 기술적 다양성에 탁월할 것입니다. 하지만 관리해야 하는 람다 함수의 수가 늘어나고 모듈을 관리하기 힘들며 자유로운 환경에 오히려 개발자들은 스트레스를 받을수 있다고 봅니다.
lambda docker container support는 250MB 용량 제한의 작은 람다 함수를 10G 용량 제한의 컨테이너 기반으로 배포 가능하게 해줍니다. 또한 NestJS (혹은 다른 프레임워크 Express, Flask, Django등)와 같은 Backend framwork로 구성된 람다 함수도 가능하게 해줍니다.

NestJS를 Lambda 함수에 Docker image 기반으로 배포를 해봅시다.

github link <== 해당 페이지에 들어가면 NestJS를 Lambda 함수에 Docker image 기반으로 배포 할수 있는 템플릿과 실행 방법이 있습니다. 이를 통해 가장 쉽고 빠르며 최소한의 NestJS 백엔드 서버를 배포 할수 있습니다. Click Me!!

해당 기술은 완벽한가요?

그 역시 아닙니다. 저는 개발 및 배포 단계부터 단기간 운영을 하는중 여러 문제점에 부딪쳤습니다.

기술에 대한 진입 장벽과 아직 작은 생태계
- product 개발중 추가 되는 모듈들 때문에 자꾸만 커지는 ZIP용량에 배포 용량 제한 이슈를 만나게 될것을 직감하고 있었습니다. NestJS를 Lambda 함수에 Docker image 기반으로 배포하기 위해서 엄청난 삽질을 많이 했습니다.
- ORM으로 Prisma를 선택해서 개발을 했습니다. 로컬 환경에서는 이슈가 없었지만 배포 이후 해당 모듈에서 이슈가 발생했죠. prisma client는 쿼리엔진을 사용 하는데 로컬의 OS와 Lambda의 OS가 달라서 발생하는 이슈였죠. 저는 이를 해결 하기 위해 근 1주를 써야만 했습니다.
Stateless를 고려해야 하는 개발
- 발급 해준 인증 코드를 다시 입력받아야 하는 기능이 필요 했습니다. 원래 같았으면 Session을 붙여 해결을 했을겁니다. 하지만 Lambda의 꺼졌다 켜졌다 하는 특성 때문에 DynamoBD를 붙여 Session 대신에 사용하게 했습니다.
Cold Start 이슈
- ZIP파일로 배포를 했을때는 약 3초 정도의 warming 시간이 필요 했습니다. 서비스 특성에 따라서 warm 상태가 아닌 cold 상태로 대기 시켜도 될 정도 였습니다. 이는 서버 운영 비용을 상당히 절약 할수 있습니다. 하지만 Docker image로 배포를 하고 나서 부터 약 5 ~ 6초 정도로 늘어 났습니다. 이는 유저 경험에 불편을 줄 정도였고 warm 상태로 대기 시켜야 하는 상황이였습니다.
배보다 배꼽이 커지는 Nat Gateway 사용
- 앞에서 말했듯 Lambda는 Serverless 환경의 서버스이기에 시스템에 맞게 켜졌다 꺼졌다 합니다. 이는 어떤 인스턴스가 이용 될것인지 알수 없고 고정된 IP를 할당 할수 없다는 의미기도 합니다. product를 개발중에 외부서비스와 통신을 해야하는 상황을 만납니다. 예를 들어 간편로그인, 이메일 전송, sms 전송등이 있습니다. 그때 whitelist에 등록할 IP가 필요합니다. 이를 해결하기 위해 Nat Gateway를 EC2에 올려 Lambda에 고정 IP를 할당하는 작업이 필요합니다. 그에 따른 비용은 월에 약 40$ + 사용량 정도의 비용이 들어갑니다.