Serverless code 패턴: 함수 당 라우트 하나 vs 함수 당 라우트 여러개

AWS lambda를 개발하며 람다 하나 당 하나의 라우트를 연결할지, 람다 하나당 여러 라우트를 연결할지 고민에 봉착했다.

 

내가 참여하고 있는 프로젝트는 다음과 같은 구조이다.

람다에 /this/is/http/path 로 단일 라우트가 연결되어 있고, 람다 함수 내에서 리퀘스트를 읽고 실행할 로직을 결정하는 형태였다.

처음에는 단순히 람다가 익숙하지 않았기 때문에 단순히 신규 라우트를 추가하는 것으로 생각했다.

하지만, 구글링을 통해 다음과 같은 Serverless Code Pattern에 대해 알게 되었다.

 

1. Microservice Pattern (One Lambda per route)

Pros

• 관심사의 완전한 분리. 각 잡/연산은 배포 단위가 독립되어, 시스템 전체에 영향 없이 애플리케이션의 컴포넌트를 독립적으로 수정할 수 있다. 이는 프로덕션 환경에서 매우 애자일하고 안전한 방식이다.
• 각 람다 함수는 단일 이벤트를 처리하여 디버깅이 쉽다.
• 관심사의 분리는 팀의 자율성에도 좋다. 독립적으로 기능을 프로덕션 환경에 내보낼 수 있다.

Cons

• 람다 함수는 일반적인 마이크로 서비스보다 더 세분화되는 경향이 있다. 이로 인해 많은 함수가 필요하고 이로 인해 관리가 힘들어진다.
• 성능이 느려질 수 있다. 함수가 단 하나의 잡만을 처리하면 호출 빈도가 낮아 더 많은 콜드 스타트가 발생할 수 있다.
• 여러 함수가 프로비져닝 되어야 하므로 배포가 느려진다.

2. Monolithic/Service Pattern (One Lambda with multiple routes)

라우트를 어떻게 그룹하는지에 따라 Monolithic과 Service Pattern으로 나뉜다.

2.1 Service Pattern

데이터 모델이 연관되어 있거나 인프라스트럭쳐 디펜던시를 공유하는 일부 잡(~4)을 단일 람다 함수에 연결

Pros

• 관리해야 할 람다 함수가 줄어든다.
• 관심사의 분리가 일부 존재한다.
• 팀은 여전히 자율성을 갖고 일할 수 있다.
• 배포가 빨라진다.
• 이론적으로 더 나은 성능을 갖는다. 여러 잡이 단일 람다에 연결될 때, 람다 함수가 호출될 가능성은 더 높아진다. 따라서 람다가 콜드 스타트 가능성이 낮아진다.

Cons

• 람다 함수가 여러 잡을 처리하고, 잡마다 다른 결과가 나오기 때문에 디버깅이 약간 더 복잡해진다.
• 리퀘스트 메소드나 endpoint에 따라 적절한 로직을 호출하는 라우터를 생성해야 한다.
• 람다 함수 내에 더 많은 연산을 두기 때문에 함수 사이즈가 커진다.

2.2 Monolith Pattern

전체 애플리케이션을 하나의 람다 함수에 연결

Pros

• 더 전통적인 방식으로 단일 람다 함수에 대한 이해와 관리가 쉽다.
• 전체 코드 사이즈에 따라 빠른 배포가 가능하다.
• 이론적으로 더 나은 성능을 갖는다. 여러 잡이 단일 람다에 연결될 때, 람다 함수가 호출될 가능성은 더 높아진다. 따라서 람다가 콜드 스타트 가능성이 낮아진다.

Cons

• 복잡한 라우터를 개발해야 하고, 라우터가 항상 적절한 로직을 호출함을 보장해야 한다.
• 성능을 측정하기 어려워진다. 람다 함수의 실행 시간이 다양해진다.
• 실제 응용 프로그램에서는 큰 함수 사이즈로 인해 쉽게 람다 사이즈 리밋에 도달할 수 있다.

 

AWS 블로그에서는 람다 함수가 모놀리틱해졌을 때의 단점이 더 크기 때문에 람다당 하나의 라우트만을 사용하는 것을 권장하고 있다. 하지만 내가 개발하고 있는 프로젝트는 실제 서비스가 아니고 (어디까지나 팀 내의 생산성 도구) 코드의 규모가 크지 않기 때문에 모놀리틱하게 만들기로 결정했다. 람다 함수로 실제 서비스를 개발하실 분들이라면 이러한 패턴을 한번 살펴보시는 것을 추천한다.

 

참고한 자료

https://www.serverless.com/blog/serverless-architecture-code-patterns/

https://aws.amazon.com/ko/blogs/compute/best-practices-for-organizing-larger-serverless-applications/

Best practices for organizing larger serverless applications | Amazon Web Services

Serverless Code Patterns