Skip to main content
QUICK REVIEW

[논문 리뷰] Accompanist: A Runtime for Resilient Choreographic Programming

Viktor Strate Kløvedal, Dan Plyukhin|arXiv (Cornell University)|2026. 03. 21.
Distributed systems and fault tolerance인용 수 0
한 줄 요약

Accompanist는 사이드카를 배치하여 계산을 재생해 결함을 가려 내고, 분산 사가 거래를 공식적인 정합성 보장을 갖춘 형태로 가능하게 하는 강인한 런타임을 제공한다.

ABSTRACT

In service-oriented architecture, services coordinate in one of two ways: directly, using point-to-point communication, or indirectly, through an intermediary called the orchestrator. Orchestrators tend to be more popular because their local state is a 'single source of truth' for the status of ongoing workflows, which simplifies fault recovery and rollback for distributed transactions that use the 'saga' pattern. But orchestration is not always an option because of hardware constraints and security policies. Without a central orchestrator, resilient saga transactions are hard to implement correctly. A natural idea is to use choreographic programming, a paradigm that brings the 'global view' of orchestrators to a decentralised setting. Unfortunately, choreographic programming relies on strong assumptions about network reliability and service uptime that often do not hold. Recent work weakens some of these assumptions with 'failure-aware' language features, but these features make programs more complex. We propose a complementary approach: to co-design the programming interface with a customizable runtime that can replay computation to mask faults. Our approach keeps programs simple, does not require modifying the compiler, and lends itself to a clean separation of concerns in formal proofs. We present Accompanist, a resilient runtime for the Choral choreographic programming language. With Accompanist, programmers can implement decentralised saga transactions as choreographic programs and deploy the compiled code to 'sidecars' that run alongside services in a pre-existing codebase. Our key assumptions are that choreographic programs should be deterministic, transactions within a saga should be idempotent, and messages should be written to a durable message queue. Based on these assumptions, we present a formal model and prove that target code is correct-by-construction.

연구 동기 및 목표

  • 서비스 지향 아키텍처에서 오케스트레이션이 대기 시간, 보안 또는 locality 제약으로 실행 불가능한 경우에도 강인한 조정(Coordination)이 필요하다는 동기를 제시한다.
  • Choral 차례 구성에 대한 결함 허용 실행 모델과 함께 프로그래밍 인터페이스를 공동 설계하는 런타임으로 Accompanist를 소개한다.
  • Accompanist로 구현된 차례 구성 사가는 교착 상태 없이 종료되고, 제한된 재시작 하에 종료되며, 보상 거래를 통해 일관성을 유지함을 보인다.
  • 형식적 모델과 정합성 결과를 제공하여 차례 구성에 대한 증명과 네트워크 수준의 비시뮬레이션(bisimulation) 증명을 분리한다.

제안 방법

  • 분산되고 올바르게 구성된 샤로그래픽 차례 거래를 위한 형식적 모델을 제시한다.
  • Choral로 생성된 코드를 실행하고 프로그래밍 가능한 채널을 통해 통신하는 사이드카 기반의 Accompanist 런타임 아키텍처를 설명한다.
  • 세션별 상태와 비정렬 메시지 버퍼링을 갖춘 경량 가상 스레드에 매핑된 세션 기반 실행을 정의한다.
  • 적어도 한 번 전송의 메시징(inbox/outbox 패턴)을 사용하여 장애 허용 재생과 멱등 트랜잭션을 가능하게 하는 내구성 있는 메시징을 구현한다.
  • 세션을 재시작하고 초기 상태에서 재생하는 장애 허용 모드를 도입하며, 결정적이고 멱등한 가정들을 활용한다.
  • 트랜잭션 인터페이스와 보상 작업을 통해 사가 거래가 실패 시 롤백되도록 보장하는 방식으로 사가 거래를 표현하는 방법을 시연한다.
Figure 1 . A workflow with three services, implemented in three different styles.
Figure 1 . A workflow with three services, implemented in three different styles.

실험 결과

연구 질문

  • RQ1차례 구성 프로그래밍을 컴파일러 변경이나 침습적인 언어 확장 없이 실제 시스템에서 어떻게 실용적으로 만들 수 있는가?
  • RQ2런타임 재생 기반 접근 방식이 무결성 특성(예: 교착 상태 방지 및 사가 안전성)을 보존하면서 분산 차례 구성에 대해 회복력을 제공할 수 있는가?
  • RQ3Accompanist의 장애 허용 재생이 기존의 사가 오케스트레이션에 비해 성능에 어떤 영향을 미치는가?
  • RQ4차례 구성을 형식적 구현으로부터 네트워크 수준의 행동과 관련지어 증명할 수 있는가(그리고 비시뮬레이션을 통해 연결될 수 있는가)?
  • RQ5사이드카 기반 차례 구성에서 신뢰성 및 관찰 가능성을 지원하기 위해 필요한 메커니즘(예: 메시지 헤더, 세션 관리)은 무엇인가?

주요 결과

  • 기본 Accompanist 모드는 영역 간의 배포에서 엔드-투-엔드 지연을 개선한다.
  • 장애 허용 모드에서 Accompanist는 성숙한 산업급 사가 오케스트레이션 프레임워크에 비해 엔드-투-엔드 지연의 중간값에서 5.9배의 현저한 개선을 달성한다.
  • 이 접근 방식은 원칙에 입각한 정합성 결과를 제공한다: 교착 상태 방지, 제한된 재시작 하에서의 종료, 참가자 간 성공 또는 보상 작업에 대한 합의.
  • 차례 구성에 대한 형식적 올바른 구현의 formalization이 제공되며, 차례 구성과 컴파일된 차례 구성 간의 비시뮬레이션 결과 및 재시작 하에서의 재생 동등성이 포함된다.
  • 아키텍처는 사이드카가 작업자(RPC)를 통해 통신하도록 함으로써 기존 다언어 코드베이스와의 통합을 지원하고, 어플리케이션 재작성의 필요성을 피한다.]
  • table_headers: []
  • table_rows: []
Figure 2 . A user checkout workflow implemented with orchestration (a) versus Accompanist (b).
Figure 2 . A user checkout workflow implemented with orchestration (a) versus Accompanist (b).

더 나은 연구,지금 바로 시작하세요

연구 설계부터 논문 작성까지, 연구 시간을 획기적으로 줄여보세요.

카드 등록 없음 · 무료 플랜 제공

이 리뷰는 AI가 만들고, 인간 에디터가 검토했습니다.