TL;DR

  • 장시간 실행되는 에이전트와 동적 프로그램에서 실행 이력 재생 대신 프로그램 연속성(continuation)을 체크포인트로 저장하는 투명 연속성 체크포인팅(TCC)이 복구 경로를 단순화하는 대안임.
  • TCC는 컴파일러와 런타임이 내구성 경계에서 현재 실행에 필요한 제어 상태를 저장하고, 장애 후 이를 직접 복원해 재개하는 방식임.
  • 약 4KB의 라이브 상태를 유지한 통제 평가에서 TCC 복구 시간은 약 0.6~0.9밀리초로 유지된 반면, 평가한 Temporal 기반 이력 재생은 경계 깊이 10~1,000에서 약 61밀리초~1.7초로 증가함.
  • TCC는 복구 시간을 항상 상수 시간으로 만들지 않으며, 복구 비용이 보존된 전체 실행 이력보다 프로그램이 여전히 필요로 하는 라이브 상태에 주로 좌우되도록 하는 접근임.
  • 프로덕션 인프라화를 위해 이식 가능한 연속성 표현, 프로그램·체크포인트 버전 관리, 대규모 라이브 상태 처리, 내구성 저장소와 커밋 프로토콜 등의 과제가 남아 있으며, Trigora는 이를 장시간 실행되는 인공지능 에이전트에 우선 적용하는 프로젝트임.

실행 이력 재생 없는 내구성 있는 실행

  • 대부분의 내구성 있는 실행 시스템은 보존된 실행 이력을 재생하는 방식으로 복구함.
  • 워커(worker)가 실패하면 새 워커가 이력을 불러오고 프로그램을 현재 위치가 재구성될 때까지 재실행함.
  • 이 모델은 워커를 일시적인 구성 요소로 유지하면서 내구성 있는 진행 상태를 제공하는 유용한 방식임.
  • 반면 누적된 이력이 복구 경로의 일부가 되는 트레이드오프가 발생함.
  • 수 시간 또는 수일 동안 실행되고, 많은 도구를 호출하며, 외부 이벤트를 기다리고, 자식 실행을 생성하고, 동적으로 방향을 바꾸는 프로그램에서는 이 트레이드오프가 더 두드러짐.
  • 장시간 실행되는 에이전트가 점점 이런 구조를 갖는 상황에서, 실행 이력으로 프로그램을 재구성하는 대신 프로그램 연속성을 체크포인트로 저장하는 다른 복구 프리미티브를 구축하고 평가함.

투명 연속성 체크포인팅

  • 이 접근을 투명 연속성 체크포인팅(Transparent Continuation Checkpointing, TCC)으로 명명함.
  • 내구성 경계에서 컴파일러와 런타임이 현재 위치에서 프로그램을 계속 실행하는 데 필요한 제어 상태인 라이브 연속성(live continuation)을 캡처함.
  • 장애 후 실행이 재개되면 런타임이 커밋된 연속성을 불러와 프로그램을 직접 복원함.
  • 이력 재생은 현재 위치를 재구성하는 방식임.
  • 보존된 이력 로드 → 접두 실행 구간 재실행 → 현재 위치 재구성
  • TCC는 커밋된 연속성을 복원하고 재개하는 방식임.
  • 커밋된 연속성 로드 → 라이브 실행 상태 복원 → 재개
  • 외부 효과는 명시적인 내구성 연산으로 유지됨.
  • 완료된 내구성 작업은 복구 후 반복되지 않음.
  • 지원되지 않는 언어 구성은 모호한 런타임 동작을 만드는 대신 컴파일 단계에서 실패함.
  • 현재 프로토타입은 내구성 효과, 외부 대기와 이벤트, 자식 실행, 취소, 구조적 동시성(structured concurrency), 장애 복구를 지원함.

달라지는 점

  • TCC가 복구를 상수 시간으로 만들지는 않음.
  • 복구 시간은 여전히 라이브 연속성의 크기와 구조에 민감함.
  • 의도된 변화는 복구가 의존하는 대상에 있음.
  • 이력 재생에서는 현재 위치를 재구성하기 위해 보존된 실행 이력이 복구에 영향을 줌.
  • TCC에서는 프로그램에 여전히 필요한 상태가 복구에 주로 영향을 줌.
  • 1만 개의 연산을 수행했더라도 작은 라이브 연속성을 유지하는 프로그램이라면 과거 이력이 길다는 이유만으로 복구가 반드시 어려워지지는 않음.

예비 평가

  • 라이브 연속성 상태를 거의 일정하게 유지하면서 내구성 경계 깊이를 10에서 1,000까지 늘리는 통제 비교를 수행함.
  • 평가 조건은 라이브 상태 약 4KB임.
  • TCC 복구 시간은 약 0.6~0.9밀리초 범위에 머묾.
  • 평가한 Temporal 기준선의 새 워커 이력 재생 복구는 약 61밀리초에서 1.7초로 증가함.
  • 워커 생성 시간은 측정에서 제외됨.
  • 이 결과는 일반적인 프로덕션 속도 향상 주장으로 해석하면 안 됨.
  • 모든 TCC 워크로드가 모든 이력 기반 시스템보다 빠르다는 의미가 아니라, 테스트 조건에서 복구 확장성이 다르게 나타난다는 점을 보여주는 결과임.

방법론과 한계

  • 생성된 사례 50,000개를 대상으로 실행 의미론을 추가 검증함.
  • 평가 대상 하위 집합에서 관찰된 의미론적 실패는 없음.

여전히 어려운 점

  • 프로토타입을 프로덕션 인프라로 전환하려면 다음 작업이 상당 부분 남아 있음.
  • 이식 가능한 연속성 표현
  • 프로그램과 체크포인트 버전 관리
  • 더 큰 라이브 상태의 효율적 처리
  • 내구성 저장소와 커밋 프로토콜
  • 운영 가시성
  • 언어 프런트엔드 간 호환성
  • 프레임워크 통합
  • 장시간 실행 정확성과 장애 테스트
  • 체크포인트 보존, 이전 연속성에서의 분기, 런타임 버전 간 마이그레이션, 실행 표현의 어느 정도를 언어 간에 안정적으로 유지할지에 관한 설계 질문도 남아 있음.
  • 이 모델을 기반으로 Trigora를 구축하고 있으며, 초기 적용 대상은 장시간 실행되는 인공지능 에이전트임.
  • 더 넓은 질문은 연속성 기반 복구가 동적이고 장수하는 소프트웨어를 위한 더 나은 실행 기반을 제공할 수 있는지 여부임.
  • 아키텍처, 의미론, 벤치마크 구성, 현재 한계는 기술 논문에서 더 자세히 설명됨.
  • 워크플로 엔진, 컴파일러, 체크포인팅 시스템, 분산 런타임을 다뤄온 사람들의 비판을 특히 요청함.