AWS Certified Solutions Architect Associate [14] 서버리스

Serverless

Serverless?

• 서버리스 서비스를 사용하는 개발자는 서버를 관리할 필요가 없습니다.
• 서버가 없다는 것은 아니고 관리할 필요가 없다는 뜻이죠.
  • 그냥 코드를 배치하면 됩니다 함수를 배치하는 거예요.
• 원래 서버리스는 FaaS, 즉 Function as a Service를 뜻했지만
  지금의 서버리스는 더 많은 것을 의미합니다.
• 서버리스가 처음 개발된 건 AWS Lambda
• 데이터베이스, 메시징, 스토리지 등
  서버를 프로비저닝 하지 않는 모든 것들을 포함합니다.
• 서버리스란 서버가 없는 게 아니라
  서버가 보이지 않거나 서버를 프로비저닝 하지 않는 겁니다.
  
  
• AWS 안에 서버리스
  • AWS Lambda
  • DynamoDB
  • AWS Cognito
  • AWS API Gateway
  • Amazon S3
  • AWS SNS & SQS
  • AWS Kinesis Data Firehose
  • Aurora Serverless
  • Step Functions
  • Fargate

---

AWS Lambda

AWS Lambda

• 람다는 가상의 함수입니다.
• 관리할 서버 없이 코드를 프로비저닝하면 함수가 실행되는 겁니다.
• 제한 시간이 있어서 실행 시간이 짧습니다. (15분)
• 온디맨드로 실행됩니다.
• 비용 역시 함수가 실행되는 동안만 청구됩니다.
• 마지막으로 스케일링이 자동화됩니다.
  
  
• 장점 :
  • 과금이 쉽습니다.
    • Lambda가 수신하는 요청의 횟수 즉, 호출 회수와 컴퓨팅 시간 = Lambda가 실행된 시간만큼.
    • 프리 티어에서 Lambda 요청 1백만 건과 40만 GB-초의 컴퓨팅 시간 제공합니다.
  • 다양한 AWS 서비스와 통합됩니다.
  • Lambda에 여러 가지 프로그래밍 언어를 사용할 수 있어서 상당히 자유로운 편
  • CloudWatch와의 모니터링 통합도 쉽습니다.
  • 함수당 최대 10GB의 램을 프로비저닝 할 수 있습니다.
  • 만약 함수의 RAM을 증가시키면
    CPU 및 네트워크의 품질과 성능도 함께 향상될 것입니다.
    
    

EX)

• 썸네일 생성
  
• 서버리스 CRON 작업
  

---

Lambda가 지원하는 언어

• Node.js (JavaScript)
• Python
• Java (Java 8 compatible)
• C# (.NET Core)
• Golang
• C# / Powershell
• Ruby
• Custom Runtime API (community supported, example Rust)
• Lambda Container Image
  • 컨테이너 이미지는 Lambda 런타임 API에서 실행되야 합니다.
  • ECS나 Fargate에서 컨테이너를 실행해야 합니다

---

AWS Lambda 통합

---

Lambda 제한

리전마다의 제한

• 실행 제한
  • 메모리 할당이 128MB에서 10GB입니다.
  • 단위는 1MB씩 증가합니다.
  • 최대 실행 시간은 900초 다시 말해 15분입니다.
  • 환경 변수로 최대 4KB를 가집니다.
  • 큰 파일을 끌어와야 한다면 임시 공간을 사용할 수 있는데, 크기는 512MB입니다.
  • 최대 1000건까지 람다 함수의 동시 실행이 가능하고 요청에 따라 늘어날 수 있습니다.
• 배치 제한
  • 압축된 zip의 최대 크기는 50MB
  • 압축되지 않으면 250MB
  • 이보다 더 큰 파일에는 대신 /tmp 공간을 사용해야 합니다. (임시공간)
  • 환경 변수는 동일하게 4KB입니다.

---

Lambda@Edge

CloudFront를 통해 CDN을 배치했는데
만약 엣지 로케이션마다 글로벌 람다 함수를
실행하고 싶다면 어떻게 할까요?
혹은 어떻게 요청 필터링을 애플리케이션 도착 전에 구현할 수 있을까요?

• Lambda@Edge 를 사용하세요.
• Lambda@Edge는 CloudFront CDN을 통해서
  특정 리전이 아닌 전 세계의 모든 리전에 람다 함수를 배치합니다.
  • 응답성이 뛰어난 애플리케이션을 구축하기 위해서 입니다.
  • 서버 관리할 필요 없이 글로벌적으로 람다가 배치됩니다.
  • CDN을 통해 전송되는 콘텐츠를 사용자 지정할 수 있고 사용량만큼 청구되기 때문입니다.

---

Lambda@Edge

• Lambda는 CloudFront의 요청과 응답을 변경합니다.
  

• 오리진으로 아무런 요청을 보내지 않더라도 뷰어로의 응답을 만들어낼 수 있습니다.

• 사용 :

  • 웹 사이트 보안 및 프라이버시
  • 엣지의 동적 웹 애플리케이션
  • 검색 엔진 최적화
  • SEO
  • 오리진 및 데이터 센터 사이의 지능적 경로
  • 엣지에서의 봇 활동 완화
  • 실시간 이미지 변환
  • A/B 테스트
  • 오리진 도달 전의 사용자 인증 및 권한 부여
  • 사용자 우선순위 지정 사용자 추적 및 분석

---

DynamoDB

DynamoDB

• 완전 관리형 데이터베이스
• 고가용성
• 데이터가 자동으로 여러 가용 영역에 복제됩니다.
• NoSQL 데이터베이스
• 대량 워크로드로 확장할 때 사용합니다.
• 분산형 데이터베이스라 수평 확장을 하며 용량이 뛰어나요.
• 성능이 빠르고 일관적이라서
  내부에서 프로비저닝을 많이 할 필요도 없습니다.
• DynamoDB API는 IAM과 완전 통합
• DynamoDB Stream은 이벤트 기반 프로그래밍에도 적합합니다.
• 용량 요구사항과 관련하여 저렴한 가격 및 오토 스케일링 능력
• Standard와 Infrequent Access(IA) 테이블 클래스

---

DynamoDB - Basics

• 테이블로 구성
• 데이터베이스가 아님.
• 각 테이블에 기본 키가 있고 이는 테이블 생성 시 결정됩니다.
• 각 테이블의 행이 무한합니다.
• 각 아이템(행)에는 속성이 있으며 간단하게는 이 속성이 바로 열이 됩니다.
  • 열은 시간에 따라 추가될 수 있습니다.
• DynamoDB의 최대 아이템 크기는 400KB입니다.
  • 즉 DynamoDB는 큰 객체를 저장하기에 좋지 않습니다.
• DynamoDB가 지원하는 데이터
  • 문자열
  • 숫자
  • 바이너리
  • Boolean
  • NULL
  • 리스트
  • Map
  • 문자열 세트
  • 숫자 세트
  • 바이너리 세트

---

읽기/쓰기 용량 모드

• 테이블의 용량을 제어하는 방법
• 프로비저닝 모드
  • 기본값
  • 테이블에 필요하다고 생각되는 초당 읽기 및 쓰기의 횟수를 미리 지정하는 겁니다.
  • 사전에 용량을 계획하는 것
  • 프로비저닝한 만큼 과금
  • 매달 지불할 비용은 프로비저닝한 RCU와 WCU의 양만큼 달라집니다.
  • 또한 RCU와 WCU에 대해 오토 스케일링이 가능합니다.
• 온 디맨드 모드
  • 워크로드에 따라 자동으로 읽기와 쓰기를 스케일 업/다운합니다.
  • 읽기 용량 단위나 쓰기 용량 단위가 없고 모든 읽기와 쓰기를 자동으로 허용하죠.
    • 정확히 사용량만큼 과금됩니다.
  • 훨씬 비싸서 프로비저닝 모드 비용의 두 세배는 될 정도입니다.
  • 아주 예측하기 힘든 워크로드에 사용합니다.

---

DynamoDB Accelerator (DAX)

• 완전 관리형
• 고가용성
• 무결절성
• DynamoDB 인 메모리 캐시
  • 가장 많이 읽은 데이터를 캐시에 저장해 읽기 혼잡을 해결할 수 있습니다.
• 애플리케이션 로직을 변경할 필요가 없습니다.
• 데이터 인덱스는 5분간 저장되고
  5분이 지나면 데이터는 만료되며
  DynamoDB에서 새로고침이 됩니다.

DynamoDB의 데이터를 빠르게
저장하고 읽는 애플리케이션이 필요한데
애플리케이션 로직을 못 변경하는 상황을 제시한다면

DAX

---

DAX와 ElastiCache

---

DynamoDB Streams

• 테이블의 항목 수정을 표시하는 정렬된 데이터 스트림
• 항목을 생성하고 업데이트 및 삭제할 때마다 DynamoDB Stream으로 이동합니다.
• Stream record
  • Kinesis Data Streams 에 보냅니다.
  • Kinesis Data Stream Lambda에서 읽을 수 있습니다.
• 최대 24시간 동안 보존되며 원하면 빠른 처리가 가능합니다.
• 사용 :
  • 데이터 실시간 변화에 대응
  • 분석
  • 파생 테이블을 DynamoDB에 삽입
  • ElasticSearch에 삽입
  • 리전 간 복제

---

DynamoDB Global Tables

• 여러 리전에 걸쳐 데이터를 이용할 때 지연 시간을 줄이려고 하는 겁니다.
• 다중 활성 복제
• 애플리케이션이 모든 리전에서 테이블을 읽고 쓸 수 있습니다.
• 글로벌 테이블을 활성화하려면 꼭 필요한 전제 조건이 바로 DynamoDB Stream인데
  변경 로그 업데이트 덕분에 각 테이블이 서로를 업데이트하며 양방향 복제가 가능합니다.

---

DynamoDB – Time To Live (TTL)

• Time To Live (TTL)를 사용하면 타임스탬프 만료 후에 자동으로 아이템을 삭제할 수 있습니다.
• 테이블 크기 통제가 가능합니다.
• 규제 의무가 있어서 특정 테이블의 데이터를 7일만 보관해야 하는 경우 사용할 수 있겠지요.

---

DynamoDB - Indexes

• GSI와 LSI 두 가지가 있는데 각각 글로벌 보조 인덱스와 로컬 보조 인덱스입니다.
• DynamoDB 테이블의 인덱스는
  기본 키 말고도 여러 속성에 쿼리를 수행할 수 있습니다.

---

DynamoDB - Transactions

• **트랜잭션을 통해 동시에 두 테이블에 쓰거나 아무 테이블에도 쓰지 않을 수 있습니다.

---

서버리스 API

• 클라이언트가 람다 함수를 불러오는 방법
• AWS에서 제공하는 서버리스 서비스
• 클라이언트가 접근 가능한 공용 REST API를 생성할 수 있게 해줍니다.
• API Gateway의 장점은 람다 함수에 오는 요청을 프록시해 준다는 것입니다.
• API Gateway를 사용하는 이유는 HTTP 엔드 포인트보다 많은 기능을 제공하기 때문입니다.

AWS API Gateway

• AWS Lambda + API Gateway
  • 인프라를 관리할 필요가 없습니다.
• WebSocket 프로토콜도 지원합니다.
• API Gateway가 API 버전 관리를 맡습니다.
• 개발 및 테스트, 운영 환경도 관리합니다.
• API Gateway 보안 활성을 위한 수단이 많습니다.
  • 인증 및 권한 부여
• API 키를 생성하거나 쓰로톨링을 조절합니다.
• Swagger, Open API 3.0 등
  일반적인 스탠다드를 이용해 정의된 API를 빠르게 가져오고 내보낼 수도 있습니다.
• 요청과 응답을 변형하거나 유효화할 수 있습니다.
• SDK와 API 사양을 생성하고 API 응답을 캐시에 저장하기도 합니다.

---

API Gateway – Integrations High Level

• Lambda 함수
  • 람다 함수 호출합니다.
  • 람다 함수가 지원하는 REST API를 노출하는 제일 간단하고 흔한 방법입니다.
• HTTP
  • 백엔드의 HTTP 엔드 포인트도 노출할 수 있습니다.
  • 온프레미스 HTTP API, 클라우드 환경에 있는 애플리케이션 로드 밸런서
  • 비율 제한과 캐싱 사용자 인증, API 키를 이용할 수 있습니다.
• AWS Service
  • API Gateway로 어떤 AWS API든 노출 가능합니다.
  • 인증을 추가하고 API를 공용으로 배포하거나 AWS 서비스상 비율 제어를 위해서 입니다.

---

API Gateway 배포 방법

• Edge-Optimized (default)
  • 엔드 포인트 타입
  • 글로벌 클라이언트를 위한 것
  • 모든 CloudFront 엣지 로케이션에서 요청 라우팅으로 지연 시간을 개선합니다.
• 리전 배포
  • 모든 사용자가 API Gateway를 생성한 리전이 있으면 직접 배포 플랫폼을 마련해도 좋습니다.
  • 캐싱 전략과 CloudFront 설정을 더 잘 제어할 수 있습니다.
• Private 배포
  • 개인 API Gateway는 VPC를 통해서만 액세스가 됩니다.
  • 인터페이스 VPC 엔드 포인트를 ENI에 사용합니다.
  • 리소스 정책을 이용해 API Gateway 액세스를 정의합니다.

---

API Gateway – Security

• IAM Permissions
  • 인프라에서 API 접근 권한을 부여할 때 아주 유용합니다.
  • AWS 외부의 사용자에게 권한을 부여해야 한다면 IAM을 사용할 수 없습니다.
  • Sig v4
• Lambda 권한 부여자
  Custom Authorizer
  • 요청의 헤더로 보내지는 토큰을 유효화하는 데에 Amazon Lambda를 사용합니다.
  • 인증 결과를 캐시에 저장할 수 있습니다.
  • OAuth, SAML 등의 타사 인증을 쓰는 경우에 사용됩니다.
  • 람다는 권한 부여 결과로 IAM 정책을 사용자에게 반환해야 합니다.
• Cognito User Pools
  • Cognito가 사용자의 수명 주기를 전부 관리합니다.
  • API Gateway는 AWS Cognito에서 자동으로 신원을 증명합니다.
  • 전부 대신 실행해 주며 무료입니다.
  • 인증에만 관여하고 권한 부여는 돕지 못합니다.
    • 소통 중인 사용자가 실제로 본인이 맞는지만 확인해줍니다.

---

AWS Cognito

• Cognito는 사용자에게 자격을 부여해 서버나 애플리케이션과 상호작용 하도록 합니다.
• Cognito 사용자 풀
  • 애플리케이션 사용자용 로그인 기능
  • API Gateway와 통합
• Cognito 자격 증명 풀 (페더레이션 자격 증명 풀)
  • AWS 자격 증명을 직접 애플리케이션 사용자에게 제공해 AWS 리소스에 직접 액세스하도록 합니다.
  • 역시 자격 증명 제공자로서 Cognito 사용자 풀과 통합합니다.
• Cognito 동기화
  • 장치에서 Cognito로 데이터를 동기화하는 것입니다.
  • AppSync로 대체됐습니다.

---

Cognito 사용자 풀

• 모바일 애플리케이션용 서버리스 사용자 데이터베이스
• 사용자명이나 이메일 비밀번호를 조합해 쉽게 로그인합니다.
• 이메일이나 핸드폰 번호를 인증할 수 있습니다.
• 멀티팩터 인증을 추가하거나 비밀번호 정책을 만들고 페더레이션 자격 증명 활성화도 가능합니다. (Facebook, Google, SAML)
• JWT라고 불리는 JSON 웹 토큰
• API Gateway와는 인증을 위해 통합이 가능합니다.

---

페더레이션 자격 증명 풀

• 클라이언트 측에서 AWS 환경으로 직접 액세스하도록 유도하는 겁니다.
• 페더레이션 자격 증명 제공자에 로그인하거나 익명을 유지해도 됩니다.
• 이런 자격 증명에 함께 달려 오는 IAM 정책에 기반해 작업할 수 있는데요.

---

AWS SAM - Serverless Application Model

• SAM은 서버리스 애플리케이션 모델을 의미합니다.
• 서버리스 애플리케이션을 배포하고 개발하는 프레임워크
• YAML 코드로 진행됩니다.
• 람다 함수나 DynamoDB 테이블 API Gateway, Cognito 사용자 풀을 구성할 수 있습니다.
• SAM은 람다 함수와 API Gateway며 DynamoDB 테이블을 긴밀하게 도와서 디버깅을 할 수 있게 합니다.
• SAM은 CodeDeploy와 통합해서 람다 함수를 빠르게 배포하도록 해줍니다.

---

From
AWS Certified Solutions Architect Associate 시험합격!