Lambda가 스트림 및 큐 기반 이벤트 소스에서 레코드를 처리하는 방법

Lambda가 스트림 및 큐 기반 이벤트 소스에서 레코드를 처리하는 방법 (How Lambda processes records from stream and queue-based event sources)

이벤트 소스 매핑(event source mapping)은 스트림 및 큐 기반 서비스에서 항목을 읽고 레코드 배치로 함수를 호출하는 Lambda 리소스입니다. 이벤트 소스 매핑 안에서 이벤트 폴러(event poller)라는 리소스가 새 메시지를 능동적으로 폴링하고 함수를 호출합니다. 기본적으로 Lambda는 이벤트 폴러를 자동으로 확장하지만, 특정 이벤트 소스 유형의 경우 프로비저닝 모드를 사용해 이벤트 소스 매핑에 전용된 이벤트 폴러의 최소 및 최대 수를 제어할 수 있습니다.

다음 서비스는 이벤트 소스 매핑을 사용해 Lambda 함수를 호출합니다:

  • Amazon DocumentDB(MongoDB 호환)(Amazon DocumentDB)
  • Amazon DynamoDB
  • Amazon Kinesis
  • Amazon MQ
  • Amazon Managed Streaming for Apache Kafka(Amazon MSK)
  • 자체 관리형 Apache Kafka
  • Amazon Simple Queue Service(Amazon SQS)

경고

Lambda 이벤트 소스 매핑은 각 이벤트를 최소 한 번 처리하며 레코드의 중복 처리가 발생할 수 있습니다. 중복 이벤트 관련 잠재적 문제를 피하기 위해 함수 코드를 멱등(idempotent)으로 만드는 것을 강력히 권장합니다. 자세한 내용은 AWS Knowledge Center에서 Lambda 함수를 멱등으로 만드는 방법을 참조하세요.

출처: AWS Lambda 개발자 안내서

본문

이벤트 소스 매핑이 직접 트리거와 다른 점

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

  • Amazon Simple Storage Service(Amazon S3) — 버킷에서 객체가 생성, 삭제 또는 수정될 때 함수를 호출합니다. 자세한 내용은 튜토리얼: Amazon S3 트리거를 사용해 Lambda 함수 호출을 참조하세요.
  • Amazon Simple Notification Service(Amazon SNS) — SNS 주제에 메시지가 게시될 때 함수를 호출합니다. 자세한 내용은 튜토리얼: Amazon Simple Notification Service와 함께 AWS Lambda 사용을 참조하세요.
  • Amazon API Gateway — 특정 엔드포인트에 API 요청이 이루어질 때 함수를 호출합니다. 자세한 내용은 Amazon API Gateway 엔드포인트를 사용한 Lambda 함수 호출을 참조하세요.

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

일괄 처리 동작

기본적으로 이벤트 소스 매핑은 레코드를 Lambda가 함수로 보내는 단일 페이로드로 함께 묶습니다. 일괄 처리 동작을 미세 조정하려면 일괄 처리 창(MaximumBatchingWindowInSeconds)과 일괄 처리 크기(BatchSize)를 구성할 수 있습니다. 일괄 처리 창은 레코드를 단일 페이로드로 모으는 최대 시간입니다. 일괄 처리 크기는 단일 배치의 최대 레코드 수입니다. Lambda는 다음 세 가지 기준 중 하나가 충족되면 함수를 호출합니다:

  1. 일괄 처리 창이 최대값에 도달함. 기본 일괄 처리 창 동작은 특정 이벤트 소스에 따라 다릅니다.

    • Kinesis, DynamoDB, Amazon SQS 이벤트 소스의 경우: 기본 일괄 처리 창은 0초입니다. 즉 레코드를 사용할 수 있는 즉시 Lambda가 함수를 호출합니다. 일괄 처리 창을 설정하려면 MaximumBatchingWindowInSeconds를 구성하세요. 이 파라미터는 0~300초 사이의 값을 1초 단위로 설정할 수 있습니다. 일괄 처리 창을 구성하면 이전 함수 호출이 완료되는 즉시 다음 창이 시작됩니다.
    • Amazon MSK, 자체 관리형 Apache Kafka, Amazon MQ, Amazon DocumentDB 이벤트 소스의 경우: 기본 일괄 처리 창은 500ms입니다. MaximumBatchingWindowInSeconds를 0초~300초 사이의 값으로 초 단위로 구성할 수 있습니다. Kafka 이벤트 소스 매핑의 프로비저닝 모드에서 일괄 처리 창을 구성하면 이전 일괄 처리가 완료되는 즉시 다음 창이 시작됩니다. 비프로비저닝 Kafka 이벤트 소스 매핑에서는 일괄 처리 창을 구성하면 이전 함수 호출이 완료되는 즉시 다음 창이 시작됩니다.
    • 프로비저닝 모드에서 Kafka 이벤트 소스 매핑을 사용할 때 대기 시간을 최소화하려면 MaximumBatchingWindowInSeconds를 0으로 설정하세요. 이 설정은 Lambda가 현재 함수 호출을 완료한 직후 다음 일괄 처리를 즉시 시작하게 합니다. 저지연 처리에 대한 추가 정보는 저지연 Apache Kafka를 참조하세요.
    • Amazon MQ 및 Amazon DocumentDB 이벤트 소스의 경우: 기본 일괄 처리 창은 500ms입니다. MaximumBatchingWindowInSeconds를 0초~300초 사이의 값으로 초 단위로 구성할 수 있습니다. 첫 번째 레코드가 도착하는 즉시 일괄 처리 창이 시작됩니다.

    • 참고

      MaximumBatchingWindowInSeconds는 초 단위로만 변경할 수 있으므로 변경 후에는 500ms 기본 일괄 처리 창으로 되돌릴 수 없습니다. 기본 일괄 처리 창을 복원하려면 새 이벤트 소스 매핑을 만들어야 합니다.

  2. 일괄 처리 크기가 충족됨. 최소 일괄 처리 크기는 1입니다. 기본 및 최대 일괄 처리 크기는 이벤트 소스에 따라 다릅니다. 이러한 값에 대한 세부 정보는 CreateEventSourceMapping API 작업의 BatchSize 명세를 참조하세요.

  3. 페이로드 크기가 6MB에 도달함. 이 제한은 수정할 수 없습니다.

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

각 이벤트 소스의 폴링 빈도가 함수가 작업을 완료할 수 있는 속도에 맞춰 조정되도록 여러 배치 및 레코드 크기로 테스트할 것을 권장합니다. CreateEventSourceMapping의 BatchSize 파라미터는 각 호출로 함수에 보낼 수 있는 최대 레코드 수를 제어합니다. 더 큰 일괄 처리 크기는 더 큰 레코드 세트에 걸쳐 호출 오버헤드를 더 효율적으로 흡수하여 처리량을 높일 수 있습니다.

Lambda는 다음 일괄 처리를 보내기 전에 구성된 확장 기능이 완료될 때까지 기다리지 않습니다. 즉 Lambda가 다음 레코드 일괄 처리를 처리하는 동안 확장 기능이 계속 실행될 수 있습니다. 이로 인해 계정의 동시성 설정이나 한도를 위반하면 제한(스로틀링) 문제가 발생할 수 있습니다. 이는 잠재적 문제인지 확인하려면 함수를 모니터링하고 이벤트 소스 매핑에 대해 예상보다 높은 동시성 메트릭이 나타나는지 확인하세요. 호출 사이의 시간이 짧기 때문에 Lambda는 샤드 수보다 높은 동시성 사용량을 잠시 보고할 수 있습니다. 이는 확장 기능이 없는 Lambda 함수에서도 마찬가지일 수 있습니다.

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

프로비저닝 모드

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

프로비저닝 모드에서는 예상 트래픽 패턴을 처리할 준비가 된 전용 폴링 리소스에 대한 최소 및 최대 한도를 정의하여 이벤트 소스 매핑의 처리량을 미세 조정할 수 있습니다. 이러한 리소스는 갑작스러운 이벤트 트래픽 급증을 처리하기 위해 3배 더 빠르게 자동 확장하며 수백만 건의 이벤트를 처리할 수 있는 16배 더 높은 용량을 제공합니다. 이는 엄격한 성능 요구 사항이 있는 응답성이 높은 이벤트 기반 워크로드를 구축하는 데 도움이 됩니다.

Lambda에서 이벤트 폴러는 이벤트 소스 유형에 따라 처리량 능력이 달라지는 컴퓨팅 단위입니다. Amazon MSK 및 자체 관리형 Apache Kafka의 경우 각 이벤트 폴러는 최대 5MB/초 처리량 또는 최대 5개의 동시 호출을 처리할 수 있습니다. 예를 들어 이벤트 소스가 평균 1MB 페이로드를 생성하고 함수의 평균 기간이 1초라면 단일 Kafka 이벤트 폴러는 5MB/초 처리량과 5개의 동시 Lambda 호출을 지원할 수 있습니다(페이로드 변환이 없다고 가정). Amazon SQS의 경우 각 이벤트 폴러는 최대 1MB/초 처리량 또는 최대 10개의 동시 호출을 처리할 수 있습니다. 프로비저닝 모드를 사용하면 이벤트 폴러 사용량에 따라 추가 비용이 발생합니다. 요금 세부 정보는 AWS Lambda 요금을 참조하세요.

프로비저닝 모드는 Amazon MSK, 자체 관리형 Apache Kafka, Amazon SQS 이벤트 소스에서 사용할 수 있습니다. 동시성 설정이 함수의 확장을 제어하는 반면, 프로비저닝 모드는 이벤트 소스 매핑의 처리량을 제어합니다. 최대 성능을 보장하려면 두 설정을 독립적으로 조정해야 할 수 있습니다.

프로비저닝 모드는 일관된 이벤트 처리 대기 시간이 필요한 실시간 애플리케이션에 이상적입니다. 예를 들어 시장 데이터 피드를 처리하는 금융 서비스 회사, 실시간 개인화 추천을 제공하는 전자 상거래 플랫폼, 라이브 플레이어 상호작용을 관리하는 게임 회사 등이 있습니다.

각 이벤트 폴러는 서로 다른 처리량 용량을 지원합니다:

  • Amazon MSK 및 자체 관리형 Apache Kafka: 최대 5MB/초 처리량 또는 최대 5개의 동시 호출
  • Amazon SQS: 최대 1MB/초 처리량 또는 최대 10개의 동시 호출 또는 초당 최대 10개의 SQS 폴링 API 호출

Amazon SQS 이벤트 소스 매핑의 경우 폴러 최소 수를 2200(기본값 2), 최대 수를 210,000(기본값 200)으로 설정할 수 있습니다. Lambda는 구성된 최소값과 최대값 사이에서 이벤트 폴러 수를 확장하며, 분당 최대 1,000개의 동시성을 빠르게 추가해 일관되고 낮은 대기 시간의 이벤트 처리를 제공합니다.

Kafka 이벤트 소스 매핑의 경우 폴러 최소 수를 1200(기본값 1), 최대 수를 12,000(기본값 200)으로 설정할 수 있습니다. Lambda는 토픽의 이벤트 백로그에 따라 구성된 최소값과 최대값 사이에서 이벤트 폴러 수를 확장해 이벤트의 낮은 대기 시간 처리를 제공합니다.

Amazon SQS 이벤트 소스의 경우 최대 동시성 설정은 프로비저닝 모드와 함께 사용할 수 없습니다. 프로비저닝 모드를 사용할 때는 최대 이벤트 폴러 설정을 통해 동시성을 제어합니다.

프로비저닝 모드 구성에 대한 자세한 내용은 다음 섹션을 참조하세요:

  • Amazon MSK 이벤트 소스 매핑에 대한 프로비저닝 모드 구성
  • 자체 관리형 Apache Kafka 이벤트 소스 매핑에 대한 프로비저닝 모드 구성
  • Amazon SQS 이벤트 소스 매핑과 함께 프로비저닝 모드 사용

프로비저닝 모드에서 대기 시간을 최소화하려면 MaximumBatchingWindowInSeconds를 0으로 설정하세요. 이 설정은 Lambda가 현재 함수 호출을 완료한 직후 다음 일괄 처리를 즉시 시작하게 합니다. 저지연 처리에 대한 추가 정보는 저지연 Apache Kafka를 참조하세요.

프로비저닝 모드를 구성한 후 ProvisionedPollers 메트릭을 모니터링해 워크로드에 대한 이벤트 폴러 사용을 관찰할 수 있습니다. 자세한 내용은 이벤트 소스 매핑 메트릭을 참조하세요.

이벤트 소스 매핑 API

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

  • CreateEventSourceMapping
  • ListEventSourceMappings
  • GetEventSourceMapping
  • UpdateEventSourceMapping
  • DeleteEventSourceMapping

더 알아보기 (Learn more)

  • Lambda 이벤트 소스 매핑 개요
  • 이벤트 소스 매핑 프로비저닝 모드
  • 이벤트 소스 매핑 오류 처리