Intro

서버리스 아키텍쳐 또한 MSA 만큼이나 많이 들어볼 수 있는 아키텍쳐 패턴이다.
서버가 없다고? 이게 무슨 소리야....싶겠지만 실제로는 그런 의미는 아니다.

이번 포스팅의 주제는 서버리스. 시작하겠다.

Serverless

앞서 말했듯 Serverless 는 서버가 없다는 의미가 아니다. 마치 서버가 없는 것 마냥 보인다고 해서 Serverless 아키텍쳐라는 이름을 가지게 된 것이다.

서버 자체는 어딘가에서 돌아간다. 즉 우리의 애플리케이션 또한 어딘가의 서버에서 작동한다는 의미다. 하지만 컴퓨터 혹은 가상 머신에 셋업 된 서버가 아니라 BaaS(Backend as a Service) 혹은 FaaS(Function as a Service) 에 의존한다. 예를 들면 Firebase, AWS Lambda 등이 있다.

기존의 많은 서비스들은 자체적인 인프라가 구축 되어있고 이러한 인프라를 관리하는 인력이 필요하게 된다. On-Premise 상에 셋업 된 서버 프로그램이 작동하고, 누군가는 이러한 프로그램을 관리해야 한다. 뿐만 아니라 On-Premise라면, 랙에 잔뜩 쌓여있는 서버 관련 장비들을 누군가가 관리해야 한다. 단순히 서버 하드웨어만 필요한 게 아니다. 인터넷 또한 깔려 있어야 할 것이고....신경써야 할 게 한두가지가 아니게 된다.

이러한 문제를 해결하기 위해 Cloud 서비스들이 등장했다. 우리가 많이들 사용하는 AWS, Azure등의 클라우드 서비스는 Iaas(Infrastructure as a Service) 라고 부른다. EC2는 많이들 사용 해 보았을 것이다.

이것 만으로는 Serverless라고 할 수 없다. 우리는 물리적인 서버를 사내에 배치하고 있지 않을 뿐 여전히 클라우드 상에서 컴퓨터는 돌아간다. AWS Elastic Beanstalk와 같은 PaaS(Platform as a Service) 제품들을 활용한다면, 그저 배포만 한다면 애플리케이션을 구동시킬 수 있는 플랫폼 까지 구축 된다.

하지만, 이런 플랫폼과 인프라가 구축 되어있다고 한 들 우리는 이러한 요소들에 대해 신경을 써야한다. EC2가 보장해주는 건 컴퓨터가 존재한다는 것. 장애가 발생했을 때 우리는 EC2에 직접 접속하여 해결해야 한다. 이런 문제를 해결하기 위해 BaaS, FaaS 제품들이 나타났다. 서버 내에 시스템이 어떤 상태인지, Auto scaling이 필요한 지 아무것도 신경쓰지 않아도 서비스를 운영할 수 있게 된 것이다.

BaaS

대표적인 예시로 Firebase가 있다. 백엔드 서버 애플리케이션을 개발할 때 단순히 코딩만 해서 문제가 해결된다면 참 좋겠지만, 실제로는 고려해야 할 게 한 두가지가 아니다. 유저의 수가 늘어남에 따라 대용량 트래픽을 어떻게 관리 할 것인지에 대한 생각도 해야한다. BaaS가 존재한다면, 개발에 요구되는 다양한 기능들을 API로 제공해준다. 즉 처음부터 끝까지 개발자가 설계하고 구축 할 필요가 없어지고 사용한 만큼의 비용만 지불하면, 코드만 신경쓰면 된다. 서비스가 커질 것을 대비하여 설계하는 데 머리를 복잡하게 쓸 필요가 없다는 것이다.

BaaS를 쓰면 이러한 복잡한 설계나 구축에 필요한 비용을 줄일 수 있다. 또한 서비스가 커짐에 따라 인프라를 확장시키는데 비용 또한 줄일 수 있다. 하지만 백엔드 로직들의 개발 방향에 제약이 생길 수 있다. BaaS 서비스에 맞춰줘야 하기 때문에 자유도가 떨어질 수 있다. RDBMS를 사용하는 서비스라면 상황에 따라 아주 복잡한 쿼리를 직접 사용해야 하는 경우도 있는데, 이런 상황에 대해 제약이 생길 수 있다. 또한 가격 문제도 발생한다.

FaaS

프로젝트를 여러 함수로 쪼개서 함수들을 사용하는 횟수만큼 비용을 내는 방식을 의미한다.
PaaS는 어떤 서버에서 프로그램이 계속해서 돌아가고 있지만 FaaS는 그야말로 사용할 때만 애플리케이션이 작동한다.

이 방식은 함수의 호출 정도에 따라 비용이 들기에 비용이 많이 절약되고 인프라 관리와 확장성과 관련 된 많은 문제들에 고려를 할 필요가 없어진다.

하지만 이 또한 FaaS 서비스에 많이 의존해야하고 함수 하나가 사용할 수 있는 자원에 제약이 크다는 문제가 있다. 프로그램이 서버에서 돌아가고 있는 상황이라면 프로세스에 메모리를 더 할당 해 줌으로써 해결 할 수 있는 문제를 여기선 그렇게까지 할 수는 없다는 단점이 존재한다.

Outro

서버리스 아키텍쳐는 분명 좋은 솔루션이 될 수 있지만, 서비스 제공 업체에 의존해야 한다는 큰 문제가 존재한다. 운영하는 서비스의 규모에 따라 다르겠지만, 서비스가 점점 커 질수록 결국엔 서버를 운영해야 하는 상황이 생길 수도 있다. 상황에 따라 유연하게 아키텍쳐를 결정하기 위해선 다양한 아키텍쳐에 대한 지식이 필수적이다.

지금까지 아키텍쳐 패턴에 대해 알아 보았다. 다음 주제는 메시지 큐, 브로커로 돌아오겠다.