# Lambda의 OS 전용 런타임을 사용해야 하는 경우
Lambda는 Java, Python, Node.js, .NET 및 Ruby에 대한 [관리형 런타임](lambda-runtimes.md)을 제공합니다. 관리형 런타임으로 사용할 수 없는 프로그래밍 언어로 Lambda 함수를 생성하려면 OS 전용 런타임(`provided` 런타임 제품군)을 사용합니다. OS 전용 런타임에는 세 가지 기본 사용 사례가 있습니다.
+ **Native Ahead-of-Time(AOT) 컴파일**: Go, Rust, Swift, C\$1\$1와 같은 언어는 기본적으로 실행 가능한 바이너리로 컴파일되므로 전용 언어 런타임이 필요하지 않습니다. 이러한 언어에는 컴파일된 바이너리를 실행할 수 있는 OS 환경만 필요합니다. 또한 Lambda OS 전용 런타임을 사용하여 .NET Native AOT 및 Java GraalVM Native Image로 컴파일된 바이너리를 배포할 수 있습니다.
바이너리에 런타임 인터페이스 클라이언트를 포함해야 합니다. 런타임 인터페이스 클라이언트는 [사용자 지정 런타임을 위한 Lambda 런타임 API 사용](runtimes-api.md)를 직접 호출하여 함수 간접 호출을 검색한 후 함수 핸들러를 직접 호출합니다. Lambda는 [Rust](lambda-rust.md), [Go](golang-package.md#golang-package-mac-linux), [.NET Native AOT](dotnet-native-aot.md), [Swift](https://github.com/awslabs/swift-aws-lambda-runtime)(실험 단계), [C\$1\$1](https://github.com/awslabs/aws-lambda-cpp)(실험 단계)에 대한 런타임 인터페이스 클라이언트를 제공합니다.
Linux 환경 및 함수에 사용하려는 것과 동일한 명령 세트 아키텍처(x86\$164 또는 arm64)에 맞게 바이너리를 컴파일해야 합니다.
+ **타사 런타임**: PHP용 [Bref](https://bref.sh/docs/news/01-bref-1.0.html#amazon-linux-2)와 같은 상용 런타임을 사용하여 Lambda 함수를 실행할 수 있습니다.
+ **사용자 지정 런타임**: Lambda가 관리형 런타임을 제공하지 않는 언어 또는 언어 버전에 대한 자체 런타임을 구축할 수 있습니다(예: Node.js 19). 자세한 내용은 [AWS Lambda에 대한 사용자 지정 런타임 빌드](runtimes-custom.md) 섹션을 참조하세요. 이는 OS 전용 런타임의 경우 가장 흔하지 않은 사용 사례입니다.
Lambda는 다음과 같은 OS 전용 런타임을 지원합니다.
| 이름 | 식별자 | 운영 체제 | 사용 중단 날짜 | 블록 함수 생성 | 블록 함수 업데이트 |
| --- | --- | --- | --- | --- | --- |
| OS 전용 런타임 | `provided.al2023` | Amazon Linux 2023 | 2029년 6월 30일 | 2029년 7월 31일 | 2029년 8월 31일 |
| OS 전용 런타임 | `provided.al2` | Amazon Linux 2 | 2026년 7월 31일 | 2026년 8월 31일 | 2026년 9월 30일 |
Amazon Linux 2023(`provided.al2023`) 런타임은 작은 배포 공간과 `glibc`와 같이 업데이트된 라이브러리 버전을 포함하여 Amazon Linux 2에 비해 여러 가지 이점을 제공합니다.
`provided.al2023` 런타임은 Amazon Linux 2의 기본 패키지 관리자인 `yum` 대신 `dnf`를 패키지 관리자로 사용합니다. `provided.al2023` 및 `provided.al2` 간의 차이점에 대한 자세한 내용은 [AWS Lambda을 위한 Amazon Linux 2023 런타임 소개](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/)를 AWS Compute 블로그에서 참조하십시오.
# AWS Lambda에 대한 사용자 지정 런타임 빌드
AWS Lambda 런타임은 모든 프로그래밍 언어로 구현할 수 있습니다. 런타임은 함수가 간접 호출될 때 Lambda 함수의 핸들러 메서드를 실행하는 프로그램입니다. 런타임은 함수의 배포 패키지 또는 [계층](chapter-layers.md)에 포함될 수 있습니다. Lambda 함수를 생성할 때 [OS 전용 런타임](runtimes-provided.md)(`provided` 런타임 제품군)을 선택합니다.
**참고**
사용자 지정 런타임을 생성하는 작업은 고급 사용 사례입니다. 네이티브 바이너리로 컴파일하거나 타사 상용 런타임을 사용하는 방법에 대한 자세한 내용은 [Lambda의 OS 전용 런타임을 사용해야 하는 경우](runtimes-provided.md) 섹션을 참조하세요.
사용자 지정 런타임 배포 프로세스에 대한 자세한 내용은 [자습서: 사용자 지정 런타임 빌드](runtimes-walkthrough.md) 섹션을 참조하세요.
**Topics**
+ [요구 사항](#runtimes-custom-build)
+ [사용자 지정 런타임에서 응답 스트리밍 구현](#runtimes-custom-response-streaming)
+ [Lambda 관리형 인스턴스에 대한 사용자 지정 런타임 빌드](#runtimes-custom-managed-instances)
## 요구 사항
사용자 지정 런타임에서는 특정 초기화 및 처리 작업을 완료해야 합니다. 런타임은 함수의 설정 코드를 실행하고, 환경 변수에서 핸들러 이름을 읽고, Lambda 런타임 API에서 호출 이벤트를 읽습니다. 런타임은 이벤트 데이터를 함수 핸들러에 전달하고 핸들러의 응답을 Lambda에 다시 게시합니다.
### 초기화 작업
초기화 작업은 [함수의 인스턴스당](lambda-runtime-environment.md) 한 번씩 실행되어 호출을 처리할 수 있는 환경을 준비합니다.
+ **설정 검색** – 환경 변수를 읽어 함수 및 환경에 관한 세부 정보를 확인합니다.
+ `_HANDLER` – 함수의 구성에서 핸들러에 대한 위치입니다. 표준 형식은 `file.method`이며, 여기서 `file`은 확장명이 없는 파일의 이름이고 `method`는 파일에 정의된 메서드 또는 함수의 이름입니다.
+ `LAMBDA_TASK_ROOT` – 함수 코드가 포함된 디렉터리입니다.
+ `AWS_LAMBDA_RUNTIME_API` – 런타임 API의 호스트 및 포트입니다.
사용 가능한 변수의 전체 목록은 [정의된 런타임 환경 변수](configuration-envvars.md#configuration-envvars-runtime) 섹션을 참조하세요.
+ **함수 초기화** – 핸들러 파일을 로드하고 이 파일에 포함된 전역적 또는 정적 코드를 실행합니다. 함수는 SDK 클라이언트 및 데이터베이스 연결과 같은 정적 리소스를 한 번 생성해야 하며, 다중 호출 시 그러한 리소스를 다시 사용해야 합니다.
+ **오류 처리** – 오류가 발생하면 [초기화 오류](runtimes-api.md#runtimes-api-initerror) API를 호출하고 즉시 종료하세요.
초기화 횟수는 청구 대상인 실행 시간 및 시간 초과에 반영됩니다. 실행으로 인해 새 함수 인스턴스의 초기화가 트리거되면 로그 및 [AWS X-Ray 추적](services-xray.md)에서 초기화 시간을 볼 수 있습니다.
**Example log**
```
REPORT RequestId: f8ac1208... Init Duration: 48.26 ms Duration: 237.17 ms Billed Duration: 300 ms Memory Size: 128 MB Max Memory Used: 26 MB
```
### 작업 처리
런타임은 실행 중에 [Lambda 런타임 인터페이스](runtimes-api.md)를 사용하여 수신 이벤트를 관리하고 오류를 보고합니다. 초기화 작업을 완료한 후, 런타임은 수신 이벤트를 루프에서 처리합니다. 런타임 코드에서 다음 단계를 순서대로 수행합니다.
+ **이벤트 가져오기** – 다음 이벤트를 가져오려면 다음 [호출](runtimes-api.md#runtimes-api-next) API를 호출합니다. 응답 본문에는 이벤트 데이터가 포함됩니다. 응답 헤더에는 요청 ID 및 기타 정보가 포함됩니다.
+ **트레이스 헤더 전파** – API 응답의 `Lambda-Runtime-Trace-Id` 헤더에서 X-Ray 트레이스 헤더를 가져옵니다. `_X_AMZN_TRACE_ID` 환경 변수를 동일한 값으로 로컬로 설정합니다. X-Ray SDK는 이 값을 사용하여 서비스 간에 추적 데이터를 연결합니다.
+ **컨텍스트 객체 생성** – API 응답에서 환경 변수 및 헤더의 컨텍스트 정보를 사용하여 객체를 생성합니다.
+ **함수 핸들러 간접 호출** – 이벤트 및 컨텍스트 객체를 핸들러에 전달합니다.
+ **응답 처리** – [호출 응답](runtimes-api.md#runtimes-api-response) API를 호출하여 핸들러의 응답을 게시합니다.
+ **오류 처리** – 오류가 발생하면 [호출 오류](runtimes-api.md#runtimes-api-invokeerror) API를 호출합니다.
+ **정리** – 사용하지 않은 리소스를 릴리스하거나 다른 서비스로 데이터를 전송하거나 혹은 다음 이벤트를 가져오기 전에 추가 작업을 수행하세요.
### 진입점
사용자 지정 런타임의 진입점은 `bootstrap`이라는 이름의 실행 파일입니다. 부트스트랩 파일은 런타임일 수 있으며 혹은 런타임을 생성하는 다른 파일을 간접 호출할 수도 있습니다. 배포 패키지의 루트에 `bootstrap` 파일이 없는 경우 Lambda는 함수 계층에서 파일을 찾습니다. `bootstrap` 파일이 없거나 실행할 수 없는 경우, 함수는 간접 호출 시 `Runtime.InvalidEntrypoint` 오류를 반환합니다.
다음은 번들 버전의 Node.js를 사용하여 별도의 `runtime.js` 파일에서 JavaScript 런타임을 실행하는 `bootstrap` 파일 예제입니다.
**Example 부트스트랩**
```
#!/bin/sh
cd $LAMBDA_TASK_ROOT
./node-v11.1.0-linux-x64/bin/node runtime.js
```
## 사용자 지정 런타임에서 응답 스트리밍 구현
[응답 스트리밍 함수](configuration-response-streaming.md)의 경우, 런타임이 클라이언트에 부분 응답을 스트리밍하고 페이로드를 청크 단위로 반환할 수 있도록 `response` 및 `error` 엔드포인트의 동작이 약간 수정되었습니다. 특정 동작에 대한 자세한 내용은 다음 섹션을 참조하세요.
+ `/runtime/invocation/AwsRequestId/response` - 런타임에서 `Content-Type` 헤더를 전파하여 클라이언트로 전송합니다. Lambda는 HTTP/1.1 청크 분할 전송 인코딩을 통해 응답 페이로드를 청크로 반환합니다. Lambda로 응답을 스트리밍하려면 런타임에서 다음을 수행해야 합니다.
+ `Lambda-Runtime-Function-Response-Mode` HTTP 헤더를 `streaming`로 설정합니다.
+ `Transfer-Encoding` 헤더를 `chunked`로 설정합니다.
+ HTTP/1.1 청크 분할 전송 인코딩 사양을 준수하는 응답을 작성합니다.
+ 응답을 성공적으로 작성한 후 기본 연결을 닫습니다.
+ `/runtime/invocation/AwsRequestId/error` - 이 런타임은 이 엔드포인트를 사용하여 `Transfer-Encoding` 헤더도 허용하는 Lambda에 함수 또는 런타임 오류를 보고할 수 있습니다. 이 엔드포인트는 런타임이 호출 응답 전송을 시작하기 전에만 호출할 수 있습니다.
+ `/runtime/invocation/AwsRequestId/response`의 오류 트레일러를 사용하여 미드스트림 오류 보고 – 이 런타임은 호출 응답 작성을 시작한 후 발생하는 오류를 보고하기 위해 선택적으로 `Lambda-Runtime-Function-Error-Type` 및 `Lambda-Runtime-Function-Error-Body`라는 HTTP 후행 헤더를 연결할 수 있습니다. Lambda는 이를 성공적인 응답으로 간주하고 런타임이 클라이언트에 제공하는 오류 메타데이터를 전달합니다.
**참고**
후행 헤더를 첨부하려면 런타임이 HTTP 요청 시작 시 `Trailer` 헤더 값을 설정해야 합니다. 이는 HTTP/1.1 청크 분할 전송 인코딩 사양의 요구 사항입니다.
+ `Lambda-Runtime-Function-Error-Type` – 런타임에서 발생한 오류 유형입니다. 이 헤더는 문자열 값으로 구성됩니다. Lambda는 모든 문자열을 허용하지만 ** 형식을 사용하는 것이 좋습니다. 예를 들어 `Runtime.APIKeyNotFound`입니다.
+ `Lambda-Runtime-Function-Error-Body` - 오류에 대한 base64로 인코딩된 정보입니다.
## Lambda 관리형 인스턴스에 대한 사용자 지정 런타임 빌드
Lambda 관리형 인스턴스는 Lambda(기본값) 함수와 동일한 런타임 API를 사용합니다. 하지만 관리형 인스턴스의 동시 실행 모델을 지원하기 위해 사용자 지정 런타임을 구현하는 방법에는 큰 차이점이 있습니다.
### 동시 요청 처리
관리형 인스턴스에 대한 사용자 지정 런타임을 빌드할 때의 주된 차이점은 동시 간접 호출 지원입니다. 런타임이 한 번에 하나의 간접 호출을 처리하는 Lambda(기본값) 함수와 달리 관리형 인스턴스는 단일 실행 환경 내에서 여러 개의 간접 호출을 동시에 처리할 수 있습니다.
사용자 지정 런타임은 다음 사항을 충족해야 합니다.
+ **동시 `/next` 요청 지원** - 런타임은 `AWS_LAMBDA_MAX_CONCURRENCY` 환경 변수에 지정된 제한까지 [다음 간접 호출](runtimes-api.md#runtimes-api-next) API를 여러 번 동시에 호출할 수 있습니다.
+ **동시 `/response` 요청 처리** - 여러 개의 간접 호출이 [간접 호출 응답](runtimes-api.md#runtimes-api-response) API를 동시에 호출할 수 있습니다.
+ **스레드 안전 요청 처리 구현** - 공유 리소스 및 상태를 적절하게 관리하여 동시 간접 호출이 서로 방해가 되지 않도록 해야 합니다.
+ **고유한 요청 ID 사용** - `Lambda-Runtime-Aws-Request-Id` 헤더를 사용하여 각 간접 호출을 개별적으로 추적하여 응답을 해당 요청과 일치시킵니다.
### 구현 패턴
관리형 인스턴스 런타임의 일반적인 구현 패턴에는 동시 간접 호출을 처리하기 위한 작업자 스레드 또는 프로세스 생성이 포함됩니다.
1. **동시성 제한 읽기** - 초기화 시 `AWS_LAMBDA_MAX_CONCURRENCY` 환경 변수를 읽고 지원할 동시 간접 호출 수를 결정합니다.
1. **작업자 풀 생성** - 동시성 제한과 같은 작업자 풀(스레드, 프로세스 또는 비동기식 태스크)을 초기화합니다.
1. **작업자 처리 루프** - 각 작업자가 독립적으로 수행하는 작업:
+ `/runtime/invocation/next` 직접 호출로 간접 호출 이벤트 가져오기
+ 이벤트 데이터로 함수 핸들러 간접 호출
+ `/runtime/invocation/AwsRequestId/response`에 응답 게시
+ 루프 반복
### 추가 고려 사항
+ **로깅 형식** - 관리형 인스턴스는 JSON 로그 형식만 지원합니다. 런타임에서 `AWS_LAMBDA_LOG_FORMAT` 환경 변수를 준수하고 JSON 형식만 사용해야 합니다. 자세한 내용은 [JSON 및 일반 텍스트 로그 형식 구성](monitoring-cloudwatchlogs-logformat.md) 섹션을 참조하세요.
+ **공유 리소스** - `/tmp` 디렉터리와 같은 공유 리소스를 동시 간접 호출에서 사용할 때는 주의해야 합니다. 경합 상황을 방지하기 위해 적절한 잠금 메커니즘을 구현해야 합니다.
Lambda 관리형 인스턴스 실행 환경에 대한 자세한 내용은 [Lambda 관리형 인스턴스 실행 환경 이해](lambda-managed-instances-execution-environment.md) 항목을 참조하세요.
# 자습서: 사용자 지정 런타임 빌드
이 자습서에서는 사용자 지정 런타임이 있는 Lambda 함수를 생성합니다. 먼저 함수의 배포 패키지에 런타임을 포함시킵니다. 그런 다음, 이 런타임을 함수와는 별도로 관리하는 계층으로 마이그레이션합니다. 마지막으로 리소스 기반 권한 정책을 업데이트하여 런타임 계층을 다른 모든 사용자와 공유합니다.
## 사전 조건
이 자습서에서는 사용자가 기본 Lambda 작업과 Lambda 콘솔에 대해 어느 정도 알고 있다고 가정합니다. 그렇지 않은 경우 [콘솔로 Lambda 함수 생성](getting-started.md#getting-started-create-function)의 지침에 따라 첫 Lambda 함수를 생성합니다.
다음 단계를 완료하려면 [AWS CLI 버전 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)가 필요합니다. 명령과 예상 결과는 별도의 블록에 나열됩니다.
```
aws --version
```
다음 결과가 표시됩니다.
```
aws-cli/2.13.27 Python/3.11.6 Linux/4.14.328-248.540.amzn2.x86_64 exe/x86_64.amzn.2
```
긴 명령의 경우 이스케이프 문자(`\`)를 사용하여 명령을 여러 행으로 분할합니다.
Linux 및 macOS는 선호 셸과 패키지 관리자를 사용합니다.
**참고**
Windows에서는 Lambda와 함께 일반적으로 사용하는 일부 Bash CLI 명령(예:`zip`)은 운영 체제의 기본 제공 터미널에서 지원되지 않습니다. Ubuntu와 Bash의 Windows 통합 버전을 가져오려면 [Linux용 Windows Subsystem을 설치](https://docs.microsoft.com/en-us/windows/wsl/install-win10)합니다. 이 안내서의 예제 CLI 명령은 Linux 형식을 사용합니다. Windows CLI를 사용하는 경우 인라인 JSON 문서를 포함하는 명령의 형식을 다시 지정해야 합니다.
Lambda 함수를 생성하려면 IAM 역할이 필요합니다. 이 역할에는 로그를 CloudWatch Logs로 전송하는 권한과 함수에서 사용하는 AWS 서비스에 액세스하는 권한이 필요합니다. 함수 개발을 위한 역할이 없는 경우 이 역할을 하나 생성합니다.
**실행 역할을 만들려면**
1. IAM 콘솔에서 [역할 페이지](https://console.aws.amazon.com/iam/home#/roles)를 엽니다.
1. **역할 생성**을 선택합니다.
1. 다음 속성을 사용하여 역할을 만듭니다.
+ **신뢰할 수 있는 엔터티** – **Lambda**.
+ **권한** – **AWSLambdaBasicExecutionRole**.
+ **역할 이름** – **lambda-role**.
**AWSLambdaBasicExecutionRole** 정책은 함수가 CloudWatch Logs에 로그를 쓰는 데 필요한 권한을 가집니다.
## 함수 생성
사용자 지정 런타임이 있는 Lambda 함수를 생성합니다. 이 예제는 두 개의 파일 즉, 런타임 `bootstrap` 파일과 함수 핸들러를 포함합니다. 두 파일은 모두 Bash에서 구현됩니다.
1. 프로젝트에 대한 디렉터리를 생성하고 해당 디렉터리로 전환합니다.
```
mkdir runtime-tutorial
cd runtime-tutorial
```
1. `bootstrap`라는 파일을 새로 생성합니다. 사용자 지정 런타임입니다.
**Example 부트스트랩**
```
#!/bin/sh
set -euo pipefail
# Initialization - load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
런타임은 배포 패키지에서 함수 스크립트를 로드합니다. 런타임은 두 변수를 사용하여 스크립트를 찾습니다. `LAMBDA_TASK_ROOT`는 패키지가 추출된 위치를 알려주며 `_HANDLER`에는 스크립트의 이름이 포함됩니다.
런타임은 함수 스크립트를 로딩한 후 런타임 API를 사용하여 Lambda에서 간접 호출 이벤트를 검색하고 이벤트를 핸들러로 전달하며 응답을 Lambda에 다시 게시합니다. 요청 ID를 가져오기 위해 런타임은 API 응답의 헤더를 임시 파일에 저장하고 이 파일에서 `Lambda-Runtime-Aws-Request-Id` 헤더를 읽습니다.
**참고**
런타임은 오류 처리를 포함한 추가적인 책임이 있으며, 핸들러에 컨텍스트 정보를 제공합니다. 세부 정보는 [요구 사항](runtimes-custom.md#runtimes-custom-build)을 참조하세요.
1. 함수에 대해 스크립트를 생성합니다. 다음 스크립트 예는 이벤트 데이터를 취하여 이를 `stderr`에 기록한 후 반환하는 핸들러 함수를 정의합니다.
**Example function.sh**
```
function handler () {
EVENT_DATA=$1
echo "$EVENT_DATA" 1>&2;
RESPONSE="Echoing request: '$EVENT_DATA'"
echo $RESPONSE
}
```
`runtime-tutorial` 디렉터리는 이제 다음과 같아야 합니다.
```
runtime-tutorial
├ bootstrap
└ function.sh
```
1. 실행 파일들을 생성하여 이를 .zip 파일 아카이브에 추가합니다. 이것이 배포 패키지입니다.
```
chmod 755 function.sh bootstrap
zip function.zip function.sh bootstrap
```
1. `bash-runtime`이라는 이름의 함수를 생성합니다. `--role`에 Lambda [실행 역할](lambda-intro-execution-role.md)의 ARN을 입력합니다.
```
aws lambda create-function --function-name bash-runtime \
--zip-file fileb://function.zip --handler function.handler --runtime provided.al2023 \
--role arn:aws:iam::123456789012:role/lambda-role
```
1. 함수를 간접 호출합니다.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
**cli-binary-format** 옵션은 AWS CLI 버전 2를 사용할 때 필요합니다. 이 설정을 기본 설정으로 지정하려면 `aws configure set cli-binary-format raw-in-base64-out`을(를) 실행하세요. 자세한 내용은 [AWS CLI 지원되는 글로벌 명령줄 옵션](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)을 AWS Command Line Interface 사용 설명서 버전 2에서 참조하세요.
다음과 같은 응답이 표시되어야 합니다.
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. 응답을 확인합니다.
```
cat response.txt
```
다음과 같은 응답이 표시되어야 합니다.
```
Echoing request: '{"text":"Hello"}'
```
## 계층 생성
함수 코드에서 런타임 코드를 분리하려면 런타임만 포함하는 계층을 생성하세요. 계층을 사용하면 함수의 종속 항목들을 독립적으로 개발할 수 있으며, 여러 함수가 있는 동일한 계층을 사용할 때 스토리지 사용량을 줄일 수 있습니다. 자세한 내용은 [계층으로 Lambda 종속성 관리](chapter-layers.md) 단원을 참조하십시오.
1. `bootstrap` 파일을 포함하는 .zip 파일을 생성합니다.
```
zip runtime.zip bootstrap
```
1. [publish-layer-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-layer-version.html?highlight=nodejs16%20x) 명령을 사용하여 계층을 생성합니다.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
그러면 해당 계층의 첫 번째 버전이 생성됩니다.
## 함수 업데이트
함수에 런타임 계층을 사용하려면 이 계층을 사용하도록 함수를 구성하고 함수에서 런타임 코드를 제거하세요.
1. 계층을 가져 오도록 함수 구성을 업데이트하세요.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:1
```
이 작업으로 `/opt` 디렉터리의 함수에 런타임이 추가됩니다. Lambda가 계층의 런타임을 사용하도록 하려면 다음 두 단계에 표시된 것처럼 함수의 배포 패키지에서 `boostrap`을 제거해야 합니다.
1. 함수 코드를 포함하는 .zip 파일을 생성합니다.
```
zip function-only.zip function.sh
```
1. 핸들러 스크립트만 포함하도록 함수 코드를 업데이트하세요.
```
aws lambda update-function-code --function-name bash-runtime --zip-file fileb://function-only.zip
```
1. 함수를 간접 호출하여 런타임 계층에서 작동하는지 확인합니다.
```
aws lambda invoke --function-name bash-runtime --payload '{"text":"Hello"}' response.txt --cli-binary-format raw-in-base64-out
```
**cli-binary-format** 옵션은 AWS CLI 버전 2를 사용할 때 필요합니다. 이 설정을 기본 설정으로 지정하려면 `aws configure set cli-binary-format raw-in-base64-out`을(를) 실행하세요. 자세한 내용은 [AWS CLI 지원되는 글로벌 명령줄 옵션](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list)을 AWS Command Line Interface 사용 설명서 버전 2에서 참조하세요.
다음과 같은 응답이 표시되어야 합니다.
```
{
"StatusCode": 200,
"ExecutedVersion": "$LATEST"
}
```
1. 응답을 확인합니다.
```
cat response.txt
```
다음과 같은 응답이 표시되어야 합니다.
```
Echoing request: '{"text":"Hello"}'
```
## 런타임 업데이트
1. 실행 환경에 관한 정보를 기록하려면 환경 변수를 출력하도록 런타임 스크립트를 업데이트하세요.
**Example 부트스트랩**
```
#!/bin/sh
set -euo pipefail
# Configure runtime to output environment variables
echo "## Environment variables:"
env
# Load function handler
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"
# Processing
while true
do
HEADERS="$(mktemp)"
# Get an event. The HTTP request will block until one is received
EVENT_DATA=$(curl -sS -LD "$HEADERS" "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
# Extract request ID by scraping response headers received above
REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
# Run the handler function from the script
RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")
# Send the response
curl "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response" -d "$RESPONSE"
done
```
1. `bootstrap` 파일의 새 버전을 포함하는 .zip 파일을 생성합니다.
```
zip runtime.zip bootstrap
```
1. `bash-runtime` 계층의 새로운 버전을 생성합니다.
```
aws lambda publish-layer-version --layer-name bash-runtime --zip-file fileb://runtime.zip
```
1. 새 버전의 계층을 사용하도록 함수를 구성합니다.
```
aws lambda update-function-configuration --function-name bash-runtime \
--layers arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2
```
## 계층 공유
계층을 다른 AWS 계정와 공유하려면 계층의 [리소스 기반 정책](access-control-resource-based.md)에 교차 계정 권한 문을 추가합니다. [add-layer-version-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-layer-version-permission.html) 명령을 실행하고 계정 ID를 `principal`로 지정합니다. 각 문에서 단일 계정, 모든 계정 또는 [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html)의 조직을 대상으로 권한을 부여할 수 있습니다.
다음 예시에서는 111122223333 계정에 `bash-runtime` 계층의 버전 2에 대한 액세스 권한을 부여합니다.
```
aws lambda add-layer-version-permission \
--layer-name bash-runtime \
--version-number 2 \
--statement-id xaccount \
--action lambda:GetLayerVersion \
--principal 111122223333 \
--output text
```
다음과 유사한 출력 화면이 표시되어야 합니다.
```
{"Sid":"xaccount","Effect":"Allow","Principal":{"AWS":"arn:aws:iam::111122223333:root"},"Action":"lambda:GetLayerVersion","Resource":"arn:aws:lambda:us-east-1:123456789012:layer:bash-runtime:2"}
```
권한은 하나의 계층 버전에만 적용됩니다. 새 계층 버전을 만들 때마다 해당 과정을 반복합니다.
## 정리
각 버전의 계층을 삭제합니다.
```
aws lambda delete-layer-version --layer-name bash-runtime --version-number 1
aws lambda delete-layer-version --layer-name bash-runtime --version-number 2
```
이 함수는 계층의 버전 2에 대한 참조가 있으므로 Lambda 내에 여전히 존재합니다. 함수는 계속 작동하며, 다만 삭제된 버전을 사용하도록 함수를 구성할 수는 없습니다. 함수의 계층 목록을 수정하려면 새 버전을 지정하거나 삭제된 계층을 생략해야 합니다.
[delete-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/delete-function.html) 명령으로 함수를 삭제합니다.
```
aws lambda delete-function --function-name bash-runtime
```