# Lambda 관리형 인스턴스 Lambda 관리형 인스턴스를 사용하면 인스턴스 수명 주기, 운영 체제 및 언어 런타임 패치 적용, 라우팅, 로드 밸런싱 또는 조정 정책을 관리하지 않고도 Graviton4, 네트워크 최적화 인스턴스 및 기타 특수 컴퓨팅 옵션을 포함한 최신 세대 Amazon EC2 인스턴스에서 Lambda 함수를 실행할 수 있습니다. Lambda 관리형 인스턴스를 사용하면 EC2 절감형 플랜 및 예약 인스턴스를 비롯한 EC2 요금 관련 혜택을 이용할 수 있습니다. 지원되는 인스턴스 유형 목록을 보려면 [AWS Lambda 요금](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) 페이지로 이동하고 AWS 리전을 선택합니다. ## 주요 기능 Lambda 관리형 인스턴스는 다음 기능을 제공합니다. + **적합한 인스턴스 선택** - Graviton4와 같은 최신 CPU 액세스, 구성 가능한 메모리-CPU 비율, 고대역폭 네트워킹 등 성능 및 비용 요구 사항에 따라 [적절한 인스턴스](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High)를 선택합니다. + **자동 프로비저닝** - AWS는 적절한 인스턴스를 자동으로 프로비저닝하고 함수 실행 환경을 가동합니다. + **동적 조정** - 인스턴스는 함수 트래픽 패턴에 따라 동적으로 규모가 조정됩니다. + **완전 관리형 환경** - AWS는 사용자에게 익숙한 광범위한 이벤트 소스 통합을 통해 인프라 관리, 규모 조정, 패치 적용 및 라우팅을 처리합니다. ## Lambda 관리형 인스턴스를 사용해야 하는 경우 다음 사용 사례에 Lambda 관리형 인스턴스를 고려하는 것이 좋습니다. + **예측 가능한 대용량 워크로드** - 예기치 못한 트래픽 급증이 발생하지 않는 정상 상태 워크로드에 적합합니다. Lambda 관리형 인스턴스는 기본적으로 5분 이내에 2배로 증가하는 트래픽을 처리하도록 규모가 조정됩니다. + **성능 중시 애플리케이션** - 최신 CPU, 다양한 메모리-CPU 비율 및 높은 네트워크 처리량에 대한 액세스 + **규제 요구 사항** - VPC 및 인스턴스 배치 제어에 대한 세분화된 거버넌스 필요 + **다양한 애플리케이션** - 서버리스로 마이그레이션하는 이벤트 기반 애플리케이션, 미디어/데이터 처리, 웹 애플리케이션 및 레거시 워크로드 ## 작동 방식 Lambda 관리형 인스턴스는 용량 공급자를 함수 실행의 기반으로 사용합니다. 1. **용량 공급자 생성** - VPC 구성과 선택적으로 인스턴스 요구 사항 및 조정 구성을 지정하여 함수의 실행 위치 정의 1. **함수 생성** - 평소와 같이 Lambda 함수를 생성하고 용량 공급자에 연결 1. **함수 버전 게시** - 게시된 이후 용량 공급자 인스턴스에서 함수 버전 활성화 용량 공급자와 함께 함수 버전을 게시하면 Lambda는 계정에서 관리형 인스턴스를 시작합니다. 기본적으로 AZ 복원력을 위해 인스턴스 3개를 시작하고 실행 환경 3개를 시작한 다음 함수 버전을 ACTIVE로 표시합니다. 이미 다른 함수가 실행 중인 기존 용량 공급자에 함수를 연결하는 경우 사용 가능한 인스턴스에 이미 새 함수의 실행 환경을 수용할 수 있는 용량이 있다면 Lambda가 새 인스턴스를 가동하지 않을 수 있습니다. ## 동시성 모델 Lambda 관리형 인스턴스는 다중 동시 간접 호출을 지원하며, 하나의 실행 환경이 여러 개의 간접 호출을 동시에 처리할 수 있습니다. 이는 하나의 실행 환경이 한 번에 최대 하나의 간접 호출을 실행할 수 있는 단일 동시성 모델을 제공하는 Lambda(기본값) 컴퓨팅 유형과 다릅니다. 다중 동시성은 기본 EC2 인스턴스의 사용률을 높이고 웹 서비스 또는 배치 작업과 같이 IO를 많이 사용하는 애플리케이션에 특히 유용합니다. 실행 모델의 차이로 인해 스레드 안전, 상태 관리 및 컨텍스트 격리를 런타임에 따라 다르게 처리해야 합니다. ## 테넌시 및 격리 Lambda(기본값) 컴퓨팅 유형은 Firecracker microVM 기술을 사용하여 공유 Lambda 플릿에서 실행 중인 실행 환경 간에 격리를 제공하는 다중 테넌트입니다. Lambda 관리형 인스턴스는 계정에서 실행되므로 최신 EC2 하드웨어 및 요금 옵션을 이용할 수 있습니다. 관리형 인스턴스는 EC2 Nitro 인스턴스에서 실행되는 컨테이너를 사용하여 Firecracker가 아닌 격리를 제공합니다. 용량 공급자는 Lambda 함수의 보안 경계 역할을 합니다. 함수는 인스턴스 내의 컨테이너에서 실행됩니다. ### 관리형 인스턴스 이해 Lambda 관리형 인스턴스 함수는 계정의 EC2 관리형 인스턴스에서 실행됩니다. 이러한 인스턴스는 Lambda에서 완전히 관리되므로 표준 EC2 인스턴스에 비해 인스턴스에 대한 권한이 제한적입니다. 다음을 통해 계정에서 Lambda 관리형 인스턴스를 식별할 수 있습니다. + EC2 `DescribeInstances` 출력의 `Operator` 필드 존재 여부 + 인스턴스의 `aws:lambda:capacity-provider` 태그 이러한 인스턴스에서는 수동 종료 등 표준 EC2 작업을 직접 수행할 수 없습니다. 관리형 인스턴스를 삭제하려면 연결된 용량 공급자를 삭제합니다. 이후 Lambda는 용량 공급자 삭제 프로세스의 일부로 인스턴스를 종료합니다. ## 가격 책정 Lambda 관리형 인스턴스는 EC2 기반 요금을 사용하며, EC2 인스턴스 비용에 15%의 관리 요금이 추가됩니다. 이 요금 모델은 EC2 절감형 플랜, 예약 인스턴스 및 EC2 사용량에 적용되는 기타 요금 할인을 지원합니다. 요금 페이지에서 자세한 내용을 확인하세요. [https://aws.amazon.com/lambda/pricing/](https://aws.amazon.com/lambda/pricing/) **중요:** EC2 요금 할인은 기본 EC2 컴퓨팅에만 적용되며 관리 요금에는 적용되지 않습니다. ## Lambda 관리형 인스턴스와 Lambda(기본값) 컴퓨팅 유형의 차이 Lambda(기본값)와 비교할 때의 Lambda 관리형 인스턴스의 Lambda 요청 처리 방식의 차이점입니다. **주요 차이점:** | | Lambda(기본값) | Lambda 관리형 인스턴스 | | --- | --- | --- | | 동시성 모델 | 실행 환경 하나가 한 번에 최대 하나의 간접 호출을 지원할 수 있는 단일 동시성 모델 | 하나의 실행 환경에서 여러 간접 호출을 동시에 처리할 수 있는 다중 동시 간접 호출로 특히 IO 사용량이 높은 애플리케이션의 처리량 증가 | | 테넌시 및 격리 | Firecracker microVM 기술을 사용하여 공유 Lambda 플릿에서 실행 중인 실행 환경 간에 격리를 제공하는 다중 테넌트 | EC2 Nitro를 사용하여 계정 내 실행으로 격리 제공 용량 공급자가 보안 경계 역할을 하고, 함수는 인스턴스 내의 컨테이너에서 실행 | | 요금 모델 | 요청당 기간 요금 | 온디맨드 및 예약 인스턴스를 포함한 EC2 요금 모델을 사용한 인스턴스 기반 요금과 컴퓨팅 절감형 플랜과 같은 절감 옵션 | | 규모 조정 동작 | 수신하는 간접 호출을 처리할 수 있는 무료 실행 환경이 없는 경우 규모 조정(콜드 스타트), 트래픽 없이 0으로 조정 | 콜드 스타트 없이 CPU 리소스 사용률에만 따라 비동기식으로 조정, 트래픽 없이 구성된 최소 실행 환경으로 조정 | | 다음과 같은 경우에 가장 적합 | 콜드 스타트 시간을 처리할 수 있는 트래픽 급증 함수 또는 0으로 조정하면 도움이 되는 지속적 로드 없는 애플리케이션 | EC2의 유연성, 요금제 및 하드웨어 옵션을 원하는 경우 예측 가능한 대용량 트래픽 함수 | ## 다음 단계 + [Lambda 관리형 인스턴스의 용량 공급자](lambda-managed-instances-capacity-providers.md) 알아보기 + [Lambda 관리형 인스턴스의 규모 조정](lambda-managed-instances-scaling.md) 알아보기 + [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) 및 [Python](lambda-managed-instances-python-runtime.md)에 대한 런타임별 가이드 검토 + [용량 공급자에 대한 VPC 연결](lambda-managed-instances-networking.md) 구성 + [Lambda 관리형 인스턴스의 보안 및 권한](lambda-managed-instances-security.md) 이해 # Lambda 관리형 인스턴스 시작하기 ## Lambda 관리형 인스턴스 함수 생성(콘솔) Lambda 콘솔을 사용하여 용량 공급자가 관리하는 Amazon EC2 인스턴스에서 실행되는 관리형 인스턴스 함수를 생성할 수 있습니다. **중요:** 관리형 인스턴스 함수 생성 전에 먼저 용량 공급자를 생성해야 합니다. 이러한 함수에는 함수를 실행할 Amazon EC2 인프라를 정의하는 용량 공급자가 필요합니다. **Lambda 관리형 인스턴스 함수 생성(콘솔)** 1. Lambda 콘솔을 엽니다. 1. 왼쪽 탐색 창에서 **용량 공급자**를 선택합니다. 1. **용량 공급자 생성**을 선택합니다. 1. **용량 공급자 설정** 섹션에서 용량 공급자의 이름을 입력합니다. 1. 용량 공급자의 VPC 및 권한을 선택합니다. 기존 역할을 사용하거나 새 역할을 생성할 수 있습니다. 필요한 운영자 역할 생성에 대한 자세한 내용은 [Lambda 관리형 인스턴스의 Lambda 운영자 역할](lambda-managed-instances-operator-role.md)을 참조하세요. 1. **Advanced settings(고급 설정)**를 확장합니다. 1. 프로세서 아키텍처와 인스턴스 유형을 선택하여 **인스턴스 요구 사항**을 정의합니다. 1. **오도 스케일링**에서 용량 공급자의 최대 EC2 vCPU 수를 지정합니다. **수동 인스턴스 규모 조정 모드**를 선택하고 자체 조정 값을 입력하면 정밀하게 제어할 수 있습니다. 1. **용량 공급자 생성**을 선택하여 새 용량 공급자를 생성합니다. 1. 다음으로 **함수 생성**을 선택합니다. 1. **새로 작성**을 선택합니다. 1. **기본 정보** 창에 **함수 이름**을 입력합니다. 1. **런타임**에서 지원되는 런타임을 선택합니다. 1. 함수의 **아키텍처**를 선택합니다(용량 공급자에 대해 선택한 아키텍처와 동일). 기본값은 **x86\$164**입니다. 1. **권한**에 선택한 **실행 역할**에 대한 권한이 있어야 합니다. 그렇지 않으면 새 역할을 생성할 수 있습니다. 1. **추가 구성**에서 **컴퓨팅 유형**을 **Lambda 관리형 인스턴스**로 선택합니다. 1. 이전 단계에서 생성한 용량 공급자의 용량 공급자 ARN이 미리 선택되어야 합니다. 1. vCPU당 **메모리 크기** 및 **vCPU당 실행 환경 메모리(GiB) 비율**을 선택합니다. 1. **함수 생성**을 선택합니다. Lambda 관리형 인스턴스 함수가 생성되고 지정된 용량 공급자에 용량을 프로비저닝합니다. 함수 생성에는 일반적으로 몇 분 정도 걸립니다. 완료되면 함수 코드를 편집하고 첫 번째 테스트를 실행할 수 있습니다. ## Lambda 관리형 인스턴스 함수 생성(AWS CLI) ### 사전 조건 시작하기 전에 다음 항목이 준비되었는지 확인합니다. + **AWS CLI** - AWS CLI를 설치하고 구성합니다. 자세한 내용은 [최신 버전의 AWS CLI 설치 또는 업데이트](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)를 참조하세요. + **IAM 권한** - IAM 사용자 또는 역할에 Lambda 함수, 용량 공급자를 생성하고 IAM 역할을 전달할 수 있는 권한이 있어야 합니다. 계정에서 용량 공급자를 처음 생성하거나 서비스 연결 역할(SLR)이 삭제된 경우에도 `iam:CreateServiceLinkedRole`이 필요합니다. ### 1단계: 필요한 IAM 역할 생성 Lambda 관리형 인스턴스에는 함수의 실행 역할과 용량 공급자의 운영자 역할이라는 2가지 IAM 역할이 필요합니다. 운영자 역할을 통해 Lambda는 사용자를 대신하여 Amazon EC2 인스턴스를 시작, 종료 및 모니터링할 수 있습니다. 함수 실행 역할은 함수에 기타 AWS 서비스 및 리소스에 액세스할 수 있는 권한을 부여합니다. **Lambda 실행 역할 생성** 1. Lambda의 역할 수임을 허용하는 신뢰 정책 문서를 생성합니다. ``` cat > lambda-trust-policy.json << 'EOF' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF ``` 1. 실행 역할을 생성합니다. ``` aws iam create-role \ --role-name MyLambdaExecutionRole \ --assume-role-policy-document file://lambda-trust-policy.json ``` 1. 기본 실행 정책을 연결합니다. ``` aws iam attach-role-policy \ --role-name MyLambdaExecutionRole \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole ``` **용량 공급자 운영자 역할 생성** 1. Lambda의 운영자 역할 수임을 허용하는 신뢰 정책 문서를 생성합니다. ``` cat > operator-trust-policy.json << 'EOF' { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EOF ``` 1. 운영자 역할 생성을 생성합니다. ``` aws iam create-role \ --role-name MyCapacityProviderOperatorRole \ --assume-role-policy-document file://operator-trust-policy.json ``` 1. 필요한 EC2 권한 정책 연결을 연결합니다. ``` aws iam attach-role-policy \ --role-name MyCapacityProviderOperatorRole \ --policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator ``` ### 2단계: VPC 리소스 설정 Lambda 관리형 인스턴스는 VPC에서 실행되며 서브넷 및 보안 그룹이 필요합니다. **VPC 리소스 생성** 1. VPC를 생성합니다. ``` VPC_ID=$(aws ec2 create-vpc \ --cidr-block 10.0.0.0/16 \ --query 'Vpc.VpcId' \ --output text) ``` 1. 서브넷을 생성합니다. ``` SUBNET_ID=$(aws ec2 create-subnet \ --vpc-id $VPC_ID \ --cidr-block 10.0.1.0/24 \ --query 'Subnet.SubnetId' \ --output text) ``` 1. 보안 그룹을 생성합니다. ``` SECURITY_GROUP_ID=$(aws ec2 create-security-group \ --group-name my-capacity-provider-sg \ --description "Security group for Lambda Managed Instances" \ --vpc-id $VPC_ID \ --query 'GroupId' \ --output text) ``` **참고:** VPC 외부의 리소스에 액세스하고 텔레메트리 데이터를 CloudWatch Logs 및 X-Ray로 전송하려면 Lambda 관리형 인스턴스 함수에 VPC 구성이 필요합니다. 구성 세부 정보는 [Lambda 관리형 인스턴스의 네트워킹](lambda-managed-instances-networking.md)을 참조하세요. ### 3단계: 용량 공급자 생성 용량 공급자는 Lambda 함수를 실행하는 EC2 인스턴스를 관리합니다. **용량 공급자를 만들려면** ``` ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) aws lambda create-capacity-provider \ --capacity-provider-name my-capacity-provider \ --vpc-config SubnetIds=[$SUBNET_ID],SecurityGroupIds=[$SECURITY_GROUP_ID] \ --permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::${ACCOUNT_ID}:role/MyCapacityProviderOperatorRole \ --instance-requirements Architectures=[x86_64] \ --capacity-provider-scaling-config MaxVCpuCount=30 ``` 이 명령은 다음 구성을 사용하여 용량 공급자를 생성합니다. + **VPC 구성** - EC2 인스턴스의 서브넷 및 보안 그룹 지정 + **권한** - Lambda가 EC2 인스턴스 관리에 사용하는 IAM 역할 정의 + **인스턴스 요구 사항** - x86\$164 아키텍처 지정 + **조정 구성** - 용량 공급자에 대해 최대 30개의 vCPU 설정 ### 4단계: 인라인 코드를 사용하여 Lambda 함수 생성 **인라인 코드를 사용하여 함수 생성** 1. 먼저 간단한 Python 함수를 생성하고 인라인으로 패키징합니다. ``` # Create a temporary directory for the function code mkdir -p /tmp/my-lambda-function cd /tmp/my-lambda-function # Create a simple Python handler cat > lambda_function.py << 'EOF' import json def lambda_handler(event, context): return { 'statusCode': 200, 'body': json.dumps({ 'message': 'Hello from Lambda Managed Instances!', 'event': event }) } EOF # Create a ZIP file zip function.zip lambda_function.py ``` 1. 인라인 ZIP 파일을 사용하여 Lambda 함수를 생성합니다. ``` ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) REGION=$(aws configure get region) aws lambda create-function \ --function-name my-managed-instance-function \ --package-type Zip \ --runtime python3.13 \ --handler lambda_function.lambda_handler \ --zip-file fileb:///tmp/my-lambda-function/function.zip \ --role arn:aws:iam::${ACCOUNT_ID}:role/MyLambdaExecutionRole \ --architectures x86_64 \ --memory-size 2048 \ --ephemeral-storage Size=512 \ --capacity-provider-config LambdaManagedInstancesCapacityProviderConfig={CapacityProviderArn=arn:aws:lambda:${REGION}:${ACCOUNT_ID}:capacity-provider:my-capacity-provider} ``` 다음을 사용하여 함수를 생성합니다. + **런타임** – Python 3.13 + **핸들러** - `lambda_function.py`의 `lambda_handler` 함수 + **메모리** - 2,048MB + **임시 스토리지 크기** - 512MB + **용량 공급자** - 생성한 용량 공급자에 연결 ### 5단계: 함수 버전 게시 Lambda 관리형 인스턴스에서 함수를 실행하려면 버전을 게시해야 합니다. **함수 버전 게시** ``` aws lambda publish-version \ --function-name my-managed-instance-function ``` 이 명령은 함수 버전 1을 게시하고 용량 공급자에 배포합니다. ### 6단계: 함수 간접 호출 게시 후 함수를 간접 호출할 수 있습니다. **함수를 간접 호출하려면** ``` aws lambda invoke \ --function-name my-managed-instance-function:1 \ --payload '{"name": "World"}' \ response.json # View the response cat response.json ``` 함수는 용량 공급자가 관리하는 EC2 인스턴스에서 실행되고 응답을 반환합니다. ### 정리 요금이 발생하지 않도록 생성한 리소스를 삭제합니다. 1. 함수를 삭제합니다. ``` aws lambda delete-function --function-name my-managed-instance-function ``` 1. 용량 공급자를 삭제합니다. ``` aws lambda delete-capacity-provider --capacity-provider-name my-capacity-provider ``` 1. VPC 리소스를 삭제합니다. ``` aws ec2 delete-security-group --group-id $SECURITY_GROUP_ID aws ec2 delete-subnet --subnet-id $SUBNET_ID aws ec2 delete-vpc --vpc-id $VPC_ID ``` 1. IAM 역할을 삭제합니다. ``` aws iam detach-role-policy \ --role-name MyLambdaExecutionRole \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole aws iam detach-role-policy \ --role-name MyCapacityProviderOperatorRole \ --policy-arn arn:aws:iam::aws:policy/AWSLambdaManagedEC2ResourceOperator aws iam delete-role --role-name MyLambdaExecutionRole aws iam delete-role --role-name MyCapacityProviderOperatorRole ``` # 핵심 개념 Lambda 관리형 인스턴스에는 기존 Lambda 함수와 다른 몇 가지 핵심 개념이 도입됩니다. 이러한 개념을 이해해야 EC2 인프라에서 함수를 효과적으로 배포 및 관리할 수 있습니다. **용량 공급자**는 Lambda 관리형 인스턴스의 기반을 형성합니다. 용량 공급자는 VPC 구성, 인스턴스 요구 사항 및 조정 정책을 포함하여 함수가 실행되는 컴퓨팅 인프라를 정의합니다. 용량 공급자는 함수의 보안 경계 역할을 하며, 동일한 용량 공급자에 할당된 모든 함수를 상호 신뢰해야 합니다. **규모 조정 동작**은 기존 Lambda 함수와 크게 다릅니다. 간접 호출이 도착할 때 온디맨드 방식으로 규모를 조정하는 대신 관리형 인스턴스는 CPU 리소스 사용률에 따라 비동기식으로 규모를 조정합니다. 이 접근 방식으로 콜드 스타트가 이루어지지 않지만 트래픽 증가를 계획해야 합니다. 5분 이내에 트래픽이 2배를 초과하는 경우 Lambda가 수요에 맞게 용량을 확장함에 따라 스로틀링이 발생할 수 있습니다. **보안 및 권한**을 신중하게 고려해야 합니다. Lambda가 용량 공급자의 EC2 리소스를 관리하도록 허용하려면 운영자 역할 권한이 필요합니다. 추가로 사용자에게 `lambda:PassCapacityProvider` 권한이 있어야 용량 공급자에 함수를 할당할 수 있고, 이는 특정 인프라에서 실행할 수 있는 함수를 제어하는 보안 게이트 역할을 합니다. **다중 동시 실행**은 관리형 인스턴스의 주요 특성입니다. 각 실행 환경은 여러 간접 호출을 동시에 처리하여 IO가 많은 애플리케이션의 리소스 사용률을 극대화할 수 있습니다. 이는 각 환경에서 한 번에 하나의 요청을 처리하는 기존 Lambda와 다릅니다. 이 실행 모델의 경우 런타임에 따라 스레드 안전, 상태 관리 및 컨텍스트 격리에 주의를 기울여야 합니다. 다음 섹션에서는 각 핵심 개념에 대한 자세한 내용을 제공합니다. # 용량 공급자 용량 공급자는 Lambda 관리형 인스턴스 실행의 기반입니다. 함수의 보안 경계 역할을 하고 Lambda가 사용자를 대신하여 프로비저닝 및 관리할 컴퓨팅 리소스를 정의합니다. 용량 공급자를 생성할 때 다음을 지정합니다. + **VPC 구성** - 인스턴스가 실행될 서브넷 및 보안 그룹 + **권한** - Lambda가 EC2 리소스를 관리하기 위한 IAM 역할 + **인스턴스 요구 사항**(선택 사항) - 아키텍처 및 [인스턴스 유형](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High) 기본 설정 + **조정 구성**(선택 사항) - Lambda가 인스턴스 규모를 조정하는 방법 ## 보안 경계로서의 용량 공급자 이해 용량 공급자는 VPC 내 Lambda 함수의 보안 경계 역할을 하여 Firecracker 기반 격리를 대체합니다. 함수는 이러한 인스턴스 내의 컨테이너에서 실행되지만 Firecracker microVM과 달리 컨테이너는 함수 간 보안 격리를 제공하지 않습니다. **주요 보안 개념:** + **용량 공급자**: Lambda 함수의 신뢰 수준을 정의하는 보안 경계 + **컨테이너 격리**: 컨테이너는 보안 공급자가 아니며, 신뢰할 수 없는 워크로드 간의 보안에 컨테이너를 의존해서는 안 됨 + **신뢰 분리**: 서로 다른 용량 공급자를 사용하여 상호 신뢰할 수 없는 워크로드 분리 ## 용량 공급자 생성 AWS CLI, AWS Management Console 또는 AWS SDK를 사용하여 용량 공급자를 생성할 수 있습니다. **AWS CLI 사용:** ``` aws lambda create-capacity-provider \ --capacity-provider-name my-capacity-provider \ --vpc-config SubnetIds=subnet-12345,subnet-67890,subnet-11111,SecurityGroupIds=sg-12345 \ --permissions-config CapacityProviderOperatorRoleArn=arn:aws:iam::123456789012:role/MyOperatorRole \ --instance-requirements Architectures=x86_64 \ --capacity-provider-scaling-config ScalingMode=Auto ``` ### 필수 파라미터 **CapacityProviderName** + 용량 공급자의 고유한 이름 + AWS 계정 내에서 고유해야 함 **VpcConfig** + **SubnetIds**(필수): 1개 이상의 서브넷(최대 16개). 복원력을 위해 여러 가용 영역에 걸친 서브넷 사용. + **SecurityGroupIds**(선택 사항): 인스턴스의 보안 그룹. 지정하지 않으면 VPC 기본 보안 그룹으로 기본 설정. **PermissionsConfig** + **CapacityProviderOperatorRoleArn**(필수): Lambda가 용량 공급자의 EC2 리소스를 관리할 수 있도록 허용하는 IAM 역할 ### 선택적 파라미터 **InstanceRequirements** 용량 공급자의 아키텍처 및 [인스턴스 유형](https://aws.amazon.com/lambda/pricing/#:~:text=EPU%20pricing%20applies.-,Management%20Fees,-Pricing%20Example%3A%20High)을 지정합니다. + **Architectures**: `x86_64` 또는 `arm64`를 선택합니다. 기본값은 `x86_64`입니다. + **AllowedInstanceTypes**: 허용된 인스턴스 유형을 지정합니다. 예시: `m5.8xlarge` + **ExcludedInstanceTypes**: 와일드카드를 사용하여 제외된 인스턴스 유형을 지정합니다. AllowedInstanceTypes 또는 ExcludedInstanceTypes 중 하나만 지정 가능합니다. 기본적으로 Lambda는 워크로드에 최적인 인스턴스 유형을 선택합니다. 가능한 인스턴스 유형 수를 제한하면 가용성이 낮아질 수 있으므로 Lambda 관리형 인스턴스가 인스턴스 유형을 자동으로 선택하도록 하는 것이 좋습니다. **CapacityProviderScalingConfig** Lambda의 인스턴스 규모 조정 방법을 구성합니다. + **ScalingMode**: `Auto`로 설정하면 자동 조정이, `Manual`로 설정하면 수동 제어가 적용됩니다. 기본값은 `Auto`입니다. + **MaxVCpuCount**: 용량 공급자의 최대 vCPU 수입니다. 기본값은 400입니다. + **ScalingPolicies**: CPU 및 메모리 사용률에 대한 목표 추적 조정 정책을 정의합니다. **KmsKeyArn** EBS 암호화를 위한 AWS KMS 키를 지정합니다. 지정하지 않으면 AWS 관리형 키로 기본 설정됩니다. **Tags** 태그를 추가하여 용량 공급자를 구성하고 관리합니다. ## 용량 공급자 관리 ### 용량 공급자 업데이트 `UpdateCapacityProvider` API를 사용하여 용량 공급자의 특정 속성을 업데이트할 수 있습니다. ``` aws lambda update-capacity-provider \ --capacity-provider-name my-capacity-provider \ --capacity-provider-scaling-config ScalingMode=Auto ``` ### 용량 공급자 삭제 `DeleteCapacityProvider` API를 사용하여 더 이상 필요하지 않은 용량 공급자를 삭제할 수 있습니다. ``` aws lambda delete-capacity-provider \ --capacity-provider-name my-capacity-provider ``` **참고:** 함수 버전이 연결된 용량 공급자는 삭제할 수 없습니다. ### 용량 공급자 세부 정보 보기 `GetCapacityProvider` API를 사용하여 용량 공급자 관련 정보를 검색합니다. ``` aws lambda get-capacity-provider \ --capacity-provider-name my-capacity-provider ``` ## 용량 공급자 상태 용량 공급자는 다음 상태 중 하나일 수 있습니다. + **보류 중**: 용량 공급자 생성 중 + **활성**: 용량 공급자 사용 준비 완료 + **실패**: 용량 공급자 생성 실패 + **삭제 중**: 용량 공급자 삭제 중 ## 할당량 + **계정당 최대 용량 공급자**: 1,000 + **용량 공급자당 최대 함수 버전**: 100(증가할 수 없음) ## 모범 사례 1. **신뢰 수준에 따른 구분**: 보안 요구 사항이 서로 다른 워크로드에 대해 서로 다른 용량 공급자 생성 1. **설명이 포함된 이름 사용**: 용량 공급자의 이름을 지정하여 용도와 신뢰 수준을 명확하게 표시(예: `production-trusted`, `dev-sandbox`) 1. **여러 가용 영역 사용:** 고가용성을 위해 여러 AZ에 걸쳐 서브넷 지정 1. **Lambda가 인스턴스 유형을 선택하도록 허용**: 별도의 하드웨어 요구 사항이 없는 한 Lambda가 가용성을 위해 최적의 인스턴스 유형을 선택하도록 허용 1. **사용량 모니터링**: AWS CloudTrail을 사용하여 용량 공급자 할당 및 액세스 패턴 모니터링 ## 다음 단계 + [Lambda 관리형 인스턴스 규모 조정](lambda-managed-instances-scaling.md) 알아보기 + [Lambda 관리형 인스턴스의 보안 및 권한](lambda-managed-instances-security.md) 이해 + [용량 공급자에 대한 VPC 연결](lambda-managed-instances-networking.md) 구성 + [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) 및 [Python](lambda-managed-instances-python-runtime.md)에 대한 런타임별 가이드 검토 # Lambda 관리형 인스턴스 규모 조정 Lambda 관리형 인스턴스는 간접 호출이 도착할 때 규모가 조정되지 않고 콜드 스타트를 지원하지 않습니다. 대신 리소스 소비 신호를 사용하여 비동기식으로 규모를 조정합니다. 관리형 인스턴스는 현재 CPU 리소스 사용률 및 다중 동시성 포화에 따라 규모가 조정됩니다. **주요 차이점:** + **Lambda(기본값):** 수신하는 간접 호출을 처리할 수 있는 무료 실행 환경이 없는 경우 규모 조정(콜드 스타트) + **Lambda 관리형 인스턴스:** 실행 환경의 CPU 리소스 사용률 및 다중 동시성 포화를 기반으로 비동기식으로 규모 조정 5분 이내에 트래픽이 2배를 초과하는 경우 Lambda가 수요에 맞춰 인스턴스 및 실행 환경을 스케일 업함에 따라 스로틀링이 발생할 수 있습니다. ## 조정 수명 주기 Lambda 관리형 인스턴스는 분산 아키텍처를 사용하여 규모 조정을 관리합니다. **구성 요소:** + **관리형 인스턴스** - 제공한 서브넷의 계정에서 실행 + **라우터 및 스케일러** - 간접 호출을 라우팅하고 조정을 관리하는 공유 Lambda 구성 요소 + **Lambda 에이전트** - 각 관리형 인스턴스에서 실행되어 실행 환경 수명 주기를 관리하고 리소스 소비량을 모니터링 **작동 방식:** 1. 용량 공급자와 함께 함수 버전을 게시하면 Lambda는 계정에서 관리형 인스턴스를 시작합니다. 기본적으로 AZ 복원력을 위해 인스턴스 3개를 시작하고 실행 환경 3개를 시작한 다음 함수 버전을 ACTIVE로 표시합니다. 1. 각 관리형 인스턴스는 동일한 용량 공급자에 매핑된 여러 개의 함수에 대한 실행 환경을 실행할 수 있습니다. 1. 트래픽이 애플리케이션으로 유입되면 실행 환경에서 리소스를 소비합니다. Lambda 에이전트는 새 실행 환경 또는 관리형 인스턴스의 규모 조정 여부를 결정하는 스케일러에 알림을 보냅니다. 1. 라우터가 리소스 사용량이 많은 실행 환경에 간접 호출을 보내려고 하면 해당 인스턴스의 Lambda 에이전트가 다른 인스턴스에서 다시 시도하도록 알림을 보냅니다. 1. 트래픽이 감소하면 Lambda 에이전트는 스케일러에 알림을 보내고, 스케일러는 실행 환경과 관리형 인스턴스를 스케일 다운하기로 결정합니다. ## 규모 조정 동작 수정 다음 4가지 제어를 통해 관리형 인스턴스의 규모 조정 동작을 사용자 지정할 수 있습니다. ### 함수 수준 제어 #### 1. 함수 메모리 및 vCPU 함수의 메모리 크기와 vCPU 할당을 선택합니다. 지원되는 가장 작은 함수 크기는 2GB 및 1개의 vCPU입니다. **고려 사항:** + 함수의 다중 동시 실행을 지원하는 메모리 및 vCPU 설정을 선택합니다. + 관리형 인스턴스에서 실행되는 함수가 다중 동시 워크로드를 지원해야 하기에 vCPU가 1개 미만인 함수는 구성할 수 없습니다. + 비율이 가장 낮은 c 인스턴스의 vCPU에 대한 2:1 메모리 비율과 일치하므로 2GB 미만을 선택할 수 없습니다. + Python 애플리케이션의 경우 Python이 다중 동시성을 처리하는 방식으로 인해 vCPU에 대한 메모리 비율을 4:1 또는 8:1로 더 높게 선택해야 할 수 있습니다. + CPU 집약적 작업을 실행하거나 IO를 거의 수행하지 않는 경우 vCPU를 2개 이상으로 선택해야 합니다. #### 2. 최대 동시성 실행 환경당 최대 동시성을 설정합니다. **기본 동작:** Lambda는 다양한 애플리케이션에서 작동하는 리소스 소비량과 처리량의 균형을 맞추는 합리적인 기본값을 선택합니다. **조정 지침:** + **동시성 증가:** 함수 간접 호출에서 CPU를 거의 사용하지 않는 경우 최대 동시성을 vCPU당 최대 64까지 늘릴 수 있습니다. + **동시성 감소:** 애플리케이션에서 대량의 메모리와 매우 적은 CPU를 사용하는 경우 최대 동시성을 줄일 수 있습니다. **중요:** Lambda 관리형 인스턴스는 다중 동시 애플리케이션에 사용하므로 동시성이 매우 낮은 실행 환경에서는 규모 조정 시 스로틀링이 발생할 수 있습니다. ### 용량 공급자 수준 제어 #### 3. 리소스 사용률 목표 CPU 사용률 소비 목표를 선택합니다. **기본 동작:** Lambda는 트래픽이 스로틀링 없이 5분 이내에 2배가 될 수 있도록 충분한 여유 공간을 유지합니다. **최적화 옵션:** + 워크로드가 매우 안정적이거나 애플리케이션이 스로틀링에 민감하지 않은 경우 목표를 높은 수준으로 설정하여 사용률을 높이고 비용을 절감할 수 있습니다. + 트래픽 급증에 대한 여유 공간을 유지하려면 더 많은 용량이 필요하도록 리소스 목표를 낮게 설정할 수 있습니다. #### 4. 인스턴스 유형 선택 허용 또는 제외된 인스턴스 유형을 설정합니다. **기본 동작:** Lambda는 워크로드에 가장 적합한 인스턴스 유형을 선택합니다. 가능한 인스턴스 유형 수를 제한하면 가용성이 낮아질 수 있으므로 Lambda 관리형 인스턴스가 인스턴스 유형을 자동으로 선택하도록 하는 것이 좋습니다. **사용자 지정 구성:** + **특정 하드웨어 요구 사항:** 허용되는 인스턴스 유형을 호환되는 인스턴스 목록으로 설정합니다. 예를 들어 애플리케이션에서 높은 네트워크 대역폭이 필요한 경우 여러 인스턴스 유형을 선택할 수 있습니다. + **비용 최적화:** 테스트 또는 개발 환경의 경우 m7a.large 인스턴스 유형과 같은 더 작은 인스턴스 유형을 선택할 수 있습니다. ## 다음 단계 + [Lambda 관리형 인스턴스의 용량 공급자](lambda-managed-instances-capacity-providers.md) 알아보기 + 런타임별 다중 동시성 처리 가이드 검토 + [용량 공급자에 대한 VPC 연결](lambda-managed-instances-networking.md) 구성 + 규모 조정 지표를 모니터링하여 규모 조정 동작 최적화 # 보안 및 권한 Lambda 관리형 인스턴스는 **신뢰 경계로 용량 공급자**를 사용합니다. 함수는 이러한 인스턴스 내의 컨테이너에서 실행되지만 컨테이너는 워크로드 간 보안 격리를 제공하지 않습니다. 동일한 용량 공급자에 할당된 모든 함수는 상호 신뢰해야 합니다. ## 주요 보안 개념 + **용량 공급자**: Lambda 함수의 신뢰 수준을 정의하는 보안 경계 + **컨테이너 격리**: 컨테이너는 보안 경계가 아니며, 신뢰할 수 없는 워크로드 간의 보안을 컨테이너에 의존해서는 안 됨 + **신뢰 분리**: 서로 다른 용량 공급자를 사용하여 상호 신뢰할 수 없는 워크로드 분리 ## 필수 권한 ### PassCapacityProvider 작업 사용자에게 용량 공급자에 함수를 할당할 수 있는 `lambda:PassCapacityProvider` 권한이 필요합니다. 이 권한은 보안 게이트 역할을 하고, 권한이 부여된 사용자만 특정 용량 공급자에 함수를 배치할 수 있습니다. 계정 관리자는 어떤 함수가 `lambda:PassCapacityProvider` IAM 작업을 통해 특정 용량 공급자를 사용할 수 있는지를 제어합니다. 이 작업이 필요한 경우는 다음과 같습니다. + Lambda 관리형 인스턴스를 사용하는 함수 생성 + 용량 공급자를 사용하도록 함수 구성 업데이트 + 코드형 인프라를 통해 함수 배포 **IAM 정책 예제** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "lambda:PassCapacityProvider", "Resource": "arn:aws:lambda:*:*:capacity-provider:trusted-workloads-*" } ] } ``` ### 서비스 연결 역할 AWS Lambda는 `AWSServiceRoleForLambda` 서비스 연결 역할을 사용하여 용량 공급자의 Lambda 관리형 인스턴스 EC2 리소스를 관리합니다. ## 모범 사례 1. **신뢰 수준에 따른 구분**: 보안 요구 사항이 서로 다른 워크로드에 대해 서로 다른 용량 공급자 생성 1. **설명이 포함된 이름 사용**: 용량 공급자의 이름을 지정하여 용도와 신뢰 수준을 명확하게 표시(예: `production-trusted`, `dev-sandbox`) 1. **최소 권한 적용**: 필요한 용량 공급자에 대해서만 `PassCapacityProvider` 권한 부여 1. **사용량 모니터링**: AWS CloudTrail을 사용하여 용량 공급자 할당 및 액세스 패턴 모니터링 ## 다음 단계 + [Lambda 관리형 인스턴스의 용량 공급자](lambda-managed-instances-capacity-providers.md) 알아보기 + [Lambda 관리형 인스턴스의 규모 조정](lambda-managed-instances-scaling.md) 알아보기 + [용량 공급자에 대한 VPC 연결](lambda-managed-instances-networking.md) 구성 + [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) 및 [Python](lambda-managed-instances-python-runtime.md)에 대한 런타임별 가이드 검토 # Lambda 관리형 인스턴스의 Lambda 운영자 역할 Lambda 관리형 인스턴스를 사용할 때 Lambda에는 계정의 컴퓨팅 용량을 관리할 권한이 필요합니다. 운영자 역할은 Lambda가 용량 공급자의 EC2 인스턴스를 관리할 수 있도록 허용하는 IAM 정책을 통해 권한을 제공합니다. Lambda는 함수가 실행될 때 Lambda가 실행 역할을 수임하는 방식과 마찬가지로 이러한 관리 작업을 수행할 때 운영자 역할을 수임합니다. ## 운영자 역할 생성 IAM 콘솔 또는 AWS CLI를 사용하여 운영자 역할을 생성할 수 있습니다. 역할에 포함되어야 하는 사항: + **권한 정책** - 용량 공급자 및 관련 리소스를 관리할 수 있는 권한 부여 + **신뢰 정책** - Lambda 서비스(`lambda.amazonaws.com`)의 역할 수임 허용 ### 권한 정책 운영자 역할에는 용량 공급자와 기본 컴퓨팅 리소스를 관리할 수 있는 권한이 필요합니다. 역할에는 최소한 [AWSLambdaManagedEC2ResourceOperator](https://us-east-1.console.aws.amazon.com/iam/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAWSLambdaManagedEC2ResourceOperator) 관리형 정책의 권한이 필요합니다. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:CreateTags", "ec2:AttachNetworkInterface" ], "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ec2:*:*:network-interface/*", "arn:aws:ec2:*:*:volume/*" ], "Condition": { "StringEquals": { "ec2:ManagedResourceOperator": "scaler.lambda.amazonaws.com" } } }, { "Effect": "Allow", "Action": [ "ec2:DescribeAvailabilityZones", "ec2:DescribeCapacityReservations", "ec2:DescribeInstances", "ec2:DescribeInstanceStatus", "ec2:DescribeInstanceTypeOfferings", "ec2:DescribeInstanceTypes", "ec2:DescribeSecurityGroups", "ec2:DescribeSubnets" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:CreateNetworkInterface" ], "Resource": [ "arn:aws:ec2:*:*:subnet/*", "arn:aws:ec2:*:*:security-group/*" ] }, { "Effect": "Allow", "Action": [ "ec2:RunInstances" ], "Resource": [ "arn:aws:ec2:*:*:image/*" ], "Condition": { "StringEquals": { "ec2:Owner": "amazon" } } } ] } ``` ### 신뢰 정책 신뢰 정책을 통해 Lambda는 운영자 역할을 수임할 수 있습니다. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ## Lambda 관리형 인스턴스의 서비스 연결 역할 Lambda 관리형 인스턴스의 수명 주기를 책임감 있는 방식으로 관리하려면 Lambda에서 계정의 관리형 인스턴스를 종료할 수 있는 지속적 액세스 권한이 필요합니다. Lambda는 AWS Identity and Access Management(IAM) 서비스 연결 역할(SLR)을 사용하여 이러한 작업을 수행합니다. **자동 생성**: 서비스 연결 역할은 용량 공급자를 처음 생성할 때 자동으로 생성됩니다. 첫 번째 용량 공급자를 생성하는 사용자에게 `lambda.amazonaws.com` 보안 주체에 대한 `iam:CreateServiceLinkedRole` 권한이 있어야 합니다. **권한**: 서비스 연결 역할은 Lambda에 다음과 같은 관리형 인스턴스 권한을 부여합니다. + `ec2:TerminateInstances` - 수명 주기 종료 시 인스턴스 종료 + `ec2:DescribeInstances` - 관리형 인스턴스 열거 **삭제**: 계정의 모든 Lambda 관리형 인스턴스 용량 공급자를 삭제한 후에만 이 서비스 연결 역할을 삭제할 수 있습니다. 서비스 연결 역할에 대한 자세한 내용은 [Lambda의 서비스 연결 역할 사용](using-service-linked-roles.md)를 참조하세요. # Lambda 관리형 인스턴스 실행 환경 이해 Lambda 관리형 인스턴스는 Lambda가 운영 측면을 관리하는 동안 고객 소유 Amazon EC2 인스턴스에서 함수 코드를 실행하는 대체 배포 모델을 제공합니다. 관리형 인스턴스의 실행 환경에는 Lambda(기본값) 함수와 몇 가지 중요한 차이점이 있는데, 특히 동시 간접 호출을 처리하고 컨테이너 수명 주기를 관리하는 방법이 다릅니다. **참고:** Lambda(기본값) 실행 환경에 대한 자세한 내용은 ‘Lambda 실행 환경 수명 주기 이해’를 참조하세요. ## 실행 환경 수명 주기 Lambda 관리형 인스턴스 함수 실행 환경의 수명 주기는 다음과 같은 몇 가지 주요 측면에 있어 Lambda(기본값)와 다릅니다. ### 초기화 단계 초기화 단계에서 Lambda는 다음 단계를 수행합니다. + 모든 확장 초기화 및 등록 + 런타임 진입점 부트스트랩. 런타임은 구성된 런타임 작업자 수 생성(구현은 런타임에 따라 다름) + 함수 초기화 코드 실행(핸들러 외부의 코드) + `/runtime/invocation/next` 직접 호출을 통해 하나 이상의 런타임 작업자가 준비 신호를 보낼 때까지 대기 확장이 초기화되고 하나 이상의 런타임 작업자가 `/runtime/invocation/next`를 직접 호출하면 초기화 단계가 완료된 것으로 간주됩니다. 이후 함수가 간접 호출을 처리할 준비가 됩니다. **참고** Lambda 관리형 인스턴스 함수의 경우 초기화에 최대 15분이 걸릴 수 있습니다. 제한 시간은 130초 또는 구성된 함수 제한 시간(최대 900초) 중 더 높은 값입니다. ### 간접 호출 단계 Lambda 관리형 인스턴스 함수의 간접 호출 단계에는 다음과 같은 몇 가지 고유한 특성이 있습니다. **연속 작업.** Lambda(기본값)와 달리 실행 환경은 지속적으로 활성 상태로 유지되어 간접 호출 간 고정 없이 도착하는 간접 호출을 처리합니다. **병렬 처리.** 동일한 실행 환경 내에서 여러 간접 호출을 동시에 실행할 수 있으며, 각각 다른 런타임 작업자가 처리합니다. **독립적 제한 시간.** 함수의 구성된 제한 시간은 각 개별 간접 호출에 적용됩니다. 간접 호출 제한 시간이 초과되면 Lambda는 해당 특정 간접 호출을 실패로 표시하지만 실행 중인 다른 간접 호출을 중단하거나 실행 환경을 종료하지 않습니다. **역압 처리.** 모든 런타임 작업자가 간접 호출을 처리 중이면 작업자를 사용할 수 있을 때까지 새 간접 호출 요청이 거부됩니다. ## 오류 처리 및 복구 Lambda 관리형 인스턴스 함수 실행 환경에서의 오류 처리는 Lambda(기본값)와 다릅니다. **간접 호출 제한 시간.** 개별 간접 호출의 제한 시간이 초과되면 Lambda는 해당 간접 호출에 대한 제한 시간 초과 오류를 반환합니다. 그러나 Lambda 관리형 인스턴스는 제한 시간 초과를 적용하지 않으므로 코드가 계속 실행됩니다. 함수 개발자가 제한 시간 초과를 감지하고 처리할 책임이 있습니다. 컨텍스트 객체는 간접 호출의 남은 시간을 표시하며, 0 또는 음수 값은 제한 시간 초과를 나타냅니다. 실행 환경 내의 다른 동시 간접 호출은 정상적으로 계속 처리됩니다. **런타임 작업자 실패.** 런타임 작업자 프로세스가 충돌하는 경우 실행 환경에서는 남은 정상 작업자를 계속 운영합니다. **확장 충돌.** 초기화 또는 운영 중에 확장 프로세스가 충돌하면 전체 실행 환경이 비정상으로 표시되고 종료됩니다. Lambda는 새 실행 환경을 생성하여 이를 대체합니다. **재설정/복구 불가.** Lambda(기본값)와 달리 관리형 인스턴스는 오류 후 실행 환경을 재설정하고 다시 초기화하려고 시도하지 않습니다. 대신 비정상 컨테이너가 종료되고 새 컨테이너로 대체됩니다. # Lambda 관리형 인스턴스의 \$1LATEST.PUBLISHED 버전 Lambda 관리형 인스턴스 함수는 Lambda(기본값)와 동일하게 번호가 지정된 버전 관리 워크플로를 지원합니다. 번호가 지정된 버전을 유지하지 않으려는 경우 Lambda 관리형 인스턴스에 `$LATEST.PUBLISHED`라는 새 버전 유형이 도입됩니다. 이 버전을 사용하면 번호가 지정된 버전을 관리하지 않고도 업데이트된 코드 또는 구성으로 필요한 경우 최신 게시 버전을 생성하거나 다시 게시할 수 있습니다. **\$1LATEST와의 주요 차이점:** 정규화되지 않은 ARN을 사용하여 Lambda 관리형 인스턴스 함수를 호출하면 Lambda는 게시되지 않은 \$1LATEST 버전이 아닌 `$LATEST.PUBLISHED` 버전을 암시적으로 간접 호출합니다. 다음 AWS CLI 명령은 `$LATEST.PUBLISHED` 버전을 생성하거나 다시 게시합니다. ``` aws lambda publish-version --function-name my-function --publish-to LATEST_PUBLISHED ``` 다음 결과가 표시됩니다. ``` { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function:$LATEST.PUBLISHED", "Version": "$LATEST.PUBLISHED", "Role": "arn:aws:iam::123456789012:role/lambda-role", "Handler": "function.handler", "Runtime": "nodejs24.x", ... } ``` **참고** AWS CloudFormation 또는 Lambda 콘솔을 사용하여 Lambda 관리형 인스턴스 함수를 생성하면 Lambda에서 자동으로 `$LATEST.PUBLISHED` 버전을 생성합니다. # Lambda 관리형 인스턴스 런타임 Lambda는 Lambda 관리형 인스턴스를 사용할 때 요청을 다르게 처리합니다. Lambda 관리형 인스턴스는 각 실행 환경에서 요청을 순차적으로 처리하는 대신 각 실행 환경 내에서 여러 요청을 동시에 처리합니다. 실행 모델의 변화로 Lambda 관리형 인스턴스를 사용하는 함수가 Lambda(기본값) 단일 동시성 모델에서는 발생하지 않는 스레드 안전, 상태 관리 및 컨텍스트 격리와 관련된 우려 사항을 고려해야 합니다. 추가로 다중 동시성 구현은 런타임마다 다릅니다. ## 지원되는 언어 Lambda 관리형 인스턴스는 다음과 같은 프로그래밍 언어 및 런타임과 함께 사용할 수 있습니다. + **Java:** Java 21 이상. + **Python:** Python 3.13 이상. + **Node.js:** Node.js 22 이상. + **.NET:** .NET 8 이상. + **Rust:** OS 전용 런타임 `provided.al2023` 이상 사용이 지원됩니다. ## 언어별 고려 사항 프로그래밍 언어마다 다르게 다중 동시성을 구현합니다. 적절한 동시성 모범 사례를 적용하려면 선택한 프로그래밍 언어로 다중 동시성이 구현되는 방식을 이해해야 합니다. **Java** 동시성을 위해 OS 스레드와 함께 단일 프로세스를 사용합니다. 여러 스레드가 핸들러 메서드를 동시에 실행하므로 상태 및 공유 리소스의 스레드 안전 처리가 필요합니다. **Python** 각각의 동시 요청이 별도의 프로세스에서 실행되는 여러 개의 Python 프로세스를 사용합니다. `/tmp` 디렉터리와 같은 공유 리소스에는 주의가 필요하지만 대부분의 동시성 문제를 예방합니다. **Node.js** 비동기 실행으로 [작업자 스레드](https://nodejs.org/api/worker_threads.html)를 사용합니다. 동시 요청이 작업자 스레드에 분산되고, 각 작업자 스레드는 동시 요청을 비동기식으로 처리할 수 있으므로 상태 및 공유 리소스를 안전하게 처리해야 합니다. **.NET** 여러 동시 요청의 비동기 처리와 함께 .NET 태스크를 사용합니다. 상태 및 공유 리소스의 안전한 처리가 필요합니다. **Rust** [Tokio](https://tokio.rs/)로 구동되는 비동기식 태스크와 함께 단일 프로세스를 사용합니다. 핸들러는 `Clone` \$1 `Send`여야 합니다. ## 다음 단계 각 런타임에 자세한 내용은 다음을 참조하세요. + [Lambda 관리형 인스턴스용 Java 런타임](lambda-managed-instances-java-runtime.md) + [Lambda 관리형 인스턴스용 Node.js 런타임](lambda-managed-instances-nodejs-runtime.md) + [Lambda 관리형 인스턴스용 Python 런타임](lambda-managed-instances-python-runtime.md) + [Lambda 관리형 인스턴스용 .NET 런타임](lambda-managed-instances-dotnet-runtime.md) + [Lambda 관리형 인스턴스에 대한 Rust 지원](lambda-managed-instances-rust.md) # Lambda 관리형 인스턴스용 Java 런타임 Java 런타임의 경우 Lambda 관리형 인스턴스는 동시성을 위해 OS 스레드를 사용합니다. Lambda는 초기화 중에 실행 환경별로 한 번씩 핸들러 객체를 로드한 다음 여러 개의 스레드를 생성합니다. 이러한 스레드는 병렬로 실행되고 상태 및 공유 리소스의 스레드 안전 처리가 필요합니다. 각 스레드는 동일한 핸들러 객체와 모든 정적 필드를 공유합니다. ## 동시성 구성 Lambda가 각 실행 환경에 보내는 최대 동시 요청 수는 함수 구성의 `PerExecutionEnvironmentMaxConcurrency` 설정으로 제어됩니다. 이 설정은 선택 사항이며, 기본값은 런타임에 따라 달라집니다. Java 런타임의 경우 기본값은 vCPU당 32개 동시 요청이며, 직접 값을 구성할 수도 있습니다. 또한 이 값은 Java 런타임에서 사용하는 스레드 수를 결정합니다. Lambda는 각 실행 환경의 용량에 따라 구성된 최대 수까지 동시 요청 수를 자동으로 조정하여 이러한 요청을 수용합니다. ## 다중 동시성 함수 빌드 Lambda 관리형 인스턴스를 사용할 때는 다른 다중 스레드 환경에서와 동일한 스레드 안전 관행을 적용해야 합니다. 핸들러 객체는 모든 런타임 작업자 스레드에서 공유되기에 변경 가능한 상태는 스레드 안전 상태여야 합니다. 여기에는 컬렉션, 데이터베이스 연결 및 요청 처리 도중 수정된 모든 정적 객체가 포함됩니다. AWS SDK 클라이언트는 스레드 안전 상태이기에 별도의 처리가 필요하지 않습니다. **예제: 데이터베이스 연결 풀** 다음 코드는 스레드 간에 공유되는 정적 데이터베이스 연결 객체를 사용합니다. 사용되는 연결 라이브러리에 따라 스레드가 안전하지 않을 수 있습니다. ``` public class DBQueryHandler implements RequestHandler { // Single connection shared across all threads - NOT SAFE private static Connection connection; public DBQueryHandler() { this.connection = DriverManager.getConnection(jdbcUrl, username, password); } @Override public String handleRequest(Object input, Context context) { PreparedStatement stmt = connection.prepareStatement(query); ResultSet rs = stmt.executeQuery(); // Multiple threads using same connection causes issues return result.toString(); } } ``` 스레드에 있어 안전한 방식은 연결 풀을 사용하는 것입니다. 다음 예제에서 함수 핸들러는 풀에서 연결을 검색합니다. 연결은 단일 요청의 컨텍스트에서만 사용됩니다. ``` public class DBQueryHandler implements RequestHandler { private static HikariDataSource dataSource; public DBQueryHandler() { HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://localhost:3306/your_database"); dataSource = new HikariDataSource(config); // Create pool once per Lambda container } @Override public String handleRequest(Object input, Context context) { String query = "SELECT column_name FROM your_table LIMIT 10"; StringBuilder result = new StringBuilder("Data:\n"); // try-with-resources automatically calls close() on the connection, // which returns it to the HikariCP pool (does NOT close the physical DB connection) try (Connection connection = dataSource.getConnection(); PreparedStatement stmt = connection.prepareStatement(query); ResultSet rs = stmt.executeQuery()) { while (rs.next()) { result.append(rs.getString("column_name")).append("\n"); } } catch (Exception e) { context.getLogger().log("Error: " + e.getMessage()); return "Error"; } return result.toString(); } } ``` **예제: 컬렉션** 표준 Java 컬렉션은 스레드에 있어 안전하지 않습니다. ``` public class Handler implements RequestHandler { private static List items = new ArrayList<>(); private static Map cache = new HashMap<>(); @Override public String handleRequest(Object input, Context context) { items.add("list item"); // Not thread-safe cache.put("key", input); // Not thread-safe return "Success"; } } ``` 대신 다음 스레드 안전 컬렉션을 사용합니다. ``` public class Handler implements RequestHandler { private static final List items = Collections.synchronizedList(new ArrayList<>()); private static final ConcurrentHashMap cache = new ConcurrentHashMap<>(); @Override public String handleRequest(Object input, Context context) { items.add("list item"); // Thread-safe cache.put("key", input); // Thread-safe return "Success"; } } ``` ## 공유 /tmp 디렉터리 `/tmp` 디렉터리는 실행 환경의 모든 동시 요청에서 공유됩니다. 동일한 파일에 대한 동시 쓰기로 인해 다른 프로세스가 파일을 덮어쓰는 등 데이터가 손상될 수 있습니다. 이를 해결하려면 공유 파일에 대한 파일 잠금을 구현하거나 스레드 또는 요청별로 고유한 파일 이름을 사용하여 충돌을 방지합니다. 사용 가능한 공간이 소진되지 않도록 불필요한 파일을 정리해야 합니다. ## 로깅 다중 동시 시스템에서는 로그 인터리브(로그에서 서로 다른 요청의 로그 항목이 인터리브됨)가 정상적인 동작입니다. Lambda 관리형 인스턴스를 사용하는 함수는 항상 [고급 로깅 제어](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)가 도입된 구조화된 JSON 로그 형식을 사용합니다. 이 형식에는 `requestId`가 포함되어 로그 항목을 단일 요청과 연관시킬 수 있습니다. `context.getLogger()`의 `LambdaLogger` 객체를 사용하면 `requestId`가 각 로그 항목에 자동으로 포함됩니다. 자세한 내용은 [Java에서 Lambda 고급 로깅 제어 사용](java-logging.md#java-logging-advanced) 항목을 참조하세요. ## 요청 컨텍스트 `context` 객체는 요청 스레드에 바인딩됩니다. `context.getAwsRequestId()`를 사용하면 현재 요청의 요청 ID에 대해 스레드 안전 액세스가 가능합니다. `context.getXrayTraceId()`를 사용하여 X-Ray 트레이스 ID에 액세스합니다. 이렇게 하면 현재 요청의 트레이스 ID에 대한 스레드 안전 액세스 권한이 제공됩니다. Lambda는 Lambda 관리형 인스턴스에서 `_X_AMZN_TRACE_ID` 환경 변수를 지원하지 않습니다. AWS SDK를 사용할 때 X-Ray 트레이스 ID가 자동으로 전파됩니다. `com.amazonaws.services.lambda.runtime.Context.getRemainingTimeInMillis()`를 사용하여 제한 시간 초과를 감지합니다. 자세한 정보는 [오류 처리 및 복구](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling)을 참조하세요. 프로그램에서 가상 스레드를 사용하거나 초기화 도중 스레드를 생성하는 경우 필요한 요청 컨텍스트를 스레드에 전달해야 합니다. ## 초기화 및 종료 함수 초기화는 실행 환경당 한 번 발생합니다. 초기화 도중 생성된 객체는 스레드 간에 공유됩니다. 확장이 포함된 Lambda 함수의 경우 실행 환경은 종료 중에 SIGTERM 신호를 내보냅니다. 이 신호는 확장에서 버퍼 비우기와 같은 정리 태스크를 트리거하는 데 사용됩니다. SIGTERM 이벤트를 구독하여 데이터베이스 연결 종료와 같은 함수 정리 태스크를 트리거할 수 있습니다. 실행 환경 수명 주기에 대한 자세한 내용은 [Lambda 실행 환경 수명 주기 이해](lambda-runtime-environment.md) 섹션을 참조하세요. ## 종속성 버전 Lambda 관리형 인스턴스에는 다음과 같은 최소 패키지 버전이 필요합니다. + AWS SDK for Java 2.0: 버전 2.34.0 이상 + AWS X-Ray SDK for Java: 버전 2.20.0 이상 + AWS Distro for OpenTelemetry - Instrumentation for Java: 버전 2.20.0 이상 + Powertools for AWS Lambda(Java): 버전 2.8.0 이상 ## Powertools for AWS Lambda(Java) Powertools for AWS Lambda(Java)는 Lambda 관리형 인스턴스와 호환되고 로깅, 추적, 지표 등을 위한 유틸리티를 제공합니다. 자세한 내용은 [Powertools for AWS Lambda(Java)](https://github.com/aws-powertools/powertools-lambda-java)를 참조하세요. ## 다음 단계 + [Lambda 관리형 인스턴스용 Node.js 런타임](lambda-managed-instances-nodejs-runtime.md) 검토 + [Lambda 관리형 인스턴스용 Python 런타임](lambda-managed-instances-python-runtime.md) 검토 + [Lambda 관리형 인스턴스용 .NET 런타임](lambda-managed-instances-dotnet-runtime.md) 검토 + [Lambda 관리형 인스턴스 규모 조정](lambda-managed-instances-scaling.md) 알아보기 # Lambda 관리형 인스턴스용 Node.js 런타임 Node.js 런타임의 경우 Lambda 관리형 인스턴스는 `async`/`await` 기반 실행과 함께 작업자 스레드를 사용하여 동시 요청을 처리합니다. 함수 초기화는 작업자 스레드당 한 번 발생합니다. 동시 간접 호출은 2가지 차원에서 처리됩니다. 작업자 스레드는 vCPU 간에 병렬 처리를 제공하고, 비동기 실행은 각 스레드 내에서 동시성을 제공합니다. 동일한 작업자 스레드에서 처리하는 각 동시 요청은 동일한 핸들러 객체와 전역 상태를 공유하기에 여러 동시 요청에서의 안전한 처리가 필요합니다. ## 최대 동시성 Lambda가 각 실행 환경에 보내는 최대 동시 요청 수는 함수 구성의 `PerExecutionEnvironmentMaxConcurrency` 설정으로 제어됩니다. 이 설정은 선택 사항이며, 기본값은 런타임에 따라 달라집니다. Node.js 런타임의 경우 기본값은 vCPU당 64개 동시 요청으로, 또는 자체 값을 구성할 수 있습니다. Lambda는 각 실행 환경의 용량에 따라 구성된 최대 수까지 동시 요청 수를 자동으로 조정하여 이러한 요청을 수용합니다. Node.js의 경우 각 실행 환경에서 처리할 수 있는 동시 요청 수는 작업자 스레드 수와 동시 요청을 비동기식으로 처리하는 각 작업자 스레드의 용량에 따라 결정됩니다. 기본 작업자 스레드 수는 사용 가능한 vCPU 수에 따라 결정됩니다. 또는 `AWS_LAMBDA_NODEJS_WORKER_COUNT` 환경 변수를 설정하여 작업자 스레드 수를 구성할 수 있습니다. 비동기 함수 핸들러를 사용하면 작업자 스레드당 여러 요청을 처리할 수 있어 사용이 권장됩니다. 함수 핸들러가 동기식인 경우 각 작업자 스레드는 한 번에 하나의 요청만 처리할 수 있습니다. ## 다중 동시성 함수 빌드 비동기 함수 핸들러를 사용하면 각 런타임 작업자가 여러 개의 요청을 동시에 처리합니다. 전역 객체가 여러 동시 요청에서 공유됩니다. 변경 가능한 객체의 경우 전역 상태를 사용하지 않거나 `AsyncLocalStorage`를 사용합니다. AWS SDK 클라이언트는 비동기식으로 안전하기에 별도의 처리가 필요하지 않습니다. **예제: 전역 상태** 다음 코드는 함수 핸들러 내에서 변형되는 전역 객체를 사용합니다. 비동기식에서 사용하기에 안전하지 않습니다. ``` let state = { currentUser: null, requestData: null }; export const handler = async (event, context) => { state.currentUser = event.userId; state.requestData = event.data; await processData(state.requestData); // state.currentUser might now belong to a different request return { user: state.currentUser }; }; ``` 함수 핸들러 내에서 `state` 객체를 초기화하면 전역 상태가 공유되지 않습니다. ``` export const handler = async (event, context) => { let state = { currentUser: event.userId, requestData: event.data }; await processData(state.requestData); return { user: state.currentUser }; }; ``` **예제: 데이터베이스 연결** 다음 코드는 여러 간접 호출 간에 공유되는 클라이언트 객체를 사용합니다. 사용되는 연결 라이브러리에 따라 동시성이 안전하지 않을 수 있습니다. ``` const { Client } = require('pg'); // Single connection created at init time const client = new Client({ host: process.env.DB_HOST, database: process.env.DB_NAME, user: process.env.DB_USER, password: process.env.DB_PASSWORD }); // Connect once during cold start client.connect(); exports.handler = async (event) => { // Multiple parallel invocations share this single connection = BAD // With multi-concurrent Lambda, queries will collide const result = await client.query('SELECT * FROM users WHERE id = $1', [event.userId]); return { statusCode: 200, body: JSON.stringify(result.rows[0]) }; }; ``` 동시성에 있어 안전한 방식은 연결 풀을 사용하는 것입니다. 풀은 각 동시 데이터베이스 쿼리에 별도의 연결을 사용합니다. ``` const { Pool } = require('pg'); // Connection pool created at init time const pool = new Pool({ host: process.env.DB_HOST, database: process.env.DB_NAME, user: process.env.DB_USER, password: process.env.DB_PASSWORD, max: 20, // Max connections in pool idleTimeoutMillis: 30000, connectionTimeoutMillis: 2000 }); exports.handler = async (event) => { // Pool gives each parallel invocation its own connection const result = await pool.query('SELECT * FROM users WHERE id = $1', [event.userId]); return { statusCode: 200, body: JSON.stringify(result.rows[0]) }; }; ``` ## Node.js 22 콜백 기반 핸들러 Node.js 22를 사용하는 경우 Lambda 관리형 인스턴스에서 콜백 기반 함수 핸들러를 사용할 수 없습니다. 콜백 기반 핸들러는 Lambda(기본값) 함수에서만 지원됩니다. Node.js 24 이상 런타임의 경우 Lambda(기본값) 및 Lambda 관리형 인스턴스 모두에서 콜백 기반 함수 핸들러가 더 이상 사용되지 않습니다. 대신 Lambda 관리형 인스턴스를 사용할 때는 `async` 함수 핸들러를 사용하세요. 자세한 내용은 [Node.js에서 Lambda 함수 핸들러 정의](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-handler.html)를 참조하세요. ## 공유 /tmp 디렉터리 `/tmp` 디렉터리는 실행 환경의 모든 동시 요청에서 공유됩니다. 동일한 파일에 대한 동시 쓰기로 인해 다른 프로세스가 파일을 덮어쓰는 등 데이터가 손상될 수 있습니다. 이를 해결하려면 공유 파일에 대한 파일 잠금을 구현하거나 요청당 고유한 파일 이름을 사용하여 충돌을 방지합니다. 사용 가능한 공간이 소진되지 않도록 불필요한 파일을 정리해야 합니다. ## 로깅 다중 동시 시스템에서는 로그 인터리브(로그에서 서로 다른 요청의 로그 항목이 인터리브됨)가 정상적인 동작입니다. Lambda 관리형 인스턴스를 사용하는 함수는 항상 [고급 로깅 제어](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)가 도입된 구조화된 JSON 로그 형식을 사용합니다. 이 형식에는 `requestId`가 포함되어 로그 항목을 단일 요청과 연관시킬 수 있습니다. `console` 로거를 사용하면 `requestId`가 각 로그 항목에 자동으로 포함됩니다. 자세한 내용은 [Node.js에서 Lambda 고급 로깅 제어 사용](nodejs-logging.md#node-js-logging-advanced) 항목을 참조하세요. [Winston](https://github.com/winstonjs/winston)과 같이 많이 사용되는 타사 로깅 라이브러리에는 일반적으로 로그 출력에 콘솔 사용 지원이 포함되어 있습니다. ## 요청 컨텍스트 `context.awsRequestId`를 사용하면 현재 요청의 요청 ID에 대해 비동기식 안전 액세스가 가능합니다. `context.xRayTraceId`를 사용하여 X-Ray 트레이스 ID에 액세스합니다. 이렇게 하면 현재 요청의 트레이스 ID에 대한 동시성 안전 액세스 권한이 제공됩니다. Lambda는 Lambda 관리형 인스턴스에서 `_X_AMZN_TRACE_ID` 환경 변수를 지원하지 않습니다. AWS SDK를 사용할 때 X-Ray 트레이스 ID가 자동으로 전파됩니다. `context.getRemainingTimeInMillis()`를 사용하여 제한 시간 초과를 감지합니다. 자세한 정보는 [오류 처리 및 복구](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling)을 참조하세요. ## 초기화 및 종료 함수 초기화는 작업자 스레드당 한 번 발생합니다. 함수가 초기화 도중 로그를 내보내는 경우 반복 로그 항목이 표시될 수 있습니다. 확장이 포함된 Lambda 함수의 경우 실행 환경은 종료 중에 SIGTERM 신호를 내보냅니다. 이 신호는 확장에서 버퍼 비우기와 같은 정리 태스크를 트리거하는 데 사용됩니다. 확장이 포함된 Lambda(기본값) 함수는 `process.on()`을 사용하여 SIGTERM 신호를 구독할 수도 있습니다. `process.on()`은 작업자 스레드에서 사용할 수 없으므로 Lambda 관리형 인스턴스를 사용하는 함수에서는 지원되지 않습니다. 실행 환경 수명 주기에 대한 자세한 내용은 [Lambda 실행 환경 수명 주기 이해](lambda-runtime-environment.md) 섹션을 참조하세요. ## 종속성 버전 Lambda 관리형 인스턴스에는 다음과 같은 최소 패키지 버전이 필요합니다. + AWS SDK for JavaScript v3: 버전 3.933.0 이상 + AWS X-Ray SDK for Node.js: 버전 3.12.0 이상 + AWS Distro for OpenTelemetry - Instrumentation for JavaScript: 버전 0.8.0 이상 + Powertools for AWS Lambda(TypeScript): 버전 2.29.0 이상 ## Powertools for AWS Lambda(TypeScript) Powertools for AWS Lambda(TypeScript)는 Lambda 관리형 인스턴스와 호환되고 로깅, 추적, 지표 등을 위한 유틸리티를 제공합니다. 자세한 내용은 [Powertools for AWS Lambda(TypeScript)](https://github.com/aws-powertools/powertools-lambda-typescript)를 참조하세요. ## 다음 단계 + [Lambda 관리형 인스턴스용 Java 런타임](lambda-managed-instances-java-runtime.md) 검토 + [Lambda 관리형 인스턴스용 Python 런타임](lambda-managed-instances-python-runtime.md) 검토 + [Lambda 관리형 인스턴스용 .NET 런타임](lambda-managed-instances-dotnet-runtime.md) 검토 + [Lambda 관리형 인스턴스 규모 조정](lambda-managed-instances-scaling.md) 알아보기 # Lambda 관리형 인스턴스용 Python 런타임 Lambda 런타임은 여러 개의 Python 프로세스를 사용하여 동시 요청을 처리합니다. 각 동시 요청은 자체 메모리 공간 및 초기화를 갖춘 별도의 프로세스로 실행됩니다. 각 프로세스는 한 번에 하나의 요청을 동기식으로 처리합니다. 프로세스는 메모리를 직접 공유하지 않으므로 전역 변수, 모듈 수준 캐시 및 싱글톤 객체는 동시 요청 간에 격리됩니다. ## 동시성 구성 Lambda가 각 실행 환경에 보내는 최대 동시 요청 수는 함수 구성의 `PerExecutionEnvironmentMaxConcurrency` 설정으로 제어됩니다. 이 설정은 선택 사항이며, 기본값은 런타임에 따라 달라집니다. Python 런타임의 경우 기본값은 vCPU당 16개 동시 요청으로, 또는 자체 값을 구성할 수 있습니다. 또한 이 값은 Python 런타임에서 사용하는 프로세스 수를 결정합니다. Lambda는 각 실행 환경의 용량에 따라 구성된 최대 수까지 동시 요청 수를 자동으로 조정하여 이러한 요청을 수용합니다. **중요** 프로세스 기반 동시성을 사용하면 각 런타임 작업자 프로세스에서 자체적으로 초기화를 수행합니다. 총 메모리 사용량은 프로세스당 메모리와 동시 프로세스 수를 곱한 값과 같습니다. 대용량 라이브러리 또는 데이터 세트를 로드하고 동시성이 높은 경우 메모리 공간이 커집니다. 워크로드에 따라 사용 가능한 메모리를 초과하지 않도록 CPU-메모리 비율을 조정하거나 더 낮은 동시성 설정을 사용해야 할 수 있습니다. CloudWatch의 `MemoryUtilization` 지표를 사용하여 메모리 사용량을 추적할 수 있습니다. ## 다중 동시성 함수 빌드 프로세스 기반 다중 동시성 모델로 인해 Python 런타임을 사용하는 Lambda 관리형 인스턴스 함수는 여러 간접 호출에서 동시에 메모리 내 리소스에 액세스하지 않습니다. 메모리 내 동시성 안전을 위한 코딩 방식을 적용할 필요가 없습니다. ## 공유 /tmp 디렉터리 `/tmp` 디렉터리는 실행 환경의 모든 동시 요청에서 공유됩니다. 동일한 파일에 대한 동시 쓰기로 인해 다른 프로세스가 파일을 덮어쓰는 등 데이터가 손상될 수 있습니다. 이를 해결하려면 공유 파일에 대한 파일 잠금을 구현하거나 프로세스 또는 요청별로 고유한 파일 이름을 사용하여 충돌을 방지합니다. 사용 가능한 공간이 소진되지 않도록 불필요한 파일을 정리해야 합니다. ## 로깅 다중 동시 시스템에서는 로그 인터리브(로그에서 서로 다른 요청의 로그 항목이 인터리브됨)가 정상적인 동작입니다. Lambda 관리형 인스턴스를 사용하는 함수는 항상 [고급 로깅 제어](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)가 도입된 구조화된 JSON 로그 형식을 사용합니다. 이 형식에는 `requestId`가 포함되어 로그 항목을 단일 요청과 연관시킬 수 있습니다. Lambda의 Python 표준 라이브러리에서 `logging` 모듈을 사용하면 `requestId`가 각 로그 항목에 자동으로 포함됩니다. 자세한 내용은 [Python에서 Lambda 고급 로깅 제어 사용](https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html#python-logging-advanced)을 참조하세요. ## 요청 컨텍스트 `context.aws_request_id`를 사용하면 현재 요청의 요청 ID에 액세스할 수 있습니다. Python 런타임을 사용하는 경우 `_X_AMZN_TRACE_ID` 환경 변수를 사용하여 Lambda 관리형 인스턴스에서 X-Ray 트레이스 ID에 액세스할 수 있습니다. AWS SDK를 사용할 때 X-Ray 트레이스 ID가 자동으로 전파됩니다. `context.get_remaining_time_in_millis()`를 사용하여 제한 시간 초과를 감지합니다. 자세한 정보는 [오류 처리 및 복구](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling)을 참조하세요. ## 초기화 및 종료 함수 초기화는 프로세스당 한 번 발생합니다. 함수가 초기화 도중 로그를 내보내는 경우 반복 로그 항목이 표시될 수 있습니다. 확장이 포함된 Lambda 함수의 경우 실행 환경은 종료 중에 SIGTERM 신호를 내보냅니다. 이 신호는 확장에서 버퍼 비우기와 같은 정리 태스크를 트리거하는 데 사용됩니다. SIGTERM 이벤트를 구독하여 데이터베이스 연결 종료와 같은 함수 정리 태스크를 트리거할 수 있습니다. 실행 환경 수명 주기에 대한 자세한 내용은 [Lambda 실행 환경 수명 주기 이해](lambda-runtime-environment.md) 섹션을 참조하세요. ## 종속성 버전 Lambda 관리형 인스턴스에는 다음과 같은 최소 패키지 버전이 필요합니다. + Powertools for AWS Lambda(Python): 버전 3.23.0 이상 ## Powertools for AWS Lambda(Python) Powertools for AWS Lambda(Python)는 Lambda 관리형 인스턴스와 호환되고 로깅, 추적, 지표 등을 위한 유틸리티를 제공합니다. 자세한 내용은 [Powertools for AWS Lambda(Python)](https://github.com/aws-powertools/powertools-lambda-python)를 참조하세요. ## 다음 단계 + [Lambda 관리형 인스턴스용 Java 런타임](lambda-managed-instances-java-runtime.md) 검토 + [Lambda 관리형 인스턴스용 Node.js 런타임](lambda-managed-instances-nodejs-runtime.md) 검토 + [Lambda 관리형 인스턴스용 .NET 런타임](lambda-managed-instances-dotnet-runtime.md) 검토 + [Lambda 관리형 인스턴스 규모 조정](lambda-managed-instances-scaling.md) 알아보기 # Lambda 관리형 인스턴스용 .NET 런타임 .NET 런타임의 경우 Lambda 관리형 인스턴스는 실행 환경당 단일 .NET 프로세스를 사용합니다. 여러 동시 요청은 .NET 태스크를 사용하여 처리됩니다. ## 동시성 구성 Lambda가 각 실행 환경에 보내는 최대 동시 요청 수는 함수 구성의 `PerExecutionEnvironmentMaxConcurrency` 설정으로 제어됩니다. 이 설정은 선택 사항이며, 기본값은 런타임에 따라 달라집니다. .NET 런타임의 경우 기본값은 vCPU당 32개 동시 요청으로, 또는 자체 값을 구성할 수 있습니다. Lambda는 각 실행 환경의 용량에 따라 구성된 최대 수까지 동시 요청 수를 자동으로 조정하여 이러한 요청을 수용합니다. ## 다중 동시성 함수 빌드 Lambda 관리형 인스턴스를 사용할 때는 다른 다중 동시성 환경에서와 동일한 동시성 안전 관행을 적용해야 합니다. 핸들러 객체는 모든 태스크에서 공유되므로 변경 가능한 상태는 스레드 안전 상태여야 합니다. 여기에는 컬렉션, 데이터베이스 연결 및 요청 처리 도중 수정된 모든 정적 객체가 포함됩니다. AWS SDK 클라이언트는 스레드 안전 상태이기에 별도의 처리가 필요하지 않습니다. **예제: 데이터베이스 연결 풀** 다음 코드는 동시 요청 간에 공유되는 정적 데이터베이스 연결 객체를 사용합니다. `SqlConnection` 객체는 스레드 안전 상태가 아닙니다. ``` public class DBQueryHandler { // Single connection shared across threads - NOT SAFE private SqlConnection connection; public DBQueryHandler() { connection = new SqlConnection("your-connection-string-here"); connection.Open(); } public string Handle(object input, ILambdaContext context) { using var cmd = connection.CreateCommand(); cmd.CommandText = "SELECT ..."; // your query using var reader = cmd.ExecuteReader(); ... } } ``` 이를 해결하려면 연결 풀에서 가져온 각 요청에 대해 별도의 연결을 사용합니다. `Microsoft.Data.SqlClient`와 같은 ADO.NET 공급자는 연결 객체가 열릴 때 연결 풀링을 자동으로 지원합니다. ``` public class DBQueryHandler { public DBQueryHandler() { } public string Handle(object input, ILambdaContext context) { using var connection = new SqlConnection("your-connection-string-here"); connection.Open(); using var cmd = connection.CreateCommand(); cmd.CommandText = "SELECT ..."; // your query using var reader = cmd.ExecuteReader(); ... } } ``` **예제: 컬렉션** 표준 .NET 컬렉션은 스레드에 있어 안전하지 않습니다. ``` public class Handler { private static List items = new List(); private static Dictionary cache = new Dictionary(); public string FunctionHandler(object input, ILambdaContext context) { items.Add(context.AwsRequestId); cache["key"] = input; return "Success"; } } ``` 동시성 안전을 위해 `System.Collections.Concurrent` 네임스페이스의 컬렉션을 사용합니다. ``` public class Handler { private static ConcurrentBag items = new ConcurrentBag(); private static ConcurrentDictionary cache = new ConcurrentDictionary(); public string FunctionHandler(object input, ILambdaContext context) { items.Add(context.AwsRequestId); cache["key"] = input; return "Success"; } } ``` ## 공유 /tmp 디렉터리 `/tmp` 디렉터리는 실행 환경의 모든 동시 요청에서 공유됩니다. 동일한 파일에 대한 동시 쓰기로 인해 다른 요청이 파일을 덮어쓰는 등 데이터가 손상될 수 있습니다. 이를 해결하려면 공유 파일에 대한 파일 잠금을 구현하거나 요청당 고유한 파일 이름을 사용하여 충돌을 방지합니다. 사용 가능한 공간이 소진되지 않도록 불필요한 파일을 정리해야 합니다. ## 로깅 다중 동시 시스템에서는 로그 인터리브(로그에서 서로 다른 요청의 로그 항목이 인터리브됨)가 정상적인 동작입니다. Lambda 관리형 인스턴스를 사용하는 함수는 항상 [고급 로깅 제어](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)가 도입된 구조화된 JSON 로그 형식을 사용합니다. 이 형식에는 `requestId`가 포함되어 로그 항목을 단일 요청과 연관시킬 수 있습니다. `context.Logger` 객체를 사용하여 로그를 생성하면 `requestId`가 각 로그 항목에 자동으로 포함됩니다. 자세한 내용은 [.NET에서 Lambda 고급 로깅 제어 사용](csharp-logging.md#csharp-logging-advanced) 항목을 참조하세요. ## 요청 컨텍스트 `context.AwsRequestId` 속성을 사용하면 현재 요청의 요청 ID에 액세스할 수 있습니다. `context.TraceId` 속성을 사용하면 X-Ray 트레이스 ID에 액세스할 수 있습니다. 이렇게 하면 현재 요청의 트레이스 ID에 대한 동시성 안전 액세스 권한이 제공됩니다. Lambda는 Lambda 관리형 인스턴스에서 `_X_AMZN_TRACE_ID` 환경 변수를 지원하지 않습니다. AWS SDK를 사용할 때 X-Ray 트레이스 ID가 자동으로 전파됩니다. `ILambdaContext.RemainingTime`을 사용하여 제한 시간 초과를 감지합니다. 자세한 정보는 [오류 처리 및 복구](lambda-managed-instances-execution-environment.md#lambda-managed-instances-error-handling)을 참조하세요. ## 초기화 및 종료 함수 초기화는 실행 환경당 한 번 발생합니다. 초기화 도중 생성된 객체는 요청 간에 공유됩니다. 확장이 포함된 Lambda 함수의 경우 실행 환경은 종료 중에 SIGTERM 신호를 내보냅니다. 이 신호는 확장에서 버퍼 비우기와 같은 정리 태스크를 트리거하는 데 사용됩니다. SIGTERM 이벤트를 구독하여 데이터베이스 연결 종료와 같은 함수 정리 태스크를 트리거할 수 있습니다. 실행 환경 수명 주기에 대한 자세한 내용은 [Lambda 실행 환경 수명 주기 이해](lambda-runtime-environment.md) 섹션을 참조하세요. ## 종속성 버전 Lambda 관리형 인스턴스에는 다음과 같은 최소 패키지 버전이 필요합니다. + Amazon.Lambda.Core: 버전 2.7.1 이상 + Amazon.Lambda.RuntimeSupport: 버전 1.14.1 이상 + OpenTelemetry.Instrumentation.AWSLambda: 버전 1.14.0 이상 + AWSXRayRecorder.Core: 버전 2.16.0 이상 + AWSSDK.Core: 버전 4.0.0.32 이상 ## Powertools for AWS Lambda(.NET) [Powertools for AWS Lambda(.NET)](https://docs.aws.amazon.com/powertools/dotnet/) 및 [AWS Distro for OpenTelemetry - Instrumentation for DotNet](https://github.com/aws-observability/aws-otel-dotnet-instrumentation)은 현재 Lambda 관리형 인스턴스를 지원하지 않습니다. ## 다음 단계 + [Lambda 관리형 인스턴스용 Java 런타임](lambda-managed-instances-java-runtime.md) 검토 + [Lambda 관리형 인스턴스용 Node.js 런타임](lambda-managed-instances-nodejs-runtime.md) 검토 + [Lambda 관리형 인스턴스용 Python 런타임](lambda-managed-instances-python-runtime.md) 검토 + [Lambda 관리형 인스턴스 규모 조정](lambda-managed-instances-scaling.md) 알아보기 # Lambda 관리형 인스턴스에 대한 Rust 지원 ## 동시성 구성 Lambda가 각 실행 환경에 보내는 최대 동시 요청 수는 함수 구성의 `PerExecutionEnvironmentMaxConcurrency` 설정으로 제어됩니다. 이 설정은 선택 사항이며, Rust의 기본값은 vCPU당 동시 요청 8개이고, 자체 값을 구성할 수 있습니다. 이 값은 런타임에서 생성된 Tokio 태스크 수를 결정하며 실행 환경의 수명 동안 변하지 않습니다. 각 작업자는 작업자당 멀티플렉싱 없이 한 번에 정확히 하나의 진행 중인 요청을 처리합니다. Lambda는 각 실행 환경의 용량에 따라 구성된 최대 수까지 동시 요청 수를 자동으로 조정하여 이러한 요청을 수용합니다. ## 다중 동시성 함수 빌드 Lambda 관리형 인스턴스를 사용할 때는 다른 다중 스레드 환경에서와 동일한 스레드 안전 관행을 적용해야 합니다. 핸들러 객체는 모든 작업자 스레드에서 공유되므로 변경 가능한 상태는 스레드 안전 상태여야 합니다. 여기에는 컬렉션, 데이터베이스 연결 및 요청 처리 도중 수정된 모든 정적 객체가 포함됩니다. 동시 요청 처리를 활성화하려면 `Cargo.toml` 파일에 `concurrency-tokio` 특성 플래그를 추가합니다. ``` [dependencies] lambda_runtime = { version = "1", features = ["concurrency-tokio"] } ``` `lambda_runtime::run_concurrent(…)` 진입점은 Tokio 런타임 내에서 직접적으로 호출되어야 하며, 일반적으로 기본 함수의 `#[tokio::main]` 속성에서 제공됩니다. 핸들러 종료에서는 [https://doc.rust-lang.org/std/clone/trait.Clone.html](https://doc.rust-lang.org/std/clone/trait.Clone.html) \$1 [https://doc.rust-lang.org/std/marker/trait.Send.html](https://doc.rust-lang.org/std/marker/trait.Send.html)를 구현해야 합니다. 그러면 프레임워크가 여러 비동기식 태스크에서 핸들러를 안전하게 공유할 수 있습니다. 이러한 경계가 충족되지 않으면 코드가 컴파일되지 않습니다. 간접 호출(데이터베이스 풀, 구성 구조) 간에 공유된 상태가 필요하면 [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)로 래핑하고 각 간접 호출에 `Arc`를 복제합니다. 모든 AWS SDK for Rust 클라이언트는 동시성에 안전하며 특별한 처리가 필요하지 않습니다. ### 예: AWS SDK 클라이언트 다음 예제에서는 S3 클라이언트를 사용하여 간접 호출마다 객체를 업로드합니다. 클라이언트는 `Arc` 없이 종료에 직접 복제됩니다. ``` let config = aws_config::load_defaults(BehaviorVersion::latest()).await; let s3_client = aws_sdk_s3::Client::new(&config); run_concurrent(service_fn(move |event: LambdaEvent| { let s3_client = s3_client.clone(); // cheap clone, no Arc needed async move { s3_client.put_object() .bucket(&event.payload.bucket) .key(&event.payload.key) .body(event.payload.body.into_bytes().into()) .send() .await?; Ok(Response { message: "uploaded".into() }) } })) .await ``` ### 예제: 데이터베이스 연결 풀 핸들러에서 클라이언트 및 구성과 같은 공유된 상태에 액세스해야 한다면 [https://doc.rust-lang.org/std/sync/struct.Arc.html](https://doc.rust-lang.org/std/sync/struct.Arc.html)로 래핑하고 각 간접 호출에 `Arc`를 복제합니다. ``` #[derive(Debug)] struct AppState { dynamodb_client: DynamoDbClient, table_name: String, cache_ttl: Duration, } let config = aws_config::load_defaults(BehaviorVersion::latest()).await; let state = Arc::new(AppState { dynamodb_client: DynamoDbClient::new(&config), table_name: std::env::var("TABLE_NAME").expect("TABLE_NAME must be set"), cache_ttl: Duration::from_secs(300), }); run_concurrent(service_fn(move |event: LambdaEvent| { let state = state.clone(); async move { handle(event, state).await } })) .await ``` ## 공유 /tmp 디렉터리 `/tmp` 디렉터리는 동일한 실행 환경의 모든 동시 간접 호출에서 공유됩니다. 간접 호출당 고유한 파일 이름을 사용하거나(예: 요청 ID 포함) 명시적 파일 잠금을 구현하여 데이터 손상을 방지합니다. ## 로깅 다중 동시 시스템에서는 로그 인터리브(로그에서 서로 다른 요청의 로그 항목이 인터리브됨)가 정상적인 동작입니다. Lambda 관리형 인스턴스를 사용하는 함수에서는 Lambda의 [고급 로깅 제어](monitoring-logs.md#monitoring-cloudwatchlogs-advanced)를 통해 구조화된 JSON 로그 형식을 지원합니다. 이 형식에는 `requestId`가 포함되어 로그 항목을 단일 요청과 연관시킬 수 있습니다. 자세한 내용은 [Tracing 크레이트를 사용한 고급 로깅 구현](rust-logging.md#rust-logging-tracing) 항목을 참조하세요. ## 요청 컨텍스트 `Context` 객체는 각 핸들러 간접 호출에 직접 전달됩니다. `event.context.request_id`를 사용하여 현재 요청의 요청 ID에 액세스합니다. `event.context.xray_trace_id`를 사용하여 X-Ray 트레이스 ID에 액세스합니다. Lambda는 Lambda 관리형 인스턴스에서 `_X_AMZN_TRACE_ID` 환경 변수를 지원하지 않습니다. AWS SDK for Rust를 사용할 때 X-Ray 트레이스 ID가 자동으로 전파됩니다. `event.context.deadline`를 사용하여 제한 시간을 탐지합니다. 밀리초 단위의 간접 호출 기한이 있습니다. ## 초기화 및 종료 함수 초기화는 실행 환경당 한 번 발생합니다. 초기화 도중 생성된 객체는 요청 간에 공유됩니다. 확장이 포함된 Lambda 함수의 경우 실행 환경은 종료 중에 SIGTERM 신호를 내보냅니다. 이 신호는 확장에서 버퍼 비우기와 같은 정리 태스크를 트리거하는 데 사용됩니다. `lambda_runtime`에서는 정상 종료 신호 처리 구성을 단순화하는 도우미를 제공합니다([https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html](https://docs.rs/lambda_runtime/latest/lambda_runtime/fn.spawn_graceful_shutdown_handler.html)). 실행 환경 수명 주기에 대한 자세한 내용은 [Lambda 실행 환경 수명 주기 이해](lambda-runtime-environment.md) 섹션을 참조하세요. ## 종속성 버전 Lambda 관리형 인스턴스에는 다음과 같은 최소 패키지 버전이 필요합니다. + `lambda_runtime`: `concurrency-tokio` 특성이 활성화된 버전 1.1.1 이상 + 지원되는 최소 Rust 버전(MSRV)은 1.84.0입니다. # Lambda 관리형 인스턴스의 네트워킹 Lambda 관리형 인스턴스 함수를 실행할 때는 함수가 VPC 외부의 리소스에 액세스할 수 있도록 네트워크 연결을 구성해야 합니다. 여기에는 Amazon S3 및 DynamoDB와 같은 AWS 서비스가 포함됩니다. CloudWatch Logs 및 X-Ray로 텔레메트리 데이터를 전송할 때에도 연결이 필요합니다. ## 연결 옵션 VPC 연결 구성에는 3가지 주요 접근 방식이 있으며, 각 접근 방식은 비용, 보안 및 복잡성에 있어 장단점이 서로 다릅니다. ## 인터넷 게이트웨이를 사용하는 퍼블릭 서브넷 이 옵션은 인터넷 게이트웨이를 통한 직접 인터넷 액세스로 퍼블릭 서브넷을 사용합니다. IPv4 및 IPv6 구성 중에서 선택할 수 있습니다. ### 인터넷 게이트웨이를 사용하는 IPv4 **인터넷 게이트웨이와의 IPv4 연결 구성** 1. IPv4 CIDR 블록을 사용하여 기존 퍼블릭 서브넷을 생성하거나 사용합니다. 1. VPC에 인터넷 게이트웨이를 연결합니다. 1. 라우팅 테이블을 업데이트하여 `0.0.0.0/0` 트래픽을 인터넷 게이트웨이로 라우팅합니다. 1. 리소스에 퍼블릭 IPv4 주소 또는 탄력적 IP 주소가 할당되어 있어야 합니다. 1. 필요한 포트에서 아웃바운드 트래픽을 허용하도록 보안 그룹을 구성합니다. 이 구성은 양방향 연결을 제공하여 함수에서의 아웃바운드 연결과 인터넷에서의 인바운드 연결을 모두 허용합니다. ### 인터넷 게이트웨이를 사용하는 IPv6 **인터넷 게이트웨이와의 IPv6 연결 구성** 1. VPC에서 IPv6를 활성화합니다. 1. IPv6 CIDR 블록이 할당된 퍼블릭 서브넷을 생성하거나 기존 퍼블릭 서브넷을 사용합니다. 1. 인터넷 게이트웨이를 VPC에 연결합니다(동일한 인터넷 게이트웨이가 IPv4와 IPv6를 모두 처리할 수 있음). 1. 라우팅 테이블을 업데이트하여 `::/0` 트래픽을 인터넷 게이트웨이로 라우팅합니다. 1. 액세스해야 하는 AWS 서비스가 해당 리전에서 IPv6를 지원하는지 확인합니다. 1. 필요한 포트에서 아웃바운드 트래픽을 허용하도록 보안 그룹을 구성합니다. 이 구성은 IPv6 주소 지정을 사용하여 양방향 연결을 제공합니다. ### 송신 전용 인터넷 게이트웨이를 사용하는 IPv6 **송신 전용 인터넷 게이트웨이와의 IPv6 연결 구성** 1. VPC에서 IPv6를 활성화합니다. 1. IPv6 CIDR 블록이 할당된 퍼블릭 서브넷을 생성하거나 기존 퍼블릭 서브넷을 사용합니다. 1. VPC에 송신 전용 인터넷 게이트웨이를 연결합니다. 1. 라우팅 테이블을 업데이트하여 `::/0` 트래픽을 외부 전용 인터넷 게이트웨이로 라우팅합니다. 1. 액세스해야 하는 AWS 서비스가 해당 리전에서 IPv6를 지원하는지 확인합니다. 1. 필요한 포트에서 아웃바운드 트래픽을 허용하도록 보안 그룹을 구성합니다. 이 구성은 아웃바운드 전용 연결을 제공하여 함수의 아웃바운드 연결 시작을 허용하면서 인터넷에서의 인바운드 연결을 방지합니다. ## VPC 엔드포인트 VPC 엔드포인트를 통해 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결을 필요로 하지 않고 VPC를 지원되는 AWS 서비스에 비공개로 연결할 수 있습니다. VPC와 AWS 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않습니다. **VPC 엔드포인트 구성** 1. [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다. 1. 탐색 창에서 **엔드포인트**를 선택합니다. 1. **엔드포인트 생성**을 선택합니다. 1. **서비스 범주(Service category)**에서 **AWS 서비스**를 선택합니다. 1. **서비스 이름**에서 필요한 서비스 엔드포인트(예: Amazon S3의 경우 `com.amazonaws.region.s3`)를 선택합니다. 1. **VPC**에서 해당 VPC를 선택합니다. 1. **서브넷**에서 엔드포인트 네트워크 인터페이스를 생성하려는 서브넷을 선택합니다. 고가용성을 위해 여러 가용 영역의 서브넷을 선택합니다. 1. **보안 그룹**에서 엔드포인트 네트워크 인터페이스에 연결할 보안 그룹을 선택합니다. 보안 그룹은 필요한 포트에서 함수의 보안 그룹으로부터의 인바운드 트래픽을 허용해야 합니다. 1. **엔드포인트 생성**을 선택합니다. 함수가 액세스해야 하는 각 AWS 서비스에 대해 이 단계를 반복합니다. ## NAT 게이트웨이를 사용하는 프라이빗 서브넷 이 옵션은 NAT 게이트웨이를 사용하여 리소스를 비공개로 유지하면서 인터넷으로 프라이빗 서브넷의 리소스에 액세스할 수 있습니다. **NAT 게이트웨이를 사용하는 프라이빗 서브넷 구성** 1. CIDR 블록이 포함된 퍼블릭 서브넷(아직 존재하지 않는 경우)을 생성합니다. 1. VPC에 인터넷 게이트웨이를 연결합니다. 1. 퍼블릭 서브넷에 NAT 게이트웨이를 생성하고 탄력적 IP 주소를 할당합니다. 1. 퍼블릭 서브넷 라우팅 테이블을 업데이트하여 ‘`0.0.0.0/0` → 인터넷 게이트웨이’ 경로를 추가합니다. 1. CIDR 블록을 사용하여 기존 퍼블릭 서브넷을 생성하거나 사용합니다. 1. 프라이빗 서브넷 라우팅 테이블을 업데이트하여 ‘`0.0.0.0/0` → NAT 게이트웨이’를 추가합니다. 1. 필요한 포트에서 아웃바운드 트래픽을 허용하도록 보안 그룹을 구성합니다. 고가용성을 위해 각 가용 영역에 NAT 게이트웨이 하나를 배포하고 로컬 NAT 게이트웨이를 사용하도록 가용 영역별로 라우팅 테이블을 구성합니다. 이를 통해 AZ 간 데이터 전송 요금이 발생하지 않고 복원력이 향상됩니다. ## 연결 옵션 선택 연결 옵션을 선택할 때 다음 요소를 고려합니다. **인터넷 게이트웨이를 사용하는 퍼블릭 서브넷** + 최저 비용으로 가장 간단한 구성 + 개발 및 테스트 환경에 적합 + 리소스가 인터넷에서 인바운드 연결 수신 가능(보안 고려 사항) + IPv4 및 IPv6 모두 지원 ** VPC 엔드포인트** + 가장 높은 보안, 트래픽이 AWS 네트워크 내에 유지 + 인터넷 라우팅에 비해 짧은 지연 시간 + 보안 요구 사항이 엄격한 프로덕션 환경에 권장 + 처리된 엔드포인트, 가용 영역 및 GB당 비용 증가 + 고가용성을 위해 각 가용 영역에 엔드포인트 필요 **NAT 게이트웨이를 사용하는 프라이빗 서브넷** + 리소스가 인바운드 인터넷 액세스 없이 비공개로 유지 + 표준 엔터프라이즈 아키텍처 패턴 + 모든 IPv4 인터넷 트래픽 지원 + NAT 게이트웨이 시간당 및 데이터 처리 요금을 포함한 중간 비용 + IPv4만 지원 ## 다음 단계 + [Lambda 관리형 인스턴스의 용량 공급자](lambda-managed-instances-capacity-providers.md) 알아보기 + [Lambda 관리형 인스턴스의 규모 조정](lambda-managed-instances-scaling.md) 알아보기 + [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) 및 [Python](lambda-managed-instances-python-runtime.md)에 대한 런타임별 가이드 검토 + [Lambda 관리형 인스턴스의 보안 및 권한](lambda-managed-instances-security.md) 이해 # Lambda 관리형 인스턴스 모니터링 CloudWatch 지표를 사용하여 Lambda 관리형 인스턴스를 모니터링할 수 있습니다. Lambda는 CloudWatch에 지표를 자동으로 게시하므로 리소스 사용률 모니터링, 비용 추적, 성능 최적화에 도움이 됩니다. ## 사용 가능한 지표 Lambda 관리형 인스턴스는 용량 공급자 수준과 실행 환경 수준이라는 2가지 수준에서 지표를 제공합니다. ### 용량 공급자 수준 지표 용량 공급자 수준 지표를 통해 인스턴스 전반의 전체 리소스 사용률을 파악할 수 있습니다. 이러한 지표는 다음과 같은 차원을 사용합니다. + **CapacityProviderName** - 용량 공급자의 이름 + **InstanceType** - EC2 인스턴스 유형 **리소스 사용률 지표:** + **CPUUtilization** - 용량 공급자의 인스턴스 간 CPU 사용률 + **MemoryUtilization** - 용량 공급자의 인스턴스 간 메모리 사용률 **용량 지표:** + **vCPUAvailable** - 인스턴스에서 할당할 수 있는 vCPU의 양(개수) + **MemoryAvailable** - 인스턴스에서 할당할 수 있는 메모리의 양(바이트) + **vCPUAllocated** - 실행 환경의 인스턴스에 할당된 vCPU의 양(개수) + **MemoryAllocated** - 실행 환경의 인스턴스에 할당된 메모리 양(바이트) ### 실행 환경 수준 지표 실행 환경 수준 지표를 통해 개별 함수의 리소스 사용률 및 동시성을 파악할 수 있습니다. 이러한 지표는 다음과 같은 차원을 사용합니다. + **CapacityProviderName** - 용량 공급자의 이름 + **FunctionName** - Lambda 함수의 이름 + **리소스** - 리소스별로 특정 함수 버전에 대한 지표를 봅니다. **참고** LMI(Lambda 관리형 인스턴스)의 경우 `Resource` 차원에서는 함수 버전만 지원합니다. 형식은 `:`입니다. **제공되는 실행 환경 지표:** + **ExecutionEnvironmentConcurrency** - 5분 샘플 기간 동안의 최대 동시성 + **ExecutionEnvironmentConcurrencyLimit** - 실행 환경당 최대 동시성 제한 + **ExecutionEnvironmentCPUUtilization** - 함수의 실행 환경에서의 CPU 사용률 + **ExecutionEnvironmentMemoryUtilization** - 함수의 실행 환경에서의 메모리 사용률 ## 지표 빈도 및 보존 Lambda 관리형 인스턴스 지표는 5분 간격으로 게시되고 15개월 동안 보존됩니다. ## CloudWatch에서 지표 보기 **CloudWatch 콘솔에서 Lambda 관리형 인스턴스 지표 보기** 1. [console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/)에서 CloudWatch 콘솔을 엽니다. 1. 탐색 창에서 **지표(Metrics)**를 선택합니다. 1. **모든 지표** 탭에서 **AWS/Lambda**를 선택합니다. 1. 확인할 지표 차원을 선택합니다. + 용량 공급자 수준 지표의 경우 **CapacityProviderName** 및 **InstanceType**을 기준으로 필터링합니다. + 실행 환경 수준 지표의 경우 **CapacityProviderName**, **FunctionName** 및 **Resource** 기준으로 필터링 1. 모니터링할 지표를 선택합니다. ## 지표를 사용하여 성능 최적화 CPU 및 메모리 사용률을 모니터링하고 함수의 크기가 적절한지 확인합니다. 사용률이 높으면 더 큰 인스턴스 유형이 필요하거나 함수 메모리 할당을 늘려야 할 수 있습니다. 동시성 지표를 추적하여 규모 조정 동작을 이해하고 스로틀링 가능성을 식별합니다. 용량 지표를 모니터링하여 워크로드에 충분한 리소스를 사용할 수 있는지 확인합니다. **vCPUAvailable** 및 **MemoryAvailable** 지표는 인스턴스의 남은 용량을 파악하는 데 도움이 됩니다. ## 다음 단계 + [Lambda 관리형 인스턴스 규모 조정](lambda-managed-instances-scaling.md) 알아보기 + [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) 및 [Python](lambda-managed-instances-python-runtime.md)에 대한 런타임별 가이드 검토 + [용량 공급자에 대한 VPC 연결](lambda-managed-instances-networking.md) 구성 + [Lambda 관리형 인스턴스의 보안 및 권한](lambda-managed-instances-security.md) 이해 # Lambda 관리형 인스턴스 할당량 이 페이지에서는 AWS Lambda 관리형 인스턴스의 서비스 할당량을 설명합니다. 이러한 할당량은 AWS Lambda(기본값) 할당량과는 별개입니다. 일부 할당량은 요청 시 늘릴 수 있습니다. ## Lambda API 요청 할당량 이러한 할당량은 Lambda 관리형 인스턴스 용량 공급자를 관리하기 위해 API 호출 비율을 제어합니다. 읽기 및 쓰기 API 비율 제한은 용량 공급자 생성, 업데이트, 설명 및 삭제를 포함하여 결합된 모든 용량 공급자 작업에 적용됩니다. | 리소스 | 할당량 | | --- | --- | | 모든 용량 공급자 읽기 API의 최대 합산 비율(초당 요청 수) | 초당 요청 15개입니다. 늘릴 수 없습니다. | | 모든 용량 공급자 쓰기 API의 최대 합산 비율(초당 요청 수) | 1초당 1개의 요청. 늘릴 수 없습니다. | ## Lambda 관리형 인스턴스 리소스 할당량 이러한 할당량은 AWS 계정 내의 코어 Lambda 관리형 인스턴스 리소스에 대한 제한을 정의합니다. 생성할 수 있는 용량 공급자 수와 각 용량 공급자와 연결할 수 있는 함수 버전 수를 관리합니다. | 리소스 | 할당량 | | --- | --- | | 용량 공급자 | 1,000. 계정에서 생성된 최대 용량 공급자 수. | | 용량 공급자당 함수 버전 | 100. 용량 공급자당 최대 함수 버전 수. 늘릴 수 없습니다. | ## 이벤트 소스 매핑 할당량 이러한 할당량은 Lambda 관리형 인스턴스에서 다양한 AWS 서비스의 이벤트를 처리하기 위한 처리량 및 구성 제한을 제어합니다. 처리량을 제한하면 예측 가능한 성능이 보장되는 반면 매핑 수를 제한하면 서비스 안정성을 유지하는 데 도움이 됩니다. Lambda 관리형 인스턴스의 이벤트 소스 매핑은 Amazon SQS, DynamoDB Streams, Amazon Kinesis Data Streams, Amazon MSK 및 자체 관리형 Apache Kafka를 이벤트 소스로 지원합니다. | 리소스 | 할당량 | | --- | --- | | Lambda 관리형 인스턴스의 표준 SQS 이벤트 소스 매핑 처리량 | 초당 5MB. 늘릴 수 없습니다. | | Lambda 관리형 인스턴스의 표준 Kafka 이벤트 소스 매핑 처리량 | 초당 1MB. 늘릴 수 없습니다. | | Lambda 관리형 인스턴스의 표준 Kafka 이벤트 소스 매핑 | 이벤트 소스 매핑 100개 늘릴 수 없습니다. | | Lambda 관리형 인스턴스의 Kinesis 이벤트 소스 매핑 처리량 | 초당 25MB. 증가 가능. | | Lambda 관리형 인스턴스의 DynamoDB 이벤트 소스 매핑 처리량 | 초당 10MB. 증가 가능. | | Lambda 관리형 인스턴스의 비동기식 간접 호출에 대한 간접 호출 요청 처리량 | 초당 5MB. 증가 가능. | ## 할당량 증가 요청 할당량을 늘릴 수 있는 경우 Service Quotas 콘솔을 통해 증가를 요청할 수 있습니다. **할당량 증가 요청**: 1. [console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/)에서 Service Quotas 콘솔을 엽니다. 1. 탐색 창에서 **AWS 서비스**를 선택합니다. 1. **AWS Lambda**를 선택합니다. 1. 늘리려는 할당량을 선택합니다. 1. **할당량 증가 요청**을 선택합니다. 1. 새 할당량 값을 입력하고 증가하려는 이유를 입력합니다. 1. **요청**을 선택합니다. ## 다음 단계 + [Lambda 관리형 인스턴스의 용량 공급자](lambda-managed-instances-capacity-providers.md) 알아보기 + [Lambda 관리형 인스턴스의 규모 조정](lambda-managed-instances-scaling.md) 알아보기 + [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) 및 [Python](lambda-managed-instances-python-runtime.md)에 대한 런타임별 가이드 검토 + [용량 공급자에 대한 VPC 연결](lambda-managed-instances-networking.md) 구성 # Lambda 관리형 인스턴스 모범 사례 ## 용량 공급자 구성 **신뢰 수준에 따라 용량 공급자를 구분합니다.** 보안 요구 사항이 서로 다른 워크로드에 대해 서로 다른 용량 공급자를 생성합니다. 용량 공급자가 보안 경계 역할을 하므로 동일한 용량 공급자에 할당된 모든 함수는 상호 신뢰해야 합니다. **설명이 포함된 이름을 사용합니다.** 용량 공급자의 이름을 지정하여 용도와 신뢰 수준을 명확하게 표시합니다(예: `production-trusted`, `dev-sandbox`). 이를 통해 팀은 각 용량 공급자의 목적과 보안 태세를 이해할 수 있습니다. **여러 가용 영역을 사용합니다.** 용량 공급자를 생성할 때 여러 가용 영역에 걸쳐 서브넷을 지정합니다. Lambda는 AZ 복원력을 위해 기본적으로 인스턴스 3개를 시작하여 함수의 고가용성을 보장합니다. ## 인스턴스 유형 선택 **Lambda가 인스턴스 유형을 선택하도록 합니다.** 기본적으로 Lambda는 워크로드에 가장 적합한 인스턴스 유형을 선택합니다. 가능한 인스턴스 유형 수를 제한하면 가용성이 낮아질 수 있으므로 Lambda 관리형 인스턴스가 인스턴스 유형을 자동으로 선택하도록 하는 것이 좋습니다. **특정 요구 사항에 맞춰 인스턴스 유형을 지정합니다.** 특정 하드웨어 요구 사항이 있는 경우 허용된 인스턴스 유형과 호환되는 인스턴스 목록으로 설정합니다. 예제: + 높은 네트워크 대역폭이 필요한 애플리케이션의 경우 여러 개의 인스턴스 유형을 선택합니다. + 비용 관련 제약이 있는 테스트 또는 개발 환경의 경우 m7a.large와 같이 더 작은 인스턴스 유형을 선택합니다. ## 함수 구성 **적절한 메모리 및 vCPU 설정을 선택합니다.** 함수의 다중 동시 실행을 지원하는 메모리 및 vCPU 구성을 선택합니다. 지원되는 최소 함수 크기는 2GB 및 1개의 vCPU입니다. + Python 애플리케이션의 경우 Python이 다중 동시성을 처리하는 방식으로 인해 vCPU에 대한 메모리 비율을 4:1 또는 8:1 등으로 더 높게 선택해야 합니다. + IO를 거의 수행하지 않는 CPU 집약적 작업 또는 함수의 경우 vCPU를 2개 이상으로 선택합니다. + 웹 서비스 또는 배치 작업과 같이 IO가 많은 애플리케이션의 경우 다중 동시성이 가장 큰 이점을 제공합니다. **적절한 최대 동시성을 구성합니다.** Lambda는 리소스 소비량과 처리량의 균형을 맞추는 최대 동시성에 있어 합리적인 기본값을 선택합니다. 함수의 리소스 사용량에 따라 설정을 조정합니다. + 함수 간접 호출에서 CPU를 거의 사용하지 않는 경우 최대 동시성을 높입니다(vCPU당 최대 64개). + 애플리케이션이 대량의 메모리와 매우 적은 CPU를 소비하는 경우 최대 동시성을 낮춥니다. 동시성이 매우 낮은 실행 환경에서는 스로틀링이 발생하고 규모 조정이 어려울 수 있습니다. ## 조정 구성 **적절한 목표 리소스 사용률을 설정합니다.** 기본적으로 Lambda는 트래픽이 스로틀링 없이 5분 이내에 2배가 될 수 있도록 충분한 여유 공간을 유지합니다. 워크로드 특성에 따라 이 설정을 조정합니다. + 스로틀링에 민감하지 않은 매우 안정적인 워크로드 또는 애플리케이션의 경우 목표를 높은 수준으로 설정하여 사용률을 높이고 비용을 절감합니다. + 트래픽 버스트 가능성이 있는 워크로드의 경우 리소스 목표를을 낮은 수준으로 설정하여 추가 여유분을 유지합니다. **트래픽 증가를 계획합니다.** 5분 이내에 트래픽이 2배를 초과하는 경우 Lambda가 인스턴스 및 실행 환경을 확장함에 따라 스로틀링이 발생할 수 있습니다. 빠르게 확장하는 동안 잠재적 스로틀링을 처리하도록 애플리케이션을 설계합니다. ## 보안 **PassCapacityProvider 권한에 최소 권한을 적용합니다.** 필요한 용량 공급자에 대해서만 `lambda:PassCapacityProvider` 권한을 부여합니다. 리소스 수준 권한을 사용하여 사용자가 함수에 할당할 수 있는 용량 공급자를 제한합니다. **용량 공급자 사용량을 모니터링합니다.** AWS CloudTrail을 사용하여 용량 공급자 할당 및 액세스 패턴을 모니터링합니다. 이를 통해 무단 액세스 시도를 식별하고 보안 정책을 준수할 수 있습니다. **신뢰할 수 없는 워크로드를 분리합니다.** 신뢰할 수 없는 워크로드 간의 보안 격리를 컨테이너에 의존하지 않습니다. 서로 다른 용량 공급자를 사용하여 상호 신뢰할 수 없는 워크로드를 분리합니다. ## 비용 최적화 **EC2 요금 옵션을 활용합니다.** EC2 절감형 플랜 및 예약 인스턴스를 활용하여 비용을 절감합니다. 이러한 요금 옵션은 기본 EC2 컴퓨팅에 적용됩니다(15% 관리 요금은 할인되지 않음). **정상 상태 워크로드에 맞춰 최적화합니다.** Lambda 관리형 인스턴스는 예측 가능한 대용량 트래픽이 있는 정상 상태 함수에 가장 적합합니다. 트래픽 버스트가 발생하는 패턴의 경우 Lambda(기본값)의 비용 효율성이 더 높을 수 있습니다. **리소스 사용률을 모니터링합니다.** CloudWatch 지표를 추적하여 CPU 및 메모리 사용률을 파악합니다. 실제 사용량 패턴을 기반으로 함수 메모리 할당 및 인스턴스 유형 선택을 조정하여 비용을 최적화합니다. ## 모니터링 및 관찰성 **용량 공급자 지표를 모니터링합니다.** CPUUtilization, MemoryUtilization, vCPUAvailable, MemoryAvailable 등의 용량 공급자 수준 지표를 추적하여 워크로드에서 충분한 리소스를 사용할 수 있는지 확인합니다. **실행 환경 지표를 모니터링합니다.** ExecutionEnvironmentConcurrency 및 ExecutionEnvironmentConcurrencyLimit 등 실행 환경 수준 지표를 추적하여 규모 조정 동작을 이해하고 스로틀링 가능성을 식별합니다. **CloudWatch 경보를 설정합니다.** 주요 지표에 대한 CloudWatch 경보를 생성하여 문제를 사전에 식별합니다. + 높은 CPU 또는 메모리 사용률 + 낮은 가용 용량 + 동시성 제한 근접 ## 언어별 고려 사항 **언어별 모범 사례를 따릅니다.** 프로그래밍 언어마다 다르게 다중 동시성을 처리합니다. 자세한 권장 사항은 언어별 가이드 참조: + **Java**: 요청별 상태에 스레드 안전 컬렉션, `AtomicInteger` 및 `ThreadLocal` 사용 + **Node.js:** 모든 요청별 상태에 InvokeStore를 사용하고 전역 변수 사용 지양 + **Python:** `/tmp`에서 요청 ID와 함께 고유한 파일 이름을 사용하고 프로세스 기반 메모리 격리 고려 + **Rust:** `concurrency-tokio` 특성이 활성화되었으면 `run` 대신에 `run_concurrent`를 사용합니다. 핸들러는 `Clone` \$1 `Send`여야 합니다. **스레드 안전 및 동시성 문제를 테스트합니다.** 프로덕션에 배포하기 전에 함수에서 동시 로드 시 스레드 안전 문제, 경합 조건 및 적절한 상태 격리가 발생하는지 여부를 테스트합니다. ## 다음 단계 + [Lambda 관리형 인스턴스의 용량 공급자](lambda-managed-instances-capacity-providers.md) 알아보기 + [Lambda 관리형 인스턴스의 규모 조정](lambda-managed-instances-scaling.md) 알아보기 + [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) 및 [Python](lambda-managed-instances-python-runtime.md)에 대한 런타임별 가이드 검토 + [용량 공급자에 대한 VPC 연결](lambda-managed-instances-networking.md) 구성 + [CloudWatch 지표](lambda-managed-instances-monitoring.md)를 사용하여 Lambda 관리형 인스턴스 모니터링 # Lambda 관리형 인스턴스 문제 해결 ## 스로틀링 및 규모 조정 문제 ### 스케일 업 도중 높은 오류율 **문제:** 트래픽이 빠르게 증가할 때 스로틀링 오류(HTTP 429)가 발생합니다. **원인:** Lambda 관리형 인스턴스는 CPU 리소스 사용률 및 다중 동시성 포화에 따라 비동기식으로 규모가 조정됩니다. 5분 이내에 트래픽이 2배를 초과하는 경우 Lambda가 수요에 맞춰 인스턴스 및 실행 환경을 스케일 업함에 따라 스로틀링이 발생할 수 있습니다. **해결 방법:** + **목표 리소스 사용률 조정:** 워크로드에 예측 가능한 트래픽 패턴이 있는 경우 목표 리소스 사용률을 낮게 설정하여 트래픽 급증에 대한 추가 여유 공간을 유지합니다. + **용량 사전 워밍:** 계획된 트래픽 증가의 경우 속도에 맞춰 조정이 이루어지도록 더 긴 기간 동안 트래픽을 점진적으로 증가시킵니다. + **조정 지표 모니터링:** 스로틀링 오류 지표를 추적하여 스로틀링 및 용량 조정 문제의 원인을 파악합니다. + **함수 구성 검토:** 함수 메모리 및 vCPU 설정이 다중 동시 실행을 지원해야 합니다. 필요한 경우 함수 메모리 또는 vCPU 할당을 늘립니다. ### 스케일 다운 속도 저하 **문제:** 트래픽이 감소한 후 인스턴스를 축소하는 데 시간이 오래 걸립니다. **원인:** Lambda 관리형 인스턴스는 가용성을 유지하고 성능에 영향을 미칠 수 있는 급격한 용량 변경을 방지하기 위해 점진적으로 스케일 다운됩니다. **해결 방법:** 이는 예상된 동작입니다. Lambda는 안정성 보장을 위해 인스턴스를 보수적으로 스케일 다운합니다. CloudWatch 지표를 모니터링하여 실행 중인 인스턴스 수를 추적합니다. ## 동시성 문제 ### 동시성이 낮은 실행 환경에서 스로틀링 발생 **문제:** 사용 가능한 용량이 있더라도 함수에 스로틀링이 발생합니다. **원인:** 최대 동시성이 매우 낮은 실행 환경은 효과적인 조정이 어려울 수 있습니다. Lambda 관리형 인스턴스는 다중 동시 애플리케이션용으로 설계되었습니다. **해결 방법:** + **최대 동시성 증가:** 함수 간접 호출에서 CPU를 거의 사용하지 않는 경우 최대 동시성 설정을 vCPU당 최대 64로 늘립니다. + **함수 코드 최적화:** 함수 코드를 검토하여 간접 호출당 CPU 소비량을 줄이고 동시성을 높입니다. + **함수 메모리 및 vCPU 조정:** 함수에 여러 개의 동시 간접 호출을 처리하기에 충분한 리소스가 있어야 합니다. ### 스레드 안전 문제(Java 런타임) **문제:** Java 함수가 잘못된 결과를 생성하거나 로드 시 경합 상태가 발생합니다. **원인:** 여러 스레드가 핸들러 메서드를 동시에 실행하며 공유 상태가 스레드 안전이 아닙니다. **해결 방법:** + 기본 유형 대신 카운터에 `AtomicInteger` 또는 `AtomicLong` 사용 + `HashMap`를 `ConcurrentHashMap`으로 바꿉니다. + `Collections.synchronizedList()`를 사용하여 `ArrayList` 래핑 + 요청별 상태에 `ThreadLocal` 사용 + 환경 변수가 아닌 Lambda 컨텍스트 객체에서 트레이스 ID에 액세스 자세한 지침은 [Lambda 관리형 인스턴스용 Java 런타임](lambda-managed-instances-java-runtime.md) 설명서를 참조하세요. ### 상태 격리 문제(Node.js 런타임) **문제:** Node.js 함수가 다른 요청의 데이터를 반환하거나 데이터 손상이 발생합니다. **원인:** 전역 변수는 동일한 작업자 스레드에서의 동시 간접 호출 간에 공유됩니다. 비동기 작업에서 제어가 가능하면 다른 간접 호출에서 공유 상태를 수정할 수 있습니다. **해결 방법:** + 모든 요청별 상태에 `@aws/lambda-invoke-store` 설치 및 사용 + 전역 변수를 `InvokeStore.set()` 및 `InvokeStore.get()`으로 바꾸기 + 요청 ID와 함께 `/tmp`에서 고유한 파일 이름 사용 + 환경 변수 대신 `InvokeStore.getXRayTraceId()`를 사용하여 트레이스 ID 액세스 자세한 지침은 [Lambda 관리형 인스턴스용 Node.js 런타임](lambda-managed-instances-nodejs-runtime.md) 설명서를 참조하세요. ### 파일 충돌(Python 런타임) **문제:** Python 함수가 `/tmp`의 파일에서 잘못된 데이터를 읽습니다. **원인:** 여러 프로세스에서 `/tmp` 디렉터리를 공유합니다. 동일한 파일에 대한 동시 쓰기는 데이터를 손상시킬 수 있습니다. **해결 방법:** + 요청 ID와 함께 고유한 파일 이름 사용: `/tmp/request_{context.request_id}.txt` + 공유 파일에 대해 `fcntl.flock()`으로 파일 잠금 사용 + 사용 후 `os.remove()`를 사용하여 임시 파일 정리 자세한 지침은 [Lambda 관리형 인스턴스용 Python 런타임](lambda-managed-instances-python-runtime.md) 설명서를 참조하세요. ## 성능 문제 ### 높은 메모리 사용률 **문제:** 함수의 메모리 사용률이 높거나 메모리 부족 오류가 발생합니다. **원인:** Python의 각 동시 요청이 자체 메모리 공간이 있는 별도의 프로세스에서 실행됩니다. 총 메모리 사용량은 프로세스당 메모리와 동시 프로세스를 곱한 값과 같습니다. **해결 방법:** + CloudWatch에서 `MemoryUtilization` 지표 모니터링 + 메모리 사용량이 함수의 메모리 제한에 가까워지면 `MaxConcurrency` 설정 감소 + 더 높은 동시성을 지원하도록 함수 메모리 할당 증가 + 초기화 도중 대신 온디맨드 방식으로 데이터를 로드하여 메모리 사용량 최적화 ### 일관적이지 않은 성능 **문제:** 함수 성능이 간접 호출마다 크게 다릅니다. **원인:** Lambda에서 가용성에 따라 다른 인스턴스 유형을 선택하거나 함수가 리소스 가용성이 다양한 인스턴스에서 실행 중일 수 있습니다. **해결 방법:** + **허용되는 인스턴스 유형 지정:** 특정 성능 요구 사항이 있는 경우 Lambda가 선택할 수 있는 인스턴스 유형을 제한하도록 용량 공급자에서 허용되는 인스턴스 유형을 구성합니다. + **인스턴스 수준 지표 모니터링:** 용량 공급자 수준에서 `CPUUtilization` 및 `MemoryUtilization` 지표를 추적하여 리소스 제약을 식별합니다. + **용량 지표 검토:** `vCPUAvailable` 및 `MemoryAvailable`을 확인하여 인스턴스에서 충분한 리소스를 사용할 수 있는지 확인합니다. ## 용량 공급자 문제 ### 함수 버전이 ACTIVE 상태가 되지 않음 **문제:** 게시 후에도 함수 버전이 보류 상태로 유지됩니다. **원인:** Lambda가 관리형 인스턴스를 시작하고 실행 환경을 시작합니다. 이 프로세스는 특히 새 용량 공급자의 첫 번째 함수 버전에서는 시간이 걸립니다. **해결 방법:** Lambda에서 초기화 프로세스가 완료될 때까지 기다립니다. Lambda는 기본적으로 AZ 복원력을 위해 인스턴스 3개를 시작하고 실행 환경 3개를 시작한 다음 함수 버전을 ACTIVE로 표시합니다. 일반적으로 몇 분 정도 걸립니다. ### 용량 공급자 삭제 불가 **문제:** 용량 공급자를 삭제하려고 할 때 오류가 발생합니다. **원인:** 함수 버전이 연결된 용량 공급자는 삭제할 수 없습니다. **해결 방법:** 1. `ListFunctionVersionsByCapacityProvider` API에서 용량 공급자를 사용하여 모든 함수 버전을 식별합니다. 1. 해당 함수 버전을 삭제 또는 업데이트하여 용량 공급자 연결을 제거합니다. 1. 용량 공급자 삭제를 다시 시도합니다. ### 함수 게시 중 발생하는 일반적인 오류 메시지 **문제:** 함수를 게시할 때 "Internal error occurred during publishing" 등의 일반 오류 메시지가 표시됩니다. **해결 방법:** + **IAM 권한 확인:** 사용하려는 용량 공급자에 대해 `lambda:PassCapacityProvider` 권한이 있어야 합니다. + **용량 공급자 구성 확인:** `GetCapacityProvider` API를 사용하여 용량 공급자가 ACTIVE 상태인지 확인합니다. + **VPC 구성 검토:** 용량 공급자에 지정된 서브넷 및 보안 그룹이 올바르게 구성되고 액세스 가능해야 합니다. + **AWS CloudTrail 로그 확인:** CloudTrail 로그에서 실패한 작업에 대한 자세한 오류 정보를 검토합니다. ## 모니터링 및 관찰성 문제 ### CloudWatch 지표 누락 **문제:** CloudWatch에서 용량 공급자 또는 함수에 대해 필요한 지표가 표시되지 않습니다. **원인:** 지표가 5분 간격으로 게시됩니다. 새 용량 공급자 또는 함수에서 지표가 즉시 제공되지 않을 수 있습니다. **해결 방법:** 함수 버전을 게시한 후 CloudWatch에 지표가 표시되기까지 최소 5\$110분 정도 기다립니다. 올바른 네임스페이스(`AWS/Lambda`)와 차원(`CapacityProviderName`, `FunctionName` 또는 `InstanceType`)을 보고 있는지 확인합니다. ### CloudWatch 로그 검색 불가 **문제:** 함수가 성공적으로 실행되지만 CloudWatch Logs에서 로그를 찾을 수 없습니다. **원인:** Lambda 관리형 인스턴스는 VPC에서 실행되며 네트워크에 연결되어야 CloudWatch Logs로 로그를 전송할 수 있습니다. 적절한 VPC 연결 구성이 없으면 함수가 CloudWatch Logs 서비스 엔드포인트에 연결할 수 없습니다. **해결 방법:** 함수가 CloudWatch Logs로 로그를 전송할 수 있도록 VPC 연결을 구성합니다. 여기에는 다음과 같은 3가지 옵션이 있습니다. **옵션 1: CloudWatch Logs용 VPC 엔드포인트(프로덕션에 권장)** 1. [console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다. 1. 탐색 창에서 **엔드포인트**를 선택합니다. 1. **엔드포인트 생성**을 선택합니다. 1. **서비스 범주(Service category)**에서 **AWS 서비스**를 선택합니다. 1. **서비스 이름**에서 `com.amazonaws.region.logs`(`region`을 해당 AWS 리전으로 교체)를 선택합니다. 1. **VPC**에서 용량 공급자에서 사용되는 VPC를 선택합니다. 1. **서브넷**에서 엔드포인트 네트워크 인터페이스를 생성하려는 서브넷을 선택합니다. 고가용성을 위해 여러 가용 영역의 서브넷을 선택합니다. 1. **보안 그룹**에서 함수의 보안 그룹 중 인바운드 HTTPS 트래픽(포트 443)을 허용하는 보안 그룹을 선택합니다. 1. 엔드포인트에 대해 **프라이빗 DNS**를 활성화합니다. 1. **엔드포인트 생성**을 선택합니다. **옵션 2: 인터넷 게이트웨이를 사용하는 퍼블릭 서브넷** 용량 공급자가 퍼블릭 서브넷을 사용하는 경우 다음 사항을 확인합니다. 1. 인터넷 게이트웨이가 VPC에 연결됨 1. 라우팅 테이블이 `0.0.0.0/0` 트래픽을 인터넷 게이트웨이로 라우팅 1. 보안 그룹이 포트 443에서 아웃바운드 HTTPS 트래픽 허용 **옵션 3: NAT 게이트웨이를 사용하는 프라이빗 서브넷** 용량 공급자가 프라이빗 서브넷을 사용하는 경우 다음 사항을 확인합니다. 1. 퍼블릭 서브넷에 NAT 게이트웨이 존재 1. 프라이빗 서브넷 라우팅 테이블이 `0.0.0.0/0` 트래픽을 NAT 게이트웨이로 라우팅 1. 퍼블릭 서브넷 라우팅 테이블이 `0.0.0.0/0` 트래픽을 인터넷 게이트웨이로 라우팅 1. 보안 그룹이 포트 443에서 아웃바운드 HTTPS 트래픽 허용 VPC 연결 옵션에 대한 자세한 지침은 [Lambda 관리형 인스턴스의 VPC 연결](lambda-managed-instances-networking.md)을 참조하세요. ### 동시 요청과 로그의 상호 연관에 대한 어려움 **문제:** 서로 다른 요청의 로그가 인터리브되어 개별 요청을 추적하기 어렵습니다. **원인:** 여러 동시 시스템에서 로그 인터리브는 자연스러운 동작입니다. **해결 방법:** + **JSON 형식의 구조화된 로깅 사용:** 모든 로그 문에 요청 ID 포함 + **Java:** `ThreadContext`와 함께 Log4j를 사용하여 요청 ID 자동 포함 + **Node.js:** JSON 형식과 함께 `console.log()`를 사용하고 `InvokeStore.getRequestId()` 포함 + **Python:** 표준 로깅 모듈을 JSON 형식과 함께 사용하고 `context.request_id` 포함 자세한 지침은 런타임별 설명서 페이지를 참조하세요. ## 추가 도움말 받기 이러한 해결 방법을 시도한 후에도 문제가 계속 발생하는 경우: 1. **CloudWatch 지표 검토:** 용량 공급자 및 실행 환경 지표를 확인하여 리소스 제약 조건 또는 규모 조정 문제를 식별합니다. 1. **AWS CloudTrail 로그 확인:** CloudTrail 로그에서 API 호출 및 오류에 대한 자세한 정보를 검토합니다. 1. **AWS Support에 문의:** 문제를 해결할 수 없는 경우 AWS Support에 용량 공급자 구성, 함수 구성 및 발생하는 특정 오류 메시지와 관련된 세부 정보를 문의합니다. ## 다음 단계 + [Lambda 관리형 인스턴스의 용량 공급자](lambda-managed-instances-capacity-providers.md) 알아보기 + [Lambda 관리형 인스턴스의 규모 조정](lambda-managed-instances-scaling.md) 알아보기 + [Java](lambda-managed-instances-java-runtime.md), [Node.js](lambda-managed-instances-nodejs-runtime.md) 및 [Python](lambda-managed-instances-python-runtime.md)에 대한 런타임별 가이드 검토 + [CloudWatch 지표](lambda-managed-instances-monitoring.md)를 사용하여 Lambda 관리형 인스턴스 모니터링 + [Lambda 관리형 인스턴스 모범 사례](lambda-managed-instances-best-practices.md) 검토