빅데이터를 지탱하는 기술[4]
Chapter 4. 빅데이터의 축적
데이터 전송에는 벌크형과 스트리밍형의 도구가 사용된다. 이 장에서는
각각의 방법으로 분산 스토리지에 데이터가 저장될 때 까지의 흐름에 대해 살펴본다.
객체 스토리지와 데이터 수집 — 분산 스토리지에 데이터 읽어들이기
빅데이터는 대부분의 경우 확장성이 높은 분산 스토리지에 저장된다.
- 데이터수집
작은 데이터는 적당히 모아서 하나의 큰 파일로 만듦으로써 효율을 높이는데 도움이 된다. 하지만 파일이 지나치게 커지는 것도 network latency등에 따라 오류발생률도 높아지기 때문에 적당히 나누어 문제 발생을 줄이는 것이 필요하다.
빅데이터는 단지 수집만 해서는 안되고, 나중에 처리하기 쉽도록 준비해 둘 필요가 있다.
수집한 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 프로세스를 데이터수집이라고 한다.
벌크형의 데이터 전송 — ETL 서버의 설치 필요성
전통적인 DW에서 사용된 것은 주로 벌크형 방식으로, 데이터베이스나 파일 서버 또는 웹 서비스 등에서 SQL이나 API등으로 정리해 데이터를 추출한다.
원래 데이터가 처음부터 분산 스토리지에 저장되어 있는 것이 아니라면 데이터 전송을 위한 ETL서버를 설치한다. ETL 서버에는 구조화 된 데이터 처리에 적합한 DW를 위한 ETL도구와 오픈소스의 벌크전송도구 또는 스크립트 등을 이용하여 데이터를 전송한다.
많은 양의 데이터를 전송할 경우 워크플로우 관리 도구를 이용하여 테스크 실행을 쉽게 관리할 수 있다.
스트리밍형의 데이터 전송
계속해서 네트워크를 통해 전송되는 데이터는 벌크형으로 모으는것은 불가능하므로, 스트리밍형의 데이터 전송이 필요하다. 이러한 데이터 전송 방식을 배시지 배송(message delivery) 이라고 하며, 메시지 배송 시스템은 전송되는 데이터양에 비해 통신을 위한 오버헤드가 커지기 때문에 이를 처리하는 서버는 높은 성능을 요구한다.
보내온 메시지를 저장할때는 작은 데이터 쓰기에 적합한 NoSQL 데이터베이스를 사용하거나, 직접 분산스토리지에 저장하지 않고 메시지큐나 메시지 브로커등의 중계시스템을 통해 일정한 간격으로 꺼내고 모아서 함께 분산 스토리지에 저장한다.
메시지브로커 — 스토리지의 성능 문제를 해결하는 중간층의 설치
외부에서 보내오는 메시지의 양은 제어할 수 없기 때문에 급격한 데이터양의 증가에 대응하는 것은 쉬운 일이 아니다. 쓰기 성능의 한계에 의해 오류가 발생하는 경우 일반적으로 클라이언트는 메시지를 재전송하려고 하지만, 문제는 해결되지 않는다. 결국 클라이언트가 재전송을 보기하고 부하가 떨어질 때까지 문제는 해결되지 않는다.
그렇기 때문에 성능이 매우 높고, 필요에 따라 성능을 자유롭게 올릴 수 있는 스토리지가 필요하다. 분산 스토리지가 반드시 그런 성격을 가진것은 아니기 때문에, 데이터를 일시적으로 축적하는 중산층을 설치하는데 이를 메시지브로커라고 한다.
메시지 배송을 확실하게 하는것은 어렵다 — 신뢰성 문제와 3가지 설계방식
네트워크전송중에는 반드시 메시지의 중복이나 누락이 발생한다.
대부분의 경우는 다음중 하나를 보장하도록 설계된다.
- at most once
메시지는 한번만 전송된다. 그러나 도중에 전송에 실패하여 데이터가 누락될 가능성이 있다.
송신중 수신완료인 ack가 반환되기 이전에 네트워크통신이 중단되었다고 가정하자. 송신측에서는 재전송을 요청하고, 수신측에서는 이미 메시지를 받았기 때문에 계속해서 데이터 처리를 진행해버린다. 이후 접속이 재개되면 메시지가 재전송되므로, 중복이 발생한다. - exactly once
메시지는 손실되거나 중복 없이 한번만 전달된다.
양쪽의 통신 내용을 보장하기 위해 중간에 코디네이터를 설치한다. 하지만 코디네이터가 중단될 경우도 있으며, 성능문제로 시간이 오래 소요된다는 문제가 있기 때문에 왠만하면 코디네이터를 도입하지 않고, 중복을 고려하여 시스템을 구축한다.(at least once) - at least once
메시지는 확실히 전달된다. 단, 중복의 가능성이 있다.
메시지의 재전송에 의한 중복이 발생하지만, 시퀀스번호를 확인하고 같은 번호의 패킷은 중복되고 파기시킨다.
중복제거의 방법
분산시스템에서 시퀀스는 그다지 사용되지 않는다. 모든 메시지에 시퀀스를 넣으려면 어딘가에 처리를 집중시킬 필요가 있으며, 이로 인해 성능 향상이 어려워지기 때문이다.
- 오프셋을 이용한 중복제거
각 메시지에 파일 안의 시작위치를 덧붙인다. 만일 메시지가 중복되어도 같은 파일의 같은 장소를 덮어쓸 뿐이므로 문제가 되지 않는다.
하지만 이 방법은 벌크형과 같이 전송할 데이터양이 고정인 경우에는 잘 작동하지만, 스트리밍형식에서는 잘 사용하지 않는다.
- 종단간 (End to End)의 신뢰성
빅데이터의 메시지 배송에서는 종종 신뢰성보다 효율이 중시된다.
클라이언트가 메시지를 중복해서 보내더라도 최종 도달되는 분산스토리지에서는 중복이 이루어지지 않아야 한다.
신뢰성이 높은 메시지 배송을 실현하려면 중간 경로를 모두 at least once로 통일한 후 모든 메시지에 고유 ID를 포함하도록 하고, 경로의 마지막 단계에서 중복제거를 실행해야 한다.
- 고유 ID를 사용한 중복제거의 방법
분산스토리지로 NoSQL 데이터베이스를 사용할 경우, 고유 ID를 지정하게 되어있어, 동일한 ID의 데이터는 덮어쓴다. 따라서 중복이 있더라도 데이터상으로는 중복제거가 이루어진다.
데이터 수집의 파이프라인
위와 같은 프로세스를 거친 다음, 마지막으로 데이터를 구조화해서 열 지향 스토리지로 반환함으로써, 데이터 수집의 파이프라인을 구성한다.
쓰기 성능에 불안감이 없다면 메시지 브로커는 불필요하므로 클라이언트나 프론트엔드에서 NoSQL 데이터베이스에 직접 데이터를 쓰는 것도 좋다.
