AWS Lambda 내부 동작 방식 및 활용 방법 자세히 살펴 보기 - 김일호 솔루션즈 아키텍트 매니저, AWS :: AWS Summit Seoul 2019

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.
AWS Lambda 내부 동작 방식
및 활용 방법 자세히 살펴 보기
김일호 솔루션즈 아키텍트 매니저, AWS

발표자료 바로 공개
발표자료는 발표 종료 후 해당
사이트에서 바로 보실 수
있습니다

AWS Lambda 주요 장점
• 주요 제품 기능
• 사용자 지정 로직으로 다른 AWS 서비스 확장
• 사용자 지정 백엔드 서비스 구축
• 기존 보유 코드 사용
• 완전히 자동화된 관리
• 내장된 내결함성
• 자동 규모 조정
• Amazon CloudFront 요청에 대한 응답으로 코드 실행
• 여러 함수 오케스트레이션
• 통합된 보안 모델
• 사용량에 따라 지불
• 유연한 리소스 모델

여러분,
AWS Lambda 를 직접 만들어 본다고 가정해 봅시다.
고민거리
Load Balancing | Auto Scaling | Handling Failures | Security Isolation | Managing Utilization

Front End Invoke
동기, 비동기 호출을 모두 관장

Counting Service
사용자가 얼마나 많은 API 요청을 하는지
모니터링하고 제한기능 제공

Worker Manager
실제 Container의 상태를 관리하고 API 요청을
가용 가능한 Container 로 중계

Worker
고객 함수(코드)가 안전하게 실행되는 실제
Container 환경

Placement Service
Worker에 Sandbox 구성을 자원 활용률이 높고,
고객 서비스 영향이 없도록 관리

가용 영역으로 트래픽 분산 (Routing) 기능

AWS Cloud
Region
Lambda
customer
(Existing
Worker, New
Sandbox)
Availability zone 2
Availability zone 1
Invoke
Front End
Invoke
Front End
Worker Mgr
Worker Mgr
Reserve
Sandbox
Invoke
Worker
Worker
Worker
Init

AWS Cloud
Region
Lambda
customer
(Existing
Worker, Existing
Sandbox)
Availability zone 2
Availability zone 1
Invoke
Front End
Invoke
Front End
Worker Mgr
Worker Mgr
Reserve
Sandbox
Invoke
Worker
Worker
Worker

컴퓨팅 자원의 효율적으로 자동화된
확장 또는 축소

AWS Cloud
Region
Lambda
customer
(New Function
or
Scaling Up)
Availability zone 2
Availability zone 1
Invoke
Front End
Invoke
Front End
Worker Mgr
Worker Mgr
Reserve
Sandbox
Invoke
Init
Placement
Claim
Worker
Worker
Worker
Worker

AWS Cloud
Region
Availability zone 2Availability zone 1
Placement
Claim Worker
Worker Worker Worker Worker Worker
Placement
Claim Worker

AWS Cloud
Region
Placement
Return Worker
Placement
Return Worker

AWS Cloud
Region
Lambda
customer
Availability zone 2
Availability zone 1
Front End
Front End
Worker Mgr
Worker Mgr
Placement
Return
Worker
Worker
Worker
Worker

호스트뿐만이 아니라 가용역역 수준의 가용성 확보

With Lambda:

With Lambda:
항상 가용한 호스트 사용

Instance Instance Instance InstanceInstance Instance
AWS Cloud
Region

Hardware
Host OS
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code

Hardware
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code

Hardware
Host OS
Hypervisor
Guest OS
Sandbox
Lambda Runtime
Your Code
One Function
Many
Accounts

Hardware
Host OS
Hypervisor
Guest OS
Virtual Devices
Device Emulation
Physical
Devices

Hardware
Host OS
Hypervisor
Guest OS
virtio drivers
virtio host in Firecracker
Physical
Devices

With Lambda:
정확히 필요할 때 사용한 만큼의 Cost

Inside Lambda:
시스템을 최대한 바쁘게 (busy) 돌리기 위한
최적화

Bad:
60% 60% 60% 60% 60% 60% 60%

Good:
99% 99% 99% 99% 0% 0% 0%
Cache Locality
Ability to Autoscale

Server
Bad: 동일 Workload를 한 곳에 다 담기
Workload
Workload
Workload
Workload
Workload
Workload

Server
Better: 다양한 Workload를 담기
Workload
Workload
Workload
Workload
Workload
Workload

Server
Best: 최적화된 Workload 배치
Workload
Workload
Workload
Workload
Workload
Workload

Worker
Lambda
Function
ENI in
your VPC
Your VPC
Local
NAT

Worker
Lambda
Function
ENI in
your VPC
Your VPC
Remote
NAT

전형적인 Lambda의 DB 접근 아키텍처
AWS Cloud
VPC
Availability zone 1
Availability zone 2
Private subnet
Private subnet
Private subnet
Private subnet
DB Instance
DB instance
standby
Elastic
network
interface
Elastic
network
interface
Lambda
Functions
Security group Security group

AWS Lambda에서 DB 접근 시 유의할 점
• 여러 가용 역역 내 Subnet 에 ENI 사용
• 가용 역영 레벨의 이벤트 또는 IP 소모 문제를 피할 수 있음
• Lambda 는 VPC 내 ENI로 접근
• 따라서 가용 IP 에 따른 확장성의 제약을 고려 해야함
• ENI 신규 구성은 시간이 소모됨
• 기본적으로 VPC의 Lambda는 인터넷 접근이 불가능함
• NAT Gateway (or NAT instance) 를 추가하고 Routing Table
구성으로 사용이 가능함
• Public host name DNS 쿼리를 피할 수록 좋음
• 비용과 시간 소모

고려사항: DB 컨넥션 관리
…
Lambda는 쉽게 확장 가능함, 그렇다면 DB 접근은?
Connection
pooling을 쓰면 될까?
일반 Database

Time
Container A
Container B
Container C
Container D
Lambda 의 시간에 따른 사용/확장 개요

그렇다면 Connection pooling관의 관계는?

Connection Pooling 과 Lambda 설정
Container 당 하나의 connection 만 사용
Connection Pool Size = 1 로 설정
또는
Handler 밖에 Global section에 DB connect 객체를 생성 재활용

DB connection 선언

Connection Pooling 과 Lambda - 고려사항
• Lambda container가 사라지는 지 인지할 수 없음
• Connection 를 명시적으로 닫을 수 없음
• Connection 삭제는 Database TTL에 의지
• Lambda container 의 생성 삭제를 조정할 수 없음
• Idle connection이 많이 생성될 수 있음
• 여러 Lambda 함수 실행은 여러 다른 Container에서 실행
될 수 있음
• Connection 재사용을 보장할 수 없음

방법 1a: 계정 Concurrency 제한
AWS Account
Lambda can help
with retries of
throttled
invocations*
* - Only for asynchronous and stream based event sources.

방법 1b: 함수 Concurrency 제한
Lambda can help
with retries of
throttled
invocations*
* - Only for asynchronous and stream based event sources.

Concurrency 제한의 장점
• Lambda의 동시 실행은 account와 function 레벨
모두 제한이 가능
• 방법
• AWS support로 Account 제한은 요청
• AWS Lambda 는 호출 제한이 있을 경우 retry
수행/관리

Concurrency 제한 - 고려사항
• Account Level 제한:
• Account 내 모든 Lambda에 적용되어 DB 접근 함수 제한이 간
단하지는 않다
• 여러 팀이 단일 Account 사용 시 관리
• Function Level 제한:
• 어떤 Lambda 함수가 DB 접근이 필요한지 확인
• Peak 발생 하기 전에 알고 Application 레벨의 이해 필요
• Lambda 워크로드가 다양할 경우, 다이나믹한 connection
할당이 어려움

동적 Connection 관리 아키텍처
Helper
Maintain atomic counter
and max count
Open / close
connections
DB operations
Do something interesting
Generic database
Alarm

동적 관리의 장점
• 확장 가능한 구조를 구현
• Connection 수를 관리 가능, Lambda 함수 개수와 무관
• Lambda 함수 실행 시 DB connection 배분이 가능하고 병목되는 곳을
막을 수 있음
• DynamoDB 를 이용하여 Connection 수를 정확히 관리
• CloudWatch metrics를 활용하여 문제가 에러 발생 시 메시지를 받아
다른 처리 구현이 가능

동적 Connection 관리 - 고려사항
• 관리할 리소스 증가
• Connection 재사용 불가
• 약간의 Latency 증가

트레이싱이 필요한 두 가지 이유
1. 서버리스 아키텍처/어플리케이션 개발 시 Debug 편의성
2. 서버리스 아키텍처/어플리케이션 동작 시 성능 문제 해결의 편의성

CloudWatch 를 통한 Metrics 모니터링

CloudWatch log를 통한 log 분석

Log와 Metric로 부족한 두 가지 경우
1. 전체 요청 처리 시 서버리스 함수간의 관계 파악 확인
2. 요청 처리 시 다른 리소스 접근에 대한 관계 파악 확인

AWS X-ray

Lambda 함수 간 성능/문제 점검을 위한 정보 제공

개발 시 지정된 환경 구성 및 공유 Library 활용

커스텀 런타임 만드는 순서
1. Create a Function
2. Create a Layer
3. Update the Function
4. Update the Runtime
5. Share the Layer
6. Clean Up

Lambda 함수에서 DocumentDB를 접근한다면?

MongoDB 용 Lambda Layer 생성
$ cp /usr/bin/mongo ./bin file.
$ zip -j ./archives/mongo.zip ./bin/mongo
$ aws --region us-east-1 lambda publish-layer-version --layer-name
mongo --zip-file fileb://archives/mongo.zip

Golang Lambda Layer 생성
$ go build `-o bin/getkey `src/getkey.go
$ zip -j ./archives/getkey.zip ./bin/getkey
$ aws --region us-east-1 lambda publish-layer-version --layer-
name get_secret --zip-file fileb://archives/getkey.zip

Runtime layer 생성
$ zip -j ./archives/runtime.zip ./src/bootstrap
$ aws --region us-east-1 lambda publish-layer-version --layer-name
runtime --zip-file fileb://archives/runtime.zip

Lambda 함수 생성 예제
$ aws --region us-east-1 lambda create-function --function-name bash-runtime
--zip-file fileb://archives/function.zip
--handler function.handler --runtime provided
--layers arn:aws:lambda:us-east-1:{AccountID}:layer:mongo:1
arn:aws:lambda:us-east-1:{AccountID}:layer:get_secret:1
arn:aws:lambda:us-east-1:{AccountID}:layer:runtime:1
--role arn:aws:iam::{AccountID}:role/lambda-role
--vpc-config SubnetIds={subnet-xxxxxx},SecurityGroupIds={sg-xxxxxx}
--kms-key-arn arn:aws:kms:us-east-1:{AccountID}:key/{KMSKeyID}
--timeout 180

Lambda 함수 실행
$ aws lambda invoke --function-name $lambda_name --payload
"{'command’:’Shell.method()'}" ./output/response.txt

여러분의 피드백을 기다립니다!
#AWSSummit 해시태그로
소셜미디어에 여러분의
행사소감을 올려주세요.
AWS Summit Seoul 2019
모바일 앱과 QR코드를 통해
강연평가 및 설문조사에
참여하시고 재미있는 기념품을
받아가세요.
내년 Summit을 만들 여러분의
소중한 의견 부탁 드립니다.

감사합니다!

AWS Lambda 내부 동작 방식 및 활용 방법 자세히 살펴 보기 - 김일호 솔루션즈 아키텍트 매니저, AWS :: AWS Summit Seoul 2019

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à AWS Lambda 내부 동작 방식 및 활용 방법 자세히 살펴 보기 - 김일호 솔루션즈 아키텍트 매니저, AWS :: AWS Summit Seoul 2019

Similaire à AWS Lambda 내부 동작 방식 및 활용 방법 자세히 살펴 보기 - 김일호 솔루션즈 아키텍트 매니저, AWS :: AWS Summit Seoul 2019 (20)

Plus de Amazon Web Services Korea

Plus de Amazon Web Services Korea (20)

Dernier

Dernier (20)

AWS Lambda 내부 동작 방식 및 활용 방법 자세히 살펴 보기 - 김일호 솔루션즈 아키텍트 매니저, AWS :: AWS Summit Seoul 2019