오래된 Workflow를 조회할 수 있으면 장애가 나도 복구할 수 있을까? 종료 이력을 보관하는 일과 진행 중인 실행을 다시 이어 가는 일은 보존 대상이 다르다. Temporal의 retention, Archival, DB 백업, Multi-Cluster Replication을 모두 “데이터를 남기는 기능”으로 묶으면 필요한 복구가 빠질 수 있다. 이번 초안은 각 수단이 어떤 질문에 답하는지 구분한다.
예제는 허용량 예약, 가상 문서 변환, 결과 저장, 예약 확정이다. 정상 완료한 문서의 처리 근거를 오래 보고 싶은 요구와, 변환 중 장애가 난 실행을 다른 환경에서 이어 가고 싶은 요구를 나눠 생각한다. 이 글은 다중 클러스터를 구축하거나 복구를 성공시킨 보고가 아니라 선택 기준과 후속 시험 제안이다.
retention은 종료 기록을 얼마나 남길지 정한다
Namespace의 retention은 종료된 Workflow 실행 이력을 얼마 동안 유지할지와 관련된다. 업무가 며칠씩 기다리는 것과 종료 후 며칠 동안 이력을 조회하는 것은 다른 시간이다. 장기 실행을 다룬다고 retention만 길게 설정하면 모든 문제가 해결되는 것이 아니다.
종료된 문서 처리를 조사할 때 History는 어떤 단계가 수행됐는지 확인하는 근거가 된다. 하지만 원본 문서나 변환 결과를 자동으로 같은 기간 보존하는 것은 아니다. History에 결과 ID만 있다면 그 ID가 가리키는 외부 데이터의 보존 정책도 따로 필요하다.
반대로 외부 결과를 오래 보관한다고 Temporal 이력도 남는 것은 아니다. 요구사항에는 “무엇을, 누가, 어떤 목적으로, 언제까지 조회해야 하는가”를 적는다. 실제 문서 내용이 필요한지, 실행 상태와 오류 근거만 필요한지에 따라 비용과 접근 통제 범위도 달라진다.
Archival은 종료 데이터를 장기 보관한다
Archival은 종료한 실행의 History와 Visibility 기록을 별도 저장소에 보존하는 기능이다. 기본 persistence에 모든 종료 데이터를 계속 두지 않고도 장기 조회를 검토할 수 있다. 그러나 진행 중인 실행의 전체 상태를 복원하는 DB 백업과 동일하게 취급할 수는 없다.
공식 Archival 문서에는 실험적 기능이라는 표기가 있으며 배포 방식에 관한 주의도 있다. 컨테이너 관련 설명과 설정 예제는 문서마다 적용 범위가 분명하지 않은 부분이 있으므로, 이 글에서는 “어떤 Docker 환경에서도 그대로 지원된다” 같은 설치 주장을 하지 않는다. 선택한 Server 태그, provider, 배포 방법에서 지원 범위와 조회 동작을 별도로 확인해야 한다.
장기 보관을 쓴다면 보관 성공 자체도 관측해야 한다. Workflow가 종료됐다는 사실만으로 별도 저장소에 즉시 사본이 생겼다고 가정하지 않는다. 실제 보관과 조회가 가능한 시점, 실패 시 재처리, 접근 권한을 시험해야 한다. 기본 저장소에서 데이터가 정리된 뒤에도 필요한 이력을 읽을 수 있는지가 검증 대상이다.
백업은 복원할 시점과 범위를 가진다
DB 백업은 특정 시점의 데이터를 복원하는 수단이다. 앞선 글처럼 실행 중인 상태를 별도 환경에 복원하고 Worker를 연결해 진행할 수 있는지 확인해야 한다. 필요한 schema와 코드, 인증 정보, 외부 업무 상태도 함께 검토한다.
백업 이후 발생한 이벤트는 백업만으로 복원되지 않을 수 있다. 또한 Temporal DB와 예약 원장, 결과 저장소의 복원 시점이 다르면 외부 효과가 앞서 있거나 뒤처질 수 있다. 그래서 백업 주기만으로 데이터 손실 범위를 판단하지 말고 복원 기준 시점과 외부 데이터 대조 방법까지 적어야 한다.
백업이 있다는 이유로 실행 중 코드의 멱등성을 생략할 수 없다. 과거 상태에서 다시 시작하는 과정은 외부 시스템에 이미 수행한 요청을 다시 보낼 가능성을 만든다. 동일한 업무 키를 사용하는 예약·저장·확정 API는 복구 절차에서도 중요한 보호 장치다.
비동기 복제도 같은 약속은 아니다
Multi-Cluster Replication은 다른 Cluster로 실행 정보를 복제하고 failover를 지원하는 방식이다. 공식 문서는 비동기 복제를 사용하므로 전환 시 복제 지연에 따른 진행 손실이나 Activity 재실행이 가능하다고 설명한다. 따라서 두 Cluster가 있다는 사실만으로 모든 장애에서 손실이 없다고 말할 수 없다.
예를 들어 기존 Cluster에서는 결과 저장이 성공했지만 관련 이벤트가 다른 Cluster에 아직 도착하지 않았다고 가정하자. 새 Cluster로 전환한 실행은 저장을 다시 요청할 수 있다. 이때 저장소가 같은 업무 키의 결과를 재사용하지 못하면 중복 효과가 생길 수 있다.
이것이 이 글의 대표 실패다. 클러스터 복제가 “외부 업무도 정확히 한 번”을 보장한다고 오해하는 것이다. 실제 후속 실험에서는 복제 지연을 제한된 시험 환경에서 만들고, 전환 전후 이벤트와 외부 결과를 대조해야 한다. 이 글에는 아직 그 실측 결과가 없다.
요구별로 증거를 나눈다
| 요구 | 먼저 검토할 수단 | 확인할 증거 |
|---|---|---|
| 최근 종료 실행 조사 | retention | 기간 안의 History 조회 |
| 종료 이력 장기 조회 | Archival 등 보관 설계 | 기본 저장소 정리 후 조회 |
| DB 손실 뒤 특정 시점 복구 | DB 백업과 복원 | 진행 중 실행 재개와 외부 대조 |
| Cluster 장애 시 전환 | 복제와 failover | 지연, 손실 범위, 중복 효과 |
표의 항목들은 서로 대체재 하나를 고르는 문제가 아니다. 같은 서비스에서 여러 요구가 동시에 존재할 수 있다. 다만 기능을 추가할 때마다 저장 비용, 권한, 장애 감지, 복구 책임도 늘어난다. 작은 학습 환경에서는 먼저 백업 복원을 확인하고 다중 클러스터는 별도 심화로 두는 편이 결과를 설명하기 쉽다.
검증 계획에는 성공 조건뿐 아니라 남는 한계도 적는다. 종료 이력을 읽었다면 진행 중 실행의 복구는 아직 미검증이다. 한 번 failover했다면 장기간의 복제 지연과 네트워크 분할은 아직 미검증일 수 있다. 확인한 범위를 정확히 적는 것이 기능 이름을 많이 나열하는 것보다 유용하다.
검증 질문은 “종료 History가 모두 보관돼 있으면 진행 중이던 예약을 그대로 이어 갈 수 있을까?”다. 또 “비동기 복제에서 외부 저장 요청의 멱등성이 여전히 필요한 이유는 무엇일까?”를 생각해 보자. 복구 수단의 이름보다 복구할 상태와 남는 손실을 설명할 수 있어야 한다.