스트림 처리

지표 대부분은 하루에 한 번 계산해도 됩니다. 어제 가입자 수를 오늘 아침에 아는 것으로 충분하고, 그래서 정해진 주기에 쌓인 것을 한꺼번에 처리하는 배치 처리가 오래 기본이었습니다.

몇 초 안에 알아야 하는 자리가 생기면 그 방식이 막힙니다. 페이지덱에서 결제가 승인된 뒤 플랜이 실제로 바뀌는 데 최대 여섯 시간이 걸린 적이 있습니다. 결제 기록을 읽어 계정 등급을 갱신하는 작업이 새벽 세 시에 한 번만 돌았기 때문입니다. 오후 두 시에 결제한 고객은 그날 유료 기능을 쓰지 못했고, 돈은 빠져나갔는데 화면은 그대로인 상태로 밤을 보냈습니다. 그 사이에 들어온 문의를 수아가 하나씩 손으로 처리했습니다.

주기를 줄여 해결하려는 시도가 먼저 나옵니다. 세 시간, 한 시간, 5분으로 줄입니다. 그런데 주기를 줄이면 한 번 도는 시간이 주기에 가까워져 다음 회차가 앞 회차를 기다리게 됩니다.

스트림 처리는 주기를 없앤 방식입니다. 사건 하나가 들어오면 그 자리에서 처리해 다음으로 넘깁니다. 원천 데이터를 분석할 수 있는 형태로 옮기고 다듬는 데이터 파이프라인 아래에서 주기 갈래에 속합니다.

다섯 가지를 정해야 굴러갑니다.

1. 몇 초 안에 필요한 값만 골라 적습니다. 전부를 이 방식으로 옮기지 않습니다. 페이지덱에서 이 목록에 들어간 것은 결제 승인과 플랜 변경, 그리고 팀원 초대 수락 셋뿐입니다.
2. 들어오는 사건을 줄 세웁니다. 작업을 줄 세워 비동기로 처리하게 하는 메시지 큐가 그 자리입니다. 받는 쪽이 잠깐 멈춰도 사건이 사라지지 않게 하는 장치이고, 이것 없이 곧바로 이어 붙이면 처리하는 쪽이 죽는 순간 그 시간의 데이터가 사라집니다.
3. 집계할 범위를 시간 창으로 자릅니다. 스트림에는 끝이 없어서 지금까지 몇 건이라는 값을 낼 수 없습니다. 최근 5분, 최근 1시간처럼 창을 정해 그 안에서 셉니다. 창의 길이가 그 숫자의 기간입니다.
4. 늦게 도착하는 사건을 어떻게 할지 정합니다. 휴대폰이 꺼져 있다가 10분 뒤에 올라온 기록이 있습니다. 창을 이미 닫았는데 그 창에 속한 사건이 도착하면 버릴지, 창을 잠시 열어 두고 기다릴지, 뒤늦게 값을 고칠지 골라야 합니다. 이 결정을 적어 두지 않으면 같은 시간대 숫자가 보는 시점마다 달라집니다.
5. 같은 사건이 두 번 처리되는 경우를 막습니다. 큐는 사건이 사라지지 않는 것을 보장하는 대신 같은 사건을 두 번 보낼 수 있습니다. 같은 구간을 두 번 돌려도 결과가 어긋나지 않는 재실행 안전성을 갖춰 두지 않으면 결제 한 건이 매출에 두 번 잡힙니다.

맞는 자리는 늦으면 손해가 나는 값입니다. 결제와 등급 변경, 재고 수량, 장애 감지, 이상 거래 탐지입니다. 판단 기준은 하나입니다. 이 숫자가 30분 늦으면 누가 무엇을 잘못하게 되는지입니다. 답이 없으면 배치로 둡니다.

한계는 넷입니다.

1. 부분 재처리가 까다롭습니다. 어제 오후 두 시부터 세 시까지만 다시 계산하는 일이 배치보다 어렵습니다. 과거 구간을 다시 처리해 채워 넣는 백필을 스트림에서 하려면 대개 같은 계산을 배치로 한 벌 더 만들어 둬야 합니다.
2. 만들고 고치는 값이 큽니다. 항상 돌아가고 있는 프로그램이라 코드를 바꿀 때 지금 들고 있는 집계 상태를 어떻게 이어받을지 정해야 합니다. 배치는 다음 회차부터 새 코드가 돌면 끝입니다.
3. 기준이 바뀌면 과거가 따라오지 않습니다. 오늘부터 테스트 계정을 빼기로 정하면 오늘 이후 값만 바뀌고 지난달 값은 옛 기준으로 남습니다.
4. 대부분의 지표에는 필요하지 않습니다. 하루 한 번으로 충분한 값에 이 방식을 쓰면 계산 값과 운영 손이 늘어나는 것 말고 달라지는 것이 없습니다.

작업의 선후를 들고 순서대로 실행해 주는 워크플로 오케스트레이터가 배치의 실패를 잡아 주는 것과 달리, 스트림에서는 감시와 알림이 그 역할을 맡습니다. 처리 지연을 재 두고 지연이 커지면 사람을 부릅니다.

"결제 반영이 여섯 시간 걸려요. 이 값만 스트림으로 떼죠."

전체가 아니라 한 값만 옮기자는 제안입니다.

"늦게 온 이벤트를 어떻게 처리하고 있어요? 어제 숫자가 오늘 달라졌는데요."

창을 닫은 뒤 도착한 사건의 처리 규칙을 묻는 말입니다.

"큐가 같은 메시지를 두 번 보낼 수 있으니 중복 처리 막아 두셨는지 확인 좀요."

두 번 처리로 값이 부풀 위험을 짚는 지적입니다.

페이지덱에서는 태오가 옮길 값을 고르고 지현이 그 값이 늦으면 무슨 일이 생기는지 적습니다. 목록이 세 개에서 멈춘 이유가 그 문서입니다. 숫자 대부분은 30분 늦어도 아무도 다른 결정을 하지 않았습니다.

실시간으로 보이는 화면과 정확한 값을 나눠 둔 것도 그때 정했습니다. 대시보드의 오늘 숫자는 스트림에서 오고, 월말 정산에 쓰는 값은 다음 날 배치가 다시 계산한 것을 씁니다.

즉시 처리하니 더 정확하다고 읽는 경우가 가장 많습니다. 빠른 것과 정확한 것이 함께 간다고 느껴지기 때문입니다. 실제로는 반대인 경우가 많습니다. 늦게 도착하는 사건 때문에 스트림이 낸 값은 나중에 배치가 같은 기간을 다시 계산한 값과 어긋납니다. 오후 세 시에 본 오늘 매출과 다음 날 정산표의 어제 매출이 다르게 나오는 일이 흔하고, 맞는 쪽은 뒤입니다. 그래서 실무에서는 두 값을 서로 다른 용도로 씁니다. 빠른 값은 지금 무슨 일이 벌어지는지 보는 데 쓰고, 정산과 보고에는 늦게 나오는 값을 씁니다.

배치를 대체하는 방식으로 아는 것도 흔합니다. 새로 나온 쪽이 이전 것을 밀어낸다는 인상이 붙습니다. 그런데 둘은 같은 자리를 다투지 않습니다. 대부분의 팀이 배치로 시작해 몇 초 안에 알아야 하는 자리만 스트림으로 떼어 내고, 그다음부터 두 벌을 함께 굴립니다. 처음부터 전부 스트림으로 짜면 만드는 값과 고치는 값이 몇 배로 뛰고, 데이터 품질을 지키는 일도 훨씬 어려워집니다. 어긋난 값을 찾았을 때 되돌려 다시 계산할 방법이 배치보다 마땅치 않기 때문입니다.