[Streaming Data 실시간 데이터 파이프라인 아키텍처] 1, 2장 요약

앤드류 살티스 저  '실시간 데이터 파이프라인 아키텍처' 를 요약 정리한 글 입니다. 

1장 스트리밍 데이터 소개

요약

스트리밍 데이터 시스템 : 서버의 실시간 데이터를 클라이언트가 데이터를 필요로 하는 시점에 데이터 가져가서 처리하는 시스템.

스트리밍 데이터 시스템 아키텍처 : 수집 - 메세지 큐 - 분석- 인메모리 데이터 저장소 - 데이터 접근

정리 (펼치기)

1) 실시간 데이터 시스템과 스트리밍 데이터 시스템 차이점

실시간 시스템은 지연 정도와 허용 가능한 지연에 따라 하드 리얼타임, 소프트 리얼타임(항공사 예약 시스템, 주식 시세 등), 니어 리얼타임(스마트 홈 등) 로 분류할 수 있음

스트리밍 데이터 시스템 : 서버의 실시간 데이터를 클라이언트가 데이터를 필요로 하는 시점에 데이터 가져가서 처리하는 시스템.

스트리밍 데이터를 실시간으로 처리하지 않는 이유 : 클라이언트 네트워크, 어플리케이션 구조 등으로 인해 데이터를 소비하지 못할 수 있고, 클라이언트 어플리케이션이 종료된 상태일 수도 있기 때문.

인더모먼트 시스템 (In-the-moment system) : 데이터가 필요한 시점에 전달이 가능한 시스템

 

2) 스트리밍 데이터 아키텍처

수집 - 메세지 큐 - 분석- 인메모리 데이터 저장소 - 데이터 접근

 

3) 스트리밍 데이터 시스템을 위한 보안

클라이언트-수집, 수집 - 메세지큐, 데이터 접근 - 클라이언트 이 부분은 퍼블릭 네트워크 망을 탈 수 있으며 필요에 따라 암호화 해야할 수 도 있다

 

 

---

2장 클라이언트에서 데이터 가져오기 : 데이터 수집

요약

데이터 수집 패턴은 요청/응답 패턴, 요청/확인 응답 패턴, 발행/구독 패턴, 스트림 패턴 등이 있다.

• 요청/응답 패턴은 서버 수평적 확장 용이하다
• 스트림 패턴은 서버 추가로 확장가능하나 버퍼를 도입해 유휴 서버가 없도록 구성할 수 있다. 

 

장애 발생 시 데이터 유실 방지, 서버를 신속하게 복구하기위해 신뢰성 향상위해 내결함성 기술 사용한다 : 체크포인팅, 로깅

 

 

정리 (펼치기)

1) 데이터 수집 패턴

• 요청/응답 패턴 : 동기로 동작하는 요청/응답 패턴은 간단하게 구현가능하나 클라이언트는 서버의 응답을 기다리는 시간이 반드시 필요하다. 이를 해결하기위해 비동기로 요청하는 방식이있다.
  • 클라이언트가 요청 비동기로 수행 : 클라이언트 지속적으로 서버로 요청. 서버의 응답오기 전까지 다른 일 수행 -> 응답 대기 시간 최소화 (현대 브라우저들)
  • 반 비동기 : 서버에서 반비동기 지원. 서버는 요청 처리 수행하는 동안 처리완료된 데이터 클라이언트에게 응답.
  • 완전 비동기 : 클라이언트, 서버 둘 다 완전 비동기
• 요청/확인응답 패턴
  • 서버가 요청 정상적으로 받았는지 확인 필요한 경우 (현재 요청 상태 확인, 마지막 응답 받기 등)
  • 예시) 이커머스 홈페이지 접속, 클릭 링크 데이터로 구매 성향 분석. 다음 요청으로부터 사용할 데이터 넘겨줌
• 발행/구독 패턴
  • 메세지 기반 데이터 시스템에 주로 사용
  • 데이터 흐름
    • 프로듀서 -> 브로커에게 메세지전달
    • 메세지는 토픽(논리적 그룹)으로 전송
    • 토픽을 구독하는 컨슈머에게 메세지 전송(브로커가 컨슈머에게 push / 컨슈머가 브로커로부터 pull 하는 방법 등)
  • 발행/구독 패턴으로 프로듀서, 컨슈머 간 결함도 낮출 수 있음
• 단방향 패턴
  • 요청하는 시스템이 응답이 필요하지 않을 때 주로 사용
  • 요청/응답, 요청/확인응답 패턴과 유사하지만, 서버가 응답을 다시 보내도 되지 않음. 클라이언트는 서버가 요청 받았는지 확인 불가
  • 그럼에도 클라이언트 리소스 충분하지 않거나 요청만 수행하는 환경에 유용
  • 일부 데이터 유실 허용, 통신 단순화, 리소스 감소, 전송 속도 보장
  • 예시)
    •  리소스 모니터링. 어떻게 어떤 식으로 처리되는지 알 필요 없고 데이터 전달만 하면됨
    • NFL 선수 몸에 RFID 태그 부착, 센서 데이터 수신기로 보냄. 태그는 수신기로부터 응답 받아도 데이터 처리할 리소스 X
• 스트림 패턴 
  • 한번의 요청에 데이터 전달하지 않거나, 지속적으로 데이터를 응답으로 보냄
  • 다른 패턴은 서버에 요청하기 위해 클라이언트 개발해야하는데, 스트림 패턴은 스트림 데이터가 존재하는 단계에 연동만하면됨

요청/응답 패턴과 스트림 패턴 비교

 

3) 수집 단계를 더 나은 방식으로 구현하는 방법

통신 패턴확장

• 요청/응답 파생 패턴 확장하기
  • 요청/응답 파생 패턴 사용 시 수평 확장 용이
    • 요청/응답 파생 패턴의 서버는 주로 비상태기반으로 만듦(수평확장, 스케일링 용이하기위해)
      • 클라이언트에서 요청 시 상태 정보 없음. 실행중인 임의 서버에 요청 날리면됨
      • 상태 정보 저장하지 않으므로 신규 서버 쉽게 추가 가능(비상태 기반 서버 확장 : 클라우드 서비스 등에 사용되는 방식)
    • 통신 형태 : 클라이언트 <-> 로드 발란서 <-> 서버. 로드 발란서가 실행중인 서버들로 라우팅
• 스트림 패턴 확장하기
  • 클라이언트(수집 단계) <-> 서버(데이터를 요청하는 서버) 지속적으로 연결된 상태
  • 스트림 데이터는 1개의 수집노드(서버)와 직접 연결됨. 나머지 서버는 유휴상태(Idle)
  • 확장 방법 2
    • 스트림 데이터를 처리하는 수집 서버들 확장
    • 수집 단계에 버퍼링 계층 도입
      • 버퍼링 계층과 수집 단계는 서로 상호 배타적이지 않아야함 + 스트림 데이터의 유입량이나 크기에 따라 둘 다 구현되어야 할 수도.
      • 데이터 소비하는 서버 대수 늘려도 되지만, 하드웨어 한계에 도달해 확장 불가능할 수도있음.
      • 스트림 데이터 수집한 시점에 비지니스 로직 포함하지 않기 때문에 버퍼링 계층 도입해도됨
      • 스트림 데이터가 가능한 빨리 버퍼링 계층으로 보내야함. 이후 수집 단계 서버들이 비지니스 계층 데이터를 가져가 비지니스 로직 수행.
      • 이런 방식으로 버펄이 계층 이후의 수집 서버들 수평 확장 가능

스트림 데이터 수집 예시. 맨 왼쪽 수집 서버와만 연결되고 나머지 3대는 유휴 상태

버퍼링 계층이 추가된 스트림 수집 단계 예시

 

 

내결함성

장애 발생 시 데이터 유실 방지, 서버를 신속하게 복구하기위해 신뢰성 향상위해 내결함성 기술 사용

-> 수집 단계의 서버에 장애 발생해도 장애 발생하지 않은 것 처럼 데이터 유실하지 않는것이 목적

내결함성 달성 방식 2

• 체크포인팅 
  • 체크포인팅 기반 프로토콜 특성 2
    • 전역 스냅샷 : 수집 단계의 상테 + 시스템 전역 상태에 대한 스탭샷 정기적으로 특정 장소에 저장
      -> 스트리밍 시스템에는 부적합(스트리밍 시스템은 다양한 기술과 여러 단계를 거치는데 데이터 이동 모든 시점에 전역 스냅샷 데이터 일관성있게 저장하기 어려움)
      
      • ex) 문서 자동저장 기능과 비슷. SW비정상 종료 시 마지막 체크포인트로 복구 가능. 그 이후 데이터 유실
      • 전역 상태(global state) : 유입되는 데이터와 처리중인 데이터 캡쳐하여 영속적 저장 장소에 저장
    • 데이터 유실 가능성 : 가장 최근에 기록된 전역 상태까지 복구할 수 있도록 한다. 이후에 처리되고 생성된 메세지는 유실
• 로깅
  • 시스템을 구성하는 각 단계가 수신한 모든 메세지 자체적으로 저장, 장애 발생 시 저장된 메세지 재처리. 수집 단계 내결하성 만족시킬 수 있음
  • 체크포인팅처럼 비용이 많이 필요하지 않고 복잡하지 않음.
  • 로깅 종류 3
    • RBML(Receiver-based massage logging)
      • 메세지 처리 전, 전달 받은 모든 메세지(Raw Data) 저장소에 저장 후 로직 처리
      • 장애 발생 시 로그 데이터 바탕으로 재처리하여 복구 가능
      • 프로듀서가 보낸 메세지 RBML로거 역할을 하는 수집 서버로 전달, 저장소에 메세지 전달 및 저장 처리 시 저장소의 처리 성능 중요.
    • SBML(Sender-based message logging)
      • 메세지 처리 후 수집 서버에서 외부로 데이터 보내기 전에 로깅(Raw data가 아닌 처리된 데이터)
      • 다음 단계에서 장애/네트워크 중단 일어나도 메세지 재전달해 유실 방지가능.
      • 메세지 큐가 데이터 전달받았다는 확인 응답 보내면 저장소에서 메세지 삭제, 응답 없으면 계속 저장
    • HML(Hybrid message logging)
      • RBML, SBML은 저장소 성능이 중요하고 로그 데이터 너무 많아질 수 있음
      • HML은 RBML + SBML 두 로거를 사용하지만, 두 로거가 하나의 저장소를 사용한다. RBML로거가 메세지를 저장하고, SBML로거가 메세지 큐에서 확인 응답을 받으면 저장소에서 메세지를 삭제하는 방식