Lambda 호출 문제 해결하기

Lambda 호출 문제 해결하기 (Troubleshoot invocation issues in Lambda)

Lambda 함수를 호출하면 Lambda가 요청을 검증하고 확장 용량을 확인한 뒤 이벤트를 함수로 보내거나(비동기 호출의 경우) 이벤트 큐로 보내요. 호출 오류는 요청 파라미터, 이벤트 구조, 함수 설정, 사용자 권한, 리소스 권한, 또는 한도 문제로 발생할 수 있어요.

함수를 직접 호출하면 Lambda의 응답에서 모든 호출 오류를 볼 수 있어요. 이벤트 소스 매핑이나 다른 서비스로 함수를 비동기 호출하면 로그, 데드 레터 큐, 또는 실패 이벤트 대상에서 오류를 찾을 수 있어요. 오류 처리 옵션과 재시도 동작은 함수를 호출하는 방식과 오류 유형에 따라 달라져요.

출처: AWS Lambda 개발자 안내서

본문

Lambda: Init 단계 중 함수 타임아웃 (Sandbox.Timedout)

오류: Task timed out after 3.00 seconds

Init 단계가 타임아웃되면 Lambda는 다음 호출 요청이 도착할 때 Init 단계를 다시 실행해 실행 환경을 재초기화해요. 이를 억제된 초기화(suppressed init)라고 해요. 하지만 함수가 짧은 타임아웃(보통 3초 안팎)으로 구성되어 있으면 억제된 초기화가 할당된 타임아웃 안에 완료되지 못해 Init 단계가 다시 타임아웃될 수 있어요. 또는 억제된 초기화는 완료되지만 Invoke 단계가 완료될 시간이 충분하지 않아 Invoke 단계가 타임아웃될 수 있어요.

타임아웃 오류를 줄이려면 다음 전략 중 하나 이상을 사용하세요.

함수 타임아웃을 늘립니다 – Init와 Invoke 단계가 성공적으로 완료될 시간을 주도록 타임아웃을 연장합니다.
함수 메모리 할당을 늘립니다 – 메모리를 더 추가하면 CPU 할당도 비례해 늘어나 Init와 Invoke 단계를 모두 빠르게 할 수 있습니다.
함수 초기화 코드를 최적화합니다 – 구성된 타임아웃 안에 Init와 Invoke 단계를 완료할 수 있도록 초기화에 필요한 시간을 줄입니다.

IAM: lambda:InvokeFunction 권한 없음

오류: User: arn:aws:iam::123456789012:user/developer is not authorized to perform: lambda:InvokeFunction on resource: my-function

사용자 또는 수임한 역할에 함수 호출 권한이 있어야 해요. 이 요구 사항은 함수를 호출하는 Lambda 함수와 기타 컴퓨팅 리소스에도 적용돼요. 사용자에게 AWS 관리 정책 AWSLambdaRole을 추가하거나, 대상 함수에서 lambda:InvokeFunction 액션을 허용하는 커스텀 정책을 추가하세요.

참고

IAM 액션 이름(lambda:InvokeFunction)은 Invoke Lambda API 작업을 가리켜요.

Lambda: 유효한 bootstrap을 찾을 수 없음 (Runtime.InvalidEntrypoint)

오류: Couldn't find valid bootstrap(s): [/var/task/bootstrap /opt/bootstrap]

이 오류는 배포 패키지의 루트에 bootstrap이라는 실행 가능한 파일이 없을 때 발생하는 경우가 많아요. 예를 들어 provided.al2023 함수를 .zip 파일로 배포한다면 bootstrap 파일이 디렉토리가 아니라 .zip 파일의 루트에 있어야 해요.

Lambda: 작업을 수행할 수 없음 ResourceConflictException

오류: ResourceConflictException: The operation cannot be performed at this time. The function is currently in the following state: Pending

함수를 만들 때 함수를 가상 프라이빗 클라우드(VPC)에 연결하면 Lambda가 탄력적 네트워크 인터페이스를 만드는 동안 함수가 Pending 상태가 돼요. 이 동안 함수를 호출하거나 수정할 수 없어요. 생성 후 함수를 VPC에 연결하면 업데이트가 대기 중인 동안 함수를 호출할 수 있지만 코드나 구성을 수정할 수는 없어요.

Lambda: 함수가 Pending에 멈춤

오류: 함수가 몇 분 동안 Pending 상태에 멈춤.

함수가 6분 이상 Pending 상태에 멈춰 있으면 다음 API 작업 중 하나를 호출해 차단을 해제하세요.

UpdateFunctionCode
UpdateFunctionConfiguration
PublishVersion

Lambda가 대기 중인 작업을 취소하고 함수를 Failed 상태로 둬요. 그런 다음 다른 업데이트를 시도할 수 있어요.

Lambda: 한 함수가 모든 동시성을 사용 중

문제: 한 함수가 모든 가용 동시성을 사용해 다른 함수가 스로틀되고 있음.

AWS 리전의 계정 가용 동시성을 풀로 나누려면 reserved concurrency를 사용하세요. reserved concurrency는 함수가 항상 할당된 동시성까지 확장되고, 할당된 동시성을 넘어 확장되지 않도록 보장해요.

일반: 다른 계정이나 서비스로 함수를 호출할 수 없음

문제: 함수를 직접 호출할 수 있는데, 다른 서비스나 계정이 호출하면 실행되지 않음.

함수의 리소스 기반 정책에서 다른 서비스와 계정에 함수 호출 권한을 부여해요. 호출자가 다른 계정에 있다면 그 사용자에게도 함수 호출 권한이 있어야 해요.

일반: 함수 호출이 루프 중

문제: 함수가 연속적으로 루프로 호출되고 있음.

이는 보통 함수가 자신을 트리거하는 것과 같은 AWS 서비스의 리소스를 관리할 때 발생해요. 예를 들어 함수를 다시 호출하는 알림이 구성된 Amazon Simple Storage Service(Amazon S3) 버킷에 객체를 저장하는 함수를 만들 수 있어요. 함수 실행을 멈추려면 가용 동시성을 0으로 줄여 향후 모든 호출을 스로틀하세요.

그런 다음 재귀 호출을 일으킨 코드 경로나 구성 오류를 식별하세요. Lambda는 일부 AWS 서비스와 SDK에서 재귀 루프를 자동으로 감지하고 중지해요.

Lambda: provisioned concurrency가 있는 별칭 라우팅

문제: 별칭 라우팅 중 provisioned concurrency 스필오버 호출.

Lambda는 두 함수 버전 사이의 트래픽을 분배하는 데 간단한 확률적 모델을 사용해요. 낮은 트래픽 수준에서는 각 버전의 구성된 트래픽 비율과 실제 비율 사이에 높은 분산이 보일 수 있어요. 함수가 provisioned concurrency를 사용한다면 별칭 라우팅이 활성화된 동안 더 많은 수의 provisioned concurrency 인스턴스를 구성해 스필오버 호출을 피할 수 있어요.

Lambda: provisioned concurrency로 인한 콜드 스타트

문제: provisioned concurrency를 활성화한 후 콜드 스타트가 보임.

함수의 동시 실행 수가 구성된 provisioned concurrency 수준보다 작거나 같으면 콜드 스타트가 없어야 해요. provisioned concurrency가 정상 작동하는지 확인하려면 다음을 수행하세요.

함수 버전이나 별칭에서 provisioned concurrency가 활성화되어 있는지 확인합니다.

참고

provisioned concurrency는 함수의 미게시 버전($LATEST)에서는 구성할 수 없어요.
트리거가 올바른 함수 버전이나 별칭을 호출하는지 확인합니다. 예를 들어 Amazon API Gateway를 사용한다면 API Gateway가 $LATEST가 아니라 provisioned concurrency가 있는 함수 버전이나 별칭을 호출하는지 확인합니다. 사용 중인지 확인하려면 ProvisionedConcurrencyInvocations Amazon CloudWatch 지표를 확인할 수 있는데, 값이 0이 아니면 함수가 초기화된 실행 환경에서 호출을 처리하고 있다는 뜻입니다.
ProvisionedConcurrencySpilloverInvocations CloudWatch 지표를 확인해 함수 동시성이 구성된 provisioned concurrency 수준을 초과하는지 판단합니다. 값이 0이 아니면 모든 provisioned concurrency가 사용 중이고 일부 호출이 콜드 스타트로 발생했다는 뜻입니다.
호출 빈도(초당 요청 수)를 확인합니다. provisioned concurrency가 있는 함수는 provisioned concurrency 1개당 초당 최대 10개 요청 한도가 있습니다. 예를 들어 100개의 provisioned concurrency로 구성된 함수는 초당 1,000개 요청을 처리할 수 있습니다. 호출률이 초당 1,000개 요청을 초과하면 일부 콜드 스타트가 발생할 수 있습니다.

Lambda: 새 버전으로 인한 콜드 스타트

문제: 함수의 새 버전을 배포하는 동안 콜드 스타트가 보임.

함수 별칭을 업데이트하면 Lambda는 별칭에 구성된 가중치에 따라 provisioned concurrency를 새 버전으로 자동 이동해요.

오류: KMSDisabledException: Lambda was unable to decrypt the environment variables because the KMS key used is disabled. Please check the function's KMS key settings.

이 오류는 AWS Key Management Service(AWS KMS) 키가 비활성화되었거나 Lambda가 키를 사용할 수 있게 하는 grant가 해지된 경우 발생할 수 있어요. grant가 없으면 함수가 다른 키를 사용하도록 구성하세요. 그런 다음 커스텀 키를 다시 할당해 grant를 다시 만들어요.

Lambda: 런타임에서 예기치 않은 Node.js 종료 (Runtime.NodejsExit)

문제: Lambda 런타임 클라이언트가 예기치 않은 Node.js 종료 코드를 감지함.

이 오류는 함수가 모든 Promise가 settled되기 전에 종료될 때 발생해요. 예를 들어 코드 버그 때문일 수 있어요. Node.js가 Promise가 settled되는 것을 막는 데드락을 감지할 때도 발생할 수 있어요. 이 오류는 async 스타일 핸들러에만 영향을 주고 콜백 스타일 핸들러에는 영향을 주지 않아요.

영향을 받는 런타임: Node.js 18 이상.

이 문제를 해결하려면:

async 핸들러에서 unsettled promise가 있는지 함수 코드를 확인합니다.
함수가 완료되기 전에 모든 promise가 제대로 settled(해결 또는 거부)되도록 합니다.
비동기 작업에서 잠재적 경쟁 조건이 있는지 코드를 검토합니다.

EFS: 함수가 EFS 파일 시스템을 마운트할 수 없음

오류: EFSMountFailureException: The function could not mount the EFS file system with access point arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd.

함수의 파일 시스템에 대한 마운트 요청이 거부되었어요. 함수의 권한을 확인하고, 파일 시스템과 access point가 존재하고 사용 준비가 되었는지 확인하세요.

EFS: 함수가 EFS 파일 시스템에 연결할 수 없음

오류: EFSMountConnectivityException: The function couldn't connect to the Amazon EFS file system with access point arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd. Check your network configuration and try again.

함수가 NFS 프로토콜(TCP 포트 2049)로 함수의 파일 시스템에 연결을 설정할 수 없었어요. VPC 서브넷의 보안 그룹과 라우팅 구성을 확인하세요. 함수의 VPC 구성 설정을 업데이트한 후 이런 오류가 발생하면 파일 시스템을 마운트 해제하고 다시 마운트해 보세요.

EFS: 타임아웃으로 함수가 EFS 파일 시스템을 마운트할 수 없음

오류: EFSMountTimeoutException: The function could not mount the EFS file system with access point {arn:aws:elasticfilesystem:us-east-2:123456789012:access-point/fsap-015cxmplb72b405fd} due to mount time out.

함수는 함수의 파일 시스템에 연결할 수 있었지만 마운트 작업이 타임아웃됐어요. 잠시 후 다시 시도하고, 파일 시스템의 부하를 줄이기 위해 함수의 동시성을 제한하는 것을 고려하세요.

S3 Files: 함수가 S3 파일 시스템을 마운트할 수 없음

오류: S3FilesMountFailureException: The function could not mount the Amazon S3 file system with access point arn:aws:s3files:us-east-2:123456789012:access-point/fsap-123456789abcde.

S3 Files: 함수가 S3 파일 시스템에 연결할 수 없음

오류: S3FilesMountConnectivityException: The function couldn't connect to the Amazon S3 file system with access point arn:aws:s3files:us-east-2:123456789012:access-point/fsap-123456789abcde. Check your network configuration and try again.

S3 Files: 타임아웃으로 함수가 S3 파일 시스템을 마운트할 수 없음

오류: S3FilesMountTimeoutException: The function could not mount the S3 file system with access point {arn:aws:s3files:us-east-2:123456789012:access-point/fsap-123456789abcde} due to mount time out.

Lambda: 너무 오래 걸리는 IO 프로세스 감지

오류: EFSIOException: This function instance was stopped because Lambda detected an IO process that was taking too long.

이전 호출이 타임아웃됐고 Lambda가 함수 핸들러를 종료할 수 없었어요. 이 문제는 연결된 파일 시스템의 버스트 크레딧이 소진되고 기준 처리량이 충분하지 않을 때 발생할 수 있어요. 처리량을 늘리려면 파일 시스템 크기를 늘리거나 provisioned throughput을 사용하세요.

컨테이너: CodeArtifactUserException 오류

CodeArtifactUserPendingException – CodeArtifact가 최적화 대기 중입니다. Lambda가 최적화를 완료하면 함수가 Active 상태로 전환됩니다. HTTP 응답 코드 409.
CodeArtifactUserDeletedException – CodeArtifact가 삭제 예정입니다. HTTP 응답 코드 409.
CodeArtifactUserFailedException – Lambda가 코드를 최적화하지 못했습니다. 코드를 수정하고 다시 업로드해야 합니다. HTTP 응답 코드 409.

컨테이너: InvalidEntrypoint 오류

오류: Runtime.ExitError 또는 "errorType": "Runtime.InvalidEntrypoint"

컨테이너 이미지의 ENTRYPOINT가 절대 경로를 위치로 포함하는지 확인하세요. 또한 이미지가 ENTRYPOINT로 심볼릭 링크를 포함하지 않는지 확인하세요.

오류: CloudFormation 템플릿을 사용 중이고 컨테이너 ENTRYPOINT가 null 또는 빈 값으로 덮어쓰여지고 있음.

CloudFormation 템플릿의 ImageConfig 리소스를 검토하세요. 템플릿에서 ImageConfig 리소스를 선언한다면 세 속성 모두에 비어 있지 않은 값을 제공해야 해요.

Lambda 호출 문제 해결하기