ysh2의 블로그

[AWS] Serverless 솔루션 아키텍처 토론

yunseohhe — Thu, 19 Dec 2024 16:08:55 +0900

Mobile application : MyTodoList

나의 할 일 목록이라는 모바일 애플리케이션을 만든다고 해보자.
우리가 하고자 하는 것은 다음과 같은 요구 사항을 가지고 있다.
- HTTPS 엔드포인트를 가진 REST API를 노출하고 싶다.
- 서버리스 아키텍처로 구축하고 싶다.
- 원하는 경우 사용자가 S3에서 자신의 폴더와 직접 상호 작용하여 데이터를 관리할 수 있다.
- 관리형 서버리스 서비스를 통해 사용자도 인증할 수 있어야 한다.
- 사용자들은 할 일을 쓸 수도 읽을 수도 있지만 대부분 읽는다.
- 데이터베이스 레이어는 스케일링이 가능해야 하고 읽기 처리량이 매우 높아야 한다.

Mobile app : REST API layer

첫 번째는 시작하는 것이다. 모바일 클라이언트가 있고 REST HTTPS 작업에 대해 이야기했고, 이를 위해 Amazon API Gateway를 사용해 보자.
현재 고전적인 서버리스 API 방식으로 수행하는 좋은 방법이다.
API Gateway는 기본적으로 서버리스 인프라를 스케일링하고 사용할 수 있도록 해주는 람다함수를 호출한다.
Lambda는 데이터베이스에서 저장하고 읽을 수 있어야 한다.
- 그러러면 확장성이 뛰어나고 서버리스인 데이터베이스여야 하는데 그것이 바로 'DynamoDB'이다.
위의 이미지에 백엔드로 DynamoDB가 있고, 일종의 인증 레이어도 진행될 것이다. 이를 위해 Amazon Cognito와 같은 서버리스 기술을 사용할 수 있다.
따라서 모바일 클라이언트는 Cognito에 연결하여 인증할 수 있다.
그런 다음 API Gateway가 Cognito를 사용하여 인증을 확인한다.

Mobile app : giving users access to S3

이제 사용자에게 Amazon S3 버킷에 대한 액세스 권한을 부여하려면 어떻게 해야 할까?
우리는 Amazon Cognito에 인증하는 모바일 클라이언트를 가지고 있으며 Cognito는 임시 자격 증명을 생성하여 이를 모바일 클라이언트에게 반환할 수 있다.
자격증명을 통해 모바일 클라이언트는 S3에서 파일을 저장하고 검색하 수 있으며 S3에서 자신만의 공간에 액세스 할 수 있다.

Mobile app : caching at the API Gateway

이제 앱이 스케일링되기 시작하며 더 많은 사용자를 확보하기 시작한다.
패턴을 살펴보면 읽기 처리량이 매우 높다는 것을 알 수 있다.
우리는 많은 RCU를 가지고 있고 할 일 목록은 별로 변하지 않는다.
기본적으로 읽기 처리량을 향상시키고 전반적인 비용을 줄이기 위해 이 아키텍처를 어떻게 변경할 수 있을까?
- 할 수 있는 일은 DAX를 캐싱 레이어로 사용하는 것이다.
- 위의 이미지 처럼 DynamoDB 직전에 DynamoDB DAX를 사용한다.
기본적으로 캐싱 레이어가 있고 현재 너무 많은 읽기를 수행하고 있기 때문에 읽기는 DAX에 캐시된다. 따라서 DynamoDB에는 읽기 용량 단위가 많이 필요하지 않는다.
많은 읽기가 캐시되기 때문에 전체적으로 비용이 절감될 수 있으며 서버리스 방식으로 아키텍처를 지속적으로 개선할 수 있는 좋은 방법이다.

In this lecture

기본적으로 HTTPS, API Gateway, Lambda 및 DynamoDB를 활용하는 고전적인 서버리스 REST API 아키텍처를 위에서 살표보았다.
그런 다음 Cognito를 사용하여 임시 자격 증명을 생성했는데 이를 통해 제한된 정책이 있는 S3 버킷에 액세스 할 수 있다.
앱에 Cognito를 사용하면 DynamoDB 또는 Lambda에 직접 액세스 할 수 있다.
그리고 DAX를 사용하여 DynamoDB에서 읽기를 캐싱할 수 있다. 이는 매우 쉽게 구현할 수 있는 방법이며, 성능 향상뿐만 아니라 비용 절감 및 캐싱 기능도 제공할 수 있다.
REST 요청은 매우 정적인 응답이 있는 경우 API Gateway 수준에서 수행할 수 있다.
마지막으로 Cognito로 전체 보안 작업을 수행할 수 있으며 Cognito는 API Gateway와 직접 통합된다.

[AWS] 솔루션 설계자 관점의 Serverless - Amazon Cognito

yunseohhe — Wed, 18 Dec 2024 17:56:16 +0900

Amazon Cognito

사용자에게 웹 및 모바일 앱과 상호 작용할 수 있는 자격 증명을 부여한다.
일반적으로 이 사용자들은 AWS 계정 외부에 있는데 모르는 사용자들에게 자격 증명을 부여해 사용자를 인식(Cognito) 한다.
Cognito에는 두 종류의 하위 서비스가 있다.
- Cognito User Pools(사용자 풀)
: 앱 사용자에게 가입 기능을 제공한다.
: API Gateway 및 애플리케이션 로드 밸런서와 원활히 통합된다.
- Cognito Identity Pools (Federated Identity)
: 앱에 등록된 사용자에게 임시 AWS 자격 증명을 제공해서 일부 AWS 리소스에 직접 액세스 할 수 있도록 해준다.
: Cognito 사용자 풀과 원활히 통합된다.
Cognito는 AWS 외부의 웹과 모바일 앱 사용자를 대상으로 ㅎ나다.
- '수백 명의 사용자', '모바일 사용자', 'SAML을 통한 인증' 같은 키워드가 나오면 Cognito를 설명하는 것이다.

Cognito User Pools (CPU) - User Features

웹 및 모바일 앱을 대상으로 하는 서버리스 사용자 데이터베이스이다.
사용자 이름 또는 이메일, 비밀번호의 조합으로 간단한 로그인 절차를 정의할 수 있다.
비밀번호 재설정 기능이 있고 이메일 및 전화번호 검증 및 사용자 멀티팩터 인증이 가능하다.
Facebook이나 Google과 통합할 수 있어 소셜 로그인도 가능하다.

Cognito User Pools (CPU) - Integrations

cognito 사용자 풀은 API Gateway나 애플리케이션 로드 밸런서와 통합된다.

API Gateway를 예시로 보자.
사용자는 Cognito 사용자 풀에 접속해서 토큰을 받고 검증을 위해 토큰을 API Gateway에 전달한다.
확인이 끝나면 사용자 자격 증명으로 변환되어 백엔드의 Lambda 함수로 전달된다.
Lambda 함수는 처리할 사용자가 잘 인증된 구체적인 사용자라는 사실을 인식하게 된다.

다른 방법으로 완전히 동일한 작업이 가능한데 Cognito 사용자 풀을 애플리케이션 로드 밸런서 위에 배치하면 된다.
애플리케이션이 Cognito 사용자 풀에 연결한 다음 애플리케이션 로드 밸런서에 전달해서 유효한 로그인인지 확인한다.
유효하다면 요청을 백엔드로 리다이렉트하고 사용자의 자격 증명과 함께 추가 헤더를 전송한다.
API Gateway나 ALB를 통해 사용자의 로그인을 한 곳에서 확실히 검증할 수 있고, 검증 책임을 백엔드로부터 백엔드의 로드를 밸런싱하는 실제 위치, 즉 API Gateway 또는 ALB로 옮긴 것이다.

Cognito Identity Pools (Federated Identity)

사용자에게 자격 증명을 제공하지만 API Gateway나 ALB를 통해서 애플리케이션에 액세스하지 않고 임시 AWS 자격 증명을 사용해 AWS 계정에 직접 액세스 한다.
사용자는 Cognito 사용자 풀 내의 사용자가 될 수도 있고, 타사 로그인이 될 수도 있다.
직접 또는 API Gateway를 통해 서비스에 액세스 할 수도 있다.
자격 증명에 적용되는 IAM 정책은 Cognito 자격 증명 풀 서비스에 사전 정의되어 있다.
user_id를 기반으로 사용자 정의하여 세분화된 제어를 할 수도 있다.
원한다면 기본 IAM 역할을 정의 할 수도 있다.
게스트 사용자나 특정 역할이 정의되지 않은 인증된 사용자는 기본 IAM 역할을 상속하게 된다.

Cognito Identity Pools - Diagram

웹이나 모바일 애플리케이션에서 S3 버킷 또는 DynamoDB 테이블에 직접 액세스하고 싶다면 Cognito 자격 증명 풀을 사용하고 웹, 모바일 앱이 로그인해서 토큰을 받을 것이다. Cognito 사용자 풀에 대한 로그인일 수도 있고, 소셜 자격 증명 제공자나 SAML OpenID Connect 일수도 있다.
그런 다음 이 토큰을 Cognito Identity Pool 서비스에 전달해서 토큰을 임시 AWS 자격 증명과 교환한다.
이를 위해 Cognito Identity Pool은 전달 받은 토큰이 올바른지, 즉 유효한 로그인인지 평가한다.
다음으로는 해당 사용자에게 적용되는 IAM 정책을 생성한다.
관련 IAM 정책이 적용된 임시 자격 증명 덕분에 AWS의 S3 버킷이나 DynamoDB 테이블에 직접 액세스 할 수 있는 것이다.
- API Gateway나 애플리케이션 로드 밸런서를 거치지 않고도

Cognito Identity Pools Row Level Security in DynamoDB

Cognito Identity Pool을 사용하면 DynamoDB에 행 수준 보안을 설정할 수 있다.

Cognito Identity Pool에 위에와 같은 정책이 있을 때 이 안에 조건을 설정하는 것이다.
이 예시에서는 DynamoDB의 LeadingKeys가 Cognito 자격 증명 사용자 ID와 같아야 한다는 조건이다.
이 정책이 적용된 사용자는 DynamoDB 테이블의 모든 항목을 읽고 쓸 수 있는 것이 아니라 이 조건을 통해 액세스를 얻은 항목에만 액세스할 수 있다.
Cognito는 좀 복잡한 서비스이지만 웹이나 모바일 애플리케이션의 사용자 기반을 생성할 수 있고 세분화된 액세스 제어를 위해 DynamoDB에서 행 수준 보안을 활성화 할 수 있다.

Cognito 사용자 풀과 API Gateway 또는 애플리케이션 로드 밸런서를 통합할 수 있다는 점을 기억하자!

[AWS] 솔루션 설계자 관점의 Serverless - Step Functions

yunseohhe — Tue, 17 Dec 2024 17:24:15 +0900

AWS Step Functions

서버리스 워크플로를 시각적으로 구성할 수 있는 기능이다.
주로 람다 함수를 오케스트레이션 하는 데 활용한다.
그래프를 만드는데 각 그래프 단계별로 해당 단계의 결과에 따라 다음으로 수행하는 작업이 뭔지 정의한다.
좀 복잡한 워크플로를 만들어 AWS에서 실행시킬 수 있는 편리한 도구이다.
Step functions가 제공하는 기능으로는 시퀀싱, 병행 실행, 조건 설정, 타임아웃, 에러 처리하기 등이 있다.
람다 함수만 처리하는 게 아니라 EC2랑도 연동할 수 있고, ECS, 온프레미스 서버 또 API Gateway, SQS queues, 등등 다양한 AWS 서비스를 워크플로에 넣을 수 있다.
워크플로에 사람이 개입해서 승인을 해야만 진행되는 단게를 설정할 수 있다.
- 예를 들어, 어떤 지점에 이르러서는 사람이 결과를 확인하고 승인을 하면 다음 단계로 넘어 가고, 아니면 워크플로가 멈춰 실패하게 한다.
다양한 사용처가 있는데, 예를 들어 주문 이행이나 데이터 처리, 웹 애플리케이션 등 구성하기 복잡한 워크플로를 시각적으로 구성하려고 할 때 사용한다.

[AWS] 솔루션 설계자 관점의 Serverless - API Gateway

yunseohhe — Mon, 16 Dec 2024 21:09:32 +0900

Example : Building a Serverless API

Lambda 함수에서 API의 데이터베이스로 DynamoDB를 사용할 수 있으며 테이블을 생성, 읽기, 업데이트 삭제할 수 있다.
클라이언트도 이 Lambda 함수를 지연 호출(Invoke)할 수 있게 하려면 클라이언트에게 IAM 권한이 있어야 한다.
클라이언트와 Lambda 함수 사이에 애플리케이션 로드 밸런서를 배치하면 Lambda 함수가 HTTP 엔드포인트에 노출된다.
API Gateway를 사용하는 방법도 있다.
- AWS의 서버리스 서비스로 REST API를 생성할 수 있으므로 클라이언트가 퍼블릭 액세스 할 수 있다.
- API Gateway에 클라이언트가 직접 소통하며 다양한 작업을 할 수 있고 Lambda 함수에 요청을 프록시 한다.
API Gateway를 사용하는 이유는 HTTP 엔드포인트뿐만 아니라 인증부터 사용량 계획, 개발 단계 등의 기능을 제공하기 때문이다.

AWS API Gateway

API Gateway는 Lambda와 통합하면 완전 서버리스 애플리케이션이 구축되므로 인프라 관리가 필요 없다.
WebSocket 프로토콜을 지원하므로 API Gateway로 두 가지 방법의 실시간 스트리밍이 가능하다.
API 버저닝을 핸들링하므로 버전 1, 2, 3이 생겨도 클라이언트 연결이 끊기지 않는다.
- dev, test, prod 등 여러 환경을 핸들링
보안에도 활용할 수 있다.
- 인증, 권한 부여 등 수많은 보안 기능을 API Gateway에 활성화 할 수 있다.
API 키를 생성할 수 있고, API Gateway에 클라이언트 요청이 과도할 때 요청을 스로틀링할 수 있다.
Swagger나 Open API 3.0과 같은 공통 표준을 사용하여 신속히 API를 정의하여 가져올 수 있다.
- Swagger나 Open API로 내보낼 수도 있다.
API Gateway 수준에서 요청과 응답을 변형하거나 유효성을 검사해 올바른 호출이 실행되게 할 수 있다.
SDK나 API 스펙을 생성할 수 있다.
API 응답을 캐시할 수도 있다.

API Gateway - Integrations High Level
(API Gateway는 어떤 통합을 지원할까?)

Lambda 함수
- Lambda 함수를 지연 호출한다.
- Lambda 함수를 사용하는 REST API를 완전 서버리스 애플리케이션에 노출시키는 가장 일반적이고 간단한 방법이다.
HTTP
- 백엔드의 HTTP의 엔드포인트를 노출시킬 수 있다.
- 온프레미스에 HTTP API가 있거나 클라우드 환경에 애플리케이션 로드 밸런서가 있을 때 API Gateway를 활용하면 속도 제한 기능 캐싱, 사용자 인증, API 키 등의 기능을 추가할 수 있다.
- HTTP 엔드포인트에서 API Gateway 계층을 활용하는 것이다.
AWS Service
- 어떤 AWS API라도 노출시킬 수 있다.
- 단계 함수 워크플로우를 시작할 수 있고, API Gateway에서 직접 SQS에 메시지를 게시할 수도 있다.
- 인증을 추가하거나 API를 퍼블릭으로 배포하거나 특정 AWS 서비스에 속도 제한을 추가하기 위해 통합하는 것이다.

API Gateway - AWS Service Integration Kinesis Data Streams example
(AWS 서비스에 API Gateway를 사용하는 예시)

Kinesis Data Stream에 사용자가 데이터를 전송할 수는 있지만 AWS 자격 증명은 가질 수 없도록 보안 설정을 할 수 있다.
Kinesis Data Stream과 클라이언트 사이에 API Gateway를 두는 것이다.
클라이언트가 API Gateway로 HTTP 요청을 보내면 Kinesis Data Stream에 전송하는 메시지로 구성해 전송한다.
위의 예시를 보시다시피 따로 서버를 관리할 필요가 없다.
Kinesis Data Stream에서 Kinesis Data Firehose로 레코드를 전송하고 최종적으로 JSON 형식으로 Amazon S3 버킷에 저장한다.
API Gateway를 통해 AWS 서비스를 외부에 노출시키는 것이다.

API Gateway - Endpoint Types

API Gateway 배포 방법은 세 가지 이며, 이를 엔드포인트 유형이라고 한다.
Edge-Optimized (default)
- 글로벌 클라이언트 용이다.
- 전 세계 누구나 API Gateway에 액세스 할 수 있다.
- 모든 요청이 CloudFront 엣지 로케이션을 통해 라우팅되므로 지연 시간이 개선된다.
Regional
- API Gateway는 생성된 리전에 위치하지만 모든 CloudFront 엣지 로케이션에서 액세스 될 수 있다.
- CloudFront 엣지 로케이션을 원하지 않을 때는 리전 배포를 사용한다.
- 모든 사용자는 API Gateway를 생성한 리전과 같은 리전에 있어야 한다. 자체 CloudFront 배포를 생성할 수도 있다.
- 엣지 최적화 배포와 동일한 결과를 내며 캐싱 전략과 CloudFront 설정에 더 많은 권한을 가질 수 있다.
Private
- 프라이빗 API Gateway는 VPC 내에서만 액세스 할 수 있다. (ENI 같은 인터페이스 VPC 엔드포인트를 사용해서)
- API Gateway에 액세스를 정의할 때는 리소스 정책을 사용한다.

API Gateway - Security

사용자를 식별하는 방법
- IAM 역할을 사용한다.
: EC2 인스턴스에서 실행되는 내부 애플리케이션에서 유용하다.
: API Gateway의 API에 액세스할 때 IAM 역할을 사용하도록 하는 것이다.
- Cognito를 사용한다.
: 모바일 애플리케이션이나 웹 애플리케이션의 외부 사용자에 대한 보안 조치로 사용한다.
- 사용자 지정 권한 부여자를 사용한다.
: 자체 로직을 실행할 때 사용한다.
사용자 지정 도메인 이름을 AWS Certificate Manager 즉, ACM과 통합할 수 있다.
- 엣지 최적화 엔드포인트를 사용할 경우 인증서는 us-east-1에 있어야 하고, 리전 엔드포인트를 사용한다면 인증서는 API Gateway 단계와 동일한 리전에 있어야 한다.
- Route 53에 CNAME이나 A-별칭 레코드를 설정해 도메인 및 API Gateway를 가리키도록 해야 한다.

[AWS] 솔루션 설계자 관점의 Serverless - DynamoDB의 고급기능

yunseohhe — Sun, 15 Dec 2024 21:23:18 +0900

DynamoDB Accelerator (DAX)

DAX는 DynamoDB를 위한 고가용성의 완전 관리형 무결절 인메모리 캐시이다.
DynamoDB 테이블에 읽기 작업이 많을 때, DAX 클러스터를 생성하고 데이터를 캐싱하여 읽기 혼잡을 해결한다.
DAX는 캐시 데이터에 마이크로초 수준의 지연 시간을 제공한다.
DAX 클러스터는 기존 DynamoDB API와 호환되므로 애플리케이션 로직을 변경할 필요가 없다.
DynamoDB 테이블과 애플리케이션이 있을 때, 몇몇 캐시 노드가 연결된 DAX 클러스터를 생성하면 백그라운드에서 DAX 클러스터가 Amazon DynamoDB 테이블에 연결된다.
캐시의 기본 TTL은 5분으로 설정되어 있으나 변경할 수 있다.

DynamoDB Accelerator (DAX) vs ElastiCache

ElastiCache가 아니라 DAX를 사용하는 이유는 뭘까?
DAX는 DynamoDB 앞에 있고 개별 객체 캐시와 쿼리와 스캔 캐시를 처리하는 데 유용하다.
예를 들어 집계 결과를 저장할 때는 Amazon ElastiCache가 좋고, Amazon DynamoDB는 대용량의 연산을 저장할 때 좋다.
두 서비스는 상호 보완적인 성격을 띈다.
DynamoDB에 캐싱 솔류션을 추가할 때는 보통 DynamoDB Accelerator를 사용한다.

DynamoDB - Stream Processing

DynamoDB에서는 스트림 처리도 가능하다.
테이블의 모든 수정 사항 즉, 생성, 업데이터, 삭제를 포함한 스트림을 생성할 수 있다.
사용자 테이블에 새로운 사용자가 등록됐을 때 환영 이메일을 보내는 등 DynamoDB 테이블의 변경 사항에 실시간으로 반응하는 데 활용할 수 있다.
실시간으로 사용 분석을 하거나 파생 테이블을 삽입할 수도 있다.
리전 간 복제를 실행하거나 DynamoDB 테이블 변경 사항에 대해 Lambda 함수를 실행할 수도 있다.
DynamoDB에는 두 가지 스트림 처리가 있다.
- DynamoDB Stream
: 보존 기간이 24시간이고, 소비자 수가 제한된다.
: Lambda 트리거와 함께 사용하면 좋다.
: 자체적으로 읽기를 실행하려면 DynamoDB Stream Kinesis 어댑터를 사용한다.
- Kinesis Data Stream
: 이 스트림은 보전 기간이 1년이고, 더 많은 수의 소비자 수를 갖고 데이터를 처리하는 방법이 훨씬 많다.
: AWS Lambda 함수 Kinesis Data Analytics, Kinesis Data Friehose, Glue 스트리밍 등으로

DynamoDB Streams

애플리케이션이 DynamoDB 테이블에서 작업을 생성, 업데이트, 삭제하면 이는 DynamoDB 스트림이나 Kinesis Data Stream로 전송된다.
Kinesis Data Stream을 선택하면 Kinesis Data Firehose를 사용할 수 있다.
그런 다음 분석 목적으로 데이터를 Amazon Redshift로 전송하고 데이터를 아카이빙하려면 Amazon S3로 전송한다.
Amazon OpenSearch로 보내면 인덱싱이나 검색을 할 수 있다.
DynamoDB 스트림을 사용하면 처리 계층을 둘 수 있다.
EC2 인스턴스에서 애플리케이션을 실행하려면 KCL Adapter나 Lambda 함수를 사용한다.
처리 계층에서 SNS로 알림을 보내거나 DynamoDB 테이블을 필터링하거나 변환할 수 있다.
Amazon OpenSearch로 처리 계층의 데이터를 전송할 수도 있다.
Kinesis Data Stream에서 EC2 인스턴스로 읽거나 Kinesis Data Stream에서 Kinesis Data Analytics를 사용할 수도 있다. 등등 여러 변형이 가능하다.

DynamoDB Global Tables

글로벌 테이블은 여러 리전 간에 복제가 가능한 테이블이다.
테이블을 US-EAST-1과 AP-SOUTHEAST-2에 둘 수 있다.
두 테이블 간에는 양방향 복제가 가능하다.
- US-EAST-1이나 AP-SOUTHEAST-2 테이블 둘 중 하나에 쓰기를 하면 된다는 뜻이다.
DynamoDB 글로벌 테이블은 복수의 리전에서 짧은 지연 시간으로 액세스할 수 있게 해준다.
다중 활성 복제가 가능하므로 애플리케이션이 모든 리전에서 테이블을 읽고 쓸 수 있다는 뜻이다.
글로벌 테이블을 활성화하려면 DynamoDB 스트림을 활성화해야 리전간 테이블을 복제할 수 있는 기본 인프라가 구축된다.

DynamoDB - Time To Live (TTL)

TTL이라는 기능은 만료 타임스탬프가 지나면 자동으로 항목을 삭제하는 기능이다.
가령 SessionData라는 테이블에서 ExpTime(TTL)이라는 만료 기간 속성이 있을 것이다. 이 안에 타임 스탬프가 들어가는 것이다.
TTL을 정의한 다음, 에포크 타임스탬프에서의 현재 시간이 ExpTime 열을 넘어설 경우 해당 항목을 만료 처리하고 삭제 처리를 진행하는 개념이다.
데이터 테이블의 항목이 일정 시간 후에 삭제되도록 하는 것이다.
사용 사례
- 최근 항목만 저장하도록 하거나 2년 후 데이터를 삭제해야 한다는 규정을 따라야 할 때 사용한다.
- 웹 세션 핸들링
: 사용자가 웹사이트에 로그인했을 때 해당 세션을 중앙 저장소인 DynamoDB에 두 시간 동안 저장하는 것이다.여기에 세션 데이터를 저장하면 모든 애플리케이션이 액세스할 수 있고 두 시간 후에 세션이 갱신되지 않으면 만료되어 해당 테이블에서 삭제될 것이다.)

DynamoDB - 재해 복구를 위한 백업

지정 시간 복구(PITR)
- 지속적인 백업을 할 수 있다.
- 활성화를 선택할 수 있고 35일 동안 지속된다.
- 활성화하면 백업 기간 내에는 언제든 지정 시간 복구를 실행할 수 있다.
- 복구를 진행할 경우 새로운 테이블을 생성한다.
온디맨드 백업
- 이 백업은 직접 삭제할 때까지 보존된다.
- 온디맨드 백업은 DynamoDB의 성능이나 지연시가에 영향을 주지 않는다.
- 백업을 좀 더 제대로 관리할 수 있는 방법 중 하나로 'AWS Backup' 서비스가 있다.
: 백업에 수명 주기 정책을 활성화할 수 있고, 재해 복구 목적으로 리전 간 백업을 복사할 수 있다.
: 이 옵션 또한 백업으로 복구를 진행하면 새로운 테이블이 생성된다.

DynamoDB - Amazon S3 간 통합

S3에 테이블을 내보낸다.
- 지정 시간 복구 기능(PITR)을 꼭 활성해 해야 한다.
- DynamoDB 테이블을 S3로 내보내고 가령 쿼리를 수행하려면 Amazon Athena 엔진을 사용한다.
- 지속적인 백업을 활성화한 상태이므로 최근 35일 이내 어떤 시점으로든 테이블을 내보낼 수 있다.
- 테이블을 내보내도 테이블의 읽기 용량이나 성능에 영향을 주지 않는다.
- DynamoDB를 Amazon S3로 먼저 내보내기하여 데이터 분석을 수행할 수 있다.
- 감사 목적으로 스냅샷을 확보할 수도 있고 데이터를 DynamoDB로 다시 가져오기 전에 데이터 ETL 등 대규모 변경을 실행할 수도 있다.
- 내보낼 때는 DynamoDB JSON이나 ION 형식을 이용해야 한다.
S3에서 테이블을 가져올 수도 있다.
- S3에서 CSV, JSON 그리고 ION 형식으로 내보낸 다음 새로운 DynamoDB 테이블을 생성하는 식이다.
- 쓰기 용량을 소비하지 않고 새로운 테이블이 생성한다.
- 가져올 때 발생한 오류는 모두 CloudWatch Logs에 기록된다.

[AWS] 솔루션 설계자 관점의 Serverless - DynamoDB

yunseohhe — Sat, 14 Dec 2024 16:13:39 +0900

AWS DynamoDB

완전 관리형 데이터베이스로 데이터가 다중 AZ 간에 복제되므로 가용성이 높다.
DynamoDB는 클라우드 네이티브이며, AWS의 독점 서비스이다.
NoSQL 데이터베이스이고, RDS나 Aurora 같은 관계형 데이터베이스는 아니지만 트랜잭션 지원 기능이 있다.
DynamoDB를 이용하면 방대한 워크로드로 확장이 가능하다.
- 데이터베이스가 내부에서 분산되기 대문이다.
초당 수백만 개의 요청을 처리하고 수조 개의 행, 수백 TB의 스토리지를 갖게 된다.
성능은 한 자릿수 밀리초를 자랑하고 일관성 또한 높다.
보안과 관련된 모든 기능은 IAM과 통합되어 있다.
- 보안, 권한부여, 관리 기능이 포함된다.
비용이 적게 들고 오토 스케일링 기능이 탑재되어 있다.
유지 관리나 패치 없이도 항상 사용할 수 있다.
데이터베이스를 프로비저닝할 필요가 없다.
항상 사용할 수 있으므로 테이블을 생성해 해당 테이블의 용량만 설정하면 된다.
- Standard 클래스 : 액세스가 빈번한 데이터 저장
- IA 테이블 클래스 : 액세스가 빈번하지 않는 데이터 저장

DynamoDB - Basics

DynamoDB는 테이블로 구성되며 데이터베이스를 생성할 필요가 없다.
- Aurora나 RDS와 달리 DynamoDB는 데이터베이스가 이미 존재하는 서비스이다.
DynamoDB에 테이블을 생성하면 각 테이블에 기본 키가 부여되는데 기본 키는 생성 시 결정된다.
각 테이블에 데이터를 추가한다.
- 항목, 즉 행을 무한히 추가할 수 있다.
각 항목은 속성을 가지며 속성은 열에 표시된다.
- 속성은 나중에 추가할 수도 있고, null이 될 수도 있다.
- RDS나 Aurora 데이터베이스에서는 열을 나중에 추가할 수 있으나 과정이 복잡하고 스키마 전개가 어려울 수 있지만 DynamoDB에서는 사전 요구 사항 없이 나중에 쉽게 속성을 추가할 수 있다.
DynamoDB 항목의 최대 크기는 400KB이므로 큰 객체를 저장할 때는 적합하지 않다.
DynamoDB는 다양한 데이터 유형을 지언한다.
- Scalar 유형 : 문자열, 숫자, Binary, Boolean, null 등
- Document 유형 : 목록, 지도 등
- Set 유형 : String Set, 숫자 Set 등
데이터의 유형과 구성 면에서 스키마를 빠르게 전개해야 할 때, Aurora나 RDS보다는 DynamoDB가 더 나은 선택이다.

DynamoDB - Table example

DynamoDB 테이블의 예시이다.
기본 키는 파티션 키와 선택 사항인 정렬 키로 구성된다.
속성테이블도 있고, 데이터베이스 형태이다.
속성은 null로 설정하거나 나중에 추가할 수 있다. = DynamoDB의 장점이다.

DynamoDB - Read/Write Capacity Modes

DynamoDB를 사용하려면 읽기/쓰기 용량 모드도 설정해야 한다.

테이블 용량 관리 방식을 제어하는 데는 두 가지 모드가 있다.

1. Provisioned Mode (기본)

프로비저닝된 모드로, 미리 용량을 프로비저닝한다.
초당 읽기/쓰기 요청 수를 예측해서 미리 지정하면 그것이 테이블의 용량이 된다.
미리 용량을 계획하고 프로비저닝된 RCU와 WCU만큼의 비용을 지불하는 방식이다.
- RCU는 읽기 용량 단위, WCU는 쓰기 용량 단위를 뜻한다.
미리 용량을 계획한 경우에도 오토 스케일링 기능이 있으므로 테이블의 로드에 따라 자동으로 RCU와 WCU를 늘리거나 줄일 수 있다.
프로비저닝된 모드는 로드를 예측할 수 있고 서서히 전개되며 비용 절감을 원하 때 적합하다.

2. On-Demand Mode

읽기/쓰기 용량이 워크로드에 따라 자동으로 확장된다.
미리 용량 계획을 하지 않으므로 RCU나 WCU 개념 자체가 없다.
온디맨드 모드에서는 정확히 사용한 만큼의 비용을 지불한다.
모든 읽기와 쓰기에 비용을 지불해야 한다.
워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용하다.
수천 개의 트랜잭션을 수백만 개의 트랜잭션으로 1분 내로 확장해야 하는 애플리케이션에서는 빠르게 확장되지 않는 프로비저닝된 모드는 적합하지 않고 온디맨드 모드를 선택해야 한다.
트랜잭션이 없거나 하루에 많아야 4~5회밖에 되지 않는 워크로드라면 트랜잭션 횟수만큼만 비용을 지불하는 온디맨드 모드가 적합할 것이다.

[AWS] 솔루션 설계자 관점의 Serverless - RDS 람다 호출 및 이벤트 알림

yunseohhe — Fri, 13 Dec 2024 18:38:27 +0900

RDS, Aurora와 Lambda는 긴밀하게 통합될까?

사실 우리는 데이터베이스 인스턴스안에서 람다 함수를 호출할 수도 있다. 그러면 우리는 데이터베이스 안에서 일어나는 데이터 이벤트를 처리할 수 있게 된다.
- RDS for PostgreSQL과 Aurora MySQL에 지원된다.
예를들어 사용자가 이벤트 데이터를 우리의 등록 테이블에 삽입하고, RDS는 우리의 람다 함수를 직접 호출하도록 설정이 될 것이다.
우리의 람다 함수는 사용자에게 환영 이메일을 보낼 수 있고, 사용자는 그걸 받게 된다.
AWS 콘솔에서 설정하는게 아니라 우리가 데이터베이스에 접속하고 그 안에서 설정해야 한다. 그리고 우리가 그렇게하면 RDS 인스턴스는 우리의 람다 함수를 호출하는 것이다.
RDS 데이터베이스 인스턴스로부터 람다 함수로 오는 인바운드 트래픽을 반드시 허용해야 한다.
- 모든 방식으로 오는 트래픽을 허용해야 한다.
- 우리의 람다가 퍼블릭 인터넷에 있는 경우에도 허용해야 한다.
우린 호출 또는 NAT 게이트웨이 또는 VPC 엔드포인트 등을 사용할 수 있다.
네트워크 연결성이 중요하다. 그 뿐만 아니라 물론 우리의 데이터베이스 인스턴스가 람다 함수를 호출할 것이기 때문에 우리는 람다 함수를 호출할 필수적인 권한을 갖고 있어야 한다.
- 그래서 우리는 데이터페이스 인스턴스가 적절한 IAM 정책을 갖고 있는지 확인해야 한다..

RDS Event Notifications

RDS 이벤트 알림을 사용하는 경우와 다르다. 이 알람들은 AWS 안에서 이루어지고, 데이터베이스 인스턴스 자체에 대한 정보를 알려주는 알림들이 있다.
예를 들면 생성된 시각이나 정지된 시각, 시작된 시각 등을 알려준다.
- 데이터베이스 안의 데이터에 대한 정보는 전혀 없다.
데이터베이스 인스턴스, 데이터베이스 스냅샷, 파라미터 그룹, 보안 그룹, 프록시 또는 커스텀 엔진 버전에 관한 이벤트를 구독할 수 있다.
- 데이터베이스 안의 데이터에 관한 정보는 받지 않을 것이다.
전달 시간이 최대 5분인 근 실시간 이벤트를 받고, 그걸 SNS에 전송하거나 그것들을 EventBridge에서 가로챌 수 있다. 그럼 SNS에서 예를 들어 SQS 대기열이나 람다 함수로 그것들을 전송할 수 있다.
EventBridge에는 예를 들어 람다 함수 같은 아주 많은 다양한 전송 대상이 있다.
- 하지만 데이터 이벤트 자체에 관한 정보는 받지 못한다는 점을 꼭 기억하자.

[AWS] 솔루션 설계자 관점의 Serverless - Lambda in VPC

yunseohhe — Thu, 12 Dec 2024 22:47:18 +0900

Lambda by default

기본적으로 Lambda 함수를 시작하면 우리의 VPC 외부에서 시작된다.
- VPC는 AWS가 제공하는 서비스이다.
우리는 VPC내에서 리소스에 액세스할 권한이 없다.
RDS 데이터베이스, ElastiCache 캐시 내부 로드 밸런드를 시작하면 Lambda 함수가 해당 서비스에 액세스 할 수 없다.
- Lambda 배포의 기본 설정이다.
인터넷의 퍼블릭 API에 액세스하는 것은 가능하다.
DynamoDB에 액세스 할 수 있는 건 DynamoDB가 AWS 클라우드의 퍼블릭 리소스이기 때문이다.
- 하지만 프라이빗 RDS 데이터베이스에는 연결할 수 없다.

Lambda in VPC

위를 해결하려면 우리의 VPC에서 Lambda 함수를 시작하면 된다.
이를 위해서는 VPC ID Lambda 함수를 시작하려는 서브넷을 지정하고 Lambda 함수에 보안 그룹을 추가해야 한다.
그러면 Lambda가 서브넷에 엘라스틱 네트워크 인터페이스를 생성해 우리의 VPC에서 실행되는 가령 Amazon RDS에 액세스할 수 있게 된다.
이렇게 하면 VPC 내 모든 항목에 비공개로 연결할 수 있다.

Lambda with RDS Proxy

VPC에서 Lambda를 사용하는 대표적인 사용사례는 'RDS Proxy'이다.
RDS 데이터베이스가 프라이빗 서브넷에 있어도 Lambda 함수로 직접 해당 DB에 액세스 할 수 있다.
- 이런 방법으로 RDS 데이터베이스에 직접 액세스하면 큰 문제가 발생하게 된다.
- Lambda 함수의 수가 너무 많이 생성되었다 사라지길 반복하면 개방된 연결이 너무 많아서 RDS 데이터베이스의 로드가 상승해 시간 초과등의 문제로 이어진다.
해결하는 방법은 RDS 프록시를 시작하는 것이다.
- 이 프록시가 연결을 한 곳으로 모으고 RDS 데이터베이스 인스턴스 연결의 수를 줄인다.
Lambda 함수가 RDS 프록시에 연결되고 RDS 프록시가 RDS DB 인스턴스로 연결되므로 아키텍처상의 문제가 해결된다.
장점
- 데이터베이스 연결의 풀링과 공유를 통해 확장성을 향상시킨다.
- 장애가 발생할 경우, 장애 조치 시간을 66%까지 줄여 가용성을 향상시키고 연결을 보존한다.
- RDS와 Aurora 모두에 적용된다.
- RDS 프록시 수준에서 IAM 인증을 강제하여 보안을 높일 수 있다.
- 자격 증명은 Secrets Manager에 저장된다.
Lambda 함수가 RDS 프록시에 연결할 수 있으려면 우리의 VPC에서 Lambda 함수를 시작해야 한다.
RDS 프록시는 퍼블릭 액세스가 불가능하므로 Lambda 함수를 퍼블릭으로 시작하면 RDS 프록시에 네트워크 연결을 할 수가 없다.

[AWS] 솔루션 설계자 관점의 Serverless - Lambda@Edge & CloudFront Functions

yunseohhe — Wed, 11 Dec 2024 22:51:15 +0900

Customization At The Edge (엣지에서의 사용자 지정)

보통은 함수와 애플리케이션을 특정 리전에서 배포하지만 CloudFront를 사용할 때는 엣지 로케이션을 통해 콘텐츠를 배포한다.
모던 애플리케이션에서는 애플리케이션에 도달하기 전에 엣지에서 로직을 실행하도록 요구하기도 한다.
- 이를 엣지 함수라고 하며, CloudFront 배포에 연결하는 코드이다.
이 함수는 사용자 근처에서 실행하여 지연 시간을 최소화하는 것이 목적이다.
CloudFront에는 두 종류의 함수가 있다.
- CloudFront 함수
- Lambda@Edge : 엣지 함수를 사용하면 서버를 관리할 필요가 없다. (전역으로 배포되기 때문에)
사용 사례
- CloudFront의 CDN 콘텐츠를 사용자 지정하는 경우
: 사용한 만큼만 비용을 지불하며 완전 서버리스이다.

CloudFront Functions & Lambda@Edge의 사용사례

웹 사이트 보안과 프라이버시
엣지에서의 동적 웹 애플리케이션
검색 엔진 최적화(SEO)에 활용 가능
오리진 및 데이터 센터 간 지능형 경로에 활용
엣지에서의 Bot Mitigation(봇 완화)
실시간 이미지 변환
A/B 테스트
사용자 Authentication(인증) 및 Authorization(권한 부여)
사용자 Prioritization (우선 순위 지정)
사용자 Tracking(추적) 및 Analytics(분석) 등등

CloudFront Functions

일반적인 CloudFront의 요청 처리 과정은 화면의 도식과 같다.
CloudFront에 클라이언트가 요청을 보내는 것을 뷰어 요청이라고 한다.
- 클라이언트가 뷰어니깐
그런 다음 CloudFront가 오리진 요청을 오리진 서버에 전송한다.
서버가 CloudFront에 오리진 응답을 보내고 CloudFront가 클라이언트에게 뷰어 응답을 전송한다.
CloudFront 함수는 JavaScript로 작성된 경량 함수로 뷰어 요청과 응답을 수정한다.
확장성이 높고 지연 시간에 민감한 CDN 사용자 지정에 사용된다.
시작 시간은 1밀리초 미만이며 초당 백만 개의 요청을 처리한다.
- 뷰어 요청과 응답을 수정할 때만 사용된다.
CloudFront가 뷰어로부터 요청을 받은 다음에 뷰어 요청을 수정할 수 있고 CloudFront가 뷰어에게 응답을 보내기 전에 뷰어 응답을 수정할 수 있다.
CloudFront의 네이티브 기능으로 모든 코드가 CloudFront에서 직접 관리된다.
CloudFront 함수는 고성능, 고확장성이 필요할 때 뷰어 요청과 뷰어 응답에만 사용된다.

Lambda@Edge

이 함수는 Node.js나 Python으로 작성하며 초당 수천 개의 요청을 처리할 수 있다.
모든 CloudFront 요청 및 응답을 변경할 수 있다.
뷰어 요청은 앞서 본대로고 오리진 요청은 CloudFront가 오리진에 요청을 전송하기 전에 수정할 수 있다.
오리진 응답은 CloudFront가 오리진에서 응답을 받은 후에 수정된다.
뷰어 응답은 CloudFront가 뷰어에게 응답을 보내기 전에 수정된다.
함수는 us-east-1 리전에만 작성할 수 있다.
- CloudFront 배포를 관리하는 리전과 같은 리전이다.
함수를 작성하면 CloudFront가 모든 로케이션에 해당 함수를 복제한다.

CloudFront Functions vs Lambda@Edge

가장 눈에 띄는 차이점은 런타임 지원이다.
- CloudFront는 JavaScript, Lambda@Edge는 Node.js와 Python을 지원한다.
CloudFront 함수의 확장성은 매우 높다.
- 수백만 개의 요청을 처리
- Lambda@Edge는 수천 개 수준인 반면에
트리거가 발생 위치도 크게 다르다.
- Lambda@Edge는 뷰어와 오리진 모두에게 영향을 미치는 반면
- CloudFront 함수는 뷰어에만 영향력이 있다.
CloudFront 함수의 최대 실행시간은 1밀리초 미만으로 아주 빠르고 간단한 함수이고, Lambda@Edge는 실행에 5~10초가 소요된다.

CloudFront Functions vs Lambda@Edge - 사용사례

CloudFront Functions

캐시 키를 정규화한다.
- 요청 속성을 변환하여 최적의 캐시 키를 생성한다.
요청이나 응답에 HTTP 헤더를 삽입, 수정, 삭제하도록 헤더를 조작한다.
URL을 다시 쓰거나 리디렉션한다.
요청을 허용 또는 거부하기 위해 JWT를 생성하거나 검증하는 요청 인증 및 권하 부여에도 사용된다.
- 모든 작업이 1밀리초 이내에 이뤄진다.

Lambda@Edge

실행 시간은 10초가 걸릴 수도 있다.
CPU와 메모리가 증가하므로 여러 라이브러리를 로드할 수 있고 타사 라이브러리에 코드를 의존시킬 수 있다.
- SDK에서 다른 AWS 서비스에 액세스 할 수 있도록
네트워크 액세스를 통해 외부 서비스에서 데이터를 처리할 수 있어 대규모 데이터 통합도 수행할 수 있다.
파일 시스템이나 HTTP 요청 본문에도 바로 액세스 할 수 있다.
다양한 사용자 지정이 가능하다.

[AWS] 솔루션 설계자 관점의 Serverless - Lambda

yunseohhe — Tue, 10 Dec 2024 17:09:25 +0900

AWS Lambda

EC2는 클라우드의 가상 서버라서 프로비저닝이 필요하다.
프로비저닝을 할 메모리와 CPU 크기가 제한된다.
지속적으로 실행되어야해서 최적화를 하기위해 효율적으로 시작하고 중단해야 한다.
- 그렇지 않으면 인스턴스에 어떤 일이 생기든 관계없이 EC2는 지속적으로 실행된다.
오토 스케일링 그룹으로 스케일링 할 수 있는데, 자동으로 서버를 추가하고 제거하는 그런 작업을 해야 한다는 뜻이다.

Lambda는 가상 함수이다.
관리할 서버 없이 코드를 프로비저닝하면 함수가 실행되는 것이다.
제한 시간이 있어서 실행 시간이 짧다고 하지만 최대 15분은 그렇게 짧지는 않다.
온디맨드로 실행된다. 즉, Lambda를 사용하지 않으면 람다함수가 실행되지 않고 비용 역시 함수가 실행되는 동안만 청구되며 호출을 받으면 온디맨드로 실행된다.
스케일링이 자동화된다.
- 더 많은 람다 함수를 동시에 필요로 하는 경우, AWS가 자동으로 프로비저닝해서 람다 함수를 늘려준다.

AWS Lambda의 장점

가격 책정이 아주 쉽다.
- Lambda가 수신하는 요청의 횟수에 따라 과금되는데 호출 횟수와 컴퓨팅 시간, 즉 Lambda가 실행된 시간만큼 청구된다.
- 프리 티어에서도 Lambda를 넉넉하게 제공해주는데 Lambda 요청 1백만 건과 40만 GB-초의 컴퓨팅 시간이 포함된다.
다양한 AWS 서비스와 통합되기도 한다.
Lambda에 여러 가지 프로그래밍 언어를 사용할 수 있어서 상당히 자유로운 편이다.
CloudWatch와의 모니터링 통합도 쉽다.
함수당 더 많은 리소스를 프로비저닝 하려면 함수당 최대 10GB의 램을 프로비저닝 할 수 있다.
함수의 RAM을 증가시키면 CPU 및 네트워크의 품질과 성능도 함께 향상된다.

AWS Lambda를 지원하는 언어

Node.js (JavaScript)
Python
Java (Java 8 호환)
C# (.NET Core)
Golang
C# / Powershell
Ruby
사용자 지정 런타임 API
- 예를 들어 Rust 언어 함수를 Lambda에서 사용하는 것도 오픈 소스 프로젝트가 있어서 가능하다.
Lambda 컨테이너 이미지를 지원한다.
- 컨테이너 이미지 자체가 Lambda의 런타임 API를 구현해야 한다. 즉, 아무 컨테이너 이미지나 Lambda에서 실행되지는 않고 컨테이너 이미지를 만들 때 전제 조건이 필요하다.
- ECS와 Fargate는 계속 임의의 도커 이미지를 실행할 때 더 많이 사용된다.
- Lambda에 컨테이너를 실행해야 할 경우, 해당 컨테이너가 Lambda 런타임 API를 구현하지 않으면 ECS나 Fargate에서 컨테이너를 실행해야 한다.

AWS 서비스와 Lambda의 통합

API Gateway는 REST API를 생성하고 람다 함수를 호출한다.
Kinesis는 Lambda를 이용해 바로 데이터를 변환한다.
DynamoDB는 트리거를 생성할 때 사용되는데 데이터베이스에 어떤 일이 생기면 람다함수가 작동되도록 한다.
Amazon S3는 언제든 람다 함수를 작동시킬 수 있다.
CloudFront용 람다는 Lambda@Edge이다.
CloudWatch Events와 EventBridge에서는 AWS의 인프라에 어떤 일이 생기고 그 상황에 대응하고자 할 때, 예를 들어 파이프라인이 끊기거나, 상태가 바뀌는 경우 등 상황에 따라 자동화를 실행하려고 람다 함수를 사용한다.
CloudWatch Logs는 어디든 해당 로그를 스트리밍 한다.
SNS로 알림과 SNS 토픽에 대처할 수 있다.
SQS로는 SQS 대기열 메시지를 처리할 수 있다.
Cognito는 예를 들어 사용자가 데이터베이스에 로그인할 때마다 응답한다.

예시 : Serverless Thumbnail creation(썸네일 생성)

S3 버킷이 있고, 여기서 바로 썸네일을 생성하고 싶다고 해보자.
Amazon S3에 새 이미지가 업로드되는 이벤트가 생기고 S3 이벤트 알림을 통해 람다 함수가 작동된다.
그리고 이때 람다 함수에는 섬네일을 생성하는 코드가 있다.
해당 썸네일은 다른 S3 버킷이나 같은 S3 버킷으로 푸시 및 업로드 된다.
- 원래 이미지보다 작은 크기로
람다 함수는 몇몇 데이터를 DynamoDB에 삽입할 수 있다.
- 이미지 이름, 크기, 생성 날짜 등 이미지의 메타 데이터가 삽입
Lambda 덕분에 기능이 자동화되고 S3에 새 이미지와 앱이 생성되는 이벤트에 대한 반응형 아키텍처를 얻는다.

예시 : Serverless CRON 작업

CRON이란 EC2 인스턴스에서 작업을 생성하는 방법이다.
5분마다, 월요일 10시마다 등등을 지정한다.
CRON은 가상 서버에 실행해야 한다.
- EC2 인스턴스 등에서
- 즉, 인스턴스가 실행되지 않거나 CRON이 아무 일도 안하면 인스턴스 시간이 낭비된다.
CloudWatch 이벤트 규칙 또는 EventBridge 규칙을 만들고 1시간마다 작동되게 설정해서 1시간마다 람다 함수와 통합되면 태스크를 수행할 수 있게 된다.(서버리스 CRON을 만드는 방법이다.)
CloudWatch 이벤트는 서버리스이고 람다 함수 역시 서버리스이다.

AWS Lambda 가격책정 예시

호출당 청구
- 처음 1백만 건의 요청은 무료이고, 이후 1백만건 요청마자 20센트가 과금된다.
- 또한 1ms 단위로 요금이 부과된다.
한 달간 첫 40만 GB 초 동안의 컴퓨팅 시간은 무료로 사용한다.
- GB 초 = 함수가 1GB RAM을 가질 때 실행 시간이 40만 초이며 실행시간이 8배 늘어나려면 함수의 RAM은 8배 작은 128MB RAM이 되어야 한다.
- 이후에는 60 GB 초당 1달러가 과금된다.
홈페이지 : https://aws.amazon.com/ko/lambda/pricing/

서버리스 컴퓨팅 – AWS Lambda 요금 – Amazon Web Services

aws.amazon.com

AWS Lambda의 한도

실행 한도
- 실행 시 메모리 할당량은 128MB에서 10GB이고 메모리는 1MB씩 증가한다.
- 메모리가 증가하면 더 많은 vCPU가 필요하다.
- 최대 실행 시간은 900초(15분)이다.
- 환경변수는 4KB까지 가질 수 있는데 상당히 제한적인 공간이나 Lambda함수를 생성하는 동안 큰 파일을 가져올 때 사용할 수 있는 임시 공간이 있다.
- /tmp 폴더에 용량이 있으며 크기는 최대 10GB이다.
- Lambda함수는 최대 1,000개까지 동시 실행이 가능하며 요청 시 증가할 수 있지만 동시성은 미리 예약해 두는 것이 좋다.
배포 한도
- 압축 시 최대 크기는 50MB이다.
- 압축하지 않았을 때는 250MB이다.
- 용량을 넘는 파일의 경우 /tmp 공간을 사용해야 한다.
- 시작할 때 크기가 큰 파일이 있으면 /tmp 디렉터리를 사용한다.
- 배포 시에도 환경변수의 한도는 4KB이다.
- 예를 들어, 30GB의 RAM과 30분의 실행 시간이 필요하고 3GB의 큰 파일을 있을 때는 워크로드 처리에 Lambda 함수가 적합하지 않다는 걸 판단할 수 있다.

AWS Lambda의 Snap Start

Lambda 함수의 성능을 높이기 위한 Lambda의 기능이다.
Java 11 이상에서 실행되는 Lambda 함수들을 추가 비용 없이 성능을 최대 10배 높여준다.
Lambda 호출을 몇 개의 수명 주기 단계가 있는데 Snap Start가 비활성화되어 있고 Java에서 실행 중인 Lambda 함수가 있다면 Lambda 함수가 호출되었을 때, 우리의 Java 코드가 초기화된 후에 호출되고 shutdown(종료)될 것이다. 그러나 Snap Start가 활성화되어 있으면 함수가 미리 초기화된 상태에서 호출 될 것이다. 즉, 처음에 함수 초기화가 없다는 의미이다.
Snap Start를 활성화하면 Java에서 실행 중인 Lambda 함수가 호출되는데 함수가 이미 초기화 되어있기 때문에 Java에서는 굉장히 오래 지속될 수 있는 초기화 단계가 없어지고 바로 호출 단계로 넘어가고 shutdown 단계로 넘어가게 된다.
완전히 무료인 기능이고 작동하는 방법
- 새로운 Lambda 버전을 발행할 때 Lambda가 우리의 함수를 초기화 할 것이다. 즉, 이 초기화 단계가 미리 진행되어 있을 것이다.
- 그 이후에 메모리와 초기화된 함수의 디스크 상태의 스냅샷이 생성된 후 마지막으로 이 스냅샷이 저지연 액세스를 위해 캐시될 것이다. 이는 우리의 함수가 Snap Start, 빠른 시작을 할 수 있도록 한다.