201. 서버리스 소개
AWS에서의 서버리스를 자세히 이야기하면 여기 사용자가 S3 버킷에서 정적 콘텐츠를 얻는데 웹 사이트 혹은 CloudFront 와 S3로 전달됩니다. 그리고 Cognito에 로그인하는데 사용자 신원 정보를 보관하는 곳입니다. API Gateway를 통해 사용자는 REST API를 호출하고 API Gateway는 람다 함수를 호출하고 람다 함수는 DynamoDB에서 데이터를 저장하고 회수합니다. 여기까지 예시였고 이번 섹션 전체를 할애하여 Lambda와 DynamoDB API Gateway와 Cognito 등을 다루겠습니다.
물론 서버리스 애플리케이션의 참조용 아키텍처를 제공하는 정도입니다.
AWS에는 Lambda, DynamoDB Cognito, API Gateway, Amazon S3 그리고 앞서 다루었던 SNS와 SQS 등이 있습니다. SQS와 SNS에서도 서버를 관리하지 않았고 자동으로 스케일링했어요 따라서 서버리스 사례와 잘 맞습니다.
Kinesis Data Firehose도 처리량에 맞춰 스케일링하고 사용한 만큼 지불하며 서버를 프로비저닝 하지 않습니다.
Aurora 서버리스는 관리 서버 없이도 데이터베이스가 온디맨드로 스케일링합니다.
단계 함수와 Fargate의 경우 Fargate는 ECS의 서버리스 기능이며 여기서는 도커 컨테이너를 실행할 인프라를 프로비저닝하지 않았습니다.
202. Lambda 개요
그러면 AWS Lambda가 무엇이고 우리에게 어떻게 도움이 될까요?
예를 들어보겠습니다 Amazon EC2로 시작합니다. 알다시피 Amazon EC2는 클라우드의 가상 서버라서 프로비저닝이 필요합니다.
따라서 프로비저닝을 할 메모리와 CPU 크기가 제한됩니다
지속적으로 실행되어야 합니다 그래서 최적화를 하려면 효율적으로 시작하고 중단해야 하죠. 그렇지 않으면 인스턴스에 어떤 일이 생기든 관계없이 EC2는 지속적으로 실행됩니다.
오토 스케일링 그룹으로 스케일링할 수 있는데 다시 말해 자동으로 서버를 추가하고 제거하는 그런 작업을 해야 한다는 뜻입니다.
이렇게 EC2를 사용해도 좋지만 AWS Lambda라는 것이 있습니다.
람다는 가상의 함수입니다. 관리할 서버 없이 코드를 프로비저닝하면 함수가 실행되는 겁니다.
제한 시간이 있어서 실행 시간이 짧다고 하지만 최대 15분은 제 생각에는 그렇게 짧지 않아요.
그리고 온디맨드로 실행됩니다. 즉 Lambda를 사용하지 않으면 람다 함수가 실행되지 않고 비용 역시 함수가 실행되는 동안만 청구되며 호출을 받으면 온디맨드로 실행됩니다. Amazon EC2과는 큰 차이가 있죠.
마지막으로 스케일링이 자동화됩니다. 더 많은 람다 함수를 동시에 필요로 하는 경우 AWS가 자동으로 프로비저닝해서 신기하게도 람다 함수를 늘려줍니다. 실습에서 보여드릴게요 이제 Lambda의 장점을 보겠습니다.
굉장히 많은 장점이 있는데요 우선 가격 책정이 아주 쉬워집니다
- Lambda가 수신하는 요청의 횟수에 따라 과금되는데 호출 횟수와 컴퓨팅 시간, 즉 Lambda가 실행된 시간만큼 청구됩니다.
- 프리 티어에서도 Lambda를 넉넉하게 제공해 주는데 Lambda 요청 1백만 건과 40만 GB-초의 컴퓨팅 시간이 포함됩니다.
다양한 AWS 서비스와 통합되기도 합니다.
또한 Lambda에 여러 가지 프로그래밍 언어를 사용할 수 있어서 상당히 자유로운 편입니다.
CloudWatch와의 모니터링 통합도 쉽습니다.
그리고 함수당 더 많은 리소스를 프로비저닝 하려면 함수당 최대 10GB의 램을 프로비저닝 할 수 있습니다.
이 부분도 알아두셔야 합니다 만약 함수의 RAM을 증가시키면 CPU 및 네트워크의 품질과 성능도 함께 향상될 것입니다.
이제 Lambda를 지원하는 언어를 살펴보겠습니다
먼저 JavaScript의 Node.js
또 Python, Java 즉 Java 8 호환이나 Java 11
C# .NET Core Golang,
C# /Powershell
Ruby,
또 웬만한 언어는 모두 Lambda에서 사용 가능합니다. 커뮤니티가 지원하는 사용자 지정 런타임 API 덕분이죠. 예를 들어 Rust 언어 함수를 Lambda에서 사용하는 것도 오픈 소스 프로젝트가 있어서 가능합니다.
이렇게 Lambda는 다양한 언어를 지원합니다. 그리고 Lambda 컨테이너 이미지를 지원합니다.
- Lambda 컨테이너 이미지는 아주 특별한 것인데 컨테이너 이미지 자체가 Lambda의 런타임 API를 구현해야 합니다. 즉 아무 컨테이너 이미지나 Lambda에서 실행되지는 않고 컨테이너 이미지를 만들 때 전제 조건이 필요합니다.
- ECS와 Fargate는 계속 임의의 도커 이미지를 실행할 때 더 많이 사용됩니다. 따라서 시험에서 Lambda에 컨테이너를 실행해야 할 경우 해당 컨테이너가 Lambda 런타임 API를 구현하지 않으면 ECS나 Fargate에서 컨테이너를 실행해야 합니다.
Lambda가 다양한 AWS 서비스와 통합된다고도 말씀드렸는데 어떤 방식으로 통합이 이루어지는지 예를 들고 이번 과정에서 몇 가지 보여드릴게요.
API Gateway는 REST API를 생성합니다. 그리고 람다 함수를 호출하죠.
Kinesis는 Lambda를 이용해 바로 데이터를 변환합니다.
DynamoDB는 트리거를 생성할 때 사용되는데 데이터베이스에 어떤 일이 생기면 람다 함수가 작동되도록 합니다.
Amazon S3은 전에 봤지만 언제든 람다 함수를 작동시킵니다. S3에 파일이 생성되거나 할 때요.
CloudFront용 람다는 Lambda@Edge인데 이번 섹션에서 다룰 예정입니다.
CloudWatch 이벤트와 EventBridge에서는 AWS의 인프라에 어떤 일이 생기고 그 상황에 대응하고자 할 때 예를 들어 파이프라인이 끊기거나, 상태가 바뀌는 경우 등 상황에 따라 자동화를 실행하려고 람다 함수를 씁니다.
CloudWatch 로그는 어디든 해당 로그를 스트리밍 합니다.
그리고 SNS로 알림과 SNS 토픽에 대처할 수 있으며
SQS로는 SQS 대기열 메시지를 처리할 수 있습니다.
마지막으로 Cognito는 예를 들어 사용자가 데이터베이스에 로그인할 때마다 응답합니다.
굉장히 많은 Lambda 통합 중에 주요 기능을 말씀드렸는데요. 좋은 예시를 하나 보여드리겠습니다. 바로 서버리스 섬네일 생성입니다
여기 S3 버킷이 있습니다. 여기서 바로 섬네일을 생성하고 싶습니다. Amazon S3에 새 이미지가 업로드되는 이벤트가 생기고 S3 이벤트 알림을 통해 람다 함수가 작동됩니다. 그리고 이때 람다 함수에는 섬네일을 생성하는 코드가 있습니다. 해당 섬네일은 다른 S3 버킷이나 같은 S3 버킷으로 푸시 및 업로드됩니다. 원래 이미지보다 작은 크기로요. 또한 람다 함수는 몇몇 데이터를 DynamoDB에 삽입할 수 있습니다. 이미지 이름, 크기, 생성 날짜 등 이미지의 메타 데이터가 삽입되지요. Lambda 덕분에 기능이 자동화되고 또 S3에 새 이미지와 앱이 생성되는 이벤트에 대한 반응형 아키텍처를 얻습니다.
아주 널리 알려진 예시로는 서버리스 CRON 작업이 있습니다. CRON이란 EC2 인스턴스에서 작업을 생성하는 방법인데
5분마다, 월요일 10시마다 등등을 지정합니다. 그런데 CRON은 가상 서버에 실행해야 합니다. EC2 인스턴스 등에요. 즉 인스턴스가 실행되지 않거나 CRON이 아무 일도 안 하면 인스턴스 시간이 낭비됩니다.
따라서 CloudWatch 이벤트 규칙 또는 EventBridge 규칙을 만들고 1시간마다 작동되게 설정해서 1시간마다 람다 함수와 통합되면 태스크를 수행할 수 있게 됩니다. 서버리스 CRON을 만드는 방법이죠. 이때 CloudWatch 이벤트는 서버리스이고 람다 함수 역시 서버리스입니다.
다음은 Lambda 가격 책정 예시를 봅시다. 웹 사이트에 모든 정보가 있습니다. 여기 정보가 최신이 아니더라도 가격 책정 방식의 예시로 보시면 됩니다.
먼저 호출당 청구입니다 처음 1백만 건의 요청은 무료이고
- 이후 1백만 건 요청마다 20센트가 과금됩니다. 정말로 저렴합니다
또한 1ms 단위로 요금이 부과됩니다.
- 한 달간 첫 40만 GB-초 동안의 컴퓨팅 시간은 무료로 사용합니다.
- 여기서 GB-초라는 것은 함수가 1GB RAM을 가질 때 실행 시간이 40만 초이며
- 다시 말해 실행 시간이 8배 늘어나려면 함수의 RAM은 8배 작은 128MB RAM이 되어야 합니다.
- 이후에는 60만 GB-초당 1달러가 과금됩니다.
계산을 해보면 아시겠지만 Lambda로 코드를 실행하면 정말 저렴하지요. 그래서 애플리케이션을 만들 때 널리 쓰입니다. 이제 Lambda가 어떻게 실행되는지 실습으로 알아보겠습니다
203. Lambda 실습
204. Lambda 제한
시험에 응시하려면 Lambda 한도는 알아야 합니다. 시험에 자주 나오는 내용이며 이 한도는 리전당 존재합니다.
한도에는 실행 한도와 배포 한도가 있습니다.
- 실행 시 메모리 할당량은 128MB에서 10GB이고 메모리는 1MB씩 증가합니다. 아시다시피 메모리가 증가하면 더 많은 vCPU가 필요하죠.
- 최대 실행 시간은 900초 즉 15분입니다. 이를 초과하면 Lambda 실행에 바람직하지 않습니다.
- 환경변수는 4KB까지 가질 수 있는데 상당히 제한적인 공간이나
- Lambda 함수를 생성하는 동안 큰 파일을 가져올 때 사용할 수 있는 임시 공간이 있습니다. /tmp 폴더에 용량이 있으며 크기는 최대 10GB입니다.
- Lambda 함수는 최대 1,000개까지 동시 실행이 가능하며 요청 시 증가할 수 있지만 동시성은 미리 예약해 두는 것이 좋습니다.
배포 한도로 넘어가 보죠
- 압축 시 최대 크기는 50MB
- 압축하지 않았을 때는 250MB입니다.
- 이 용량을 넘는 파일의 경우 /tmp 공간을 사용해야 합니다.
- 시작할 때 크기가 큰 파일이 있으면 /tmp 디렉터리를 사용하세요. 배포 시에도 환경변수의 한도는 4KB입니다
이 한도를 알고 있어야 시험 문제를 풀 수 있어요. 예를 들어 30GB의 RAM과 30분의 실행 시간이 필요하고 3GB의 큰 파일을 있을 때는 워크로드 처리에 Lambda 함수가 적합하지 않다는 걸 판단할 수 있습니다. 유익했길 바라며 다음 강의에서 뵙겠습니다.
205. Lambda@엣지 & CloudFront Functions
엣지에서의 사용자 지정에 대해 알아보겠습니다.
보통은 함수와 애플리케이션을 특정 리전에서 배포하지만 CloudFront를 사용할 때는 엣지 로케이션을 통해 콘텐츠를 배포합니다. 모던 애플리케이션에서는 애플리케이션에 도달하기 전에 엣지에서 로직을 실행하도록 요구하기도 합니다.
이를 엣지 함수라고 하며
- CloudFront 배포에 연결하는 코드입니다.
- 이 함수는 사용자 근처에서 실행하여 지연 시간을 최소화하는 것이 목적입니다.
CloudFront에는 두 종류의 함수가 있는데 CloudFront 함수와 Lambda@Edge입니다. 이 둘이 각각 언제 필요한지와 차이점을 본 강의에서 알아보겠습니다.
엣지 함수를 사용하면 서버를 관리할 필요가 없습니다. 전역으로 배포되기 때문이죠.
사용 사례로는 CloudFront의 CDN 콘텐츠를 사용자 지정하는 경우를 들 수 있습니다.
사용한 만큼만 비용을 지불하며 완전 서버리스입니다.
사용 사례를 자세히 한번 살펴보도록 하죠
첫 번째는 웹사이트 보안과 프라이버시입니다
엣지에서의 동적 웹 애플리케이션에도 쓰이고
검색 엔진 최적화(SEO)에도 활용 가능하죠.
오리진 및 데이터 센터 간 지능형 경로에도 활용합니다.
엣지에서의 봇 완화
엣지에서의 실시간 이미지 변환
A/B 테스트 사용자 인증 및 권한 부여
사용자 우선순위 지정
사용자 추적 및 분석 등
다양한 사용자 지정에 CloudFront 함수와 Lambda@Edge가 활용됩니다.
CloudFront 함수의 활용과 원리를 알아보겠습니다. 일반적인 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 함수와 Lambda@Edge의 비교표가 있습니다.
가장 눈에 띄는 차이점은 런타임 지원입니다. CloudFront는 JavaScript만 Lambda@Edge는 Node.js와 Python을 지원합니다. CloudFront 함수의 확장성은 매우 높습니다. 수백만 개의 요청을 처리하죠 Lambda@Edge는 수천 개 수준인 반면에요. 트리거가 발생 위치도 크게 다릅니다. Lambda@Edge는 뷰어와 오리진 모두에게 영향을 미치는 반면 CloudFront 함수는 뷰어에만 영향력이 있습니다.
다음이 중요한데요. CloudFront 함수의 최대 실행 시간은 1밀리초 미만입니다. 아주 빠르고 간단한 함수이죠. Lambda@Edge는 실행에 5~10초가 소요됩니다. 이 함수들로 여러 로직을 실행할 수 있는데요. 나머지 항목은 각자 살펴보세요.
사용 사례를 봅시다
CloudFront 함수는 캐시 키를 정규화합니다.
- 요청 속성을 변환하여 최적의 캐시 키를 생성하죠.
요청이나 응답에 HTTP 헤더를 삽입, 수정, 삭제하도록 헤더를 조작하고
URL을 다시 쓰거나 리디렉션합니다
요청을 허용 또는 거부하기 위해
- JWT를 생성하거나 검증하는 요청 인증 및 권한 부여에도 사용되고요. 모든 작업이 1밀리초 이내에 이뤄집니다.
반면에 Lambda@Edge의 실행 시간은 10초가 걸릴 수도 있죠.
CPU와 메모리가 증가하므로 여러 라이브러리를 로드할 수 있고
타사 라이브러리에 코드를 의존시킬 수 있습니다. 가령 SDK에서 다른 AWS 서비스에 액세스할 수 있도록요.
네트워크 액세스를 통해 외부 서비스에서 데이터를 처리할 수 있어 대규모 데이터 통합도 수행할 수 있습니다.
파일 시스템이나 HTTP 요청 본문에도 바로 액세스할 수 있습니다. 다양한 사용자 지정이 가능하죠.
206. Lambda in VPC
이번 강의에서는 Lambda 네트워킹 기초를 알아보겠습니다.
기본적으로 Lambda 함수를 시작하면 여러분의 VPC 외부에서 시작됩니다. VPC는 AWS가 제공하는 서비스죠.
따라서 여러분은 VPC 내에서 리소스에 액세스할 권한이 없습니다. RDS 데이터베이스, ElastiCache 캐시 내부 로드 밸런서를 시작하면 Lambda 함수가 해당 서비스에 액세스할 수 없습니다.
Lambda 배포의 기본 설정이에요. 인터넷의 퍼블릭 API에 액세스하는 것은 가능합니다. DynamoDB에 액세스할 수 있는 건 DynamoDB가 AWS 클라우드의 퍼블릭 리소스이기 때문입니다. 하지만 프라이빗 RDS 데이터베이스에는 연결할 수 없습니다.
이를 해결하려면 여러분의 VPC에서 Lambda 함수를 시작하면 됩니다. 이를 위해서는 VPC ID Lambda 함수를 시작하려는 서브넷을 지정하고 Lambda 함수에 보안 그룹을 추가해야 합니다.
그러면 Lambda가 서브넷에 엘라스틱 네트워크 인터페이스를 생성해 여러분의 VPC에서 실행되는 가령 Amazon RDS에 액세스할 수 있게 됩니다. Lambda 함수를 프라이빗 서브넷에 시작하는 방법을 알아보았습니다. 이렇게 하면 VPC 내 모든 항목에 비공개로 연결할 수 있습니다.
VPC에서 Lambda를 사용하는 대표적인 사용 사례는 RDS 프록시입니다. 따라서 RDS 데이터베이스가 프라이빗 서브넷에 있어도 Lambda 함수로 직접 해당 DB에 액세스할 수 있어요. 그런데 이런 방법으로 RDS 데이터베이스에 직접 액세스하면 큰 문제가 발생하게 됩니다 Lambda 함수의 수가 너무 많이 생성되었다 사라지길 반복하면 개방된 연결이 너무 많아서 RDS 데이터베이스의 로드가 상승해 시간 초과 등의 문제로 이어집니다.
이를 해결하는 방법은 RDS 프록시를 시작하는 것입니다. 이 프록시가 연결을 한곳으로 모으고 RDS 데이터베이스 인스턴스 연결의 수를 줄입니다. Lambda 함수가 RDS 프록시에 연결되고 RDS 프록시가 RDS DB 인스턴스로 연결되므로 아키텍처상의 문제가 해결됩니다
RDS 프록시에는 세 가지 장점이 있습니다
- 먼저 데이터베이스 연결의 풀링과 공유를 통해 확장성을 향상시킵니다.
- 또한 장애가 발생할 경우 장애 조치 시간을 66%까지 줄여 가용성을 향상시키고 연결을 보존합니다. RDS와 Aurora 모두에 적용되고요.
- 또한 RDS 프록시 수준에서 IAM 인증을 강제하여 보안을 높일 수 있고 자격 증명은 Secrets Manager에 저장됩니다.
Lambda 함수가 RDS 프록시에 연결할 수 있으려면 여러분의 VPC에서 Lambda 함수를 시작해야 합니다. 당연하죠, RDS 프록시는 퍼블릭 액세스가 불가능하므로 Lambda 함수를 퍼블릭으로 시작하면 RDS 프록시에 네트워크 연결을 할 수가 없습니다. 퍼블릭이 아니기 때문이죠. 이를 이해하면 시험에서 두세 문제 정도는 해결할 수 있을 겁니다
207. Amazon DynamoDB 개요
시험에서 아키텍처 관련해 자주 출제되는 데이터베이스인
Amazon DynamoDB를 알아보겠습니다
완전 관리형 데이터베이스로
데이터가 다중 AZ 간에 복제되므로 가용성이 높습니다
DynamoDB는 클라우드 네이티브이며
AWS의 독점 서비스입니다 NoSQL 데이터베이스이고요
RDS나 Aurora 같은 관계형 데이터베이스는 아니지만
트랜잭션 지원 기능이 있습니다
DynamoDB를 이용하면 방대한 워크로드로 확장이 가능합니다
데이터베이스가 내부에서 분산되기 때문입니다
초당 수백만 개의 요청을 처리하고
수조 개의 행, 수백 TB의 스토리지를 갖게 됩니다
이 점은 기억하셔야 합니다
성능은 한 자릿수 밀리초를 자랑하고 일관성 또한 높습니다
보안과 관련된 모든 기능은 IAM과 통합되어 있습니다
보안, 권한 부여, 관리 기능이 포함되고요
비용이 적게 들고 오토 스케일링 기능이 탑재돼 있습니다
유지 관리나 패치 없이도 항상 사용할 수 있습니다
데이터베이스를 프로비저닝할 필요가 없습니다
항상 사용할 수 있으므로 테이블을 생성해
해당 테이블의 용량만 설정하면 됩니다
테이블 클래스는 두 종류입니다
액세스가 빈번한 데이터에는 Standard 클래스
액세스가 빈번하지 않는 데이터는 IA 테이블 클래스에 저장합니다
DynamoDB는 테이블로 구성되며 데이터베이스를 생성할 필요가 없습니다
Aurora나 RDS와 달리
DynamoDB는 데이터베이스가 이미 존재하는 서비스입니다
DynamoDB에 테이블을 생성하면 각 테이블에 기본 키가 부여되는데
기본 키는 생성 시 결정됩니다
각 테이블에 데이터를 추가합니다 항목, 즉 행을 무한히 추가할 수 있어요
각 항목은 속성을 가지며 속성은 열에 표시됩니다
속성은 나중에 추가할 수도 있고 null이 될 수도 있습니다
상당한 장점이라고 할 수 있습니다 RDS나 Aurora 데이터베이스에서는
열을 나중에 추가할 수 있으나 과정이 복잡하고
스키마 전개가 어려울 수 있지만
DynamoDB에서는 사전 요구 사항 없이
나중에 쉽게 속성을 추가할 수 있습니다
DynamoDB 항목의 최대 크기는 400KB이므로
큰 객체를 저장할 때는 적합하지 않죠
DynamoDB는 다양한 데이터 유형을 지원합니다
문자열, 숫자, 바이너리, 불리언 null과 같은 스칼라 유형
목록, 지도와 같은 문서 유형과 세트 유형을 지원합니다
시험에서 스키마를 빠르게 전개해야 할 때 DynamoDB를
선택하면 아주 좋습니다
데이터의 유형과 구성 면에서 스키마를 빠르게 전개해야 할 때
Aurora나 RDS보다는 DynamoDB가 더 나은 선택입니다
시험 볼 때 이 점을 기억하세요
DynamoDB 테이블의 예시입니다
기본 키는 파티션 키와 선택 사항인 정렬 키로 구성되고요
속성 테이블이 있습니다
데이터베이스 형태입니다
속성은 null로 설정하거나 나중에 추가할 수 있습니다
DynamoDB의 장점이죠
DynamoDB를 사용하려면 읽기/쓰기 용량 모드도 설정해야 합니다
테이블 용량 관리 방식을 제어하는 데는
두 가지 모드가 있습니다
기본 설정은 프로비저닝된 모드로
미리 용량을 프로비저닝합니다
초당 읽기/쓰기 요청 수를 예측해서 미리 지정하면
그것이 테이블의 용량이 됩니다
미리 용량을 계획하고
프로비저닝된 RCU와 WCU만큼의 비용을 지불하는 방식입니다
RCU는 읽기 용량 단위 WCU는 쓰기 용량 단위를 뜻하고요
미리 용량을 계획한 경우에도 오토 스케일링 기능이 있으므로
테이블의 로드에 따라 자동으로 RCU와 WCU를
늘리거나 줄일 수 있습니다
프로비저닝된 모드는 로드를 예측할 수 있고 서서히 전개되며
비용 절감을 원할 때 적합합니다
다음은 온디맨드 모드인데요
온디맨드 모드에서는 읽기/쓰기 용량이 워크로드에 따라 자동으로 확장됩니다
미리 용량 계획을 하지 않으므로 RCU나 WCU 개념 자체가 없어요
온디맨드 모드에서는 정확히 사용한 만큼의 비용을 지불합니다
모든 읽기와 쓰기에 비용을 지불해야 하죠
비싼 솔루션으로 볼 수도 있지만
워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용합니다
시험에 나올 수 있어요 수천 개의 트랜잭션을
수백만 개의 트랜잭션으로 1분 내로 확장해야 하는 애플리케이션에서는
빠르게 확장되지 않는 프로비저닝된 모드는 적합하지 않습니다
온디맨드 모드를 선택해야겠죠
그러나 트랜잭션이 없거나 하루에 많아야 4~5회밖에 되지 않는 워크로드라면
트랜잭션 횟수만큼만 비용을 지불하는 온디맨드 모드가 적합할 겁니다
프로비저닝된 모드와 온디맨드 모드의 차이점과 주요 키워드를 잘 기억해서
적합한 모드를 선택하기 바랍니다
DynamoDB의 기초를 살펴봤습니다
유익하셨길 바라며 다음 강의에서 뵙겠습니다
