Lambda가 스트림 및 대기열 기반 이벤트 소스의 레코드를 처리하는 방법

이벤트 소스 매핑은 스트림 및 대기열 기반 서비스에서 항목을 읽고 레코드 배치로 함수를 간접적으로 간접 호출하는 Lambda 리소스입니다. 이벤트 소스 매핑 내에서 이벤트 폴러라고 하는 리소스는 새 메시지를 적극적으로 폴링하고 함수를 간접 호출합니다. 기본적으로 Lambda는 이벤트 폴러 크기를 자동으로 조정하지만 특정 이벤트 소스 유형의 경우 프로비저닝된 모드를 사용하여 이벤트 소스 매핑 전용 이벤트 폴러의 최소 및 최대 수를 제어할 수 있습니다.

다음 서비스는 이벤트 소스 매핑을 사용하여 Lambda 함수를 간접적으로 간접 호출합니다.

이벤트 소스 매핑과 직접 트리거의 차이점

일부 AWS 서비스에서는 트리거를 사용하여 바로 Lambda 함수를 간접 호출할 수 있습니다. 이러한 서비스는 Lambda로 이벤트를 푸시하고, 지정된 이벤트가 발생하면 함수가 즉시 간접적으로 간접 호출됩니다. 트리거는 개별 이벤트와 실시간 처리에 적합합니다. Lambda 콘솔을 사용하여 트리거를 생성하면 콘솔은 해당 AWS 서비스와 상호 작용하여 서비스에 대한 이벤트 알림을 구성합니다. 트리거는 실제로 Lambda가 아니라 이벤트를 생성하는 서비스에 의해 저장되고 관리됩니다. 다음은 트리거를 사용하여 Lambda 함수를 간접적으로 간접 호출하는 서비스의 몇 가지 예입니다.

이벤트 소스 매핑은 Lambda 서비스 내에서 생성되고 관리되는 Lambda 리소스입니다. 이벤트 소스 매핑은 대기열의 대용량 스트리밍 데이터 또는 메시지를 처리하도록 설계되었습니다. 스트림이나 대기열의 레코드를 일괄적으로 처리하는 것이 레코드를 개별적으로 처리하는 것보다 더 효율적입니다.

일괄 처리 동작

기본적으로 이벤트 소스 매핑은 레코드를 일괄 처리하고 Lambda는 이를 단일 페이로드로 함수에 전송합니다. 일괄 처리 동작을 미세 조정하려면 배치 기간(MaximumBatchingWindowInSeconds)과 배치 크기(BatchSize)를 구성합니다. 일괄 처리 기간은 레코드를 단일 페이로드로 수집할 최대 기간입니다. 배치 크기는 단일 배치의 최대 레코드 수입니다. Lambda는 다음 세 가지 기준 중 하나에 부합할 때 함수를 간접 호출합니다.

다음 다이어그램은 이 세 가지 조건을 보여줍니다. 일괄 처리 기간이 t = 7초에서 시작한다고 가정합니다. 첫 번째 시나리오에서는 5개의 레코드를 누적한 후 일괄 처리 기간이 t = 47초로 2차 최댓값인 40에 도달합니다. 두 번째 시나리오에서는 일괄 처리 기간이 만료되기 전에 배치 크기가 10에 도달하므로 일괄 처리 기간이 일찍 종료됩니다. 세 번째 시나리오에서는 일괄 처리 기간이 만료되기 전에 최대 페이로드 크기에 도달하므로 일괄 처리 기간이 일찍 종료됩니다.

각 이벤트 소스의 폴링 빈도를 함수가 작업을 완료할 수 있는 속도에 맞게 조정할 수 있도록 다양한 배치 및 레코드 크기로 테스트하는 것이 좋습니다. CreateEventSourceMapping BatchSize 파라미터는 각 간접 호출에서 함수로 보낼 수 있는 최대 레코드 수를 제어합니다. 배치 크기가 클수록 더 큰 레코드 세트에서 간접 호출 오버헤드를 더 효율적으로 수용하여 처리량을 늘릴 수 있습니다.

Lambda는 처리를 위해 다음 배치를 전송하기 전에 구성된 확장이 완료될 때까지 기다리지 않습니다. 즉, Lambda가 다음 레코드 배치를 처리할 때 확장이 계속 실행될 수 있습니다. 이로 인해 계정의 동시성 설정 또는 제한을 위반하는 경우 제한 문제가 발생할 수 있습니다. 이것이 잠재적인 문제인지 여부를 탐지하려면 함수를 모니터링하고 이벤트 소스 매핑에 대해 예상보다 높은 동시성 지표가 표시되는지 확인하세요. 간접 호출 간격이 짧기 때문에 Lambda는 일시적으로 동시성 사용량을 샤드 수보다 더 높게 보고할 수 있습니다. 확장이 없는 Lambda 함수에서도 마찬가지입니다.

기본적으로, 함수가 오류를 반환하는 경우 함수가 성공할 때까지 또는 배치에 있는 항목이 만료될 때까지 전체 배치가 다시 처리됩니다. 순차적 처리를 위해 이벤트 소스 매핑은 오류가 해결될 때까지 영향을 받은 샤드에 대한 처리를 일시 중지합니다. 스트림 소스(DynamoDB 및 Kinesis)의 경우, 함수에서 오류가 반환될 때 Lambda가 재시도하는 최대 횟수를 구성할 수 있습니다. 배치가 함수에 도달하지 않는 서비스 오류 또는 제한은 재시도 횟수에 반영되지 않습니다. 이벤트 배치를 삭제할 때 간접 호출 레코드를 대상으로 보내도록 이벤트 소스 매핑을 구성할 수도 있습니다.

프로비저닝된 모드

Lambda 이벤트 소스 매핑은 이벤트 폴러를 사용하여 새 메시지에 대해 이벤트 소스를 폴링합니다. 기본적으로 Lambda에서 메시지 볼륨에 따라 이러한 폴러의 자동 규모 조정을 관리합니다. 메시지 트래픽이 증가하면 Lambda는 로드를 처리할 이벤트 폴러 수를 자동으로 늘리고 트래픽이 감소하면 줄입니다.

프로비저닝된 모드에서는 프로비저닝된 이벤트 폴러 수에 대한 최소 및 최대 제한을 정의하여 이벤트 소스 매핑의 처리량을 미세 조정할 수 있습니다. 그런 다음, Lambda는 응답 방식으로 최소 및 최대 이벤트 폴러 수 사이에서 이벤트 소스 매핑을 조정합니다. 이러한 프로비저닝된 이벤트 폴러는 이벤트 소스 매핑 전용이므로 이벤트에서 예측할 수 없는 급증을 처리하는 기능이 개선됩니다.

Lambda에서 이벤트 폴러는 최대 5MBps의 처리량을 처리할 수 있는 컴퓨팅 장치입니다. 참조를 위해 이벤트 소스가 1MB의 평균 페이로드를 생성하고 평균 함수 지속 시간이 1초라고 가정합니다. 페이로드에서 변환(예: 필터링)이 수행되지 않는 경우 단일 폴러는 5MBps의 처리량과 5개의 동시 Lambda 간접 호출을 지원할 수 있습니다. 프로비저닝된 모드를 사용하면 추가 비용이 발생합니다. 예상 요금은 AWS Lambda 요금을 참조하세요.

프로비저닝 모드는 Amazon MSK 및 자체 관리형 Apache Kafka 이벤트 소스에 대해서만 지원됩니다. 동시성 설정을 통해 함수 규모 조정을 제어할 수 있지만 프로비저닝된 모드를 사용하면 이벤트 소스 매핑의 처리량을 제어할 수 있습니다. 성능을 극대화하기 위해 두 설정을 독립적으로 조정해야 할 수도 있습니다. 프로비저닝된 모드 구성에 대한 자세한 내용은 다음 섹션을 참조하세요.

프로비저닝된 모드를 구성한 후 ProvisionedPollers 지표를 모니터링하여 워크로드에 대한 이벤트 폴러 사용량을 관찰할 수 있습니다. 자세한 내용은 이벤트 소스 매핑 지표 단원을 참조하십시오.

이벤트 소스 매핑 API

AWS Command Line Interface(AWS CLI) 또는 AWS SDK를 사용하여 이벤트 소스를 관리하려면 다음 API 작업을 사용할 수 있습니다.