신뢰할 수 있는 실행

자동화는 뭔가를 두 번 보내기 전까지는 아무도 눈치채지 못해요

그러고 나서야 모두 눈치채죠. 이 페이지의 네 가지 메커니즘이 존재하는 이유는, 이런 소프트웨어의 실패가 언제나 같은 네 가지이고, 그 모두가 주의가 아니라 설계로 피할 수 있기 때문이에요.

게시 전에 시뮬레이션하세요

꺼져 있는 워크플로에 실제 레코드를 통과시키고, 정확히 무슨 일이 일어났을지 그대로 읽어보세요. 취해진 경로, 매 스텝의 모든 값, 모든 메시지의 문구, 그리고 각 외부 시스템으로 전송됐을 요청까지요.

아무것도 밖으로 나가지 않아요. 이메일도 보내지지 않고, 송장도 발행되지 않고, 결제도 시도되지 않고, 행도 기록되지 않아요. 외부 호출은 의도로 기록되고, 전송됐을 페이로드와 함께 보관되므로, 누군가의 문제가 되기 전에 매핑이 맞는지 확인하실 수 있어요.

시뮬레이션은 사람들이 자동화를 켜는 일을 막는 질문, 즉 이게 실제로 뭘 하는가?에 답하는 방법이에요.

시뮬레이션 · 주문 88,214발송 없음

1주소 검증일치했어요. 6개 필드를 작성했을 거예요.
?조건1 000 zł 넘는 주문인가요? 아니요 — 289,00 zł예요. 짧은 경로를 거쳤어요.
3청구서송장 시스템으로 POST 요청을 보냈을 거예요. 페이로드 전체가 표시돼요.
!여기서 잡혔어요부가세율을 잘못된 필드에서 가져왔어요. 회계사의 받은 편지함이 아니라 시뮬레이션에서 발견됐어요.

전송됨: 없음청구됨: 없음

실행은 진입 시점의 버전을 따라갑니다

워크플로에 변경 사항을 게시해도 이미 그 안에 들어 있는 실행에는 영향을 주지 않아요. 각 실행은 시작한 버전에 고정되며, 얼마나 오래 걸리든 그동안 얼마나 다시 작성하든 그 버전으로 끝까지 진행돼요.

그래서 만 명이 절반쯤 진행 중인 워크플로를 재구성해도, 모든 사람이 약속받은 흐름을 그대로 완료해요. 진입 시점에 전체 다운스트림 경로를 구체화하는 대안이야말로 대부분의 도구에서 실행 중인 자동화를 편집하는 게 위험하게 느껴지는 이유예요. 여기서는 그냥 당연한 일이에요.

새 실행은 게시하는 순간부터 새 버전을 받아요. 실행이 어느 버전에 있는지는 실행 자체에 기록되므로, 3월의 동작에 대한 질문에 9월에도 답을 찾을 수 있어요.

실행 중 편집v4 → v5

1이전진행 중인 실행 2 918건, 모두 v4예요. 일부는 이틀 대기 중이에요.
2v5 게시11:40두 단계의 순서를 바꾸고, 메시지 하나를 다시 썼어요.
3이후그 2 918건은 v4로 끝나요. 11:40부터 시작하는 모든 것은 v5로 실행돼요.
§아무도한 워크플로의 절반과 다른 워크플로의 절반을 받지 않았어요.

모든 실행에 버전 기록이전 버전 보존

이중 전송이 불가능한 재시도

단계는 입력값의 순수 함수이고, 그 효과는 실행이 다음 단계로 진행되는 것과 함께 커밋돼요. 메시지는 나갔는데 실행은 그 사실을 모르는 창은 존재하지 않아요.

이게 전부인데, 약속이 아니라 구조적 특성이에요. 단계 도중에 죽은 워커 — 배포, 크래시, 사라진 머신 — 는 실행을 정확히 원래 자리에 남겨둬요. 다른 워커가 그것을 받아 단계를 다시 실행해요. 효과와 진행이 하나로 커밋되기 때문에, 둘 다 일어났거나 둘 다 일어나지 않았어요.

멱등성 키를 지원하는 시스템으로 나가는 호출에는 실행과 단계에서 파생된 키가 실려서, 상대방도 반복을 인식할 수 있어요.

전송 도중 워커 사망복구됨

15단계 시작09:14:06배송 알림을 보내요.
✕워커 사망09:14:07배포. 아무것도 커밋되지 않았어요.
2인계됨09:14:31다른 워커가 실행이 여전히 5단계에 있는 걸 발견해요.
✓한 번만 전송됨09:14:32고객은 두 통이 아니라 한 통의 이메일을 받았어요.

효과는 진행과 함께 커밋실행·단계별 멱등성 키

사람이 읽기 위해 쓰인 로그

모든 실행, 모든 단계, 선택된 분기와 그것을 결정한 값. 단계별 소요 시간. 자격 증명이 가려진 각 외부 호출의 요청과 응답. 실행이 있던 버전. 실행이 대기 중인 위치와 대기 기한.

십사 일에 접수된 주문에 무슨 일이 있었는지 누군가 물으면 답이 있고, 찾는 데 세 시스템의 로그를 대조하는 오후가 아니라 1분이면 충분해요.

실패한 실행은 한 곳에 모여 원인별로 그룹화되므로, “밤사이 마흔한 번의 실패”가 마흔한 번의 별도 조사가 아니라 “공급업체가 503을 9분간 반환”이라는 하나의 결론으로 정리돼요.

밤사이, 그룹화됨실패 41건

1원인 하나공급업체 API가 02:41부터 02:50까지 503을 반환했어요.
2무슨 일이 있었나요41건 모두 재시도했고, 39건은 두 번째 시도에서 성공했어요.
3남은 건두 건이 중단된 상태로 담당자를 기다리고 있어요. 두 건 모두 실패한 행과 함께 목록에 표시돼요.
§마흔한 번이 아니라조사 한 번, 그리고 두 레코드에 대한 결정 하나예요.

자격 증명 비공개 처리버전 기록됨

말하지 않는 것들

마케팅 페이지에 가동률 수치를 게시하지 않아요. 측정 기간과 “가동”의 정의 없는 숫자는 장식에 불과하기 때문이에요. 계약상 필요하시면 말씀해 주세요. 실제로 약속할 수 있는 범위에 대해 논의해 드릴게요.

또한 다른 사람의 API를 안정적으로 만들 수는 없어요. 공급업체가 다운되면, 그에 의존하는 워크플로는 대기하고, 재시도하고, 결국 명확한 이유와 함께 중단돼요. 우리가 약속할 수 있는 것은 실패가 잘 보인다는 것, 무언가를 손상시키지 않는다는 것, 그리고 재개할 때 메시지를 두 번 보내지 않는다는 것뿐이에요.

대기에 대해: 이틀간 대기하는 실행은 큐에 쌓여 있는 작업이 아니라 실행에 기록된 wake_at이에요. 그래서 워크플로가 3주간의 대기 중에 십만 개의 실행을 비용 없이 보유할 수 있고, 현재 대기 중인 실행 수를 신경 쓰지 않으셔도 돼요.