AWS Lambda Event Source Mapping과 Confluent-Kafka 연동 시 발생할 수 있는 도전 과제 및 극복 방안

핵심 트렌드

AWS Lambda Event Source Mapping(ESM)과 Confluent-Kafka 라이브러리를 활용한 이벤트 기반 아키텍처(EDA) 구축 시, 기존 Kafka Consumer 패턴과는 다른 접근 방식이 요구됩니다. ESM의 제약 사항을 이해하고 이에 맞춰 설계를 최적화하는 것이 성공의 열쇠입니다.

주요 변화 및 영향

• Kafka Consumer 방식의 변화: ESM이 Kafka 소비를 관리하므로, 개발자는 직접 Consumer 코드를 작성하는 대신 배치된 메시지를 처리하는 Lambda 함수에 집중해야 합니다.
• Polling 제어 불가: ESM의 자동 폴링 간격(500ms)으로 인해 백프레셔나 커스텀 폴링 전략 구현이 어렵습니다.
• Poller 수 제한: ESM의 자동 확장으로 인한 Consumer Group Rebalance 발생 가능성이 있으며, Provisioned 모드가 이를 완화하는 데 도움이 될 수 있습니다.
• 배치 크기 중요성: Lambda 과부하 또는 호출 낭비를 막기 위해 적절한 배치 크기 설정(초기 10-50 메시지 권장) 및 튜닝이 필수적입니다.
• 메시지 단위 오류 처리 불가: 한 메시지 실패 시 전체 배치가 재처리되므로, 초기부터 Idempotency(멱등성)를 설계에 반영해야 합니다.
• Lambda 실패 시 재처리: Lambda 핸들러에서 예외 발생 시, 처리된 모든 메시지와 실패한 메시지, 그리고 실패한 메시지 이후의 메시지까지 모두 재처리됩니다. 따라서 At-least-once(최소 한 번) 전달을 가정하고 개발해야 합니다.
• Dead Letter Topic(DLQ) 필수: 프로덕션 환경에서는 반드시 DLQ를 설정하여 잘못된 메시지로 인한 파티션 차단을 방지해야 합니다.
• Kafka Producer의 Cold Start 문제: Lambda의 Cold Start 시 Kafka Producer 연결 안정성을 확인하고, confluent-kafka-python의 logger 설정을 통해 문제 발생 시 디버깅 가시성을 확보해야 합니다.
• SnapStart 사용 지양: Lambda SnapStart는 librdkafka의 내부 상태 관리와 충돌하여 Producer의 비정상적인 동작을 유발할 수 있으므로 사용하지 않는 것이 좋습니다.

트렌드 임팩트

서버리스 환경에서 Kafka를 활용한 EDA 구축은 기존의 Kafka 개발 방식과는 근본적으로 다른 사고방식을 요구합니다. ESM의 제약을 받아들이고, Push 기반 처리, 멱등성 설계, 배치 중심의 오류 처리, 다계층적 관측 가능성 확보, 실패 모드에 대한 대비가 중요합니다. 이러한 패턴을 이해하고 적용하면 생산성을 크게 높일 수 있습니다.

업계 반응 및 전망

AWS MSK와 Lambda, Confluent-Kafka의 조합은 강력한 EDA 스택을 제공하지만, ESM의 제약으로 인해 전통적인 Kafka 애플리케이션 개발과는 다르다는 점을 명확히 인지해야 합니다. 플랫폼의 제약을 이해하고 설계하는 것이 중요하며, AWS Lambda ESM 문서와 초기 단계부터 작게 시작하여 점진적으로 복잡성을 늘려가는 접근 방식이 권장됩니다.