Lambda 런타임에서 함수 코드를 실행하면 이벤트가 일정 시간 동안 처리 중인 함수의 인스턴스에서 처리되거나 새 인스턴스를 초기화해야 할 수 있습니다. 함수 초기화 동안 핸들러 코드가 이벤트를 처리할 때 또는 함수가 응답을 반환하거나 반환하지 않을 때 오류가 발생할 수 있습니다.
함수 실행 오류는 코드, 함수 구성, 다운스트림 리소스 또는 권한 문제로 인해 발생할 수 있습니다. 함수를 직접 간접 호출하면 Lambda의 응답에 함수 오류가 표시됩니다. 이벤트 소스 매핑으로 또는 다른 서비스를 통해 함수를 비동기적으로 간접 호출하는 경우 로그, 배달 못한 편지 대기열 또는 on-failure 대상에 오류가 있을 수 있습니다. 오류 처리 옵션 및 재시도 동작은 함수를 간접 호출하는 방법과 오류 유형에 따라 다릅니다.
함수 코드 또는 Lambda 런타임에서 오류를 반환하면 Lambda의 응답에서 상태 코드는 200 OK입니다. 응답에 오류가 있으면 X-Amz-Function-Error라는 헤더로 표시됩니다. 400 및 500 시리즈 상태 코드는 호출 오류에 예약되어 있습니다.
Lambda: 실행 시간이 너무 오래 걸림
문제: 함수 실행에 너무 많은 시간이 소요됩니다.
코드가 로컬 시스템보다 Lambda에서 실행하는 데 더 오래 걸리는 경우, 함수에 사용할 수 있는 메모리 또는 처리 성능으로 인해 제한될 수 있습니다. 메모리와 CPU를 모두 관리하려면 추가 메모리를 사용하여 함수를 구성하세요.
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~1인지 확인하는 등 경계도 확인하지 못합니다. 따라서 이러한 경계를 벗어난 값이 터무니 없는 결과를 생성합니다. 잘못된 유형이나 누락된 속성은 런타임 오류를 발생시킵니다.
함수가 더 큰 페이로드 크기를 처리하는지 확인하기 위해 테스트를 생성합니다. Lambda 이벤트 페이로드의 최대 크기는 256KB입니다. 콘텐츠에 따라 페이로드가 클수록 함수로 전달되는 항목이 많아지거나 JSON 속성에 포함되는 바이너리 데이터가 늘어날 수 있습니다. 두 경우 모두 Lambda 함수에 대한 처리가 늘어날 수 있습니다.
페이로드가 클수록 제한 시간이 초과될 수도 있습니다. 예를 들어 Lambda 함수에서 100밀리초당 하나의 레코드를 처리하고 제한 시간은 3초입니다. 페이로드에서 0~29개의 항목에 대한 처리는 성공했습니다. 그러나 페이로드에 30개가 넘는 항목이 포함되면 함수의 제한 시간이 초과되고 오류가 발생합니다. 이를 방지하려면 예상되는 최대 항목 수에 대한 추가 처리 시간을 지원하도록 제한 시간이 설정되어 있는지 확인합니다.
Lambda: 예기치 않게 큰 페이로드 크기
문제: 대용량 페이로드로 인해 함수가 시간 초과되거나 오류가 발생합니다.
페이로드가 클수록 제한 시간이 초과되거나 오류가 발생할 수 있습니다. 함수가 가장 큰 예상 페이로드를 처리할 수 있는지 확인하기 위한 테스트를 생성하고 함수 제한 시간이 올바르게 설정되었는지 확인하는 것이 좋습니다.
또한 특정 이벤트 페이로드가 다른 리소스에 대한 포인터를 포함할 수 있습니다. 예를 들어 메모리가 128MB인 Lambda 함수는 S3에 객체로 저장된 JPG 파일에 대한 이미지 처리를 수행할 수 있습니다. 함수는 더 작은 이미지 파일에서 예상대로 작동합니다. 그러나 더 큰 JPG 파일이 입력으로 제공되면 메모리 부족으로 인해 Lambda 함수에서 오류가 발생합니다. 이를 방지하려면 테스트 사례에 예상 데이터 크기 상한의 예가 포함되어야 합니다. 코드는 페이로드 크기도 검증해야 합니다.
Lambda: JSON 인코딩 및 디코딩 오류
문제: JSON 입력을 구문 분석할 때 NoSuchKey 예외가 발생합니다.
JSON 속성을 올바르게 처리하고 있는지 확인합니다. 예를 들어 S3에서 생성된 이벤트의 경우 s3.object.key 속성에는 URL로 인코딩된 객체 키 이름이 포함됩니다. 많은 함수가 이 속성을 텍스트로 처리하여 참조된 S3 객체를 로드합니다.
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 인코딩은 키 이름에서 공백 및 기타 문자를 변환하므로 이 데이터를 사용하기 전에 함수에서 키를 디코딩해야 합니다.
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를 호출할 수 있는 권한이 필요합니다. 권한을 부여하려면 실행 역할을 업데이트하세요. 다음 관리형 정책을 추가하여 로그 및 추적을 활성화합니다.
-
AWSLambdaBasicExecutionRole
-
AWSXRayDaemonWriteAccess
함수에 권한을 추가할 때 코드나 구성에 대한 간단한 업데이트도 수행하세요. 그러면 자격 증명이 오래된 함수의 인스턴스 실행이 중지 및 대체됩니다.
참고
함수 호출 후 로그가 표시되는 데 5~10분 정도 걸릴 수 있습니다.
Lambda: 일부 함수 로그가 표시되지 않음
문제: 권한이 올바른 경우에도 CloudWatch Logs에서 함수 로그가 누락됨
AWS 계정에서 CloudWatch Logs 할당량 한도에 도달하면 CloudWatch는 함수 로깅을 제한합니다. 이 경우 함수가 출력하는 일부 로그는 CloudWatch Logs에 표시되지 않을 수 있습니다.
함수의 로그 출력 속도가 높아 Lambda에서 처리할 수 없는 경우에도 CloudWatch Logs에 로그 출력이 나타나지 않을 수 있습니다. Lambda에서 함수의 로그 생성 속도에 맞춰 CloudWatch로 로그를 전송할 수 없는 경우 로그를 삭제하여 함수 실행 속도가 느려지는 것을 방지합니다. 단일 로그 스트림의 로그 처리량이 2MB/s를 초과할 경우 삭제된 로그를 지속적으로 관찰해야 합니다.
함수가 JSON 형식의 로그를 사용하도록 구성된 경우 Lambda는 로그를 삭제하면 CloudWatch Logs에 logsDropped 이벤트를 보내려고 합니다. 하지만 CloudWatch가 함수의 로깅을 제한하면 해당 이벤트가 CloudWatch Logs에 도달하지 않을 수 있으므로 Lambda가 로그를 삭제할 때 레코드가 항상 표시되는 것은 아닙니다.
AWS 계정에서 CloudWatch Logs 할당량 한도에 도달했는지 확인하려면 다음을 수행합니다.
-
Service Quotas 콘솔
을 엽니다. -
탐색 창에서 AWS 서비스를 선택합니다.
-
AWS 서비스 목록에서 Amazon CloudWatch Logs를 검색합니다.
-
서비스 할당량 목록에서
CreateLogGroup throttle limit in transactions per second,CreateLogStream throttle limit in transactions per second,PutLogEvents throttle limit in transactions per second할당량을 선택하여 사용률을 확인합니다.
또한 계정 사용률이 이러한 할당량에 지정한 한도를 초과할 경우 알리도록 CloudWatch 경보를 설정할 수 있습니다. 자세한 내용은 정적 임곗값을 기반으로 CloudWatch 경보 생성을 참조하세요.
CloudWatch Logs의 기본 할당량 한도가 사용 사례에 충분하지 않은 경우 할당량 증가를 요청할 수 있습니다.
Lambda: 실행이 완료되기 전에 함수가 반환됨
문제: (Node.js) 코드 실행을 완료하기 전에 함수가 반환됨
AWS SDK를 포함하는 많은 라이브러리가 비동기적으로 작동합니다. 네트워크를 호출하거나 응답을 기다려야 하는 다른 작업을 수행할 때 라이브러리는 백그라운드에서 작업의 진행 상황을 추적하는 promise라는 객체를 반환합니다.
promise가 응답으로 확인될 때까지 기다리려면 await 키워드를 사용하세요. 이렇게 하면 promise가 응답을 포함하는 객체로 확인될 때까지 핸들러 코드가 실행되지 않습니다. 코드에서 응답의 데이터를 사용할 필요가 없으면 promise를 런타임에 직접 반환 할 수 있습니다.
일부 라이브러리는 promise를 반환하지 않지만, 반환하는 코드로 래핑될 수 있습니다. 자세한 내용은 Node.js에서 Lambda 함수 핸들러 정의 단원을 참조하십시오.
Lambda: 의도하지 않은 함수 버전 또는 별칭 실행
문제: 함수 버전 또는 별칭이 간접 호출되지 않음
콘솔에서 또는 AWS SAM을 사용하여 새 Lambda 함수를 게시할 때 최신 코드 버전은 $LATEST로 표시됩니다. 기본적으로 버전 또는 별칭을 지정하지 않은 간접 호출은 함수 코드의 $LATEST 버전을 자동으로 대상으로 지정합니다.
특정 함수 버전 또는 별칭을 사용하는 경우 이는 $LATEST와 더불어 변경할 수 없는 게시된 함수 버전입니다. 이러한 함수의 문제를 해결할 때에는 먼저 직접 호출자가 의도한 버전 또는 별칭을 간접적으로 호출했는지 확인하세요. 함수 로그를 확인하여 이 작업을 수행할 수 있습니다. 간접적으로 호출된 함수의 버전은 항상 START 로그 줄에 표시됩니다.
Lambda: 무한 루프 감지
문제: Lambda 함수와 관련된 무한 루프 패턴
Lambda 함수에는 두 가지 유형의 무한 루프가 있습니다. 첫 번째는 함수 자체 내부에서 종료되지 않는 루프로 인해 발생합니다. 간접 호출은 함수가 시간 초과되는 경우에만 종료됩니다. 시간 초과를 모니터링한 다음 루프 동작을 수정하여 이를 파악할 수 있습니다.
루프의 두 번째 유형은 Lambda 함수 및 기타 AWS 리소스 간입니다. 이 유형은 S3 버킷과 같은 리소스의 이벤트에서 Lambda 함수를 간접 호출하는 경우 이후에 동일한 소스 리소스와 상호 작용하여 다른 이벤트를 트리거할 때 나타납니다. 그러면 함수가 다시 간접 호출되어 동일한 S3 버킷과 또 다른 상호 작용을 생성하는 식으로 반복됩니다. 이러한 유형의 루프는 Amazon SQS 대기열 및 DynamoDB 테이블을 비롯한 여러 가지 다양한 AWS 이벤트 소스로 인해 발생할 수 있습니다. 재귀 루프 감지를 사용하여 이러한 패턴을 식별할 수 있습니다.
소비 리소스와 동일하지 않은 리소스에 Lambda 함수가 쓰기 작업을 수행하도록 하면 이러한 루프를 방지할 수 있습니다. 데이터를 소비 리소스에 다시 게시해야 하는 경우 새 데이터가 동일한 이벤트를 트리거하지 않는지 확인하세요. 또는 이벤트 필터링을 사용하세요. 예를 들어 다음은 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
는 Lambda 기반 애플리케이션의 확장성 및 복원력을 개선하도록 설계된 서비스입니다.
AWS SDK: 버전 및 업데이트
문제: 런타임에 포함된 AWS SDK가 최신 버전이 아님
문제: 런타임에 포함된 AWS SDK가 자동으로 업데이트됨
해석된 언어의 런타임에는 AWS SDK 버전이 포함됩니다. Lambda는 최신 SDK 버전을 사용하도록 이러한 런타임을 주기적으로 업데이트합니다. 런타임에 포함된 SDK 버전을 확인하려면 다음 섹션을 참조하세요.
최신 버전의 AWS SDK를 사용하거나 함수를 특정 버전으로 잠그려면 라이브러리를 함수 코드와 번들로 묶거나 Lambda 계층을 생성하면 됩니다. 종속성을 사용하여 배포 패키지를 만드는 방법에 대한 자세한 내용은 다음 항목을 참조하세요.
Python: 라이브러리가 잘못 로드됨
문제: (Python) 일부 라이브러리는 배포 패키지에서 올바르게 로드되지 않음
C 또는 C++로 작성된 확장 모듈이 있는 라이브러리는 Lambda(Amazon Linux)와 동일한 프로세서 아키텍처를 사용하는 환경에서 컴파일해야 합니다. 자세한 내용은 Python Lambda 함수에 대한 .zip 파일 아카이브 작업 단원을 참조하십시오.
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 환경 변수에 대한 이해를 참조하세요.
