[책정리] 빅데이터를 지탱하는기술 4.2 메세지 배송의 트레이드 오프

6월 선정도서 - 빅데이터를 지탱하는 기술

선정계기 - 데이터가 쌓이고 흐르는 전체적인 구조를 깊이 있게 이해할 수 있고,

미래의 데이터엔지니어로써 해야하는 업무들의 전반적인 흐름을 파악할 수 있을 것 같아 선정(기대가 된다

 

목차 

챕터4. 빅데이터의 축적

4-1. 벌크형과 스트리밍형 데이터의 수집

4-2. 메세지 배송의 트레이드 오프

4-3. 시계열데이터의 최적화

4-4. 비구조화 데이터의 분산 스토리지 (Dynamodb/Cassandra/MongoDB/ElasticSearch/Splunk)

 

클라이언트 수가 많아지면 스트리밍형의 메세지배송의 성능과 신뢰성을 둘다 만족시키는 것이 어렵다. 왜? 

---

성능문제 : 메세지브로커

메세지브로커가 없다면? 성능문제 

메세지 배송으로 보내진 데이터들을 분산스토리지에 저장할때 쓰기가 많아지면 디스크성능의 한계에 도달한다.

만약, 쓰기성능의 한계에 도달하면 대부분 클라이언트는 메세지를 재전송한다. 

하지만 아무리 재전송해도 부하가 높아지기만 할 뿐 해결되지 않는다. 

결국 어떻게든 쓰기 성능을 높이거나 재전송을 포기하고 부하가 떨어질때까지 오류를 계속하는 상황을 맞이할 뿐.

 

메세지 브로커란?

빈번한 쓰기에도 견딜수 있도록 성능이 매우 높고, 성능을 언제든지 올릴 수 있는 스토리지.

데이터의 쓰기속도를 조정하기 위한 완충부분, 푸쉬형에서 풀형으로 메세지배송의 타이밍을 변환하는 역할 

높은 빈도로 데이터를 쓰는것에 최적화되어 있으며, 여러대의 노드에 부하분산, 뛰어난 확장성 

Apache Kafka, AWS Kinesis 가 있다. 

 

푸쉬(push)형의 메세지전송 : 송신측의 제어로 데이터를 보내는 방식

이때 메세지 브로커에 데이터를 넣는것을 생산자(producer)

메세지 브로커에 집중시키고 거기에서 일정한 빈도로 꺼낸 데이터를 분산스토리에 기록하므로 성능문제를 해결!

 

풀(Pull)형의 메세지전송 : 수신측의 주도로 데이터를 가져오는 방식 

이때 메세지 브로커에서 데이터를 꺼내오는 것을 소비자(consumer)

프론트엔드에서 대량의 메세지를 받아 매우많은 작은 파일이 생성된다. 

소비자가 브로커로부터 일정한 간격으로 가져온 적당히 모아진 데이터를 분산스토리지 기록->파일 사이즈를 조절한다. 

 

스트림처리 

프론트엔드에서는 메시지 브로커에 데이터를 푸쉬하도록 하고, 그것을 소비자에서 모아서 가져온다. 

이렇게 짧은 간격으로 차례대로 데이터를 꺼내서 처리하는 것이 스트림처리

 

메시지라우팅

메세지 브로커에 써넣은 데이터를 복수의 다른 소비자에서 읽을 수 있다. 

이를 통해 메세지가 복사되어 여러경로로 분기시키는 것이 메시지 라우팅

 

---

신뢰성문제 : 설계방식

신뢰성문제 : 메세지의 중복이나 누락이 발생하더라도 어떻게 처리할 것인지 어떻게 보장할것인지 

 

이를 위한 3가지 설계방식

at most once

메세지는 한번만 전송된다. 무슨일이 있어도 메세지를 다시 보내지 않는다.

그러나 도중에 전송에 실패해서 사라질 가능성은 있기 때문에 이러한 결손을 피하고자 재전송이 이루어진다.

단점 : 데이터가 중간에 손실되거나 데이터중복이 발생할 수 있다. 

 

exactly once

메세지는 손실되거나 중복없이 한번만 전달된다. 

메시지의 송신측과 수신측 모두 서로의 정보를 가운데에서 중계하는 코디네이터에게 전달한다.

그래서 문제가 발생한 경우 코디네이터의 지시에 따라 해결한다. 

단점 : 코디네이터가 항상 존재해야한다, 코디네이터에 너무 의존하다보니 시간이 너무 소요된다. 

 

at least once

메세지를 확실하게 전달한다. 단 같은것이 여러번 전달될 가능성은 있다. 

그래서 중복이 없는 것처럼 보이기 위해 중복을 제거한다. 

apache flume, apache kafka, logstash, fluentd와 같은 대부분의 배송시스템에서 사용하는 방식

 

신뢰성문제: 중복제거방식 

메시지의 데이터중복을 제거하려면 메세지가 과거에 받은 것인지에 대한 여부를 판정해야한다. 

모든 메세지에 일련번호를 붙여 확인할 수 있지만, 이로인해 성능향상이 어려워지기 떄문에 다른방법을 사용한다. 

 

오프셋을 이용한 중복제거 

전송해야할 데이터에 파일명 등의 이름을 부여하고, 시작위치(오프셋)을 덧붙여 작은 메시지에 실어서 배송하는 방법.

메시지가 중복되어도 같은 파일의 같은장소를 덮어쓰기 때문에 데이터중복이 일어나지 않는다. 

벌크형 데이터전송처럼 데이터양이 고정된 경우에 적합하다.

 

고유ID에 의한 중복제거

모든 메세지에  UUID 등 고유ID를 지정하는 방법.

메세지가 늘어남에 따라 ID가 폭발적으로 증가하므로 ID를 관리해야하는 문제가 있지만,

현실적으로 최근에 받은 ID만 기억해두고 그보다 늦게 온 메세지의 중복은 허락한다. 

스트리밍형 데이터전송에서 자주사용한다. 

 

- 분산스토리지로 NoSQL을 사용하는 방법 

Cassandra와 ElasticSearch처럼 데이터를 쓸 때 고유ID를 지정하고, 동일한 ID는 덮어쓴다.

중복이 있더라도 변화가 일어나지 않아 결과적으로 중복제거가 실현된다.

 

-SQL로 중복을 제거하는 방법

보내는 데이터는 그대로 스토리지에 저장하고, 나중에 읽을때 Distinct나 Group by를 이용해 중복을 제거한다. 

메모리에서 실행하는 것은 불가능하고 Hive같은 배치형쿼리엔진에서 실행한다. 

 

End to End의 신뢰성

신뢰성을 높이려면 중간경로를 모두 at least once로 통일한후

클라이언트 상에서 모든 메시지에 고유ID를 포함하도록 하고, 

경로 말단에서 중복제거를 실행해야한다. 

 

 

중복도 손실도 없는 메시지를 배송하는 것은 쉬운일이 아니다. 

그리고 충분한 신뢰성이 실현된다고해도 성능이 낮아지는 트레이드 오프관계

따라서, 신뢰성보다 효율이 중요시 된다. 

중간경로에 at least once를 보장하는 한편 중복제거는 하지 않는 것이 표준적인 구현 

 

---

데이터수집의 파이프라인

이렇게 성능과 신뢰성문제를 고려한 뒤 데이터를 구조화해서 열지향 스토리지로 변환한다.

그럼 장기간의 데이터분석에 적합한 스토리지가 완성되고, 이것이 데이터수집의 파이프라인

 

큰 쓰기 성능을 요구하는게 아닌 경우라면

메세지 브로커 대신 클라이언트나 프론트엔드에서 NoSQL 데이터베이스에 직접 쓰는게 나을 수도 있다. 

 

데이터집계에 쿼리엔진을 사용해야하는 경우라면 

구조화된 데이터를 열지향 스토리지 형식으로 객체스토리지에 저장한다. 

MPP 데이터베이스를 사용하고 있다면 정기적으로 데이터를 로드해서 완성할 수 있다 

 

신뢰성이 매우 중요한 경우라면 (예를 들어 과금데이터처럼 오차가 허용되지 않는 경우)

스트리밍형의 메세지전송은 피하는 것이 좋다. 

중간에 명시적으로 중복제거방식을 도입하지 않는 이상

항상 중복의 가능성이 있고, 아주작은 중복은 무시하는 경향이 있기 떄문에 오차가 허용된다.