Lambda의 Apache Kafka 이벤트 폴러 확장 모드

Lambda의 Apache Kafka 이벤트 폴러 확장 모드

Amazon MSK와 자체 관리형 Apache Kafka 이벤트 소스 매핑에 대해 두 가지 이벤트 폴러 확장 모드 중에서 선택할 수 있습니다.

출처: AWS Lambda 개발자 안내서

본문

  • 온디맨드(On-demand) 모드 (기본값)
  • 프로비저닝(Provisioned) 모드

온디맨드(On-demand) 모드 (기본값)

Kafka 이벤트 소스를 처음 만들 때 Lambda는 Kafka 토픽의 모든 파티션을 처리할 기본 수의 이벤트 폴러를 할당합니다. Lambda는 메시지 부하에 따라 이벤트 폴러 수를 자동으로 늘리거나 줄입니다.

1분 간격으로 Lambda는 토픽의 모든 파티션의 **오프셋 지연(offset lag)**을 평가합니다. 오프셋 지연이 너무 높으면 파티션이 Lambda가 처리할 수 있는 것보다 빠르게 메시지를 받고 있는 것입니다. 필요하면 Lambda는 토픽에서 이벤트 폴러를 추가하거나 제거합니다. 이 자동 확장(오토스케일링) 과정은 평가 후 3분 이내에 발생합니다.

대상 Lambda 함수가 제한(throttle)되면 Lambda는 이벤트 폴러 수를 줄입니다. 이 작업은 이벤트 폴러가 검색해 함수로 보낼 수 있는 메시지 수를 줄여 함수의 워크로드를 낮춥니다.

프로비저닝(Provisioned) 모드

이벤트 소스 매핑의 처리량을 세밀하게 조정해야 하는 워크로드에는 프로비저닝 모드를 사용할 수 있습니다. 프로비저닝 모드에서는 프로비저닝된 이벤트 폴러 수의 최소·최대 한도를 정의합니다. 이 프로비저닝된 이벤트 폴러는 이벤트 소스 매핑 전용이며, 반응형 자동 확장으로 예상 밖의 메시지 급증을 처리할 수 있습니다. 엄격한 성능 요구 사항이 있는 Kafka 워크로드에는 프로비저닝 모드를 사용할 것을 권장합니다.

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

프로비저닝 모드를 사용할 때는 네트워크 구성의 일부로 AWS PrivateLink VPC 엔드포인트를 만들거나 관련 권한을 부여할 필요가 없습니다.

프로비저닝 모드에서 이벤트 폴러 최소 수(MinimumPollers)의 허용 값 범위는 1200입니다(포함). 이벤트 폴러 최대 수(MaximumPollers)의 허용 값 범위는 12,000입니다(포함). MaximumPollers는 MinimumPollers보다 크거나 같아야 합니다. 또한 파티션 내 순서 처리(ordered processing)를 유지하기 위해 Lambda는 MaximumPollers를 토픽의 파티션 수로 제한합니다.

최소·최대 이벤트 폴러에 적절한 값을 선택하는 자세한 내용은 'Best practices'를 참고하세요.

콘솔이나 Lambda API로 Kafka 이벤트 소스 매핑에 프로비저닝 모드를 구성할 수 있습니다.

콘솔로 구성:

  1. Lambda 콘솔의 Functions 페이지를 엽니다.
  2. 프로비저닝 모드를 구성할 이벤트 소스 매핑이 있는 함수를 선택합니다.
  3. Configuration을 선택한 뒤 Triggers를 선택합니다.
  4. 프로비저닝 모드를 구성할 이벤트 소스 매핑을 선택한 뒤 Edit을 선택합니다.
  5. Provisioned mode 아래에서 Configure를 선택합니다.
  6. Minimum event pollers에 1~200 사이의 값을 입력합니다. 값을 지정하지 않으면 Lambda는 기본값 1을 선택합니다.
  7. Maximum event pollers에 1~2,000 사이의 값을 입력합니다. 이 값은 Minimum event pollers 값보다 크거나 같아야 합니다. 값을 지정하지 않으면 Lambda는 기본값 200을 선택합니다.
  8. Save를 선택합니다.

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

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 on-failure 대상 – 실패한 레코드를 나중에 처리하거나 분석하기 위해 Kafka 토픽으로 보냅니다.

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

이벤트 소스 매핑의 최적 최소·최대 이벤트 폴러 구성은 애플리케이션의 성능 요구 사항에 따라 다릅니다. 기본 최소 이벤트 폴러로 시작해 성능 프로필을 기준선으로 잡을 것을 권장합니다. 관찰된 메시지 처리 패턴과 원하는 성능 프로필에 따라 구성을 조정하세요.

  • 급증 트래픽과 엄격한 성능 요구가 있는 워크로드에는 최소 이벤트 폴러를 늘려 갑작스러운 메시지 급증을 처리하세요. 필요한 최소 이벤트 폴러를 결정하려면 워크로드의 초당 메시지 수와 평균 페이로드 크기를 고려하고 단일 이벤트 폴러의 처리량 용량(최대 5MBps)을 참고로 사용하세요.
  • 파티션 내 순서 처리를 유지하기 위해 Lambda는 최대 이벤트 폴러를 토픽의 파티션 수로 제한합니다. 또한 이벤트 소스 매핑이 확장할 수 있는 최대 이벤트 폴러는 함수의 동시성 설정에 따라 달라집니다.
  • 프로비저닝 모드를 활성화할 때는 네트워크 설정을 갱신해 AWS PrivateLink VPC 엔드포인트와 관련 권한을 제거하세요.

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

프로비저닝 모드 가격

프로비저닝 모드는 프로비저닝된 최소 이벤트 폴러와 자동 확장 중 소비된 이벤트 폴러를 기준으로 요금이 부과됩니다. 요금은 이벤트 폴러 단위(EPU, Event Poller Unit)라는 결제 단위를 사용해 계산됩니다. 사용한 EPU의 수와 기간(Event-Poller-Unit-hours로 측정)에 대해 비용을 지불합니다.

성능에 민감한 애플리케이션에는 단일 ESM으로 프로비저닝 모드를 사용하거나, 같은 VPC 안의 여러 ESM을 그룹화해 EPU 용량과 비용을 공유할 수 있습니다. 다음 섹션은 프로비저닝 모드 비용을 최적화하는 데 도움이 되는 두 가지 기능을 설명합니다. 가격 자세한 내용은 AWS Lambda pricing을 참고하세요.

향상된 EPU 활용(Enhanced EPU Utilization)

각 EPU는 이벤트 폴링에 최대 20MB/s 처리량 용량을 지원하며 기본적으로 10개의 이벤트 폴러를 지원합니다. Kafka ESM에 최소·최대 폴러를 설정해 프로비저닝 모드를 만들면 EPU당 기본 10개 이벤트 폴러를 기준으로 최소 폴러 수를 사용해 EPU를 프로비저닝합니다. 그러나 각 이벤트 폴러는 최대 5MB/s 처리량 용량을 지원하도록 독립적으로 확장될 수 있으며, 이는 특정 EPU에서 더 낮은 이벤트 폴러 밀도를 요구하고 EPU 확장을 트리거할 수 있습니다. EPU에 할당된 이벤트 폴러 수는 각 이벤트 폴러가 소비하는 컴퓨팅 용량에 따라 달라집니다. 이 향상된 EPU 활용 방식을 사용하면 다양한 처리량 요구 사항을 가진 이벤트 폴러가 EPU 용량을 효과적으로 사용할 수 있어 모든 ESM의 비용이 줄어듭니다.

ESM 그룹화(ESM grouping)

프로비저닝 모드 비용을 더 최적화하려면 여러 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에 걸친 최대 폴러 합계는 2,000을 초과할 수 없습니다.

ESM 그룹화 구성(콘솔):

  1. Lambda 콘솔의 Functions 페이지를 엽니다.
  2. 함수를 선택합니다.
  3. Configuration을 선택한 뒤 Triggers를 선택합니다.
  4. 새 Kafka 이벤트 소스 매핑을 만들거나 기존 것을 편집할 때 Provisioned mode 아래에서 Configure를 선택합니다.
  5. Minimum event pollers에 1~200 사이의 값을 입력합니다.
  6. Maximum event pollers에 1~2,000 사이의 값을 입력합니다.
  7. Poller group name에 그룹의 식별자를 입력합니다. 함께 그룹화하려는 다른 ESM에도 같은 이름을 사용합니다.
  8. Save를 선택합니다.

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"
  }'

같은 그룹에 다른 ESM을 추가하려면(EPU 용량 공유) 같은 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) 같은 명명 규칙 사용을 고려하세요.
  • 트래픽 패턴 – 자원 경쟁(resource contention)을 초래할 수 있으므로 높은 처리량과 급증 트래픽 패턴을 가진 ESM을 그룹화하지 마세요.
  • 블라스트 반경(Blast radius) – 공유 인프라에 문제가 생길 경우의 영향을 고려하세요. 같은 그룹의 모든 ESM은 공유 리소스 제한의 영향을 받습니다. 중요 업무 워크로드에는 별도의 그룹이나 전용 ESM을 사용하는 것을 고려하세요.

비용 최적화 예제

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

그룹화 없음:

  • 각 ESM은 자체 EPU가 필요합니다.
  • 필요한 총 EPU: 10
  • EPU당 비용: US East (N. Virginia)에서 $0.185/시간
  • 월 EPU 비용(720시간): 10 × 720 × $0.185 = $1,332

그룹화 있음:

  • 10개 ESM 모두 EPU 용량 공유
  • 10개의 이벤트 폴러가 1개의 EPU에 맞음(새 EPU당 10 폴러 지원)
  • 필요한 총 EPU: 1
  • 월 EPU 비용(720시간): 1 × 720 × $0.185 = $133.20
  • 비용 절감: 90% (월 $1,198.80 절감)

더 알아보기 (Learn more)