AWS[Serverless]

정지범·2024년 1월 9일
serverless
0

aws

목록 보기
15/26

Serverless

  • 서버리스 서비스를 사용하는 개발자는 더이상 서버를 관리할 필요가 없다. 서버가 없다는 뜻이 아닌, 관리할 필요가 없다는 것이다. 개발자는 단지 코드를 배포하기만, 함수를 배치하기만 하면 된다.
  • 초기의 서버리스는 Faas (Function as a Service)를 의미했지만, 지금의 서버리스는 더 많은 것을 의미한다.
  • AWS Lambda로부터 서버리스는 개발되었고, 이제는 데이터베이스, 메시징, 스토리지 등을 포함한 모든 관리형 서비스를 의미한다.
  • 서버리스는 서버가 없다는 것을 의미하지 않고, 서버가 보이지 않거나, 관리하지 않고, 프로비저닝하지 않는 것을 의미한다.

Serverless in 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

Why AWS Lambda

Amazon EC2

  • 클라우드 가상 서버 - 프로비저닝이 필요함
  • RAM과 CPU 크기가 제한됨
  • 지속적으로 실행됨
  • 스케일링은 서버를 추가하거나 제거하는 작업을 해야 함

Amazon Lambda

  • 가상 함수 - 관리할 서버가 없음
  • 제한 시간이 있음 - 짧은 실행 시간
  • 온디맨드로 실행됨 (호출 시 실행)
  • 스케일링 자동화

Benefits of AWS Lambda

  • 쉬운 가격 정책:
    • 호출 횟수 및 컴퓨팅 시간, 즉 Lambda가 실행된 시간 만큼 청구
    • Lambda 요청 1백만 건과 40만 GB의 컴퓨팅 시간에 대한 프리 티어 제공
  • AWS의 전체 서비스와 통합 가능
  • 다양한 프로그래밍 언어 사용 가능
  • AWS CloudWatch를 통한 쉬운 모니터링
  • 함수당 추가 리소스 확보가 쉬움 (최대 10 GB의 램을 프로비저닝 할 수 있음)
  • RAM을 증가시키면 CPU 및 네트워크 성능도 향상됨

AWS Lambda language support

  • Node.js (JavaScript)
  • Python
  • Java (compatible with Java 8)
  • C# (.NET Core)
  • Golang
  • C# / Powershell
  • Ruby
  • Custom Runtime API (community-supported, ex. Rust)
  • Lambda 컨테이너 이미지를 지원함
    • Lambda 컨테이너 이미지는 Lambda Runtime API를 구현해야 함
    • 임의의 Docker 이미지를 실행하기 위해서는 ECS 또는 Fargate를 사용하는 것이 권장됨

AWS Lambda Integrations Main ones

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

Example: Serverless Thumbnail creation

Example: Serverless CRON Job

AWS Lambda Pricing: example

https://aws.amazon.com/ko/lambda/pricing/

  • 요청당 지불:
    • 처음 1백만 건의 요청은 무료
    • 이후 1백만 건 요청마다 $0.20 (요청 당 $0.0000002)
  • 기간당 지불: (1ms 단위로 증가)
    • 월당 첫 40만 GB-초의 컴퓨팅 시간은 무료
      • == 함수가 1 GM RAM인 경우 40만 초
      • == 함수가 128 MB RAM인 경우 320만 초
    • 이후 60만 GB-초에 대해 $1 달러 청구
  • AWS Lambda의 실행 비용은 매우 저렴하며 많은 사용자에게 인기가 있다.

AWS Lambda Limits to Know - per region

Lambda 한도는 리전당 존재함

  • 실행
    • 메모리 할당: 128 MB - 10 GB (메모리는 1MB씩 증가)
    • 최대 실행 시간: 900초 (15분)
    • 환경 변수: 4 KB 까지
    • "함수 컨테이너"의 디스크 용량 (/tmp 폴더): 512 MB - 10 GB
    • 동시 실행 횟수: 1,000회 (증가 가능)
  • 배포
    • Lambda 함수 배포 시 최대 크기 (압축된 .zip 파일): 50 MB
    • 압축하지 않았을 때의 배포 크기 (코드 + dependecies): 250 MB
    • 시작 시 다른 파일을 로드하기 위해 /tmp 디렉토리 사용 가능
    • 환경 변수: 4 KB

Edge Function: Lambda@Edge & CloudFront Functions

Customization At The Edge

  • 보통은 함수와 애플리케이션을 특정 리전에서 배포하지만 CloudFront를 사용할 때에는 엣지 로케이션을 통해 콘텐츠를 배포한다.
  • 모던 애플리케이션에서는 애플리케이션에 도달하기 전에 엣지에서 로직을 실행하도록 요구하기도 함
  • 엣지 함수:
    • CloudFront 배포에 연결하고 작성한 코드
    • 지연시간을 최소화하기 위해 사용자에게 가까운 위치에서 실행됨
  • CloudFront는 두 가지 유형을 제공
    • CloudFront Functions
    • Lambda@Edge
  • 서버를 관리할 필요 없이 전역으로 배포됨
  • 사용 사례: CDN 콘텐츠를 사용자 지정하는 경우
  • 사용한 만큼만 비용 지불
  • 완전히 서버리스!

CloudFront Functions & Lambda@Edge Use Cases:

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

CloudFront Functions

  • JavaScript로 작성된 경량화된 함수
  • 확장성이 높고 지연 시간에 민감한 CDN 사용자 지정에 사용됨
  • 시작 시간은 1ms 미만, 초당 수백만 개의 요청 처리
  • Viewer 요청 및 응답 변경에 사용
    • 뷰어 요청: CloudFront가 뷰어로부터 요청을 받은 다음 뷰어 요청 수정 가능
    • 뷰어 응답: CloudFront가 뷰어에게 응답을 보내기 전에 뷰어 응답 수정 가능
  • CloudFront의 네이티브 기능 (모든 코드가 CloudFront에서 직접 관리)
  • CloudFront는 고성능, 고확장성이 필요할 때 뷰어 요청과 뷰어 응답에만 사용됨

Lambda@Edge

  • Node.js 또는 Python으로 작성된 Lambda 함수
  • 초당 수천 개의 요청 처리
  • 모든 CloudFront 요청 및 응답 변경에 사용
    • 뷰어 요청: CloudFront가 뷰어로부터 요청을 받은 다음 뷰어 요청 수정 가능
    • 오리진 요청: CloudFront가 오리진에 요청을 전송하기 전에 수정
    • 오리진 응답: CloudFront가 오리진에서 응답을 받은 후에 수정
    • 뷰어 응답: CloudFront가 뷰어에게 응답을 보내기 전에 뷰어 응답 수정 가능
  • 함수는 하나의 AWS 리전(us-east-1)에서 작성하고, CloudFront가 모든 로케이션에 해당 함수 복제

CloudFront Functions vs. Lambda@Edge

CloudFront Functions vs. Lambda@Edge - Use Cases

CloudFront Functions

  • 캐시 키 정규화
    • 요청 속성 (헤더, 쿠키, 쿼리 문자열, URL)을 변환하여 최적의 캐시 키 생성
  • 헤더 조작
    • 요청 또는 응답에서 HTTP 헤더 삽입/수정/삭제
  • URL 재작성 또는 리디렉션
  • 요청 인증 및 권한 부여
    • 사용자가 생성한 토큰 (JWT 등) 생성 및 유효성 검사를 통한 요청 허용/거부

Lambda@Edge

  • 더 긴 실행 시간 (수 밀리초)
  • 조정 가능한 CPU 또는 메모리
  • 코드가 3rd party 라이브러리에 의존하는 경우 (예: 다른 AWS 서비스에 액세스하기 위한 AWS SDK)
  • 데이터 처리를 위한 외부 서비스에 대한 네트워크 액세스를 통해 대규모 데이터 통합 수행
  • 파일 시스템 액세스 또는 HTTP 요청의 본문에 대한 액세스

Lambda in VPC


기본적으로 Lambda 함수는 사용자의 VPC가 아닌 AWS 소유의 VPC에서 실행된다. 따라서 VPC 내에서 리소스(RDS, ElastiCache, 내부 ELB 등)에 액세스할 수 없다. 이를 해결하려면 사용자의 VPC에서 Lambda 함수를 시작하면 된다.


사용자의 VPC에서 Lambda 함수를 시작하려면 VPC ID Lambda 함수를 시작하려는 서브넷을 지정하고 Lambda 함수에 보안 그룹을 추가해야 한다. Lambda는 사용자의 서브넷에 ENI (Elastic Network Interface)를 생성한다.

Lambda with RDS Proxy

VPC에서 Lambda를 사용하는 대표적인 사용 사례는 RDS 프록시이다. RDS 데이터베이스가 프라이빗 서브넷에 있어도 Lambda 함수로 직접 해당 DB에 액세스할 수 있다. 하지만 이런 방법으로 Lambda 함수가 DB에 직접 액세스하게 되면 RDS 데이터베이스의 로드가 상승해 시간 초과 등의 문제로 이어진다. 이를 해결하기 위해 RDS 프록시를 사용한다.

  • RDS Proxy
    • DB 연결의 풀링과 공유를 통해 확장성 향상
    • 장애가 발생할 경우 장애 조치 시간을 66%까지 감소시키고 연결을 유지함으로써 가용성을 향상시킴
    • IAM 인증을 강제화하고 자격 증명을 Secret Manager에 저장함으로써 보안을 향상시킴
  • RDS Proxy는 퍼블릭 액세스가 불가능하므로 Lambda 함수는 반드시 사용자의 VPC에 배포되어야 함

Amazon DynamoDB

  • 완전 관리형 데이터베이스
  • 다중 AZ간의 데이터 복제를 통해 고가용성 제공
  • NoSQL - 관계형 데이터베이스가 아님. 트랜잭션 지원
  • 대규모 워크로드로 확장 가능한 분산 데이터베이스
  • 성능이 빠르고 일관성을 유지함 (한 자릿수 밀리초의 성능)
  • 보안, 인가 및 관리를 위해 IAM과 통합되어 있음
  • 저렴한 비용. 오토 스케일링 기능 제공
  • 유지 관리나 패치 작업이 필요 없으며 항상 사용 가능함
  • Standard 및 Infrequent Access (IA) 테이블 클래스 지원
  • DynamoDB는 테이블로 구성됨
  • 각 테이블에는 Primary Key가 있음 (생성 시 부여됨)
  • 각 테이블에는 무한한 개수의 항목 (=rows)를 가질 수 있음
  • 각 항목은 속성이 있음 (추후 추가 가능 / null 가능)
  • 항목의 최대 크기는 400 KB
  • 지원하는 데이터 타입:
    • Scalar Types: String, Number, Binary, Boolean, Null
    • Document Types: List, Map
    • Set Types: String Set, Number Set, Binary Set
  • 스키마를 빠르게 전개해야할 때 Aurora나 RDS보다는 DynamoDB가 더 나은 선택임

Read/Write Capacity Modes

  • 테이블의 용량 (읽기/쓰기 처리량)을 관리하는 방식을 제어한다.
  • Provisioned Mode (default)
    • 초당 읽기/쓰기 수를 예측하여 미리 지정
    • 용량을 사전에 계획해야 함
    • 프로비저닝된 읽기 용량 단위 (RCU) 및 쓰기 용량 단위 (WCU)에 대해 비용을 지불
    • RCU 및 WCU에 대한 오토 스케일링 가능
  • On-Demand Mode
    • 읽기/쓰기가 작업량에 따라 자동으로 확장/축소
    • 용량 계획이 필요하지 않음
    • 사용한 만큼 비용을 지불하며, 비용이 더 비싸지만 ($$$) 사용량에 따라 유연하게 대응할 수 있음
    • 예측할 수 없는 작업량이나 급격한 증가가 예상되는 경우에 적합

DynamoDB Advanced Features

DynamoDB Accelerator (DAX)

  • DynamoDB를 위한 완전 관리형 무결졀 인메모리 캐시
  • DynamoDB 테이블에 읽기 작업이 많을 때 DAX 클러스터를 생성하고 데이터를 캐싱하여 읽기 혼잡을 해결함
  • 캐시된 데이터에 대한 마이크로초 수준의 지연 시간
  • 애플리케이션 로직 수정이 필요하지 않음 (기존 DynamoDB API와 호환됨)
  • 캐시의 기본 TTL 기본값은 5분

DynamoDB Accelerator (DAX) vs. ElastiCache


DAX는 DynamoDB 앞에 있고 개별 객체 캐시, 쿼리, 스캔 캐시를 처리하는데 유용하다.

예를 들어 집계 결과를 저장할 때는 Amazon ElastiCache가 좋고, 대용량의 연산을 저장할 때에는 Amazon DynamoDB가 좋다.

두 서비스는 상호 보완적인 성격을 띄며 Amazon DynamoDB에 캐싱 솔루션을 추가할 때는 보통 DAX를 사용한다.

Stream Processing

스트림 처리는 데이터의 변경 사항을 실시간으로 감지하고 이를 처리하는 기술이다. DynamoDB의 스트림은 테이블에서 발생하는 모든 항목의 생성, 업데이트, 삭제 작업에 대한 변경 이벤트를 기록하는 일련의 이벤트 스트림이다.

  • 사용 사례:
    • 실시간으로 변경 사항에 대응하기 (사용자에게 환영 이메일 보내기)
    • 실시간 사용 분석
    • 파생 테이블 삽입
  • 리전 간 복제 구현
  • DynamoDB 테이블 변경 시 AWS Lambda 호출

DynamoDB Stream

  • 보존 기간: 24시간
  • 소비자 수 제한
  • Lambda 트리거 또는 DynamoDB Stream adapter 사용 가능

Kinesis Data Stream

  • 보존 기간: 1년
  • 더 많은 소비자의 수
  • AWS Lambda, Kinesis Data Analytics, Kineis Data Firehose, AWS Glue Streaming ETL 등 사용 가능

DynamoDB Global Table

  • 여러 리전 간에 짧은 지연 시간으로 액세스 할 수 있도록 하는 기능
  • active-active 복제
  • 애플리케이션은 어떤 리전에서든 해당 테이블을 읽고 쓸 수 있음
  • Global Tables를 설정하기 위해서는 먼저 테이블에 DynamoDB Streams를 활성화해야 함

Time To Live (TTL)

  • 만료 타임스탬프가 지난 항목을 자동으로 삭제하는 기능
  • 사용 사례: 최근 항목만 저장, 규정 준수(ex. 2년 후 데이터 삭제해야 함), 웹 세션 핸들링

Backups for disaster recovery

지정 시간 복구(Point-in-time Recovery, PITR)을 통한 지속적인 백업
선택적으로 활성화할 수 있고, 최근 35일간 지속됨
활성화하면 백업 기간 내에는 언제든 백업 윈도우 내에서 복구할 수 있음
복구 과정에서는 새로운 테이블이 생성됨
On-demand backups
장기 보관을 위해 명시적으로 삭제할 때까지 보관되는 전체 백업 수행
성능이나 지연 시간에 영향을 주지 않음
AWS Backup 서비스에서 구성 및 관리할 수 있음 (교차 리전 복사 기능 사용 가능)
복구 과정에서 새로운 테이블 생성

Integration with Amazon S3

  • S3로 내보내기 (Export to S3) - PITR 기능 활성화해야 함
    • 최근 35일 이내 어떤 시점으로든 테이블을 내보낼 수 있음
    • 읽기 용량이나 성능에 영향을 주지 않음
    • 데이터 분석 수행 가능
    • 감사 목적으로 스냅샷 확보 가능
    • 데이터를 다시 DynamoDB로 가져오기 전에 데이터 ETL 등 대규모 변경을 실행할 수 있음
    • DynamoDB JSON 또는 ION 형식으로 내보냄
  • S3에서 가져오기 (Import from S3)
  • S3에서 CSV, DynamoDB JSON 또는 ION 형식의 데이터를 가져와 DynamoDB에 새로운 테이블로 임포트
  • 쓰기 용량을 소모하지 않음
  • 임포트 중 발생하는 오류는 모두 CloudWatch Logs에 기록됨

AWS API Gateway

Example: Building a Serverless API


클라이언트와 Lambda 함수 사이에 애플리케이션 로드 밸런서를 배치하면 Lambda 함수가 HTTP 엔드포인트에 노출된다. 이때 API Gateway를 사용하는 방법도 있는데, AWS 서버리스 서비스로 REST API를 생성할 수 있으므로 클라이언트가 퍼블릭 액세스할 수 있게 된다. API Gateway에 클라이언트가 직접 소통하며 다양한 작업을 할 수 있고 Lambda 함수에 요청을 프록시한다.

API Gateway를 사용하는 이유는 HTTP 엔드포인트 뿐만 아니라 사용량 계획, 개발 단계 등의 기능을 제공하기 때문이다.

AWS API Gateway

  • AWS Lambda + API Gateway: 완전 서버리스 애플리케이션이 구축되므로 인프라 관리 필요 없음
  • WebSocket 프로토콜 지원: 양방향 통신 가능
  • API 버전 관리 (v1, v2 ...)
  • 환경 관리 (dev, test, prod ...)
  • 보안 관리
  • API 키 생성, 요청 스트롤링
  • Swagger/OpenAPI와 같은 공통 표준을 사용하여 신속히 API를 정의하여 가져올 수 있고 Swagger/OpenAPI로 내보낼 수도 있음
  • 요청 변환 및 유효성 검사
  • API 응답 캐시

Integrations High Level

  • Lambda Function

    • Lambda 함수를 호출하는 방식으로 백엔드와의 통합 구성
    • AWS Lambda를 백엔드로 사용하여 REST API를 간편하게 노출

  • HTTP

    • 백엔드에 있는 HTTP 엔드포인트를 노출하는 방식으로 통합 구성
    • 예를 들어, 온프레미스에 있는 내부 HTTP API나 Application Load Balancer와 같은 시스템을 연결할 수 있음
    • 이를 통해 속도 제한, 캐싱, 사용자 인증, API 키 등의 기능을 추가할 수 있음

  • AWS Service

  • API Gateway를 통해 어떤 AWS API라도 노출할 수 있음

  • 예를 들어, AWS Step Functions 워크플로우를 시작하거나 SQS에 메시지를 게시하는 등의 작업을 수행할 수 있음

  • 이를 통해 인증, API 퍼블릭 배포, 특정 AWS 서비스에 속도 제한 추가 가능

AWS Service Integration Kinesis Data Streams example


1.Kinesis Data Stream에 사용자가 데이터를 전송할 수는 있지만 AWS 자격 증명은 가질 수 없도록 보안 설정을 할 수 있음
2.Kinesis Data Straem과 클라이언트 사이에 API Gateway를 둠
3.클라이언트가 API Gateway로 HTTP 요청을 보내면 Kinesis Data Stream에 전송하는 메시지로 구성해 전송 - 따로 서버를 관리할 필요가 없음
4.Kinesis Data Stream에서 Kinesis Data Firehose로 레코드 전송
5.최종적으로 JSON 형식으로 Amazon S3 버킷에 저장

Endpoint Types

  • Edge-Optimized (default): 글로벌 클라이언트용
    • 요청이 CloudFront 엣지 위치를 통해 라우팅됨 (지연 시간 개선)
    • API Gateway는 여전히 생성된 리전에 위치함 - but, 모든 CloudFront 엣지 로케이션에서 액세스될 수 있음
  • Regional:
    • 동일한 리전 내의 클라이언트용 - 모든 사용자는 API Gateway를 생성한 리전과 같은 리전에 있어야 함
    • 수동으로 CloudFront와 결합할 수 있음 (캐싱 전략 및 배포에 대해 더 많은 제어 가능)
  • Private:
    • 인터페이스 VPC 엔드포인트 (ENI)를 사용하여 VPC 내에서만 액세스할 수 있음
    • 리소스 정책을 사용하여 액세스를 정의

Security

  • User Authentication through
    • IAM Roles (내부 애플리케이션에서 유용)
    • Cognito (외부 사용자를 위한 신원 확인 - ex. 모바일 사용자)
    • 사용자 지정 권한 부여 (자체 로직 실행)
  • Custom Domain Name HTTPS security through integration with AWS Certificate Manager (ACM)
    • Edge-Optimized 엔드포인트를 사용하는 경우 인증서는 us-east-1에 있어야 함
    • egional 엔드포인트를 사용하는 경우 인증서는 API Gateway 리전에 있어야 함
    • Route 53에서 CNAME 또는 A-alias 레코드를 설정하여 도메인 및 API Gateway를 가리키도록 해야함

AWS Step Functions

  • Lambda 함수를 조율하기 위한 서버리스 워크플로우를 시각적으로 구축할 수 있는 서비스
  • 기능: 시퀀스, 병렬 처리, 조건부 실행, 타임아웃, 오류 처리 등
  • Lambda 함수 뿐만 아니라 EC2, ECS, 온프레미스 서버, API Gateway, SQS 큐 등 다양한 AWS 서비스와 통합 가능
  • 사람이 개입해서 승인을 해야만 진행되는 단계를 설정할 수 있음
  • 주문 처리, 데이터 처리, 웹 애플리케이션 등 구성하기 복잡한 다양한 워크플로우를 시각적으로 구성하려고 할 때 사용함
profile
정지범
안녕하세요
이전 포스트

AWS[Container: ECS, Fargate, ECR, EKS]

다음 포스트

AWS[Serverless Architectures]

0개의 댓글