[Udemy][day-48] Section21 : AWS 서버리스 : Lambda - 2

#AWS Certified Developer Associate

 

 

286. Lambda - Destinations(목적지)

기존에는 비동기식 호출이나 이벤트 매핑을 할 때 성공인지 실패인지를 쉽게 알 수 없다는 문제점이 있었음

 

Destinations 기능 - 비동기식 호출이나 이밴트 매핑의 결과를 다른 어딘가로 전송하는 것

 

비동기식 호출 목적지 : SQS, SNS, Lambda, Amazon EventBridge bus

이는 DLQ 와 기능이 유사한데 목적지 기능이 비교적 최신에 서비스되었고 더 많은 대상을 가질 수 있기 때문에 권장된다.

- DLQ 는 실패한 메세지만 전달되지만, 목적지 기능은 성공과 실패 결과 모두가 전달됨

 

이벤트 소스 매핑 : 처리할 수 없는 이벤트 배치를 폐기하는 경우 사용됨

이벤트 소스 매핑 목적지 : SQS, SNS

이벤트 소스 매핑이 SQS 에서 읽기를 하고 있다면 실패한 목적지를 설정하거나 DLQ 를 SQS 에 직접 설정해야 함

 

 

 

 

287. Lambda 목적지 실습

이전에 만들었던 lambda-s3 함수에서 실습

성공 시 목적지와 실패 시 목적지를 모두 만들어 본다고 함

 

먼저 sqs 로 가서 성공 시 저장할 큐와 실패 시 저장할 큐를 생성해준다고 함

표준 형식으로 이름은 s3-seccess 큐를 하나 만들어주고

똑같이 표준 형식으로 s3-failure 큐를 하나 만들어줬다

이름 이름, 유형 제외 나머진 모두 기본값으로 놓고 생성

 

이후 람다 함수 콘솔로 돌아와서

add destination

소스를 선택할 수 있고

실패와 성공 조건을 사용할 수 있다

아까 만들어줬던 sqs queue 를 선택해주고

권한이 없다고 하는데 저장하면 권한이 자동 추가된다고 한다

 

목적지 추가

성공시 전달할 큐도 추가해 줬다

 

이제 성공하는 케이스와 실패하는 케이스 2개 모두 실습해본다고 한다

연결된 s3 버킷으로 이동해서

 

upload file

파일을 하나 업로드 했다

status 가 성공이니까 

 

s3-success queue 로 가보면 수신할 수 있는 메세지가 1개 확인되고 폴링한 후 본문을 보면

sqs message

requestContext 에 많은 정보가 포함되어 있음을 확인할 수 있다

 

이제 실패한 사례를 보기 위해 람다 함수의 코드를 조금 수정한다

리턴을 없애고 레이즈문을 추가

import json

def lambda_handler(event, context):
    print(event)
    raise Exception("boom!")

deploy 하고 다시 s3 콘솔로 가서 새로운 파일을 업로드 해보면

아직 failure 큐에서 메세지를 확인할 수 없는데

이는 s3 의 lambda 호출이 비동기식 이기 때문이며 2~3분 동안 2번의 재시도 후에도 실패한다면

실패했을때의 목적지로 메세지가 전송될 것이다

failure - message

컨디션이 retriesexhausted 이다 재시도 횟수가 소진되었다는 뜻

이렇게 실패결과를 따로 저장하는 큐를 살펴봤다

 

 

 

 

288. Lambda 권한 - IAM 역할 및 리소스 정책

람다함수는 권한을 통해 AWS 서비스와 리소스에 액세스 할 수 있는 권한을 가짐

람다 샘플 관리 정책 : 

이벤트 소스 매핑으로 함수를 호출할 때마다 데이터를 읽는 것이 바로 람다 함수

- 따라서 이벤트 데이터를 읽으려면 실행 역할이 필요함

- 함수마다 하나의 람다 실행 역할을 생성하는게 권장됨

 

람다 함수가 다른 서비스를 통해 호출되는 경우 - 리소스 기반 정책 사용

- 다른 계정 및 AWS 서비스에게 람다 리소스를 사용할 수 있는 권한을 제공하여 함수에 호출할 수 있도록 함

- S3 버킷 정책과 유사함

- IAM 주체가 람다 함수에 액세스 할 수 있음

  - 주체와 연결된 IAM 정책이 인증을 하는 경우 (user access)

  - 리소스 기반 정책을 가지고 람다 함수로 액세스 권한을 부여하는 경우(service access)

 

Amazon S3 와 같은 다른 AWS 서비스가 람다 함수를 호출하려고 한다면 리소스 기반 정책이 액세스 권한을 제공하는지 확인해야 함

 

 

 

 

288. Lambda 권한 - IAM 역할 및 리소스 정책 - 실습

모든 Lambda 함수는 IAM 역할을 필요로 함

 

AWSLambdaBasicExecutionRole

lambda 의 기본 권한 정책

CreateLogStream 과 PutLogEvents 가 허용되어있는 것을 확인할 수 있다

로그 그룹도 생성할 수 있게 설정되어있다

리소스는 해당 람다 함수

 

비동기식 호출 리소스 기반 정책 - s3

lambda-s3

InvokeFunction 으로 해당 람다 함수와 버킷 arn 이 묶여있는걸 확인할 수 있다

 

비동기 유형의 호출이 Lambda 함수 호출의 소스이다

sqs 큐를 트리거 하고 있는 lambda 함수에는 리소스 기반 정책이 따로 없는데

이는 람다함수가 SQS 대기열에서 데이터 메세지를 폴링한 다음 이를 처리하는 함수이기 때문이다

 

람다 샘플 관리 정책

이 권한의 정책을 상세히 볼 수 있는데

 

정책 요약

위와 같은 액션을 할 수 있게끔 미리 정의되어있다

 

 

 

 

290. Lambda Environment Variables (환경 변수)

Environment variable = key / value pair in "String" form

코드를 업데이트 하지 않고도 함수 행위 특성을 조정할 수 있음

함수의 환경 변수는 코드에 사용할 수 있음

Lambda 서비스 또한 자체 시스템 환경 변수와 더불어서 사용할 수 있음

환경변수를 사용하도록 프로그래밍할 때 흔히 볼 수 있음

 

이와 같은 환경변수를 KMS 등으로 암호화하면 비밀 값을 저장할 수도 있음

해당 비밀 값은 Lambda 서비스 키나 고객 마스터 키(CMK)로 암호화 됨

 

 

 

290. Lambda Environment Variables (환경 변수) - 실습

함수를 새로 만들어줬다

이름은 lambda-config-demo 로 해주고 파이썬 최신 버전 런타임을 선택해줬다

일단 암호화되지 않은 형태로 환경변수를 함수에 입력해본다고 한다

함수 생성

 

이후 코드를 조금 수정해준다고 한다

import json
import os

def lambda_handler(event, context):
    return os.getenv("ENVIRONMENT_NAME")

os 패키지로 환경 변수에 대한 엑세스를 얻을 수 있다고 한다

ENVIRONMENT_NAME 이라는 환경변수를 생성한 다음 값을 부여해서 람다 함수가 이 값을 찾고 리턴하게끔 한다

배포한 후

구성의 환경변수 탭으로 들어가준다

 

환경변수

문자열로 이루어진 key / value 환경변수를 새로 생성해준다

아래에서 암호화 구성을 할 수 있지만 지금은 그냥 생성한다

저장

이제 테스트를 해보면

 

dev

환경변수에 저장했던 값이 반환된다

 

 

 

 

 

292. Lambda 모니터링 및 X-Ray

Lambda 는 CloudWatch Logs 와 통합되어있음

- Lambda 의 모든 실행 로그는 자동으로 CloudWatch Logs 에 저장됨

- 단, 람다 함수가 CloudWatch Logs 에 기록될 수 있도록 권한을 주는 알맞는 IAM 역할이 있어야 함

 

CloudWatch Metrics

- 람다 지표(Metrics) 는 CloudWatch Metric UI 또는 Lambda UI 에 저장됨

- 호출, 기간, 동시실행, 오류 수, 성공률, 스로틀, 비동기 전송 실패에 대한 정보를 나타냄

- Kinesis 또는 DynamoDB 스트림에서 읽어오는 경우, 즉 스트림을 읽어들이는 작업에 얼마나 지연이 발생하는지 알 수 있음

 

Lambda Tracing with X-Ray

람다 구성에서 Active Tracing 만 활성화해주면 됨

- 활성화하면 X-Ray 데몬이 실행됨

- 그 후 코드에 X-Ray SDK 만 입력해 주면 됨 

Lambda 함수에 X-Ray 를 사용할 수 있는 IAM 실행 역할이 있는지 확인해야 함

- AWSXRayDaemonWriteAccess

필요한 경우 X-Ray와 통신할 수 있는 환경변수

- _X_AMZN_TRACE_ID

- AWS_XRAY_CONTEXT_MISSING

- AWS_XRAY_DAEMON_ADDRESS : 람다 함수에 대해 X-Ray 데몬이 실행되는 IP 와 포트를 알려줌

 

 

 

 

293. Lambda 모니터링 및 X-Ray 추적 - 실습

이전에 실습했던 lambda-s3 함수로 들어가서 모니터링 탭으로 들어가준다

 

lambda - monitoring - metrics

Invocations - 호출된 횟수

Duration - 호출이 지속된 시간

Error count and success rate - 오류의 수와 성공률

Thottles - 람다 제한(limit)이 존재할 때 대한 지표

Iterator age - 반복자 기간, 스트림을 읽어들일 때 살펴보는 값

Total concurrent executions - 총 동시 실행, 람다 함수의 동시 실행 수준

Async delivery failures - 비동기 전송 실패 그래프

- 람다 함수가 이벤트를 처리할 기회를 얻지 못했을때를 나타냄

 

x-ray 수집을 활성화 한다고 한다

람다 함수의 구성 탭에서 모니터링 및 운영 도구로 들어가서 편집으로 들어가면

활성 추적

Active tracing 을 활성화 해주면 콘솔이 역할을 알아서 추가하도록 시도한다고 한다

변경사항을 저장해주고

확인하려면

구성의 권한 탭으로 가서 람다 역할로 들어가보면

리소스 요약

이렇게 x-ray 리소스가 추가되어 있다

람다 함수로 X-Ray 에 쓰기 작업이 가능해졌다는 뜻

 

테스트를 위해 람다 함수에 연결된 s3 버킷으로 들어가서 객체를 하나 업로드 한다

그리고 x-ray 콘솔로 이동한다

지표를 얻으려면 5분정도 기다려야 한다고 함

 

x-ray service map

람다가 호출되면 33% 에러를 동반할 수 있다고 한다

이걸로 람다 함수가 x-ray 콘솔에 나타날 수 있다는걸 확인했다

 

 

 

 

 

294. VPC 의 Lambda

기본적으로 람다 함수는 사용자 자체 VPC 외부에서 실행된다 - AWS 소유의 다른 VPC

따라서 사용자 VPC 에 있는 리소스에는 액세스가 불가능함

 

Default Lambda Deployment

lambda 함수는 모든 공용 웹 사이트에 액세스 할 수 있음 - 외부 API 에 액세스 

DynamoDB 와 같은 AWS 서비스에도 액세스가 가능

하지만 자체 VPC 나 사설 서브넷이 있을때 - Lambda 는 액세스 불가

 

Lambda in VPC

VPC ID 와 서브넷을 정의하고 람다 함수에 보안 그룹을 배정해야 함

람다 함수는 ENI(Elastic Network Interface) 를 생성함 - 선택한 서브넷

IAM 역할 - AWSLambdaVPCAccessExecutionRole

제대로 작동하려면 접근하려는 리소스의 보안그룹이 lambda 보안그룹에 대한 액세스를 허용한 상태여야 함

 

Lambda in VPC - Internet Access

기본적으로 VPC 내에 있는 람다 함수에는 인터넷 액세스 권한이 없음

람다 함수를 공용 서브넷(public subnet)에서 배포한다고 해도 인터넷이나 공용 IP 접근 권한을 얻을 수는 없음

람다함수를 private subnet 에 배포해서 인터넷 액세스 권한을 얻으려면 NAT Gateway / Instance 를 사용해야 함

클라우드에서 private subnet 에 람다함수를 배포했을 때

외부 api 에 접근하려면 NAT 디바이스의 공용 서브넷(public subnet)을 거쳐야 함

NAT 게이트웨이나 인스턴스는 VPC의 인터넷 게이트웨이와 통신하고 인터넷 게이트웨이는 외부 api 에 대한 액세스를 허용해줌

만약 dynamoDB 에 액세스 할 땐 public route 나 internet gateway 를 통해 액세스 할 수 있다 - nat 가 구성된 후에 가능한 작업

dynamoDB 에 사설 경로를 통해 액세스 하려면 VPC 앤드포인트를 사용해야 함

 

람다함수를 private subnet 에 배포해도 CloudWatch Logs 는 정상 작동함

 

 

 

295. VPC 의 Lambda - 실습

함수를 처음부터 생성해본다고 한다

이름은 lambda-vpc 이고 런타임은 파이썬 최신으로 하고 함수 생성

 

lambda 함수에 대한 보안그룹을 생성해준다고 한다

ec2 콘솔로 이동해서 보안그룹 탭으로 이동한 다음 create security group

이름은 lambda-sg 로 하고 인/아웃 바운드 규칙은 일단 설정하지 않고 생성

 

다시 람다함수 콘솔로 돌아와서 구성 탭으로 이동한다

현재 lambda 함수를 vpc 에 배포할 수 있고 aws 클라우드 내에 존재하며 인터넷 액세스는 가능하지만 vpc 액세스는 불가능함을 확인한다고 한다

구성 화면의 VPC 탭으로 들어가서 vpc 편집으로 들어가서 추가해준다

위에 경고문이 뜨는데 이는 인터넷에 액세스 할 수 없으며, 사설 서브넷이나 게이트웨이 대신 공용 서브넷이 있어서 트래픽을 라우팅 할 수 있는 nat 게이트웨이 또는 nat 인스턴스로 배포되어야 함을 의미한다

error

생성하려고 하면 에러가 뜨는데 (아 한번에 하지 ㅡㅡ)

Lambda 가 ec2 상에 네트워크 인터페이스 생성을 호출할 수 있는 권한이 없기 때문에 수행할 수 없다는 뜻이다

vpc 에서 람다 함수를 생성할 때에 실행을 위해서는 네트워크 인터페이스가 필요한데 이 권한은 사용자의 vpc 에 있기 때문

따라서 람다 함수에 이를 위한 충분한 권한을 지정해 줘야함 

 

람다 함수의 구성 탭의 권한 항목으로 이동한 다음 역할을 클릭해서 정책을 연결한다

LambdaENI

람다 함수가 vpc 내에 존재하기 위한 모든 권한이 추가됨

이제 다시 람다 vpc 편집 생성

lambda vpc

람다 vpc 를 처음 생성하면 업데이트 부터 첫 시작까지 약간의 시간이 소요된다고 함

- aws 상에서 설정해야 하는 일부 사항이 있기 때문

 

이후 업데이트가 끝나고 함수를 테스트 해본 뒤

ec2 콘솔의 네트워크 인터페이스 탭으로 가보면

ENI

3개의 네트워크 인터페이스가 생겼다

각기 다른 가용영역에 생성되었으며 vpc 내 lambda 함수의 네트워크 인터페이스에 해당한다

각기 다른 서브넷에 있으면서 lambda 함수가 vpc 와 통신할 수 있도록 해준다

rds DB 나 Elastic cache 와 연동할 때 사용

 

 

 

 

296. Lambda 함수 성능 (Configuration)

RAM

- 128MB ~ 10GB 까지 1MB 씩 확장할 수 있음

- lambda 함수에 RAM 이나 메모리를 추가할수록 더 많은 vCPU 크레딧을 얻을 수 있음

- 직접적으로 vCPU 수를 설정할 수 없음, RAM 을 증가하는 방식으로 vCPU 를 얻을 수 있음

- RAM 이 1,792MB 에 달하면 람다 함수가 하나의 full vCPU 를 가짐, 이후에는 vCPU 가 하나 이상인 상태가 됨

  - 이때 추가된 vCPU 를 활용하기 위해 다중 스레드 작업을 필요로 함

애플리케이션이 CPU 바운드라면 함수가 실행되는 시간을 줄이기 위해 람다 함수 RAM 을 늘려야 함

람다 함수의 시간 제한은 3초로 설정되어있음

- 람다 함수가 3초 이상 실행되는 경우 시간 초과 오류가 발생하게 됨

- 시간 초과 제한은 최대 900초(15분)까지 설정 가능함

- 즉 15분 이내 프로그램이라면 람다에 적합함

 

Lambda Execution Context

실행 컨텍스트 - 임시 시간 제한 환경 , lambda 코드의 외부 종속성을 초기화함

이 컨텍스트를 사용하여 DB 를 연결하고 HTTP 클라이언트나 SDK 클라이언트를 생성할 수 있음

- 람다 함수가 다시 호출될 것을 예상하고 일정 시간 동안 유지됨

- 즉, 람다 함수를 연속으로 여러 번 호출하는 경우 호출에 대한 컨텍스트를 재사용하고 기존의 db 연결 http 클라이언트 등을 재사용하여 람다 함수의 속도를 높이고 성능을 향상시킴

실행 컨텍스트에는 /tmp 디렉토리가 포함되어 있음 

 

Initialize outside the handler

위 BAD 코드 예시에 보면 코드 실행때 마다 db 연결 또한 실행됨 - 람다 함수를 여러번 호출할 때 비효율적임

GOOD - 핸들러 외부에서 db 연결을 초기화 하는 것

- 한번 초기화하면 이를 함수 호출 전반에 걸쳐 재사용 할 수 있음

- 함수 성능을 크게 향상 시킬 수 있음

가장 좋은 방법은 초기화에 시간이 많이 걸리는 작업은 무엇이든 함수 핸들러에 적용해서 실행 전반에 걸쳐 재사용하는 것

 

Lambda Functions /tmp space

임시 파일을 작성하여 재사용할 때 /tmp 디렉토리를 사용함

최대 512MB 의 공간 사용 가능

이 디렉토리는 람다 함수가 실행하는 동안 유지됨

- 따라서 Lambda 함수가 중단된 후 재호출 되더라도 /tmp 공간에서 동일한 파일을 반환하여 시간을 크게 절약할 수 있음

실행 컨텍스트와 동일한 원리

객체의 영구적인 지속성을 요하는 경우 호출 전반에 걸쳐 지속될 수 있는 공간에 저장해 둘 필요가 있음 (ex - S3)

 

 

 

297. Lambda 함수 성능 - 실습

메모리

이전에 만들었던 lambda-config-demo 함수로 가서

구성 탭의 기본설정으로 들어가서 편집에 들어가보면

기본 설정

이렇게 메모리에 비례해 CPU 성능을 증가시킬 수 있다

메모리가 늘어나는 만큼 람다 비용도 증가하기에 과도한 요금이 청구되지 않으려면 프로그램이 실행되기에 충분한 정도만큼의 메모리만큼만 설정해야함

 

강의에서는 /tmp 공간은 최대 512MB 라고 했는데 10기가까지 사용할 수 있게 업데이트 되었나보다

 

제한 시간

제한시간

시간 초과 제한 (위 사진에서 제한시간) 은 람다 함수가 오류를 발생시키기 전 실행되는 시간을 나타냄

 

이제 코드를 조금 수정해서 테스트를 해본다고 한다

import json
import os
import time

def lambda_handler(event, context):
    time.sleep(2)
    return os.getenv("ENVIRONMENT_NAME")

위처럼 타임 슬립을 주면

billed duration

지속 시간이 2004ms 로 약 2초가 걸리게 되는데

이 시간을 5초로 수정하고 다시 테스트 해보면

task time out after 3.00 seconds

3초 타임아웃으로 인한 에러가 나오게 된다

시간 제한을 3초로 설정했기 때문

 

시간제한을 6초로 수정하고 다시 테스트 해보면 정상적으로 결과값이 반환되는걸 확인할 수 있다

 

제한 시간은 합리적으로 설정해야 함

- 만약 제한 시간을 10분으로 설정한 함수에서 실행 후 10초에 프로그램 실행이 멈췄다면 제한시간 10분간 시간 초과 오류가 발생하기를 기다려야 함

- 사용하는 경우와 함수의 역할에 따라서 시간 초과 제한을 설정해야 함

 

함수를 초기화 하는 위치

만약 람다 핸들러 안에서 초기화를 진행한다면

import json
import os
import time

def lambda_handler(event, context):
    connect_to_db()
    return os.getenv("ENVIRONMENT_NAME")

def connect_to_db() :
    time.sleep(3)

위와 같이 db 연결 작업이 3초가 걸리고 이를 람다 핸들러 안에서 진행한다고 했을때

함수를 실행할 때마다 위의 connect_to_db() 함수가 실행된다는 의미이다

테스트를 진행해보면

test

람다 함수 실행에 3초가 소요되는 것을 확인할 수 있다

import json
import os
import time

def connect_to_db() :
    time.sleep(3)
    
connect_to_db()

def lambda_handler(event, context):
    return os.getenv("ENVIRONMENT_NAME")

하지만 초기화 작업을 위와 같이 이벤트 핸들러 밖에서 진행하면

test 1

첫 실행에 걸리는 시간이 2ms 로 나오고 뒤에 초기화 시간에 3초가 걸리는 것을 확인할 수 있다

다시 테스트를 한번 더해보면

test 2

실행 시간이 1.15ms 로 아주 빨라진 것을 확인할 수 있는데

위의 connect_to_db() 부분을 재사용하기 때문이다

 

 

 

 

 

298. Lambda 동시성

람다 함수를 더 많이 호출할수록 람다 함수의 동시 실행 또한 더 많아짐

최대 1,000개까지 동시 실행 - 최대 동시 실행 갯수를 제한하는 것이 좋음

예약된 동시성 - 함수 레벨에서 정의

동시성 제한을 초과하는 각 호출은 스로틀(Throttle) 을 트리거 함

스로틀

- 동기식 호출 : return ThrottleError-429

- 비동기식 호출 : 자동으로 재시도한 후 DLQ 로 이동

한번에 1,000개 이상의 동시 실행을 요하는 경우에는 지원 티켓을 열어서 더 높은 제한을 요청할 수 있음

 

Lambda Concurrency Issue

예약된 동시성을 설정하지 않을 시 즉 함수의 동시성에 대해 어떤 제한도 두지 않을 시

람다 함수에 ALB 가 연결되어있다고 가정

또 다른 애플리케이션은 사용자가 거의 없고 API Gateway 를 통해 또 다른 람다 함수에 연결되어있음

마지막 애플리케이션은 SDK 와 CLI 를 통해 람다 함수를 호출함

 

대부분의 낮은 수준의 처리량을 갖는 경우라면 별 문제가 없음

만약 대대적인 프로모션을 진행 중이며 수 많은 사용자가 ALB 를 사용하는 등의 상황이라면

로드밸런서가 무수히 많은 람다 함수를 호출하게 되고 람다 함수가 자동으로 스케일링 되어 최대 1000개까지 동시 실행이 이루어지게 됨

문제는 모든 동시 실행이 첫번째 애플리케이션으로 몰리는데에서 발생함

- 이로 인해 API 게이트웨이와 SDK 를 사용하는 애플리케이션의 사용자도 조절 대상이 됨 (Throttle)

동시성 제한이 사용자 계정의 모든 함수에 적용됨

- 하나의 함수가 이 제한을 초과해도 다른 함수까지 스로틀 대상이 됨

 

 

Concurrency and Asynchronous Invocations (동시성과 비동기식 호출)

만약 s3 버킷에 새로운 객체에 대한 이벤트가 람다 함수의 트리거라고 할 때

수많은 파일을 동시에 업로드 한다면 람다 동시 실행이 발생함

 

동시성 제한 초과 시 추가 요청은 역시 스로틀 됨

-  비동기식 호출의 경우 error-code 429 or 500-series 에 대해 람다가 이벤트를 이벤트 대기열로 반환하게 됨

- 비동기 모드에서는 내부 이벤트 대기열이 있으므로 최대 6시간에 걸쳐 함수를 실행하려고 시도하게 됨

  - 스로틀 등으로 인해 재시도가 무수히 많이 발생하는 것

이 재시도 간격은 지수 백오프 방식으로 증가함 - 최소 1초에서 최대 5분마다 람다 함수를 재시도 할 수 있음

 

 

Cold Starts & Provisioned Concurrency (콜드 스타트와 프로비저닝된 동시성)

• Cold Start : 새로운 람다 함수 인스턴스를 생성할 때 코드가 로드되어야 하며 핸들러 외부에서 이 코드가 실행되어야 함을 의미함 (초기화에 해당 - init)

초기화가 대규모로 진행되는 경우 - 즉, 코드와 종속성이 많고 여러 db 에 연결해야 하며 많은 sdk 를 생성할 경우 처리에 오랜 시간이 소요될 수 있음

이때 새 인스턴스로 수행하게 되는 첫번째 요청은 나머지 인스턴스보다 지연 시간이 길기 때문에 사용자에게 영향을 줄 수 있음

 

 

• Provisioned Concurrency (프로비저닝된 동시성) : 함수가 호출되기도 전에 동시성을 할당해 놓는 것

콜드 스타트는 발생하지 않음

모든 호출의 지연 시간도 줄어듬

프로비저닝된 동시성의 관리를 위해 애플리케이션 오토 스케일링을 사용할 수 있음 - schedule or target utilization

 

예약된 동시 구성

https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html

Configuring reserved concurrency - AWS Lambda

 

 

 

 

299. Lambda 동시성 실습

이전 실습했던 lambda-config-demo 함수로 가서

구성 메뉴로 가서 concurrency(동시성) 탭으로 이동한다

 

동시성

기본값으로 예약되지 않은 계정 동시성 사용 으로 설정되어있고

예약되지 않은 계정 동시성은 10으로 되어있다

강의는 1000으로 되어있는데 수정되었나보다

편집으로 들어가서

예약되지 않은 계정 동시성 값을 수정해보려고 해도

예약되지 않은 계정 동시성의 값은 10 미만일 수 없는데

예약되지 않은 계정 동시성 값 - 동시성 예약 = 계정 동시성

이기 때문에 설정할 수가 없다..

...?

강의 최신화가 필요할듯..

 

강의에선 일단 0으로 저장해놓고 테스트를 진행했다

rate exceeded

예약된 동시성을 초과할때마다 이렇게 에러가 난다고 한다

 

동시성을 프로비저닝해서 콜드 스타트를 제거할 수도 있다고 한다

프로비저닝된 동시성에 대해서는 최신버전 함수 실행이 불가능 하다고 한다

아래 프로비저닝된 동시성에서 갯수를 입력하면 금액도 알 수 있다고 하는데

0 사용가능이다 ㅡㅡ

도쿄리전이라 동시성 갯수는 1000개라고 나와있는데

왜 10개인 최소로 잡히는지 모르겠다

 

 

 

 

300. Lambda 외부 종속성 (Function Dependencies)

실무에서는 패키지 등에 더 많은 종속성을 추가해야만 함

람다 함수가 외부 라이브러리에 의존하는 경우, 예를 들어 X-Ray SDK, Database Clients 등

코드에 패키지를 함께 설치하고 모두 압축 해야 함

- Node.js 에는 npm과 node_moules 디렉토리

- python 에는 pip --target options

- java 는 관련 .jar 파일 포함

압축 파일이 50MB 이면 바로 람다에 업로드 하는데, 그렇지 않으면 Amazon S3 로 보내서 람다에서 참조함

네이티브 라이브러리의 경우 먼저 Amazon Linux 에서 컴파일 되어야 실행됨

AWS SDK 는 모든 람다 함수에 포함되어있음 - AWS SDK 는 기본값으로 따로 패키징 하지 않아도 됨

 

 

 

301. Lambda 외부 종속성 - 실습

먼저 클라우드쉘로 이동해서 람다 폴더를 만든 후 내부로 이동한다

에디터 설치

이후 패키지 파일을 작성하기 위해 에디터를 하나 설치해준다

이제 디렉토리 안에 예제 파일을 만들어 준다

 

index.js

// Require the X-Ray SDK (need to install it first)
const AWSXRay = require('aws-xray-sdk-core')

// Require the AWS SDK (comes with every Lambda function)
const AWS = AWSXRay.captureAWS(require('aws-sdk'))

// We'll use the S3 service, so we need a proper IAM role
const s3 = new AWS.S3()

exports.handler = async function(event) {
  return s3.listBuckets().promise()
}

파일을 보면 require 는 aws-xray-sdk-core 인데 이것을 람다 함수와 함께 번들로 제공해야 한다

그 다음 aws sdk 를 열어서 아마존 s3 와 통신하면 

s3 로 listbucket() 연산을 반환하는 파일이다

 

따라서 람다 함수가 aws 의 xray-sdk 에 액세스 할 수 있는지 확인해야 함

 

steps.sh

#!/bin/bash

# You need to have nodejs / npm installed beforehand
npm install aws-xray-sdk

# Set proper permissions for project files
chmod a+r * 

# You need to have the zip command available
zip -r function.zip .

# create the Lambda function using the CLI
aws lambda create-function --zip-file fileb://function.zip --function-name lambda-xray-with-dependencies --runtime nodejs14.x --handler index.handler --role arn:aws:iam::001736599714:role/DemoLambdaWithDependencies

npm 으로 aws-xray-sdk 를 설치해준다

sdk 에 액세스 하는데 필요한 모든 파일과 폴더를 로컬로 설치할 것

이후 모든 파일의 권한을 변경해주고

function.zip 파일로 압축해준다

 

.zip

마지막으로 이 압축 파일을 lambda 콘솔로 업로드 해야 한다

CLI 로 진행하기 위해 IAM 역할을 생성해야 한다고 한다

IAM 콘솔로 이동

역할 생성

aws 서비스의 람다를 선택하고 다음

정책 연결

AWSLambdaBasicExecutionRole 을 추가해주고 다음

역할 이름은 DemoLambdaWithDependencies 로 하고 생성

 

위 코드의 arn 부분을 방금 생성한 역할의 arn 으로 수정해준다

클라우드쉘로 가서 명령을 붙여넣고 엔터

[cloudshell-user@ip-10-6-54-219 lambda]$ aws lambda create-function --zip-file fileb://function.zip --function-name lambda-xray-with-dependencies --runtime nodejs14.x --handler index.handler --role arn:aws:iam::662307199274:role/DemoLambdaWithDependencies
{
    "FunctionName": "lambda-xray-with-dependencies",
    "FunctionArn": "arn:aws:lambda:ap-northeast-1:662307199274:function:lambda-xray-with-dependencies",
    "Runtime": "nodejs14.x",
    "Role": "arn:aws:iam::662307199274:role/DemoLambdaWithDependencies",
    "Handler": "index.handler",
    "CodeSize": 1229308,
    "Description": "",
    "Timeout": 3,
    "MemorySize": 128,
    "LastModified": "2023-01-15T10:05:42.606+0000",
    "CodeSha256": "FHj1qdeUu0DHk90FoS/BS422kq+dQE0LXWAieXNwTM4=",
    "Version": "$LATEST",
    "TracingConfig": {
        "Mode": "PassThrough"
    },
    "RevisionId": "948b2923-6d93-48ee-833b-5654862667aa",
    "State": "Pending",
    "StateReason": "The function is being created.",
    "StateReasonCode": "Creating",
    "PackageType": "Zip",
    "Architectures": [
        "x86_64"
    ],
    "EphemeralStorage": {
        "Size": 512
    },
    "SnapStart": {
        "ApplyOn": "None",
        "OptimizationStatus": "Off"
    }
}
[cloudshell-user@ip-10-6-54-219 lambda]$ aws lambda create-function --zip-file fileb://function.zip --function-name lambda-xray-with-dependencies --runtime nodejs14.x --handler index.handler --role arn:aws:iam::662307199274:role/DemoLambdaWithDependencies

An error occurred (ResourceConflictException) when calling the CreateFunction operation: Function already exist: lambda-xray-with-dependencies
[cloudshell-user@ip-10-6-54-219 lambda]$

상태값이 pending 이라서 한번 더 실행해줬는데 잘 실행 되었나보다

 

람다 함수 콘솔로 가서 확인해보면

람다 함수

index.js 와 package-lock.json 파일도 생성되었다 버전을 락해주는 파일이다

이 명령들은 클라우드쉘이 아니라 터미널에서도 실행할 수 있는데 npm 이 설치되어있어야 한다

종속성 파일은 람다 콘솔에서 직접 업로드 해도 되고 s3 버킷을 이용할 수도 있다

 

이제 테스트를 진행한다고 한다

이름은 SampleEvent 로 하고 테스트 값은 기본으로 놓고 진행해보면

access denied

접근이 거부되는데 함수가 s3와 x-ray 에 접근하려고 하기 때문이다

 

먼저 구성 메뉴의 모니터링 및 운영 도구 탭으로 이동해서

x-ray 활성 추적

활성 추적을 활성화해주면 실행 역할에 권한을 추가해준다

iam role

그러면 iam role 에 tracerAccess 관련 정책이 하나 자동으로 연결되고

여기에 하나 더 수동으로 정책을 연결해준다

 

정책 연결

readonly 면 충분하기때문에 정책을 연결해주고

다시 테스트를 진행해보면

 

succeeded

이렇게 계정 내 모든 버킷의 정보가 리턴되고

x-ray 콘솔로 가보면

 

service map

서비스 맵에 프로그램의 일련의 동작들이 모두 지표로 나와있고

트레이스로 가보면

 

x-ray 추적을 사용하면 람다로 수행하는 모든 작업에 관한 액세스와 개요를 제공함

 

너무 길어서 3번째 포스팅으로