NestJS, Lambda, CDK 및 Docker를 사용하여 서버 배포하기

Intro

최근 부동산 비즈니스가 빠르게 성장하면서 부동산 어드민 시스템의 필요성이 증가했다.
팀의 니즈에 따라 속도감 있으면서도 안정감 있고 확장성 있는 아키텍처 구축이 필요했다.
사실 기존의 Node.js 애플리케이션을 개발/운영하면서 아쉬운 점도 있고 개선할 사항도 많았다. 그동안 고민했던 사항들을 반영하여 프로젝트를 시작했다.

아키텍처

기존의 프로젝트와 새로운 프로젝트의 아키텍처 구성도이다.
구성도로 보면 새로운 프로젝트 구조가 더 단순한 걸 알 수 있는데 인프라의 복잡성을 낮추고 비즈니스 코드에 집중할 수 있는 구조다.

기존 프로젝트 아키텍처

새로운 프로젝트 아키텍처

개선점

1. NestJS FrameWork 사용
사실 위에서 언급한 빠르고 안정감 있는 개발에는 프레임워크의 역할이 가장 크다.
기존의 프로젝트에선 Life Cycle의 모든 과정을 직접 만들어줘야 했었다.
아무래도 시간도 오래 걸리고 프레임워크 대비 코드의 성능이나 효율이 좋지 않을 수도 있다.
물론 좋은 점도 있는데 직접 삽질하며 깨달은 게 많고 프레임워크가 얼마나 소중한지 느낄 수 있다. 😇

라우팅을 예로 들면, 기존의 프로젝트에선 Api Gateway의 1차 라우팅과 Node.js 내에서 2차로 라우팅 코드를 모두 작성해 줘야 한다.
NestJS에서도 물론 라우팅 관련 코드를 작성하지만 10배는 간단하고 안정적이다.

2. Lambda 통합
기존 프로젝트의 람다는 기능별로 최대한 람다를 통합을 했지만 여전히 나누어져 있다.
새로운 구조처럼 람다를 하나로 통합하면서 좋은 점은 우선 구조가 단순해져서 복잡성이 줄어든다.
람다 인프라를 위한 cdk 코드가 줄어들고 인프라가 아닌 비즈니스 로직에 집중할 수 있다.

또한 람다의 가장 큰 허들인 콜드스타트를 훨씬 줄일 수 있다.
람다 수를 적게 사용하면 그만큼 용량이 커지는 것도 고려해야 하지만 여기선 우려할 수준은 아니었다.

3. Docker Container
구성도를 보면 기존에는 로컬에서 사용하던 소스코드는 각각의 람다로 흩어져있다.
또한 로컬의 Node Modules와 Layer에 등록하는 Node Modules는 동일하지 않고 별도로 존재한다.
그러다 보니 시스템이 복잡해질수록 종속성 문제가 발생할 수 있다.

도커를 사용하면 로컬에서 사용하던 환경을 도커 컨테이너를 통해서 그대로 람다에 옮길 수 있다.
또한 기존의 프로젝트처럼 별도의 람다 Layer를 만들고 관리할 필요도 없다.
도커 이미지는 AWS ECR(Elastic Container Registry)에 저장해서 람다에서 불러올 수 있다.

느낀점

기존의 프로젝트에서 아쉬웠던 사항들을 새로운 프로젝트에 많이 적용할 수 있어 정말 재밌게 개발한 것 같다.
또한 1차 완성을 목표로 예상했던 5주 기간 내 완료할 수 있어 좋았는데 NestJS의 도입과 아키텍처 개선으로 얻은 이득이 정말 크다.