Sailhouse

토픽은 이벤트가 나뉘는 바구니다. slug로 식별되는 하나의 토픽에 JSON 이벤트를 발행하면, 플랫폼이 그 토픽에 붙은 각 구독으로 나눠 보낸다. 이벤트는 메타데이터도 지녀서, 여기에 트레이스 ID를 붙이거나 cron이 발생시킨 이벤트에 스케줄을 실어 보낸다. 토픽과 구독이 두 가지 기본 자원이고, 나머지는 그 위에 세워진다.

Sailhouse는 두 전달 방식을 모두 지원한다. 푸시 구독은 이벤트가 도착하면 엔드포인트로 POST 요청을 보내고 5초 안에 200 응답을 기대한다. 풀 구독은 반대다. 워커가 자기 속도로 이벤트를 요청하며, 결제 주기나 주간 요약처럼 처리가 무거운 작업에 맞는다. 선택은 구독 단위로 하므로, 토픽 하나가 실시간 웹훅과 배치 워커를 동시에 먹일 수 있다.

대기 그룹은 병렬 에이전트 작업을 실용적으로 만드는 기능이다. 발생시킬 이벤트 목록과 완료 시 알릴 토픽을 넘기면, Sailhouse가 실행하고 그룹 전체가 끝났을 때 이벤트 하나를 발행한다. 이것이 없으면 중복 확인을 짜거나 "다 끝났나"라는 경합에 약한 루프를 돌려야 한다. 프로그래밍 언어의 wait-group과 같은 패턴을, 재시도가 군더더기 호출을 만들지 않는 이벤트 기반 시스템으로 옮긴 셈이다.

Sailhouse는 자원을 필요할 때 만든다. 없는 토픽으로 이벤트를 보내면 준 slug로 토픽을 만들고 그 이벤트를 담는다. 풀 구독도 같은 식으로 만들 수 있으며, 최대 24시간의 시간 창으로 그 기간에 토픽에 들어온 것을 한꺼번에 끌어온다. 목표는 코드를 쓰고 내보내기까지의 스키마 단계를 줄이는 것이다. 에이전트를 반복해 다듬을 때 이 점이 크다.

작업을 나중으로 미루는 방법은 두 가지다. 예약 이벤트는 단일 이벤트나 구독에 시각을 정해, 주문 14일 뒤 결제를 처리하거나 알림을 보내는 데 쓴다. cron 작업은 현재 비공개 베타로, 반복 스케줄에 따라 이벤트를 토픽으로 발생시킨다. 시각은 항상 UTC이며 일간 요약이나 시간 단위 사용량 계산에 쓴다. 둘 다 같은 구독 모델을 쓰므로 따로 배울 스케줄러가 없다.

구독 필터를 쓰면 토픽을 범용으로 두면서도 잡음과 비용을 줄일 수 있다. 토픽 하나를 열댓 개의 좁은 토픽으로 쪼개는 대신, JSON 경로로 구독 쪽을 걸러 소비자는 관심 있는 이벤트만 본다. 같은 계층에서 속도 제한과 중복 제거도 지원하며, 중복 전달이나 폭주하는 발행자의 급증을 막는 방어를 여기에 둔다.

Sailhouse는 TypeScript와 JavaScript, Go, Python(베타), Rust(베타)용 자체 SDK를 내고, 나머지에는 CLI와 REST API를 제공한다. 관측성은 이벤트 추적을 다뤄, 트레이스 ID를 붙여 이벤트를 시스템 전체에서 따라갈 수 있다. 호스팅 서비스라 현재 수집 리전은 런던, 애슈번, 산호세에 걸치고, 데이터는 중앙에 기록되며 전송과 저장 시 모두 암호화된다.