Temporal
한 편씩 읽고 보완하는 초안입니다. 검토와 고도화를 마친 글부터 정식으로 발행합니다.
초안MSA에서 무엇을 함께 성공시켜야 할까
초안
분산된 문서 처리에서 API 성공과 업무 성공을 구별하고, 실패 뒤 남아도 되는 상태를 먼저 정의한다.
서비스 경계를 바꾸면 트랜잭션이 단순해질까
초안
서비스별 데이터 소유권과 로컬 트랜잭션 범위를 구별하고, 경계 조정으로 부분 성공 문제를 줄일 수 있는지 검토한다.
2PC와 Saga는 무엇을 약속하는가
초안
2PC의 commit 조정과 Saga의 재시도·보상이 제공하는 보장을 구별하고, 예제의 참여 범위와 중간 상태를 검토한다.
이벤트로 다음 작업을 시작해 본다
초안
예약·변환·저장을 이벤트로 연결하고, 코레오그래피에서 다음 단계와 실패 처리 책임이 어디에 있는지 살펴본다.
한곳에서 다음 단계를 정해 본다
초안
같은 참여자들을 중앙 조정 코드로 연결해 책임을 비교하고, 논리적 중앙 제어와 물리적 단일 프로세스를 구별한다.
Saga 중간 상태를 다른 요청이 읽으면
초안
동시 예약과 중간 상태 노출을 통해 Saga의 격리 한계를 확인하고, 원장과 조회 계약의 책임을 분리한다.
DB에는 있는데 다음 작업이 시작되지 않는다
초안
DB 커밋과 다음 요청 사이의 유실을 재현하고, outbox가 남기는 전송 의도와 중복 처리 책임을 구별한다.
오케스트레이터가 꺼지면 누가 이어 갈까
초안
프로세스 중단 뒤 조정자가 이어 가려면 필요한 상태를 살펴보고, Temporal의 실행 이력과 메모리 저장을 구별한다.
Temporal을 선택하기 전에 적을 판단 기준
초안
중앙 조정 요구와 Temporal 도입을 별도 결정으로 검토하고, 동일 실패 실험으로 초기 판단을 재평가할 기준을 만든다.
Client·Service·Worker는 어디서 실행되는가
초안
문서 처리 요청을 Temporal에 보냈다고 해서 Temporal Service가 문서를 변환하는 것은 아니다.
첫 Java Workflow를 실행한다
초안
첫 실습의 목적은 실제 문서 변환 기능을 만드는 것이 아니다.
Worker를 재시작하면 왜 이어지는가
초안
Worker가 종료되면 그 프로세스의 메모리도 사라진다.
재생되는 코드에서 HTTP를 호출하면 안 되는 이유
초안
문서를 변환하기 전에 허용량을 확인해야 한다고 해 보자.
Activity의 어느 시간을 제한할까
초안
문서 변환이 오래 걸릴 때 “타임아웃을 1분으로 설정한다”는 말만으로는 충분하지 않다.
Heartbeat가 와도 작업이 멈춰 있을 수 있다
초안
오래 걸리는 문서 변환 Activity가 주기적으로 Heartbeat를 보낸다고 하자.
저장 성공 뒤 재시도돼도 한 번만 반영하려면
초안
문서 변환 결과를 DB에 저장하는 Activity가 있다고 하자.
Cancel과 Terminate는 정리 결과가 다르다
초안
사용자가 문서 처리를 취소했다.
Signal·Query·Update 중 무엇을 선택할까
초안
문서 변환 전에 사용자의 승인을 기다리는 Workflow를 만든다고 하자.
메시지 handler가 끝나기 전에 종료하면
초안
승인 Update를 받은 Workflow가 허용량 예약 Activity를 기다리고 있다고 하자.
Workflow와 Activity Worker를 분리한다
초안
처음 만든 Java 예제에서는 하나의 Worker 프로세스가 Workflow와 Activity를 모두 실행했다.
Spring 자동 설정 뒤에도 확인할 것은
초안
Java 기본 예제로 Worker와 Client의 역할을 이해했다면 Spring Boot 통합을 붙일 수 있다.
보상을 등록했는데 예약이 남는 이유
초안
문서 처리에서 허용량을 예약한 뒤 변환이 실패하면 예약을 해제하기로 했다고 하자.
DB 저장과 Workflow 시작을 연결한다
초안
문서 처리 API가 요청을 DB에 저장한 다음 Temporal Workflow를 시작한다고 하자.
Continue-As-New로 무엇을 넘겨야 할까
초안
문서 처리 요청을 계속 받아 같은 Workflow에서 반복 처리하면 이력이 커질 수 있다.
Child Workflow는 함수 분리와 무엇이 다른가
초안
문서 처리 코드가 길어지면 메서드로 나누고 싶어진다.
정기 실행이 겹치면 어떻게 할까
초안
매분 변환 대기 문서를 찾아 처리하는 Workflow를 시작한다고 하자.
본문 대신 ID만 넘기면 충분할까
초안
문서 본문을 Workflow 입력과 Activity 결과에 계속 넣으면 실행 이력에도 큰 데이터가 남을 수 있다.
암호화하면 History의 무엇이 가려질까
초안
문서 본문이 Activity 입력과 결과에 들어간다면 실행 이력에서 어떤 데이터가 보이는지 확인해야 한다.
Service의 History와 Matching은 무엇을 맡는가
초안
History·Matching·SDK Worker의 책임과 History Shard를 실행 흐름으로 구분한다.
PostgreSQL에 실행 상태를 남긴다
초안
PostgreSQL 기반 영속 환경을 준비하고 재시작 전후 실행과 업무 데이터를 대조한다.
Namespace와 TLS만으로 접근을 막을 수 있을까
초안
Namespace, TLS, 인증, 인가가 답하는 질문을 나누고 허용·거절을 시험한다.
Kubernetes 배포에서 schema Job이 실패하면
초안
schema Job 실패를 Server 배포 전에 발견하고 데이터 준비와 Pod 상태를 구분한다.
정상 health인데 왜 처리가 멈춰 있을까
초안
Service health가 정상이어도 멈출 수 있는 실행을 SDK·Service·업무 지표로 진단한다.
Worker를 늘리면 얼마나 빨라질까
초안
Worker replica와 slot을 하나씩 바꾸며 유효 처리량과 외부 시스템의 제한을 관찰한다.
병목이 Service나 DB라면 무엇이 달라질까
초안
Worker 여유와 별개로 발생하는 Service·persistence·Visibility 병목을 나누어 본다.
코드 변경이 기존 History와 맞는지 검사한다
초안
기존 History를 새 코드로 재생하고 getVersion 분기로 호환성을 검증한다.
실행 중인 v1과 새 v2 Worker를 함께 둔다
초안
새 유입과 기존 Pinned 실행을 나누고 구버전 Worker를 너무 일찍 종료하는 실패를 다룬다.
Server 업그레이드에서 스키마가 먼저인 이유
초안
Server·SDK·chart의 독립 버전을 기록하고 schema 선행 업그레이드와 복구 조건을 검토한다.
백업을 별도 환경에 복원해 본다
초안
백업을 분리된 환경에 복원하고 실행 재개와 외부 예약·결과의 정합성을 확인한다.
종료 이력 보존과 재해 복구는 다르다
초안
retention·Archival·백업·비동기 복제가 보존하는 대상과 복구 한계를 구분한다.
같은 실패로 Temporal 선택을 다시 검토한다
초안
동일한 응답 유실 실패로 세 조정 구현을 비교할 가설과 미실험 판정표를 제시한다.
직접 운영할지 Cloud를 쓸지 다시 결정한다
초안
자체 운영과 Cloud의 책임·비용 항목을 비교하고 Worker와 업무 정확성의 책임을 확인한다.