Lambda에서 자체 관리형 Apache Kafka 메시지 처리

Kafka 클러스터를 이벤트 소스로 추가

이벤트 소스 매핑을 생성하려면 Lambda 콘솔, AWS SDK 또는 AWS Command Line Interface(AWS CLI)를 사용해 Kafka를 Lambda 함수 트리거로 추가합니다.

이 단원에서는 Lambda 콘솔 및 AWS CLI를 사용해 이벤트 소스 매핑을 생성하는 방법을 설명합니다.

사전 조건

사용자 지정이 가능한 소비자 그룹 ID

Kafka를 이벤트 소스로 설정할 때 소비자 그룹 ID를 지정할 수 있습니다. 이 소비자 그룹 ID는 Lambda 함수에 가입하려는 Kafka 소비자 그룹의 기존 식별자입니다. 이 기능을 사용하여 진행 중인 모든 Kafka 레코드 처리 설정을 다른 소비자에서 Lambda로 원활하게 마이그레이션할 수 있습니다.

소비자 그룹 ID를 지정하고 해당 소비자 그룹 내에 다른 활성 폴러가 있는 경우 Kafka는 모든 소비자에게 메시지를 배포합니다. 즉, Lambda는 Kafka 주제에 대한 모든 메시지를 수신하지는 않습니다. Lambda가 주제에 있는 모든 메시지를 처리하도록 하려면 해당 소비자 그룹의 다른 모든 폴러를 끄십시오.

또한 소비자 그룹 ID를 지정했는데 Kafka가 동일한 ID를 가진 유효한 기존 소비자 그룹을 찾으면 Lambda는 이벤트 소스 매핑을 위한 StartingPosition 파라미터를 무시합니다. 대신 Lambda는 소비자 그룹의 커밋된 오프셋에 따라 레코드 처리를 시작합니다. 소비자 그룹 ID를 지정했는데 Kafka가 기존 소비자 그룹을 찾을 수 없는 경우, Lambda는 StartingPosition에서 지정된 대로 이벤트 소스를 구성합니다.

지정하는 소비자 그룹 ID는 모든 Kafka 이벤트 소스 중에서 고유해야 합니다. 지정된 소비자 그룹 ID로 Kafka 이벤트 소스 매핑을 생성한 후에는 이 값을 업데이트할 수 없습니다.

자체 관리형 Kafka 클러스터 추가(콘솔)

다음 단계에 따라 자체 관리형 Apache Kafka 클러스터 및 Kafka 주제를 Lambda 함수의 트리거로 추가합니다.

자체 관리형 Kafka 클러스터 추가(AWS CLI)

다음 예제 AWS CLI 명령을 사용하여 Lambda 함수에 대한 자체 관리형 Apache Kafka 트리거를 생성하고 확인합니다.

SASL/SCRAM 사용

Kafka 사용자가 인터넷을 통해 Kafka 브로커에 액세스한다면 SASL/SCRAM 인증용으로 생성한 Secrets Manager 비밀 정보를 지정합니다. 다음 예제에서는 create-event-source-mapping AWS CLI 명령을 사용하여 my-kafka-function이라는 Lambda 함수를 AWSKafkaTopic이라는 Kafka 주제에 매핑합니다.

aws lambda create-event-source-mapping \ 
  --topics AWSKafkaTopic \
  --source-access-configuration Type=SASL_SCRAM_512_AUTH,URI=arn:aws:secretsmanager:us-east-1:111122223333:secret:MyBrokerSecretName \
  --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \
  --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'

VPC 사용

VPC 내의 Kafka 사용자만 Kafka 브로커에 액세스한다면 VPC, 서브넷 및 VPC 보안 그룹을 지정해야 합니다. 다음 예제에서는 create-event-source-mapping AWS CLI 명령을 사용하여 my-kafka-function이라는 Lambda 함수를 AWSKafkaTopic이라는 Kafka 주제에 매핑합니다.

aws lambda create-event-source-mapping \ 
  --topics AWSKafkaTopic \
  --source-access-configuration '[{"Type": "VPC_SUBNET", "URI": "subnet:subnet-0011001100"}, {"Type": "VPC_SUBNET", "URI": "subnet:subnet-0022002200"}, {"Type": "VPC_SECURITY_GROUP", "URI": "security_group:sg-0123456789"}]' \
  --function-name arn:aws:lambda:us-east-1:111122223333:function:my-kafka-function \
  --self-managed-event-source '{"Endpoints":{"KAFKA_BOOTSTRAP_SERVERS":["abc3.xyz.com:9092", "abc2.xyz.com:9092"]}}'

AWS CLI를 사용하여 상태 확인

다음 예제에서는 get-event-source-mapping AWS CLI 명령을 사용하여 생성한 이벤트 소스 매핑의 상태를 설명합니다.

aws lambda get-event-source-mapping
          --uuid dh38738e-992b-343a-1077-3478934hjkfd7

자체 관리형 Apache Kafka 구성 파라미터

모든 Lambda 이벤트 소스 유형은 동일한 CreateEventSourceMapping 및 UpdateEventSourceMapping API 작업을 공유합니다. 그러나 파라마터 중 일부는 Apache Kafka에 적용됩니다.

Kafka 클러스터를 이벤트 소스로 사용

Apache Kafka 또는 Amazon MSK 클러스터를 Lambda 함수의 트리거로 추가하면 해당 클러스터가 이벤트 소스로 사용됩니다.

Lambda는 사용자가 지정한 StartingPosition을 기반으로 CreateEventSourceMapping 요청에서 Topics로 지정한 Kafka 주제에서 이벤트 데이터를 읽습니다. 성공적인 처리 후, Kafka 토픽은 Kafka 클러스터에 커밋됩니다.

StartingPosition을 LATEST로 지정하면 Lambda는 주제에 속한 각 파티션의 최신 메시지에서 읽기를 시작합니다. 트리거 구성 후 Lambda가 메시지를 읽기 시작하기까지 약간의 지연이 발생할 수 있으므로 Lambda는 이 기간 중에 생성된 메시지를 읽지 않습니다.

Lambda는 지정한 하나 이상의 Kafka 주제 파티션의 레코드를 처리하고 JSON 페이로드를 함수로 보냅니다. 단일 Lambda 페이로드에는 여러 파티션의 메시지가 포함될 수 있습니다. 사용 가능한 레코드가 더 있는 경우 Lambda는 함수가 주제를 따라잡을 때까지 CreateEventSourceMapping 요청에서 지정한 BatchSize 값을 기반으로 배치로 레코드를 계속 처리합니다.

함수가 배치의 어떤 메시지에 대해 오류를 반환하면 Lambda는 처리가 성공하거나 메시지가 만료될 때까지 전체 메시지 배치를 다시 시도합니다. 모든 재시도에 실패한 레코드를 실패 시 대상으로 전송하여 나중에 처리하도록 할 수 있습니다.

폴링 및 스트리밍 시작 위치

이벤트 소스 매핑 생성 및 업데이트 중 스트림 폴링은 최종적으로 일관됩니다.

이 동작은 스트림의 시작 위치로 LATEST를 지정하면 이벤트 소스 매핑이 생성 또는 업데이트 중에 이벤트를 놓칠 수 있음을 의미합니다. 누락된 이벤트가 없도록 하기 위해서는 스트림 시작 위치를 TRIM_HORIZON 또는 AT_TIMESTAMP로 지정하세요.

자체 관리형 Apache Kafka 이벤트 소스 매핑에 대한 메시지 처리량 조정 동작

Amazon MSK 이벤트 소스 매핑에 대한 메시지 처리량 조정 동작에 관한 두 가지 모드 중에서 선택할 수 있습니다.

기본(온디맨드) 모드

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

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

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

Kafka 주제의 처리량을 모니터링하려면 consumer_lag 및 consumer_offset 같은 Apache Kafka 소비자 지표를 확인합니다.

프로비저닝된 모드 구성

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

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

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

최소 및 최대 이벤트 폴러에 대해 적절한 값을 선택하는 방법에 대한 자세한 내용은 프로비저닝된 모드 사용 시 모범 사례 및 고려 사항 섹션을 참조하세요.

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

EventSourceMappingConfiguration의 ProvisionedPollerConfig 객체를 사용하여 프로그래밍 방식으로 프로비저닝된 모드를 구성할 수 있습니다. 예를 들어 다음 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 '{}'

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

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

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

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

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

Amazon CloudWatch 지표

Lambda는 함수가 레코드를 처리하는 동안 OffsetLag 지표를 내보냅니다. 이 지표의 값은 Kafka 이벤트 소스 주제에 작성된 마지막 레코드와 함수의 소비자 그룹에서 처리한 마지막 레코드 간의 오프셋 차이입니다. 레코드가 추가되는 시점과 소비자 그룹이 이를 처리하는 시점 사이의 지연 시간을 추정하는 데 OffsetLag를 사용할 수 있습니다.

OffsetLag의 증가 추세는 함수의 소비자 그룹 폴러에 문제가 있음을 나타낼 수 있습니다. 자세한 내용은 Lambda에서 CloudWatch 지표 사용 단원을 참조하십시오.