7.6 실시간 및 스트리밍 데이터

개요와 동기

데이터 파이프라인에 대해 아는 대부분은 데이터가 가만히 있다고 가정합니다. 하루치 기록을 모으고, 밤사이 작업을 돌리고, 아침에 결과를 읽습니다. 실시간 및 스트리밍 데이터는 그 가정을 뒤집습니다. 끝난 데이터 더미를 처리하는 대신, 도착하는 대로 끝없는 이벤트의 흐름을 처리하고 답을 지속적으로 냅니다. 이것이 한정되고 완전한 데이터셋을 다루는 배치 처리와, 한정되지 않고 끝나지 않는 흐름을 다루는 스트림 처리의 차이입니다.

큰 팀에게 스트리밍은 지연이 비즈니스에 중요해지는 순간 나타납니다. 한 시간 늦게 도착한 사기 결정은 쓸모없습니다. 내일 도착하는 개인화 신호는 아무것도 개인화하지 못합니다. 현실보다 한 교대만큼 뒤처진 운영 대시보드는 그것을 지켜보는 사람들을 오도합니다. 7.2장(데이터 엔지니어링)은 기본은 배치로 하고 지연이 정말로 보답하는 곳에서만 스트리밍에 손을 뻗으라고 주장하며, 이 장은 나머지 길을 데려갑니다. 실시간이 언제 비용만큼 값하는지, 운영 예산에 불을 지르지 않고 어떻게 만드는지입니다. 스트리밍은 3.12장(이벤트 기반 아키텍처와 메시징)의 이벤트 기반 메시징 패턴, 3.4장(데이터 아키텍처와 저장소)의 저장소 선택, 9.2장(관측 가능성과 텔레메트리)의 텔레메트리 실천과 가깝습니다.

기업과 정부 환경은 판돈을 높입니다. 은행은 카드 리더가 깜빡이는 시간 안에 거래의 사기를 점수화합니다. 교통 기관은 차량을 추적하고 수백만 승객의 도착을 예측합니다. 급여 기관은 모든 결정의 감사 가능한 기록을 유지하면서 청구의 이상을 지켜봅니다. 이 모두에서 가치는 데이터가 아직 신선할 때 행동하는 데서 오고, 위험은 틀렸거나, 불완전하거나, 나중에 재구성할 수 없는 데이터에 따라 행동하는 데서 옵니다. 이 장은 둘 다에 대해 단호합니다.

핵심 원칙

지연에 분명한 비즈니스 가치가 있을 때만 스트리밍에 손을 뻗으십시오. 배치가 더 싸고 단순합니다.
한정된(유한) 데이터와 한정되지 않은(끝없는) 데이터를 구별하고 그에 맞게 설계하십시오.
도착 시간이 아니라 이벤트 시간을 진실의 원천으로 다루고, 늦고 순서가 어긋난 데이터에 대비하십시오.
윈도우와 워터마크는 무한한 스트림에서 유한한 답을 얻는 방법입니다.
취약한 정확히 한 번의 약속보다 멱등 싱크를 통한 사실상 한 번의 결과를 선호하십시오.
상태 있는 처리는 손실이나 이중 집계 없이 복구할 수 있도록 체크포인트가 필요합니다.
백프레셔와 재처리를 사후 고려가 아니라 첫날부터 위해 설계하십시오.
스트리밍 로직을 관찰 가능하고 감사 가능하게 유지하십시오. 조용한 스트림은 실패한 배치보다 나쁩니다.

권장 사항

만들기 전에 실시간을 정당화한다

가장 중요한 스트리밍 결정은 스트리밍을 할지 말지입니다. 실시간은 운영 복잡성과 비용을 대략 두 배로 만듭니다. 실행하고 멈추는 작업을 매초 건강해야 하는 시스템과 맞바꾸기 때문입니다. 약속하기 전에 신선한 데이터가 가능하게 하는 결정과 그 결정이 늦게 도착하는 비용의 이름을 대십시오. 사기 점수화, 운영 알림, 라이브 개인화는 대개 기준을 넘습니다. 사람이 하루 두 번 보는 대시보드는 기획 회의에서 “실시간”이 아무리 만족스럽게 들려도 거의 넘지 못합니다. 지연 요건을 초나 분 단위의 숫자로 적고 현실에 견주어 확인하십시오. 사람들이 실시간이라고 부르는 것의 상당수는 몇 분마다 도는 마이크로 배치로 훨씬 적은 비용에 잘 충족됩니다.

처리 시간이 아니라 이벤트 시간을 중심으로 설계한다

스트리밍에서 가장 어려운 단일 생각은 이벤트가 한 순간에 일어나고 다른 순간에 처리된다는 것입니다. 이벤트 시간은 일이 실제로 일어난 때, 예컨대 승객이 카드를 찍은 때입니다. 처리 시간은 시스템이 그것을 처리하게 된 때입니다. 이 둘은 끊임없이 벌어집니다. 휴대폰이 터널에서 신호를 잃고 3분치 탭을 한꺼번에 업로드하고, 네트워크 문제가 메시지 순서를 바꾸고, 파티션이 뒤처집니다. 처리 시간으로 계산하면 숫자가 세상을 반영하는 대신 인프라와 함께 흔들립니다. 이 늦고 순서가 어긋난 문제가 이 규율의 핵심이며, 이벤트 기반 아키텍처의 이벤트 모델링에 직접 연결됩니다. 모든 이벤트에 원천에서 이벤트 시간을 찍고, 그 타임스탬프를 파이프라인 전체에 실어 나르고, 그에 대해 결과를 계산하십시오.

윈도우와 워터마크로 유한한 답을 얻는다

한정되지 않은 스트림은 끝나지 않으므로, 한정하기 전까지 “이벤트를 세라”에는 답이 없습니다. 윈도우가 그 한정을 합니다. 텀블링 윈도우는 시간을 예컨대 매 분 같은 고정되고 겹치지 않는 버킷으로 자릅니다. 슬라이딩 윈도우는 겹쳐서, 매 분 전진하는 5분 윈도우가 매끄러운 이동 수치를 줍니다. 세션 윈도우는 비활동의 간격으로 분리된 활동의 폭발을 묶으며, 사용자 세션에 잘 맞습니다. 윈도우가 생기면 늦은 데이터가 여전히 도착할 수 있으므로 윈도우가 언제 끝났는지 정해야 합니다. 워터마크는 주어진 이벤트 시간까지의 모든 이벤트를 아마 보았다는 시스템의 추정입니다. 워터마크가 윈도우의 끝을 지나면 결과를 내보냅니다. 얼마나 기다릴지 튜닝하십시오. 윈도우를 더 오래 열어 두면 지연과 메모리를 대가로 더 많은 늦음을 감내하고, 더 빨리 닫으면 뒤처진 것을 놓칠 위험이 있습니다. 윈도우가 닫힌 뒤 도착하는 데이터를 버릴지, 기록할지, 정정을 내보낼지 명시적으로 정하십시오.

싱크를 멱등하게 만들고 사실상 한 번을 선호한다

전달 보장은 단순하게 들리지만 그렇지 않습니다. 최소 한 번 전달은 모든 이벤트가 처리되지만 재시도 후 일부가 두 번 이상 처리될 수 있어 집계가 부풀 수 있다는 뜻입니다. 정확히 한 번은 이상적으로 들리지만 비싸고, 임의의 외부 시스템에 걸쳐 문자 그대로 받아들이면 불가능한 경우가 많습니다. 실용적 목표는 사실상 한 번입니다. 밑에서 기계가 재시도했더라도 관찰 가능한 결과가 각 이벤트가 한 번 처리된 것과 같습니다. 이는 멱등 싱크를 반복해서 써도 안전하게 만들어 도달합니다. 결정적 키와 업서트를 써서 재생된 이벤트가 중복이 아니라 덮어쓰게 합니다. 최소 한 번 전달을 멱등 쓰기와 결합하면 어디서나 무거운 트랜잭션 조율에 값을 치르지 않고 올바른 결과를 얻습니다. 진정한 정확히 한 번의 기계는 정말로 필요로 하는 좁은 곳에 남겨 두십시오.

상태 있는 처리를 체크포인트해 복구할 수 있게 한다

많은 유용한 스트리밍 계산은 상태가 있습니다. 누적 집계, 스트림 간 조인, 중복 제거, 최근 행동을 기억하는 사기 모델입니다. 그 상태는 메모리에 살며 프로세스가 재시작하면 사라집니다. 체크포인트는 주기적으로 상태와 스트림 위치를 함께 스냅샷해, 충돌 후 시스템이 모든 것을 재생하거나 기억을 잃는 대신 일관된 지점에서 재개합니다. 한정되지 않은 상태가 프로덕션에서 스트리밍 작업의 메모리를 소진하는 흔한 방법이므로 상태 크기를 의도적으로 정하십시오. 더 이상 필요 없는 상태에는 만료와 TTL을 쓰고, 상태 크기를 일급 지표로 모니터링하십시오. 실패 후 복구 시간은 실제 서비스 수준의 관심사이므로, 사용자가 하기 전에 테스트하십시오.

변경 데이터 캡처로 운영 데이터베이스에서 스트리밍한다

이벤트를 내보내도록 설계된 적 없는 데이터베이스의 변경에 반응하고 싶은 경우가 많습니다. 변경 데이터 캡처(CDC)는 데이터베이스의 트랜잭션 로그를 읽어 모든 삽입, 갱신, 삭제를 변경 이벤트의 스트림으로 바꾸어 이를 해결합니다. 이는 타이머로 테이블을 폴링하는 것보다 훨씬 낫습니다. 폴링은 느리고, 중간 상태를 놓치고, 원천을 두드립니다. CDC는 검색 색인, 캐시, 분석 저장소, 하류 서비스를 기록 시스템과 지속적으로 동기화하게 해 주며, 애플리케이션에 침습적 변경 없이 합니다. 변경 스트림을 일급 데이터 제품으로 다루십시오. 스키마의 버전을 관리하고, 의미를 문서화하고, 지연을 지켜보십시오. 하류의 모든 것이 그 지연을 물려받기 때문입니다.

두 개의 코드베이스를 유지하는 대신 스트리밍 우선 아키텍처를 선호한다

고전적인 람다 아키텍처는 정확하고 완전한 이력을 위한 배치 계층을 신선하고 근사한 결과를 위한 속도 계층과 나란히 돌린 뒤 병합합니다. 동작하지만, 같은 비즈니스 로직을 두 시스템에서 두 번 쓰고 유지하며 차이를 영원히 조정하게 만듭니다. 카파 아키텍처는 이를 붕괴시킵니다. 이벤트의 내구성 있고 재생 가능한 로그를 유지하고 모든 처리를 스트림 처리로 돌리며, 로직이 바뀔 때 로그를 재생해 이력을 재처리합니다. 단일 코드베이스가 유지하고 추론하기 극적으로 더 싸기 때문에 업계는 이 스트리밍 우선 형태로 표류해 왔습니다. 배치 필요를 보존된 이벤트 로그에 대한 재생으로 표현할 수 있다면 두 코드베이스 세금을 완전히 피합니다. 재처리가 다시 만드는 것이 아니라 되감는 일이 되도록 이력을 보존하는 로그 기반 브로커를 쓰십시오.

스트림을 SQL, 구체화된 뷰, 실시간 OLAP으로 노출한다

스트리밍이 필요한 모두가 저수준 스트림 처리 코드를 써야 하는 것은 아닙니다. 스트리밍 SQL은 분석가와 엔지니어가 윈도우, 조인, 집계를 이미 아는 언어로 표현하게 하고, 결과를 구체화된 뷰로 지속적으로 최신 상태로 유지합니다. 신선한 데이터에 대한 낮은 지연의 분석 질의에는 실시간 온라인 분석 처리(OLAP) 저장소가 스트림을 수집해 슬라이스 앤 다이스 질의에 밀리초로 답하며, 이것이 진정으로 라이브인 운영 대시보드를 움직입니다. 목표가 기능과 실험에 대한 빠른 피드백일 때는 이를 7.4장(제품 분석과 실험)의 제품 분석 실천과 짝지우십시오. 맞는 곳에서는 이 상위 수준 도구를 고르고, 표현할 수 없는 로직에는 손으로 쓴 스트림 처리기를 남겨 두십시오.

백프레셔와 재처리를 처음부터 계획한다

스트림은 처리할 수 있는 것보다 빨리 도착할 수 있습니다. 백프레셔는 느린 소비자가 쓰러지거나 데이터를 조용히 버리는 대신 상류에 속도를 늦추라고 신호하게 하는 메커니즘입니다. 파이프라인의 모든 단계가 이를 지키는지 확인하고, 커지는 지연이 경주에서 지고 있다는 가장 이른 경고이므로 소비자 지연을 대표 지표로 모니터링하십시오. 재처리는 사람들이 만들어 두었기를 바라는 다른 능력입니다. 버그를 찾거나 규칙을 바꿀 때 이력을 수정된 로직으로 재생하고 싶습니다. 이는 이벤트 로그가 충분한 이력을 보존하고 싱크가 재생을 흡수할 만큼 멱등할 때만 가능합니다. 둘 다 첫날부터 설계에 넣으십시오. 사고의 압박 아래 사후 보강하는 것은 비참합니다.

장단점

선택	장점	단점	가장 적합한 곳
배치	단순하고, 싸고, 테스트와 백필이 쉬움	높은 지연. 실행 사이에는 낡음	보고, 대부분의 분석
마이크로 배치 (분 단위)	거의 실시간. 스트리밍보다 훨씬 단순	진정한 즉시는 아님	“실시간” 대시보드
진정한 스트리밍 (1초 미만)	즉각적 반응. 지속적 결과	복잡하고 비싸며 테스트하기 어려움	사기, 알림, 라이브 개인화
최소 한 번 + 멱등 싱크	올바른 결과. 감당할 만함. 복원력	규율 있는 키 설계 필요	대부분의 스트리밍 파이프라인
정확히 한 번의 기계	끝에서 끝까지 강한 보장	비싸고 시스템 간에는 제한적	좁고 판돈이 큰 경로
람다 (배치 + 속도)	정확한 이력에 신선한 뷰	유지할 두 개의 코드베이스	레거시 이전
카파 (스트리밍 우선)	하나의 코드베이스. 재생 가능	보존된 내구성 있는 로그 필요	새 스트리밍 플랫폼

중심 긴장은 지연 대 복잡성입니다. 실시간을 향한 모든 걸음은 운영 부담, 테스트 어려움, 돈이 들며, 수익은 선형이 아닙니다. 일 단위에서 몇 분마다로 가는 것은 싸고 흔히 충분한 반면, 분에서 1초 미만으로 가는 것은 비용이 집중되는 곳입니다. 기술이 아니라 결정의 가격을 매겨 긴장을 해결하십시오. 신선함이 가능하게 하는 행동과 늦음의 비용을 묻고, 그 행동이 정당화하는 만큼의 지연 감소만 사십시오. 스트리밍이 필요할 때는 최소 한 번 전달에 멱등 싱크와 스트리밍 우선 로그를 쓰십시오. 그 조합이 가장 무거운 보장 없이도 정확성과 재생 가능성을 주기 때문입니다.

팀과 논의할 질문

실시간 데이터는 실제로 우리에게 어떤 결정을 가능하게 하며, 그 데이터가 즉시가 아니라 1분 늦게 도착하면 비용이 얼마입니까? 이 질문이 모든 스트리밍 프로젝트를 관문 통제해야 합니다. 스트리밍은 배치에 비해 운영 비용과 복잡성을 대략 두 배로 만들기 때문입니다. 큰 팀이 사람이 하루 두 번 확인하는 대시보드를 위한 실시간 플랫폼을 만드는 데 몇 분기를 태울 수 있으며, 이는 불에 던진 돈입니다. 데이터가 이끄는 구체적 행동을 가져오십시오. 사기 거래 차단이든, 운영자 호출이든, 사용자가 보는 것의 변경이든, 각각에 대해 지연의 비용에 숫자를 매기십시오. 정직한 답이 5분 마이크로 배치가 필요를 충족한다는 것이라면, 그것은 숨길 것이 아니라 축하할 발견입니다. 답은 진정한 스트리밍을 만들지, 마이크로 배치로 만족할지, 배치에 머물지를 직접 바꿔야 합니다.
늦고 순서가 어긋난 이벤트를 어떻게 다루며, 윈도우가 닫힌 뒤 도착하는 데이터는 어떻게 됩니까? 늦고 순서가 어긋난 데이터는 스트리밍의 어려운 부분이며, 이 질문을 건너뛴 팀은 숫자가 맞춰지기를 거부할 때 프로덕션에서 이를 발견합니다. 경쟁하는 압력은 지연과 정확성입니다. 윈도우를 더 오래 열어 뒤처진 것을 잡으면 모든 결과가 늦어지고 메모리를 더 쓰며, 더 빨리 닫으면 실제 데이터를 조용히 버립니다. 데이터가 실제로 얼마나 늦게 도착하는지의 증거를 가져오십시오. 원천 전반에 걸쳐 이벤트 시간과 처리 시간의 간격으로 측정합니다. 터널의 모바일 원천은 서버 측 이벤트와 매우 다르게 행동하기 때문입니다. 늦은 데이터를 버릴지, 기록할지, 정정을 촉발할지 명시적으로 정하고 하류의 모두가 어느 쪽인지 알게 하십시오. 수치가 방어 가능해야 하는 정부 맥락에서 늦은 이벤트를 조용히 버리는 것은 컴플라이언스 문제일 수 있으므로, 정책은 의도적이고 문서화되어야 합니다.
싱크가 이력을 안전하게 재생할 만큼 멱등하며, 이벤트 로그가 재생을 가능하게 할 만큼 충분히 보존됩니까? 재처리는 팀이 만들어 두었기를 가장 자주 바라고 가장 자주 만들지 않은 능력이며, 두 가지가 함께 동작하는 데 달려 있습니다. 재생된 이벤트를 중복 없이 흡수하는 멱등 싱크와, 재생할 만큼 이력을 보존하는 내구성 있는 로그입니다. 둘 다 없으면 로직 버그를 고쳐도 영향받은 기간을 깨끗하게 재계산할 수 없고, 압박 아래 숫자를 손으로 땜질하게 됩니다. 현재 보존 기간과 구체적인 테스트를 가져오십시오. 지난 분기의 실제 버그 하나를 골라 영향받은 데이터에 수정된 로직을 재생할 수 있었을지 물으십시오. 이에 맞서는 끌림은 비용입니다. 이력을 보존하고 멱등 쓰기를 설계하는 데는 앞서 저장소와 규율이 들기 때문입니다. 그러나 대안은 사고 중이라는 최악의 순간에 드러나므로, 답은 필요하기 전에 재생 가능성에 얼마나 투자할지 형성합니다.
스트리밍 작업이 충돌하면 얼마나 빨리 복구해야 하고, 상태를 얼마나 가질 수 있으며, 프로덕션 부하에서 복구를 실제로 시간 재 봤습니까? 죽은 배치 작업은 내일 다시 실행하면 되지만, 죽은 상시 스트림은 진행 중인 장애이며, 누적 집계, 조인, 사기 모델을 쥔 상태 있는 작업은 재시작 후 몇 분치 기억을 잃거나 상태를 다시 불러오는 데 오래 걸릴 수 있습니다. 큰 팀에서 이것이 화려하지 않은 세부 사항이 실제 가용성을 조용히 정하는 곳입니다. 한정되지 않은 상태는 작업의 메모리가 소진될 때까지 커지고, 느린 체크포인트 복원은 10초의 깜빡임을 10분으로 바꿉니다. 경쟁하는 압력은 신선함 대 안전입니다. 더 자주 하는 체크포인트는 복구를 단축하지만 오버헤드를 더하고, 넉넉한 상태 보존은 정확성을 높이지만 메모리 소진 위험이 있기 때문입니다. 구체적인 복구 시간 목표, 현재 상태 크기와 성장 곡선, 체크포인트 간격, 희망적인 추정이 아니라 실제 장애 조치 훈련의 결과를 가져오십시오. 스트림이 사기 점수화나 공공 안전 피드를 뒷받침하는 기업과 정부 환경에서 테스트되지 않은 복구 경로는 측정하지 않고 받아들인 운영 위험이므로, 훈련을 있으면 좋은 것이 아니라 요건으로 다루십시오.
하나의 스트리밍 우선 코드베이스를 운영합니까, 별도의 배치 계층과 속도 계층을 운영합니까? 둘을 조정된 채로 유지하는 데 실제로 비용이 얼마나 듭니까? 정확한 이력을 위한 배치 계층에 신선한 결과를 위한 속도 계층을 더하는 람다 패턴은 같은 비즈니스 로직을 두 시스템에서 두 번 쓰고 그 답을 영원히 조정하게 하는 반면, 스트리밍 우선(카파) 형태는 내구성 있고 재생 가능한 로그를 유지하고 모든 처리를 스트림 처리로 돌립니다. 큰 조직에서 중복된 로직은 드리프트와 논쟁이 되는 숫자가 자라나는 곳입니다. 규칙이 한 계층에서는 바뀌고 다른 계층에서는 바뀌지 않아, 엔지니어들이 둘이 왜 다른지 설명하는 데 실제 시간을 쓰기 때문입니다. 둘을 모두 유지하려는 끌림은 관성과 검증된 배치 계층의 편안함이므로, 이를 유지보수 세금에 견주어 정직하게 저울질하십시오. 오늘 두 곳 모두에서 돌리는 계산의 목록, 두 계층이 어긋나 생긴 사고, 이벤트 로그가 배치 필요를 재생으로 표현할 만큼 충분한 이력을 보존하는지의 평가를 가져오십시오. 정부와 감사받는 기업 맥락에서 같은 기간에 대해 다른 수치를 보고할 수 있는 두 계층은 그 자체가 컴플라이언스 부채입니다. 어느 숫자가 권위 있고 왜인지 말할 수 있어야 하기 때문입니다.
이 상시 시스템이 새벽 3시에 깨지면 누가 운영하며, 요구하는 온콜 부하와 전문 기술에 예산을 잡았습니까, 아니면 배치 모양의 인력 배치를 가정하고 있습니까? 스트리밍은 비용을 구축에서 운영으로 옮깁니다. 시스템이 매초 건강해야 하므로, 실제 온콜 커버리지, 이벤트 시간, 워터마크, 상태, 전달 의미론에 능숙한 엔지니어, 실행하고 멈추는 작업보다 어려운 테스트가 필요합니다. 팀들은 스트리밍 플랫폼을 그 역량만 보고 승인하고 그것을 살려 둘 사람에게는 자금을 대지 않아 플랫폼이 저하되고 신뢰가 침식됩니다. 트레이드오프는 범위 대 지속 가능성입니다. 추가되는 실시간 파이프라인마다 누군가를 호출할 수 있는 또 하나이므로, 질문은 그것이 사는 지연이 영구적 운영 약속을 정당화하는가입니다. 프로덕션의 각 스트림을 누가 소유하는지, 현재 온콜 순환과 그 여유, 이벤트 시간 전문성이 실제로 어디에 있는지(채용, 파트너, 관리형 서비스)의 정직한 목록을 가져오십시오. 공공 기관이나 대기업에서는 조달과 채용의 리드 타임과 관리형 서비스 옵션을 더하십시오. 모집하거나 유지할 수 없는 희소한 인재에 의존하는 실시간 플랫폼은 인력이 부족한 장애 잦은 시스템을 운영하겠다는 계획이기 때문입니다.

분야별 관점

스타트업. 스트리밍은 첫 수가 되는 경우가 드물며, 무거운 플랫폼을 세우면 아주 작은 팀을 가라앉힐 수 있습니다. 핵심 가치에 닿는 신호 하나를 골라 이벤트를 보존하는 단일 로그 기반 브로커에 올리고, 최소 한 번 재시도가 이중 집계하지 않도록 키가 있는 멱등 싱크가 있는 가벼운 처리기를 돌리십시오. 수정된 로직으로 재생할 수 있도록 며칠의 이력을 유지하고, 가장 희소한 자원이 엔지니어링의 주의이므로 자체 클러스터를 운영하는 것보다 관리형 스트리밍 서비스를 선호하십시오.

소기업. 스트리밍 전문가도 상시 인프라를 운영할 의욕도 없을 테니, 실시간을 인력을 두는 시스템이 아니라 이미 쓰는 도구 안에서 사는 것으로 다루십시오. 필요를 숫자가 붙은 지연의 문제로 구성하면, 대부분의 경우 몇 분마다 갱신되는 마이크로 배치가 훨씬 적은 비용과 위험으로 충족합니다. 지연에 대해 투명하고 대체하기 쉬운 실시간 기능을 가진 벤더를 고르고, 맞춤 스트리밍은 신선한 데이터가 매출이나 안전을 직접 이끄는 드문 경우에 남겨 두십시오.

대기업. 문제는 많은 팀에 걸친 일관성과 비용입니다. 공유 로그 기반 플랫폼, 표준 이벤트 시간과 늦은 데이터 정책, 그룹들이 취약한 파이프라인을 다시 발명하지 않도록 하는 멱등 싱크입니다. 상시 운영과 온콜 부담을 명시적으로 예산에 잡고, 중복된 배치 코드베이스를 피하도록 스트리밍 우선 로그로 표준화하고, 스트림을 맞춤 작업의 흩어짐이 아니라 소유자, 스키마 버전 관리, 모니터링되는 지연이 있는 거버넌스가 적용되는 데이터 제품으로 관리하십시오. 지연, 복구 시간, 스트림당 비용을 포트폴리오 지표로 추적하십시오.

정부. 감사 가능성과 공적 책임이 모든 선택을 형성합니다. 감독 기관에 보고되는 수치, 곧 승객 수, 급여 이상, 사기 결정을 정확히 재구성할 수 있도록 처리된 모든 이벤트를 내구성 있는 로그에 보존하고, 늦은 데이터 정책을 이벤트를 조용히 버리는 대신 명시적이고 문서화하십시오. 조달은 데이터 이식성과 관리형 서비스의 전달 및 보존 보장의 공개를 요구해야 하며, 규칙이 바뀐 뒤의 모든 재작성은 아무도 추적할 수 없는 수동 땜질이 아니라 수정된 로직을 통한 방어 가능한 재생이어야 합니다.

사례

스타트업. 한 소비자 앱이 사용자에게 라이브 활동 피드를 보여 주고 의심스러운 로그인을 일어나는 대로 표시하고 싶어 합니다. 팀은 무거운 스트리밍 플랫폼을 세우는 것에 저항합니다. 이벤트를 보존하는 단일 로그 기반 브로커에 올리고, 로그인 위험 로직에 가벼운 스트림 처리기를 돌리고, 활동 피드를 움직이는 실시간 OLAP 저장소에 공급합니다. 모든 싱크가 키가 있고 멱등이므로 최소 한 번 재시도가 이중 집계하지 않습니다. 나중에 위험 규칙에서 버그를 찾았을 때, 일주일치 이력을 보관했고 두 번째 배치 코드베이스가 필요 없었기 때문에 밤사이 수정된 로직으로 로그를 그냥 재생합니다.

기업. 한 소매 은행이 최근 계정 행동의 상태 있는 모델에 라이브 거래 스트림을 조인해 승인 윈도우 안에 모든 카드 거래의 사기를 점수화합니다. 체크포인트 덕에 점수화 서비스가 노드 장애에서 최근 몇 분의 기억을 잃지 않고 몇 초 만에 복구합니다. 별도로 변경 데이터 캡처가 핵심 뱅킹 데이터베이스의 갱신을 검색 색인과 개인화 서비스로 스트리밍해, 폴링 없이 둘을 신선하게 유지합니다. 운영 대시보드는 실시간 OLAP 저장소에서 읽어 위험과 운영 팀이 사업이 움직이는 대로 지켜보며, 전체 파이프라인은 9.2장에 기술된 지연과 처리량 텔레메트리를 내보냅니다.

정부. 한 대도시 교통 기관이 차량 위치와 요금 탭을 수집해 도착을 예측하고 혼잡을 실시간으로 모니터링하며, 공개 앱과 운영 센터 양쪽에 공급합니다. 터널의 승객이 탭을 지연된 폭발로 업로드하므로, 팀은 관찰된 늦음에 맞춰 튜닝된 워터마크로 이벤트 시간에 승객 수를 계산하고, 윈도우가 닫힌 뒤 도착하는 이벤트를 조용히 버리는 대신 기록합니다. 감독 기관에 보고되는 승객 수를 정확히 재구성할 수 있도록 처리된 모든 이벤트가 감사 가능한 로그에 보존됩니다. 요금 규칙이 바뀌면 영향받은 기간을 수정된 로직으로 재생해 방어 가능한 재작성을 만듭니다.

비즈니스 사례: 동기, ROI, TCO

실시간 데이터의 수익은 행동이 여전히 중요할 때 행동하는 데서 나옵니다. 승인 중에 잡은 사기는 야간 배치가 보고만 할 손실을 막습니다. 세션 안에서 반응하는 개인화는 내일의 추천이 할 수 없는 방식으로 전환을 끌어올립니다. 현재를 반영하는 운영 모니터링은 작은 문제가 장애나 공개 사고가 되기 전에 개입하게 합니다. 각 경우에 가치는 지금 행동하는 것과 나중에 행동하는 것의 차이이며, 논거를 만들 때 정량화해야 할 것이 그 차이입니다.

총소유비용은 배치보다 높으며, 그에 대해 정직한 것이 신뢰성을 지킵니다. 상시 인프라, 이벤트 시간, 워터마크, 상태, 전달 의미론을 이해하는 엔지니어, 실행하고 멈추는 대신 지속적으로 건강해야 하는 시스템의 더 어려운 테스트와 온콜 부담에 값을 치릅니다. 보존된 로그 위의 스트리밍 우선 아키텍처는 중복된 배치 코드베이스를 면하게 해 지속적 비용을 낮추고, 멱등 싱크가 있는 최소 한 번을 고르면 끝에서 끝까지 정확히 한 번의 기계 비용을 피합니다. 가장 비싼 실수는 마이크로 배치나 배치로 될 곳에 실시간을 만드는 것이므로, 가장 강한 비용 논거는 스트리밍하지 않기로 하는 결정인 경우가 많습니다. 리더십에는 지연에 민감한 구체적 결정과 측정 가능한 보답을 중심으로 제안을 구성하고, 배치에 머무는 것이 가치 손실 없이 돈을 아끼는 곳도 똑같이 분명히 하십시오.

안티패턴과 함정

몇 분마다의 마이크로 배치가 필요를 충족할 때 위신을 위해 스트리밍을 만드는 것.
처리 시간으로 계산해 숫자가 세상 대신 인프라와 함께 흔들리는 것.
프로덕션에서 조정이 실패할 때까지 늦고 순서가 어긋난 데이터를 무시하는 것.
멱등 싱크가 있는 최소 한 번 대신 문자 그대로의 정확히 한 번을 어디서나 쫓는 것.
만료 없는 한정되지 않은 상태로, 작업의 메모리가 소진될 때까지 조용히 자라는 것.
체크포인트가 없어 재시작이 상태를 잃거나 전체 재생을 강제하는 것.
변경 데이터 캡처를 쓰지 않고 타이머로 운영 데이터베이스를 폴링하는 것.
중복되고 표류하는 로직으로 람다 배치 계층과 속도 계층을 유지하는 것.
버그를 찾았을 때 이력을 재생하기에 너무 짧은 보존 기간.
지연, 처리량, 최신성 지표 없이 조용히 실패하는 스트림.

성숙도 모델

1단계, 시작: 모든 것이 배치이거나, 손으로 만든 몇 개의 스트리밍 작업이 모니터링 없이 반응적으로 돕니다. 숫자는 처리 시간으로 계산되고, 늦은 데이터는 무시되며, 재시작은 상태를 잃습니다. 아무도 버그를 고치려고 이력을 재생할 수 없고, 하류 수치가 조정에 실패할 때 문제가 발견됩니다.
2단계, 발전: 일부 팀이 체크포인트가 있는 로그 기반 브로커에서 핵심 스트리밍 파이프라인을 돌리고, 이벤트 시간과 처리 시간을 구별하며 기본 윈도우를 씁니다. 실천은 팀마다 일관되지 않습니다. 전달은 최소 한 번이지만 모든 싱크가 멱등한 것은 아니고, 늦은 데이터 처리는 즉흥적이며, 지연은 알림이 아니라 비공식적으로 지켜봅니다.
3단계, 표준화: 이벤트 시간, 워터마크, 명시적 늦은 데이터 정책이 문서화되어 조직 전체에 적용됩니다. 싱크는 사실상 한 번의 결과를 위해 멱등하고, 상태에는 만료가 있으며, 변경 데이터 캡처가 관례로 하류 시스템에 공급합니다. 보존된 로그가 재생을 뒷받침하고, 지연, 처리량, 최신성이 팀별 습관이 아니라 조직 전체의 표준으로 알림과 함께 모니터링됩니다.
4단계, 관리: 스트리밍 영역이 기준선에 대해 측정되고 통제됩니다. 각 파이프라인은 끝에서 끝까지의 지연, 소비자 지연, 복구 시간, 이벤트 시간 편차, 늦은 이벤트 비율, 상태 크기, 백만 이벤트당 비용에 대한 서비스 수준 목표를 지니며, 모두 합의된 목표에 대해 추적되고 회귀 시 알림을 줍니다. 복구는 가정되는 것이 아니라 훈련되고 시간이 측정되고, 백프레셔 여유와 상태 증가는 용량 신호로 지켜보며, 새 스트림은 프로덕션에 가기 전에 이 지표를 통과해야 합니다.
5단계, 오케스트레이션: 스트리밍 우선 아키텍처가 하나의 재생 가능한 로그에서 신선한 필요와 과거 필요를 모두 섬기고, 스트리밍 SQL, 구체화된 뷰, 실시간 OLAP이 신선한 데이터를 폭넓게 접근 가능하게 합니다. 재처리는 일상적이고 테스트되며, 플랫폼은 측정된 부하와 비용에 맞춰 자동 확장하고 재균형하며, 스트림은 증거에 따라 퇴역하고, 범위가 다시 정해지고, 교체됩니다. 스트리밍은 비즈니스 및 위험 계획과 통합되고, 부하와 비용 그림이 이동함에 따라 모든 스트림이 끝에서 끝까지 관찰 가능하고 감사 가능합니다.

논의를 위한 아이디어

스택의 어디서 “실시간”이 비용만큼 값하고, 어디서 검토되지 않은 소원입니까?
원천 전반에서 이벤트 시간과 처리 시간의 간격은 얼마나 크며, 측정하고 있습니까?
람다 배치-속도 구성을 하나의 스트리밍 우선 코드베이스로 붕괴시킬 수 있겠습니까? 무엇이 막겠습니까?
싱크 중 진정으로 멱등한 것은 어느 것이며, 오늘 지난 분기 데이터를 수정된 로직으로 안전하게 재생할 수 있습니까?
윈도우가 닫힌 뒤 도착하는 데이터에 대한 정책은 무엇이며, 하류의 모두가 압니까?
변경 데이터 캡처는 검색, 캐시, 분석을 동기화 상태로 유지하는 방식을 어떻게 바꾸겠습니까?

핵심 요점

지연에 민감한 결정이 값을 할 때만 스트리밍에 손을 뻗으십시오. 배치와 마이크로 배치가 더 싼 기본값입니다.
이벤트 시간으로 계산하고, 늦고 순서가 어긋난 데이터를 윈도우와 워터마크로 다루는 핵심 문제로 취급하십시오.
어디서나 문자 그대로의 정확히 한 번보다 사실상 한 번의 결과를 위해 멱등 싱크가 있는 최소 한 번 전달을 선호하십시오.
상태 있는 처리를 체크포인트하고, 상태를 한정하고, 소비자 지연을 대표 지표로 모니터링하십시오.
폴링 대신 변경 데이터 캡처로 운영 데이터베이스에서 스트리밍하십시오.
두 개의 코드베이스를 유지하는 것보다 보존되고 재생 가능한 로그 위의 스트리밍 우선 아키텍처를 선호하십시오.
스트리밍 SQL, 구체화된 뷰, 실시간 OLAP으로 스트림을 노출하고 모든 스트림을 관찰 가능하고 감사 가능하게 유지하십시오.

참고 문헌과 더 읽을거리

Tyler Akidau, Slava Chernyak, and Reuven Lax, “Streaming Systems.”
Martin Kleppmann, “Designing Data-Intensive Applications.”
Nathan Marz and James Warren, “Big Data” (Lambda architecture).
Jay Kreps, “Questioning the Lambda Architecture” (O’Reilly Radar).
Fabian Hueske and Vasiliki Kalavri, “Stream Processing with Apache Flink.”
Ben Stopford, “Designing Event-Driven Systems.”
Tyler Akidau and colleagues, “The Dataflow Model” (VLDB paper on windowing and watermarks).