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(기본값)와 달리 관리형 인스턴스는 오류 후 실행 환경을 재설정하고 다시 초기화하려고 시도하지 않습니다. 대신 비정상 컨테이너가 종료되고 새 컨테이너로 대체됩니다.
간접 호출 제한 시간
개별 간접 호출 시간이 초과되면 Lambda는 함수 오류 상태와 함께 Task timed out after <timeout> seconds 오류를 호출자에게 반환합니다. 그러나 Lambda 관리형 인스턴스는 코드를 강제로 종료하지 않고 실행 환경에서 계속 실행됩니다. 함수 개발자가 제한 시간 초과를 감지하고 처리할 책임이 있습니다. 컨텍스트 객체는 간접 호출에 남은 시간을 노출합니다. 0 또는 음수 값은 간접 호출이 시간 초과되었음을 나타냅니다. 실행 환경 내의 다른 동시 간접 호출은 정상적으로 계속 처리됩니다.
재시도 동작
간접 호출 시간이 초과된 경우:
-
동기식 간접 호출: 호출자가 제한 시간 오류를 수신하고 재시도를 담당합니다.
-
비동기식 간접 호출: Lambda는 함수의 재시도 정책에 따라 재시도합니다(기본값: 2회 재시도). 모든 재시도가 소진되면 이벤트가 구성된 Dead Letter Queue(DLQ) 또는 장애 시 대상으로 전송됩니다.
-
이벤트 소스 매핑: 재시도 동작은 이벤트 소스 구성(예: 배치 크기, 오류 발생 시 이분할, 최대 재시도 횟수)에 따라 달라집니다. 재시도 정책에 따라 배치를 재시도하거나 실패 시 대상으로 전송할 수 있습니다.
제한 시간을 처리하지 않으면 어떻게 되나요?
코드가 남은 시간을 확인하지 않고 실행을 중지하는 경우:
-
간접 호출이 이미 실패로 표시되어 있습니다. Lambda는 이미 호출자에게 제한 시간 오류를 반환했으므로, 호출자의 관점에서 제한 시간 이후 코드가 완료한 작업은 호출자 관점에서는 사실상 손실된 것으로 간주됩니다.
-
리소스는 계속 사용됩니다. 코드는 런타임 작업자 슬롯을 계속 차지하므로 해당 인스턴스에서 새 호출에 사용할 수 있는 동시성이 줄어듭니다.
-
비결정적 동작입니다. 제한 시간이 발생하면 코드가 중지되지 않고 백그라운드에서 계속 실행됩니다. 즉, Lambda가 호출자에게 간접 호출 실패를 이미 알린 후에도 부작용이 계속 발생할 수 있습니다. 예를 들어 핸들러가 DynamoDB에 레코드를 쓴 뒤 제한 시간이 발생하여 Lambda가 호출자에게 제한 시간 오류를 반환했지만, 코드는 여전히 실행 중이며 이어서 SNS 알림을 전송할 수 있습니다. 호출자는 간접 호출을 재시도하여 레코드를 다시 쓰고 알림을 다시 보냅니다. 이제 중복 데이터와 중복 알림이 생기며, 백그라운드에서 계속 실행 중이던 “실패한” 간접 호출에서 어떤 것이 발생했는지 쉽게 구분할 방법도 없습니다.
코드의 제한 시간 처리
컨텍스트 객체를 사용하여 남은 시간을 확인하고 제한 시간 전에 처리를 중지합니다. 다음 작업 단위의 예상 소요 시간을 기준으로 버퍼를 구성하세요. 예를 들어 각 항목을 처리하는 데 약 500ms가 걸린다면, 버퍼를 최소 500ms에 여유 시간을 더한 값으로 설정하세요.
제한 시간 처리의 언어별 예는 각 런타임 페이지의 요청 컨텍스트 섹션을 참조하세요.