메시지 브로커를 포함한 데이터 수집 파이프라인과 함께 메시지 브로커에서 at least once를 통해 메시지가 중복으로 올 때,

이를 어떻게 중복제거를 할지 공부한 것을 정리한다.

우선 지금까지 설명한 것을 바탕으로 데이터 파이프라인의 구성을 한 번 살펴보려고 한다.

아래 그림은 설명하기에 적절한 그림을 찾지 못해 직접 아이패드와 애플펜슬로 Notability 앱을 이용해 그렸다.

Data Pipeline by loustler

A는 데이터 파이프라이닝의 프론트 서버다.

여기에서는 B에 메시지(스트리밍 데이터)를 보내기 전에 필요한 전처리를 담당한다.

A는 서버로 가급적이면 가볍게 구성하여 빠르게 메시지들을 B로 보내줄 수 있게 하는게 좋겠다.

예를 들어서,

  1. 인증
  2. 암호화
  3. validation

등과 같은 것들을 한다.

이렇게 전처리를 하고 난뒤에 적절한 메시지를 B에 보내주는데 이 메시지들을 받는 B는 메시지 브로커(Message Broker)이다.

보통 메시지 브로커는 클러스터로 구성하고 메시지를 수신하여 적절한 곳에서 이 수신한 메시지들을 가져가서 사용할 수 있게 해준다.

예를 들어 Kafka가 있다.

메시지 브로커 입장에서 A는 Producer(생산자), C는 Consumer(소비자)이다.

이렇게 B에 메시지들을 모으고 나면 이를 처리하는 스트리밍 프로세싱인 C가 등장하여 메시지 브로커의 메시지들을 소비한다(consume).

C는 Apache Storm이나 Spark Stream

A-C까지 보면 거의 실시간으로 일어나고 있는 것이라고 봐도 무방하다

이렇게 B(메시지 브로커)로부터 받은 메시지들은 D에 저장한다.

D는 분산 스토리지로 HDFS나 S3를 떠올리면 된다.

E의 경우는 NoSQL DB인데, HBase 같은 것을 생각하면 되겠다.

D 위에 E가 있고, 이런 E에 저장을 하면 결국 D로 저장이 되는 그런 형식을 말한다.

파이프라인의 전체 흐름을 본인의 경험과 빗대어 설명을 하면

  1. 데이터를 서버에 보냄
  2. 서버에서는 인증, 암호화, validation을 비롯한 각종 필요한 전처리를 하고 메시지 브로커(카프카)에 전송(produce)
  3. Storm(혹은 Spark stream)을 이용하여 kafka의 topic을 consume하여 필요한 스트리밍 프로세스를 처리한 뒤 NoSQL DB인 HBase에 저장

이렇게 전체 흐름을 잡을 수 있겠다.

여기에서 추가적으로 Columnar DB로 변환하는 등 DW나 Data Mart를 위한 작업을 할 수도 있다.

메시지 브로커는 보통 기본 설정이 At Least Once를 통해 메시지의 수신을 보장해준다.

그럼 이 때 발생할 수 있는 메시지의 중복은 어떤 방법으로 처리할 수 있을까?

사실 그 방법 중 하나가 이미 데이터 파이프라인 안에 있다.

바로 E였던 NoSQL DB을 사용하는 것이다.

HBase와 같은 NoSQL DB는 저장할 때 key를 입력하게 되어 있고, 이를 통해 저장을 하게 된다.

그리고 HBase는 별도의 update가 없으며 모두 upsert 즉, overwrite 덮어쓰기를 한다.

key에 데이터가 없으면 새로 생기고, 있으면 덮어써버린다.

이 특성을 이용하여 중복을 제거한다.

이 방법 외에도

  1. 오프셋을 활용
  2. UUID 와 같은 ID를 사용하는 방법

등이 있다.

간랸하게 소개하면

오프셋은 각 메시지에 오프셋을 붙임으로써 중복이 일어나더라도 이 오프셋에 의해 덮어씌워짐으로써 중복이 없어지게끔 하는 것이고,

UUID를 이용하는 방법은 UUID를 각 메시지에 붙여서 이 메시지들을 캐시해두고 있으면서 중복된 것은 처리하지 않는다거나 하는 것이다.

이 때, 캐시를 할 때에는 메시지 양에 따라 다르겠지만 보통 시간단위로 한다. 이정도만 해도 높은 신뢰도를 달성할 수 있기 때문이다.

이로써 위의 데이터 파이프라인에 이어서 메시지 브로커를 통해 중복된 메시지를 받게 되었을 때, 이를 중복제거 하는 방법까지 간단하게 알아봤다.


포스트에 대한 피드백이 있으시다면 여기로 메일 부탁드립니다. 읽어주셔서 감사합니다.