[빅데이터를 지탱하는 기술] 4. 빅데이터의 축적 (2)

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

메시지 브로커

푸쉬 형과 풀 형의 메시지 전송

 

▪ 데이터양이 많을 때 쓰기의 빈도가 증가함에 따라 디스크 성능의 한계에 도달, 이에 적절한 대응이 필요

▪ 메시지 브로커(message brocker): 빅데이터의 메시지 배송 시스템에서 데이터를 일시적으로 축적하는 역할

▪ 오픈 소스의 경우 'Apache Kafka(아파치 카프카)', 클라우드 서비스의 경우 'Amazon Kinesis(아마존 키네시스)' 

푸쉬 형과 풀 형

▪ 푸시(push) 형: 송신 측의 제어로 데이터를 보내오는 방식 

▪ 풀(pull) 형: 수신 측의 주도로 데이터를 가져오는 방식

▪ 메시지 브로커에 데이터를 넣는(push) 것을 '생산자(producder)', 꺼내오는(pull) 것을 '소비자(consumer)'라고 함

▪ 메시지 브로커는 높은 빈도로 데이터를 쓰는 것에 최적화, 여러 대의 노드에 부하를 분산, 뛰어난 확장성 

▪ 푸쉬 형의 메시지 배송은 메시지 브로커에 집중시키고, 일정한 빈도로 데이터를 꺼내 분산 스토리지에 기록

메시지 라우팅

메시지 브로커에 의한 메시지 라우팅

 

▪ 프런트 엔드에서는 메시지 브로커에 데이터를 푸쉬하고 그것을 '소비자'에서 모아서 가져옴 

▪ 스트림 처리(stream processing): 1초 단위의 짧은 간격으로 차례대로 데이터를 꺼내서 처리

▪ 메시지 라우팅(message routing): 메시지 브로커에 써넣은 데이터는 다른 소비자에서도 읽을 수 있음, 메시지가 복사되어 데이터를 여러 경로로 분기

▪ 메시지 브로커에 기록된 데이터는 일정 기간 보관

▪ 실시간 스트림 처리에서는 짧은 간격으로 데이터 추출, 장기적으로 분산 스토리지에 저장하는 경우는 어느 정도 데이터를 모아서 한번에 저장

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

▪ 성능 문제 외에도 피할 수 없는 것이 '신뢰성(reliability)'

▪ 신뢰성이 낮은 네트워크는 메시지 누락과 중복이 발생, 이를 처리하기 위해 아래 중 하나를 보장하도록 설계

   - at most once: 메시지는 한번만 전송, 전송 실패하면 사라질 가능성 존재 

   - exactly once: 메시지는 손실되거나 중복 없이 한번만 전달 

   - at least once: 메시지는 확실히 전달, 같은 것이 여러번 전달되어 중복 가능성 존재

at most once

▪ 절대로 메시지를 다시 보내지 않음 그러나 대개 데이터의 결손을 피하기 위해 '재전송(retransmission)'이 이루어짐

▪ 재전송하는 시스템에서는 'at most once'를 보장하기 어려움 

▪ 두 노드간에 데이터 전송에서 수신완료를 나타내는 'ack'가 반환되기 직전에 네트워크 통신이 중단될 경우, 접속 재개시 메시지가 재전송되어 중복 발생 

exactly once

▪ 네트워크 상에서 두 개의 노드간에 통신을 보장하기 위해서 사이를 중계하는 '코디네이터(coordinator)'가 필수적

▪ 메시지의 송신 측과 수신 측 모두 정보를 코디네이터에게 전달하고, 문제가 발생할 경우 코디네이터의 지시에 따라 해결

▪ 하지만 이는 두가지 문제점이 존재

   - 분산 시스템에서 항상 코디네이터가 존재한다고 가정할 수 없음 ex) 코디네이터 자신이 정지되는 경우

   - 코디네이터의 부재시 시스템을 멈출 수는 없기 때문에 어떻게 할 것인지 '합의(consensus)' 함

   - 코디네이터의 판단에만 따르면 시간이 많이 걸리는 성능상의 문제

at least once

▪ 중복제거(deduplication): 메시지가 재전송되어도 그것을 없앨 수 있는 구조

▪ TCP는 메시지 수신 확인을 위해 'ack' 플래그를 도입하여 'at least once'를 실현

▪ TCP/IP에 의한 네트워크 통신에서 TCP 패킷은 중복을 식별하는 시퀀스 번호가 포함됨, 이를 이용해서 중복제거가 이루어짐

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

▪ 메시지 중복을 피하기 위해 해당 메시지를 과거에 받았는지 판단해야함 

▪ TCP에서는 메시지에 시퀀스 번호를 붙이고 있지만, 분산 시스템에서는 사용되지 않음 

▪ 한 부분에 중복처리를 집중시켜야하는데, 이로 인해 성능 향상이 어려워짐

▪ 대안으로 다음의 방법을 사용 

오프셋을 이용한 중복 제거

▪ 전송할 데이터에 파일명 등의 이름을 부여해 작은 메시지에 실어서 배송 

▪ 각 메시지에는 파일 안의 시작 위치(오프셋)를 덧붙임 

▪ 중복이 발생해도 같은 파일의 같은 장소를 덮어쓰기에 문제가 되지 않음 

▪ 벌크 형의 데이터 전송과 같이 데이터 양이 고정된 경우 잘 작동

▪ 스트리밍 형식의 메시지 배송에서 이 방식을 사용하는 경우는 거의 없음 

고유 ID에 의한 중복 제거 

▪ 스트리밍 형의 메시지 배송에서는 모든 메시지에 'UUID(Universally Unique IDentifier)' 등의 고유 ID를 지정하는 방법을 사용 

▪ ID가 폭발적으로 증가하는 것을 관리하기 위해 최근에 받은 ID만 기억하고, 늦게 온 메시지의 중복은 허용 

▪ 중복의 대부분은 일시적인 통신 오류로 인해 발생하기에 이것만 제거하면 높은 신뢰도를 가질 수 있음 

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

▪ 빅데이터의 메시지 배송에서는 종종 신뢰성보다 '효율' 쪽이 중시

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

▪ 스트리밍 형의 메시지 배송은 프런트 엔드, 브로커, 소비자 등 다수의 요소로 구성되는데, 이들 중 하나에서 중복이 발생하면 신뢰성이 깨짐 

▪ 즉 최종적인 신뢰성은 중간 경로의 신뢰성 조합으로 결정 

▪ 신뢰성 높은 메시지 배송을 위해서는 중간 경로를 모두 'at least once'로 하고, 모든 메시지에 고유 ID를 포함하여 경로의 말단에서 중복을 제거

고유 ID를 사용한 중복 제거의 방법 

SQL을 이용한 중복 제거

 

▪ 분산 스토리지로 NoSQL 데이터베이스를 이용하여 중복 제거 실현, Cassandra나 Elasticsearch 등은 데이터를 쓸때 고유 ID를 지정하게 되어 있어 동일한 ID의 데이터는 덮어씀 

▪ 보내온 데이터는 일단 저장하고 읽는 단계에서 SQL로 중복 제거, 이는 대규모 데이터 처리이므로 Hive와 같은 배치형 쿼리 엔진에서 실행  

데이터 수집의 파이프라인 

데이터 수집의 일례(스트리밍 형)

 

▪ 일련의 프로세스를 거친 다음, 데이터를 구조화해서 열 지향 스토리지로 변환 

▪ 어떤 파이프라인을 만들지는 필요에 따라 시스템을 조합 

중복을 고려한 시스템 설계 

▪ 일반적으로 스트리밍 형의 메시지 배송에서는 항상 중복의 가능성이 있다고 생각하는 것이 좋음 

▪ 빅데이터를 다루는 시스템은 높은 성능이 중요하기에 아주 작은 중복은 무시되는 경향이 있음 

▪ 어느 정도의 오차를 허용하고 '멱등한 조작'에 유의하여 중복이 있어도 문제가 되지 않는 시스템을 설계

▪ 신뢰성이 중시되는 경우는 스트리밍 형의 메시지 배송을 피하는 것이 좋음 

 

 

[참고]

빅데이터를 지탱하는 기술(니시다 케이스케)