[빅데이터의 축적] 2. 메시지 배송의 트레이드 오프

---

이 글은 빅데이터를 지탱하는 기술을 읽고 정리한 글입니다.

---

 

 

 

1. 메시지 브로커

---

메시지 배송에 의해 보내진 데이터를 분산 스토리지에 저장할 때는 외부에서 보내오는 메시지의 양을 제어할 수 없기 때문에 디스크 쓰기의 성능 한계에 도달하여 쓸 수 없을 수도 있으므로 주의가 필요하다.

만약 성능 한계에 도달하면 클라이언트는 메시지를 다시 보내려고 하지만, 저장이 될리가 없어서 부하만 높아지고 아무것도 해결이 되지 않는다. 이것을 해결하려면 쓰기 성능을 높이거나 클라이언트가 재전송을 포기하고 부하가 떨어질 때까지 오류가 계속되는 상황을 맞이할 수 밖에 없다.

 

메시지 브로커

대량의 메시지를 안정적으로 받기 위해서는 성능이 매우 높고, 필요에 따라 성능을 더 올릴 수 있는 스토리지가 필요하다. 하지만 분산 스토리지는 반드시 저런 특징을 지녔다고 할 수 없기 때문에 메시지 배송 시스템에서 데이터를 일시적으로 축적하는 중산층이 설치되는데, 이것을 메시지 브로커라고 부른다. 메시지 브로커는 높은 빈도로 데이터를 쓰는 것에 최적화되어 있고, 여러 대의 노드에 부하를 분산시켜 성능을 끌어 올릴 수 있는 뛰어난 확장성을 구현하였다.

대표적인 분산형 메시지 브로커는 오픈소스에서 카프카(Apache Kafak)가 유명하고, 클라우드쪽은 키네시스(Amazon Kinesis)가 유명하다.

 

* AWS → Kafka → SQL 순인 토이 프로젝트들이 다른 블로그에서 종종 보인다.

 

 

푸쉬(push) 형

- 송신 측의 제어로 데이터를 보내는 방식이다.

- 메시지 브로커에 데이터를 넣으면 생산자라고 부른다.

- 메시지 배송을 메시지 브로커에 집중시켜 일정하게 꺼낸 데이터를 분산 스토리지에 기록하여 성능 문제를 해결한다.

 

풀(pull) 형

- 수신 측의 주도로 데이터를 가져오는 방식이다.

- 메시지 브로커에서 데이터를 꺼내면 소비자라고 부른다.

- 소비자가 메시지 브로커로부터 일정한 간격으로 데이터를 얻어 분산 스토리지에 기록하기 때문에 파일 사이즈 적정화에도 도움이 된다. 

 

스트림 처리

대량의 데이터를 한 번에 데이터베이스에 기록을 하려고 하면 데이터베이스에 부하가 생긴다. 프론트 엔드에서 메시지 브로커에 데이터를 푸쉬하도록 하고, 그것을 소비자에서 모아 가져와 일정한 간격으로 작은 데이터를 데이터베이스가 처리를 할 수 있도록 한다. 이렇게 짧은 간격으로 차례대로 데이터를 꺼내서 처리하는 것을 스트림 처리라고 부른다.

 

메시지 라우팅

메시지 브로커에 써넣은 데이터는 다른 소비자들이 읽어 들일 수 있다. 이를 통해 메시지가 복사되어 데이터를 여러 경로로 분기시킬 수 있는데, 이것을 메시지 라우팅이라고 부른다.

---

 

 

 

2. 신뢰성 문제와 세 가지 설계 방식

---

신뢰성이 낮은 네트워크에서는 반드시 메시지의 중복이나 누락이 발생하기 때문에 신뢰성 문제가 생긴다.

그래서 이것을 어떻게 처리할 지에 대한 세 가지 시스템이 있는데, 대부분 이중에 하나를 무조건 보장할 수 있도록 한다.

 

at most once 

무슨 일이 있어도 메시지는 단 한 번만 전송한다. 전송이 실패해도 다시 보내지 않아 결손 문제가 발생할 수 있다.

그러나 대부분은 데이터의 결손을 피하고자 재전송이 이루어지기 때문에 at most once를 보장하기 어렵다.

 

exactly once

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

양쪽의 통신 내용을 보장하기 위해 그 사이를 중계하는 코디네이터를 사용하여, 문제가 생긴 경우 코디네이터의 지시에 따라 해결한다. 하지만 이러면 아래 두 가지 문제점이 생긴다.

 

1. 분산 시스템에서 무조건 코디네이터가 존재한다고 할 수 없다. 만약 코디네이터가 존재하지 않는 경우 합의를 해야하는데, 이것은 분산 시스템 설계에서 어려운 문제 중의 하나이다.

2. 코디네이터의 판단에만 따르고 있으면 시간이 너무 소요가 된다는 점이다.

 

그래서 위 두 문제점 때문에 메시지 배송 시스템은 at least once을 보장하여 시스템을 구축한다.

 

at least once

메시지는 확질히 전달되는데, 같은 것이 여러 번 전달될 가능성이 있다.

만약 메시지가 재전송되어도 중복 제거 구조를 통하여 중복이 없는 것처럼 보이게 할 수 있다. 하지만 대부분의 메시지 배송 시스템은 중복 제거를 이용자에게 맡긴다.

Apache Flume, Apache Kafka, Logstach, Fluentd가 at least once를 보장한다.

---

 

 

 

3. 중복 제거는 높은 비용의 오퍼레이션

---

메시지 중복을 제거하려면 과거에 같은 메시지를 받았는지 확인을 해야하기 때문에 성능 향상이 어려워지기 때문에 아래와 같은 방법을 사용한다.

 

오프셋을 이용한 중복 제거

전송해야할 데이터에 파일명 등의 이름을 부여해 작은 메시지에 실어서 배송한다. 각 메시지에는 파일 안의 시작 위치(오프셋)을 덧붙인다. 만일 메시지가 중복되어도 오프셋을 통해 같은 파일의 같은 장소를 덮어 쓰기 때문에 문제가 되지 않는다.

이 방법은 벌크 형의 데이터 전송과 같이 데이터양이 고정된 경우에는 잘 작동하지만, 스트리밍 형의 데이터 전송에는 사용하지 않는다.

 

고유 ID에 의한 중복 제거

스트리밍 형의 메시지 배송에서 자주 사용되는 것은 모든 메시지에 고유 ID를 지정하는 방법이다.

최근에 받은 ID만을 기억하여 중복 관리를 하고, 과거에 전송된 ID를 저장하면 관리가 힘들어지니 메시지 중복을 허용한다.

고유 ID를 이용하여 중복을 제거하는 방법에는 대표적으로 두 가지 방법이 있다.

 

1. NoSQL 데이터베이스를 사용

→ Cassandra와 Elasticsearch 등은 특성상 데이터를 지정할 때 고유 ID를 지정하게 되어 있어 동일한 ID의 데이터는 덮어쓰기 때문에 중복 제거가 실현된다.

 

2. SQL로 중복을 제거하는 것

일단 객체 스토리지에 모든 데이터를 저장한 후에, Hive와 같은 배치형 쿼리 엔진에서 DISTINCT나 GROUP BY를 사용하여 대규모 데이터를 중복 제거를 처리하게 만든다.

 

End to End(종단간)의 신뢰성

빅데이터의 메시지 배송은 종종 신뢰성보다 효율성을 중시하는데 이 경우엔 중간 경로는 at least once를 보장하지만, 중복 제거를 하지 않도록 구현한다.

신뢰성이 높은 메시지 배송을 실현하려면 중간 경로를 모두 at least once로 통일하고, 클라이언트 상에서 모든 메시지에 고유 ID를 포함하도록 하여서 경로의 말단에서 중복 제거를 실행해야 한다.

---

 

 

 

4. 데이터 수집의 파이프라인

---

클라이언트 → 프론트엔드 → 메시지 브로커 → 소비자 → 분산 스토리지 → 중복 제거 → 데이터를 구조화하여 열 지향 스토리지로 변환 → 완성

이 과정이 스트리밍 형의 장기간의 데이터 분석에 적합한 스토리지이다.

 

- 쓰기 성능이 안정적이라면 메시지 브로커는 필요하지 않으니 클라이언트나 프론트엔드에서 NoSQL 데이터베이스에 직접 데이터를 쓰는 것도 좋다.

- 데이터 집계에 쿼리 엔진을 사용하는 경우에는 구조화된 데이터를 열 지향 스토리지 형식으로 객체 스토리지에 저장한다.

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

 

중복을 고려한 시스템 설계

일반적으로 스트리밍 형의 메시지 배송에서는 중간에 중복 제거 방식을 도입하지 않는한 데이터 중복이 있다고 가정한다. 빅데이터를 다루는 시스템은 매우 높은 성능을 요구하고 있기 때문에 아주 작은 중복을 무시하는 경향이 있는데, 이정도 오차로는 큰 문제가 발생하지 않는다. 그러나 신뢰성이 중시되는 경우에는 스트리밍 형의 메시지 배송을 피하는 것이 가장 좋다.

---