스트리밍 분석: 이동 중 데이터 분석과 스트리밍 분석이 필요한 시점

‘실시간 분석’ 요청은 대개 5초, 30초, 혹은 1분과 같은 지연 시간 목표에서 시작됩니다. 하지만 결과가 얼마나 빨리 도출되어야 하는지 안다고 해서 스트리밍 분석이 필요한지까지 알 수 있는 것은 아닙니다.

사용자에게 최신 상태로 보이는 대시보드의 이면에는 이동 중 이벤트를 지속적으로 변환하는 스트림 처리가 있을 수도 있고, 최근 로드된 데이터에 대한 빠른 쿼리가 있을 수도 있습니다. 후자로 요구 사항을 충족할 수 있다면 스트리밍 분석의 복잡성과 그에 따른 아키텍처 부담을 굳이 감수할 이유가 없습니다.

다음 세 가지 질문에 답해 보면 더 명확하게 판단할 수 있습니다. 결과가 어느 정도 오래되면 가치를 잃게 되는가? 데이터를 활용하기 전에 변환하거나 보강해야 하는가? 그리고 이러한 변환이 이동 중 이벤트에 대해 지속적으로 이루어져야 하는가, 아니면 데이터가 랜딩된 후에 이루어져도 되는가?

첫 번째 질문의 답을 통해 최신성 목표를 정할 수 있습니다. 두 번째와 세 번째 질문의 답을 통해 스트리밍 분석 스택 중 실제로 얼마만큼이 필요한지 파악할 수 있습니다. 스트리밍 수집만 필요할 수도 있고, 스트리밍 수집과 스트림 처리가 모두 필요할 수도 있습니다.

스트리밍 분석은 데이터를 지속적으로 수집하고 필요에 따라 이동 중에 처리하여, 의사 결정과 조치에 활용할 수 있도록 최대한 빠르게 서빙 계층에 전달하는 엔드투엔드 분야입니다. 일부 스트리밍 분석 워크로드에서는 시스템이 상태를 유지하면서 새 이벤트가 반영될 때마다 결과를 업데이트해야 합니다(스트림 처리). 반면 데이터를 즉시 쿼리할 수 있는 서빙 계층으로 빠르고 안정적으로 수집하기만 하면 되는 워크로드도 있습니다.

스트리밍 분석은 더 광범위한 이벤트 기반 아키텍처의 일부이므로, 각 구성 요소가 어떤 역할을 하는지 정확히 구분하는 것이 좋습니다.

스트리밍 수집은 이벤트가 분석 환경으로 유입되는 방식입니다. Kafka 같은 플랫폼은 타임스탬프가 지정된 이벤트를 생산자와 소비자 간에 전송하며, 직접 쓰기 API와 변경 데이터 캡처는 운영 시스템의 데이터를 가져옵니다. 핵심은 데이터를 안정적이고 빠르게 가져오는 것입니다.

스트림 처리는 계산 계층입니다. Apache Flink나 Spark Structured Streaming 같은 엔진은 이러한 스트림에 대한 윈도우 집계, 상태 저장 조인, 필터링, 보강 기능을 제공합니다.

대량의 연속 데이터를 스트리밍하여 준실시간 인사이트를 얻을 수 있는 Snowpipe Streaming의 개요 영상을 시청하세요.

스트리밍 분석과 실시간 분석은 함께 논의되는 경우가 많지만, 서로 같은 개념은 아닙니다.

실시간 분석은 포괄적인 개념입니다. 정해진 시간 범위 내에서 의사 결정이나 조치가 이루어지려면 데이터와 결과가 충분히 최신이어야 하고 쿼리도 충분히 빨라야 합니다. 이러한 최신성은 스트리밍 수집, 마이크로 배치 로드, CDC 복제 또는 이들의 조합을 통해 확보할 수 있으며, 쿼리는 일반적으로 최신 데이터와 과거 컨텍스트를 함께 활용합니다.

실시간 분석 자세히 알아보기 >

스트리밍 분석은 실시간 분석의 하위 집합입니다. 스트리밍 분석은 데이터가 서빙 계층에 도달하기 전의 처리 방식에 대해 더 엄격한 요구 사항을 가집니다. 또한 더 구체적인 처리 모델이 추가됩니다. 들어오는 이벤트를 도착하는 즉시 처리하며, 이벤트, 윈도우 또는 시퀀스 전반에 걸쳐 상태를 유지하는 경우가 많습니다. 계산이 저장된 데이터가 아니라 이동 중 데이터를 대상으로 이루어지기 때문에 데이터 최신성과 변환에 관한 요구 사항이 더 엄격합니다.

5초 전에 로드된 데이터에 대해 인터랙티브 쿼리가 1초 이내에 결과를 반환한다고 가정해 보겠습니다. 비즈니스에서 10초 이내의 최신 결과만 필요하다면 이 아키텍처로도 실시간 요구 사항을 충분히 충족할 수 있습니다. 상시 실행되는 스트리밍 쿼리는 필요하지 않습니다.

이번에는 반대의 경우를 살펴보겠습니다. 파이프라인이 집계를 지속적으로 업데이트하지만, 이를 표시하는 대시보드는 한 시간에 한 번만 확인됩니다. 계산은 스트리밍 방식이지만, 조직이 추가적인 최신성에서 얻는 가치는 거의 없습니다.

스트리밍 분석이 실시간 분석과 나란히 놓이는 별개의 카테고리가 아니라 더 넓은 실시간 분석 카테고리에 속하는 이유도 여기에 있습니다. 스트리밍 계산은 실시간 분석에 필요한 최신성을 확보하는 한 가지 방법일 뿐 유일한 방법은 아닙니다. 또한 상태 관리, 순서 처리, 전달 시맨틱 측면에서 추가적인 복잡성이 따릅니다.

이러한 차이에 따라 구축해야 하는 대상이 달라집니다. 최신성 요구 사항은 데이터를 얼마나 빨리 사용할 수 있어야 하는지, 쿼리가 얼마나 빨리 결과를 반환해야 하는지에 대한 제약 조건을 정합니다. 반면 스트리밍 요구 사항이 있다는 것은 계산 자체가 진행 중인 이벤트 스트림을 계속 추적해야 한다는 의미입니다. 여기에는 결과에 영향을 미치는 상태, 순서, 타이밍 시맨틱이 모두 포함됩니다.

일부 워크로드는 새로 로드된 데이터에 대해 주기적으로 계산을 실행하는 것만으로도 충분합니다. 반면 이벤트 시퀀스, 이동 윈도우 또는 스트림이 진행되는 동안 보존해야 하는 누적 상태에 의존하는 워크로드도 있습니다.

아키텍처에 스트림 처리가 도입될 때 나타나는 가장 큰 개념적 변화 중 하나는 입력이 ‘완료’되는 자연스러운 시점이 없다는 것입니다.

지난주 매출 테이블에 대해 쿼리를 실행하는 경우에는 경계가 명확합니다. 어떤 레코드가 계산에 포함되는지 알 수 있기 때문입니다. 하지만 진행 중인 스트림에서는 경계를 직접 설정해야 합니다. 어떤 이벤트를 계산에 포함할지, 지연 데이터를 얼마나 오래 기다릴지, 이벤트가 재시도되거나 두 번 이상 전달되면 어떻게 처리할지를 정해야 합니다.

측정 대상을 정의하는 윈도우

대부분의 스트리밍 계산에는 진행 중인 스트림을 분석 가능한 단위로 나누는 방법이 필요합니다. 바로 이때 윈도우가 사용됩니다.

• 텀블링 윈도우는 겹치지 않는 고정된 기간을 생성합니다. 예를 들어 10:00~10:05의 트랜잭션 양을 계산한 다음, 10:05~10:10의 새 윈도우를 시작할 수 있습니다.
• 슬라이딩 윈도우는 서로 겹칩니다. ‘직전 10분 동안의 트랜잭션’을 1분마다 다시 계산하려는 경우, 새 윈도우마다 이전 윈도우의 이벤트 일부가 포함됩니다.
• 세션 윈도우는 이와 다르게 작동하며, 고정된 시간 경계가 아니라 활동 기간에 따라 이벤트를 그룹화합니다.

즉, ‘1,240건의 트랜잭션’과 같은 스트리밍 수치는 그 자체만으로는 불완전합니다. 해당 트랜잭션이 어떤 간격이나 세션에 속하는지도 알아야 합니다.

이벤트 시간과 처리 시간의 차이

이벤트 시간은 어떤 일이 실제로 발생한 시점입니다. 처리 시간은 분석 시스템이 해당 이벤트를 확인하거나 처리한 시점입니다. 이 두 타임스탬프는 서로 다른 경우가 많습니다.

어떤 트랜잭션이 10:04:58에 발생했지만 10:06이 되어서야 분석 파이프라인에 도달했다고 가정해 보겠습니다. 네트워크 연결이 지연되었거나 업스트림 시스템이 이벤트를 재시도했을 수 있습니다. 이벤트 시간 기준으로 보면 이 트랜잭션은 10:00~10:05 윈도우에 속합니다. 하지만 처리 시간 기준으로 보면 해당 윈도우는 이미 지난 상태입니다.

이 때문에 워터마크와 지연 데이터 정책이 필요합니다. 워터마크는 이벤트 시간이 어디까지 진행되었는지에 대한 시스템의 추정치입니다. 시스템은 이를 바탕으로 이벤트 시간 기준의 시간 범위(윈도우)가 결과를 산출할 준비가 되었는지 판단합니다. 지연 정책은 이 시점 이후에 도착한 이벤트를 어떻게 처리할지 결정합니다. 더 오래 기다리면 결과가 확정되기 전에 늦게 도착한 이벤트를 더 많이 반영할 수 있습니다. 반면 더 일찍 마감하면 더 최신의 결과를 얻을 수 있지만, 지연 데이터 때문에 결과를 업데이트하거나 별도로 처리해야 할 가능성이 커집니다.

Snowflake Interactive Analytics 수석 프로덕트 매니저 Will Xu는 이러한 허용 범위를 의사 결정 자체에 근거해 설정할 것을 제안합니다. “팀은 워크로드가 허용할 수 있는 지연 도착 데이터의 최대 윈도우를 결정해야 합니다. 일반적으로 이 윈도우는 4시간입니다. 윈도우가 클수록 인프라 비용도 높아집니다. 이는 계획 단계 초기에 내려야 하는 비즈니스 의사 결정입니다.”

전송 시맨틱이 수치에 미치는 영향

지연 이벤트는 불확실성의 원인 중 하나에 불과합니다. 재시도 역시 불확실성을 만듭니다. 분산 시스템에서는 본질적으로 연결이 끊기고, 프로세스가 재시작되며, 데이터가 재전송됩니다. 결국 지극히 평범한 질문 하나가 분석 결과에 중대한 영향을 미치게 됩니다. ‘이 이벤트를 이미 처리했는가?’

최소 1회(at-least-once) 전송 방식에서 시스템은 이벤트 손실 방지를 우선시합니다. 따라서 컨슈머가 동일한 이벤트를 두 번 이상 수신할 수 있습니다. 다운스트림 처리는 이러한 중복을 감당할 수 있어야 합니다. 일반적으로는 반복 실행해도 실질적으로 동일한 결과를 생성하는 멱등 연산을 통해 이를 해결합니다.

정확히 1회(exactly-once) 전송은 재시도가 발생하더라도 각 이벤트가 결과에 실질적으로 한 번만 반영되도록 하는 것을 목표로 합니다. 이를 위해서는 일반적으로 이벤트를 생성, 처리, 저장하는 시스템 간의 조율이 필요합니다.

분석 결과를 보는 사람에게 이 모든 인프라는 화면에 표시되는 하나의 숫자일 뿐입니다. 하지만 시맨틱이 파이프라인 속에 묻혀 버려서는 안 됩니다. 스트리밍 지표가 의사 결정에 영향을 미친다면, 팀은 해당 지표의 윈도우와 지연 데이터 처리 방식, 그리고 그 기반이 되는 전송 보장 수준을 알고 있어야 합니다.

또한 팀에는 정합성 조정 정책도 필요합니다. 10:05에 사용된 스트리밍 수치는 지연된 레코드가 시스템에 모두 반영된 후 산출된 배치 결과와 다를 수 있습니다. 어떤 수치를 기록 시스템(system of record)으로 삼을지, 그리고 이러한 차이를 어떻게 해소할지 미리 결정해 두세요.

일부 워크로드는 실제로 극히 짧은 의사 결정 윈도우 안에서 운영됩니다. 결제 사기 방지를 위한 권한 부여, 광고 입찰, 특정 기계 제어 시스템은 밀리초 단위로 대응해야 할 수 있습니다. 이런 경우 일반적으로 처리 로직이 애플리케이션 또는 스트림 처리 경로에 직접 배치되므로 트랜잭션 내에서 의사 결정이 이루어질 수 있습니다.

하지만 대부분의 엔터프라이즈 분석 사용 사례는 이러한 제약 조건에서 운영되지 않으며, 상당수는 지속적인 이동 중 계산 없이도 준실시간 분석으로 충분히 대응할 수 있습니다. 예를 들어 운영팀은 담당자가 개입할 수 있도록 몇 분 이내에 백로그가 쌓이는 상황을 파악해야 할 수 있습니다. 또는 물류 워크플로우에서는 경로 변경이 아직 가능할 때 배송 예외 상황을 확인해야 할 수 있습니다. 자동화 프로세스는 다음 작업을 결정하기 전에 최신 텔레메트리가 필요할 수 있습니다. 이러한 경우에는 수 초에서 수 분 수준의 데이터 최신성이 실질적인 가치를 제공합니다.

주기적 처리 또는 마이크로 배치 처리로 충분한 경우

배치 처리가 지금까지 꾸준히 사용되어 온 데는 그만한 이유가 있습니다. 각 실행은 정해진 간격에 따라 범위가 한정된 데이터 집합을 처리합니다. 따라서 문제가 발생했을 때 테스트, 재실행, 점검할 수 있는 비교적 명확한 단위를 제공합니다.

마이크로 배치는 이 간격을 줄여 몇 초 또는 몇 분마다 소규모 레코드 그룹을 처리합니다. 워크로드에 따라서는 마이크로 배치만으로도 충분히 최신의 데이터를 생성할 수 있는 경우가 많습니다.

예를 들어 물류 대시보드를 5분 간격으로 새로 고쳐도 충분히 유용하다면, 들어오는 모든 이벤트 간에 지속적으로 상태를 유지하더라도 의사 결정이 개선되지 않을 수 있습니다. 이 경우에는 준실시간 분석이 더 적합할 가능성이 높습니다. 그러나 팀이 진행 중인 시퀀스를 즉시 감지해야 하거나, 5분을 기다리면 개입할 수 있는 시간이 지나 버리는 경우라면 스트림 처리가 더 설득력 있는 선택입니다.

많은 팀이 파이프라인의 모든 단계에 동일한 처리 모델을 강제하기보다는 배치 방식과 스트리밍 방식을 함께 활용합니다.

지연 시간 단축에 따른 비용 증가

이러한 접근 방식은 더 유용한 비용 모델도 제공합니다. 지연 시간을 줄이려면 일반적으로 더 빈번한 처리와 더 엄격한 운영 허용 오차가 필요합니다. 이로 인해 컴퓨팅 비용은 물론, 워크로드에 필요한 모니터링, 문제 해결, 정합성 조정 부담도 늘어날 수 있습니다. 이러한 지속적인 비용을 데이터가 더 빨리 전달될 때 실제로 결과가 개선되는 의사 결정과 비교해 보세요.

다음 예시를 보면 요구 사항이 얼마나 다양할 수 있는지 알 수 있습니다.

• 사기 방지 권한 부여: 보통 밀리초 단위이며, 의사 결정 로직이 트랜잭션 또는 스트림 처리 경로에 포함됩니다.
• 운영 이상 감지: 사람이나 자동화된 워크플로우가 얼마나 빨리 대응해야 하는지에 따라 수 초에서 수 분 단위입니다.
• 재고 및 주문 처리 모니터링: 주로 분 단위로 측정되며, 증분 처리나 짧은 간격의 처리로 요구 사항을 충족할 수 있습니다.
• 경영진 보고: 다른 다운스트림 워크플로우가 데이터를 더 빨리 사용하지 않는 한, 보통 시간 단위 또는 일 단위입니다.

Snowflake는 거버넌스가 적용된 단일 플랫폼에서 수집, 스트림 처리, 짧은 지연 시간의 데이터 소비에 이르는 스트리밍 분석 전 과정을 지원합니다. 따라서 팀은 별도의 스트리밍 인프라 스택을 운영할 필요가 없습니다.

스트리밍 분석 경로는 세 단계로 구성되며, 각 단계별로 심층 가이드가 마련되어 있습니다.

스트리밍 수집은 이벤트 데이터가 생성되는 즉시 Snowflake로 가져오므로 스테이징 파일이나 중간 오브젝트 스토리지를 거칠 필요가 없습니다. 여기에는 Snowpipe Streaming을 통한 직접 API 수집, Snowflake Kafka 커넥터, 운영 데이터베이스의 변경 데이터 캡처가 포함됩니다.

스트림 처리는 데이터가 서빙 계층에 도달하기 전에 이동 중인 데이터를 변환하고 보강하며 원하는 형태로 가공합니다. 여기에는 중복 제거, 차원 테이블과의 조인, 시간 범위 집계, CDC 처리 등이 포함됩니다. 이러한 작업에는 기존에 Apache Flink와 같은 별도의 스트림 처리 엔진이 필요했습니다.

짧은 지연 시간의 서빙은 결과 데이터를 워크로드가 요구하는 속도로 쿼리할 수 있게 합니다. 인터랙티브 분석은 1초 미만의 응답 속도와 높은 동시성을 갖춘 쿼리를 지원합니다.

세 단계 모두 Snowflake 내부에서 네이티브로 실행되므로, 모든 행에는 사용자가 구성한 기존 거버넌스, 액세스 제어, 계보가 그대로 적용됩니다. 보안을 적용하거나 정합성을 맞춰야 할 별도의 스트리밍 스택이 필요하지 않습니다.

실시간 분석이 필요해지면 흔히 지속적인 수집, 이동 중 처리, 전체 스택을 갖춘 스트리밍 분석부터 곧바로 떠올리곤 합니다. 하지만 실시간 분석은 포괄적인 개념이며, 스트리밍 분석은 이를 구현하는 하나의 방법일 뿐입니다. 많은 실시간 워크로드는 이동 중 데이터(data-in-motion) 아키텍처 없이도 자주 새로 고쳐지는 데이터에 대한 빠른 쿼리만으로 충분히 지원할 수 있습니다.

먼저 워크로드에 실제로 필요한 것이 무엇인지 파악하세요. 데이터가 얼마나 최신이어야 하는지, 데이터를 활용하기 전에 변환이 필요한지, 그리고 그 변환이 이동 중에 이루어져야 하는지 확인해야 합니다. 이러한 답변을 바탕으로 스트리밍 분석 스택 중 어느 부분까지 설계에 포함할지 결정하세요. 그 결과 운영하고 정합성을 맞춰야 할 구성 요소는 줄이면서도, 필요한 곳에서는 스트리밍 성능을 그대로 확보할 수 있습니다.