🚧 백엔드 프레임워크
Express.js를 전제로 설명하지만 대부분의 백엔드 프레임워크에 적용할 수 있습니다.
Express.js로 개발한 작은 프로젝트를 AWS Lambda와 API Gateway를 활용한 서버리스로 마이그레이션하려고 찾으며 두가지 방법을 찾았고 결국 둘 중 하나의 방법으로 구현을 끝내고 느낀 두가지 방법의 특징을 소개해보려 한다.
올바른 비유는 아니겠지만 이해를 돕기 위해 GraphQL과 REST API에 빗대어 설명하겠다.
📦 패키징
말 그대로 기존에 구현한 서버를 패키징해서 Lambda 함수에 올려서 Lambda 함수 하나가 서버 자체가 되는 방법이다.
예를 들어 GET abc.com/data/1 를 호출하면 abc.com 까지는 API Gateway가, /data/1은 Lambda가 라우팅할 수 있다. GraphQL을 떠올리면 이해하기 쉬울 것 같다!
특징
-
마이그레이션이라면 시간 등 대부분에서 더 효율적이다.
패키징을 위한 약간의 처리와 API Gateway-Lambda를 하나만 연결하면 마무리되어 가장 간단하고 시간 등의 리소스를 절약할 수 있다. -
모듈, 유틸 코드, DB 연결 등을 재사용할 수 있다.
하나의 Lambda 함수에서 모든 로직을 처리하므로 Lambda마다 모듈을 추가하는 등의 번거로운 일이 줄어든다.
심지어 Lambda가 Stateless라고는 하지만 매 실행마다 DB에 새로 연결하지는 않는다. 실제로 실행해보면 기존 연결을 끊지 않고 재활용함을 알 수 있는데 하나의 엔드포인트에서 DB를 연결한다면 별도의 함수에서 새로 연결하기를 반복하는 것보다 효율적이다. -
API별 관리는 알아서 처리해야한다.
엔드포인트가 하나이기 때문에 엔드포인트를 분리해서 CSP에서 관리할 수 없고 서버에서 관리하는 방식과 똑같이 알아서 관리해야한다. 인가를 하지 않아도 되는 API가 포함되어있다면 API Gateway의 Authorizer를 활용하기도 어렵다.
AWS Lambda에 Node.js Express 애플리케이션 배포하기
🔀 API별 Lambda 함수
엔드포인트, API별로 Labmda 함수를 새로 구성하는 것이다. 마이그레이션이라기보다는 코드를 일부 재사용해서 새로 서버리스 애플리케이션을 구성하는 방법에 가깝다.
위 사진처럼 엔드포인트마다 분리하거나 API마다 분리하거나 필요와 목적, 효율에 맞게 기존 애플리케이션 구현을 쪼개면 된다. GraphQL과 비교한 REST API를 떠올리면 이해하기 쉬울 것 같다!
특징
-
새롭고 복잡하다.
말만 마이그레이션이지 코드를 일부 재사용해서 새로 개발하는 것과 비슷하다. 그만큼 시간도 패키징보다 오래 걸리고 CSP 학습 리소스도 추가로 발생한다. -
모듈, 유틸 코드, DB 연결 등을 재사용할 수 없다.
함수마다 DB 연결을 시도하고 함수마다 모듈/유틸 코드나 layer를 추가해야한다. DB 연결을 계속 새로 시도하는 점은 비효율적일 것이고 코드나 계층을 매번 추가해야하는 점은 생각보다 더더욱 번거롭다. -
API별 관리까지 완전관리를 적용할 수 있다.
API별로 권한 부여자를 붙이거나 쓰로틀링을 거는 등의 인가와 트래픽 제한에서 분리가 가능하다.
하지만 사실은..
위에서 두가지 방법을 열심히 설명했지만 이미 구성된 백엔드 애플리케이션을 서버리스로 마이그레이션한다면 Beanstalk, 특히 컨테이너를 활용해서 배포했다면 AWS Fargate, AWS ECS, AWS EKS 등의 서비스를 활용해서 Lift&Shift 방식을 활용하는 것을 권장할 것 같다.
하지만 방금 마무리한 서버리스 마이그레이션 프로젝트의 목적이 Lambda와 API Gateway를 활용하고 아키텍처 이해와 비교하는 것이 목적이었기 때문에 이 두 서비스를 활용해서 마이그레이션을 하는 다양한 방법이 있다~는 취지로 글을 써보려 한다.
Lambda + API Gateway를 활용하는 아키텍처 이해를 위해서는 시도해볼만하고 AWS 서비스나 컨테이너 학습 리소스가 부담이라면 참고하겠지만 그 이외의 경우에는.. 혼자 학습을 위해서 시도했지 당장 급한 실무라면 고려하지 않을 것 같다..🫠
