1. 메시지 순서 보장 문제
1.1 문제 발생
Kafka는 기본적으로 파티션 단위로 메시지의 순서를 보장하지만, 다중 파티션을 사용할 경우 메시지 순서가 보장되지 않는 문제가 발생했다. 이로 인해 서비스의 일관성이 깨지고, 처리 순서가 중요한 비즈니스 로직에 혼란이 발생했다.
1.2 원인
- 다중 파티션 사용 시 순서가 보장되지 않음
- Kafka는 메시지를 여러 개의 파티션에 분산 저장하며, 컨슈머가 다수일 경우 각 컨슈머가 다른 순서로 메시지를 소비할 수 있음
- 리밸런싱(Rebalancing) 과정에서 메시지 순서가 깨짐
- 컨슈머 그룹이 리밸런싱될 경우 특정 컨슈머가 다른 파티션을 처리하게 되어 순서가 깨질 가능성이 존재
1.3 해결책 수립
- 단일 파티션 사용 : 순서를 절대적으로 보장하지만 확장성이 떨어짐
- Kafka Streams를 활용한 순서 재구성 : 운영 부담이 크고 개발이 복잡함
- 메시지 키를 활용하여 동일한 파티션으로 메시지 전송 : 순서를 유지하면서도 확장성이 뛰어남 (최적 해결책)
1.4 해결 방법 선택 및 이유
메시지 키를 활용하여 동일한 파티션으로 메시지를 전송
ProducerRecord<String, String> record = new ProducerRecord<>("order-topic", orderId, orderData);
producer.send(record);
- 선택 이유: 동일한 키(Order ID 등)를 가진 메시지는 같은 파티션에 저장되어 순서가 유지되므로, 다중 파티션을 사용할 경우에도 일관성을 보장할 수 있음. 성능 저하를 최소화하면서도 확장성을 유지할 수 있는 가장 실용적인 방법.
- 다른 방법과의 비교: 단일 파티션을 사용하는 방법은 절대적인 순서를 보장할 수 있으나, 성능 확장성이 제한되므로 현실적으로 적용이 어렵다. 반면, Kafka Streams를 이용한 순서 재구성 방식은 추가적인 개발 및 설정이 필요해 운영 부담이 크다.
2. 중복 메시지 처리 문제
2.1 문제 발생
Kafka는 기본적으로 At-Least-Once 메시징을 보장하기 때문에 컨슈머가 동일한 메시지를 여러 번 소비할 가능성이 발생했다. 이는 데이터의 중복 삽입, 리소스 낭비 및 트랜잭션 오류로 이어질 수 있다.
2.2 원인
- 컨슈머 오프셋 커밋 실패
- 컨슈머가 메시지를 처리한 후 오프셋 커밋 전에 장애가 발생하면 동일한 메시지가 다시 처리될 가능성이 있음
- 프로듀서에서 동일한 메시지가 여러 번 전송될 가능성
- 네트워크 장애 등으로 인해 프로듀서가 동일한 메시지를 여러 번 보낼 수 있음
2.3 해결책 수립
- Kafka의 Exactly-Once Processing 활용 : 중복 방지가 가능하지만 성능 부담이 큼
- Redis 또는 DB를 활용한 중복 방지 로직 추가 : 외부 스토리지가 필요하여 운영 비용 증가
- 멱등한 메시지 처리(Idempotent Consumer) 구현 : 트랜잭션을 단순하게 유지하면서도 중복 처리가 가능 (최적 해결책)
2.4 해결 방법 선택 및 이유
멱등한 메시지 처리(Idempotent Consumer) 구현
- 선택 이유: 가장 일반적인 해결 방법으로, UUID 등의 고유한 ID를 활용해 중복 메시지를 무시함으로써 트랜잭션을 단순하게 유지할 수 있음. Kafka의 Exactly-Once Processing보다 성능 부담이 적고 설정이 간단하여 운영 비용이 낮아짐.
- 다른 방법과의 비교: Kafka의 Exactly-Once Processing 모드는 중복 메시지 문제를 원천적으로 해결할 수 있으나, 성능 부담이 크고 설정이 복잡하여 운영에 부담이 된다. Redis 또는 데이터베이스를 활용한 중복 방지 방식은 단순하지만, 외부 스토리지를 필요로 하므로 유지 비용이 발생한다.
3. 결론
Kafka 운영 과정에서 발생한 메시지 순서 보장 및 중복 메시지 처리 문제를 트러블슈팅한 결과, 주요 해결 방법과 그 이유를 정리하면 다음과 같다.
문제점 | 원인 | 해결 방법 | 선택 이유 |
메시지 순서 보장 문제 | 다중 파티션 사용, 리밸런싱 발생 | 메시지 키 지정 | 확장성과 성능을 고려하여 일관성 유지 가능 |
중복 메시지 처리 문제 | 컨슈머 오프셋 커밋 실패, 중복 전송 | 멱등성 처리 | 설정이 간단하고 성능 부담이 적음 |
'트러블슈팅&기술선택' 카테고리의 다른 글
Elasticsearch의 데이터는 어때야 하는가? (0) | 2025.03.20 |
---|---|
Kafka Exactly-Once에서 At-Least-Once로 변경한 이유 (0) | 2025.03.20 |
Kafka를 선택한 이유: Redis PUB/SUB, RabbitMQ와의 비교 (0) | 2025.03.20 |
Elasticsearch에서 대량 데이터 처리 전략 (0) | 2025.03.20 |
Elasticsearch 클러스터 구성 및 운영 전략 (0) | 2025.03.20 |