# Lambda 문제 해결 다음 항목에서는 Lambda API, 콘솔 또는 도구를 사용할 때 발생할 수 있는 오류 및 문제에 대한 문제 해결 조언을 제공합니다. 여기에 나열되지 않은 문제를 발견하는 경우 이 페이지의 [**Feedback**] 버튼을 사용하여 해당 문제를 보고할 수 있습니다. 문제 해결 조언과 일반적인 지원 질문에 대한 답변은 [AWS 지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda)를 참조하세요. Lambda 애플리케이션 디버깅 및 문제 해결에 대한 자세한 내용은 Serverless Land의 [Debugging](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops)을 참조하세요. **Topics** + [Lambda의 구성 문제 해결](troubleshooting-configuration.md) + [Lambda의 배포 문제 해결](troubleshooting-deployment.md) + [Lambda의 호출 문제 해결](troubleshooting-invocation.md) + [Lambda의 실행 문제 해결](troubleshooting-execution.md) + [Lambda의 이벤트 소스 매핑 문제 해결](troubleshooting-event-source-mapping.md) + [Lambda의 네트워킹 문제 해결](troubleshooting-networking.md) # Lambda의 구성 문제 해결 함수 구성 설정은 Lambda 함수의 전반적인 성능 및 동작에 영향을 미칠 수 있습니다. 이로 인해 실제 함수 오류가 발생하지는 않지만 예기치 않은 제한 시간 초과 및 결과가 발생할 수 있습니다. 다음 주제에서는 Lambda 함수 구성 설정과 관련하여 발생할 수 있는 일반적인 문제에 대한 문제 해결 조언을 제공합니다. **Topics** + [메모리 구성](#memory-config) + [CPU 경계 구성](#cpu-bound-config) + [시간 초과](#timeouts) + [간접 호출 간 메모리 누수](#memory-leakage) + [비동기식 결과가 이후 간접 호출로 반환됨](#asynchronous-results) ## 메모리 구성 128MB\$110,240MB의 메모리를 사용하도록 Lambda 함수를 구성할 수 있습니다. 기본적으로 콘솔에서 생성된 모든 함수에는 가장 적은 양의 메모리가 할당됩니다. 많은 Lambda 함수가 이 최저 설정에서 작동합니다. 그러나 대용량 코드 라이브러리를 가져오거나 메모리 집약적인 작업을 완료하는 경우 128MB로는 충분하지 않습니다. 함수 실행 속도가 예상보다 느린 경우 첫 번째 단계는 메모리 설정을 늘리는 것입니다. 메모리 경계 함수의 경우 이를 통해 병목 현상을 해결하고 함수 성능을 개선할 수 있습니다. ## CPU 경계 구성 컴퓨팅 집약적 작업의 경우 함수 성능이 예상보다 느리다면 함수가 CPU 바운드이기 때문일 수 있습니다. 이 경우 함수의 계산 용량이 작업과 보조를 맞출 수 없습니다. Lambda에서는 CPU 구성을 직접 수정할 수 없지만 메모리 설정을 통해 CPU를 간접적으로 제어할 수 있습니다. Lambda 서비스는 메모리를 더 많이 할당하면 비례적으로 더 많은 가상 CPU를 할당합니다. 1.8GB 메모리에서 Lambda 함수에는 하나의 전체 vCPU가 할당되며, 이 수준을 초과하면 둘 이상의 vCPU 코어에 액세스할 수 있습니다. 10,240MB에서는 6개의 vCPU를 사용할 수 있습니다. 즉, 함수가 메모리를 모두 사용하지 않더라도 메모리 할당을 늘려 성능을 개선할 수 있습니다. ## 시간 초과 Lambda 함수의 [제한 시간](https://docs.aws.amazon.com/lambda/latest/dg/configuration-console.html)은 1\$1900초(15분)로 설정할 수 있습니다. 기본적으로 Lambda 콘솔은 이를 3초로 설정합니다. 제한 시간 값은 함수가 무기한 실행되지 않도록 하는 안전 밸브입니다. 제한 시간 값에 도달하면 Lambda는 함수 간접 호출을 중지합니다. 제한 시간 값이 함수의 평균 지속 시간에 가깝게 설정되면 함수가 예기치 않게 제한 시간을 초과할 위험이 커집니다. 함수의 지속 시간은 데이터 전송량 및 처리량과 함수가 상호 작용하는 서비스의 지연 시간에 따라 달라질 수 있습니다. 시간 초과의 일반적인 원인은 다음과 같습니다. + S3 버킷 또는 기타 데이터 저장소에서 데이터를 다운로드할 때 다운로드 크기가 더 커지거나 시간이 평균보다 더 오래 걸립니다. + 함수가 다른 서비스에 요청을 보내면 응답하는 데 시간이 더 오래 걸립니다. + 함수에 제공되는 파라미터가 있으면 함수의 계산 복잡성이 커지므로 호출 시간이 더 오래 걸립니다. 애플리케이션을 테스트할 때는 데이터의 크기 및 양과 실제 파라미터 값이 테스트에 정확하게 반영되는지 확인하세요. 중요한 것은 워크로드에 대해 합리적으로 예상되는 상한의 데이터세트를 사용하는 것입니다. 또한 가능한 경우 워크로드에 상한을 구현하세요. 이 예제에서 애플리케이션은 각 파일 유형에 대해 최대 크기 제한을 사용할 수 있습니다. 그런 다음, 최대 한도(경계 포함)를 포함하여 예상되는 파일 크기 범위에 대해 애플리케이션의 성능을 테스트할 수 있습니다. ## 간접 호출 간 메모리 누수 Lambda 간접 호출의 INIT 단계에 저장된 전역 변수 및 객체는 웜 간접 호출 사이에서 상태를 유지합니다. 실행 환경이 처음 실행되는 경우에만 완전히 재설정됩니다('콜드 스타트'라고도 함). 핸들러에 저장된 모든 변수는 핸들러가 종료되면 소멸됩니다. INIT 단계를 사용하여 데이터베이스 연결을 설정하고 라이브러리를 로드하며 캐시를 생성하고 변경할 수 없는 자산을 로드하는 것이 좋습니다. 동일한 실행 환경의 여러 간접 호출에서 서드파티 라이브러리를 사용하는 경우 서버리스 컴퓨팅 환경에서의 사용에 대한 해당 라이브러리 설명서를 확인하세요. 일부 데이터베이스 연결 및 로깅 라이브러리는 중간 간접 호출 결과 및 기타 데이터를 저장할 수 있습니다. 이 경우 후속 웜 간접 호출 시 이러한 라이브러리의 메모리 사용량이 증가합니다. 이런 경우라면 사용자 지정 코드에서 변수를 올바르게 처리하더라도 Lambda 함수의 메모리가 부족해질 수 있습니다. 이 문제는 웜 실행 환경에서 발생하는 간접 호출에 영향을 미칩니다. 예를 들어 다음 코드로 인해 간접 호출 사이에서 메모리 누수가 발생합니다. Lambda 함수는 전역 배열의 크기를 늘려 간접 호출할 때마다 추가 메모리를 소비합니다. ``` let a = [] exports.handler = async (event) => { a.push(Array(100000).fill(1)) } ``` 128MB 메모리로 구성된 상태에서 이 함수를 1,000회 간접 호출한 후 Lambda 함수의 **모니터링** 탭에는 메모리 누수가 발생했을 때 간접 호출, 지속 시간 및 오류 횟수의 일반적인 변화가 표시됩니다. ![\[디버깅 운영 그림 4\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-4.png) 1. **간접 호출** – 간접 호출을 완료하는 데 더 오래 걸리므로 트랜잭션 속도가 일정하게 유지되다가 주기적으로 중단됩니다. 안정 상태인 동안 메모리 누수는 함수에 할당된 메모리를 모두 소비하지 않습니다. 성능이 저하됨에 따라 운영 체제는 함수에 필요한 증가하는 메모리를 수용하기 위해 로컬 스토리지를 페이징하므로 트랜잭션이 완료되는 횟수가 더 줄어듭니다. 1. **지속 시간** – 함수는 메모리가 부족해지기 전까지 간접 호출을 일정한 두 자릿수 밀리초 속도로 완료합니다. 페이징이 발생하면 지속 시간이 크게 증가합니다. 1. **오류 횟수** – 메모리 누수로 할당된 메모리를 초과하면 결국 계산이 제한 시간을 초과하여 함수 오류가 발생하거나 실행 환경에서 함수를 중지합니다. 오류가 발생한 후 Lambda는 실행 환경을 다시 시작합니다. 이는 세 그래프 모두 원래 상태로 돌아가는 이유를 설명합니다. 지속 시간에 대한 CloudWatch 지표를 확장하면 최소, 최대 및 평균 지속 시간 통계에 대한 세부 정보가 제공됩니다. ![\[디버깅 운영 그림 5\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-5.png) 1,000개의 호출에서 생성된 오류를 찾기 위해 CloudWatch Insights 쿼리 언어를 사용할 수 있습니다. 다음 쿼리에서는 오류만 보고하기 위해 정보 로그를 제외합니다. ``` fields @timestamp, @message | sort @timestamp desc | filter @message not like 'EXTENSION' | filter @message not like 'Lambda Insights' | filter @message not like 'INFO'  | filter @message not like 'REPORT' | filter @message not like 'END' | filter @message not like 'START' ``` 이 함수에 대한 로그 그룹에서 실행하면 제한 시간이 주기적 오류의 원인임을 보여줍니다. ![\[디버깅 운영 그림 6\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-6.png) ## 비동기식 결과가 이후 간접 호출로 반환됨 비동기식 패턴을 사용하는 함수 코드의 경우 한 간접 호출의 콜백 결과가 향후 간접 호출에서 반환될 수 있습니다. 이 예제에서는 Node.js를 사용하지만 비동기식 패턴을 사용하여 다른 런타임에 동일한 로직을 적용할 수 있습니다. 함수는 JavaScript에서 기존 콜백 구문을 사용합니다. 간접 호출 수를 추적하는 증분 카운터를 포함하는 비동기식 함수를 직접 호출합니다. ``` let seqId = 0 exports.handler = async (event, context) => { console.log(`Starting: sequence Id=${++seqId}`) doWork(seqId, function(id) { console.log(`Work done: sequence Id=${id}`) }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` 연속해서 여러 번 간접 호출하면 후속 간접 호출에서 콜백 결과가 나타납니다. ![\[디버깅 운영 그림 7\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-7.png) 1. 코드는 `doWork` 함수를 직접 호출하며 콜백 함수를 마지막 파라미터로 제공합니다. 1. 콜백을 간접적으로 호출하기 전에 `doWork` 함수를 완료하는 데 어느 정도 시간이 걸립니다. 1. 함수의 로깅은 `doWork` 함수가 실행을 완료하기 전에 간접 호출이 종료되고 있음을 나타냅니다. 또한 반복을 시작한 후 로그에서와 같이 이전 반복의 콜백이 처리되고 있습니다. JavaScript에서 비동기 콜백은 [이벤트 루프](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop)로 처리됩니다. 다른 런타임에서는 다른 메커니즘을 사용하여 동시성을 처리합니다. 함수의 실행 환경이 종료되면 Lambda는 다음 간접 호출까지 환경을 동결합니다. 재개된 후 JavaScript는 이벤트 루프를 계속 처리합니다. 이 경우에는 이전 간접 호출의 비동기식 콜백이 포함됩니다. 이 컨텍스트가 없으면 함수가 아무런 이유 없이 코드를 실행하고 임의의 데이터를 반환하는 것처럼 보일 수 있습니다. 실제로는 런타임 동시성 및 실행 환경이 상호 작용하는 방식을 보여주는 아티팩트입니다. 이 경우 이전 간접 호출의 프라이빗 데이터가 후속 간접 호출에 나타날 수 있습니다. 이 동작을 방지하거나 감지하는 두 가지 방법이 있습니다. 먼저 JavaScript는 [비동기식 및 대기 키워드](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function)를 제공하여 비동기식 개발을 단순화하고 비동기식 직접 호출이 완료될 때까지 코드 실행에서 강제로 대기하도록 합니다. 위 함수는 다음과 같이 접근 방식을 사용하여 다시 쓸 수 있습니다. ``` let seqId = 0 exports.handler = async (event) => { console.log(`Starting: sequence Id=${++seqId}`) const result = await doWork(seqId) console.log(`Work done: sequence Id=${result}`) } function doWork(id) { return new Promise(resolve => { setTimeout(() => resolve(id), 4000) }) } ``` 이 구문을 사용하면 비동기식 함수가 완료되기 전에 핸들러가 종료되지 않습니다. 이 경우 콜백이 Lambda 함수의 제한 시간보다 오래 걸리는 경우 함수는 나중에 간접 호출에서 콜백 결과를 반환하는 대신 오류를 발생시킵니다. ![\[디버깅 운영 그림 8\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-8.png) 1. 코드는 핸들러의 await 키워드를 사용하여 비동기식 `doWork` 함수를 직접적으로 호출합니다. 1. promise를 해결하기 전에 `doWork` 함수를 완료하는 데 어느 정도 시간이 걸립니다. 1. `doWork`가 제한 시간보다 오래 걸리고 나중에 간접 호출 시 콜백 결과가 반환되지 않으므로 함수 제한 시간이 초과됩니다. 일반적으로 코드가 존재하려면 먼저 코드의 백그라운드 프로세스나 콜백이 완료되어야 합니다. 사용 사례에서 불가능한 경우 콜백이 현재 간접 호출에 속하도록 식별자를 사용할 수 있습니다. 이를 위해 컨텍스트 객체에서 제공하는 *awsRequestId*를 사용할 수 있습니다. 이 값을 비동기식 콜백에 전달하면 전달된 값을 현재 값과 비교하여 콜백이 다른 간접 호출에서 시작되었는지 여부를 감지할 수 있습니다. ``` let currentContext exports.handler = async (event, context) => { console.log(`Starting: request id=$\{context.awsRequestId}`) currentContext = context doWork(context.awsRequestId, function(id) { if (id != currentContext.awsRequestId) { console.info(`This callback is from another invocation.`) } }) } function doWork(id, callback) { setTimeout(() => callback(id), 3000) } ``` ![\[디버깅 운영 그림 9\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-9.png) 1. Lambda 함수 핸들러는 고유한 간접 호출 요청 ID에 대한 액세스를 제공하는 컨텍스트 파라미터를 사용합니다. 1. `awsRequestId`가 doWork 함수로 전달됩니다. 콜백에서 ID는 현재 간접 호출의 `awsRequestId`와 비교됩니다. 이러한 값이 서로 다르면 코드에서 적절히 작업을 수행할 수 있습니다. # Lambda의 배포 문제 해결 함수를 업데이트할 때 Lambda는 업데이트된 코드 또는 설정으로 함수의 새 인스턴스를 시작하여 변경 사항을 배포합니다. 배포 오류로 인해 새 버전이 사용되지 않으며, 이는 배포 패키지, 코드, 권한 또는 도구 문제 때문에 발생할 수 있습니다. Lambda API를 사용하거나 AWS CLI와 같은 클라이언트를 사용하여 함수로 업데이트를 직접 배포하면 출력에서 직접 Lambda의 오류를 볼 수 있습니다. AWS CloudFormation, AWS CodeDeploy 또는 AWS CodePipeline 같은 서비스를 사용하는 경우에는 해당 서비스 로그 또는 이벤트 스트림에서 Lambda의 응답을 찾아보세요. 다음 항목에서는 Lambda API, 콘솔 또는 도구를 사용할 때 발생할 수 있는 오류 및 문제에 대한 문제 해결 조언을 제공합니다. 여기에 나열되지 않은 문제를 발견하는 경우 이 페이지의 [**Feedback**] 버튼을 사용하여 해당 문제를 보고할 수 있습니다. 문제 해결 조언과 일반적인 지원 질문에 대한 답변은 [AWS 지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/#AWS_Lambda)를 참조하세요. Lambda 애플리케이션 디버깅 및 문제 해결에 대한 자세한 내용은 Serverless Land의 [Debugging](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/debugging-ops)을 참조하세요. **Topics** + [일반: 권한이 거부됨 / 해당 파일을 로드할 수 없음](#troubleshooting-deployment-denied) + [일반: UpdateFunctionCode 호출 시 오류 발생](#troubleshooting-deployment-updatefunctioncode) + [Amazon S3: 오류 코드 PermanentRedirect.](#troubleshooting-deployment-PermanentRedirect) + [일반: 찾을 수 없음, 로드할 수 없음, 가져올 수 없음, 클래스를 찾을 수 없음, 해당 파일 또는 디렉터리가 없음](#troubleshooting-deployment-functionHandler1) + [일반: 정의되지 않은 메서드 핸들러](#troubleshooting-deployment-functionHandler2) + [일반: Lambda 코드 스토리지 한도 초과](#troubleshooting-deployment-CodeStorageExceeded) + [Lambda: 계층 변환 실패](#troubleshooting-deployment-LayerConversionFailed) + [Lambda: InvalidParameterValueException or RequestEntityTooLargeException](#troubleshooting-deployment-InvalidParameterValueException1) + [Lambda: InvalidParameterValueException](#troubleshooting-deployment-InvalidParameterValueException2) + [Lambda: 동시성 및 메모리 할당량](#troubleshooting-deployment-quotas) + [Lambda: 프로비저닝된 동시성에 대한 잘못된 별칭 구성](#troubleshooting-deployment-provisioned-concurrency) ## 일반: 권한이 거부됨 / 해당 파일을 로드할 수 없음 **오류:** *EACCES: 권한 거부, '/var/task/index.js' 열기* **오류:** *해당 파일을 로드할 수 없음 -- 함수* **오류:** *[Errno 13] 권한 거부: '/var/task/function.py'* Lambda 런타임은 배포 패키지의 파일을 읽을 수 있는 권한이 필요합니다. Linux 권한 8진수 표기법에서는 Lambda에 실행 불가능한 파일(rw-r--r--)에 대한 644개의 권한과 디렉터리 및 실행 파일에 대한 755개의 권한(rwxr-xr-x)이 필요합니다. Linux 및 MacOS에서는 `chmod` 명령을 사용하여 배포 패키지의 파일 및 디렉터리에 대한 파일 권한을 변경합니다. 예를 들어 실행 불가능한 파일에 올바른 권한을 부여하려면 다음 명령을 실행합니다. ``` chmod 644 ``` Windows에서 파일 권한을 변경하려면 Microsoft Windows 설명서의 [Set, View, Change, or Remove Permissions on an Object](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731667(v=ws.10))를 참조하세요. **참고** 배포 패키지의 디렉터리에 액세스하는 데 필요한 권한을 Lambda에 부여하지 않으면 Lambda는 해당 디렉터리에 대한 권한을 755(rwxr-xr-x)로 설정합니다. ## 일반: UpdateFunctionCode 호출 시 오류 발생 **오류:** *UpdateFunctionCode 작업을 호출할 때 오류 발생(RequestEntityTooLargeException)* 배포 패키지 또는 계층 아카이브를 Lambda에 직접 업로드하면 ZIP 파일의 크기가 50MB로 제한됩니다. 더 큰 파일을 업로드하려면 Amazon S3에 저장하고 S3Bucket 및 S3Key 파라미터를 사용하세요. **참고** AWS CLI, AWS SDK 또는 다른 방법으로 파일을 직접 업로드하면 이진수 ZIP 파일이 base64로 변환되어 크기가 약 30% 증가합니다. 이를 허용하고 요청에서 다른 파라미터 크기를 허용하려면 Lambda가 적용하는 실제 요청 크기 제한이 더 큽니다. 이로 인해 50MB 제한은 근사값입니다. ## Amazon S3: 오류 코드 PermanentRedirect. **오류:** *GetObject를 수행하는 동안 오류가 발생했습니다. S3 오류 코드: PermanentRedirect. S3 오류 메시지: 버킷이 us-east-2 리전에 있습니다. 이 리전을 사용하여 요청을 다시 시도하세요* Amazon S3 버킷에서 함수의 배포 패키지를 업로드할 때 버킷은 함수와 동일한 리전에 있어야 합니다. [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) 호출 시 Amazon S3 객체를 지정하거나 AWS CLI 또는 AWS SAM CLI에서 패키지를 사용하고 명령을 배포할 때 이러한 문제가 발생할 수 있습니다. 애플리케이션을 개발하는 각 리전에 대한 배포 아티팩트 버킷을 생성합니다. ## 일반: 찾을 수 없음, 로드할 수 없음, 가져올 수 없음, 클래스를 찾을 수 없음, 해당 파일 또는 디렉터리가 없음 **오류:** *모듈 'function'을 찾을 수 없음* **오류:** *해당 파일을 로드할 수 없음 -- 함수* **오류:** *모듈 'function'을 가져올 수 없음* **오류:** *클래스를 찾을 수 없음: function.Handler* **오류:** *fork/exec /var/task/function: 이러한 파일 또는 디렉터리 없음* **오류:** *어셈블리 'Function'에서 'Function.Handler' 유형을 로드할 수 없음.* 함수의 핸들러 구성에 있는 파일 또는 클래스의 이름이 코드와 일치하지 않습니다. 자세한 내용은 다음 섹션을 참조하세요. ## 일반: 정의되지 않은 메서드 핸들러 **오류:** *index.handler가 정의되지 않거나 내보내지지 않음* **오류:** *모듈 'function'에 핸들러 'handler'가 없음* **오류:** *\$1에 정의되지 않은 메서드 `handler'* **오류:** *class function.Handler에서 적절한 메서드 서명이 있는 handleRequest라는 이름의 퍼블릭 메서드 없음* **오류:** *어셈블리 'Function'에서 'Function.Handler' 유형의 'handleRequest' 메서드를 찾을 수 없음* 함수의 핸들러 구성에 있는 핸들러 메서드의 이름이 코드와 일치하지 않습니다. 각 런타임은 *filename*.*methodname* 같은 핸들러의 이름 지정 규칙을 정의합니다. 핸들러는 함수가 간접 호출될 때 런타임이 실행하는 함수 코드의 메서드입니다. 일부 언어의 경우 Lambda는 핸들러 메서드에 특정 이름이 있어야 하는 인터페이스를 라이브러리에 제공합니다. 각 언어의 핸들러 이름 지정에 관한 자세한 내용은 다음 항목을 참조하세요. + [Node.js를 사용하여 Lambda 함수 빌드](lambda-nodejs.md) + [Python을 사용하여 Lambda 함수 빌드](lambda-python.md) + [Ruby를 사용하여 Lambda 함수 빌드](lambda-ruby.md) + [Java를 사용하여 Lambda 함수 빌드](lambda-java.md) + [Go를 사용하여 Lambda 함수 빌드](lambda-golang.md) + [C\$1을 사용하여 Lambda 함수 빌드](lambda-csharp.md) + [PowerShell을 사용하여 Lambda 함수 빌드](lambda-powershell.md) ## 일반: Lambda 코드 스토리지 한도 초과 **오류:** *코드 스토리지 한도를 초과했습니다.* Lambda는 계정에 프라이빗으로 존재하는 내부 S3 버킷에 함수 코드를 저장합니다. 각 AWS 계정에는 각 리전에 75GB의 스토리지가 할당됩니다. 코드 스토리지에는 Lambda 함수 및 계층 모두에서 사용하는 총 스토리지가 포함됩니다. 할당량에 도달하면 새 함수를 배포하려고 할 때 *CodeStorageExceededException*이 수신됩니다. 이전 버전의 함수를 정리하거나, 사용되지 않는 코드를 제거하거나, Lambda 계층을 사용하여 사용 가능한 스토리지 스페이스를 관리합니다. 또한 스토리지 할당량을 관리하는 데 도움이 되도록 [별도의 워크로드에 별도의 AWS 계정을 사용하는 것](concepts-application-design.md#multiple-accounts)이 좋습니다. Lambda 콘솔의 **대시보드** 하위 메뉴에서 총 스토리지 사용량을 볼 수 있습니다. ![\[모니터링 관찰성 그림 26\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/monitoring-observability-figure-26.png) ## Lambda: 계층 변환 실패 **오류:** *Lambda 계층 변환에 실패했습니다. *이 문제를 해결하는 방법에 대한 자세한 내용은 Lambda 사용 설명서의 Lambda의 배포 문제 해결 페이지를 참조하세요. 계층으로 Lambda 함수를 구성하면 Lambda는 계층을 함수 코드와 병합합니다. 이 프로세스가 완료되지 않으면 Lambda는 이 오류를 반환합니다. 이 오류가 발생한 경우 다음 단계를 수행합니다. + 계층에서 사용하지 않는 파일 삭제 + 계층에서 심볼 링크 삭제 + 모든 함수 계층의 디렉터리와 이름이 같은 모든 파일의 이름 변경 ## Lambda: InvalidParameterValueException or RequestEntityTooLargeException **오류:** *InvalidParameterValueException: 제공된 환경 변수가 4KB 제한을 초과했기 때문에 Lambda에서 환경 변수를 구성할 수 없음. 측정된 문자열: \$1"A1":"uSFeY5cyPiPn7AtnX5BsM...* **오류:** *RequestEntityTooLargeException: UpdateFunctionConfiguration 작업에 대한 요청은 5,120바이트보다 작아야 함* 함수의 구성에 저장되는 변수 객체의 최대 크기는 4,096바이트를 초과할 수 없습니다. 여기에는 키 이름, 값, 따옴표, 쉼표 및 대괄호가 포함됩니다. HTTP 요청 본문의 총 크기도 제한됩니다. ``` { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:us-east-2:123456789012:function:my-function", "Runtime": "nodejs24.x", "Role": "arn:aws:iam::123456789012:role/lambda-role", "Environment": { "Variables": { "BUCKET": "amzn-s3-demo-bucket", "KEY": "file.txt" } }, ... } ``` 이 예제에서 객체는 39자이며 공백 없이 문자열 `{"BUCKET":"amzn-s3-demo-bucket","KEY":"file.txt"}`로 저장될 때 39바이트를 차지합니다. 환경 변수 값의 표준 ASCII 문자는 각각 1바이트를 사용합니다. 확장 ASCII 및 유니코드 문자는 문자당 2\$14바이트를 사용할 수 있습니다. ## Lambda: InvalidParameterValueException **오류:** *InvalidParameterValueException: 제공된 환경 변수에 현재 수정 불가능한 예약된 키가 포함되어 있기 때문에 Lambda에서 환경 변수를 구성할 수 없음.* Lambda는 내부 사용을 위해 일부 환경 변수 키를 예약합니다. 예를 들어 `AWS_REGION`는 런타임에 현재 리전을 결정하는 데 사용되며 재정의될 수 없습니다. `PATH`를 비롯한 다른 변수는 런타임에 사용되지만 함수 구성에서 확장될 수 있습니다. 전체 목록은 [정의된 런타임 환경 변수](configuration-envvars.md#configuration-envvars-runtime) 단원을 참조하세요. ## Lambda: 동시성 및 메모리 할당량 **Error:*** Specified ConcurrentExecutions for function decreases account's UnreservedConcurrentExecution below its minimum value* **Error:*** 'MemorySize' value failed to satisfy constraint: Member must have value less than or equal to 3008* 이러한 오류는 계정에 대한 동시성 또는 메모리 [할당량](gettingstarted-limits.md)이 초과될 때 발생합니다. 새 AWS 계정에 감소된 동시성 및 메모리 할당량이 적용되었습니다. 동시성과 관련한 오류를 해결하려면 [할당량 증가를 요청](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)하면 됩니다. 메모리 할당량 증가는 요청할 수 없습니다. + **동시성:** 예약되거나 프로비저닝된 동시성을 사용하여 함수를 만들려고 하거나 함수별 동시성 요청([PutFunctionConcurrency](https://docs.aws.amazon.com/lambda/latest/api/API_PutFunctionConcurrency.html))이 계정의 동시성 할당량을 초과하는 경우 오류가 발생할 수 있습니다. + **메모리:** 함수에 할당된 메모리의 양이 계정의 메모리 할당량을 초과하면 오류가 발생합니다. ## Lambda: 프로비저닝된 동시성에 대한 잘못된 별칭 구성 **오류:*** 프로비저닝된 동시성에 대한 잘못된 별칭 구성* 이 오류는 프로비저닝된 동시성을 사용하는 별칭이 문제 있는 버전을 가리키는 상태에서 Lambda 함수의 코드 또는 구성을 업데이트하려고 할 때 발생합니다. Lambda는 프로비저닝된 동시성을 위해 실행 환경을 사전 초기화하며 코드 오류, 리소스 제약 또는 영향을 받는 스택 및 별칭으로 인해 이러한 환경을 제대로 초기화할 수 없는 경우 배포가 실패합니다. 이 문제가 발생한 경우 다음 단계를 수행합니다. 1. **별칭 롤백:** 이전에 작동한 버전을 가리키도록 별칭을 일시적으로 업데이트합니다. ``` aws lambda update-alias \ --function-name \ --name \ --function-version ``` 1. **Lambda 초기화 코드 수정:** 핸들러 외부에서 실행되는 초기화 코드에 발견되지 않은 예외가 없는지 확인하고 클라이언트와 연결을 초기화합니다. 1. **안전 재배포:** 수정된 코드를 배포하고 새 버전을 게시합니다. 그런 다음 수정된 버전을 가리키도록 별칭을 업데이트합니다. 필요한 경우 [프로비저닝된 동시성](provisioned-concurrency.md)을 다시 활성화할 수 있습니다. AWS CloudFormation를 사용하는 경우 별칭이 작동 버전을 가리키도록 스택 정의 `FunctionVersion:!GetAtt version.Version`를 업데이트합니다. ``` alias: Type: AWS::Lambda::Alias Properties: FunctionName: !Ref function FunctionVersion: !GetAtt version.Version Name: BLUE ProvisionedConcurrencyConfig: ProvisionedConcurrentExecutions: 1 ``` # Lambda의 호출 문제 해결 Lambda 함수를 간접 호출하면 Lambda는 요청을 검증하고 이벤트를 함수로 전송하거나 비동기 간접 호출의 경우 이벤트 대기열로 보내기 전에 용량 확장을 확인합니다. 요청 파라미터, 이벤트 구조, 함수 설정, 사용자 권한, 리소스 권한 또는 한도와 관련된 문제로 인해 호출 오류가 발생할 수 있습니다. 함수를 직접 간접 호출하면 Lambda에서 보낸 응답에 간접 호출 오류가 표시됩니다. 이벤트 소스 매핑으로 또는 다른 서비스를 통해 함수를 비동기적으로 간접 호출하는 경우 로그, 배달 못한 편지 대기열 또는 실패한 이벤트 대상에 오류가 있을 수 있습니다. 오류 처리 옵션 및 재시도 동작은 함수를 간접 호출하는 방법과 오류 유형에 따라 다릅니다. `Invoke` 작업이 반환할 수 있는 오류 유형 목록은 [간접 호출](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)을 참조하세요. **Topics** + [Lambda: Init 단계에서 함수 시간 초과(Sandbox.Timedout)](#troubleshooting-timeouts) + [IAM: lambda:간접 호출Function 권한 없음](#troubleshooting-invocation-noauth) + [Lambda: 유효한 부트스트랩을 찾을 수 없음(Runtime.InvalidEntrypoint)](#troubleshooting-invocation-bootstrap) + [Lambda: ResourceConflictException 작업을 수행할 수 없음](#troubleshooting-invocation-ResourceConflictException) + [Lambda: 함수가 보류 상태에서 멈춰 있음](#troubleshooting-invocation-pending) + [Lambda: 하나의 함수가 모든 동시성을 사용함](#troubleshooting-invocation-allconcurrency) + [일반: 다른 계정 또는 서비스로 함수를 간접 호출할 수 없음](#troubleshooting-invocation-cannotinvoke) + [일반: 함수 호출이 반복됨](#troubleshooting-invocation-loop) + [Lambda: 프로비저닝된 동시성을 사용한 별칭 라우팅](#troubleshooting-invocation-alias) + [Lambda: 프로비저닝된 동시성으로 콜드 스타트](#troubleshooting-invocation-coldstart) + [Lambda: 새 버전으로 콜드 스타트](#troubleshooting-invocation-newversion) + [Lambda: 런타임에서 예기치 않은 Node.js 종료(Runtime.NodejsExit)](#troubleshooting-invocation-nodejs-exit) + [EFS: 함수가 EFS 파일 시스템을 마운트할 수 없음](#troubleshooting-invocation-efsmount) + [EFS: 함수가 EFS 파일 시스템에 연결할 수 없음](#troubleshooting-invocation-efsconnect) + [EFS: 시간 초과로 인해 함수가 EFS 파일 시스템을 마운트할 수 없음](#troubleshooting-invocation-efstimeout) + [Lambda: Lambda가 시간이 너무 오래 걸리는 IO 프로세스를 탐지함](#troubleshooting-invocation-ioprocess) + [컨테이너: CodeArtifactUserException 오류](#troubleshooting-deployment-container-artifact) + [컨테이너: InvalidEntrypoint 오류](#troubleshooting-deployment-container-entrypoint) ## Lambda: Init 단계에서 함수 시간 초과(Sandbox.Timedout) **오류:** *3.00초 후 작업 시간 초과* [Init](lambda-runtime-environment.md#runtimes-lifecycle-ib) 단계가 시간 초과되면 Lambda는 다음 간접 호출 요청이 도착하면 `Init` 단계를 다시 실행하여 실행 환경을 다시 초기화합니다. 이를 억제된 초기화라고 합니다.[](lambda-runtime-environment.md#suppressed-init) 그러나 함수가 짧은 [제한 시간](configuration-timeout.md)(일반적으로 약 3초)으로 구성된 경우 할당된 제한 시간 동안 억제된 초기화가 완료되지 않아 `Init` 단계가 다시 시간 초과될 수 있습니다. 또는 억제된 초기화가 완료되지만 [간접 호출](lambda-runtime-environment.md#runtimes-lifecycle-invoke) 단계가 완료될 시간이 충분하지 않아 `Invoke` 단계가 시간 초과됩니다. 시간 초과 오류를 줄이려면 다음 전략을 하나 이상 사용하세요. + **함수 제한 시간 늘리기**: [제한 시간](configuration-timeout.md)을 연장하여 `Init` 및 `Invoke` 단계가 성공적으로 완료될 수 있는 시간을 확보합니다. + **함수 메모리 할당 늘리기**: [메모리](configuration-memory.md)가 많을수록 CPU 할당이 비례적으로 더 많아지므로 `Init` 및 `Invoke` 단계 모두 빨라질 수 있습니다. + **함수 초기화 코드 최적화**: 초기화에 필요한 시간을 줄여 구성된 시간 초과 내에 `Init` 및 `Invoke` 단계가 완료될 수 있도록 합니다. ## IAM: lambda:간접 호출Function 권한 없음 **오류:** *사용자: arn:aws:iam::123456789012:사용자/개발자가 수행할 권한이 없음: 리소스의 lambda:간접 호출Function: my-function* 사용자 또는 수임하고자 하는 역할에는 함수를 간접 호출할 수 있는 권한이 있어야 합니다. 이 요구 사항은 Lambda 함수와 함수를 간접 호출하는 다른 컴퓨팅 리소스에도 적용됩니다. AWS 관리형 정책 **AWSLambdaRole**을 사용자에게 추가하거나, 대상 함수에서 `lambda:InvokeFunction` 작업을 허용하는 사용자 정의 정책을 추가하세요. **참고** IAM 작업의 이름(`lambda:InvokeFunction`)은 `Invoke` Lambda API 작업을 나타냅니다. 자세한 내용은 [AWS Lambda에서 권한 관리](lambda-permissions.md) 섹션을 참조하세요. ## Lambda: 유효한 부트스트랩을 찾을 수 없음(Runtime.InvalidEntrypoint) **오류:** *Couldn't find valid bootstrap(s): [/var/task/bootstrap /opt/bootstrap]* 이 오류는 일반적으로 배포 패키지의 루트에 `bootstrap` 실행 파일이 없을 때 발생합니다. 예를 들어, .zip 파일이 포함된 `provided.al2023` 함수를 배포하는 경우 `bootstrap` 파일은 디렉터리가 아닌 .zip 파일의 루트에 있어야 합니다. ## Lambda: ResourceConflictException 작업을 수행할 수 없음 **오류:** *ResourceConflictException: 지금은 작업을 수행할 수 없음. 함수가 현재 보류 중 상태* 함수를 만들 때 Virtual Private Cloud(VPC)에 함수를 연결하면 Lambda에서 탄력적 네트워크 인터페이스를 생성하는 동안 함수가 `Pending` 상태가 됩니다. 이 시간 동안에는 함수를 간접 호출하거나 수정할 수 없습니다. 함수를 만든 후 VPC에 함수를 연결하면 업데이트가 보류 중인 동안 함수를 간접 호출할 수 있지만 해당 코드 또는 구성을 수정할 수는 없습니다. 자세한 정보는 [Lambda 함수 상태](functions-states.md)을 참조하세요. ## Lambda: 함수가 보류 상태에서 멈춰 있음 **오류:** *함수가 몇 분 동안 `Pending` 상태에서 멈춰 있습니다.* 함수가 6분 이상 `Pending` 상태에서 멈춰 있는 경우 다음 API 작업 중 하나를 호출하여 차단을 해제합니다. + [UpdateFunctionCode](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionCode.html) + [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) + [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html) Lambda는 보류 중인 작업을 취소하고 함수를 `Failed` 상태로 전환합니다. 그런 다음 다른 업데이트를 시도할 수 있습니다. ## Lambda: 하나의 함수가 모든 동시성을 사용함 **문제:** *한 함수가 사용 가능한 모든 동시성을 사용하여 다른 함수에 병목을 유발합니다.* AWS 리전에서 AWS 계정의 사용 가능한 동시성을 풀로 나누려면 [예약된 동시성](configuration-concurrency.md)을 사용합니다. 예약된 동시성은 함수가 항상 할당된 동시성으로 확장할 수 있으며 할당된 동시성을 초과하여 확장되지 않도록 합니다. ## 일반: 다른 계정 또는 서비스로 함수를 간접 호출할 수 없음 **문제:** *함수를 직접 간접 호출할 수 있지만, 다른 서비스 또는 계정에서 간접 호출하는 경우 실행되지 않습니다.* [기타 서비스](lambda-services.md) 및 계정에 함수의 [리소스 기반 정책](access-control-resource-based.md)에서 함수를 간접 호출할 수 있는 권한을 부여합니다. 간접 호출자가 다른 계정에 있는 경우, 해당 사용자도 [함수를 간접 호출할 수 있는 권한](access-control-identity-based.md)이 있어야 합니다. ## 일반: 함수 호출이 반복됨 **문제:** *함수가 루프에서 계속 간접 호출됩니다.* 이 문제는 일반적으로 함수가 해당 함수를 트리거하는 동일한 AWS 서비스의 리소스를 관리할 때 발생합니다. 예를 들어, [함수를 다시 간접 호출하는 알림](with-s3.md)으로 구성된 Amazon Simple Storage Service(Amazon S3) 버킷에 객체를 저장하는 함수를 생성할 수 있습니다. 함수 실행을 중지하려면 사용 가능한 [동시성](lambda-concurrency.md)을 0으로 줄입니다. 이렇게 하면 향후 모든 간접 호출이 제한됩니다. 그런 다음 재귀 호출을 일으킨 코드 경로 또는 구성 오류를 파악합니다. Lambda는 일부 AWS 서비스 및 SDK에 대한 재귀 루프를 자동으로 감지하고 중지합니다. 자세한 내용은 [Lambda 재귀 루프 감지를 사용하여 무한 루프 방지](invocation-recursion.md) 섹션을 참조하세요. ## Lambda: 프로비저닝된 동시성을 사용한 별칭 라우팅 **문제:** *별칭 라우팅 중에 프로비저닝된 동시성 초과 호출.* Lambda는 간단한 확률 모델을 사용하여 두 함수 버전 간에 트래픽을 분산시킵니다. 트래픽 수준이 낮으면 각 버전에서 구성된 트래픽과 실제 트래픽의 비율 간에 큰 차이가 나타날 수 있습니다. 함수가 프로비저닝된 동시성을 사용하는 경우 별칭 라우팅이 활성 상태인 동안 더 많은 수의 프로비전된 동시성 인스턴스를 구성하여 [초과(spillover) 호출](monitoring-metrics-types.md#invocation-metrics)을 방지할 수 있습니다. ## Lambda: 프로비저닝된 동시성으로 콜드 스타트 **문제:** *프로비저닝된 동시성을 활성화한 후 콜드 스타트가 표시됩니다.* 함수에 대한 동시 실행 수가 [프로비저닝된 동시성의 구성된 수준](provisioned-concurrency.md)보다 작거나 이와 같으면 콜드 스타트가 없어야 합니다. 프로비저닝된 동시성이 정상적으로 작동하는지 확인하려면 다음을 수행하세요. + 함수 버전 또는 별칭에서 [프로비저닝된 동시성이 활성화되어 있는지 확인](provisioned-concurrency.md)합니다. **참고** 게시되지 않은 [버전의 함수](configuration-versions.md)(\$1LATEST)에서는 프로비저닝된 동시성을 구성할 수 없습니다. + 트리거가 올바른 함수 버전 또는 별칭을 간접 호출하는지 확인합니다. 예를 들어, Amazon API Gateway를 사용하는 경우 API Gateway가 \$1LATEST가 아닌 프로비저닝된 동시성을 사용하여 함수 버전 또는 별칭을 간접 호출하는지 확인합니다. 프로비저닝된 동시성이 사용되고 있는지 확인하려면 [ProvisionedConcurrencyInvocations Amazon CloudWatch 지표](monitoring-concurrency.md#provisioned-concurrency-metrics)를 살펴보면 됩니다. 0이 아닌 값은 함수가 초기화된 실행 환경에서 호출을 처리하고 있음을 나타냅니다. + [ProvisionedConcurrencySpilloverInvocations CloudWatch 지표](monitoring-concurrency.md#provisioned-concurrency-metrics)를 살펴봐서 함수 동시성이 프로비저닝된 동시성의 구성된 수준을 초과하는지 확인합니다. 0이 아닌 값은 프로비저닝된 모든 동시성이 사용 중이고 일부 호출이 콜드 스타트로 발생했음을 나타냅니다. + [호출 빈도](gettingstarted-limits.md#api-requests)(초당 요청 수)를 확인하세요. 프로비저닝된 동시성이 있는 함수의 최대 비율은 프로비저닝된 동시성별 초당 10개의 요청입니다. 예를 들어, 100 개의 프로비저닝된 동시성으로 구성된 함수는 초당 1,000개의 요청을 처리할 수 있습니다. 호출 비율이 초당 1,000개의 요청을 초과하면 일부 콜드 스타트가 발생할 수 있습니다. ## Lambda: 새 버전으로 콜드 스타트 **문제:** *함수의 새 버전을 배포하는 동안 콜드 스타트가 나타납니다.* 함수 별칭을 업데이트하면 Lambda는 별칭에 구성된 가중치를 기반으로 프로비저닝된 동시성을 새 버전으로 자동으로 이동시킵니다. **오류:** *KMSDisabledException: 사용된 KMS 키가 비활성화되어 있으므로 Lambda에서 환경 변수의 암호화를 해제할 수 없음. 해당 함수의 KMS 키 설정을 확인해야 함* AWS Key Management Service(AWS KMS) 키가 비활성화되어 있거나 Lambda에서 이 키를 사용할 수 있도록 하는 권한 부여가 취소된 경우 이 오류가 발생할 수 있습니다. 권한 부여가 누락된 경우 다른 키를 사용하도록 함수를 구성합니다. 그런 다음 사용자 지정 키를 다시 할당하여 권한 부여를 다시 만듭니다. ## Lambda: 런타임에서 예기치 않은 Node.js 종료(Runtime.NodejsExit) **문제:** *Lambda 런타임 클라이언트가 예기치 않은 Node.js 종료 코드를 감지했습니다.* 이 오류는 코드 버그 등으로 인해 모든 Promise가 확정되기 전에 함수가 종료될 때 발생합니다. 또한 Node.js가 Promise가 확정되지 않는 교착 상태를 감지할 때도 발생할 수 있습니다. 이 오류는 콜백 스타일 핸들러가 아닌 비동기 스타일 핸들러에만 영향을 미칩니다. **영향을 받는 런타임:** Node.js 18 이상. **이 문제를 해결하는 방법:** 1. 비동기 핸들러에서 함수 코드에 확정되지 않은 Promise가 있는지 확인합니다. 1. 함수가 완료되기 전에 모든 Promise가 제대로 확정(해결 또는 거부)되었는지 확인합니다. 1. 코드를 검토하여 비동기 작업의 잠재적 경합 조건을 확인합니다. Node.js 종료 코드 및 프로세스 종료에 대한 자세한 내용은 [Node.js 설명서](https://nodejs.org/docs/latest/api/process.html#exit-codes)를 참조하세요. ## EFS: 함수가 EFS 파일 시스템을 마운트할 수 없음 **오류:** *EFSMountFailureException: 이 함수는 액세스 포인트 arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd를 사용하여 EFS 파일 시스템을 마운트할 수 없습니다.* 함수의 [파일 시스템](configuration-filesystem.md)에 대한 마운트 요청이 거부되었습니다. 함수의 권한을 확인하고 해당 파일 시스템 및 액세스 포인트가 존재하며 사용할 준비가 되었는지 확인합니다. ## EFS: 함수가 EFS 파일 시스템에 연결할 수 없음 **오류**: *EFSMountConnectivityException: 이 함수는 액세스 포인트 arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd를 사용하여 Amazon EFS 파일 시스템에 연결할 수 없습니다. 네트워크 구성을 확인하고 다시 시도하세요.* 함수가 NFS 프로토콜(TCP 포트 2049)을 사용하여 함수의 [파일 시스템](configuration-filesystem.md)에 대한 연결을 설정할 수 없습니다. VPC 서브넷에 대한 [보안 그룹 및 라우팅 구성](https://docs.aws.amazon.com/efs/latest/ug/network-access.html)을 확인합니다. 함수의 VPC 구성 설정을 업데이트한 후 이러한 오류가 발생하면 파일 시스템을 탑재 해제했다가 다시 탑재해 봅니다. ## EFS: 시간 초과로 인해 함수가 EFS 파일 시스템을 마운트할 수 없음 **오류:** *EFSMountTimeoutException: 이 함수는 마운트 시간 초과로 인해 액세스 포인트 \$1arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd\$1를 사용하여 EFS 파일 시스템을 마운트할 수 없습니다.* 함수가 함수의 [파일 시스템](configuration-filesystem.md)에 연결할 수 있었지만 마운트 작업 시간이 초과되었습니다. 잠시 후 다시 시도를 하고, 함수의 [동시성](configuration-concurrency.md)을 제한하여 파일 시스템의 부하를 줄이기 방법을 고려합니다. ## Lambda: Lambda가 시간이 너무 오래 걸리는 IO 프로세스를 탐지함 *EFSIOException: Lambda가 너무 오래 걸리는 IO 프로세스를 탐지했기 때문에 이 함수 인스턴스가 중지되었습니다.* 이전 호출이 시간 초과되어 Lambda가 함수 핸들러를 종료할 수 없었습니다. 이 문제는 연결된 파일 시스템에 버스트 크레딧이 부족하여 기본 처리량이 충분하지 않은 경우에 발생할 수 있습니다. 처리량을 늘리려면 파일 시스템의 크기를 늘리거나 프로비저닝된 처리량을 사용할 수 있습니다. ## 컨테이너: CodeArtifactUserException 오류 **오류:** **CodeArtifactUserPendingException 오류 메시지 CodeArtifact가 최적화를 보류 중입니다. Lambda가 최적화를 완료하면 함수가 [활성 상태](functions-states.md)로 전환됩니다. HTTP 응답 코드: 409 **오류:** **CodeArtifactUserDeletedException 오류 메시지 CodeArtifact가 삭제되도록 예약되어 있습니다. HTTP 응답 코드: 409 **오류:** **CodeArtifactUserFailedException 오류 메시지 Lambda가 코드를 최적화하지 못했습니다. 코드를 수정하고 다시 업로드해야 합니다. HTTP 응답 코드: 409 ## 컨테이너: InvalidEntrypoint 오류 **오류:** **Runtime.ExitError 또는 'errorType': 'Runtime.InvalidEntrypoint' 컨테이너 이미지의 ENTRYPOINT에 절대 경로가 위치로 포함되어 있는지 확인합니다. 또한 이미지에 symlink가 ENTRYPOINT로 포함되어 있지 않은지 확인합니다. **오류:** *CloudFormation 템플릿을 사용하고 있으며 컨테이너 ENTRYPOINT가 null 또는 빈 값으로 재정의됩니다.* CloudFormation 템플릿에서 [ImageConfig](https://docs.aws.amazon.com/AWSCloudFormation/latest/TemplateReference/aws-properties-lambda-function-imageconfig.html) 리소스를 검토합니다. 템플릿에서 `ImageConfig` 리소스를 선언하는 경우 세 가지 속성 모두에 비어 있지 않은 값을 제공해야 합니다. # Lambda의 실행 문제 해결 Lambda 런타임에서 함수 코드를 실행하면 이벤트가 일정 시간 동안 처리 중인 함수의 인스턴스에서 처리되거나 새 인스턴스를 초기화해야 할 수 있습니다. 함수 초기화 동안 핸들러 코드가 이벤트를 처리할 때 또는 함수가 응답을 반환하거나 반환하지 않을 때 오류가 발생할 수 있습니다. 함수 실행 오류는 코드, 함수 구성, 다운스트림 리소스 또는 권한 문제로 인해 발생할 수 있습니다. 함수를 직접 간접 호출하면 Lambda의 응답에 함수 오류가 표시됩니다. 이벤트 소스 매핑으로 또는 다른 서비스를 통해 함수를 비동기적으로 간접 호출하는 경우 로그, Dead Letter Queue(DLQ) 또는 on-failure 대상에 오류가 있을 수 있습니다. 오류 처리 옵션 및 재시도 동작은 함수를 간접 호출하는 방법과 오류 유형에 따라 다릅니다. 함수 코드 또는 Lambda 런타임에서 오류를 반환하면 Lambda의 응답에서 상태 코드는 200 OK입니다. 응답에 오류가 있으면 `X-Amz-Function-Error`라는 헤더로 표시됩니다. 400 및 500 시리즈 상태 코드는 [호출 오류](troubleshooting-invocation.md)에 예약되어 있습니다. **Topics** + [Lambda: Visual Studio Code를 사용한 원격 디버깅](#troubleshooting-execution-remote-debugging) + [Lambda: 실행 시간이 너무 오래 걸림](#troubleshooting-execution-toolong) + [Lambda: 예상치 못한 이벤트 페이로드](#troubleshooting-execution-unexpected-payload) + [Lambda: 예기치 않게 큰 페이로드 크기](#troubleshooting-execution-large-payload) + [Lambda: JSON 인코딩 및 디코딩 오류](#troubleshooting-execution-json-encoding) + [Lambda: 로그 또는 추적이 나타나지 않음](#troubleshooting-execution-logstraces) + [Lambda: 일부 함수 로그가 표시되지 않음](#troubleshooting-execution-missinglogs) + [Lambda: 실행이 완료되기 전에 함수가 반환됨](#troubleshooting-execution-unfinished) + [Lambda: 의도하지 않은 함수 버전 또는 별칭 실행](#unintended-function) + [Lambda: 무한 루프 감지](#infinite-loops) + [일반: 다운스트림 서비스 사용 불가](#downstream-unavailability) + [AWS SDK: 버전 및 업데이트](#troubleshooting-execution-versions) + [Python: 라이브러리가 잘못 로드됨](#troubleshooting-execution-libraries) + [Java: Java 11에서 Java 17로 업데이트한 후 함수가 이벤트를 처리하는 데 시간이 더 오래 걸립니다.](#troubleshooting-execution-java-perf) + [Kafka: 오류 처리 및 구성 문제 재시도](#troubleshooting-kafka-error-handling) ## Lambda: Visual Studio Code를 사용한 원격 디버깅 **문제:** *실제 AWS 환경에서 복잡한 Lambda 함수 동작을 해결하기 어려움* Lambda가 AWS Toolkit for Visual Studio Code을 통해 원격 디버깅 기능을 제공합니다. 설정 및 일반 지침은 [Visual Studio Code를 사용하여 Lambda 함수를 원격으로 디버깅](debugging.md) 섹션을 참조하세요. 문제 해결, 고급 사용 사례, 리전 가용성에 대한 자세한 지침은 AWS Toolkit for Visual Studio Code 사용자 가이드의 [Remote debugging Lambda functions](https://docs.aws.amazon.com/toolkit-for-vscode/latest/userguide/lambda-remote-debug.html)를 참조하세요. ## Lambda: 실행 시간이 너무 오래 걸림 **문제:** *함수 실행에 너무 많은 시간이 소요됩니다.* 코드가 로컬 시스템보다 Lambda에서 실행하는 데 더 오래 걸리는 경우, 함수에 사용할 수 있는 메모리 또는 처리 성능으로 인해 제한될 수 있습니다. 메모리와 CPU를 모두 관리하려면 [추가 메모리를 사용하여 함수를 구성](configuration-memory.md)하세요. ## Lambda: 예상치 못한 이벤트 페이로드 **문제:** *잘못된 JSON 또는 부적절한 데이터 검증과 관련된 함수 오류입니다.* 모든 Lambda 함수는 핸들러의 첫 번째 파라미터에서 이벤트 페이로드를 수신합니다. 이벤트 페이로드는 배열 및 중첩된 요소를 포함할 수 있는 JSON 구조입니다. JSON 구조 확인을 위한 강력한 프로세스를 사용하지 않는 업스트림 서비스에서 제공하는 경우 잘못된 JSON이 나타날 수 있습니다. 이 오류는 서비스가 새니타이징 처리되지 않은 사용자 입력을 포함하거나 텍스트 문자열을 연결하는 경우 발생합니다. 또한 JSON은 서비스 사이에서 전달하기 위해 자주 직렬화됩니다. 항상 JSON 구조를 JSON의 생산자 및 소비자로 구문 분석하여 해당 구조가 유효한지 확인합니다. 마찬가지로 이벤트 페이로드에서 값의 범위를 확인하지 않은 경우에도 오류가 발생할 수 있습니다. 이 예제에서는 원천징수를 계산하는 함수를 보여줍니다. ``` exports.handler = async (event) => { let pct = event.taxPct let salary = event.salary // Calculate % of paycheck for taxes return (salary * pct) } ``` 이 함수는 이벤트 페이로드에서 급여 및 세율을 사용하여 계산을 수행합니다. 그러나 이 코드에서는 속성이 존재하는지 확인하지 못합니다. 또한 데이터 유형을 확인하거나 세율이 0\$11인지 확인하는 등 경계도 확인하지 못합니다. 따라서 이러한 경계를 벗어난 값이 터무니 없는 결과를 생성합니다. 잘못된 유형이나 누락된 속성은 런타임 오류를 발생시킵니다. 함수가 더 큰 페이로드 크기를 처리하는지 확인하기 위해 테스트를 생성합니다. Lambda 이벤트 페이로드의 최대 크기는 1MB입니다. 콘텐츠에 따라 페이로드가 클수록 함수로 전달되는 항목이 많아지거나 JSON 속성에 포함되는 바이너리 데이터가 늘어날 수 있습니다. 두 경우 모두 Lambda 함수에 대한 처리가 늘어날 수 있습니다. 페이로드가 클수록 제한 시간이 초과될 수도 있습니다. 예를 들어 Lambda 함수에서 100밀리초당 하나의 레코드를 처리하고 제한 시간은 3초입니다. 페이로드에서 0\$129개의 항목에 대한 처리는 성공했습니다. 그러나 페이로드에 30개가 넘는 항목이 포함되면 함수의 제한 시간이 초과되고 오류가 발생합니다. 이를 방지하려면 예상되는 최대 항목 수에 대한 추가 처리 시간을 지원하도록 제한 시간이 설정되어 있는지 확인합니다. ## Lambda: 예기치 않게 큰 페이로드 크기 **문제:** *대용량 페이로드로 인해 함수가 시간 초과되거나 오류가 발생합니다.* 페이로드가 클수록 제한 시간이 초과되거나 오류가 발생할 수 있습니다. 함수가 가장 큰 예상 페이로드를 처리할 수 있는지 확인하기 위한 테스트를 생성하고 함수 제한 시간이 올바르게 설정되었는지 확인하는 것이 좋습니다. 또한 특정 이벤트 페이로드가 다른 리소스에 대한 포인터를 포함할 수 있습니다. 예를 들어 메모리가 128MB인 Lambda 함수는 S3에 객체로 저장된 JPG 파일에 대한 이미지 처리를 수행할 수 있습니다. 함수는 더 작은 이미지 파일에서 예상대로 작동합니다. 그러나 더 큰 JPG 파일이 입력으로 제공되면 메모리 부족으로 인해 Lambda 함수에서 오류가 발생합니다. 이를 방지하려면 테스트 사례에 예상 데이터 크기 상한의 예가 포함되어야 합니다. 코드는 페이로드 크기도 검증해야 합니다. ## Lambda: JSON 인코딩 및 디코딩 오류 **문제:** *JSON 입력을 구문 분석할 때 NoSuchKey 예외가 발생합니다.* JSON 속성을 올바르게 처리하고 있는지 확인합니다. 예를 들어 S3에서 생성된 이벤트의 경우 `s3.object.key` 속성에는 URL로 인코딩된 객체 키 이름이 포함됩니다. 많은 함수가 이 속성을 텍스트로 처리하여 참조된 S3 객체를 로드합니다. **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: event.Records[0].s3.object.key }).promise() ``` 이 코드는 `james.jpg`의 키 이름과 함께 작동하지만 이름이 `james beswick.jpg`이면 `NoSuchKey` 오류가 발생합니다. URL 인코딩은 키 이름에서 공백 및 기타 문자를 변환하므로 이 데이터를 사용하기 전에 함수에서 키를 디코딩해야 합니다. **Example** ``` const originalText = await s3.getObject({ Bucket: event.Records[0].s3.bucket.name, Key: decodeURIComponent(event.Records[0].s3.object.key.replace(/\+/g, " ")) }).promise() ``` ## Lambda: 로그 또는 추적이 나타나지 않음 **문제:** *CloudWatch Logs에 로그가 나타나지 않습니다.* **문제:** *추적이 AWS X-Ray에 나타나지 않습니다.* 함수는 CloudWatch Logs 및 X-Ray를 호출할 수 있는 권한이 필요합니다. 권한을 부여하려면 [실행 역할](lambda-intro-execution-role.md)을 업데이트하세요. 다음 관리형 정책을 추가하여 로그 및 추적을 활성화합니다. + **AWSLambdaBasicExecutionRole** + **AWSXRayDaemonWriteAccess** 함수에 권한을 추가할 때 코드나 구성에 대한 간단한 업데이트도 수행하세요. 그러면 자격 증명이 오래된 함수의 인스턴스 실행이 중지 및 대체됩니다. **참고** 함수 호출 후 로그가 표시되는 데 5\$110분 정도 걸릴 수 있습니다. ## Lambda: 일부 함수 로그가 표시되지 않음 **문제:** *권한이 올바른 경우에도 CloudWatch Logs에서 함수 로그가 누락됨* AWS 계정에서 [CloudWatch Logs 할당량 한도](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html)에 도달하면 CloudWatch는 함수 로깅을 제한합니다. 이 경우 함수가 출력하는 일부 로그는 CloudWatch Logs에 표시되지 않을 수 있습니다. 함수의 로그 출력 속도가 높아 Lambda에서 처리할 수 없는 경우에도 CloudWatch Logs에 로그 출력이 나타나지 않을 수 있습니다. Lambda에서 함수의 로그 생성 속도에 맞춰 CloudWatch로 로그를 전송할 수 없는 경우 로그를 삭제하여 함수 실행 속도가 느려지는 것을 방지합니다. 단일 로그 스트림의 로그 처리량이 2MB/s를 초과할 경우 삭제된 로그를 지속적으로 관찰해야 합니다. 함수가 [JSON 형식의 로그](monitoring-cloudwatchlogs-logformat.md)를 사용하도록 구성된 경우 Lambda는 로그를 삭제하면 CloudWatch Logs에 [`logsDropped`](telemetry-schema-reference.md#platform-logsDropped) 이벤트를 보내려고 합니다. 하지만 CloudWatch가 함수의 로깅을 제한하면 해당 이벤트가 CloudWatch Logs에 도달하지 않을 수 있으므로 Lambda가 로그를 삭제할 때 레코드가 항상 표시되는 것은 아닙니다. AWS 계정에서 CloudWatch Logs 할당량 한도에 도달했는지 확인하려면 다음을 수행합니다. 1. [Service Quotas 콘솔](https://console.aws.amazon.com/servicequotas)을 엽니다. 1. 탐색 창에서 **AWS 서비스**를 선택합니다. 1. **AWS 서비스 목록**에서 Amazon CloudWatch Logs를 검색합니다. 1. **서비스 할당량** 목록에서 `CreateLogGroup throttle limit in transactions per second`, `CreateLogStream throttle limit in transactions per second`, `PutLogEvents throttle limit in transactions per second` 할당량을 선택하여 사용률을 확인합니다. 또한 계정 사용률이 이러한 할당량에 지정한 한도를 초과할 경우 알리도록 CloudWatch 경보를 설정할 수 있습니다. 자세한 내용은 [정적 임곗값을 기반으로 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)을 참조하세요. CloudWatch Logs의 기본 할당량 한도가 사용 사례에 충분하지 않은 경우 [할당량 증가를 요청](https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html)할 수 있습니다. ## Lambda: 실행이 완료되기 전에 함수가 반환됨 **문제: (Node.js)** *코드 실행을 완료하기 전에 함수가 반환됨* AWS SDK를 포함하는 많은 라이브러리가 비동기적으로 작동합니다. 네트워크를 호출하거나 응답을 기다려야 하는 다른 작업을 수행할 때 라이브러리는 백그라운드에서 작업의 진행 상황을 추적하는 promise라는 객체를 반환합니다. promise가 응답으로 확인될 때까지 기다리려면 `await` 키워드를 사용하세요. 이렇게 하면 promise가 응답을 포함하는 객체로 확인될 때까지 핸들러 코드가 실행되지 않습니다. 코드에서 응답의 데이터를 사용할 필요가 없으면 promise를 런타임에 직접 반환 할 수 있습니다. 일부 라이브러리는 promise를 반환하지 않지만, 반환하는 코드로 래핑될 수 있습니다. 자세한 내용은 [Node.js에서 Lambda 함수 핸들러 정의](nodejs-handler.md) 섹션을 참조하세요. ## Lambda: 의도하지 않은 함수 버전 또는 별칭 실행 **문제:** *함수 버전 또는 별칭이 간접 호출되지 않음* 콘솔에서 또는 AWS SAM을 사용하여 새 Lambda 함수를 게시할 때 최신 코드 버전은 `$LATEST`로 표시됩니다. 기본적으로 버전 또는 별칭을 지정하지 않은 간접 호출은 함수 코드의 `$LATEST` 버전을 자동으로 대상으로 지정합니다. 특정 함수 버전 또는 별칭을 사용하는 경우 이는 `$LATEST`와 더불어 변경할 수 없는 게시된 함수 버전입니다. 이러한 함수의 문제를 해결할 때에는 먼저 직접 호출자가 의도한 버전 또는 별칭을 간접적으로 호출했는지 확인하세요. 함수 로그를 확인하여 이 작업을 수행할 수 있습니다. 간접적으로 호출된 함수의 버전은 항상 START 로그 줄에 표시됩니다. ![\[디버깅 운영 그림 1\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-1.png) ## Lambda: 무한 루프 감지 **문제:** *Lambda 함수와 관련된 무한 루프 패턴* Lambda 함수에는 두 가지 유형의 무한 루프가 있습니다. 첫 번째는 함수 자체 내부에서 종료되지 않는 루프로 인해 발생합니다. 간접 호출은 함수가 시간 초과되는 경우에만 종료됩니다. 시간 초과를 모니터링한 다음 루프 동작을 수정하여 이를 파악할 수 있습니다. 루프의 두 번째 유형은 Lambda 함수 및 기타 AWS 리소스 간입니다. 이 유형은 S3 버킷과 같은 리소스의 이벤트에서 Lambda 함수를 간접 호출하는 경우 이후에 동일한 소스 리소스와 상호 작용하여 다른 이벤트를 트리거할 때 나타납니다. 그러면 함수가 다시 간접 호출되어 동일한 S3 버킷과 또 다른 상호 작용을 생성하는 식으로 반복됩니다. 이러한 유형의 루프는 Amazon SQS 대기열 및 DynamoDB 테이블을 비롯한 여러 가지 다양한 AWS 이벤트 소스로 인해 발생할 수 있습니다. [재귀 루프 감지](invocation-recursion.md)를 사용하여 이러한 패턴을 식별할 수 있습니다. ![\[디버깅 운영 그림 2\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-2.png) 소비 리소스와 동일하지 않은 리소스에 Lambda 함수가 쓰기 작업을 수행하도록 하면 이러한 루프를 방지할 수 있습니다. 데이터를 소비 리소스에 다시 게시해야 하는 경우 새 데이터가 동일한 이벤트를 트리거하지 않는지 확인하세요. 또는 [이벤트 필터링](invocation-eventfiltering.md)을 사용하세요. 예를 들어 다음은 S3 및 DynamoDB 리소스를 사용하는 무한 루프에 대해 제안된 두 가지 솔루션입니다. + 동일한 S3 버킷에 다시 쓰는 경우 이벤트 트리거와 다른 접두사 또는 접미사를 사용합니다. + 동일한 DynamoDB 테이블에 항목을 쓰는 경우 소비하는 Lambda 함수가 필터링할 수 있는 속성을 포함합니다. Lambda가 속성을 찾으면 다른 간접 호출이 발생하지 않습니다. ## 일반: 다운스트림 서비스 사용 불가 **문제:** *Lambda 함수가 의존하는 다운스트림 서비스를 사용할 수 없음* 타사 엔드포인트 또는 기타 다운스트림 리소스를 직접적으로 호출하는 Lambda 함수의 경우 서비스 오류와 제한 시간 초과를 처리할 수 있는지 확인하세요. 이러한 다운스트림 리소스는 응답 시간이 가변적이거나 서비스 중단으로 인해 사용하지 못하게 될 수 있습니다. 구현에 따라 이러한 다운스트림 오류는 Lambda 제한 시간 초과로 나타나거나 서비스의 오류 응답이 함수 코드 내에서 처리되지 않는 경우 예외로 나타날 수 있습니다. 함수가 API 직접 호출과 같은 다운스트림 서비스에 의존하는 경우 항상 적절한 오류 처리 및 재시도 로직을 구현하세요. 중요한 서비스의 경우 Lambda 함수는 지표 또는 로그를 CloudWatch에 게시해야 합니다. 예를 들어 서드파티 결제 API를 사용할 수 없게 되면 Lambda 함수에서 이 정보를 로깅할 수 있습니다. 그런 다음 CloudWatch 경보를 설정하여 해당 오류와 관련된 알림을 보낼 수 있습니다. Lambda 서비스는 빠르게 규모를 조정할 수 있으므로 서버리스가 아닌 다운스트림 서비스에서 트래픽 급증을 처리하는 데 어려움을 겪을 수 있습니다. 이를 처리하는 세 가지 일반적인 접근 방식이 있습니다. + **캐싱**-자주 변경되지 않는 경우 타사 서비스에서 반환한 값의 결과를 캐싱하는 것이 좋습니다. 함수의 전역 변수 또는 다른 서비스에 이러한 값을 저장할 수 있습니다. 예를 들어 Amazon RDS 인스턴스에서 제품 목록 쿼리의 결과는 중복 쿼리를 방지하기 위해 함수 내 일정 기간 저장할 수 있습니다. + **대기열**: – 데이터를 저장하거나 업데이트하는 경우 Lambda 함수와 리소스 사이에 Amazon SQS 대기열을 추가합니다. 다운스트림 서비스가 메시지를 처리하는 동안 대기열에서 지속적으로 데이터를 유지합니다. + **프록시** – Amazon RDS 인스턴스와 같이 일반적으로 장기 연결이 사용되는 경우 프록시 계층을 사용하여 이러한 연결을 풀링하고 재사용합니다. 관계형 데이터베이스의 경우 [Amazon RDS Proxy](https://github.com/aws-samples/s3-to-lambda-patterns/tree/master/docrepository)는 Lambda 기반 애플리케이션의 확장성 및 복원력을 개선하도록 설계된 서비스입니다. ## AWS SDK: 버전 및 업데이트 **문제:** *런타임에 포함된 AWS SDK가 최신 버전이 아님* **문제:** *런타임에 포함된 AWS SDK가 자동으로 업데이트됨* 해석된 언어의 런타임에는 AWS SDK 버전이 포함됩니다. Lambda는 최신 SDK 버전을 사용하도록 이러한 런타임을 주기적으로 업데이트합니다. 런타임에 포함된 SDK 버전을 확인하려면 다음 섹션을 참조하세요. + [런타임에 포함된 SDK 버전(Node.js)](lambda-nodejs.md#nodejs-sdk-included) + [런타임에 포함된 SDK 버전(Python)](lambda-python.md#python-sdk-included) + [런타임에 포함된 SDK 버전(Ruby)](lambda-ruby.md#ruby-sdk-included) 최신 버전의 AWS SDK를 사용하거나 함수를 특정 버전으로 잠그려면 라이브러리를 함수 코드와 번들로 묶거나 [Lambda 계층을 생성](chapter-layers.md)하면 됩니다. 종속성을 사용하여 배포 패키지를 만드는 방법에 대한 자세한 내용은 다음 항목을 참조하세요. ------ #### [ Node.js ] [.zip 파일 아카이브를 사용하여 Node.js Lambda 함수 배포](nodejs-package.md) ------ #### [ Python ] [Python Lambda 함수에 대한 .zip 파일 아카이브 작업](python-package.md) ------ #### [ Ruby ] [.zip 파일 아카이브를 사용하여 Ruby Lambda 함수 배포](ruby-package.md) ------ #### [ Java ] [.zip 또는 JAR 파일 아카이브를 사용하여 Java Lambda 함수 배포](java-package.md) ------ #### [ Go ] [.zip 파일 아카이브를 사용하여 Go Lambda 함수 배포](golang-package.md) ------ #### [ C\$1 ] [.zip 파일 아카이브를 사용하여 C\$1 Lambda 함수를 빌드 및 배포](csharp-package.md) ------ #### [ PowerShell ] [.zip 파일 아카이브를 사용하여 PowerShell Lambda 함수 배포](powershell-package.md) ------ ## Python: 라이브러리가 잘못 로드됨 **문제:** (Python) *일부 라이브러리는 배포 패키지에서 올바르게 로드되지 않음* C 또는 C\$1\$1로 작성된 확장 모듈이 있는 라이브러리는 Lambda(Amazon Linux)와 동일한 프로세서 아키텍처를 사용하는 환경에서 컴파일해야 합니다. 자세한 내용은 [Python Lambda 함수에 대한 .zip 파일 아카이브 작업](python-package.md) 섹션을 참조하세요. ## Java: Java 11에서 Java 17로 업데이트한 후 함수가 이벤트를 처리하는 데 시간이 더 오래 걸립니다. **문제:** (Java) *Java 11에서 Java 17로 업데이트한 후 함수가 이벤트를 처리하는 데 시간이 더 오래 걸림* `JAVA_TOOL_OPTIONS` 파라미터를 사용하여 컴파일러를 조정하세요. Java 17 이상의 Java 버전용 Lambda 런타임은 기본 컴파일러 옵션을 변경합니다. 이 변경으로 수명이 짧은 함수의 콜드 스타트 시간이 개선되지만 이전 동작은 계산 집약적이고 오래 실행되는 함수에 더 적합합니다. Java 11 동작으로 되돌리려면 `JAVA_TOOL_OPTIONS`를 `-XX:-TieredCompilation`으로 설정합니다. `JAVA_TOOL_OPTIONS` 파라미터에 대한 자세한 내용은 [`JAVA_TOOL_OPTIONS` 환경 변수에 대한 이해](java-customization.md#java-tool-options)를 참조하세요. ## Kafka: 오류 처리 및 구성 문제 재시도 **문제:** *Kafka 이벤트 소스 매핑이 재시도 설정 또는 실패 시 대상을 구성하지 못함* Kafka 재시도 구성 및 실패 시 대상은 프로비저닝 모드가 활성화된 이벤트 소스 매핑에만 사용할 수 있습니다. 재시도 구성을 설정하기 전에 `ProvisionedPollerConfig`에서 `MinimumPollers`를 구성해야 합니다. 일반 구성 오류: + **bisect 배치를 사용한 무한 재시도** – `MaximumRetryAttempts`가 -1(무한)로 설정된 경우 `BisectBatchOnFunctionError`를 활성화할 수 없습니다. 유한 재시도 제한을 설정하거나 bisect 배치를 비활성화합니다. + **동일한 주제 재귀** - Kafka 실패 시 대상 주제는 소스 주제와 같을 수 없습니다. 배달 못한 편지 주제에 대해 다른 주제 이름을 선택합니다. + **잘못된 Kafka 대상 형식** - Kafka 주제를 실패 시 대상으로 지정할 때 `kafka://` 형식을 사용합니다. + **kafka:WriteData 권한 문제** - 실행 역할에 대상 주제에 대한 `kafka-cluster:WriteData` 권한이 있어야 합니다. 주제에 제한 시간 예외가 없거나 쓰기 API 스로틀링 문제로 인해 계정 제한을 늘려야 할 수 있습니다. # Lambda의 이벤트 소스 매핑 문제 해결 [이벤트 소스 매핑](invocation-eventsourcemapping.md)과 관련된 Lambda의 문제는 여러 서비스에서의 디버깅을 포함하므로 더 복잡할 수 있습니다. 또한 이벤트 소스 동작은 정확히 어떤 이벤트 소스가 사용되었는지에 따라 달라질 수 있습니다. 이 섹션에서는 이벤트 소스 매핑과 관련된 일반적인 문제를 나열하고, 이를 식별하고 해결하는 방법에 대한 지침을 제공합니다. **참고** 이 섹션에서는 Amazon SQS 이벤트 소스를 예시로 사용하지만, 이 원칙은 Lambda 함수에 대한 메시지를 대기열에 추가하는 다른 이벤트 소스 매핑에도 적용됩니다. ## 스로틀링 식별 및 관리 Lambda에서 스로틀링은 함수 또는 계정의 동시성 한도에 도달하면 발생합니다. Amazon SQS 대기열에서 메시지를 읽는 Lambda 함수가 있는 다음 예제를 생각해 보겠습니다. 이 Lambda 함수는 30초 간접 호출을 시뮬레이션하며 배치 크기는 1입니다. 즉, 함수는 30초마다 1개의 메시지만 처리합니다. ``` const doWork = (ms) => new Promise(resolve => setTimeout(resolve, ms)) exports.handler = async (event) => { await doWork(30000) } ``` 간접 호출 시간이 길어지면 메시지가 처리되는 속도보다 더 빠르게 대기열에 도착하기 시작합니다. 계정의 예약되지 않은 동시성이 100인 경우 Lambda는 최대 100개의 동시 실행으로 스케일 업된 다음 스로틀링이 발생합니다. 함수에 대해 CloudWatch 지표에서 이 패턴을 볼 수 있습니다. ![\[디버깅 운영 그림 10\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-10.png) 함수에 대한 CloudWatch 지표에는 오류가 표시되지 않지만 **동시 실행** 차트에는 최대 동시성인 100에 도달한 것으로 표시됩니다. 따라서 **스로틀링** 차트는 스로틀링이 발생한 것을 보여줍니다. CloudWatch 경보를 사용하고 함수에 대한 스로틀링 지표가 0보다 클 때마다 경보를 설정하여 스로틀링을 감지할 수 있습니다. 스로틀링 문제를 파악한 후에는 몇 가지 해결 옵션이 있습니다. + 이 리전의 AWS Support에서 동시성 증가를 요청합니다. + 함수의 성능 문제를 식별하고 처리 속도를 개선하여 처리량을 개선합니다. + 함수의 배치 크기를 늘려 간접 호출할 때마다 더 많은 메시지가 처리되도록 합니다. ## 처리 함수에서의 오류 처리 함수에서 오류가 발생하면 Lambda는 메시지를 SQS 대기열로 반환합니다. Lambda는 함수의 규모 조정을 방지하여 대규모 오류를 방지합니다. CloudWatch의 다음 SQS 지표는 대기열 처리 관련 문제를 나타냅니다. ![\[디버깅 운영 그림 11\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-11.png) 특히 가장 오래된 메시지의 수명과 표시되는 메시지 수가 모두 늘어나는 반면, 삭제되는 메시지는 없습니다. 대기열은 계속 증가하지만 메시지는 처리되지 않습니다. Lambda 처리 함수에 대한 CloudWatch 지표에서도 문제가 있음을 나타냅니다. ![\[디버깅 운영 그림 12\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-12.png) **오류 수** 지표는 0이 아니고 증가하지만 **동시 실행**은 줄어들고 스로틀링은 중지됩니다. 이는 Lambda가 오류로 인해 함수 스케일 업을 중지했음을 보여줍니다. 함수의 CloudWatch 로그는 오류 유형에 대한 세부 정보를 제공합니다. 오류를 유발하는 함수를 식별한 다음, 오류를 찾아 해결함으로써 이 문제를 해결할 수 있습니다. 오류를 수정하고 새 함수 코드를 배포한 후에는 CloudWatch 지표에 처리 복구가 표시되어야 합니다. ![\[디버깅 운영 그림 13\]](http://docs.aws.amazon.com/ko_kr/lambda/latest/dg/images/debugging-ops-figure-13.png) 여기서 **오류 수** 지표는 0으로 감소하고 **성공률** 지표는 100%로 돌아갑니다. Lambda 서비스는 **동시 실행** 그래프에 표시된 것처럼 함수 스케일 업을 다시 시작합니다. ## 역압 식별 및 처리 이벤트 생산자가 Lambda 함수에서 처리할 수 있는 것보다 빠른 속도로 SQS 대기열에 대한 메시지를 지속적으로 생성하는 경우 역압이 발생합니다. 이 경우 SQS 모니터링에는 표시되는 대략적인 메시지 수와 함께 가장 오래된 메시지의 수명이 선형적으로 증가하는 것을 보여주어야 합니다. CloudWatch 경보를 사용하여 대기열의 역압을 감지할 수 있습니다. 역압을 해결하는 단계는 워크로드에 따라 달라집니다. Lambda 함수로 처리 능력 및 처리량을 높이는 것이 주요 목표인 경우 다음과 같은 몇 가지 옵션이 있습니다. + AWS Support에서 이 특정 리전의 동시성 증가를 요청합니다. + 함수의 배치 크기를 늘려 간접 호출할 때마다 더 많은 메시지가 처리되도록 합니다. # Lambda의 네트워킹 문제 해결 기본적으로 Lambda는 AWS 서비스 및 인터넷에 연결된 내부 가상 프라이빗 클라우드(VPC)에서 함수를 실행합니다. 로컬 네트워크 리소스에 액세스하려면 [계정의 VPC에 연결하도록 함수를 구성](configuration-vpc.md)할 수 있습니다. 이 기능을 사용하면 함수의 인터넷 액세스 및 Amazon Virtual Private Cloud(Amazon VPC) 리소스로의 네트워크 연결을 관리할 수 있습니다. 네트워크 연결 오류는 VPC의 라우팅 구성, 보안 그룹 규칙, AWS Identity and Access Management(IAM) 역할 권한 또는 네트워크 주소 변환(NAT) 문제로 야기되거나 IP 주소 또는 네트워크 인터페이스와 같은 리소스의 가용성 문제로 야기될 수 있습니다. 문제에 따라, 요청이 대상에 도달할 수 없는 경우 특정 오류나 시간 초과가 발생할 수 있습니다. **Topics** + [VPC: 함수가 인터넷 액세스를 잃거나 시간이 초과됨](#troubleshooting-networking-cfn) + [VPC: TCP 또는 UDP 연결이 간헐적으로 실패함](#troubleshooting-networking-tcp-udp) + [VPC: 함수에서 인터넷을 사용하지 않고 AWS 서비스에 액세스해야 함](#troubleshooting-networking-access) + [VPC: 탄력적 네트워크 인터페이스 한도에 도달](#troubleshooting-networking-limit) + [EC2: ‘lambda’ 유형 포함 탄력적 네트워크 인터페이스](#troubleshooting-networking-eni) + [DNS: 알 수 없는 호스트 예외가 있는 호스트에 연결하지 못했습니다.](#troubleshooting-networking-dns-tcp) ## VPC: 함수가 인터넷 액세스를 잃거나 시간이 초과됨 **문제:** *VPC 연결 후 Lambda 함수의 인터넷 액세스가 끊깁니다.* **오류:** *오류: connect ETIMEDOUT 176.32.98.189:443* **오류:** *오류: 10.00초 후 작업 시간 초과* **오류:** *ReadTimuTerror: 읽기 시간이 초과되었습니다.(읽기 시간 초과=15)* VPC에 함수를 연결하면 모든 아웃바운드 요청이 VPC를 통과합니다. 인터넷에 연결하려면 함수의 서브넷에서 퍼블릭 서브넷의 NAT 게이트웨이로 아웃바운드 트래픽을 보내도록 VPC를 구성합니다. 자세한 내용과 샘플 VPC 구성은 을 참조하세요[VPC 연결 Lambda 함수에 대한 인터넷 액세스 활성화](configuration-vpc-internet.md) 일부 TCP 연결이 시간 초과되면 서브넷에서 네트워크 액세스 제어 목록(NACL)을 사용하는 경우 [VPC: TCP 또는 UDP 연결이 간헐적으로 실패함](#troubleshooting-networking-tcp-udp)을 참조하세요. 그렇지 않은 경우 패킷 조각화 때문일 수 있습니다. Lambda는 TCP 또는 ICMP에 대한 IP 조각화를 지원하지 않으므로 Lambda 함수는 수신되는 조각화된 TCP 요청을 처리할 수 없습니다. ## VPC: TCP 또는 UDP 연결이 간헐적으로 실패함 **참고** 이 문제는 서브넷에서 [네트워크 액세스 제어 목록(ACL)](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-network-acls.html#nacl-basics)을 사용하는 경우에만 적용됩니다. Lambda가 서브넷에 연결하는 데 네트워크 ACL은 필요하지 않습니다. **문제:** *네트워크 액세스 제어 목록(ACL)을 구성한 VPC 서브넷에 대한 연결이 간헐적으로 끊어집니다.* VPC 지원 Lambda 함수의 경우 AWS는 고객 계정에 [하이퍼플레인 ENI](configuration-vpc.md#configuration-vpc-enis)를 생성하고 `1024`\$1`65535`의 임시 포트를 사용하여 Lambda를 고객의 VPC에 연결합니다. 대상 서브넷에서 네트워크 ACL을 사용하는 경우 TCP와 UDP 모두에 대해 `1024`\$1`65535`의 포트 범위를 허용해야 합니다. 이 전체 포트 범위를 허용하지 않으면 간헐적 연결 실패가 발생할 수 있습니다. ## VPC: 함수에서 인터넷을 사용하지 않고 AWS 서비스에 액세스해야 함 **문제:** *Lambda 함수에서 인터넷을 사용하지 않고 AWS 서비스에 액세스해야 합니다.* 인터넷에 액세스할 수 없는 프라이빗 서브넷에서 AWS 서비스에 함수를 연결하려면 VPC 엔드포인트를 사용합니다. ## VPC: 탄력적 네트워크 인터페이스 한도에 도달 **오류:** *ENILimitReachedException: 함수의 VPC의 탄력적 네트워크 인터페이스 한도에 도달했습니다.* Lambda 함수를 VPC에 연결하면 Lambda는 함수에 연결된 서브넷과 보안 그룹의 각 조합에 대해 탄력적 네트워크 인터페이스를 생성합니다. 기본 서비스 할당량은 VPC당 250개의 네트워크 인터페이스입니다. 할당량 증가를 요청하려면 [Service Quotas 콘솔](https://console.aws.amazon.com/servicequotas/home/services/lambda/quotas/L-9FEE3D26)을 사용합니다. ## EC2: ‘lambda’ 유형 포함 탄력적 네트워크 인터페이스 **오류 코드:**: *Client.OperationNotPermitted* **오류 메시지:** *The security group can not be modified for this type of interface* Lambda에서 관리하는 탄력적 네트워크 인터페이스(ENI)를 수정하려고 하면 이 오류가 발생합니다. Lambda에서 생성한 탄력적 네트워크 인터페이스의 업데이트 작업을 위한 Lambda API에는 `ModifyNetworkInterfaceAttribute`가 포함되어 있지 않습니다. ## DNS: 알 수 없는 호스트 예외가 있는 호스트에 연결하지 못했습니다. **오류 메시지:** *알 수 없는 호스트 예외* Lambda 함수는 DNS 문제 해결을 위해 최대 20개의 동시 TCP 연결을 지원합니다. 함수가 해당 한도를 다 사용하고 있을 수 있습니다. 대부분의 일반적인 DNS 요청은 UDP를 통해 이루어집니다. 함수가 UDP DNS 연결만 하는 경우에는 문제가 되지 않을 수 있습니다. 이 오류는 일반적으로 잘못된 구성이나 인프라 성능 저하로 인해 발생하므로 DNS 트래픽을 심층적으로 검사하기 전에 DNS 인프라가 제대로 구성되어 있고 정상인지, Lambda 함수가 DNS에 지정된 호스트를 참조하고 있는지 확인하십시오. 문제가 TCP 연결 최대값과 관련된 것으로 진단되는 경우 이 한도를 상향 조정하도록 하는 요청을 할 수 없다는 점에 유의하십시오. DNS 페이로드가 커서 Lambda 함수가 TCP DNS로 폴백되는 경우 솔루션이 EDNS를 지원하는 라이브러리를 사용하고 있는지 확인하십시오. EDNS에 대한 자세한 내용은 [RFC 6891 기준](https://datatracker.ietf.org/doc/html/rfc6891)을 참조하세요. DNS 페이로드가 지속적으로 EDNS 최대 크기를 초과할 경우, 솔루션은 계속해서 TCP DNS 한도를 소진할 수 있습니다.