1. 스트리밍 데이터 소개

디지털 유니버스의 규모가 2년마다 두 배로 증가하고 있음

실시간 시스템들의 분류

소프트로 할지, 니어로 할지 선택은 매우 중요, 데이터가 처리되어 사용될 준비가 된 데이터가 있다면 이 시점은 소프트 리얼타임인가 니어 리얼타임인가? 소프트로 할지, 니어 리얼타임인지 구분 짓기 매우 어려움

스트리밍 데이터 시스템 정의

우리는 하드 리얼 타임이 아닌 서버의 실시간 데이터를 클라이언트가 원할 때 사용하는 시스템을 원한다. 이를 스트리밍 데이터 시스템이라고 한다.

클라이언트가 데이터를 필요로하는 시점에 데이터를 가져가서 처리할 수 있도록 구현되어있다. 이런 것을 소프트 리얼타임이나 니어 리얼타임이 아닌 스트리밍이라고 부를 수 있다.

예시

트위터 - 스트리밍 시스템은 트위터에 작성된 글을 처리한다. 그리고 잠시 후 또느 몇 초 또는 몇시간 뒤 애플리케이션 클라이언트에서 글을 조회할 때 데이터를 가져간다.

클라이언트가 데이터를 요청하는 그 시점에 서버에서 어떤 데이터를 어떻게 전달할지 구현하는 것에 집중해야 한다. 이렇게 데이터가 필요한 시점에 전달이 가능한 시스템을 인더모먼트 시스템이라고 부를 수 있다.

스트리밍 데이터 아키텍처

• 수집 단계
  • 사용자가 트위터에 글을 쓰면 트위터 서버는 데이터를 수집
• 메시지 큐 단계
  • 트위터의 데이터 센터는 전 세계 다양한 곳에 위치, 수집과 분석은 다양한 위치의 서버에서 수행
• 분석 단계
  • 140자의 글을 분석하기 위해 엄청나게 많은 절차 수행, 여기서는 팔로워들을 추출하는 최소한의 분석 수행
• 인메모리 저장소 단계
  • 몇 초 전에 추가된 트위터 글은 인메모리 저장소에 저장되어 있을 가능성이 큼
• 데이터 접근
  • 트위터 데이터 센터에 접근하기 위해 다수의 트위터 클라이언트들은 트위터 서버에 연결되어 있어야 함

서비스를 확장하는 방법

넓은 범위에서 수직 확장과 수평 확장이 있다.

• 수직 확장
  • 하드웨어 또는 소프트웨어에 리소스를 추가
• 수평 확장
  • 서버를 추가

현대의 시스템 디자인에서는 수평 확장으로 구현하는 것이 목표, 즉 수직 확장을 사용하여 서버의 적정 리소스를 찾고 이후에 수평 확장으로 대응하는 것이 일반적이다.

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

수집 단계는 스트리밍 시스템으로 데이터를 입수하는 지점이다. 데이터 입수는 다음과 같은 예시가 있을 것이다.

• 트위터에 사용자가 게시글을 작성함
• 자동차로부터 다양한 데이터를 수집받음
• 등 어떤 형태로든 데이터를 획득하는 것을 데이터수집이라고 한다.

일반적인 통신 패턴

다양한 통신 패턴이 존재하지만 다음과 같은 몇 가지 통신 패턴 중 한 가지 패턴을 선택하여 통신하는 것이 일반적

요청 / 응답 패턴

• 클라이언트가 서버에게 명령을 내리거나 데이터를 요청
• 서버는 클라이언트로 응답을 보냄

동기적으로 동작하므로 응답을 받기 위해 클라이언트는 기다려야 하는 시간이 반드시 필요하다는 한계 존재, 한계를 극복하는 가장 간단한 방법은 요청을 비동기로 수행하는 것

• 클라이언트는 지속적으로 서버로 요청을 날리고 응답이 오기 전까지 다른 일을 수행
• 비동기 방식으로 클라이언트는 서버로부터 응답을 기다리는 시간을 최소화할 수 있음

많은 프로그래밍 언어들과 프레임워크는 비동기로 요청할 수 있도록 설계되어 있어 구현이 어렵지 않다. 그림 2.3과 같은 방식은 요청과 응답이 비동기로 이루어지기 때문에 반비동기라고도 한다.

이 패턴의 마지막 종류로는 완전비동기 요청 / 응답 패턴이 있다. 이 패턴은 서버와 클라이언트 모두 완전히 비동기로 동작을 의미

요청/확인 응답 패턴

요청/응답 패턴과 유사하나 서버로부터 응답 데이터는 필요하지 않은데 요청이 제대로 갔는지 확인만 해야할 필요가 있을 때는 요청 / 응답 확인 패턴이 적합하다.

요청 / 응답 패턴은 요청에 대해 성공이나 실패를 응답으로 주는데 요청 / 응답 확인 패턴에서는 다음 요청부터 사용할 데이터를 넘겨준다. 주로 다음 요청에 사용할 액세스 토큰을 보내줌

발행 / 구독 패턴

프로듀서 / 컨슈머가 존재하며 메시지는 토픽을 통해 논리적인 그룹으로 나뉘어진다. 프로듀서는 메시지를 논리적인 그룹인 토픽으로 전달하며 토픽을 구독하는 모든 컨슈머에게 메시지가 전송된다.

단방향 패턴

요청을 하는 시스템이 응답이 필요하지 않을 때 보통 사용된다.

기존 요청 확인 응답패턴이나 요청 확인 패턴과의 차이점은 서버가 응답을 다시 보내지 않아도 된다는 점이다. 그래서 단방향 패턴의 경우 클라이언트는 서버가 요청을 받았는 지 알 수없다.

일부 데이터가 유실되는 것을 허용하고 통신의 단순화, 리소스 감소, 전송 속도를 보장해야하는 환경에서는 단방향 패턴이 적합하다.

• cpu와 메모리 사용량 리소스 보내기
• 풋볼 선수들에게 동전 크기의 태그를 부착하고 속도 데이터, 움직임, 거리데이터 수집 등

스트림 패턴

스트림 패턴은 기존 패턴과 다르게 한번의 요청에 데이터를 전달하지 않거나 지속적으로 데이터를 응답으로 보내는 특징이 있다.

스트림 패턴을 활용하면 스트림 데이터가 존재하는 단계에 연동하여 데이터를 지속적으로 처리하거나 새로운 스트림 데이터를 만들 수 있다.

내결함성

내결함성: 시스템의 일부 구성 요소가 작동하지 않더라도 계속 작동할 수 있는 기능

우리가 개발한 코드에 의해 버그가 발생해서, 혹은 우리가 연동하는 제 3의 소프트웨어, 혹은 하드웨어 등등 다양한 이슈로 장애가 발생할 수 있다.

수집 단계에서 재전달을 요청하더라도 클라이언트가 데이터를 다시 보내지 못하는 환경이 대부분이여서 수집 단계에서 데이터를 유실하면 복구가 불가능할 수 있기 때문에 우리는 장애를 해결할 수 있게 구현하여야 한다.

서버에 장애가 발생해도 발생하지 않은 것 처럼 데이터를 유실하지 않도록 하는 것이 주요 달성 목적이 된다.

체크포인팅과 로깅 기법을 사용할 수 있음, 이 두 가지 방식을 사용하면 데이터 유실을 방지하고 장애가 발생한 서버를 복구할 수 있다.

체크포인팅

체크포인팅의 특징이다.

• 전역 스냅샷
  • 시스템 전역 상태에 대한 스냅샷을 정기적으로 특정 저장소에 저장한다.
• 데이터 유실 가능성
  • 가장 최근에 기록된 전역 상태까지 복구할 수 있도록 한다. 이후에 처리되고 생성된 모든 메시지는 유실된다.

시스템에서 처리하고 있는 데이터가 변경되었음에도 전역 상태가 저장되지 않는다면 처리된 데이터는 복구 불가능하다.

스트리밍 시스템에서 단계별로 데이터가 이동할 때마다 전역 스냅샷을 일관성있게 저장하는 것은 매우 어려운 일이다.

즉 스트리밍 시스템에서 체크포인팅을 사용하는 것은 잘못된 선택이다.

로깅

로깅은 체크포인팅의 비용과 복잡성을 극복하고 장애가 발생하기 전까지 수신된 마지막 메시지까지 복구하는 기능을 제공한다.

로깅의 목표는 메시지를 재처리할 수 있다면 전역 스냅샷이 없어도 전 구간에서 일관된 상태에 도달할 수 있음이다.

로깅은 어느 부분에 구현되어야 할까?

로깅의 종류

RBML은 비즈니스 로직이 데이터를 처리하기 전 로깅, SBML은 데이터 처리 후 로깅하는 것 → 오히려 오버헤드와 결합도를 증가시킬수도, HML은 RBML과 SBML을 적절히 균형을 맞춘 방식이다.

고전적 기술 - RBML(Receiver-Based Message Logging)

• 서버가 데이터를 다운받을 때 유실 방지 가능, 전달받은 모든 메시지를 저장소에 저장한 이후에 로직을 처리

• 저장소의 성능이 따라주지 않으면 2단계, 3단계 처리 시 심각한 영향을 줄수도 → HML이 개선
  

• 장애발생 시 저장되있던 데이터를 바탕으로 재처리하여 복구 가능

• 장애 복구 전까지는 메시지 입수 중단됨

고전적 기술 - SBML (Sender-Based Message Logging)

• 데이터를 다음 단계로 보낼 때 유실 방지 가능, 서버가 처리한 데이터를 다음 단계로 보내기 전에 외부로 나가는 모든 메시지를 로깅
• RBML이 포함된 그림임
  

• 메시지 큐에 정상적으로 전달받으면 수집단계에서 데이터를 보관할 필요가 없으므로 삭제처리한다.

새로운 기술 - HML (Hybrid Message Logging)

• RBML, SBML 모두 사용하면 저장되는 데이터가 2배로 늘어날 것, 또한 데이터를 처리해야하는 양보다 로깅을 쓰는데 데이터양이 더 많아질 수 있다.
• HML은 RBML, SBML의 장점을 최대한 활용하도록 설계됨

저장소를 2개에서 하나로 줄이고 저장소에 저장을 비동기로 처리한다. 연구에 따르면 HML은 RBML에 비해 43%의 오버헤드를 줄였다고 한다.

3. 수집 단계에서 데이터 전송: 데이터 파이프라인 분리

이번 장에서는 수집 단계에서 나머지 스트리밍 파이프라인으로 데이터를 전달하는 데 초점을 맞추고 알아볼 것, 즉 메시지 큐 단계와 통신하는 데이터이다.

메시지 큐 단계가 필요한 이유

스트리밍 시스템은 수많은 서버들로 이루어져 있다. 잘 동작하는 시스템을 개발할 때는 서버들간 디커플링이 잘 되어 있어야 한다.

메시지 큐 모델을 이용하여 프로세스 간 통신을 할 경우 수집 단계와 분석 단계 등 단계별 프로세스들 사이의 커플링을 끊어낼 수 있다.

데이터 생성량이 컨슈머의 데이터 처리량보다 많은 상황이 발생할 수 있다. 이 경우 일부 데이터가 유실될 가능성이 있다.

데이터 유실을 허용하지 않는 사업을 하고 있다면 데이터를 안전하게 오랜 기간 저장할 수 있는 메시지 큐 기술을 적용해야한다.

이를 통해 장애가 발생하더라도 복구할 수 있으며 일시적인 컨슈머의 연결 종료에도 안전하게 데이터를 처리할 수 있게된다.

((카프카가 최고인듯))

메시지 전달 시멘틱(at most once, at least once, exactly once)

• at most once
  • 최대 한 번
  • 일부 메시지 유실 가능
• at least once
  • 적어도 한 번
  • 메시지가 절대 유실되지 않음, 단 동일 메시지 2번 처리 가능성 있음
• exactly once
  • 메시지가 절대 유실되지 않음, 컨슈머는 단 한번만 메시지 처리 보장

장애 허용

분산 시스템에서는 장애가 발생할 수 있는 것에 초점을 맞추는 것이 아니라 장애가 날 것에 관심을 두어야 한다.

• 브로커에 장애가 발생하면?
  1. 프로듀서가 메시지를 보낸 다음, 디스크에 안전하게 저장되었다는 확인응답을 받아 이슈 해결 가능
  2. 브로커가 메시지를 복제해서 다른 브로커에 들고 있는 방법으로 해결 가능
  3. 브로커가 메시지를 처리할 때 메모리가 메시지를 최대한 작게 가지도록 해서 해결 가능
• 메시지 브로커들 사이에 네트워크 장애가 발생하면? 많은 메시지 큐 솔루션은 메시지를 복제해서 다른 브로커가 들고있는 복제기능 제공, 그래서 우리는 다음과 같은 고민을 하면 된다.
  1. 새롭게 메시지를 복제하기 위해 어떤 브로커가 선택될까?
  2. 네트워크 통신이 장애 복구가 되면 어떻게 동작할까?
  3. 네트워크 장애로 판단하기 위해 지연 정도를 설정할 수 있는가?
  4. 네트워크 장애 이후에 복구되지 못한다면 어떻게 동작하나?
  5. 프로듀서가 클러스터에서 탈락된 브로커에 미시지를 보내게 되면 어떻게 되나?
• 저장소에 장애가 발생하면?
  1. 유실된 데이터에 대한 복제본이 있는가?
  2. 복제가 진행되고 있을 때 디스크에 기록되지 않은 상태에서 장애가 발생하면?
  3. 브로커를 복구하는 방법은 어떻게 되나?

비즈니스 요구사항들에 주요 개념을 적용해보기

비즈니스를 스트리밍 시스템으로 구현할 때 다음과 같은 질문을 해보자

• 수집 단계와 분석 단계에서 네트워크 지연이 발생하게되면 서비스에 어떤 영향이 가는가?
• 며칠만큼의 데이터가 유실되도 괜찮은가?
• 며칠만큼의 데이터를 저장하고 있어야 하는가?
• 스트리밍 시스템의 메시지 전달 시맨틱은 무엇이어야 하는가?

4. 스트리밍 데이터 분석

분석 단계에 대한 기본 원리를 이해하자. 분석 단계는 데이터가 들어가는 것에 대해서만 살펴보며 분석이 완료된 데이터가 어떤 방식으로 조회되는지는 다루지 않는다.

in-flight data와 continuous queries(연속쿼리) 라는 개념을 이해해야한다.

• in-flight data: 데이터에서 인플라이트라는 것은 시스템에서 입력과 출력 그리고 클라이언트(다음단계)를 묶는 시스템에서 사용되는 튜플
  • 데이터는 계속 움직이며 내부 저장소에 영구히 저장되지 않는다.
• 연속 쿼리 모델: 쿼리를하면 데이터가 지속적으로 들어온다.
  

RDB는 본질적으로 정적으로 데이터를 저장되어야 함(쿼리를 수행하기 위해서는 데이터가 모두 시스템에 쌓인 이후에 가능) 스트리밍은 쿼리를 실행하면 데이터가 추가되면서 지속적(인터벌 혹은 트리거로 인해) 데이터가 추출된다.

전통적 DBMS에서는 쿼리를 보내고 결과를 다시 애플리케이션으로 가져오는 것, 스트리밍은 데이터가 지속적으로 쿼리를 통해 처리, 데이터는 지속적으로 풀 또는 푸쉬되어 시스템 안에서 데이터가 흐른다.

참고자료

실시간 데이터파이프라인 아키텍처