서버리스 아키텍쳐(Serverless architecture)에 대해 알아보자.

먼저 개발자가 만든 애플리케이션을 사용자에게 제공하기 위한 과정을 간략하게 살펴보자.

보통 호스팅 서비스를 이용해 서버를 구매하거나 임대를 한다.

서버에 접속해 필요한 프로그램을 설치하고 환경변수나

필요한 프로그램을 설치하고 환경변수나 네트워크 관련한 설정을 구성한다.

그리고 피와 땀을 흘려 열심히 만든 앱을 배포하면 세상에 앱이 탄생한다.

이와 같은 과정을 통해 물리 서버 혹은 클라우드의 가상 서버 환경의 인프라를 운영하게 된다.

그럼 서버리스는 무엇일까?

사실 서버가 아예 존재하지 않는다는 개념은 아니다.

이해를 돕기 위해 서버리스의 대표적인 예시로 AWS에서 제공하는 Lambda 라는 서비스를 예로 들어보겠다.

Lambda는 AWS 웹 콘솔에서 원하는 개발 언어를 선택하고 코드를 작성하기만 하면 사용자가 원할 때 프로그램을 실행시킬 수 있게 된다.

이것을 곧이 곧대로 해석해보면 AWS와 같은 서버리스 환경을 제공하는 업체에서 사용자의 요구에 따라 서버 인프라를 구성하거나 운영에 크게 신경 쓰지 않아도 되도록

컴퓨팅 환경을 준비해놓고 필요한 순간에 정의된 코드를 그때 그때 컴퓨터에 올려 실행할 수 있게 해주는 것이다.

요즘은 서버리스가 많이 알려지고 보편화되었지만 처음 알게되었을때 참 신박했던 기억이 있다.

자 그럼 언제 서버리스 아키텍쳐를 사용하면 좋을까?

각각의 요구사항, 서비스 환경과 각자의 선호도 모두 다르기에 정답은 없다고 생각한다.

그렇기에 스스로 겪어본 경험을 토대로 일반적인 장단점을 적어보겠다. (AWS Lambda 기준으로 작성)

서버리스 장점

• 개발 생산성 증가: 개발자가 인프라 구축 및 배포에 신경을 적게 써도 된다. 개발에 집중 할 수 있고 빠르게 아이디어를 검증하기에도 좋다.
• 비용 절감: 서버를 계속 임대(혹은 구매)하는 것이 아니고 사용한 만큼 비용이 과금되는 종량제로 절약이 가능하다.
• 이벤트 드라이븐: 이벤트 단위로 람다 함수를 생성하여 유연한 아키텍쳐를 구성 할 수 있다. API Gateway, SDK 등 결합 및 구성이 용이하다.

서버리스 단점

• 콜드 스타트: 람다는 함수가 특정 시간 이상 호출되지 않은 경우 콜드 상태가 되어 호출시 몇 초의 시작시간이 소요된다.
• 대규모 아키텍쳐: 아키텍쳐가 복잡해지는 경우에는 적합하지 않을 수 있다. 특히 여러개의 람다를 연결해 각각 호출하는 경우 콜드 스타트로 인해 대기시간이 길어질 수도 있으며 인프라 구성이 오히려 복잡해져 관리에 어려움이 있을 수 있어 소규모 프로젝트에 추천한다.
• 서비스 의존성: 서버리스 서비스를 제공하는 AWS, GCP 등 벤더사에 의존성이 생긴다. 상황에 따라 제약이 생길 수도 있고 인프라 이전이 필요한 경우 발목이 잡힐 수도 있다.

만약 소규모 프로젝트나 아이디어 검증을 위한 POC를 진행해야한다면 서버리스 아키텍쳐 도입을 검토해보는 것을 추천한다.