AWS Lambda, 자체 관리형 Kafka에 큐 모드 추가: 여러 폴러가 순서 없이 한 파티션을 읽으며 Amazon MSK는 아직 미지원

2026년 11월 2일 AWS는 AWS Lambda가 자체 관리형 Kafka 이벤트 소스 매핑에서 Apache Kafka 큐를 지원한다고 발표했다. 지금까지 Kafka 이벤트 소스 매핑은 각 파티션을 그룹 내 정확히 하나의 컨슈머에 할당하는 Kafka 컨슈머 그룹 프로토콜을 썼다. 더 높은 병렬성이 필요한 팀은 토픽을 과도하게 파티셔닝하거나 트래픽을 별도의 큐잉 시스템으로 옮겨야 했고, 그만큼 운영할 인프라와 유지할 프로듀서 코드가 늘었다. 새 큐 모드는 Kafka 쉐어 그룹에 기반하며, 여러 이벤트 폴러가 같은 파티션을 동시에 읽을 수 있다.

AWS에 따르면 각 이벤트 폴러는 최대 10개의 동시 호출을 지원하고, 병렬성이 더 이상 파티션 수에 묶이지 않으며, 프로듀서, 토픽 설정, 함수 코드를 바꿀 필요가 없다. 느리거나 실패한 이벤트가 같은 파티션의 다른 이벤트를 더는 막지 않는다. 발표는 그 대가도 솔직히 밝힌다. 큐 모드는 파티션 순서를 보존하지 않으며 순서가 필요 없는 워크로드를 위한 것이다. 각 이벤트가 독립된 작업 단위이고 순서보다 속도가 중요한 사례로 이미지와 동영상 인코딩, 사기 탐지, 알림 전송, 텔레메트리 수집을 든다.

요건은 제목이 주는 인상보다 좁다. 발표는 클러스터에 쉐어 그룹이 활성화되어 있어야 하며, 예를 들어 Apache Kafka 4.2 이상이어야 하고, 자체 관리형 Kafka 이벤트 소스 매핑을 쓸 수 있는 모든 AWS 상용 리전에서 이용할 수 있다고 말한다. 고객이 직접 운영하는 클러스터와 Confluent Cloud 같은 관리형 서비스를 포함한다고 한다. Lambda 개발자 가이드는 더 나아간다. 쉐어 그룹은 Apache Kafka 4.0에서 등장했지만 Kafka Queue Poller는 4.2 이상이 필요하고, 큐 모드는 자체 관리형 클러스터 전용이라고 한다. 가이드의 표현으로 Amazon MSK는 현재 큐 모드를 지원하지 않으며, MSK가 쉐어 그룹이 켜진 Kafka 4.2 이상을 제공하면 AWS가 MSK 지원을 추가한다. 따라서 Amazon MSK를 운영하는 팀은 이 발표가 자기 클러스터를 포함한다고 읽어서는 안 된다.

사용하려면 콘솔, Lambda API, AWS CLI, CloudFormation, SAM, CDK 중 하나로 ConsumptionMode를 Queue로 설정한 자체 관리형 Kafka 이벤트 소스 매핑을 만든다. 모드를 지정하지 않으면 기본인 Stream 모드가 쓰인다. 가이드는 둘을 비교한다. Stream은 파티션 내 순서를 지키고 폴러당 최대 5개의 동시 호출을 허용한다. Queue는 순서를 보장하지 않고 최대 10개를 허용한다. 비교표에서는 둘 다 폴러당 최대 5MB/s 처리량을 적지만, 큐 모드의 온디맨드 부분에는 폴러당 최대 1MB/s, 폴러 최대 5개, 합계 5MB/s와 동시 호출 50개가 적혀 있다. 프로비저닝 모드에서는 최소와 최대 폴러 수를 정할 수 있으며 최소는 1~200, 최대는 1~2,000이고 가이드는 여기서 폴러당 최대 5MB/s를 적는다. 페이지마다 모드별로 다른 한도가 나오므로 실제로 쓸 모드의 설명을 읽어야 한다.

익숙한 설정 몇 가지가 달라진다. 큐 모드는 MaximumBatchingWindowInSeconds를 지원하지 않으며, 지정하면 검증 오류가 난다. Kafka 쉐어 컨슈머가 배치의 모든 레코드를 명시적으로 확인 응답해야 하기 때문이다. StartingPosition과 StartingPositionTimestamp도 지원되지 않는다. 큐 모드는 항상 쉐어 그룹의 커밋된 위치에서 읽기 때문이다. MaximumRetryAttempts의 기본값은 0이고, 실패 시 대상이 설정되지 않으면 브로커가 재시도한다. 최대 5개 패턴의 이벤트 필터링, 스키마 레지스트리, 실패 시 대상, 이벤트 소스 매핑 로깅은 지원된다. 큐 매핑은 다른 큐 매핑과만 이벤트 폴러 유닛을 공유한다. 일반 Kafka 가이드도 매핑이 각 이벤트를 최소 한 번 처리하므로 함수 코드를 멱등하게 만들라고 경고한다.

비용에 대해 발표는 표준 Lambda 요금이 적용되고 프로비저닝 모드를 설정한 고객은 이벤트 폴러 유닛 사용량도 지불한다고 말한다. 합리적인 시험은 중요하지 않은 토픽에서 시작하는 것이다. 클러스터 버전과 쉐어 그룹 활성화를 확인하고, 테스트 계정에 큐 매핑을 만들고, 버스트 트래픽을 보내 처리량, 중복, 실패 레코드 처리를 측정한다. 큐 모드는 순서를 없애므로 어떤 컨슈머가 순서를 필요로 하는지 먼저 정해야 한다. 발표에는 처리량 향상 벤치마크가 없으므로 가속 주장은 자신의 테스트에서 나와야 한다.

설계 관점에서 이 기능은 병렬성을 파티션 수로 사는 방식을 메시지 단위로 가져가는 방식으로 바꾸는 것이며, 큐 서비스를 쓰는 방식에 가깝다. 하지만 컨슈머 그룹의 단순 대체물은 아니다. 같은 주문이나 같은 계정의 이벤트 선후 관계에 의존하는 파이프라인은 Stream 모드에 두어야 한다. 토픽 단위로 고르는 것이 좋으며, 순서가 필요한 토픽은 Stream에 남기고 서로 독립적인 작업형 토픽을 Queue로 옮기고, 각 매핑에서 선택한 이유를 기록해 둔다.