1. 개요
이 사용방법(예제)에서는 스트리밍 플랫폼의 메시지 전달 의미 체계에 대해 설명합니다.
먼저 스트리밍 플랫폼의 주요 구성 요소를 통한 이벤트 흐름을 빠르게 살펴보겠습니다. 다음으로 이러한 플랫폼에서 데이터 손실 및 복제에 대한 일반적인 이유에 대해 설명합니다. 그런 다음 사용 가능한 세 가지 주요 전달 의미에 중점을 둘 것입니다.
스트리밍 플랫폼에서 이러한 의미 체계를 달성하는 방법과 데이터 손실 및 중복 문제를 처리하는 방법에 대해 논의할 것입니다.
각각의 전달 의미론에서 우리는 Apache Kafka에서 전달 보장을 얻는 방법을 아주 간략하게 다룰 것입니다.
2. 스트리밍 플랫폼의 기본
간단히 말해서 Apache Kafka 및 Apache ActiveMQ 와 같은 스트리밍 플랫폼 은 하나 이상의 소스(생산자라고도 함)에서 실시간 또는 거의 실시간 방식으로 이벤트를 처리하고 추가 처리를 위해 하나 이상의 대상(소비자라고도 함)에 전달합니다. , 변환, 분석 또는 저장.
생산자와 소비자는 브로커를 통해 분리되어 확장성이 가능합니다.
스트리밍 애플리케이션의 일부 사용 사례는 전자 상거래 사이트의 대량 사용자 활동 추적, 실시간 방식의 금융 거래 및 사기 탐지, 실시간 처리가 필요한 자율 모바일 장치 등이 될 수 있습니다.
메시지 전달 플랫폼에는 두 가지 중요한 고려 사항이 있습니다 .
- 정확성
- 지연 시간
종종 분산 된 실시간 시스템 에서는 시스템 에 더 중요한 것이 무엇인지에 따라 지연 시간과 정확도 사이에 균형을 맞춰야 합니다.
여기에서 스트리밍 플랫폼이 제공하는 배달 보장을 즉시 이해하거나 메시지 메타데이터 및 플랫폼 구성을 사용하여 원하는 것을 구현해야 합니다.
다음으로 스트리밍 플랫폼의 데이터 손실 및 복제 문제를 간략하게 살펴본 다음 이러한 문제를 관리하기 위한 전달 의미론에 대해 논의하도록 하겠습니다.
3. 가능한 데이터 손실 및 복제 시나리오
스트리밍 플랫폼의 데이터 손실 및/또는 중복을 이해하기 위해 빠르게 뒤로 물러나서 스트리밍 플랫폼에서 높은 수준의 이벤트 흐름을 살펴보겠습니다.
여기에서 생산자에서 소비자로의 흐름을 따라 잠재적으로 여러 실패 지점이 있을 수 있음을 알 수 있습니다.
종종 이로 인해 데이터 손실, 지연 및 메시지 중복과 같은 문제가 발생합니다.
위 다이어그램의 각 구성 요소에 초점을 맞추고 무엇이 잘못될 수 있고 스트리밍 시스템에 미칠 수 있는 결과를 살펴보겠습니다.
3.1. 생산자 실패
다음과 같은 문제가 발생할 수 있습니다.
- 생산자가 메시지를 생성한 후 네트워크를 통해 보내기 전에 실패할 수 있습니다. 이로 인해 데이터가 손실될 수 있습니다.
- 브로커로부터 승인을 받기 위해 기다리는 동안 생산자가 실패할 수 있습니다. 생산자가 복구되면 브로커의 승인이 누락된 것으로 가정하여 메시지를 다시 보내려고 합니다. 이로 인해 브로커에서 데이터 중복이 발생할 수 있습니다 .
3.2. 생산자와 브로커 간의 네트워크 문제
생산자와 브로커 사이에 네트워크 장애가 있을 수 있습니다.
- 생산자는 네트워크 문제로 인해 브로커에 도달하지 못한 메시지를 보낼 수 있습니다.
- 브로커가 메시지를 수신하고 승인을 보내지만 생산자가 네트워크 문제로 인해 승인을 받지 못하는 시나리오도 있을 수 있습니다.
이 두 경우 모두 생산자는 메시지를 다시 보내므로 브로커에서 데이터가 중복됩니다 .
3.3. 브로커 실패
마찬가지로 브로커 오류로 인해 데이터 중복이 발생할 수도 있습니다.
- 메시지를 영구 저장소에 커밋하고 생산자에게 승인을 보내기 전에 브로커가 실패할 수 있습니다. 이로 인해 생산자로부터 데이터가 다시 전송되어 데이터가 중복될 수 있습니다.
- 브로커는 소비자가 지금까지 읽은 메시지를 추적하고 있을 수 있습니다. 이 정보를 커밋하기 전에 브로커가 실패할 수 있습니다. 이로 인해 소비자가 동일한 메시지를 여러 번 읽게 되어 데이터가 중복될 수 있습니다.
3.4. 메시지 지속성 문제
메모리 내 상태에서 디스크에 데이터를 쓰는 동안 오류가 발생하여 데이터가 손실될 수 있습니다.
3.5. 소비자와 브로커 간의 네트워크 문제
브로커와 소비자 사이에 네트워크 장애가 있을 수 있습니다.
- 브로커가 메시지를 보내고 메시지를 보냈다는 기록에도 불구하고 소비자는 메시지를 수신하지 못할 수 있습니다.
- 마찬가지로 소비자는 메시지를 받은 후 승인을 보낼 수 있지만 승인은 브로커에 도달하지 못할 수 있습니다.
두 경우 모두 브로커는 데이터 중복으로 이어지는 메시지를 다시 보낼 수 있습니다.
3.6. 소비자 실패
- 소비자는 메시지를 처리하기 전에 실패할 수 있습니다.
- 소비자는 메시지를 처리한 지속성 저장소에 기록하기 전에 실패할 수 있습니다.
- 소비자는 메시지를 처리했다는 것을 기록한 후 승인을 보내기 전에 실패할 수도 있습니다.
이로 인해 소비자가 브로커에게 동일한 메시지를 다시 요청하여 데이터 중복이 발생할 수 있습니다.
다음으로 개별 시스템 요구 사항을 충족하기 위해 이러한 문제를 처리하기 위해 스트리밍 플랫폼에서 사용할 수 있는 전달 의미 체계를 살펴보겠습니다.
4. 전달 의미론
전달 의미론은 스트리밍 플랫폼이 스트리밍 애플리케이션에서 소스에서 대상으로 이벤트 전달을 보장하는 방법을 정의합니다.
세 가지 다른 전달 의미 체계를 사용할 수 있습니다.
- 최대 한 번
- 적어도 한 번
- 정확히 한 번
4.1. 최대 1회 배송
이 접근 방식 에서 소비자는 마지막으로 수신된 이벤트의 위치를 먼저 저장한 다음 처리합니다.
간단히 말해서, 이벤트 처리가 중간에 실패하면 소비자가 다시 시작될 때 이전 이벤트를 읽기 위해 돌아갈 수 없습니다.
따라서 수신된 모든 이벤트에서 이벤트가 성공적으로 처리된다는 보장은 없습니다.
기껏해야 의미 체계는 일부 데이터 손실이 문제가 되지 않고 정확성이 필수 사항이 아닌 상황에 이상적입니다.
메시지에 오프셋을 사용하는 Apache Kafka의 예를 고려할 때 At-Most-Once 보증 순서는 다음과 같습니다.
- 오프셋 유지
- 결과 지속
Kafka에서 At-Most-Once 의미 체계를 활성화 하려면 소비자에서 " enable.auto.commit" 을 " true" 로 설정해야 합니다.
오류가 있고 소비자가 다시 시작되면 마지막으로 지속되는 오프셋을 확인합니다. 오프셋은 실제 이벤트 처리 이전에 유지되기 때문에 소비자가 수신한 모든 이벤트가 성공적으로 처리되었는지 여부를 확인할 수 없습니다. 이 경우 소비자는 일부 이벤트를 놓치게 될 수 있습니다.
이 의미를 시각화해 보겠습니다.
4.2. 최소 1회 배달
이 접근 방식에서 소비자는 수신된 이벤트를 처리하고 결과를 어딘가에 유지한 다음 마지막으로 수신된 이벤트의 위치를 저장합니다.
최대 한 번과 달리 여기에서는 실패 시 소비자가 이전 이벤트를 읽고 다시 처리할 수 있습니다.
일부 시나리오에서는 이로 인해 데이터가 중복될 수 있습니다. 소비자가 이벤트를 처리하고 저장한 후 마지막으로 알려진 이벤트 위치(오프셋이라고도 함)를 저장하기 전에 실패하는 예를 살펴보겠습니다.
소비자는 다시 시작하고 오프셋에서 읽습니다. 여기서 소비자는 실패 전에 메시지가 성공적으로 처리되었지만 마지막으로 수신된 이벤트의 위치가 성공적으로 저장되지 않았기 때문에 이벤트를 두 번 이상 재처리합니다.
이 접근 방식은 현재 값을 표시하도록 티커 또는 게이지를 업데이트하는 모든 애플리케이션에 이상적입니다. 그러나 합계 및 카운터와 같이 집계의 정확성이 필요한 사용 사례는 주로 중복 이벤트로 인해 잘못된 결과가 발생하기 때문에 최소 1회 처리에 적합하지 않습니다.
결과적으로 이 전달 의미 체계에서는 데이터가 손실되지 않지만 동일한 이벤트가 다시 처리되는 상황이 있을 수 있습니다 .
동일한 이벤트를 여러 번 처리하는 것을 피하기 위해 멱등원 소비자를 사용할 수 있습니다 .
본질적으로 멱등성 소비자는 메시지를 여러 번 사용할 수 있지만 한 번만 처리합니다.
다음 접근 방식을 조합하면 멱등 소비자가 최소 한 번 배달할 수 있습니다.
- 생산자는 각 메시지 에 고유한 messageId 를 할당합니다.
- 소비자는 데이터베이스에서 처리된 모든 메시지의 기록을 유지 관리합니다.
- 새 메시지가 도착하면 소비자는 영구 저장소 테이블의 기존 messageId 와 비교하여 확인합니다.
- 일치하는 항목이 있는 경우 소비자는 다시 소비하지 않고 오프셋을 업데이트하고 승인을 다시 보내고 메시지를 소비된 것으로 효과적으로 표시합니다.
- 이벤트가 아직 없으면 데이터베이스 트랜잭션이 시작되고 새 messageId 가 삽입됩니다. 다음으로 이 새 메시지는 필요한 비즈니스 로직에 따라 처리됩니다. 메시지 처리가 완료되면 트랜잭션이 최종적으로 커밋됩니다.
Kafka에서 최소 한 번 의미 체계를 보장하기 위해 생산자는 브로커의 승인을 기다려야 합니다.
생산자는 브로커로부터 승인을 받지 못한 경우 메시지를 다시 보냅니다.
또한 생산자가 일괄적으로 브로커에 메시지를 쓰기 때문에 해당 쓰기가 실패하고 생산자가 재시도하면 일괄 처리 내의 메시지가 Kafka에서 두 번 이상 기록될 수 있습니다.
그러나 중복을 피하기 위해 Kafka는 멱등 생산자 기능을 도입했습니다.
기본적으로 Kafka에서 최소 한 번 의미 체계를 활성화하려면 다음을 수행해야 합니다.
- 생산자 측에서 " ack " 속성 을 값 "1" 로 설정합니다.
- 소비자 측에서 " enable.auto.commit " 속성을 " false " 값으로 설정합니다.
- " enable.idempotence " 속성을 " true " 값으로 설정
- 생산자의 각 메시지에 시퀀스 번호와 생산자 ID를 첨부합니다.
Kafka Broker는 시퀀스 번호와 생산자 ID를 사용하여 주제에 대한 메시지 중복을 식별할 수 있습니다.
4.3. 정확히 한 번 배달
이 전달 보장은 최소 한 번 의미 체계와 유사합니다. 먼저 수신된 이벤트를 처리한 다음 결과를 어딘가에 저장합니다. 실패하고 다시 시작하는 경우 소비자는 이전 이벤트를 다시 읽고 다시 처리할 수 있습니다. 그러나 최소 한 번 처리와 달리 중복 이벤트는 삭제되고 처리되지 않으므로 정확히 한 번 처리됩니다.
이는 정확한 카운터와 같은 집계를 포함하는 애플리케이션 또는 손실 없이 한 번만 처리되는 이벤트가 필요한 애플리케이션과 같이 정확성이 중요한 모든 애플리케이션에 이상적입니다.
시퀀스는 다음과 같이 진행됩니다.
- 결과 지속
- 오프셋 유지
소비자가 이벤트를 처리한 후 실패했지만 오프셋을 저장하지 않은 경우 아래 다이어그램에서 어떤 일이 발생하는지 살펴보겠습니다.
다음을 사용하여 정확히 한 번 의미 체계에서 중복을 제거할 수 있습니다.
- 멱등성 업데이트 – 생성된 고유 키 또는 ID에 대한 결과를 저장합니다. 중복의 경우 생성된 키 또는 ID가 이미 결과(예: 데이터베이스)에 있으므로 소비자는 결과를 업데이트하지 않고 중복을 제거할 수 있습니다.
- 트랜잭션 업데이트 – 트랜잭션을 시작하고 트랜잭션을 커밋해야 하는 배치에 결과를 저장하므로 커밋이 발생하면 이벤트가 성공적으로 처리됩니다. 여기서는 결과 업데이트 없이 중복 이벤트를 삭제하기만 하면 됩니다.
Kafka에서 정확히 한 번 의미 체계 를 활성화하기 위해 무엇을 해야 하는지 봅시다 .
- 각 생산자에 대해 " transaction.id "에 대한 고유 값을 설정하여 생산자에서 멱등 생산자 및 트랜잭션 기능을 활성화합니다.
- " isolation.level " 속성을 " read_committed " 값 으로 설정하여 소비자에서 트랜잭션 기능을 활성화합니다 .
5. 결론
이 기사에서는 스트리밍 플랫폼에서 사용되는 세 가지 전달 의미의 차이점을 살펴보았습니다.
스트리밍 플랫폼의 이벤트 흐름에 대한 간략한 개요 후 데이터 손실 및 중복 문제를 살펴보았습니다. 그런 다음 다양한 전달 의미 체계를 사용하여 이러한 문제를 완화하는 방법을 살펴보았습니다. 그런 다음 최소 한 번 전달, 최대 한 번 및 마지막으로 정확히 한 번 전달 의미 체계를 살펴보았습니다.
