서버리스 아키텍처란?

• 애플리케이션이 필요할 경우에만 시작
• 이벤트가 구동을 위한 애플리케이션 코드를 트리거하면 퍼블릭 클라우드 공급업체가
  신속하게 해당 코드에 대한 리소스를 할당
• 코드 실행이 종료되면 비용도 청구되지 않음
• 운영 체제 및 파일 시스템 관리, 보안 패치, 부하 분산, 용량 관리, 스케일링, 로깅, 모니터링과 같은 일상적인 태스크를 모드 클라우드 서비스 제공업체에 이관
• 완전한 서버리스 애플리케이션은 물론, 일부는 서버리스로 일부는 전통적인 마이크로 서비스
  구성 요소로 이루어진 애플리케이션을 구축

BaaS (Backend Service)

애플리케이션 개발에 있어서 필요한 다양한 기능들을 API로 제공해 줌으로서, 필요한 기능을 쉽고 빠르게 구현 할 수 있게 함

1. 개발자의 생산성을 높이고 운영 비용을 줄일 수 있음
2. 인프라를 명시적으로 설명할 필요를 줄여줌으로써 DevOps 도입을 지원
3. 3rd party Baas 오퍼링의 모든 구성요소를 통합해 애플리케이션 개발을 간소화
4. 컴퓨팅 시간에 대해 비용을 지불하기 때문에 운영 비용이 낮아짐

장 / 단점

• 장점
  1. 개발 속도가 매우 빠름
  2. 개발 비용이 매우 저렴함
  3. 서버가 필요 없고, 기반 시설을 관리할 필요가 없음
• 단점
  1. 커스텀 코딩에 비교하여 낮은 유연성
  2. 커스텀 백엔드와 비교하여 낮은 레벨의 맞춤화
  3. 비개방형 소스 플랫폼을 위한 벤더 종속

FaaS (Function as a Service)

FaaS는 프로젝트를 여러 개의 함수로 쪼개서, 매우 거대하고 분산된 컴퓨팅 자원에 준비해둔 함수를 등록하고, 이 함수들이 실행되는 횟수 만큼 비용을 내는 방식

PaaS와의 주요 차이점

• 서버 시스템에 대해서 신경 쓰지 않아도 된다는점이 Paas와 유사
• PaaS의 경우엔, 전체 애플리케이션을 배포하며, 일단 어떠한 서버에서 당신의 애플리케이션이 24시간동안 계속 돌아가고 있음
• 반면 FaaS는, 애플리케이션이 아닌 함수를 배포하며, 계속 실행되고 있는 것이 아니라
  특정 이벤트가 발생 했을 때 실행되며, 실행이 되었다가 작업을 마치면 종료됨

장 / 단점

• 장점
  • 비용: 필요할 때만 함수가 호출되어 처리되며 비용이 절약됨
  • 인프라 관리: 네트워크, 장비 등에 대한 구성 작업을 신경 쓰지 않아도 됨
  • 인프라 보안: OS 업데이트, Meltdown 취약점 보안 패치 등을 신경 쓰지 않아도 됨
  • 확장성: 특정 조건에 따라 자동으로 확장되는 것이 아니라 자동 확장
• 단점
  • 제한: 함수에서 사용할 수 있는 자원에 제한이 있음
  • FaaS 제공사에 강한 의존: AWS, Azure, Google 등 FaaS 제공사에 강한 의존

AWS Lambda란?

AWS Lambda는 서버를 프로비저닝 또는 관리하지 않고도 모든 유형의 애플리케이션 또는
백엔드 서비스에 대한 코드를 실행할 수 있는 이벤트 중심의 서버리스 컴퓨팅 서비스

• 인프라를 프로비저닝하거나 관리하지 않고 코드를 실행
• 어떤 규모에서든 코드 실행, 요청에 자동으로 응답
• 사용하는 컴퓨팅 시간에 대해서만 요금을 지불
• 함수 메모리 크기로 코드 실행 시간 및 성능을 최적화

사용 사례

대규모 데이터 처리 → 필요한 용량으로 코드를 실행
대화형 웹 및 모바일 백엔드 → 다른 AWS 서비스와 결합하여 안전하고 안정적이며 확장 가능한 경험 생성
강력한 기계 학습 인사이트 지원 → 기계 학습 모델에 제공하기 전 데이터 전처리
이벤트 중심의 애플리케이션 생성 → 분리된 서비스 사이에서 손쉬운 통신을 위해 이벤트 중심의 함수를 구축

주요 개념

함수

코드를 실행하기 위해 호출할 수 있는 리소스

트리거

Lambda 함수를 호출하는 리소스 또는 구성
함수 및 이벤트 소스 매핑을 호출하도록 구성할 수 있는 AWS 서비스가 포함

이벤트

처리할 Lambda 함수에 대한 데이터가 포함된 JSON 형식 문서

# 날씨 데이터

{
 "TemperatureK": 281,
 "WindKmh": -3,
 "HumidityPct": 0.55,
 "PressureHPa":1020
 }

실행 환경

실행 환경은 Lambda 함수를 위한 안전하고 격리된 런타임 환경을 제공
함수를 실행하는 데 필요한 프로세스와 리소스를 관리

명령 세트 아키텍처

명령 세트 아키텍처에 따라 Lambda가 함수를 실행하는 데 사용하는 컴퓨터 프로세서의 유형이 결정

• arm64 - AWS Graviton2 프로세서에 사용되는 64비트 ARM 아키텍처
• x86_64 - x86 기반 프로세서에 사용되는 64비트 x86 아키텍처

배포 패키지

• 함수 코드 및 종속 항목이 포함된 .zip 파일 아카이브
• Open Container Initiative(OCI) 사양과 호환되는 컨테이너 이미지

런타임

실행 환경에서 실행되는 언어별 환경을 제공
컨테이너 이미지의 경우 이미지를 빌드할 때 런타임을 포함

Layer

Lambda 계층은 추가 코드 또는 기타 컨텐츠를 포함할 수 있는 .zip 파일 아카이브
계층에는 라이브러리, 사용자 정의 런타임, 데이터 또는 구성 파일이 포함

API 게이트웨이란?

요청을 적절한 서비스로 라우팅하고 요청자에게 응답을 다시 보내는 기능을 담당
REST 및 WebSocket API를 생성, 게시 유지, 모니터링 및 보호하기 위한 AWS 서비스

• 백엔드 HTTP 엔드포인트, AWS Lambda 함수 또는 기타 AWS 서비스를 노출하기 위한
  RESTful API의 생성, 배포 및 관리
• AWS Lambda 함수 또는 기타 AWS 서비스를 노출하기 위한
  WebSocket API의 생성, 배포 및 관리
• 프론트 엔드 HTTP 및 WebSocket 엔드포인트를 통해 노출된 API 메서드 호출
• 상태 저장(WebSocket) 및 상태 비저장(HTTP 및 REST)API에 대한 지원
• 변경 사항을 안전하게 롤아웃하기 위한 Canary 릴리스 배포
• API 사용 및 API 변경에 대한 CloudTrail 로깅 및 모니터링
• 경보 설정 기능을 포함한 CloudWatch 액세스 로깅 및 실행 로깅
• AWS CloudFormation 템플릿을 사용하여 API 생성을 활성화할 수 있는 기능
• 사용자 지정 도메인 이름 지원
• 일반적인 웹 익스폴로잇으로부터 API를 보호하기 위해 AWS WAF와 통합
• 성능 지연 시간 파악 및 학습을 위해 AWS X-Ray와 통합

제공 API 유형

HTTP API

• 백엔드 HTTP 엔드포인트 또는 Lambda 함수와 통합된 라우팅 및 메서드의 모음
• 이 모음을 하나 이상의 스테이지로 배포
• 각 라우팅은 API Gateway에서 지원되는 고유의 HTTP 동사를 가진 API 메서드를 하나 이상 노출

REST API

• 백엔드 HTTP 엔드포인트, Lambda 함수 또는 기타 AWS 서비스와 통합되어 있는 HTTP 리소스와 메서드의 모음
• 이 모음을 하나 이상의 스테이지로 배포
• 애플리케이션 로직에 따른 리소스 트리로 정리
• 각 API 리소스는 API Gateway에서 지원하는 전용 HTTP 동사가 있는 API 메서드를 하나 이상 표시

WebSocket API

• 백엔드 HTTP 엔드포인트, Lambda 함수 또는 기타 AWS 서비스와 통합되어 있는
  WebSocket 경로와 경로 키의 모음
• 이 모음을 하나 이상의 스테이지로 배포
• API 메서드는 프론트 엔드 WebSocket 연결을 통해 호출
• 등록된 사용자 지정 도메인 이름과 연결

API 게이트웨이 구성요소

경로

• API Gateway에 있는 API 메서드의 퍼블릭 인터페이스로 파라미터와 본문을 정의

배포

• API Gateway API의 특정 시점 스냅샷
• 클라이언트가 사용할 수 있게 하려면 배포가 하나 이상의 API 단계와 연결되어야 함

스테이지

• API의 수명 주기 상태에 대한 논리적 참조
  (예: 'dev', 'prod', 'beta', 'v2')
• API 단계는 API ID와 단계 이름으로 식별

Rate Limit 알고리즘

• 서비스의 가용성을 유지하기 위해 클라이언트의 과도한 사용에 대한 보호가 필요
• 서비스를 보호해주는 수단으로 Rate Limit 알고리즘을 적용
  • 과도한 트래픽으로부터 서비스를 보호
  • Resource 사용에 대한 공정성과 합리성 유도
  • 트래픽 비용이 서비스 예산을 넘는 것을 방지
  • Rate에 대해 과금을 부과하는 Business Model로 활용

Leaky Bucket

네트워크로의 데이터 주입 속도의 상한을 정해 제어하고 네트워크에서 트래픽 체증을 일정하게 유지

Token Bucket

평균 유입 속도를 제한하고 처리 패킷 손실없이 특정 수준의 버스트 요청 허용

Fixed Window Counter

정해진 시간 단위로 Window가 만들어지고 요청 건수가 기록되어 해당 Window의 요청 건수가 정해진 건수보다 크면 해당 요청은 처리 거부

Token Bucket 알고리즘

1. 토큰은 정해진 비율로 토큰 버킷에 넣음
2. 버킷은 최대 n개의 토큰을 저장하며, 버킷이 가득차면 새로 추가된 토큰은 삭제되거나 거부
3. 요청이 들어오면 큐에 들어가며 유청을 처리하기 전에 토큰 버킷의 토큰을 획득해야 하며,
   토큰을 보유한 후에 요청이 처리되며 처리된 후에는 토큰을 삭제
4. 토큰 버킷은 토큰이 배치되는 속도를 기반으로 액세스 속도를 제어
5. 전송 횟수를 누적할 수 있으며, 버킷이 가득차면 패킷 손실 없이 토큰이 손실