스트리밍 데이터 아키텍쳐- 2 저장소, 접근

이전 포스팅에 이어서 스트리밍 시스템에서 사용하는 패턴의 아키텍쳐를 공부해보고자 합니다.

실시간 데이터 파이프라인 아키텍쳐를 보고 공부한 내용을 다룹니다!

스트리밍 데이터 아키텍쳐

스트리밍 아키텍쳐는 크게 6가지 단계로 나눌 수 있습니다.

본 포스팅에서는 수집, 접근 단계에 대해 정리해 보려합니다.

수집

열심히 수집하고 분석한 데이터는 비즈니스에 맞게 적절하게 저장되어야합니다.

장기 스토리지(Long-term storage)에 저장

스트리밍 시스템에서 처리한 데이터를 S3, HDFS 또는 RDBMS와 같은 장기 저장소에 저장하는 경우가 있습니다.

이는 주로 배치 또는 오프라인 접근을 위한 저장입니다.

 

분석단계에서 매시지를 보낼때 즉시 저장하거나, 배치로 장기 저장소에 저장할수도 있지만,

배치로더를 통해 저장할수도 있습니다.

직접 저장 (Direct writing)

직접 저장은 일반적인 저장방법, 분석단계에서 임시로 메시지를 가지고 있다가 장기 스토리지에 저장하는 배치 방식입니다.

두 방법은 데이터를 빠른 속도로 처리할 경우 데이터의 크기와 속도가 증가하면 대응이 어렵습니다.

그렇기에 배치로 데이터를 가져온뒤 상황에 맞게 처리하는 경우가 많습니다.

간접 저장 (indirect writing)

간접 저장은 직접 저장보다는 다소 복잡하지만 분석 단계와 장기 스토리지의 커플링을 분리하는데 도움이 됩니다.

먼저 분석이 완료된 스트림 데이터를 큐에 저장합니다.

특이한 점은 최종적으로 배치 로더(Batch loader)를 사용해 장기 스토리지에 저장합니다.

간접 저장 방식을 사용하면 메시지 큐 단계는 스트림 데이터 처리 속도와 볼륨에 대응 할 수 있고, 대용량 저장 처리는 배치 로더에 위임해서 성능 발생이 줄어들 수 있습니다.

캐싱 시스템(Caching system)

캐싱 시스템을 사용하면 메모리(DRAM)에 데이터를 저장할 수 있습니다.

Read-through

Read-througt는 캐싱 시스템이 캐시에 없는 데이터를 요청받았을 때 영구 저장소에서 데이터를 읽어옵니다.

Refresh-ahead

Refresh-ahead는 캐시가 만료 또는 삭제되기 전에 최근에 접근했던 데이터로 캐시의 값을 새롭게 변경합니다.

캐시가 만료되면 영구 저장소에 접근해야하는 Read-through전략에 비해 상대적인 성능이점이 있습니다.

스트림 데이터에서 쉬운일은 아니지만 데이터를 새로고침하는 주기를 데이터 업데이트 빈도와 거의 동일하게 설정한다면 캐시는 영속 저장소에 있는 데이터와 거의 동일한 값을 가질수도 있습니다.

Write-through

데이터가 들어오면 캐시와 영속 저장소에 동시에 저장하는 방식입니다.

상대적으로 쓰기 비용이 다른 캐싱시스템에 비해 높다는 단점이 있습니다.

Write-around

write-around에서는 캐싱시스템은 캐시가 영속 저장소를 업데이트합니다.

하지만 이 경우 캐시는 영속 저장소의 기록되거나 변경되는 사항을 알 수는 없습니다.

영속 저장소에 데이터가 업데이트되고 나면 캐시를 업데이트 하기 위한 별도의 프로세스가 실행됩니다.

영속 저장소와 캐시 두곳에 각각 다른 방식으로 데이터를 업데이트 해야한다는 복잡성이 있지만 두 저장소가 연결되어 있지 않을 수 있다는 장점이 있습니다.

Write-back (Write-behind)

write-around에서 캐싱시스템은 캐시가 영속 저장소에 새로운 값을 쓰는 방식입니다.

Write-through와 조금 다르게 케시에 대한 쓰기가 된 후 바로 백그라운드를 통해 영속 저장소에 값을 쓰거나 업데이트합니다.

인메모리 데이터베이스, 인메모리 데이터 그리드, 캐싱 시스템의 차이

캐싱 시스템은 데이터를 빠르게 읽기 위한 임시 저장소로 영속성을 보장하지 않습니다. 

반면 IMDB(In-Memory Database), IMDG(In-Memory Data Grids)는 캐싱 시스템과 다르게 영속성을 보장하기 위해 메모리에 우서 저장을 하고 이후 디스크에 저장한다는 차이점이 있습니다.

 

IMDB와 IMDG는 캐싱 시스템이 발전함에 따라 점점 차이점이 사라지고 있지만 전통적으로 몇가지 차이점이 존재합니다.

IMDG는 분산 아키텍쳐를 사용하여 주로 대용량 데이터를 처리하며, RDBMS에서 익숙한 저장 프로시저와 유사한 동작을 할 수 있고,

IMDB는 메모리에 전체 데이터를 저장해 빠른 처리와 트랜잭션을 제공합니다.

또한 IMDG는 SQL을 통해 API접근을 제공하는 반면, IMDB는 비SQL API를 사용합니다.

데이터 접근

스트리밍 시스템의 마지막 단계입니다.

우리가 여러 단계를 거쳐 데이터를 모으고 가공한 이유는 결국 마지막에 클라이언트에 보여주기위해서 입니다.

아무리 스트리밍 시스템이라도 할지라도 클라이언트와의 통신에서도 반드시 연속적인 통신이 필요한것은 아닙니다.

일반적인 PUSH/PULL 방식뿐만 아니라 데이터 동기화 방식, RMI/RPC, 심플 메시지, 구독/발행 등 다양한 패턴이 가능합니다.

데이터 동기화

데이터 동기화는 클라이언트와 API간 통신이 아닌, API의 데이터베이스 또는 저장소와 동기화하는 방식을 의미합니다.

서버에서 스트리밍 분석을 마치고 데이터의 변경사항을 감지하여 스트리밍 클라이언트에 데이터를 보내는 방식입니다.

 

이 패턴은 크게 두가지로 나뉘는데

클라이언트가 처음 API로 연결될 때 분석된 데이터를 요청합니다.

이후 데이터들에 대한 변경사항은 클라이언트로 푸시하거나 클라이언트가 데이터를 가져오는 방식으로 진행됩니다.

RMI와 RPC

RMI(Remote Method Invocation)/RPC(Remote Procedure Call)패턴은 API서버에 새로운 데이터가 도착하거나 클라이언트가 필요로 하는 데이터가 도착했을 때, 클라이언트에 있는 메서드를 원격으로 호출하는 방식입니다.

 

스트리밍 데이터 API서버는 분석 단계에서 처리 완료된 데이터가 저장소에 저장되었는지 모니터링하고, 저장소의 데이터가 변경되면 원격 메소드를 호출하여 클라이언트에 변경된 데이터를 전송합니다.

하지만 RMI와 고전적인 RPC 방식은 현재는 잘 사용되지 않으며, 구글의 gRPC가 상황에 따라 주로 사용됩니다.

심플 메시징

클라이언트는 스트리밍API 서버의 가장 최근에 데이터를 요청하고 응답으로 가장 최신의 데이터만을 전달하는 방식입니다.

그렇기에 심플 메시징 방식은 'xxxx보다 최신인 데이터를 요청', 'xxxx기간 동안 변경되지 않은 데이터의 요청'과 같은 명령에는 적합한 방식이 아닙니다.

 

하지만 클라이언트는 계속해서 신규 데이터를 요청하기에 통신량이 많을 수 있습니다

발행 - 구독 패턴

클라이언트가 특정 채널을 구독하고, API는 데이터가 변경될 때 해당 채널을 구독하고 있는 모든 클라이언트에 메시지를 보내는 방식입니다.

스트리밍 시스템에서 가장 널리 사용되는 방식입니다.

클라이언트에 데이터 전달 프로토콜 방식

스트리밍 API에서는 웹훅, 롱풀링, SSE, 웹소켓과 같은 통신 패턴이 사용됩니다.

SSE는 롱풀링의 단점을 극복하고 나온 방식이기에 웹훅, SSE, 웹소켓에 대해 알아보겠습니다.

웹훅(Webhook)

새로운 데이터가 도착하거나 기타 조건이 충족되면 클라이언트를 HTTP엔드포인트로 호출하는 방식으로 사용됩니다.

호출은 HTTP의 POST를 통해 실행됩니다.

 

최초 클라이언트가 HTTP POST를 사용하여 콜백을 등록하기 위한 요청을 보냅니다.

콜백이 저장되면 이후 이벤트 조건이 충족되면 콜백을 호출합니다.

결제 완료 알림이나, 깃 커밋 푸시시 슬랙이나 CI로 전달하는 깃허브 웹훅과 같은 방식에서 사용됩니다.

SSE (Server Sent Events)

W3C의 권장 서버 -> 브라우저간 단방향 프로토콜입니다.

클라이언트가 먼저 스트리밍 API 연결 후 맺어진 네트워크를 통해 모든 이벤트가 지속적으로 전송됩니다.

조회만을 위한 간단한 실시간 서비스라거나 서버 로그 스트리밍에서 주로 사용됩니다.

비연결 푸시 (Connection push)

SSE는 클라이언트와의 지속적인 연결이 필수적입니다.

그렇기에 모바일 디바이스와 같은 상황에서는 배터리 소모 이슈, 네트워크 측면에서는 리소스 이슈가 있습니다.

하지만 비연결 푸시 방식을 사용하면 SSE의 단점인 지속적인 연결을 해결할 수 있습니다.

푸시 프록시 서버를 사용하여 어플리케이션이 꺼져있어도 메시지를 보낼 수 있습니다.

먼저 클라이언트(여기서는 모바일 디바이스)가 스트리밍 API와 연결을 하고 이벤트를 수신합니다.

이후 클라이언트에서 지정한 시간, 조건이 지나면 디바이스는 절전모드로 전환됩니다.

이 때 푸시 프록시 서버와 연결 상태를 유지하기 위한 통신(마지막으로 받은 이벤트의ID를 전송)을 시작합니다.

 

푸시 프록시 서버가 이벤트를 수신하면 모바일 푸시 시스템(FCM,APNs)을 사용해서 클라이언트로 이벤트를 전송합니다.

클라이언트에서는 메시지를 처리하기 위해 절전모드를 일시 해제하고 다시 절전모드에 들어갑니다.

특정 시점이 되면 푸시 프록시가 스트리밍API와 연결을 끊고 연결이 종료됩니다.

웹소켓

웹소켓은 스트리밍 시스템에서 가장 대중적이고 효율적인 방법중 하나입니다.

초기 핸드 쉐이크에서는 HTTP를 사용하고 이후 통신은 TCP를 사용합니다.

 

아래 그림에서 "저속 (Slow down)"으로 표시딘 부분은 통신이 양방향으로 이루어지고 클라이언트가 종류와 전송 시점을 결정하여 서버로 언제든지 메시지를 보낼 수 있다는 의미입니다.

클라이언트가 데이터를 빨리 읽지 못할 경우, 서버에게 요청해서 데이터 전송 속도를 낮출 수 있습니다.

 

연결을 올바르게 종료하려면 종료 헨드쉐이크를 사용해서 서로 TCP 통신을 끊습니다.

 

기본적인 스트리밍 시스템의 구조에 대해서 알아보았는데,

아무래도 실무적인 부분과 직접 연관짓기에는 조금 부족한 글인것 같습니다..

조만간 직접 만들어 보고 부족한 부분들을 더 채워넣으면 좋겠다는 생각이 듭니다!

 

다음 포스팅에서는 스트리밍 시스템에서 사용하는 알고리즘을 알아보고자 합니다.