AWS Serverless

Serverless

• 서버가 없다는 것이 아닌 관리할 필요가 없다는 것
  • 단순히 코드만 배치하면 된다 → 함수를 배치
  • FaaS Function as a Service라는 뜻도 있었지만 지금은 더 많은 뜻을 가진다
• 서버리스는 원격 관리되는 모든 것을 의미한다
• 서버를 프로비저닝하지 않는 것 or 서버가 보이지 않는 것

 

AWS in Serverless

프로비저닝하지 않고 완전 관리형 서비스들을 서버리스 개념으로 이해할 수 있다.

서버리스 개념은 현재 중요하게 사용되는만큼 시험에서도 자주 출제됨

• AWS Lambda
• DynamoDB
• AWS Cognito
• AWS API Gateway • Amazon S3
• AWS SNS & SQS
• AWS Kinesis Data Firehose • Aurora Serverless
• Step Functions
• Fargate

 

AWS Lambda

• 관리할 서버가 없다 → (가상함수로 코드를 프로비저닝)
• 제한 시간이 있어 실행 시간이 짧다
• 온디맨드로 실행
• 스케일링 자동화

 

Benefits of AWS Lambda

• 가격 정책이 매우 쉬워진다 → 실행시간 + 요청 횟수만큼 청구
  • 프리티어에서 넉넉하게 제공해줌
• 다양한 AWS 서비스와 통합되며 많은 프로그래밍 언어와 통합
• CloudWatch와 모니터링 통합도 간단
• 더 많은 리소스가 필요하다면 최대 10GB램을 프로비저닝 가능
• 함수의 RAM을 증가시키려면 CPU와 네트워크 성능 또한 향상된다

 

람다가 지원하는 언어

• Node.js (JavaScript)
• Python
• Java (compatible with Java 8)
• C# (.NET Core)
• Golang
• C# / Powershell
• Ruby
• Custom Runtime API - example Rust
• Lambda 컨테이너 이미지를 지원한다
  • 컨테이너 이미지 자체가 Lambda의 런타임 API를 구현해야한다.
    • 컨테이너 이미지를 만들 때 전제 조건이 필요하다 (런타임 API)
  • ECS와 Fargate는 계속 임의의 도커 이미지를 실행할 때 더 많이 사용된다
    • Lambda 런타임 API가 구현되지 않으면 ECS and Fargate 사용해야함

 

AWS Lambda Integrations Main ones

• API Gateway: REST API를 생성하여 람다 함수 호출
• Kinesis: Lambda를 이용해 즉시 데이터 변환
• DynamoDB: 데이터베이스에 트리거를 통해 람다 함수실행
• S3: 언제든 람다 함수를 작동 가능
• CloudFront: Lambda@Edge Part
• CloudWatch Evnets, EventBridge: AWS의 인프라에 어떤 일이 생기고 그 상황에 대응하고자 할 때 상황에 따라 자동화를 하기 위해 람다 함수를 쓴다
• CloudWatch Logs: 어디든 해당 로그를 스트리밍
• SNS: 알림과 SNS 토픽을 처리할 수 있음
• SQS: SQS 대기열 메시지 처리 가능
• Cognito: 사용자가 데이터베이스에 로그인할 때 마다 응답

 

람다 예시

Serverless Thumbnail creation

 

Serverless CRON Job

• 인스턴스 시간을 낭비하지 않고 이벤트 브릿지 트리거를 활용해 작업을 수행

람다로 코드를 실행하면 매우매우 저렴해진다

람다는 대규모 작업에 적절한 비용절감 메커니즘으로 활용 가능

 

 

AWS Lambda Limits to Know(한도)

한도는 리전당 존재하며 두 가지 한도가 있다

 

Execution 한도

• 메모리 할당량은 128MB ~ 10GB 1GB씩 증가 가능
• 메모리가 증가하면 더 많은 vCPU가 필요
• 최대 실행시간은 900초
• 환경변수는 4KB
• 람다 함수를 생성하는 동안 큰파일을 가져올 떄 사용할 수 있는 임시 공간이 있다
  • /tmp 크기는 512MB to 10GB
• 최대 1000개까지 동시 실행 가능(늘릴 수 있다)

 

Deployment 한도

• 압축시 최대 크기는 50MB 비압축시 250
  • 용량을 넘기는 경우 /tmp 디렉터리 이용해야함
• 배포시에도 한도는 4KB

 

Lambda@Edge & CloudFront Functions

• 모던 애플리케이션은 애플리케이션에 도착하기 전 Edge에서 특정 로직을 실행하도록 요구하기도 한다
  • 이를 엣지 함수라고 하며 CloudFront 배포에 연결하는 코드
  • 사용자 근처에서 실행하여 지연시간을 최소화하는 것이 목적
• CloudFront Functions와 Lambda@Edge로 나뉨
• 엣지 함수를 사용하면 서버 관리 필요 없다 → 전역적으로 배포되기 때문임
• CloudFront의 CDN 컨텐츠를 사용자 지정하는 경우
• 사용한 만큼만 비용을 지불

 

Lambda@Edge & CloudFront Functions 사용 사례

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

사용자 지정에 활용 된다

 

CloudFront Functions

뷰어 요청 → 클라이언트가 CloudFront에 요청

Origin 요청 → CloudFront가 서버에 요청

응답도 마찬가지이다

• Javascript로 작성된 경량 함수
• 높은 확장성, 적은 지연시간에 민감한 CDN 사용자 지정에 사용됨
• 초당 백만 개의 요청을 처리
• 뷰어 요청과 응답을 수정할 떄만 사용
  • Viewer Request: CloudFront가 클라이언트로부터 요청을 받은 다음에 뷰어 요청 수정 가능
  • Viewer Response: 클라이언트에게 응답을 보내기 전에 뷰어 응답을 수정 가능
• 모든 코드가 CloudFront에서 직접 관리 → 고성능, 고확장성 + 뷰어 요청/응답에만 사용

 

Lambda@Edge

• NodeJS or Python
• 초당 1000개 요청 처리 가능
• 모든 CLoudFront 요청 및 응답 변경 가능
  • Viewer Request: CloudFront가 클라이언트로부터 요청을 받은 다음에 뷰어 요청 수정
  • Viewer Response: 클라이언트에게 응답을 보내기 전에 뷰어 응답을 수정
  • Origin Request: CloudFront가 오리진에 요청을 전송하기 전 수정
  • Origin Response: CloudFront가 오리진에서 응답을 받은 후 수정
• 함수는 하나의 리전에서 작성(CloudFront 배포를 관리하는 리전), CloudFront가 모든 로케이션에 함수를 복제한다

 

CloudFront Functions vs Lambda@Edge

CloudFront Functions → 경량이라 요청도 많이 처리하지만 실행 시간이 짧고 한정적

Lambda@Edge → 요청은 적제 처리하지만 실행 시간이 길고 트리거도 다양함

 

CloudFront Functions vs Lambda@Edge - 사용사례

CloudFront Functions

• 캐시 키 정규화 → 최적의 캐시 키 생성
• 헤더 조작 → HTTP 헤더 삽입 수정 삭제
• URL을 다시 쓰거나 리디렉션을 수행
• 요청 인증과 권한 부여를 위해 JWT 토큰을 생성하거나 검증해서 요청을 허가/거부함

 

Lambda@Edge

• 실행시간이 CloudFront Functions보다 길다 10sec
• CPU, 메모리가 증가하므로 여러 라이브러리 로드 가능
• 타사 라이브러리에 의존 가능 (AWS SDK를 통한 AWS 서비스 엑세스 가능한 것처럼..)
• 네트워크 엑세스를 통해 외부 서비스에 데이터 처리 요청도 가능 → 대규모 통합
• 파일시스템이나 HTTP 요청 본문에도 바로 엑세스 가능
• 다양한 사용자 지정

 

Lambda in VPC

• 사용자의 VPC외부에서 사용한다 → VPC는 AWS가 소유하고 있어 접근이 불가능
• 사용자 VPC에서 실행 중인 여러 서비스에 Lanbda가 엑세스할 수 없다

이러한 옵션이 기본 설정되어 있음

 

따라서 이 문제를 해결하려면 사용자의 VPC에서 람다 함수를 시작하면 된다.

→ 기본설정이 AWS VPC로 되어있음

 

VPC ID로 람다함수를 시작하려는 서브넷을 지정하고 람다 함수에 보안그룹을 추가해야 한다

 

그러면 람다가 서브넷에 ENI(Elastic Network Interface)를 생성해 사용자의 AWS 서비스에 엑세스가 가능하다.

이렇게 하면 VPC내 모든 항목에 비공개로 연결이 가능하다

 

 

Usecase - Lambda with RDS Proxy

RDS가 Private Subnet에 있어도 람다 함수로 직접 해당 RDS 인스턴스에 접근 가능하다.

 

하지만 이런 방식을 사용하게 되면 람다 함수가 계속 생성되었다가 사라지길 반복하면서 개방된 연결이 너무 많아 RDS 데이터베이스의 로드가 상승해 여러 문제로 이루어진다

 

이를 해결하는 방법이 RDS 프록시를 시작하는 것이다

연결을 모아서 RDS 인스턴스 연결을 줄인다

 

RDS proxy

• 데이터베이스 연결의 풀링과 공유를 통해 확장성을 향상
• 장애가 발생할 경우 장애 조치시간을 66%까지 줄여 가용성 향상시킨다
• IAM 인증을 강제하여 보안을 높이고 자격 증명은 Secrets Manager에 저장

람다 함수가 RDS 프록시에 연결될 수 있으러면 반드시 사용자의 VPC내에서 실행되어야 한다.

 

RDS 프록시는 퍼블릭 엑세스가 불가능해서 람다 함수를 퍼블릭(기본)으로 시작하면 RDS 프록시 네트워크에 연결할 수 없다 → RDS는 프라이빗이기 때문

 

Amazon DynamoDB

• 완전 관리형 데이터베이스로 데이터가 다중 AZ간 복사된다
• NoSQL 데이터베이스지만 트랜잭션 지원
• 방대한 워크로드로 확장 가능, 동시에 분산 데이터베이스이다
• 초당 수백만 개의 요청, 수백 TB의 스토리지
• 한 자릿수 밀리초의 속도와 일관성이 높다
• 보안과 관련된 모든 기능은 IAM과 통합되어 있다
• 비용이 적게들고 오토 스케일링이 가능
• 유지관리나 패치 없이도 항상 사용 가능
• 데이터베이스를 프로비저닝 할 필요 없다
• Standard / IA 클래스로 나뉜다

 

DynamoDB 기본

• 테이블로 구성되며, 데이터베이스를 따로 생성할 필요는 없다.
• 각 테이블마다 Primary Key를 가지며 생성될 때 결정된다
• 데이터, 즉 행을 무한히 추가할 수 있다
• 각 항목은 속성을 가지며 열이 속성에 추가된다 (null도 허용)
  • 사전 요구사항 없이 쉽게 열을 추가할 수 있다.
• 각 아이템의 최대 크기는 400KB로 큰 객체는 저장 불가
• 다양한 데이터 유형을 지원
  • Scalar Types: String, Number, Binary, Boolean, Null
  • Document Types: List, Map
  • Set Types: String Set, Number Set, Binary Set
• 스키마를 빠르게 전개해야할 때 사용하면 된다

기본키(Partition Key + Sort Key(Optional)) + Attributes(Nullable)

 

Read/Write Capacity Modes

• 테이블 용량(읽기/쓰기 처리량) 관리 방식을 정해야한다

 

프로비저닝 모드

• 초당 읽기/쓰기 요청수를 예측해서 미리 지정하면 테이블의 용량이 된다
• 미리 용량을 결정하고 프로비저닝된 RCU와 WCU단위로 결제
  • Read Capacity Unit & Write Capacity Unit
• 오토 스케일링 기능이 있어 로드에 따라 자동으로 RCU와 WCU를 늘리거나 줄일 수 있다
• 천천히 전개되기 때문에 비용절감시 효과적

 

온디맨드 모드

• 어떠한 용량 계획 없이 읽기/쓰기 처리량에 따라 자동으로 스케일이 관리된다
• 조금 더 비싸지만 워크로드를 예측할 수 없거나 급격히 증가하는 경우 유용하다
• 수천 개의 트랜잭션을 수 백만개의 트랜잭션으로 빠르게 확장하려면 필요할 수도 있다

 

실습

데이터베이스와 관계없이 테이블을 만들어 서버리스로 관리된다 Read Capacity / Write Capacity를 따로 설정 가능하며 unit 단위로 관리

 

DynamoDB 고급 기능

DynamoDB Accelerator (DAX)

• 고가용성의 완전 관리형 무결점 인메모리 캐시
• 읽기 작업이 많을 떄 DAX 클러스터를 생성해 데이터 캐싱을 통한 읽기 혼잡을 줄인다
• DAX는 캐시 데이터에 마이크로초 수준의 레이턴시를 제공
• 기존 DynamoDB API와 호환되어 로직 변경이 필요없다
• Default TTL은 5분

 

DynamoDB Accelerator (DAX) vs ElastiCache

• DAX는 DynamoDB앞에 있어 개별 객체 캐시와 쿼리, 스캔 캐시를 처리하는데 유용
• 집계 결과를 저장할 떄는 ElastiCache가 좋다
• 대용량의 연산이 필요한 데이터를 저장하는 경우 DynamoDB가 좋다
• 상호 보완적인 성격을 가지며 케이스를 잘 살펴봐야한다

 

Stream Processing

테이블의 모든 수정 사항 → 생성, 업데이트, 삭제를 포함해서 스트림을 생성할 수 있다

• 테이블 변경 사항에 실시간으로 반응하는데 활용할 수 있다
• 실시간으로 사용 분석
• 파생 테이블 삽입
• 리전간 복제
• DynamoDB 변경사항에 대해 Lambda 함수를 실행할 수도 있다

 

DynamoDB Streams

• 24시간의 보존기간
• 소비자 수 제한
• 람다 트리거 혹은 자체적으로 읽기를 실행하려면 DynamoDB Stream Kinesis 어댑터를 사용

 

Kinesis Data Streams로 변경 사항을 바로 보낸다

• 보존기간은 1년
• 더 많은 소비자
• 처리 방법이 훨씬 많다 → 람다 함수, Kinesis Data Analytics, Data Firehose ..

 

DynamoDB Global Table

여러 리전간에 복제를 할 수 있는 테이블

• 양방향 복제가 가능하다. 테이블 둘 중 하나에 쓰기만 해도 됨
• 복수의 리전에서 짧은 지연시간
• 다중 활성 복제가 가능하여 모든 리전에서 테이블 읽기 쓰기 가능
• DynamoDB Streams를 활성화해야한다

 

DynamoDB - TTL

• 시간이 지난 항목을 자동으로 삭제하는 기능
• 최근 항목만 저장할 수 있도록 하거나 2년 후 데이터를 삭제하는 규정
• 자주 등장하는 사례는 웹 세션 핸들링
  • 유저가 로그인하면 해당 세션을 중앙 저장소인 DynamoDB에 2시간 저장 이후 갱신되지 않으면 삭제되고 그 전까지 모든 애플리케이션이 조회가능

 

Backups for disaster recovery

• 지정 시간 복구(Point-in-time Recovery, PITR)을 통한 백업 가능
  • 활성화하면 35일 동안 지속
  • 백업 기간 내에는 언제든지 PITR을 실행 가능
  • 복구를 진행할 경우 새로운 테이블을 생성
• 온디맨드 백업
  • 직접 삭제할 때까지 보존된다
  • 성능 혹은 지연시간에 영향을 주지 않는다
  • AWS 백업 서비스로 수명 주기 정책 활성화와 리전 간 백업을 가능하게 함
  • 백업으로 복구시 새로운 테이블 생성한다

 

Integration with Amazon S3

 

Export to S3

• S3로 테이블을 내보낼 수 있다(PITR을 활성화해야 한다)
• 35일 이내 어떤 시점으로든 테이블을 보낼 수 있다
• 테이블을 내보내도 데이터베이스 성능에 영향을 주지 않는다
• s3로 먼저 내보내어 데이터분석을 수행할 수 있다
• 감사 목적으로 스냅샷 확보가 가능하다
• 데이터를 DynamoDB로 가져오기 전에 데이터 ETL등 대규모 변경 수행 가능
• DynamoDB JSON / ION으로 내보낼 수 있다

Import to s3

• CSV, DynamoDB JSON, ION 포맷으로 새로운 테이블을 생성
• 쓰기 용량을 소비하지 않고 새로운 테이블을 생성
• 가져올 때 발생한 모든 오류는 CloudWatch Logs로 생성된다

 

AWS API Gateway

클라이언트가 직접 람다함수를 호출할 수 있게 하려면 클라이언트에게 IAM 권한이 필요한데 이때 ALB로 람다와 클라이언트를 연결하면 람다 함수의 HTTP 엔드포인트가 노출된다

 

따라서 API Gateway로 연결하여 요청을 프록시한다

 

API Gateway 개요

• 람다와 통합하면 완전 서버리스 애플리케이션이 되어 관리가 필요없다
• WebSocket을 지원하여 실시간 스트리밍이 가능
• API 버저닝을 핸들링하여 클라이언트와 연결이 끊기지 않는다
• dev test prod 여러 환경을 구분
• 인증, 권한 부여 등 수많은 보안 기능을 API Gateway에 활성화 가능
• API 키 생성, 하나의 클라이언트에서 요청이 몰리면 쓰로틀링 또한 가능
• Swagger, Open API 3.0을 통해 신속히 API를 정의하여 가져올 수 있다
  • 내보내기도가능
• API Gateway 수준에서 요청과 응답을 변형하거나 유효성을 검사할 수 있다
• API 응답 캐싱 가능

 

Integrations High Level

• 람다 함수
  • 람다 함수를 호출 가능하여 람다를 백엔드로 구성하여 REST API를 노출시키는 쉬운 방법
• HTTP
  • 백엔드 HTTP를 노출 가능
  • ALB가 있을 때 속도 제한 기능, 캐싱, 사용자 인증, API 키 등의 기능을 추가할 수 있다
• AWS Service
  • 어떤 AWS API라도 노출할 수 있다 → 직접 SQS에 메시지 게시도 가능
  • 인증을 추가하거나 API를 퍼블릭 배포 혹은 속도 제한을 주기 위함

 

AWS Service Integration Kinesis Data Streams example

AWS 서비스와 통합되는 예시

키네시스 데이터 스트림으로 사용자가 데이터를 전송할 수는 있지만 AWS 자격증명은 가질 수 없도록 보안 설정이 가능하다

 

 

API Gateway를 통해 AWS 서비스를 외부에 노출시키는게 핵심이다

 

EndPoint Types

Edge-Optimized (default): 글로벌 클라이언트용

• 모든 요청이 CloudFront엣지 로케이션을 통해 라우팅되어 지연시간이 개선
• API Gateway는 생성된 리전에 위치하지만 모든 CloudFront 엣지 로케이션에서 엑세스

 

Regional

• 모든 사용자는 같은 리전에 있어야한다
• 자체 CloudFront 배포 가능 → Edge-Optimized와 같은 결과를 내지만 캐싱, 배포 등 더 많은 제어가 필요하다)

 

Private

• VPC내에서만 엑세스 가능 ENI
• 엑세스를 정의할 때는 리소스 정책을 사용

 

Security

사용자 식별하는 방법

• IAM Role → 내부 애플리케이션에서 유용
  • API Gateway의 API에 엑세스할 때 IAM 역할을 사용하도록 한다
• Cognito -.> 외부 사용자를 위한 신원확인
• 사용자 지정 권한 부여(커스텀 로직)

 

Custom Domain Name HTTPS security through integration with AWS Certificate Manager (ACM)

• 사용자 지정 도메인 이름을 ACM과 통합가능
• 엣지 최적화 엔드포인트를 사용할 경우 us-east-1에 있어야 한다
• 리전 엔드포인트를 사용한다면 인증서는 API Gateway와 같은 리전에 있어야 함
• Route 53에 CNAME이나 A-alias 레코드를 설정해 도메인 및 API Gateway를 가리키도록 해야함

 

AWS Step functions

• 서버리스 워크플로를 시각적으로 구성할 수 있다. 주로 람다함수를 오케스트레이션하는데 활용
  • 그래프를 만들어 각 단계별로 결과에 따라 다음으로 수행하는 작업이 무엇인지 정의
  • 복잡한 워크플로를 만들어 AWS에서 실행시킬 수 있는 편리한 도구
• Step Functions가 제공하는 기능으로는 시퀀싱, 병행 실행, 조건 설정, 타임아웃 에러 핸들링
• EC2 ECS 온프레미스 서버 등 다양한 AWS 서비스를 워크플로에 넣을 수 있다
• 워크플로에 사람이 개입해서 승인해야만 진행되는 단계를 설정할 수 있다
  • 사람의 개입을 논리적으로 적용 가능
• 주문 이행, 데이터처리, 웹 애플리케이션 등 구성하기 복잡한 워크플로를 시각적으로 구성하려고할 때 사용한다