음악추천챗봇0. 왜 Serverless아키텍쳐인가? Lambda의 장단점-동시성

지금까지 한 작업은 이렇다.

1. Front - 카카오챗봇 기획작업 완료

2. Back - 스포티파이 API 파악 완료 

이번엔 인프라를 구성해볼까 한다. 프론트와 백단을 이어줄 틀을 잡아준다라고 할까.

그전에 개념적인 공부부터 진행해보려고한다. 솔직히 진짜 정성들여서 썼다..

On-premise ->IaaS -> PaaS -> SaaS 

우선, 서버리스 아키텍쳐의 개념을 알기 전에 서버리스 아키텍쳐가 나타나게 된 배경부터 보고자한다

전체적인 일반적인 온프레미스 구성방식부터을 생각해보자.  

일반적인 '전산실'을 생각하면 된다.  

네트워크-스토리지-서버-가상화-운영체제-미들웨어-런타임-데이터-앱까지 일일이 물리적으로 직접 다 관리한다. 

하지만 물리적 장비를 모두 다 관리하고 구축한다는 점에서 비용이 많이 든다. 

 

그러다 클라우시대가 되었다. 이제 어느수준까지 가상화하는지에 따라  클라우드컴퓨팅 모델을 구분하게 되었다. 

다음으로, AWS같은 클라우드로 인프라자원만 가상화하는 방식이다. IaaS(Infra as a Service)다. 

모든 물리적 장비까지 다 구성하지 않고 인프라자원 즉, 네트워크/스토리지/서버까지는 클라우드를 쓰는 것이다.  

예를 들면 AWS의 VPC로 네트워크, RDS로 스토리지, EC2로 서버를 구성하는 것이다.

이렇게 되면 네트워크,스토리지,서버는 구축이 되어 있어서,

서비스가 돌아갈 개발/운영환경을 관리/개발하고 배포하면 서비스가 가능하다. 

 

다음으로, 개발환경까지 가상화하하는 방식이다. PaaS(Platform as a Service)라고 한다. 

인프라자원뿐만 아니라 개발이나 운영환경 등 OS/미들웨어/런타임까지 클라우드를 사용하는 것이다. 

서비스마다 여러가지 환경에서 서비스를 개발하고 운영할 수 있게 된다. 

IaaS와 차이점이 조금 헷갈리는데 
IaaS는 가상머신만 제공한다면, paas는 가상머신위에 java나 node.js같은 런타임을 미리 깔아놓고 제공한다. 

이렇게 되면 이미 인프라부터 환경까지 하나의 플랫폼처럼 세팅이 되어 있어

소스코드를 이 환경에 배포하면 서비스가 가능하다. 

 

다음으로, 소트프웨어 자체가 가상화되어 서비스로 제공하는 방식이다. Saas(Software as a service)다.

인프라자원+개발/운영환경 +서비스배포까지 소프트웨어를 가상화하여 제공한다. 

직접 다운로드하거나 설치할 필요도 없는 완제품이라는 이야기이다. 즉, 클라우드를 통해 제공되는 sw라고 볼 수 있다. 

그래서 로직이 동작할 백엔드 소스코드를 짜기만 하면 된다. 배포도 필요가 없다. 이 자체가 서비스가 되기 떄문이다. 

예를 들어 구글의 gmail, 구글드라이브과 같은 구글앱들이다. 이미 다 만들어진 소프트웨어로 이용하고 있다.

데이터베이스를 구축하데 오랜시간이 걸리는 저장소와 달리 구글드라이브를 사용하기만 하면 정보를 관리할 수 있다

---

Serverless 아키텍쳐

서버리스는 실제로 서버가 없는게 아니라 '서버가 없는것 처럼' 느껴진다고 표현할 수 있겠다. 

즉, 서버를 신경쓰지 않아도 서비스를 할 수 있는 기술이라고 정의할 수 있다. 

서버리스 아키텍쳐는 두가지로 나뉜다. BaaS와 FaaS이다. 

백엔드 기능을 API로 제공해주는 Bass(Backend as a service)이다.

대표적으로 google의 firebase가 있다.

안드로이드 앱개발시 파이어베이스에서 제공해주는 sdk코드를 넣기만 하면 

데이터베이스나 sns연동 등 필요한 백엔드 기능을 어떠한 설정없이 사용할 수 있다. 

그래서 서버구성없이, DB설계없이, 스토리지생성없이 빠르게 기능을 구현할 수 있고, 자동으로 확장도 해준다. 

 

다음으로, 함수기반으로 동작하는 Faas(Function as as Service)라고 한다. 

프로젝트를 여러개의 함수로 쪼개서 비즈니스 로직을 수행하는 함수를 만들고,

그 함수가 실행되는 횟수와 시간만큼 비용을 내는 방식이다. 

특정이벤트가 발생했을떄 실행되기 때문에 주기적인 작업이 필요한 경우 사용하기도 한다. 또는 특정 URL로 들어오면 어떠한 작업을하게끔 할 수 있어서 API구성을 할 수도 있다.

PaaS와 차이점은 
PaaS는 전체앱을 배포하고 어떤 서버에서 앱이 24시간 돌아가고 있는 반면 
Serverless의 FaaS는 전체앱이 아닌 함수를 배포한다.
그리고 계속 실행되는게 아니라 특정이벤트가 발생했을때만 함수가 실행이 되고 작업을 마치면 종료된다. 

앞으로 AWS의 Lambda와 API Gateway를 사용해서 구성할 방식은 Serverless 아키텍쳐의 FaaS방식이다. 

 

단순히 람다에 백엔드 코드만 작성하여 배포하면 바로 서비스를 운영할 수가 있다. 

서버관리를 전혀 하지 않아도 된다. 그냥 개발만 하면 된다. 

서버가 어떤 사양으로 돌아가는지, 어떻게 늘려야하는지, 어떤 네트워크를 사용할지 고민할 필요가 없다. 

소스코드를 EC2에 배포해서 운영하는 상황과 비교해보자. IaaS방식이겠지. 
VPC/ELB/SG 등등 인프라를 자원을 구성해야한다. 
그리고 소스코드가 돌아갈 서버 ec2를 생성하려면,EC2의 사양, OS의 버전,
private한지 public한 네트워크인지,ec2가 죽으면 어떻게 autoscaling할지, ec2모니터링까지
관리하고 고민해야할게 많다.    

이런식으로 서버를 관리할 필요가 없는 클라우드 컴퓨팅 모델을 서버리스아키텍쳐라 한다.

 

드디어 본론이다...휴..

왜 Serverless 아키텍쳐를 사용하는가?  

Serverless 아키텍쳐의 FaaS방식의 장단점을 알아보았다.

나에게 가장 와닿는 최대의 장점은 '비용'이다. 

지금생각해보면 이전에 구성했던 뉴스레터 서비스는 Iass이다.

물론 인프라적인 부분을 학습하려고 진행하긴 했지만 그러다보니 인프라 구성/운영 비용 때문에 제한적이였다.

하지만 서버리스 아키텍쳐는 필요할때만 함수가 호출되어 처리한다는 점에서 비용이 훨씬 절약된다. 

두번째 장점은 '확장성'이였다.

서버리스로 구성하게 되면 인프라적인 구성작업은 신경 쓸 필요가 없다. 그래서 빨리 완성할 수 있다. 

그리고 다양한 트래픽에 유연하게 대응할 수 있다고 한다.

보통 트래픽이 많이들어오면 오토스케일링으로

cpu사용량과 네트워크 처리량에 따라 서버의 개수가 자동으로 늘어난다. 

 

하지만 서버리스로 구성하게 되면 즉, FaaS방식인 람다로 구성하게 되면

오토스케일링처럼 조건에 따라 확장이 되는 것이 아니라 조건없이 확장된다. (물론 내 서비스는 그럴리가 없겠지만) 

헐 어떻게 확장하는건데?

'컨테이너'라는 개념으로 스케일링한다.
가상os가 새로생성되는 방식이 아니라 os위에 독립적인 하나의 프로그램을 생성한다고 한다. 
다시말해 꺼져있는 컴퓨터를 새로키는게 아니라 켜져있는 컴퓨터에 프로그램을 하나 키는 방식이라 훨씬 가볍다. 

함수가 1초에 1개가 호출이 되면 1개가 호출이 되는 것이고, 1000개가 호출이 되면 1000개가 호출이 된다. 

이를 두고 기본적으로 1000개의 동시성 제한이 있다고 표현한다. 

람다의 동시성(Concurrency)

동시성이란 특정시간에 함수가 제공하는 요청의 수이다. 
함수가 호출되면 람다는 함수의 인스턴스를 할당하여 이벤트를 처리하고, 실행이 끝나면 다른요청을 처리한다. 
만약 요청을 처리하는 와중에 함수가 다시 호출이 되면 다른 인스턴스가 할당이 되어 동시성이 증가한다.

 

그렇다면 단점은? 리소스제한 : 메모리(최대 1500MB), 처리시간 (최대300초, 즉 15분)  

아무래도 직접 서버에서 돌리는 것보다 부족한 스펙이다. 

모든 코드를 함수로 쪼개서 작업하다보니 함수에서 사용할 수 있는 자원에 제한이 있다. 

하나의 함수가 한번 호출될때 AWS에서는 최대 1500MB의 메모리까지 사용이 가능하며, 처리시간은 최대 300초이다. 

그러다보니 웹소켓같이 계쏙 켜놔야하는 서비는 람다로 구성할 수가 없다. 

 

두번째 단점은 '로컬데이터'불가능

함수는 Stateless이다. 상태를 저장하고 기억하지 않는다. 

그러다보니 데이터를 로컬스토리지에서 읽고 쓸수가 없다.

그 대신 aws에서 제공하는 스토리지들을 연결할 수 있다. s3라 dynamodb,rds 등 api로 가져 올 수 있으니까.

 

마지막으로 '콜드 스타트'부분이다. 

람다하면 늘 한계로 나오는 부분이다. 하지만 아직 실무경험이 부족한 나로는 이론적으로만 이해하고 있다.

실제로 콜드스타트가 생기면 크게 문제가 되는지 직접 경험해보지 못했다.

그래서 얼마나 실무에 영향이 있는지도 궁금하기도 하고, 이러한 성능의 중요성을 아직 체감하지 못하고 있어 아쉽다.  

콜드스타트가 왜 생기는걸까? 람다함수 동작원리

람다함수가 하나 동작하기 위한 라이프사이클은 아래와 같다. 
소스코드 다운로드 -> 실행환경구성 (컨테이너 시작) -> 런타임 동작 -> 코드실행
위에서도 말했듯이 람다가 실행하기 위한 환경을 구성하기 위해 컨테이너가 띄워진다. 

 

하지만 항상 컨테이너가 준비되어 있는게 아니다.

아까도 말했듯이 람다는 24시간 늘 켜져있는 컴퓨팅리소스가 아니다. 필요할때만 호출되서 사용이 된다.그러다보니 

컴퓨팅제공업체에서는 자원을 효율적으로 관리하기 위해서

이러한 컨테이너를 항상 활성화하고 있지 않다. 컴퓨팅 파워를 꺼두고있는 것이다.

그렇다고 해서 다시 사용하려고 할떄 별도의 사용자 액션이 필요한 것은 아니다. 

이벤트가 트리거되지 않은 상태에선 서버는 그저 잠시 '절전모드'가 되는 것이다.

콜드스타트 상태

그래서 오랫동안 꺼져있는 람다서버가 트리거에 의해 호출이 되면

서버가 켜지고 부수적인 세팅이 되기까지 적지않은 시간이 소요된다. 이 상태가 바로 '콜드스타트'이다.  

즉, 함수를 처음 호출할떄나 업데이트 된 후 실행할떄

다시 컨테이너를 시작하기 위해, 실행환경을 구성하기 위해 어쩔수없이 발생하는 딜레이(delay) 를 의미한다. 

콜드스타트를 해결하는 방법은?

1. 람다를 계속 호출해준다.

항상 컨테이너가 준비되어 있게 하도록 람다를 지속적으로 호출해는게 가장 좋다고 한다. 

즉, 일정량의 요청이 5분마다 또는 15분마다 꾸준히 들어와 람다함수를 호출하게 된다면 컨테이너가 계속 떠있게 된다. 

하지만 호출이 될때마다 비용이 산정되는 방식이기 때문에 그만큼 비용이 더 들수 있다고 한다. 

또 요청이 너무 빈번하게 발생할바엔 그냥 ec2를 쓰는게 나을 수도 있다. 

 

2. 람다의 메모리를 늘려 스펙을 높인다. 

메모리를 더 할당할 수록 인스턴스 사양이 올라간다고 한다.

그래서 처리속도가 빨라져 소요되는 요청이 처리되는 시간이 줄어든다.. 

물론 또 그만큼 비용이 증가할테지만..오히려 처리되는 시간과 요청수가 줄면 비용이 줄어들지도 모른다.

 

3. '프로비저닝된 동시성'을 활성화 한다.

콜드스타트는 결국 꺼져있는 상태가 문제가 되는 것이다.

그렇면 미리 켜두면 되지 않을까? 이를 warm start 한다고 표현한다.이를 도와주는게 프로비저닝된 동시성이다. 

프로비저닝된 동시성을 활성화하면

람다가 요청된 수의 '실행환경을 초기화'한다. 그래서 함수의 호출에 바로 응답할 수 있도록 미리 준비하는 것이다.

이렇게 따로 '프로비저닝된 동시성'을 선택할 수 있는 구성옵션이 있다.

다만 또 이 서비스를 활성화하는만큼 비용이 든다..비용..비용..그놈의 비용..😭

 

결론적으로 아래의 단점은 나의 서비스는 (매우 작고 소중하기에) 크게 제한이 되는 요소가 아니다.

그리고 매우 저렴하고(거의무료료) 사용할 수 있는 장점으로

서버관리가 필요하지 않고 개발에만 집중할 수 있는 환경을 구성할 수 있어서 lambda를 선택했다.

 

 

출처

서버리스 ,bass와 fass  : https://velopert.com/3543

서버리스, 람다의 장단점 : https://mayajuni.github.io/2020/01/17/Lambda%EB%A5%BC-%EC%84%A0%ED%83%9D%ED%95%9C-%EC%9D%B4%EC%9C%A0/

Serverless를 선택한 이유(Lambda, Altas)

콜드스타트 : https://medium.com/harrythegreat/aws-lambda%EB%A5%BC-%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-%EC%A0%84-%EC%95%8C%EC%95%98%EC%9C%BC%EB%A9%B4-%EC%A2%8B%EC%95%98%EC%9D%84%EA%B2%83%EB%93%A4-788bd3b3bdd2
동시성제한 : https://kimjingo.tistory.com/75

AWS Lambda를 시작하기 전 알았으면 좋았을것들

프로비저닝된 동시성 활성화하기(aws) 
https://aws.amazon.com/ko/blogs/korea/new-provisioned-concurrency-for-lambda-functions/