[빅데이터를 지탱하는 기술] CH 04. 빅데이터의 축적

CH 04. 빅데이터의 축적

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

객체 스토리지와 데이터 수집

- 분산 스토리지에 데이터 읽어들이기

 

대부분 확장성이 높음 분산스토리지에 저장되지만 객체스토리지 사용이 기본적이긴 하다.

객체 스토리지에서 파일을 읽고 쓸때는 네트워크를 거쳐서 실행하는데, 이때 다수의 하드웨어에 분산함으로써 데이터의 양이 늘어나고 일부에 오류가 발생해도 성능이 떨어지지 않고 문제없이 데이터가 저장된다. 그러나 객체스토리지는 데이터 양이 많을 때는 우수하지만, 소량의 데이터에 대해서는 반대로 비효율적이다. 

따라서 너무 작은 데이터들은 하나의 파일로 합치되 너무 크면 네트워크 전송시간에 문제가 생기므로 적절히 쪼개 주어야 한다.(이 기준은 1메가바이트에서 1기가바이트이다)

 

일반적으로 빅데이터에서는 시계열 데이터를 주로 다룬다. 이를 객체 스토리지에 기록하면 대량의 작은 파일이 생성되므로 적당히 모아서 하나의 큰 파일로 만듦으로써 효율을 높여야 한다. 

반대로 파일이 지나치게 커져서 파일크기가 증가하면 네트워크 정송에 시간이 걸려 오류를 발생시키기도 한다. 이런 경우에는 적당히 나누어서 문제 발생을 줄일 수 있다. 

이렇듯 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 일련의 프로세스가 데이터 수집이다. 

 

벌크형의 데이터 전송

- ETL 서버의 설치 필요성

 

데이터 전송에는 벌크형/ 스트리밍형으로 크게 두가지 종류가 있다. 

먼저 벌크형 전송을 위해서는  ETL서버가 필요하다. 해당 서버에는 구조화된 데이터 처리에 적합한 데이터 웨어하우스를 위한 ETL도구와 오픈소스의 벌크전송 도구 또는 스크립트를 이용하여 데이터를 전송한다.

배치처리는 보통 특정 주기로 실행되고 그 때마다 데이터가 일정하게 축적되어 작업된다. 이 과정에서 태스크를 적절히 나누어서 작업을 관리하는 도구가 워크플로 관리 도구이다. 

 

스트리밍 형의 데이터 전송

- 계속해서 전송되어 오는 작은 데이터를 취급하기 위한 데이터 전송

 

스트리밍 형의 데이터 전송은 계속해서 전송되어 오는 작은 데이터를 취급하는 데이터 전송이다. 이러한 방식을 메시지 배송이라고 한다. 

메시지 배송 시스템은 전송되는 데이터양에 비해 통신을 위한 오버헤드가 커지기 때문에 이를 처리하는 서버는 높은 성능을 요구한다. 

이러한 데이터를 저장하는 방식에는 NoSQL에 저장한 후, Hive와 같은 쿼리엔진과 연결해서 데이터를 읽는 방식이 있고,

메시지 큐와 브로커등의 중계 시스템을 이용해서 전송하는 방식이 있다.

 

여러 애플리케이션에서 메시지를 배송하게 되는데, 웹에서는 fluentd나 logstash라는 메시지 브로커를 사용할 수도 있다. 이들을 서버 상주형 로그 수집 소프트웨어라고 한다. 혹은 HTML페이지에 태그를 삽입해서 웹브라우저에서 직접 메시지를 보내는 웹 이벤트 추적 방식도 있다. 

Fluentd는 메시지 브로커의 역할을 하는 로그 수집 소프트웨어이다. 내부에 효율적인 버퍼링 메커니즘을 갖고 있어서 일정한 시간 간격 또는 특정 사이즈에 외부로 데이터를 모아서 내보낼 수 있다. 
하지만 애초에 메시지 브로커로 설꼐된 것이 아니기 때문에 한계가 있다.
- 여러대로 데이터를 복제할 수 없으므로 만일 노드가 고장나서 버퍼가 사라진다면 보내지 못한 데이터는 없어진다. 
- 메시지를 일방적으로 발송만 할수 있으므로 외부에서 요청해서 메시지를 꺼낼 수 없다. 

모바일의 경우도 웹과 비슷하나, 모바일 앱은 오프라인이 되는 경우도 많으므로 발생한 이벤트를 우선 SDK내부에 축적하고 있다가 온라인 상태가 되었을때 모아서 보낼수도 있다. 

디바이스로부터 메시지배송을 하는 경우는 아직 정확한 규격은 없으나 MQTT를 활용한다. 이는 TCP/IP를 사용하여 데이터를 전송하는 프로토콜의 하나이며, 일반적으로 Pub/sub(전달과 구독) 형 메시지 배송이라는 구조를 가진다.

먼저 관리자에 의해 토픽이 만들어진다, 이것은 메시지를 송수신 하기 위한 대화방과 같은 것으로, 이 토픽을 구독하면 메시비가 도착하게 되고, 그 토픽을 전달하면 구독중인 모든 클라이언트에 보내진다. 이러한 메시지의 교환을 중계하는 서버를 MQTT 브로커라고 하고 메시지를 수신하는 시스템을 MQTT 구독자라고 한다. 

 

일반적으로 데이터소스에 따라서 메시지 배송방식은 다르다. 그러나 공통적으로 클라이언트(메시지가 처음 생성되는 곳)가 있으며, 프론트 엔드는 클라이언트와 통신 프로토콜을 제대로 구현해야 한다. 암호화와 사용자 인증을 구현하여 성능 문제를 해결해야 한다. 

이렇게 받은 메시진느 메시지 브로커로 전송한다. 이후는 분산 스토리지가 할 역할이다. 

 

4-2. 성능과 신뢰성. 메시지 배송의 트레이드 오프 

클라이언트의 수가 많아지면 스트리밍형의 메시지 배송의 성능과 신뢰성을 둘다 만족하기 어려워진다. 이와 관련해서 클라이언트와 분산스토리지 사이에서 메시지 전달을 담당하는 메시지 브로커의 구조와 한계에 대해 이해하는 것이 중요하다.

 

메시지 브로커

-스토리지 성능 문제를 해결하는 중간층의 설치

 

분산 스토리지에 직접적으로 메시지를 배송하면 부하 제어가 힘들기 때문에 그 중간에서 메시지를 받아서 분산 스토리지에 적절하게 전달하는 역할로서 메시지 브로커가 중요하다. (대표적으로 오픈소스로는 kafka, 클라우드로는 kinesis가 있다.)

스트리밍 데이터의 경우 쓰기의 빈도가 점점 증가하고 이에 따라서 부하가 올 가능성이 크기 때문에, 중간에 데이터를 일시적으로 축적하는 중산층이 설치되며 이 것이 메시지 브로커의 역할인 것이다. 

메시지 브로커에 데이터를 넣는 것을 생산자(producer), 꺼내오는 것을 소비자(consumer)라고 한다. 

메시지 브로커는 높은 빈도로 데이터를 쓰는 것에 최적화되어 있으며, 여러대의 노드에 부하 분산함으로써 성능을 끌어올릴 수 있다. 

스트리밍 데이터의 각 용량은 매우 적어서, 그 적은 데이터를 잦은 빈도로 처리하면 부하가 생긴다. 따라서 메시지브로커에서 적절하게 모아서 한꺼번에 파일에 저장한다. 

이렇게 브로커에 모아진 데이터는 여러 용도로 한꺼번에 활용 가능하며 이를 메시지 라우팅이라고 한다.

 

메시지 배송을 확실하게 실시하는 것은 어렵다.

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

 

이러한 메시지 배송에서는 신뢰성 문제가 항상 따른다.

따라서 다음 중 하나를 보장하도록 설계된다.

• at most once : 메시지는 한번만 전송된다. 그러나 메시지 결손 발생 가능성이 있다.
• exactly once : 메시지는 손실되거나 중복없이 한번만 전달된다.
• at least once : 메시지는 확실히 전달된다. 하지만 중복의 가능성이 있다. 

at most once의 경우, 장애 감지시 재전송이 발생하면 지켜지기 힘들다. 메시지를 주고 받는 두 노드 간의 네트워크가 잠깐 끊겼는데, 그 직전에 메시지가 전송되었지만 완료 메시지가 전달되지 않았다면, 전달하는 입장에서는 실패로 인지하고 재전송하게 되어, 중복이 발생할 수 밖에 없기 때문이다.

이를 위해 코디네이터가 존재하여 송수신측 사이를 중계한다. 그러나 코디네이터 또한 통신이 끊길수도 있고, 코디네이터에 전적으로 의존하기에는 효율적이지 않아서, 일반적으로는 중복을 전제로 하고 시스템을 구축한다. 

즉 성능을 보장하되 신뢰성을 보장하기가 힘들다. 

 

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

 

관리자는 중복제거를 위한 구조를 설계해 두어야 한다. 보통 통신이 이루어 질때 식별가능한 시퀀스번호가 포함되는데 이를 통해 중복제거를 하는 것이다. 그러나 분산 시스템에서는 그닥 사용되지 않는다. 

• 오프셋을 이용한 중복제거
  : 각 메시지에 파일 안의 시작위치를 덧붙인다. 메시지가 중복되면 같은 파일의 같은 장소를 덮어쓰게 되는 것이다. 이는 벌크형의 배치처리에 적당하지 스트림 처리에는 적당하지 않다.
• 고유 ID에 의한 중복제거
  : 모든 메시지에 UUID 등의 고유 ID를 지정하는 방법. 모든 아이디를 기억하는 것은 비현실적이므로, 최근에 받은 ID만을 기억하고, 그보다 늦게 온 메시지의 중복은 허용한다. 
  : NoSQL데이터베이스를 활용하는 방법도 있다. 대표적으로 카산드라나 Elasticsearch는 특성상 데이터를 쓸때 고유 ID를 지정하고, 동일한 ID의 데이터는 덮어쓴다. 결과적으로 중복이 있어도 중복제거가 실현된다. 
• 차후에 데이터를 읽어들일때 SQL로 중복 제거

빅 데이터의 메시지 배송은 신뢰성보다는 효율쪽을 중시한다. 따라서 때로는 중복제거도 하지 않기도 한다. 최종적으로 분산스토리지에 저장되기 직전 최종 과정에서 중복 제거를 하고 저장하거나, 분산 스토리지에 저장한 후, 열지향 스토리지에 저장할때 중복제거가 진행된다. 분산스토리지까지 스트리밍으로 저장하다가 열지향 스토리지로 벌크처리하며 데이터를 구조화 하는 것이다. 

메시지 배송 처리에 많은 과정이 있으므로 매 과정마다 중복 제거를 해도 또 어디서 중복이 발생할 수도 있기 때문이다. 

 

데이터 수집의 파이프라인

- 장기적인 데이터 분석에 적합한 스토리지

 

기본적으로 중복을 고려하여 시스템을 설계해야한다. 즉 멱등성을 고려.

 

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

프로세스 시간과 이벤트 시간

- 데이터 분석의 대상은 주로 이벤트 시간

 

프로세스 시간에 의한 분할과 문제점

 

보통 분산 스토리지에 데이터를 넣을 때는 프로세스 시간을 사용한다. 따라서 1월1일에 도착한 데이터지만 과거에 발생한 이벤트를 포함하는 경우도 있다. 

따라서 특정 이벤트 시간에 대한 데이터를 조회하고 싶으면 풀스캔을 해야한다. 이는 부하를 일으키고 한정된 자원의 낭비를 일으키게 된다. 

 

시계열 인덱스

- 이벤트 시간에 의한 집계의 효율화 1.

 

카산드라와 같이 시계열 인덱스에 대응하는 분산 데이터 베이스를 이용해보는 것. 하지만 장기간에 걸쳐서 대량의 데이터를 집계하는 경우에는 적절하지 못하며 결국 열 지향 스토리지를 써야한다.

 

조건절 푸쉬다운

- 이벤트 시간에 의한 집계의 효율화 2.

 

데이터를 배치처리로 이벤트 시간 기준 데이터 정렬한 후에 열지향 스토리지로 변환하는 것이다. 

여기서 필요 최소한의 데이터만을 읽도록 하는 최적화가 조건절 푸시다운이며, 이를 통해 풀스캔을 피한다.

조건절 푸시다운을 최대한 활용하려면 다수의 연속된 데이터를 한 곳에 배치해야한다. 따라서 데이터 정렬이 필요한 것이다. 따라서 열지향 스토리지를 짧은 주기로 만들면 정렬이 잘 이루어지고 잇더라도 데이터 로드가 빈번히 발생해서 최적화의 효과를 낮춘다.

 

이벤트 시간에 의한 분할

- 테이블 파티셔닝, 시계열 테이블

 

이벤트 발생시간을 파티션의 이름에 포함하여 시계열 테이블을 만드는 것이다. 이런 경우 새로운 데이터를 추가할 때 문제가 생긴다. 과거의 데이터가 온 경우, 이미 만들어진 과거의 시계열 테이블에도 계속해서 쓰기 작업이 진행되기 때문이다. 

따라서 데이터 수집 시에는 프로세스시간만으로 효율적으로 진행하고, 데이터 마트를 이벤트 시간에 의해 정렬하도록 할 수도 있다. 

 

4-4. 비구조화 데이터의 분산 스토리지

NoSQL 데이터 베이스에 의한 데이터 활용

 

전달되는 데이터가 커져서 빅데이터가 된다면, 이를 저장하는 분산스토리지 또한 확장성과 유연성이 필요해진다. 객체 스토리지는 임의의 파일을 저장하는 것에는 용이하나, 일반적인 스토리지처럼 교환등의 수정 작업이 불편하다. 또한 트랜잭션 처리를 고려하기 힘들다.

스트리밍형의 메시지 배송은 트랜잭션 처리가 이루어지지 않기 때문에 확실한기록을 보증하는 것이 어렵다. 

 

대표적인 데이터 베이스로는 객체 스토리지인 S3 외에 다양하게 존재한다.

 

분산 KVS

- 디스크로의 쓰기 성능 높이기

 

모든 데이터를 키값쌍으로 저장하도록 설계된 데이터 저장소. 객체스토리지도 넓은 의미에서는 분산 KVS이다. 

모든 데이터에 고유의 키를 지정하고 그것을 부하 분산을 위해 이용한다. 

 

대표적으로 AWS dynamo DB : 임의의 스키마리스 데이터 저장 가능. 마스터/슬레이브 형이 아니라, 모든 노드가 대등한 관계인  P2P형이다. 데이터의 읽기 및 쓰기에 지연이 발생하면 곤란한 애플리케이션에 유용하다. 가령 사용자가 늘어나서 기록하는 빈도가 증가했을 때, 설정을 바꾸는 것만으로 성능이 향상되고 데이터베이스의 지연이 발생하지 않을 수 있다. 

데이터를 분석하기 위해서는 aws의 EMR(대량의 베치처리) 및 redshift와 결합함으로써 hive에 의한 배치처리를 실행하거나 DW에 데이터를 전송할 수 있다. 고유 기능인 dynamo DB  stream을 사용하면 데이터 변경을 이벤트로 외부에 전송해서 실시간 스트림 처리를 할 수 있다. 

 

일반적으로 NoSQL 데이터베이스는 애플리케이션에서 처음에 데이터를 기록하는 장소로 이용된다. 자체적으로는 대량의 데이터를 집계하여 데이터 분석을 하기에는 용이하지 않으므로, 외부로 데이터를 추출해야한다. 

 

와이드 칼럼 스토어

- 구조화 데이터를 분석해서 저장하기

 

분산 KVS를 발전시켜 2개 이상의 임의의 키에 데이터를 저장할수 있음.대표적으로 카산드라, apache Hbase.

내부적으로 행키와 칼럼명의 조합에 대해 값을 저장한다. 테이블에 새로운 행을 추가하는 것과 마찬가지로 칼럼도 얼마든지 추가할 수 있다. 

 

카산드라는 테이블 스키마를 먼저 결정해야 하므로 구조화 데이터만 취급한다. 또한 P2P형 분산 아키텍쳐를 갖고 있다. CQL이라 불리는 쿼리언어가 구현되어있다. 

지정한 키에 의해 결정한 노드에 해당 키와 관련된 모든 값을 저장한다. 그러면 그 노드 안에서 관련되 쿼리가 실행된다. 이를 통해 독립적인 키가 있는 경우에 처리를 잘 분산할 수 있다.

와이드 칼럼 스토어에서 데이터를 집계하기 위해서는 분산된 모든 노드에서 데이터를 모아야 하므로 결국 데이터 집계에 적절하지 않다. 이에 대응하기 위해 데이터를 추출한 후 hive,presto,spark 등의 쿼리엔진이 쓰인다. 

 

도큐먼트 스토어

- 스키마리스 데이터 관리하기

 

와이드 칼럼스토어가 성능 향상을 목표로 한다면, 도큐먼트 스토어는 데이터 처리의 유연성을 목적으로 한다. 

간단한 분산 KVS도 JSON 텍스트로 저장할 수 있지만, 도큐먼스 스토어에서만 중첩된 데이터 구조에 대해 인덱스를 만들거나 도큐먼트 일부만을 치환하는 식의 쿼리를 쉽게 실행할 수 있다.

장점은 스키마를 정하지 않고 데이터 처리를 할 수 있다. 외부에서 들여온 데이터를 저장하는 데 특히 적합하다. 

몽고db가 대표적이다.

 

검색 엔진

- 키워드 검색으로 데이터 검색

 

저장된 데이터를 쿼리로 찾아낸다는 점에서 데이터 베이스와 유사한 부분도 많다. 

텍스트 데이터 검색을 위해 역색인을 만든다. 대표적으로 elasticsearch. 도큐먼트 스토어와 비슷하지만, 쓰기 부하가 더 크고 필요에 따라 명시적으로 스키마를 결정한다. 

색인 작성이 성능향상에 제한적이라 대부분의 NoSQL데이터 베이스에서는 제한하고 있지만, 검색 엔진에서는 읽기에 특화되기 위하여 색인을 적극적으로 권장한다. 

따라서 장기적인 데이터 축적보다는 실시간 집계 시스템의 일부로 이용되기도 한다. 

최근엔 SQL로도 정규표현을 통해 키워드를 찾아내고 패턴에 일치하는 문자열을 추출할 수 있게 되었다. 기존에는 검색엔진 없이는 데이터를 스캔하는 것을 상상도 할 수 없었다. 
빅쿼리를 이용하면 대량의 계산 자원을 이용하여 전체스캔이 가능하다.