[AWS] 서버리스 개념과 lambda 아키텍처

클라우드 기반 개발 1주차

서버리스

개발자가 서버를 관리 할 필요 없이 애플리케이션을 빌드하고 실행 할 수 있도록 하는 클라우드 네이티브 개발 모델.

서버를 관리 할 필요가 없다 -> 트래픽에 따라 사용자가 직접 서버의 가용량을 증/감 시킬 필요가 없다.

서버리스 종류

1. FaaS (Fuction as a Service)

   함수를 서비스로 제공. 일반적인 서버가 아닌 클라우드 제공업체가 관리하는 클라우드 컨테이너에서 작동.

   코드를 함수 단위로 저장, 요청이 들어오면 대기 상태의 서버가 함수를 실행.

   비용은 함수 호출 횟수에 따라 청구

EX) AWS Lambda, MS Azure Fuction.

1. Baas (Backend as a Service)

백엔드 개발에 필요한 여러 기능을 API 로 제공하는 서비스.

클라우드 제공업체가 인증 서비스와 추가 암호화, 클라우드 액세스 가능한 데이터베이스, 상세한 데이터 사용량 모니터링 등을 ‘완성해’ 제공.

EX) Firebase

서버리스 아키텍처를 왜 사용 할까?

1. 서버 관리가 필요 없다.

   서버리스 아키텍처 서비스 제공자에게 서버 관리 위임. 개발자는 개발 로직(서비스 품질)에만 집중 할 수 있다.

2. 합리적인 가격

   실제 사용량 (예를 들어 함수 호출 횟수) 에 대해서만 비용 청구.

3. 높은 가용성과 유연한 확장

   요청이 들어올때만 서버 실행되고, 요청에 따라 유연하게 scaling 이 되기 때문에.

CustomBackend VS Baas

결론부터 얘기 하자면, 각각 이점을 가지는 상황이 있기 때문에 내가 처한 상황에 맞게 사용하는 것이 현명.

1. CustomBackend
   • Baas 가 제공하지 않은 고유한 기능을 사용 해야 할 때,
   • 오랜 기간동안 지원 해야 하는 서비스 일 경우
   • 더 많은 사용자를 유치할 수 있는 잠재력 있는 서비스를 만들고 싶을 경우
2. Baas
   • MVP(Minimum viable product) 같이 가능한 빨리 사용자의 피드백을 받는것이 중요한 상황이거나
     출시기간을 단축하고 개발비용을 절감 해야 할때 고려.
   • upscaling 이 필요하지 않은 어플리케이션.
   • Baas 공급자가 도입한 수정 사항이 어플리케이션에 크게 영향을 미치지 않을 때 고려.

BaaS 의 한계점

1. 서비스가 BaaS 제공자에 의존적 이게 된다. (BaaS 정책이 바뀌거나 공급에 문제가 있을 경우, 서비스에 직접적인 피해.)
2. 디버깅이 어렵다. (그에 반해 CustomBackend 는 코드의 작성자이기 때문에 디버깅 수월.)
3. BaaS 의 목표는 다양한 웹 및 모바일 환경에서 작동하는것. 그말은

   자신의 서비스에 필요한 기능을 제공하는 API 가 없을 수도 있고,
   자신의 서비스가 요구하는 기능의 코드를 작성 하는 것보다 성능이나 유연성이 떨어질 수 있다.

서버리스 한계점 정리

1. Cold-Start

   상시 대기가 아닌 요청이 들어올때마다 실행 되기 때문에 response 가 느림 상대적으로.

2. 제공 플랫폼에 대한 의존성 (종속성)
3. 표준 프레임워크 없음 : 클라우드 제공자가 제공하지 않는 기능은 쓸 수 없다.
4. 긴 작업에 대한 비효율성

   서버리스는 함수가 1회 호출 될 때 사용할 수 있는 메모리 및 시간에 제한이 있기 때문.
   작업이 끝나지 않은채로 해당 시간이 지나면 작업이 끝날때까지 일정 시간마다 계속 함수를 다시 호출하므로 굉장히 비효율적이다.

5. 보안

   데이터를 사내에서 직접 관리하는것이 아니기 때문에 민감한 데이터에 관해서는 우려가 생긴다.

lambda 아키텍처