What's serverless?

서버리스는 서버가 없는건 아니라고 한다.
그저 서버를 관리할 필요가 없다는것!

그냥 코드 배치만 하면 된다고 한다.
프로비저닝 하지 않는것을 의미한다!

Why AWS Lambda

Amazon EC2 를 보면 서버가 클라우드 안에있고 제한된 RAM,CPU,,,,
그리고 지속적으로 실행이괴고 서버를 스캐일링 해줘야한다.

하지만 Amazon Lambda 는 가상의 함수로 관리할 서버가 없다
짧은 실행시간으로 제한시간이 있고 사용하지 않으면 실행이 되지 않는다.

Benefits of AWS Lambda

일단 가격 측정하기가 쉽다. 그냥 Lambda 가 실행된 시간 만큼 청구가 된다고한다.
AWS 전체 서비스와 통합이 가능하고
AWS Cloudwatch 로 쉬운 관리도 된다.
Ram 을 올리면 CPu 성능도 향상이 된다.

AWS Lambda Integrations Main ones

Serverless Thumbnail creation

먼저 S3 에 이미지가 삽입되면 이벤트가 발생하고 lambda 를 실행시키게 된다.그렇게 썸네일은 S3에 넣어지게 되고 Metadata 는 DynamoDB 에 들어가게 된다.

Lambda 때문에 기능이 자동화 S3에 새 이미지와 앱이 생성되는 이벤트에 대한 반응형 Archi 를 얻게된다.

Serverless CRON job

CRON 은 EC2 Instance 에서 작업을 생성한다고 한다...
근데 가상서버에서 실행해야하는데 아무것도 안하고 있으면 시간 낭비라고 한다.
이럴때 CloudWatch Event 를 사용해서 1시간마다 lambda 를 실행시켜서 일을 시켜주면 된다고 한다.

Lambda SnapStart

Lambda 의 함수 성능 높이기 위한 lambda 의 기능이라고 한다. 최대 10배 높일수 있다고 한다.
이게 활성화 되어있으면 기존에 lambda 가 실행되고 초기화하지않고 바로 실행시키고 종료가 된다. 그래서 실행속도가 좋다고 한다.

CloudFront Functions & Lambda@Edge Use Cases

웹사이트 보안 및 개인정보 보호
엣지에서 동적 웹 애플리케이션
검색 엔진 최적화 (SEO)
다양한 오리진과 데이터 센터 간 지능적인 라우팅
엣지에서의 봇 완화
실시간 이미지 변환
A/B 테스팅
사용자 인증 및 권한 부여
사용자 우선 순위 지정
사용자 추적 및 분석

CloudFront Functions

Javascript 로 작성된 함수라고 한다.
그리고 Viewer 요청 및 응답 변경에 사용되고는 한다.
Viewer Request 랑 Viewer Response 가 있는데
Viewer Request 는 viewer 로 부터 요청을 받은 다음에 Viewer 요청을 수정할수 있고
Viewer Response 는 응답 보내기 전에 Viewer 응답 수정 가능한것이다.

CloudFront 는 고성능, 고확장성이 필요할때 뷰어 요청,응답에 사용된다고 한다.

Lambda@Edge

NodeJS 와 Python 으로 작성된 Lambda 함수이다.
모든 CloudFront 요청 및 응답 변경에 사용된다고 한다.
여기서 ViewerRequest,Viewer Response 두개 다 있지만
Origin Request,Origin Response 라는 개념도 추가가 된다.
Origin Request 는 Origin 에 요청을 전송하기 전에 수정 가능한것이고
Origin Response 는 Origin 에서 응답 받은 후에 수정하는것이다.

CloudFront Functions vs Lambda@Edge

Use Case

CloudFront Function은 캐시 정규화,헤더수정,URL 재작성,,요청인증에 쓰인다

Lambda@Edge 는 더 긴 실행시간,다른 AWS service 에 엑세스, 하기 위한 AWS SDK ,,,외부 서비스에 대한 네트워크 엑세스를 통해 대규모 데이터 통합 수행,,,

Lambda by default

Lambda 는 시작하면 VPC 외부에서 시작한다.
그래서 VPC 안에 있는 resource 에 접근을 하지 못한다.

Lambda in VPC

그래서 VPC 안에서 Lambda 를 시작하면 된다.

Private subent 에 ENI 를 만들어서 접근을 가능하게 해준다.

Lambda with RDS Proxy

만약 람다가 db에 직접적으로 접근을 하고 그것들이 많아저 버리면 DB 의 Load 는 당연하게 상승될것이다.그래서 Proxt 를 두어서 모든 연결을 Proxy 로 주어서 결국 연결은 하나인것처럼 속이는것이다.

RDS Proxy 역시 Public Access 가 가능하지 않기 때문에 Lambda 를 VPC 내에 접근가능ㅎ ㅏ게 해야한다.

Amazon DynamoDB

완전 관리형 데이터베이스
다중 AZ간의 데이터 복제를 통해 고가용성 제공
NoSQL - 관계형 데이터베이스가 아님. 트랜잭션 지원
대규모 워크로드로 확장 가능한 분산 데이터베이스
성능이 빠르고 일관성을 유지함 (한 자릿수 밀리초의 성능)
보안, 인가 및 관리를 위해 IAM과 통합되어 있음
저렴한 비용. 오토 스케일링 기능 제공
유지 관리나 패치 작업이 필요 없으며 항상 사용 가능함
Standard 및 Infrequent Access (IA) 테이블 클래스 지원

또한 DynamoDB 는 DB를 만들필요없다 이미 DB가 존재하는 서비스이다.

Read/Write Capacity Modes

Provisioned Mode,On-Demand Mode 가 있다

Provisioned Mode 는 미리 용량을 관리하는것이다.
또한 미리 계획해도 ASG 사용이 가능하고
비용절감 원할떄 적합하다

On-Demand Mode 는 워클드에 따라 자동으로 확장한다.
예측할수 없는 작업량이나 급격한 증가가 예상되는 경우에 적합하다.

DynamoDB Accelerator(DAX)

고가용성의 완전 관리형 무결절 인메모리 캐시이다.

읽기 많을떄 DAX Cluster 생성하고 데이터 캐싱,읽기 혼잡 해결한다고 한다.

DynamoDB Accelerator(DAX) vs ElastiCache

DAX 는 쿼리와 스킨 캐시를 처리하는데 유용하다고 한다.
대용량 연산을 저장할떄 유용하다.

집계결과 저장은 ElastiCache 가 좋다고 한다.

Stream Processing

스트림 처리는 데이터의 변경 사항을 실시간으로 감지하고 처리하는 기술이다.

실시간으로 변경 사항에 대응하기 (사용자에게 환영 이메일 보내기)
실시간 사용 분석
파생 테이블 삽입
리전 간 복제 구현
DynamoDB 테이블 변경 시 AWS Lambda 호출

DynamoDB Stream
보존 기간: 24시간
소비자 수 제한
Lambda 트리거 또는 DynamoDB Stream adapter 사용 가능

Kinesis Data Stream
보존 기간: 1년
더 많은 소비자의 수
AWS Lambda, Kinesis Data Analytics, Kineis Data Firehose, AWS Glue Streaming ETL 등 사용 가능

DynamoDB Global Tables

여러 리전 간에 복제가 가능한 Table 이다.

양방향 복제를 한다고 한다.

DynamoDB - Time To Live(TTL)

만료 TimeStmap 가 지나면 자동으로 항목 삭제하는기능이다.

Session Data 저장이나 갱신되지 않은건 자동으로 삭제한다한다.

DynamoDB - Integratoin with Amazon S3

S3로 내보내기 (Export to S3) - PITR 기능 활성화해야 함
최근 35일 이내 어떤 시점으로든 테이블을 내보낼 수 있음
읽기 용량이나 성능에 영향을 주지 않음
데이터 분석 수행 가능
감사 목적으로 스냅샷 확보 가능
데이터를 다시 DynamoDB로 가져오기 전에 데이터 ETL 등 대규모 변경을 실행할 수 있음
DynamoDB JSON 또는 ION 형식으로 내보냄

S3에서 가져오기 (Import from S3)
S3에서 CSV, DynamoDB JSON 또는 ION 형식의 데이터를 가져와 DynamoDB에 새로운 테이블로 임포트
쓰기 용량을 소모하지 않음
임포트 중 발생하는 오류는 모두 CloudWatch Logs에 기록됨

AWS API Gateway

Client 가 직접 Lambda 함수를 지연호출 할수 있게 할려면 클라이언트가 IAM Permission 있어야한다.

AWS Lambda + API Gateway: 완전 서버리스 애플리케이션이 구축되므로 인프라 관리 필요 없음
WebSocket 프로토콜 지원: 양방향 통신 가능
API 버전 관리 (v1, v2 ...)
환경 관리 (dev, test, prod ...)
보안 관리
API 키 생성, 요청 스트롤링
Swagger/OpenAPI와 같은 공통 표준을 사용하여 신속히 API를 정의하여 가져올 수 있고 Swagger/OpenAPI로 내보낼 수도 있음
요청 변환 및 유효성 검사
API 응답 캐시

Integrations High Level

Lambda Function,HTTP,AWS SErvice 와 연동이 된다.

이렇게 API Gateway 를 통해서 AWS service 를 외부에 노출 시킨다.

Endpoint Types

• Edge-Optimized(Default)

전세계 누구나 APi Gateway 로 access 가능하다.

• Regional

모든 사용자는 API Gateway 를 생성한 리전과 같은 리전에 있어야한다.

• Private

VPC 엔드포인트(ENI) 를 사용해서 VPC 내에서만 엑세스 할수 있다.

Security

User Authentication through
IAM Roles (내부 애플리케이션에서 유용)
Cognito (외부 사용자를 위한 신원 확인 - ex. 모바일 사용자)
사용자 지정 권한 부여 (자체 로직 실행)

Custom Domain Name HTTPS security through integration with AWS Certificate Manager (ACM)
Edge-Optimized 엔드포인트를 사용하는 경우 인증서는 us-east-1에 있어야 함
egional 엔드포인트를 사용하는 경우 인증서는 API Gateway 리전에 있어야 함
Route 53에서 CNAME 또는 A-alias 레코드를 설정하여 도메인 및 API Gateway를 가리키도록 해야함

AWS Step Functions

Serverless WorkFlow 를 시작적으로 구성할 수 있는 기능이다.
승인을 해야만 진행되는 단계를 설정할 수 있다.

Amazon Cognito

웹 및 모바일 앱과 상호작용 할수있는 자격증명을 부여한다.

Cognito User Pools(CUP) - User Features

Serverless database 를 생성한다.
간단한 로그인 가능하고
이메일 , 휴대폰 전화번호로 인증가능하고
다중요소인증이 된다.