[AWSCloudClubs] Serverless, Lambda, API Gateway, Elastic Beanstalk

Serverless

1. 서버가 없다는 의미보단, 개발자가 서버를 직접 관리할 필요가 없다는 의미를 담고 있다.
2. 서버가 대기상태에 있다가 function을 실행시켜서 처리하는 방식이다.
   1. 그래서 cold start 문제가 발생한다.
      1. cold start현상은 함수의 크기, 코드의 복잡성은 물론이고 사용하는 언어, 설정한 메모리에도 따라 다르게 나타난다고 한다. (역시나 파이썬이 1등)
      2. 메모리를 추가하면 그에 비례해 cpu 용량이 늘어나 사용가능한 전체 계산 성능이 향상된다.
      3. lambda snapstart : lambda가 함수를 초기화하고 초기화된 실행환경의 메모리 및 디스크 상태 스냅샷을 생성하고 암호화하여 캐싱한다. 그 결과 짧은 지연 시간으로 엑세스 할 수 있게 되는 것.
3. BaaS(Backend as a Service)
   1. 필요한 서비스를 미리 만들어진 백엔드 api로 지원
      1. 호출한 api수만큼 값을 지불한다.
   2. 서버를 개발하지 않아도 쉽게 서버 구축 가능
      1. 꽤나 달콤한 유혹인데… 그럼 그렇다고해서 서버를 개발할 줄 몰라도 구축이 과연 가능할까? 마침 사용자 인증 및 관리 기능도 제공한다고 하니, 직접 jwt 로그인 방식을 공부하며 고생했던 것을 떠올리며 얼마나 편할지/생산성이 올라갈지 비교해보아야겠다.
   3. 클라우드 공급자로부터 안정성을 보장받는다.
   4. ex : Firebase, AWS Amplify…
4. FaaS(Function as a Service)
   1. 이벤트에 반응하여(HTTP 요청, 데이터베이스 변경, 파일 업로드 등) 해당 함수를 저장소로부터 읽어와서 해당 함수 컨테이너/가상머신 생성 → 함수 실행하고 결과 반환/동작 수행
   2. 자동 확장 : 함수 호출 없으면 컨테이너/가상머신 알아서 삭제
   3. 그럼 container orchestrator와 어떤 점이 다를까? 궁금해졌다. 
   4. ex : AWS Lambda, Google Cloud Functions, Azure Functions…

Lambda

1. serveless 컴퓨팅 FaaS(Function as a Service)
2. Provisioning/관리할 필요없이 코드 실행 가능하다는게 큰 장점
   1. 완전한 자동화 : 자동확장, 자동 failure handling 등
   2. Provisioning : 사용자 요구에 맞게 시스템 자체를 제공하는 것
      1. 하드웨어 or 가상서버 자원 할당/운영체제 설치/필요한 소프트웨어 설치 (웹서버, 데이터베이스, 런타임 환경 등)/네트워크 설정/보안 설정(사용자 및 권한 관리, SSL 인증서 설치 등)/모니터링 및 로깅 설정
   3. 서버 관리의 복잡성을 줄이고 코드 작성과 비즈니스 로직에 집중할 수 있다.
3. 메모리/시간제한이 있어서 긴 시간을 요하는 작업(인공지능) 등은 EC2에서 하는게 좋다.
   1. 뒤집어 얘기하면 사이드프로젝트의 경우 api를 쏘는 게 우리밖에 없기 때문에 그럴 땐 유리하다는 것.
4. AWS의 다른 서비스와 연결지어 사용할 수 있다.
   1. aws Eventbridge(cloudwatch events) :
      1. cloudwatch에서 임계점이 다다르면 lambda호출해서 ec2 종료해달라고 하기, 사용자가 없는 밤시간엔 재워버리기 등등 가능할 듯
   2. s3에 값을 넣었을 때 등을 트리거로 호출하기
      1. 드롭박스 서비스 만들기 팀플 중인데, 썸네일을 만들 때 쓸 수 있을 것 같다.
         1. 그렇게되면 lambda함수를 비동기식으로 호출하는게 되는건지 다음의 블로그를 참고하면서 구현해보자.
         2. https://medium.com/awesome-cloud/aws-different-ways-to-trigger-aws-lambda-functions-understand-lambda-invocations-integration-other-services-7d8110028141

API gateway

1. 개발자가 쉽게 api발행할 수 있도록, 규모와 상관없이 유지관리/보호 할 수 있도록 해준다.
2. 백엔드 서비스와 api 사용자 사이에 위치하여 api 엔드포인트에 대한 http 요청을 처리하고 올바른 백엔드로 routing
3. HTTP API
   1. endpoint를 api gateway로 활용하여 http 요청을 통해 서버에 접근한다.
      1. http1.1일까? 궁금해졌다.
4. REST API
   1. CRUD 메서드 동작을 하는 API
      1. 그럼 http api와 어떤 차이가 있을까 궁금했다. 사실 실제로 더 많은 기능을 추가할 뿐 구분이 크게 되지 않는다고 한다.
   2. aws 내의 다른 서비스를 쓸 때에는 REST API가 더 적합하다
      1. 드롭박스 팀플에서 썸네일 만드는 기능을 api gateway와 lambda, s3를 이용할 예정이다. 그 때 확인해보아야겠다.
5. WebSocket API
   1. 클라이언트 앱과 백엔드 간의 양방향 통신 지원
   2. 채팅앱, 스트리밍 대시보드
      1. 음... 어떻게 지원한다는건지 아직은 잘 와닿지 않는다. websocket으로 스트리밍 대시보드를 어떻게 지원한다는건지... tcp socket programming했던 것과 어떤 차이가 있는지...

Elastic Beanstalk

1. lightsail처럼 완전관리형 PaaS(Platform as a Service)
   1. lightsail이 더 쉽고 안정적이므로, 간단한 애플리케이션 호스팅에 더 적합하다.
      1. 먼저 서비스로 배포했는데 어려워서 lightsail이 다시 출시된 것이라고 한다.
      2. lightsail은 auto-scailing이 안된다는 단점이 있다. 즉, 수동으로 인스턴스를 추가/제거해야 한다.
2. 다양한 언어/프레임워크 지원
3. 코드를 업로드 하면 보안, 버전관리, 로드밸런싱, 모니터링(cloudwatch), 배포 작업을 자동으로 처리해준다.
4. AWS AutoScailing, Elastic LoadBalancing 안 쓴다면 무료이다... ㄷㄷ 어케그러지 신기하다
   1. 클라우드 컴퓨팅 팀플같이 빨리 프로젝트를 배포해야하는 상황이라면 일단 lightsail이나 beanstalk으로 구성하고, 나중에 ASG, ELB를 공부하며 EC2로 리팩토링(?)해보는 것도 나쁘지 않을 것같다. DevOps? 오히려좋아 (맞나)