올바른 AWS Lambda 레이어 사용

AWS Lambda layers란?알다시피 AWS Lambda 함수는 서버가 없는 모드를 기반으로 클라우드에서 코드를 실행할 수 있습니다.서버가 없는 모든 클라우드 응용 프로그램에는 일반적으로 여러 개의 독립된 Lambda 함수가 있으며, 특정한 이벤트 (예:rest API, 계획, 트리거) 에 응답할 수 있다.각 Lambda 함수는 추가 라이브러리, 종속성 및 중간부품과 같은 소스 코드와 요구 사항을 포함하는 자체 배포 패키지로 정의됩니다.
이런 유형의 체계 구조에서 AWS Lambda 층은 코드/중용성에 의존하는 개념을 도입하여 서로 다른 기능 사이에서 모듈을 공유할 수 있도록 한다. 이런 층은 Lambda에서 중용할 수 있는 간단한 패키지로 기본적으로 운행할 때 확장된다.도면층을 어떻게 사용하는지 봅시다.

AWS Lambda layers 101
AWS Lambda 레이어는 어떻게 준비합니까?그것을 보여주기 위해서, 이 예를 생각해 봅시다. 파이톤에 내장된 Lambda는 표준 AWS가 실행될 때 포함되지 않는 바이너리 프로그램을 실행해야 합니다.우리의 예시에서 응용 프로그램은 간단한 bash 스크립트입니다.

#!/bin/bash 

# This is version.sh script
echo "Hello from layer!"

레이어를 만들려면 다음과 같은 구조의 ZIP 아카이브를 준비해야 합니다.

layer.zip 
└ bin/version.sh

AWS Lambda 콘솔에서는 소스 ZIP 아카이브와 런타임 이름 호환성을 제공하는 레이어만 만들면 됩니다.
이제 레이어를 사용하는 Lambda 함수를 생성한다고 가정합니다.코드는 다음과 같습니다.

import json

def lambda_handler(event, context):
    import os

    stream = os.popen('version.sh')
    output = stream.read()

    return {
        'statusCode': 200,
        'body': json.dumps('Message from script: {}'.format(output))
    }

그 산출은:

{
  "statusCode": 200,
  "body": "\"Message from script: Hello from layer!\\n\""
}

AWS Lambda 함수는 레이어에 포함된 bash 스크립트를 올바르게 수행합니다.이것은 층의 내용이/opt 폴더로 추출되었기 때문입니다.AWS에서 제공하는 구조를 사용하여 ZIP 압축 파일을 구축했기 때문에, bash 스크립트는 기본 경로 (/opt/bin) 에 포함되어 있습니다.위대하다
더 완전한 예를 고려하여 나는 다른 글에서 파이톤 프로젝트를 언급했다. using Chromium and Selenium in an AWS Lambda function
Lambda 함수에서 Chromium을 사용하려면 배포 패키지에 바이너리 파일과 관련 라이브러리를 포함해야 합니다. 왜냐하면 AWS는 표준 Python이 실행될 때 포함되지 않기 때문입니다.나의 첫 번째 방법은 80MB가 넘는 ZIP 패키지를 얻어서 어떤 층도 사용하지 않는 것이다.내 람다 함수 코드를 업데이트하고 싶을 때마다 가방 전체를 업로드해야 해 긴 기다림이 이어졌다.내가 프로젝트 개발 단계에서 반복적으로 조작한 횟수와 함수의 원본 코드가 전체 소프트웨어 패키지의 일부분(몇 줄 코드)에 불과하다는 것을 감안하면 나는 내가 얼마나 많은 시간을 낭비했는지 깨달았다.
두 번째 더 똑똑한 방법은 AWS Lambda층을 사용해서 위에서 보듯이 Chromium의 바이너리 파일과 필요한 모든 파이톤 패키지를 포함하는 것이다.구조는 다음과 같습니다.

layer.zip
└ bin
  └ chromium
    chromedriver    
    fonts.conf      
    lib
    └ ...        
└ python
  └ selenium
    selenium-3.14.0.dist-info
    ...

파이썬 패키지를 설치하기 위해 자주 사용하는 PIP 명령을 사용했습니다.

pip3 install -r requirements.txt -t python

일단 이 층을 창설하면 이 기능을 배치하는 데 소요되는 시간이 크게 줄어들어 생산성을 높이는 데 도움이 된다.
AWS Lambda 레이어에 대한 자세한 내용:

여러 lambda

에서 사용 가능

업데이트 가능, 매번

새 버전 생성

버전 1부터 자동 번호 지정

다른 AWS 계정과 공유 및 공개 가능

AWS 지역별

Lambda에 여러 레이어가 있는 경우 지정된 순서대로 "결합"되어 존재하는 모든 파일을 덮어씁니다

.

함수 한 번에 최대 5레벨

사용 가능

AWS 하도급

을 초과할 수 없음the limit of the size

AWS Lambda 레이어 사용 시기
구체적인 사례에서 배치 시간을 줄여 사용층이 큰 이익을 가져왔다.그래서 AWS Lambda 레이어를 사용하는 것이 항상 좋은 생각인지 궁금합니다.스포일러 경고: 정답은 정해지지 않았다!
레이어를 사용하는 두 가지 주요 이유는 다음과 같습니다.

AWS Lambda 배포 패키지 축소

코드, 중간부품과 이진 파일의 재사용성

마지막으로 가장 중요한 것은 Lambda 함수가 의존하는 층의 생명 주기에 어떤 일이 일어날까요?
레이어를 삭제할 수 있습니다. 레이어를 삭제해도 이미 사용한 기능에 문제가 생기지 않습니다.함수의 코드를 수정할 수 있지만, 함수에 의존하는 단계를 수정해야 한다면, 더 이상 사용할 수 없는 층에 대한 의존을 삭제해야 한다.
도면층을 업그레이드할 수 있습니다. 새 버전의 도면층을 작성해도 이전 버전의 기능을 사용하는 데 문제가 되지 않습니다.단, lambda 업데이트 과정은 자동이 아닙니다. 필요하면, lambda 정의에 새 도면층 버전을 지정하고, 먼저 이전 버전을 삭제해야 합니다.비록 층의 사용으로 인해 흔히 볼 수 있는 Lambda 구성 요소와 관련된 복구 프로그램과 보안 패치를 발표할 수 있지만, 이 과정이 완전히 자동화된 것이 아니라는 것을 고려해야 한다.

AWS Lambda 레이어: 더 복잡한 테스트?
앞에서 강조한 내용을 제외하고 층의 사용은 새로운 도전, 특히 테스트 환경에서 직면해야 한다.
고려해야 할 첫 번째 부분은 층이 실행할 때만 사용할 수 있는 의존항을 도입하기 때문에 로컬 디버깅 코드를 더욱 어렵게 한다.해결 방안은 AWS에서 다운로드한 층의 내용을 구축 과정에 포함하는 것이다.그러나 이것은 그다지 현실적이지 않다.
이와 유사하게 단원 테스트와 통합 테스트의 실행도 복잡성을 증가시킬 수 있다. 로컬 디버깅에 있어 층의 내용은 실행 기간에 사용할 수 있어야 한다.
두 번째는 Java나 C# 같은 정적 언어와 관련되어 있으며, 모든 의존항을 DLL이나 JAR을 컴파일하는 데 사용할 수 있도록 요구한다.분명히, 설령 이런 상황에서도, 예를 들어 실행할 때 그것들을 불러오는 우아한 해결 방안이 많거나 적거나 있다.

보안 및 성능
일반적으로 AWS Lambda층의 도입은 어떠한 안전 결함도 언급하지 않는다. 더욱 좋은 것은 기존 층의 새 버전을 배치하여 보안 패치를 발표할 수 있다는 것이다.위에서 말한 바와 같이 업데이트 과정은 자동적이지 않다는 것을 명심하세요.
특히 제3자 층에 주의해야 한다. 서로 다른 등급made publicly available이 있고 서로 다른 분야에 전문적으로 사용된다.비록 이미 특정 목적을 위해 설정된 층을 사용할 수 있는 것은 사실상 매우 편리하지만, 악성코드의 피해자가 되지 않도록 직접 자신의 층을 만드는 것이 가장 좋다.또는 사용할 레이어의 저장소를 먼저 확인하는 것이 좋습니다.
성능: 냉각 가동 상황에서도 일체형 포장의 대체품으로 층을 사용해도 효과가 없다.

구름층 형성
CloudFormation에서 AWS Lambda 레이어를 작성하는 것은 매우 간단합니다.레이어는 유형AWS::Lambda::LayerVersion의 리소스입니다.Lambda 함수 정의에서 Layers 매개 변수는 최대 5개의 종속성 목록을 지정할 수 있습니다.
다음 예는 다음과 같습니다.

SeleniumChromiumLayer:
    Type: AWS::Lambda::LayerVersion
    Properties:
        CompatibleRuntimes:
            - python3.7
            - python3.6
        Content:
            S3Bucket: 
                Ref: BucketName
            S3Key: 
                Fn::Sub: '${SourceFolder}/SeleniumChromiumLayer.zip'
        Description: Selenium and Chromium Layer for Python3.6

SampleFunction:
    Type: AWS::Lambda::Function
    Properties:
        Runtime: python3.7
        Description: Sample function 
        Handler: src/lambda_function.lambda_handler
        Role: 
            Fn::GetAtt: [ "SampleFunctionRole", "Arn" ]
        Timeout: 15
        MemorySize: 512
        Code:
            S3Bucket: 
                Ref: BucketName
            S3Key: 
                Fn::Sub: '${SourceFolder}/SampleFunction.zip'
        Layers:
            - Ref: SeleniumChromiumLayer

결론
이것은 항상 좋은 생각입니까?
내 2푼 돈: AWS Lambda층을 사용하면 자주 업데이트할 필요가 없는 대형 의존항이 존재할 때 분명히 이득을 볼 수 있다.이러한 의존 항목을 한 층으로 이동하면 Lambda 함수의 배치 시간을 현저히 단축할 수 있다.
소스 코드를 공유하는 게 어때요?이런 상황에서 응용 프로그램의 디버깅과 테스트 과정에서 도입된 복잡성을 고려하여 평가하는 것은 좋다. 도입층이 얻을 수 있는 이점 때문에 필요한 노력이 불합리할 가능성이 높다.
우리 재밌게 놀았어요?다음에 또 만나요!