AWS serverless, Lambda, Architect

jsbak·2022년 4월 20일

Architect FaaS aws lambda function lambda

AWS

목록 보기

4/5

혼자 보는 이것 저것 스크랩 짬뽕
AWS 유튜브, AWS Skill Builder 강의, 강의

서버리스 마이그레이션

서버리스 적용

기존의 서비스를 마이그레이션하는 경우
새로운 서비스를 기존의 서비스와 연동할 경우
새로운 어플리케이션을 개발할 경우

Application Load Balancer	Amazon API Gateway
Application Load Balancer를 이미 사용하고 있는 경우 기존 컴퓨팅 스택을 쉽게 전환할 수 있음	REST API를 빌드하고 다른 서비스 및 Lambda 함수와 통합하는 데 적합
Amazon Cognito 사용자 풀을 포함하여 OID 지원 공급자를 통한 권한 부여 지원	AWS Identity and Access Management(IAM), Amazon Cognito 및 Lambda 권한 부여자를 통한 권한 부여 지원
처리된 요청을 기준으로 요금 부과	로드 밸런서 용량 단위를 기준으로 시간당 요금 청구
안정적인 트래픽 스트림에 대해 경제적일 수 있음	급변하는 패턴에 더 경제적일 수 있음
	API 관리를 위한 추가 기능:
	- 클라이언트용 SDK 내보내기
	- 제한 및 사용 계획을 사용하여 액세스 제어
	- 여러 API 버전 유지 관리
	- 카나리 배포

소유 비용을 비교할 때 다음 세 가지 요소를 고려

워크로드를 실행하는 인프라 비용(예: 프로비저닝된 EC2 용량에 대한 비용과 Lambda 함수의 호출당 비용)
애플리케이션이 실행될 리소스를 계획, 설계 및 프로비저닝하기 위한 개발 노력
애플리케이션이 프로덕션 상태가 되었을 때 팀이 애플리케이션을 유지 관리하는 데 소요되는 시간 비용

도메인 주도 설계 커뮤니티: DDD 배우기

서버리스 컴퓨팅 서비스 - AWS Lambda

AWS Lambda - 서버를 프로비저닝하거나 관리하지 않아도 코드를 실행할 수 있도록 해주는 컴퓨팅 서비스

필요 시에만 코드를 실행

구분	내용
서비스명	AWS Lambda
설명	- 서버에 대한 걱정 없이 코드 실행
	- 사용한 컴퓨팅 시간에 대해서만 비용 지불
주요 특징	- 기존코드 활용 가능(Node.js, Java, Python, Go, C#)
	- 단순한 자원 모델을 가지며, 실행되는 메모리에 따라 CPU, N/W 자원 할당
	- 여러 AWS 서비스들과 통합되어 있으며, Event, Request 기반으로 실행 가능
	- 자체 Editor, Zip 배포, Cloud9을 통해 개발 및 배포 가능
	- Cloudwatch, X-ray를 통해 요청 수, 에러 수, 처리 시간, 처리량 모니터링 가능
	- AWS IAM Role을 사용한 권한 관리 AWS 이벤트 소스의 자원 정책 적용
프리티어	- 월 1백만 건 무료 요청과 월 400,000초 컴퓨팅 시간(메모리에 따라변경됨)
	- 프리티어는 12개월 이후에도 종료되지 않으며, AWAS 고객에게 무기한 제공

AWS Lambda 서비스 개요

기존 IDC 내부에서 사용하던 서버를 클라우드로 옮기는 일들은 더이상 낯설지 않습니다. 또한 최근에는 웹 서비스에 대한 구축이나 데이터 가공 수집을 위한 플랫폼 구축 시 가장 많이 논의되는 것이 바로 서버리스(Serverless) 아키텍처입니다.

이전에는 기업용 홈페이지나 웹 서비스를 구현하기 위해 회사 내부에 HP, IBM 서버를 구입하여 H/W 기반의 웹 서버와 DB 서버를 직접 설치하고 운영하였습니다. 이후 VMware 나 Hyper-V 기반의 가상화 서버로 P2V를 수행하여 H/W 서버의 수량을 줄이고 손쉽게 서버를 관리할 수 있었으며, 클라우드가 대중화되면서, 가상화 서버를 클라우드로 전환하는 사례가 다양하게 진행되고 있습니다. 또한 최근에는 MSA(Microservice Architecture) 기반의 컨테이너 서비스를 도입하는 기업이 점점 들어나고 있습니다.

1. IDC 내부 H/W 서버 ( 물리적 서버 )
2. IDC 내부 가상화 서버 ( Virtual Servers )
3. 클라우드 가상화 서버 ( Cloud Virtual Servers )
4. 클라우드 컨테이너 ( Cloud Containers )
5. 클라우드 서버리스 ( Cloud Serverless )

서버리스(serverless)라는 말 자체가 서버가 필요없다는 뜻은 아니며, 서비스는 클라우드 기반의 서버에서 구동 되지만 고객 스스토 관리해야할 서버 혹은 컨테이너 서비스가 없기 때문에 고객 입장에서는 서버를 사용하는 것이 아니라 서비스를 이용하는 의미로 이해할 수 있다.

서비스 동작 방식

코드 관리도 중요하지만 접근권한에 대한 관리를 해야한다.

AWS Lambda 리소스 기반 정책
- Lambda 기능에 부여한 권한으로 호출할 수 있는 서비스 또는 이벤트 소스가 결정됨
- 리소스 기반 정책을 통해 Lambda 기능을 호출할 수 있는 타 계정 간(Croos-Account) 사용 권한 쉽게 부여 가능
- AWS 서비스에서 함수를 호출하는 경우 리소스 기반 정책으로 권한 부여 필요함

AWS Lambda 실행 역할(Execution Role)
- AWS 서비스 및 리소스에 대한 액세스 권한 부여
- Amazon DynamoDB 또는 Amazon Kinesis 이벤트가 발생되면, Lambda에 대해 IAM 역할에 읽기 권한 추가됨
- Lambda 이벤트로 읽는 서비스
  - Amazon Kinesis, DynamoDB, Simple Queue Service

AWS Lambda의 기대 효과

구분	내용
완전 관리형 서비스	- 가용성이 뛰어나며, 내결함성을 갖춘 인프라에서 코드 실행
	- OS의 패치나, 사용량 증가에 따른 서버 증설 및 관리 불필요
	- 코드를 원할하게 배포하고, 내장된 로깅 및 모니터링 기능 제공
기존 보유 코드 재활용	- 새로운 언어 및 도구, 프레임워크를 배울 필요 없음
	- 기존 라이브러리 및 타사 도구 활용 가능
	- 모든 코드나 라이브러리를 Layer로 만들어 손쉽게 공유 활용 가능
통합된 보안 모델	- 내장 SDK, IAM과 통합하여 코드가 안전하게 다른 서비스의 엑세스 제공
	- 기본적으로 VPC 내부에서 코드가 실행되며, 리소스의 엑세스 제어 가능
사용량 기반 지불	- 코드 실행에 필요한 컴퓨팅 시간 및 자원된 요청에 대해서만 비용 지불
	- 100밀리초 단위로 청구 금액이 정산되기 때문에 비용 효율적인 서비스
높은 내결함성	- 각 리전의 여러 가용 영역의 컴퓨팅 파워를 활용하여 높은 내결합성
	- 데이터 센터나 시설에 장애가 발생되어도 코드에 대한 보호 가능
	- 유지 관리 시간이나 예약된 가동 중단 시간 없음
자동 규모 조정	- 사용량 변화에 따라 고객이 관리할 필요 없으며, 자동으로 확장
	- 하루 몇 개의 요청부터 1초당 수천 개의 요청까지 자동으로 쉽게 확장
	- 이벤트 발생 빈도의 증가에 상관 없이 일관 되게 높은 성능 유지

AWS Lambda의 서비스 모델

구분	서비스 모델	구현 사례
Synchronous(Push)	Amazon API Gateway와 연동으로 웹 애플리케이션을 통한 Request 수신 및 처리 결과에 대한 Feedback 제공(양방향)	웹 애플리케이션, 모바일, 백앤드, IoT 백앤드
Asynchronous(Event)	Amazon SNS, Amazon S3 등의 이벤트 수신을 통해 트리거되어, 요청에 대한 처리 후 결과를 별도 저장 및 다른 서비스로 전송 처리	파일 또는 이미지 변환, 실시간 요청사항 처리, 타서비스 연동 및 전달
Stream-Base	Amazon DynamoDB, Amazon Kinesis로부터 상태 변경에 따른 트리거나 스트림베이스트의 요청에 따른 사항 처리 및 타 서비스 연동	실시간 스트림 처리, 데이터 축출 및 변환 서비스

Introduction to AWS Lambda & Serverless Applications - AWS

Introduction to AWS Lambda & Serverless Applications - AWS 유튜브 참고 자료

Serverless means ...

No servers to provision or manage ( 프로 비전 : 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다.)
Scales with usage ( Scale Up/Out )
Pay for value
Availability and fault tolerance built-in ( 가용성 및 내결함성 )

6가지

Greater agility ( 민첩성 향상 )
Less overhead ( 오버헤드 감소 )
- overhead 는 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간 · 메모리 등을 의미
Better focus
Increased scale
More flexibility ( 유연성 향상 )
Faster time to market

Lambda Handles

Load Balancing
Auto Scaling
Handling Failures
Security Isolation
OS Management
Managing Utilization
(and many other things) for you

Smart resource allocation

Match resource allocation ( up to 3 GB! ) to logic Stats for Lambda function that calculates 1000 times all prime numbers <= 1000000

Lambda API

API provided by the Lambda service
Used by all other services that
invoke Lambda across all models

Supports sync and async

Can pass any event payload
structure you want

Client included in every SDK

Lambda permissions model

Fine grained security controls for both execution and invocation:

Execution plicies:
- Define what AWS resources/API calls can this function access via IAM
- Used in streaming invocatinos
- E.g. "Lambda function A can read from DynamoDB table users"
Function policies:
- Used for sync and async invocations
- E.g. "Actions on bucket X can invoke Lambda function Z"
Resource policies allow for croess account access
AWS Lambda 에서 Node.js ES 모듈 및 최상위 대기

AWS Lambda 자세히 살펴보기 - 2018.12.2

코드가 Repo에 Commit 되면 파이프 라인 실행
코드 레벨 빌드, 테스트, 검즘
Functional 및 End-to-end 레벨의 연동 테스트
각 스테이지 별 독립된 환경에 배포
- 여기서 각 스테이별 독립된 환경 배포 시 Infrastructure Resource 및 Application 가 동일한 상태로 배포되어야 함.

AWS CloudFormation

Infrastructure as a Code
AWS 리소스들을 JSON/YAML 포맷의 Template 로 작성
CloudFormation 은 이 Template에 기반하여 리소스를 배포하고 관리
리소스 업데이트 역시 Template 혹은 Parameter 변경을 통해 가능

Best Practices

Cold Start vs Warm Start

Cold Start vs Warm Start
- Lambda Function 이 일정 기간 이상 실행되지 않은 경우 Stand-by 중인 컨테이너가 하나도 남지 않게 되어 호출 시 소요 시간이 증가됨 (Cold Start)
- VPC에 위치한 Lambda Function의 경우 Cold Start 시 ENI를 Attach하기 떄문에 소요 시간이 더욱 더 증가
- CloudWatch Time-based Event를 통해 주기적인 Warm-up 필요
코드 패키지 사이즈를 최소화
Lambda Handler와 Core Logic을 분히
Execution Context 재사용을 활용
Environment Variable을 적극 활용
자바의 경우 .jar 파일들을 별도의 /lib 디렉토리에 배치
Max Memory Used 사이즈는 Lambda Function 실행에 충분할 정도로만
사용되지 않는 Lambda Function들을 삭제
- 75 GB limit
API 스트로틀링에 대비
- Exponential back-off algorith
반드시 필요한 경우에만 Lambda Function 을 VPC에 배치
CloudWatch Custom Metrics를 통해 Lambda Function에서 필요한 지표들을 기록
X-Ray를 이용해 Lambda Function을 Trace

Common issues and troubleshooting

1. Lambda 함수가 실패 혹은 실행이 되지 않을 경우

CloudWatch Log에 에러가 기록되었는지 확인
- Timeout Exceeded
- Memory Exceeded
이벤트 소스 및 Execution Role의 Permssion 확인 (IAM Role 설정 확인)

2. Lambda 함수 실행이 너무 오래 걸림

Cold Start
- 2번 정도 실행해보고 Cold Start 인지 확인
메모리를 확장하여 재시도
- memory Used, Code Execution Time, 그리고 Memory Allocated는 CloudWatch Log를 통해 확인 가능
비효율적으로 작성된 코드
- 로컬 테스트
Third Party 혹은 Dependency에서 시간을 소요할 수도 있음.

3. 스로틀링(Throttling)

기본적으로 Lambda는 동시 실행 갯수를 리전별 1000개로 제한
- 함수별 동시 실행 갯수를 리전별로 상이(서울 리전의 경우 500개)
스로틀링 발생 시 동작
- 스트림 기반 동기식 호출 : 429 에러를 반환
- 스트림 기반 비동기식 호출: 최대 6시간 동안 호출 재시도
- 스트림 기반 풀 이벤트 소스(Kinesis, Dynamo DB): 최대 7일간 호출 재시도
- 스트림 기반이 아닌 풀 기반 이벤트 소스(SQS): MessageRetentionPeriod가 만료할 때까지 재시도
추가 Limit이 필요한 경우 Support Center에 케이스를 접수

AWS Lambda에서 쓰로틀링은 함수에 대한 동시 실행 요청 수를 제한
- 쓰로틀링은 클라이언트의 과도한 요청으로 함수와 리소스에 과부하가 오는것을 막고 그에 따른 비용을 제어하는 역할을 수행
  - 예를 들어, 403 에러로 람다가 트래픽을 처리하지 못하는 경우에도 쓰로틀링이 발생합니다.

동시성 : 주어진 시간에 요청을 처리하는 인스턴스의 수
- 동시성 계산방법: 평균 함수 실행 시간 (초) * 평균 요청/초
- 동시성을 줄이기 위해서는 실행시간을 줄여야합니다.
- (컨텍스트 재사용으로, 동시성과 RPS는 매핑되지는 않습니다. )

4. Schedule을 설정했는데 제때 동작하지 않을 경우

CRON Expression이 맞는지 확인
- 또한 대한민국 표준시가 아니라 UTC 시간으로 설정하였는지 확인
Lambda는 second level of precision을 지원하지 않음
- 예제) Lambda Function이 매일 23:00 UTC에 실행 되도록 설정하면 이 Lambda Function은 23:00:00부터 23:00:59 사이에 실행됨
- 따라서, second level of precision이 필요한 경우 EC2/ECS에 NTP 및 Cron 설정으로 해결해야 함.

5.VPC 에 Lambda Function 생성 불가

Execution Role에 ENI 생성 권한이 있는지 확인
- Lambda는 Excution Role을 통해 ENI를 생성하므로 반드시 권한이 있어야 함.
Subnet ID 확인
Security Group 이 해당 VPC에 소속되어 있는지 확인

6. 인터넷 연결이 안될 경우

Public Subnet에 Lambda Function 을 배치하였는지 확인
- Lambda가 인터넷 연결할 때 사용하는 ENI는 Private IP만 할당 됨
- 따라서 Lambda Function에 인터넷 연결이 필요한 경우 NAT Gatway 혹은 NAT Instance가 설정된 Private Subnet에 배치하여야 함.
NAT Gateway 혹은 NAT Instance가 제대로 설정되었는지 확인
- Route Table, Security Group, ACL 등 네트워크 설정을 확인
- NAT Instance가 Stop 되어 있거나 혹은 장애가 발생하여 인터넷 연결이 안될 수도 있음.
- 손쉽게 확인 및 트러블 슈팅하는 방법으로는 EC2 Spot Instance를 Lambda Function이 위치한 Subnet에 생성 후, SSH로 ping을 돌리면서 설정을 변경하는 방법이 있음. 설정 변경 후 SSH 창 확인

2022.04.19 수업

	VM	Container
	자원분리	자원공유
	다른 OS 가능	동일 OS
스케일 OUT 시	구동 시간⬆	구동시간⬇(VM 대비)

⬇
VM ➡ Container ➡ MSA (k8s 기반으로) ➡ serverless (컨테이너 대신 만들어 줄게)

서버 환경 동일화 등의 문제가 있으니 ➡ 서버리스
이벤트 (트리거로) -> lambda 실행 (함수 배포, 단일 기능의 함수)
250MB⬆ -> 컨테이너화 해야된다.
휘발성 작업 환경
- 전역 변수 x(람다간 쉐어가 안됨) stateless (컨테이너에서 람다가 실행된다고 생각)
- sticky session X

Cold start vs Warm start

Cold start : 전역 변수 실행까지 (많을 수록 오래걸림), 정적 초기화 (맨위에 전역 변수)
- 준비된 Workers 가 없으면, Workers 를 생성하고 초기화 해야한다.
Warm Start : 이미 준비된 Workers 호출
스로틀링 : 과열된 기기으 ㅣ손상 방지를 우해 강제로 클릭/전압⬇ 또는 Shutdown
람다 : 계정별 리밋이 정해져있다. 리전별 1000개 ( 모든 함수가 공유 )
API 게이트 웨어 : Timeout 30초
함수는 짧게, 동시성 ↑, 프로비저닝 동시성 (하앙 준비?)
RDS Proxy : DB connect pool 역할, Aurora는 지원 x (자기가 알아서 관리하기 때문)
종속성 최적화, 정역 자원 리연 로딩( 인스턴스 할당 늦게, 사용시점에 할당 하자)

Message

프로세스간의 통신 (Socket, queue)

SQS(Simple Queue Service), Message Queue(MQ)

순서 보장 타입
- 최소 1회 보장(FIFO)
- TPS ↓
- 순서 보장
- 메시지 그룹
순서 비보장 타입

SNS(Simple Notification Service), kafka Topic 역할

AWS Skill Builder - serverless lambda

AWS Skill Builder - 아키텍트

이벤트 제출 패턴

클라이언트 폴링 패턴

장점
- 동기식 흐름 교체 용이
단점
- 클라이언트로 전송되는 데이터의 일관성 지연 추가 발생
- 불필요한 작업 증가 및 변경된 사항이 없는 경우의 요청/응답에 따른 비용 증가
Amazon Simple Notification Service(Amazon SNS)를 사용한 Webhook
API Gateway를 사용한 WebSocket 패턴

클라이언트 폴링은 최소한의 재작업으로 솔루션을 제공하지만 폴링 간의 지연이 발생할 수 있습니다.
내부 경우 신뢰할 수 있는 Webhook을 사용하여 폴링 없이도 클라이언트에 결과 데이터를 제공 할 수 있습니다.
WebSocket은 클라이언트와 백업 서비스 간의 양방향 영구 연결을 제공합니다. API Gateway를 사용한 WebSocket을 사용하면 WebSocket을 구현하고 API Gateway 기능을 활용할 수 있습니다.
AWS AppSync(GraphQL) 를 사용한 WebSocket을 사용하면 클라이언트가 상태 업데이트를 수신할 수 있으며 데이터로 사용자 인터페이스가 구동될 때 적합한 옵션입니다.

jsbak

끄적끄적 쓰는곳

이전 포스트