Lambda에서의 Apache Kafka 이벤트 폴러 스케일링 모드 - AWS Lambda

Lambda에서의 Apache Kafka 이벤트 폴러 스케일링 모드

Amazon MSK 및 자체 관리형 Apache Kafka 이벤트 소스 매핑을 위한 두 가지 이벤트 폴러 스케일링 모드 중에서 선택할 수 있습니다.

온디맨드 모드(기본값)

Kafka 이벤트 소스를 처음 생성하는 경우 Lambda는 기본 이벤트 폴러 수를 할당하여 Kafka 주제의 모든 파티션을 처리합니다. Lambda는 메시지 로드에 따라 이벤트 폴러 수를 자동으로 스케일 업 또는 스케일 다운합니다.

Lambda는 1분 간격으로 주제의 모든 파티션에 대한 오프셋 지연을 평가합니다. 오프셋 지연이 너무 크면 파티션은 Lambda에서 메시지를 처리할 수 있는 것보다 더 빠르게 메시지를 수신합니다. 필요한 경우 Lambda는 주제에서 이벤트 폴러를 추가하거나 제거합니다. 이벤트 폴러를 추가하거나 제거하는 이 오토 스케일링 프로세스는 평가 후 3분 이내에 수행됩니다.

대상 Lambda 함수가 스로틀링되면 Lambda는 이벤트 폴러 수를 줄입니다. 이 작업은 이벤트 폴러에서 검색하고 함수에 전송할 수 있는 메시지 수를 줄임으로써 함수의 워크로드를 줄입니다.

프로비저닝된 모드

이벤트 소스 매핑의 처리량을 미세 조정해야 하는 워크로드의 경우 프로비저닝된 모드를 사용할 수 있습니다. 프로비저닝된 모드에서는 프로비저닝된 이벤트 폴러의 양에 대한 최소 및 최대 제한을 정의합니다. 이러한 프로비저닝된 이벤트 폴러는 이벤트 소스 매핑 전용이며 응답형 오토스케일링을 통해 예상치 못한 메시지 급증을 처리할 수 있습니다. 성능 요구 사항이 엄격한 Kafka 워크로드에 대해서는 프로비저닝된 모드를 사용하는 것이 좋습니다.

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

참고

프로비저닝된 모드를 사용하는 경우 네트워크 구성의 일부로 AWS PrivateLink VPC 엔드포인트를 생성하거나 연결된 권한을 부여하지 않아도 됩니다.

프로비저닝된 모드에서 최소 이벤트 폴러 수(MinimumPollers)에 대해 허용되는 값의 범위는 1~200입니다. 최대 이벤트 폴러 수(MaximumPollers)에 대해 허용되는 값의 범위는 1~2,000(경계 포함)입니다. MaximumPollersMinimumPollers 이상이어야 합니다. 또한 파티션 내에서 정렬된 처리를 유지 관리하기 위해 Lambda는 주제에서 파티션 수를 MaximumPollers로 제한합니다.

최소 및 최대 이벤트 폴러에 대해 적절한 값을 선택하는 방법에 대한 자세한 내용은 모범 사례 섹션을 참조하세요.

콘솔 또는 Lambda API를 사용하여 Kafka 이벤트 소스 매핑에 대한 프로비저닝된 모드를 구성할 수 있습니다.

기존 이벤트 소스 매핑에 대해 프로비저닝된 모드를 구성하는 방법(콘솔)
  1. Lambda 콘솔의 함수 페이지를 엽니다.

  2. 프로비저닝된 모드를 구성할 이벤트 소스 매핑을 사용하는 함수를 선택합니다.

  3. 구성을 선택한 다음 트리거를 선택합니다.

  4. 프로비저닝된 모드를 구성할 이벤트 소스 매핑을 선택하고 편집을 선택합니다.

  5. 프로비저닝된 모드에서 구성을 선택합니다.

    • 최소 이벤트 폴러에 1~200의 값을 입력하세요. 값을 지정하지 않는 경우 Lambda에서는 기본값(1)을 선택합니다.

    • 최대 이벤트 폴러에 1~2,000의 값을 입력하세요 이 값은 최소 이벤트 폴러의 값 이상이어야 합니다. 값을 지정하지 않는 경우 Lambda에서는 기본값(200)을 선택합니다.

  6. 저장을 선택합니다.

EventSourceMappingConfigurationProvisionedPollerConfig 객체를 사용하여 프로그래밍 방식으로 프로비저닝된 모드를 구성할 수 있습니다. 예를 들어 다음 UpdateEventSourceMapping CLI 명령은 5의 MinimumPollers 값과 100의 MaximumPollers 값을 구성합니다.

aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{"MinimumPollers": 5, "MaximumPollers": 100}'

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

프로비저닝 모드를 비활성화하고 기본(온디맨드) 모드로 돌아가기 위해 다음 UpdateEventSourceMapping CLI 명령을 사용할 수 있습니다.

aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{}'

고급 오류 처리 및 성능 기능

프로비저닝 모드가 활성화된 Kafka 이벤트 소스 매핑의 경우 오류 처리 및 성능을 개선하기 위해 추가 기능을 구성할 수 있습니다.

  • 재시도 구성 - Lambda가 최대 재시도 횟수, 레코드 기간 제한, 배치 분할 및 부분 배치 응답으로 실패한 레코드를 처리하는 방법을 제어합니다.

  • Kafka 실패 시 대상 - 후속 처리 또는 분석을 위해 실패한 레코드를 Kafka 주제로 보냅니다.

프로비저닝된 모드 사용 시 모범 사례 및 고려 사항

이벤트 소스 매핑에 대한 최소 및 최대 이벤트 폴러의 최적 구성은 애플리케이션의 성능 요구 사항에 따라 달라집니다. 기본 최소 이벤트 폴러로 시작하여 성능 프로파일을 기준선으로 설정하는 것이 좋습니다. 관찰된 메시지 처리 패턴 및 원하는 성능 프로파일에 따라 구성을 조정합니다.

트래픽이 급증하고 성능 요구가 엄격한 워크로드의 경우 메시지의 갑작스러운 급증을 처리하도록 최소 이벤트 폴러를 늘립니다. 필요한 최소 이벤트 폴러를 확인하려면 초당 워크로드의 메시지 수와 평균 페이로드 크기를 고려하고 단일 이벤트 폴러의 처리량 용량(최대 5MBps)을 참조로 사용합니다.

파티션 내에서 정렬된 처리를 유지 관리하기 위해 Lambda는 최대 이벤트 폴러를 주제의 파티션 수로 제한합니다. 또한 이벤트 소스 매핑에서 조정할 수 있는 최대 이벤트 폴러는 함수의 동시성 설정에 따라 달라집니다.

프로비저닝된 모드를 활성화하는 경우 AWS PrivateLink VPC 엔드포인트 및 연결된 권한을 제거하도록 네트워크 설정을 업데이트합니다.

프로비저닝 모드의 비용 최적화

프로비저닝 모드 요금

프로비저닝 모드는 프로비저닝된 최소 이벤트 폴러와 오토 스케일링 중에 사용된 이벤트 폴러를 기준으로 요금이 부과됩니다. 요금은 이벤트 폴러 단위(EPU)라는 결제 단위를 사용하여 계산됩니다. Event-Poller-Unit-hours로 측정되는 사용한 EPU의 수와 기간에 대해 비용을 지불합니다. 성능에 민감한 애플리케이션에 대해 단일 ESM과 함께 프로비저닝 모드를 사용하거나 동일한 VPC 내에서 여러 ESM을 그룹화하여 EPU 용량과 비용을 공유할 수 있습니다. 프로비저닝 모드 비용을 최적화하는 데 도움이 되는 2가지 기능을 자세히 살펴보겠습니다. 요금에 대한 자세한 내용은 AWS Lambda 요금을 참조하세요.

향상된 EPU 사용률

각 EPU는 이벤트 폴링에 대해 최대 20MB/s의 처리량 용량을 지원하며 기본적으로 이벤트 폴러 10개를 지원합니다. 최소 및 최대 폴러를 설정하여 Kafka ESM에 대한 프로비저닝 모드를 생성하면 최소 폴러 수를 사용하여 EPU당 10개의 기본 이벤트 폴러를 EPU를 프로비저닝합니다. 하지만 각 이벤트 폴러는 최대 5MB/s의 처리량 용량을 지원하도록 독립적으로 규모를 조정할 수 있으며, 이로 인해 특정 EPU에서 밀도가 낮은 이벤트 폴러가 필요하게 되고 EPU 규모 조정이 트리거될 수 있습니다. EPU에 할당된 이벤트 폴러 수는 각 이벤트 폴러에서 사용하는 컴퓨팅 용량에 따라 달라집니다. 향상된 EPU 사용률 접근 방식을 사용하면 처리량 요구 사항이 다양한 이벤트 폴러가 EPU 용량을 효과적으로 활용하여 모든 ESM의 비용이 감소합니다.

ESM 그룹화

프로비저닝 모드 비용을 추가로 최적화하려면 여러 Kafka ESM을 그룹화하여 EPU 용량을 공유할 수 있습니다. ESM 그룹화 및 향상된 EPU 사용률을 사용하면 단일 ESM 모드에서 실행하는 것에 비해 처리량이 적은 워크로드에 대해 프로비저닝 모드 비용을 최대 90% 줄일 수 있습니다. 1 EPU 용량 미만을 필요로 하는 모든 ESM은 ESM 그룹화의 이점을 누릴 수 있습니다. 이러한 ESM은 대체로 처리량 요구 사항을 지원하기 위해 최소 이벤트 폴러가 거의 필요하지 않습니다. 이 기능을 사용하면 모든 Kafka 워크로드에 프로비저닝 모드를 채택하고 스키마 검증, Avro/Protobuf 이벤트 필터링, 지연 시간이 짧은 간접 호출, 프로비저닝 모드에서만 사용할 수 있는 향상된 오류 처리 등의 기능을 활용할 수 있습니다.

동일한 Amazon VPC 내의 여러 ESM에 대해 동일한 값으로 PollerGroupName 파라미터를 구성하면 해당 ESM은 각각 전용 EPU 용량을 필요로 하는 대신 EPU 리소스를 공유합니다. 폴러 그룹당 최대 100개의 ESM을 그룹화할 수 있으며 그룹 내 모든 ESM의 최대 총 폴러 수는 2000개를 초과할 수 없습니다.

ESM 그룹화 구성(콘솔)

  1. Lambda 콘솔의 함수 페이지를 엽니다.

  2. 함수를 선택합니다.

  3. 구성을 선택하고 트리거를 선택합니다.

  4. 새 Kafka 이벤트 소스 매핑을 생성하거나 기존 Kafka 이벤트 소스 매핑을 편집할 때 프로비저닝 모드에서 구성을 선택합니다.

  5. 최소 이벤트 폴러에 1~200의 값을 입력하세요.

  6. 최대 이벤트 폴러에 1~2,000의 값을 입력하세요

  7. 폴러 그룹 이름에 그룹의 식별자를 입력합니다. 그룹화하려는 다른 ESM에도 동일한 이름을 사용합니다.

  8. 저장을 선택합니다.

ESM 그룹화 구성(AWS CLI)

다음 예제에서는 이름이 production-app-group인 폴러 그룹을 사용하여 ESM을 생성합니다.

aws lambda create-event-source-mapping \ --function-name myFunction1 \ --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \ --topics topic1 \ --starting-position LATEST \ --provisioned-poller-config '{ "MinimumPollers": 1, "MaximumPollers": 10, "PollerGroupName": "production-app-group" }'

(EPU 용량을 공유하는) 동일한 그룹에 다른 ESM을 추가하려면 동일한 PollerGroupName을 사용합니다.

aws lambda create-event-source-mapping \ --function-name myFunction2 \ --event-source-arn arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster/abcd1234 \ --topics topic2 \ --starting-position LATEST \ --provisioned-poller-config '{ "MinimumPollers": 1, "MaximumPollers": 10, "PollerGroupName": "production-app-group" }'
참고

PollerGroupName을 업데이트하여 ESM을 다른 그룹으로 이동하거나 PollerGroupName에 대해 빈 문자열("")을 전달하여 그룹에서 ESM을 제거할 수 있습니다.

# Move ESM to a different group aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{ "MinimumPollers": 1, "MaximumPollers": 10, "PollerGroupName": "new-group-name" }' # Remove ESM from group (use dedicated resources) aws lambda update-event-source-mapping \ --uuid a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 \ --provisioned-poller-config '{ "MinimumPollers": 1, "MaximumPollers": 10, "PollerGroupName": "" }'

그룹화 전략 고려 사항

  • 애플리케이션 경계 - 더욱 효과적인 비용 할당 및 관리를 위해 동일한 애플리케이션 또는 서비스에 속하는 ESM을 그룹화합니다. app-name-environment 같은 명명 규칙을 사용하는 것이 좋습니다(예: order-processor-prod).

  • 트래픽 패턴 - 리소스 경합으로 이어질 수 있으므로 처리량이 높고 트래픽 패턴이 급증하는 ESM을 그룹화하지 않습니다.

  • 영향 범위 - 공유 인프라에 문제가 발생할 경우의 영향을 고려합니다. 동일한 그룹의 모든 ESM은 공유 리소스 제한의 영향을 받습니다. 미션 크리티컬 워크로드의 경우 별도의 그룹 또는 전용 ESM을 사용하는 것이 좋습니다.

비용 최적화 예제

각각 1개의 이벤트 폴러와 2MB/s 미만의 처리량으로 구성된 10개의 ESM이 있는 시나리오를 생각해 보겠습니다.

그룹화 미사용:

  • 각 ESM에는 자체 EPU가 필요합니다.

  • 필요한 총 EPU: 10

  • EPU당 비용: 미국 동부(버지니아 북부)에서 시간당 0.185 USD

  • 월별 EPU 비용(720시간): 10 × 720 × 0.185 USD = 1,332 USD

그룹화 사용:

  • 10개의 ESM 모두 EPU 용량 공유

  • 1개의 EPU에 10개의 이벤트 폴러(EPU 지원당 10개의 새 폴러 사용)

  • 필요한 총 EPU: 1

  • 월별 EPU 비용(720시간): 1 × 720 × 0.185 USD = 133.20 USD

  • 비용 절감: 90%(월간 1,198.80 USD 절감)