데이터 스트림_1(이론)

Streaming data
Data stream

What is streaming data, data stream?

막연하게 이름으로만 해석하면 '데이터가 흐르는' 개념이라고 생각한다.

데이터가 흐르다니, 어떻게 움직이는 것을 '흐르다'라고 표현할까?

인터넷 회선이 연결된 곳, 그리고 무선 네트워크가 닿는 곳이라면

어떻게든 데이터를 송/수신 할 수 있다.

인터넷과 연결되지 않는 폐쇄망 및 로컬 네트워크에서도

데이터는 송/수신 할 수 있으며

CAN 프로토콜 위에서 나르는 데이터도 있다.
(사용자 이동통신단말기, 서버, IoT 디바이스 등)

위 형태들도 Data가 오고 가고있으니 stream이 아닐까?

request & response와는 다른 특징

Data stream은 위와 같은 네트워크상에 연결된 기계들 외에 추가적인 feature들이 있다.

<항상 지속적으로>

Data stream 서비스에서는 새로운 데이터가 지속적으로 생성된다.

그리고 이 데이터는 데이터의 근원지로부터 다른 리소스로 이동한다.

Data의 생성과 이동이 실시간으로 진행된다.

실시간성을 강조하는 시스템에서는 event라고 부르는 단위를 사용한다.

이 리소스는 실제 물리적으로 분리되어있는 리소스일 수도 있고

같은 머신에서 작동하는 다른 프로세스일 수도 있다.

예를 들어 시나리오를 가정하면, 다음과 같다.

스마트팜의 IoT Device들로부터 '지속적으로 생성'된 데이터들을

인터넷과 연결되어 있는 온프레미스 머신이 수집하고
이 데이터들의 분석및 저장을 위해

시간 순차적으로 인터넷 회선을 통해 Cloud service로 전송한다.

이 전송은 지속적이고, 연속적으로 일어난다.

작은 양의 일련의 데이터를 연속적으로 보내는 행위가 곧 스트리밍이다.

기존 통신 방식과 전혀 다른 기술을 사용하는 것이 아니다.

인터넷 회로에서 OSI 계층 위에서 작동하며

정보를 담은 디지털 인코딩된 일련의 신호를 보내는 행위이다.

위와같은 지속적이고 연속적으로 데이터를 보내기 위해서는

전제 조건이 있다.

연결이 유지되어야 하며, 데이터를 보내기 전에 논리적인 상호간의 '연결'이 성립해야 된다.

특히, 이기종간 논리적인 연결이 성립돼야하는데 TCP가 대표적이다.

<느슨한 구조>

다양한 형태의 데이터가 스트리밍 환경에서는 흔하다.

다양한 원천 소스로부터 오는 것이 첫 이유고,

데이터 분석을 통해 미지의 인사이트를 발굴해낼 수도 있기 때문이다.

전송할 데이터가 추가될수도, 삭제될 수도 있기 때문에

JSON과 같이 쉽게 수정할 수 있는 포맷이 사용된다.

<높은 카디널리티 데이터>

높은 카디널리티는 데이터 조각에 고유한 값이 많다는 것을 의미한다.

높은 카디널리티는 빈도수가 적은 '롱테일' 특징에서 나타난다.

배치 프로세스로 구현

위 요구사항을 배치 프로그램으로 구현할 수도 있다.

chunk 단위의 수집된 데이터들의 분석 결과는 같을 수 있으나

실시간성이 떨어진다.

'실시간성이 떨어진다'의 예시는 다음과 같다.

똑같이 IoT 디바이스에서 데이터를 수집하나 

데이터 스트리밍 구조를 가진 스마트팜 A

배치 프로세스 구조를 가진 스마트팜 B가 있다고 가정했을 때,

데이터 스트리밍 구조를 가진 스마트팜 A가 데이터의 실시간성이 보장된다.

배치 프로세스 구조를 가진 스마트팜 B는 정해진 시각에 

그 동안 저장된 데이터들을 한 꺼번에 처리하기 때문이다.

즉, 다음 시간 간격 동안까지는 실시간 지표를 확인할 수 없다.

규모가 큰 기업에서는 스트리밍 데이터 구조와 배치 처리 구조를

병행하여 관리한다.

처리할 레코드의 계산이 복잡한 경우 일괄처리가 더 적합하기 때문이다.

Amazon EMR과 같은 MapReduce 기반 시스템은 배치 작업을 지원하는 플랫폼의 예이다.

반면에 스트림 처리는 데이터의 시퀀스를 수집하고,
수신되는 각 데이터 레코드에 대한 응답으로
지표, 보고서 및 요약 통계를 증분식으로 업데이트,
실시간 모니터링 및 응답 기능에 적합하다.

범용성

24년 기준으로, 개발자들은 수집에 전문화된 하드웨어나 소프트웨어를 사용하지 않아도 된다.

사물 인터넷 기기들 및 스마트폰들의 보급화로 인해

범용 시스템이 이미 충분히 작동할만한 배경이 있고

그에 맞는 웹에서 작동하는 프로토콜들이 있다.

HTTP뿐 아니라 보다 경량화된 MQTT프로토콜이 그 예이다.

Twitter의 Stream API

Twitter의 Stream API도 예로 들어보려고 한다.

Twitter의 Development platform에서는
Twitter가 제공하는 API 기능 중 Filtered stream을 이렇게 설명하고있다.

"...enables developers to filter the real-time stream of public Tweets."

실시간으로 공개 트윗들이 쏟아지는데

개발자는 본인이 정한 rule에 부합되는 Tweet들만 필터링 하여 받을 수 있다.

(어떤 시스템 아키텍쳐를 통해 Stream API를 제공하는지는 아직 조사를 안 해보았다.)

부가적으로 API의 엔터프라이즈 버전의 경우에는
endtime 파라미터를 통해 지난 24시간 동안의 빠진 데이터를 복구할 수 있다.

endtime 날짜 데이터 형식은 (YYYY-MM-DDTHH:mm:ssZ)로

국제표준화기구(ISO)에서 지정한 날짜, 시간 데이터에 대한 표준 규격을 사용한다.

필터링 rule 설정 후에는, 서버와 streaming connection을 만들 수 있다. 

Twitter 서버는 Persistent HTTP Streaming connection을 통해
JSON 형태로 Tweet 객체를 전송하기 시작한다.

stream에 연결되어있는 동안에는 개발자가 설정한
rule에 따라 필터링된 정보만 받을 수 있다.

연결을 끊지 않은 채 stream connection 상태에서 룰 수정이 가능하다.

Streaming 대 Long pooling

Streaming

서두에서 말했듯이 기존 통신 방식과 전혀 다른 기술을 사용하는 것이 아니다.

서버 관점에서 본 stream data는 전송 절차는 다음과 같다.

한 온라인 비디오 스트리밍 서비스가 있다하자.

프론트 서버는 사용자의 요청 신호를 적절하게 분배해서 전달할 것이고

인증 로직이 구현되어 있는 서버에서는 데이터베이스와 통신을 해서

가입되어 있는 사용자인지, 또는 비디오 컨텐츠에 접근이 가능한지 등의 

인증&권한을 파악할 것이다.

사용자 인증 & 권한 검사가 통과되면

서버는 response 를 지속적으로 open 상태로 유지해서

계속해서 요청 client에게 data를 보내야한다.

명시적으로 연결 끊음 명령이 입력되었을 때 연결을 close한다.

  

Long pooling

Long pooling 상태에 있는 Client와 Server는
1번 요청을 한 Client에 대해서 연결을 바로 끊지 않는다.
지정된 timeout 값을 초과하거나, 새 메시지를 Client에게 보낼 때에만 응답한다. 

새 메시지가 서버에 발생해서 Client에 메시지를 보내면,

메시지를 받자마자 Client는 다시 서버로 request를 보내 connection을 유지한다.

이런 로직은 마치 실시간으로 Push 메시지를 전송하는 기능을 구현한다. 

Long pooling은 다시 연결을 open(), close()하거나, header의 보안값 등을 검사하는 등의 overhead를 줄여준다.

Conclusion

서버에서 Client로 보낼 메시지가 자주 발생하지 않으면

Long pooling이 적합할 수 있다.

하지만 비디오 데이터처럼 실시간, 연속성이 있는 서비스라면 Streaming이 적합하다.

출처

https://aws.amazon.com/ko/streaming-data/
https://en.wikipedia.org/wiki/Connection-oriented_communication

https://developer.twitter.com/en/docs/twitter-api/tweets/filtered-stream/introduction

실시간 분석의 모든 것:스트리밍 데이터 분석 및 시각화 시스템 구축 가이드