AWS Lambda 및 Lambda@Edge 실행 환경에 대한 향후 업데이트 계획 안내

AWS Lambda는 AWS re : Invent 2014에서 처음 발표되었습니다. Amazon CTO 인 Werner Vogels는 Lambda 서비스에 대해 “서버 인스턴스를 준비하고 운영할 필요가 없으며, 코드를 작성 하기만 하면 된다”는 측면을 강조했습니다. 2016 년에 Lambda 함수를 실행하여 Amazon CloudFront가 제공하는 콘텐츠를 맞춤형 처리를 할 수 있도록 하는 Lambda@Edge를 출시했습니다.

AWS에서 “공유 책임 모델”에 대해 자주 이야기합니다. 서비스 제공 회사가 책임 지는 부분과 고객의 임무 사이에 역할을 분산하는 곳입니다. Lambda와 Lambda@Edge의 경우 저희가 관리하는 핵심 사항 중 하나는 “실행 환경(Execution Environment)”입니다. 실행 환경은 소스 코드가 내부에서 기본 운영 체제, 시스템 패키지, 사용 중인 언어의 런타임 (정식 제공 되는 언어의 경우) 및 환경 변수와 같은 공통 기능으로 구성됩니다. 고객 입장에서 볼 때, 애플리케이션 코드 개발 및 구성에 대한 역할은 주로 개발자에게 책임이 있습니다.

이 글에서는 Node.js v10을 제외한 모든 런타임에 대해 Lambda 및 Lambda@Edge 함수의 실행 환경에 대한 향후 변경 사항을 간략하게 설명합니다. 모든 업데이트와 마찬가지로 일부 기능이 영향을 받을 수 있습니다. 이 게시물을 통해 변경 사항 및 취해야 할 조치를 이해하시고 확인하시기를 권장 드립니다.

향후 업데이트 주요 계획

AWS Lambda 및 Lambda@Edge는 Amazon Linux 운영 체제에서 실행되고 있으며, 핵심 OS 및 관리되는 언어 런타임에 대한 업데이트를 유지합니다. 현재 Lambda 실행 환경 AMI를 Amazon Linux의 버전 2018.03으로 업데이트하고 있습니다. 이 새로운 AMI는 기능, 성능, 보안 및 응용 프로그램 코드와 상호 작용할 수 있는 업데이트 된 패키지의 향상된 기능을 제공하는 업데이트를 제공합니다.

이것은 현재 Amazon Linux 2에서 실행되는 최근에 발표 된 Node.js v10 런타임에는 적용되지 않습니다.

대부분 람다 함수는 아무런 추가 조치 없이 이 업데이트의 향상된 기능을 원활하게 이용할 수 있습니다. 그러나, 드물긴 하지만 패키지 업데이트로 인해 호환성 문제가 발생할 수 있습니다. 잠재적인 영향을 받는 람다 함수는 라이브러리 또는 특정 기본 OS 패키지 또는 기타 시스템 라이브러리에 대해 컴파일 된 응용 프로그램 코드가 포함 된 기능 일 수 있습니다. 그러나, AWS SDK 또는 다른 종속성 없이 AWS X-Ray SDK를 주로 사용하는 경우 아무런 영향을 주지 않습니다.

이번 업데이트에 따르 다음 옵션을 선택할 수 있습니다.

5월 21일 부터 신규/업데이트하는 람다 함수 적용 및 6월 11일부터 기존 함수에 자동 적용
신규 환경에 대비하여 람다 함수를 테스트하여 호환성 확인
혹시 이슈가 있는 경우, 6월 18일까지 추가 테스트를 할 수 있게 업데이트 지연 요청

이번 변경에 대한 전반적인 일정 외에도 이 게시물은 다음에 대한 지침도 제공합니다.

Lambda/Lambda@Edge 함수에 대한 신규 실행 환경 테스트 방법
신규 실행 환경에서 함수 업데이트 방법
테스트를 실행 환경 업데이트를 1주일간 연장하는 방법

업데이트 일정

업데이트 일정은 향후 몇 주 동안 4 단계로 나뉩니다.

2019 년 5 월 14 일 – 테스트 시작 : AWS SAM CLI를 사용하거나 Amazon Linux 2018.03에서 실행되는 Amazon EC2 인스턴스를 사용하여 새 실행 환경에 대한 함수를 로컬에서 테스트 할 수 있습니다. 마지막 부분에서 설명하는 옵트-인 메커니즘을 사용하여 AWS Lambda의 신규 환경을 사전에 활성화 할 수 있습니다.
2019 년 5 월 21 일 – 업데이트/신규 생성 함수 : 신규 또는 함수 업데이트로 인해 신규 실행 환경에서 실행하는 함수가 생성됩니다.
2019 년 6 월 11 일 – 일반 업데이트 : 업데이트 지연을 요청 하지 않는 한, 기존 함수가 호출 할 때 새 실행 환경을 사용하기 시작합니다.
2019 년 6 월 18 일 – 업데이트 지연 요청 종료 : 지연 요청된 업데이트 실행 환경의 모든 함수가 자동으로 마이그레이션 되기 시작합니다.
2019 년 6 월 24 일 – 마이그레이션 끝 : 모든 기능이 새 실행 환경으로 마이그레이션 됩니다.

실행 환경 업데이트 추천 대응 전략

즉, 여러분의 애플리케이션이 이전 실행 환경에서만 작동하도록 컴파일된 의존성을 가진 경우에만 대응하시면 됩니다. 그렇지 않다면, 다른 테스트 단계를 수행하지 않고도 신규 실행 환경에서 람다 함수를 계속 배포 할 수 있습니다. 함수가 그러한 종속성을 사용하는지 확실하지 않은 분들은 새로운 함수 배포 및 테스트를 하시는 것이 좋습니다.

신규 실행 환경에서 함수를 테스트 할 수 있는 시기는 두 가지 옵션이 있습니다.

옵트-인 메커니즘을 사용하여 테스트를 시작할 수 있습니다.
5 월 21 일부터 새로운 함수의 배포 또는 업데이트가 진행 될 때 신규 실행 환경을 사용합니다.

람다 함수가 신규 실행 환경의 영향을 받고 있다는 것이 테스트로 확인 되면, 현재 실행 환경에 대한 새로운 AMI를 사용하여 종속성을 다시 컴파일하거나 빌드 한 다음, 테스트를 반복 할 수 있습니다. 마지막 단계는 5 월 21일 이후에 언제든지 신규 실행 환경을 사용하기 위해 람다 함수를 재배포하는 것입니다.

신규 실행 환경에서 의존성 테스트 하기

신규 실행 환경 역시 기존 Amazon Linux AMI 환경을 기반으로 하기 때문에 EC2에서 해당 AMI에 대한 코드를 작성하고 테스트하는 것으로 시작할 수 있습니다. 이 AMI를 통해 EC2 인스턴스를 사용하면 일반 프로세스를 사용하여 패키지를 컴파일하고 빌드 할 수 있습니다.

모든 리전의 AMI ID 목록을 보려면 출시 정보를 확인시면 됩니다. 본 AMI를 실행하는 EC2 인스턴스를 시작하려면 Amazon EC2 사용 설명서의 인스턴스 시작 마법사를 사용하여 인스턴스 시작 단계를 수행하시기 바랍니다.

Lambda Layer를 통한 옵트인 혹은 업데이트 지연 요청

지금 부터 바로 람다 함수 테스트를 시작할 수 있습니다. 또는 테스트 시간이 더 필요한 경우, 업데이트 지연 요청도 가능합니다.

함수 테스트 과정을 제어하기 위해 두 개의 특수 Lambda Layer를 출시합니다. 람다 레이어는 람다 함수간에 공유 리소스, 코드 또는 데이터를 제공하는 데 사용할 수 있으며 배포 및 업데이트 프로세스를 단순화 할 수 있습니다. 이 레이어에는 실제로 데이터나 코드가 포함되어 있지 않습니다. 대신, 예전 혹은 신규 실행 환경에서 함수 실행을 실행하기 위해 Lambda에 대한 특별한 플래그 역할을 합니다.

Opt-In 레이어를 사용하면 오늘 테스트를 시작할 수 있습니다. 업데이트 지연 레이어는 5월 21일 이후에 함수 또는 해당 구성을 업데이트를 완료 해야 하지만, 새로운 실행 환경에 배포 할 준비가 되지 않은 경우에 사용할 수 있습니다. Delayed-Update 레이어는 실행 환경을 변경하지 않고, 6월 17일 말까지 기능을 배포 할 수 있는 초기 기간을 1 주일 연장합니다.

이 두 가지 레이어는 람다 함수의 성능 또는 런타임에 영향을 주지 않습니다. 6월 24일 이후에는 이들 레이어에 함수 기능이 없어지기 때문에, 테스트 후에는 함수 구성에서 제거해야 합니다.

아래는 각 레이어의 ARN 주소입니다.

OPT-IN – 신규 실행 환경에서 테스트를 바로 원할 때

arn:aws:lambda:::awslayer:AmazonLinux1803

DELAY THE UPDATE – 6월 18일까지 기존 실행 환경에서 테스트 및 사용을 해야 할 때

arn:aws:lambda:::awslayer:AmazonLinux1703

기존 함수에 레이어를 추가하는 작업은 람다 함수의 구성을 업데이트 해야 합니다. AWS CLI, AWS CloudFormation 또는 AWS SAM, 널리 사용되는 타사 프레임 워크, AWS 관리 콘솔 또는 AWS SDK를 사용 하여 이 작업을 수행 할 수 있습니다.

함수 테스트 방법

이번 변경에 따라 Lambda 함수 코드를 테스트하고, 실행 환경이 업데이트 된 후에도 작동하는지 확인하는 데는 여러 가지 방법이 있습니다.

로컬 테스트

신규 실행 환경에 대해 로컬에서 함수를 테스트 할 수 있도록 AWS SAM CLI에 대한 업데이트를 제공하고 있습니다. AWS SAM CLI는 개발할 때마다 람다 환경을 로컬에서 미러링 하는 Docker 이미지를 사용합니다. 신규 업데이트를 테스트하려면 AWS SAM CLI 버전 0.16.0에 대한 최신 업데이트가 있어야 합니다. 또한 각 함수에 맞게 구성된 AWS SAM 템플릿이 있어야 합니다.

AWS SAM CLI 설치 혹은 업데이트

$ pip install --upgrade aws-sam-cli

-또는-

$ pip install aws-sam-cli

AWS SAM 템플릿에 대한 유효성 확인
```
$ sam validate -t <template file name>
```
유효한 AWS SAM 템플릿이 없는 경우, 기본 템플릿으로 시작하여 함수를 테스트 할 수 있습니다. 다음 예제는 함수를 실행하기 위한 기본 요구 사항을 나타냅니다. 런타임 값은 AWS Lambda Runtimes 항목에 나열되어야 합니다.
```
AWSTemplateFormatVersion: 2010-09-09
Transform: 'AWS::Serverless-2016-10-31'

Resources:
  myFunction:
    Type: 'AWS::Serverless::Function'
    Properties:
      CodeUri: ./ 
      Handler: YOUR_HANDLER
      Runtime: YOUR_RUNTIME
```

유효한 템플릿을 사용하면, 모의 이벤트 페이로드 정보로 함수를 테스트 할 수 있습니다. 모의 이벤트 페이로드를 생성하려면 AWS SAM CLI local generate-event 명령을 사용할 수 있습니다. 다음은 Amazon S3 알림 유형의 이벤트를 생성하기 위해 실행되는 명령의 예제입니다.

sam local generate-event s3 put --bucket munns-test --key somephoto.jpeg

{
  "Records": [
    {
      "eventVersion": "2.0", 
      "eventTime": "1970-01-01T00:00:00.000Z", 
      "requestParameters": {
        "sourceIPAddress": "127.0.0.1"
      }, 
      "s3": {
        "configurationId": "testConfigRule", 
        "object": {
          "eTag": "0123456789abcdef0123456789abcdef", 
          "sequencer": "0A1B2C3D4E5F678901", 
          "key": "somephoto.jpeg", 
          "size": 1024
        }, 
        "bucket": {
          "arn": "arn:aws:s3:::munns-test", 
          "name": "munns-test", 
          "ownerIdentity": {
            "principalId": "EXAMPLE"
          }
        }, 
        "s3SchemaVersion": "1.0"
      }, 
      "responseElements": {
        "x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH", 
        "x-amz-request-id": "EXAMPLE123456789"
      }, 
      "awsRegion": "us-east-1", 
      "eventName": "ObjectCreated:Put", 
      "userIdentity": {
        "principalId": "EXAMPLE"
      }, 
      "eventSource": "aws:s3"
    }
  ]
}

그런 다음 이전 명령의 실행 출력에서 AWS SAM CLI 로컬 호출 명령과 파이프를 사용할 수 있습니다. 또는 이전 명령의 출력을 파일에 저장 한 다음 -e 플래그를 사용하여 파일의 이름 및 위치에 대한 참조를 전달할 수 있습니다. 다음은 파이프 이벤트 메소드의 예입니다.

sam local generate-event s3 put --bucket munns-test --key somephoto.jpeg | sam local invoke myFunction
2019-02-19 18:45:53 Reading invoke payload from stdin (you can also pass it from file with --event)
2019-02-19 18:45:53 Found credentials in shared credentials file: ~/.aws/credentials
2019-02-19 18:45:53 Invoking index.handler (python2.7)

Fetching lambci/lambda:python2.7 Docker container image......
2019-02-19 18:45:53 Mounting /home/ec2-user/environment/forblog as /var/task:ro inside runtime container
START RequestId: 7c14eea1-96e9-4b7d-ab54-ed1f50bd1a34 Version: $LATEST
{"Records": [{"eventVersion": "2.0", "eventTime": "1970-01-01T00:00:00.000Z", "requestParameters": {"sourceIPAddress": "127.0.0.1"}, "s3": {"configurationId": "testConfigRule", "object": {"eTag": "0123456789abcdef0123456789abcdef", "key": "somephoto.jpeg", "sequencer": "0A1B2C3D4E5F678901", "size": 1024}, "bucket": {"ownerIdentity": {"principalId": "EXAMPLE"}, "name": "munns-test", "arn": "arn:aws:s3:::munns-test"}, "s3SchemaVersion": "1.0"}, "responseElements": {"x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH", "x-amz-request-id": "EXAMPLE123456789"}, "awsRegion": "us-east-1", "eventName": "ObjectCreated:Put", "userIdentity": {"principalId": "EXAMPLE"}, "eventSource": "aws:s3"}]}
END RequestId: 7c14eea1-96e9-4b7d-ab54-ed1f50bd1a34
REPORT RequestId: 7c14eea1-96e9-4b7d-ab54-ed1f50bd1a34 Duration: 1 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 14 MB

"Success! Parsed Events"

이제 invoke 명령 다음의 로그에서 함수의 전체 출력을 볼 수 있습니다. 이 예제에서 파이썬 함수는 이벤트 페이로드를 출력 한 다음 종료합니다.

AWS SAM CLI를 사용하면, 다른 AWS 서비스의 데이터와 연동하는 유효한 테스트 페이로드를 전달할 수 있습니다. 또한, Amazon DynamoDB 테이블, Amazon S3 버킷 등 같은 계정에 있는 다른 AWS 리소스와 람다 함수를 연결하게 할 수 있습니다. API 기반 이벤트로 AWS SAM 템플리트를 구성한 경우, local start-api 명령을 사용하여 API 인터페이스를 테스트 할 수도 있습니다. AWS SAM CLI를 설치할 때, AWS SAM CLI 설정 및 구성에 대한 전체 지침을 살펴 보시길 권장 드립니다. 더 자세한 것은 AWS Serverless Application Model 문서에서 AWS SAM 템플릿에 대한 전체 구문 가이드를 보시면 됩니다.

Lambda 콘솔에서 테스트

업데이트 단계가 시작된 후 또는 레이어가 추가 되고 함수를 배포 한 시점부터는 람다 콘솔에서 함수를 테스트하시기 바랍니다.

람다 콘솔에서 테스트 할 함수를 선택하십시오.
테스트 이벤트를 선택하고 Test를 선택하십시오.
테스트 이벤트가 없으면 Configure test events을 선택하십시오.
1. Event template를 선택하고 테스트 할 관련 호출 서비스를 선택하십시오.
2. 테스트 이벤트의 이름을 지정하십시오.
3. 특정 기능에 대한 이벤트 페이로드를 수정하십시오.
4. Create를 선택한 다음 2 단계로 돌아갑니다.

그러면, 테스트 결과가 표시됩니다.

마무리

AWS Lambda와 Lambda @ Edge를 통해 AWS는 개발자가 실제 서버를 관리하는 작업에 관해 생각할 필요 없이 애플리케이션 코드에만 집중할 수 있게 했습니다. 이 글에서는 좀 더 나은 실행 환경을 제공해 드리기 위한 업데이트에 대해 진행 방법, 테스트 방법 등을 알려드렸습니다.

여러분 중 일부는 이 과정에 대해 질문이 있으실 수 있고, 저희는 여러분을 도울 준비가 되어 있습니다. AWS Support, AWS Forum 또는 개별 AWS 어카운트 담당자를 통해 문의해 주시기 바랍니다.

– Chris Munn, Serverless Developer Advocate

이 글은 AWS Compute Blog의 Upcoming updates to the AWS Lambda and AWS Lambda@Edge execution environment의 한국어 번역입니다. 미묘한 번역 상의 오류가 있을 수 있으니, 더 궁금하신 점은 위의 영문 글을 참고하시기 바랍니다.

Amazon Web Services 한국 블로그