AWS SAA : Serverless

Serverless

서버를 관리할 필요가 없는 것 !

function을 deploy 하는 것

초기에는, Function as a Service 정도였지만

최근엔 서버를 프로비저닝하지 않는 모든 것을 의미함

Lambda

Lambda

• Virtual Function으로 관리할 서버가 없음 (코드만 provisioning)
• 실행하는 데 제한 시간이 있음 (15분)
• on-demand로 실행됨
• 자동 Scaling

장점

• Easy pricing : Lambda가 수신하는 요청의 횟수에 따라 과금
  • 호출 횟수, 컴퓨팅 시간 (실행된 시간) 에 따라 과금
• 다양한 AWS 서비스와 통합
  • API Gateway : Rest API 생성, 람다 함수 호출
  • Kinesis : 람다를 이용해 데이터 변환
  • DynamoDB : 트리거 생성하고, 트리거 발생 시 람다 작동
  • S3 : 언제든 작동 (파일 생성 등)
  • CloudFront : Lambda@Edge
  • CloudWatch Events, EventBridge : AWS 인프라에 문제가 생기고 그에 대응할 때 자동화 실행
  • CloudWatch Log : 어디든 해당 로그를 스트리밍
  • SNS : 알림과 SNS topic에 대처
  • SQS : SQS 대기열 메시지 처리
  • Cognito : 사용자가 로그인할 때마다 람다 호출
  ⇒ ex. Serverless CRON job
• 다양한 programming language와 통합
  • Node.js, Python, Java, C#, Golang, C# / Powershell, Ruby, Custom Runtime API (community supported), Lambda Container Image (컨테이너 이미지 자체가 람다 런타임 API를 구현하거나 / ECS와 Fargate에서 컨테이너 실행)
• CloudWatch를 통한 모니터링
• function당 최대 10GB의 램을 프로비저닝 가능
  • RAM 증가시키면 CPU, Network 성능도 함께 증가

Limits per region

• Execution Limit
  • 메모리 할당량 : 128GB - 10GB
  • 실행 시간 : 최대 900초
  • 환경 변수 : 최대 4KB
  • temp space (in /tmp) : 최대 10GB
  • 동시 실행 : 최대 1000개
• Deployment
  • 압축 시 최대 50MB, 비압축시 최대 250MB
    • 이 용량을 넘는 파일은 temp space (/tmp) 사용
  • 환경 변수 : 최대 4KB 한도

Lambda Snapstart

• lambda 함수의 성능을 높이기 위한 무료 기능
• Java 11 이상에서 실행되는 람다 함수들을 추가비용 없이 성능 최대 10배 높임
• Snapstart가 활성화되면, pre-initialized state 에서 invoke되어, 초기 initialization 단계를 스킵할 수 있음
• lambda가 function을 초기화하고, initialized function 상태의 메모리와 디스크 상태를 스냅샷함. 이 스냅샷이 캐시되어 저지연 액세스됨.

Customization At the Edge

• CloudFront를 사용할 때는 엣지 로케이션을 통해 콘텐츠 배포
• 이때, 전역으로 배포되기에 서버를 관리할 필요 없음
• 사용한만큼 지불
• Serverless
• 엣지 함수
  • 애플리케이션에 도달하기 전, 엣지 로케이션 실행되는 함수
  • CloudFront 배포에 연결됨
  • latency 줄이기 위해 user 근처에서 실행됨
• CloudFront의 Function
  • CloudFront Functions
    • 참고
      • Origin → CloudFront : Origin Request
      • CloudFront → Origin : Origin Response
      • Client → CloudFront : Viewer Request
      • CloudFront → Client : Viewer Response
    • JS로 작성된 경량함수로, Viewer Request, Response 수정
    • 초당 수백만개의 요청 처리
    • 확장성이 높고 지연 시간에 민감한 CDN customization에 사용
    • CloudFront의 Native feature
    • 최대 실행 시간 1밀리초
    • Cache Key normalization : 요청 속성 변화해 최적의 캐시 키 생성
    • Headeer manipulation : 요청이나 응답에 HTTP 헤더를 삽입, 수정, 삭제
    • URL rewrites, redirects
    • Request authentication & authorization (JWT 토큰 생성)
  • Lambda@Edge
    • NodeJS, Python으로 작성된 함수
    • 초당 수천개의 요청 처리
    • Origin Request, Origin Response, Viewer Request, Viewer Response 수정 가능
    • 함수는 us-east-1 리전에만 작성 가능
    • 함수 작성하면, CloudFront가 모든 로케이션에 대해 해당 함수 복제
    • 실행 기간이 5~10초
    • CPU, 메모리 증가 → 여러 라이브러리 로드 가능 : 타사 라이브러리에 코드 의존 가능
    • 네트워크 액세스를 통해 외부 서비스에서 데이터를 처리할 수 있어 대규모 데이터 통합 수행 가능
    • 파일 시스템이나 HTTP 요청 본문에 바로 액세스

Lambda의 Networking

• Lambda by default
  • VPC 외부에서 시작
    • public web 접근 가능
    • DynamoDB 접근 가능
  • VPC 내부의 리소스에는 접근이 불가능
    • Private RDS 접근 불가능
• Lambda in VPC
  • VPC ID, subnets, security group 정의
  • private subnets 내에 ENI (Elastic Network Interface) 생성
  • 따라서 VPC 내부의 리소스에도 접근이 가능함
• Lambda with RDS Proxy
  • Lambda function이 너무 많아지면 RDS에 high load 장애 발생 가능
  • 따라서 proxy에 RDS를 연결해서 리소스에 직접 연결하지 못하게 만듦
  • proxy의 기능
    • RDS 연결의 풀링과 공유를 통한 확장성 향상
    • 장애 발생 시, 장애 조치 시간을 줄여 가용성 향상, 연결 보존
    • RDS프록시 수준에서 IAM 인증 강요해 보안 높임

Lambda & Event

• Invoking Lambda from RDS & Aurora
  • DB instance에 lambda function invoke
  • DB에서 데이터 이벤트 처리 (데이터에 대한 정보 처리 가능)
  • lambda function 인바운드 허용 (←RDS)
  • RDS invoke 허용 (→ lambda function)
• RDS Event Notification
  • DB instance 자체에 대한 정보를 알려줌
  • DB 내 데이터에 대한 정보는 전혀 없음

DynamoDB

DynamoDB

• 완전 관리형, multi AZ에 데이터가 복제된 고가용성 DB
• 클라우드 네이티브
• NoSQL 데이터베이스, but 트랜잭션 지원
• 방대한 워크로드로 확장 가능, DB 분산 가능
• 초당 수백만개 요청 처리, 수조 개의 행, 수백 TB 스토리지
• 성능 : 한자릿수 밀리초, 일관성이 매우 높음
• 보안과 관련된 기능은 IAM 과 통합됨
• 비용이 적게 들고 오토 스케일링 가능
• 테이블로 구성되며, DB를 생성하지 않음 (DB 프로비저닝 X)
• 테이블을 생성하면, 해당 테이블의 용량만 설정
  • 테이블 클래스
    • Standard Class : 액세스가 빈번한 데이터
    • IA Table Class : 액세스가 빈번하지 않은 데이터
  • 테이블 Primary key : 생성시 결정되는 기본키
    • Partition Key
    • Sort Key (Optional)
  • 테이블에 데이터 추가 : 항목 (행)을 무한히 추가, 항목은 속성을 가지며 속성은 열에 표시됨. 데이터 사이즈는 최대 400KB
• 데이터의 유형과 구성 면에서 스키마를 빠르게 전개해야할 때 사용
• 읽기/쓰기 용량 모드 설정
  • Provisioned Mode (default) : 초당 읽기(RCU), 쓰기 횟수(WCU)를 예측해 미리 용량을 프로비저닝. 이후 Auto-scaling 기능을 통해 조절 가능.
  • On-Demand Mode : 읽기/쓰기 용량이 워크로드에 따라 자동으로 확장. 미리 용량 계획하지 않음. 정확히 사용한만큼의 비용을 지불. 워크로드를 예측할 수 없거나 급격히 증가할 때 사용.

DynamoDB Accelerator (DAX)

• 고가용성의 완전 관리형 무결절 인메모리 캐시
• DynamoDB 테이블에 읽기 작업이 많을 때, DAX 클러스터를 생성하고 데이터를 캐싱해 읽기 혼잡 해결
• DAX는 캐시 데이터에 마이크로초 수준의 latency 가짐
• 기존 DynamoDB API와 호환 → 애플리케이션 로직 변경 필요 X
• 캐시 TTL : 5분 (기본), 변경 가능
• DAX vs ElastiCache
  • DAX
    • 개별 객체 / 쿼리 / 스캔 캐시 처리에 유용
    • 대용량 연산 저장
  • ElastiCache
    • 집계 결과 저장

DynamoDB Stream Processing

• 테이블의 모든 수정 사항 (생성, 업데이트, 삭제)에 대한 스트림 생성
• Use case
  • 테이블 수정 사항에 대해 실시간으로 반응
  • 실시간 사용 분석
  • 파생 테이블 삽입
  • 리전 간 복제 실행
  • DynamoDB 테이블 변경 사항에 대해 lambda function 실행
• 스트림 처리 방식
  • DynamoDB Streams
    • 보존 기간 24시간
    • 소비자 수 제한
    • Lambda 트리거와 함께 사용하면 좋음
    • 자체적 읽기 실행을 위해 DynamoDB Stream Kinesis 어댑터 사용
  • Kinesis Data Streams
    • 보존 기간 1년
    • 소비자 수 더 많음
    • 데이터 처리 방법이 더 많음

DynamoDB Global Tables

• 여러 리전 간 복제가 가능한 테이블
  • 각 리전의 테이블은 양방향 복제 가능
• 복수의 리전에서 짧은 지연시간으로 액세스
• 다중 활성 복제 가능 → 애플리케이션이 모든 리전에서 테이블 READ, WRITE
• DynamoDB Stream을 활성화해야 Global Table 활성화 가능

DynamoDB Time To Live (TTL)

• 만료 타임스탬프가 지나면 자동으로 항목을 삭제
• Use case
  • 최근 항목만 저장
  • 개인정보 규정을 따라야 할 때
  • 웹 세션 핸들링 : 사용자가 웹사이트에 로그인했을 때 2시간동안 세션 유지

DynamoDB - Backup for disaster recovery

• Continuous backups using point-in-time recovery (PITR)
  • 활성화 선택 가능
  • 35일동안 지속
  • 활성화하면 백업 기간 내에는 언제든 실행 가능
  • 복구 진행 시, 새로운 테이블 생성
• On-Demand Backup
  • 직접 삭제할 때까지 보존됨
  • DynamoDB의 성능이나 latency에 영향 X
  • AWS Backup Service : 백업에 수명 주기 정책 활성화, 리전 간 백업 복사
  • 복구 진행 시, 새로운 테이블 생성

DynamoDB and S3 Integration

• table export to S3 ← PITR 활성화해야 함
  • S3에 쿼리하고 싶다면, Athena를 이용
  • 최근 35일 이내 어떤 시점으로든 테이블 export 가능
  • 기존 테이블의 읽기 용량, 성능에 영향 X
  • 감사 목적으로 스냅샷 확보
  • 데이터를 DynamoDB를 가져오기 전에 데이터 ETL 등 대규모 변경 가능
  • DynamoDB JSON, ION 형식 이용
• table import from S3
  • S3에서 CSV, JSON, ION 형식으로 내보낸 다음 새로운 테이블 생성
  • 가져올 때 발생한 오류는 모두 CloudWatch Log에 저장
  • Write Capacity에 영향 X

API Gateway

REST API를 생성하는 AWS의 서버리스 서비스 → 클라이언트가 퍼블릭 액세스

기능

• Lambda + API Gateway → 완전 서버리스 애플리케이션, 인프라 관리 필요X
• WebSocket 프로토콜 지원
• API Versioning 핸들링 → 클라이언트 연결 끊기지 않음
• Environment 핸들링 → dev, test, prod
• Security 핸들링 → Authentication, Authorization 활성화
• API Key 생성
• 과도한 요청 처리
• Swagger, Open API 등 공통 표준 사용해 신속한 API 정읙 ㅏ능
• API Gateway 수준에서 request, response를 변환하고 유효성 검증
• SDK, API specification 생성
• API 응답 캐싱

Integrations

• Lambda Function
  • invoke lambda function
  • Lambda를 사용하는 REST API를 완전 서버리스 애플리케이션에 노출
• HTTP
  • 백엔드의 HTTP Endpoint 노출
  • 온프레미스에 HTTP API가 있거나, 클라우드 환경에 ALB가 있을 때 다양한 기능 추가 가능
• AWS Service
  • 어떤 AWS API라도 노출 가능

Endpoint Type

• Edge-Optimized (default) : For global clients
  • 모든 요청이 CloudFront Edge Location을 통해 라우팅→ 지연 시간 개선
  • API Gateway는 생성된 리전에 위치, 모든 엣지에서 액세스됨
• Regional
  • 모든 요청은 API Gateway가 생성된 리전과 같은 리전에 있어야 함
  • 자체 CloudFront 배포 가능
• Private
  • VPC 내에서만 액세스 ← ENI 같은 인터페이스 VPC Endpoint를 활용
  • API Gateway에 액세스 정의할 때는 리소스 정책 사용

Security

• User Authentication
  • IAM Roles (internal application에 적용)
  • Cognito (외부 사용자에 대해 적용)
  • Custom Authorizer (자체 로직, lambda)
• Custom Domain Name HTTPS
  • AWS Certificate Manager (ACM)에 Domain Name 등록
  • Edge-Optimized endpoint 사용하면, 인증서는 us-east-1에 등록
  • Regional endpoint 사용하면, 인증서는 API gateway와 같은 리전 등록
  • Route53에 CNAME과 A-alias 레코드 설정

Step Functions

서버리스 워크플로를 시각적으로 구성하는 기능

람다 함수를 오케스트레이션하는데 사용

기능

• Sequence
• Parallel
• Condition
• Timeout
• Error Handling
• EC2, ECS, On-premise server등에도 통합 가능
• 워크플로에 사람이 개입해 승인해야하는 작업도 구현 가능

Cognito

사용자(AWS 외부)에게 웹, 앱과 상호작용할 수 있는 자격 증명 부여

• Cognito User Pool (CUP)
  • 앱 사용자에게 가입 기능 제공
    • 웹 및 앱을 대상으로 하는 서버리스 사용자 DB
    • 간단한 로그인 절차 정의 가능
    • 비밀번호 재설정 기능
    • 이메일, 전화번호 검증
    • MFA 사용자 인증
    • Facebook, Google 등 소셜 로그인 통합
  • API Gateway 및 ALB와 원활히 통합
    • 방법 1
      1. 사용자는 CUP에 접속해 토큰을 받음
      2. 검증을 위해 토큰을 API Gateway에 전달
      3. 확인이 끝나면 user identity로 전환됨
      4. Lambda 함수는 처리할 사용자가 잘 인증된 구체적인 사용자라는 사실을 인식하게 됨
    • 방법 2
      • CUP를 ALB 위에 배치
  • 
• Cognito Identity Pools (Federated Identity)
  • 앱에 등록된 사용자에게 임시 AWS 자격 증명을 제공해 직접 또는 API Gateway를 통해 일부 AWS 리소스에 액세스할 수 있게 해줌
  • Cognito User Pool과 원활히 통합
  • 사용자는 Cognito User Pool이 될수도 있고 3rd party 로그인일수도

⇒ 시험에서 ‘hundred of users’, ‘mobile users’, ‘authenticate with SAML’ 나오면 cognito 생각할 것