▲

Jepsen: TigerBeetle 0.16.11

 (jepsen.io)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • TigerBeetle는 이중 입출금 회계 처리에 특화된 OLTP 데이터베이스로, 안전성과 빠른 처리 속도를 목표로 개발됨
  • Viewstamped Replication 합의 프로토콜과 strong serializability 기준을 지원하며, 고경합, 고처리량 작업에 최적화된 구조를 가짐
  • 결함 허용 및 장애 복원력에 매우 신경 쓴 설계와 테스트 절차를 갖추고, 다양한 장애 상황에서 데이터 손실 없는 동작을 지향함
  • 업그레이드, 테스트, 연산 모델, 클러스터 장애 복원력 등에서 다양한 버그와 성능 이슈가 Jepsen 테스트로 발견, 대응 가능성 개선됨
  • 최신 버전에서는 Ring 기반 복제 성능, 클라이언트 오류 처리, 로깅·쿼리 정확성 등 여러 개선점과 버그 픽스가 제공됨

TigerBeetle 소개

  • TigerBeetle은 이중 입출금(Double-entry bookkeeping) 에 특화된 온라인 트랜잭션 처리(OLTP) 데이터베이스임
  • Viewstamped Replication(VR) 합의 프로토콜 기반의 strong serializability를 보장하며, 계좌와 계좌간 전송(transfer) 데이터만 저장
  • 은행 내부 스위치, 중개업, 티켓 발권, 전력 계량 등 거래량이 많고 동시성 경쟁이 심한 환경에 적합함
  • 단일 노드(Core)에서 모든 쓰기 연산을 관장하는 구조로 수평 확장(Scale-out)이 아니라 수직 확장(Scale-up)에 집중
  • 배치 처리, IO 병렬화, 고정 스키마 등 하드웨어 친화적 최적화로 단일 노드 처리량 극대화를 지향함

장애 복원력 및 결함 허용

  • TigerBeetle은 메모리, 프로세스, 시계, 저장소, 네트워크 결함에 대해 명시적 모델 및 복구 절차 제공
  • 데이터 내구성은 단 하나의 복제본만 살아 있어도 데이터 손실이 없음을 보장
    • 모든 복제본에서 기록이 손상되면 안전하게 멈추는 형태
  • 시스템 하드웨어/소프트웨어 장애, 시계 오차, 디스크 손상, 네트워크 지연·손실·중복 등 다양한 장애를 가정
  • Viewstamped Replication과 Protocol-Aware Recovery 기법, 데이터 블록 체크섬 및 다중 복제본 저장 적용
  • 런타임 검증(assertion) 활용해 오류 및 버그 발생 시 피해를 최소화함

업그레이드 방식

  • 바이너리에는 현재 버전과 여러 이전 버전의 코드가 포함되어 있음
  • 업그레이드는 단순히 바이너리를 교체하는 것만으로 가능
  • 클러스터 내 모든 노드가 자동 롤링 방식으로 버전 변경, 사용자 개입 최소화
  • 특정 버전에서 커밋된 연산이 다른 버전에서 중복 커밋되는 것을 방지하여 상태 불일치 방지에 유리함

시간 모델

  • VR 뷰와 연산 번호를 이용한 논리 시계와, 하이브리드 물리 시계(physical time) 동시 사용
  • 리더가 모든 복제본의 POSIX 시각 수집, 오차 범위 내에서 클러스터 상호 동기화
  • 시계 동기화가 60초 이상 실패하면 서비스 거부
  • 타임스탬프는 "유닉스 에폭 이후 나노초" 단위지만 실제 POSIX 시간과 27초 오차 발생
  • 윤초나 음의 시간 조정 시 내부 시계가 느려지는 현상 있음

데이터 모델

  • 계정(account) 과 이체(transfer) 라는 두 가지 데이터 타입만 지원
    • 각 필드는 고정 크기, 불변성(immutable) 원칙, unsigned int 기반 설계
  • 계정은 사용자 정의 128비트 id, 원장(ledger), 플래그, 생성 시각, 커스텀 필드로 정의
  • 이체는 debit/credit account id, code, amount, 커스텀 필드 등 포함
  • 이체는 즉시 수행(단일 단계) 또는 2단계(예약·실행 협상) 처리 모두 지원
    • 예약 전송(pending) 취소/만료 가능
    • 특수 이체로 계좌 폐쇄/재개 처리 가능

연산 모델 및 트랜잭션

  • 클라이언트가 데이터 상태 갱신 또는 조회를 위한 단일 요청(batch) 단위로 동작
  • 요청 내 각 이벤트는 순차적이고 원자적(atomic) 트랜잭션으로 처리
  • 반복 실행, 다중 요청 트랜잭션, 대화형 쿼리 등은 지원하지 않음
  • 강한 일관성(Strong Serializability) 및 강한 세션 일관성 제공
  • 각 연산의 성공·실패, 오류코드 반환, 체인(Chain, 서브트랜잭션) 기능을 통한 복합 처리 지원

Jepsen 테스트 설계

  • Jepsen 라이브러리 통한 속성 기반(property-based) 테스트와 장애 주입(fault injection) 수행
  • LXC, EC2 등 다양한 환경에서 3~6노드 클러스터 대상으로 실험
  • 데이터 모델 제약으로 기존 리스트·셋 형태 일관성 검증 어려움 → 전체 연산 순서(total order) 이용해 상태/시간 일관성 검증
  • 타임스탬프 기반 일관성 체크, 모델 검증, 시뮬레이션 등 서로 보완적 방식으로 오류 감지

모델 검증과 연산 생성

  • 1600+ 라인 규모의 단일 스레드 상태 기계 모델로 TigerBeetle 동작 정확성 세밀하게 확인
  • 다양한 오류 조건(중복 id, 불연속 타임스탬프, 잔고 제약 등)와 링크드 체인에 대한 추론 및 롤백 처리
  • 검증 효율성을 위해 operation·id 생성, 상태 업데이트, 확률 기반 쿼리 조합 등 다양한 방식 활용

장애 주입

  • 프로세스 크래시(SIGKILL), 일시정지(SIGSTOP), 네트워크 파티션, 클럭 변경 등 기본 장애 시나리오 포함
  • 버전 업그레이드, 파일 손상 시뮬레이션, 일부 복제본만 부분 손상 등 세밀한 저장소 장애 주입
  • 지그재그(helical) 디스크 손상 등 다양한 시나리오로 데이터 손실 가능성 최소화 검증

주요 버그 사례 및 개선 내역

요청 타임아웃 처리의 문제점 (#206)

  • TigerBeetle 설계상 클라이언트 요청이 절대로 타임아웃되지 않음; 클러스터로부터 응답받을 때까지 무한 재시도
  • 실제로는 Java 등 클라이언트가 비동기 연산시 타임아웃 예외를 발생할 수 있으며, 애플리케이션에서 외부 타임아웃을 둘 수밖에 없음
  • 네트워크 오류나 확실한 오류를 애매하게 숨기는 설계로 인해 명확한 실패와 불확실 오류 구분이 어려움
  • Jepsen은 실패 유형(확실/불확실)별 반환 방식 및 재시도 옵션 추가를 권고

클라이언트 오류로 인한 JVM 크래시 (#2435)

  • 타임아웃을 우회하기 위한 스레드/비동기 래핑이 JVM segfault 문제를 유발
  • Java 클라이언트에서 적절히 초기화되지 않은 필드가 참조되어 발생, 0.16.12에서 픽스

세션 만료시 클라이언트 크래시 (#2484)

  • 과도한 세션으로 인한 클라이언트 강제 종료 현상
  • 0.16.13부터 오류 반환식으로 개선

단일 노드 장애시 대기 시간 급등 (#2739)

  • 링 기반 복제 방식의 약점으로 일부 노드 실패시 전체 응답 시간이 극심하게 늘어남
  • 원인: 기본적으로 프라이머리가 다음 노드로 한 단계씩 메세지를 보내는데, 일부 노드 실패시 ack 미수신으로 대기 발생
  • 0.16.30 이후, 역방향 복제 및 동적 링 토폴로지 등 도입해 장애 시 응답 지연 대폭 개선

Java 클라이언트 Header API 버그 (#2495)

  • 빈 응답 배치에 singleton 객체 사용하여 헤더·타임스탬프가 잘못 공유되는 문제 발생
  • 데이터 정확성에는 영향 없으나 헤더 API 결과가 오염됨, 0.16.14에서 수정

쿼리 결과 누락 (#2544)

  • 0.16.13 버전 query_accounts, query_transfers 등 결과 일부 누락되는 버그 보고, 응답 결과가 올바른 prefix로만 제한됨

결론

  • TigerBeetle은 금융·회계 분야에서 높은 안전성과 결함 허용성을 요구하는 환경에 특화됨
  • Jepsen 시리즈 테스트로 다양한 복원력, 일관성, 연산 모델, 성능 이슈가 드러남
  • 적극적 협업을 통해 장애 복원력, 클라이언트 오류 처리, 복제 및 업그레이드 자동화 등 실질적인 개선 이뤄짐
  • 최신 버전에서 더욱 견고한 장애 대응, 연결·응답 보장, 연산 일관성 등 높은 수준의 신뢰성 제공

(이 내용의 일부는 Github, 공식 TigerBeetle 문서, Jepsen 테스트 리포트 등 다양한 오픈 소스를 참고하여 작성됨)

▲
GN⁺ 1일전  [-]
Hacker News 의견

  • Fuzzer Blind Spots (Meet Jepsen!) 글도 참고 정보, https://tigerbeetle.com/blog/… 안내

  • TigerBeetle의 신뢰성과 확장성에 관한 이야기를 항상 Jepsen 보고서로 최종 확인한 경험 공유, 이번 보고서에서 여러 이슈 발견 내용이나 이를 빠르게 수정하고 앞으로 유사 버그가 반복되지 않도록 내부 테스트 스위트도 강화한 엔지니어링 접근 좋아 보인다는 평가, 이런 자세라면 10년 후 금융 특화 데이터베이스 분야에서 ‘그냥 Postgres 써라’급의 기본값 위치 도달 기대, aphyr의 훌륭한 작업으로 많은 공부 인증

    • TigerBeetle에 6,000개 이상의 assertion 구성, 일부가 지나치게 엄격해서 일부 crash 유발했지만 해당 assertion이 정확히 의도대로 경고 역할 수행 경험, 실제로는 Java 클라이언트 쪽 Jepsen 감사 편의를 위한 내부 테스트 기능에서만 작은 correctness bug 발생 사례와, durability에 지장 없는 한 가지 correctness bug Jepsen에서 발견, 관련 사례는 해당 링크에서 상세 내용 설명, TigerBeetle은 Postgres보다 많은 장애를 견디도록 설계 및 테스트 수행 중이고, 명시적 스토리지 장애 모델 채택, Postgres 출시 당시 존재하지 않았던 연구 성과 반영, Deterministic Simulation Testing과 NASA 안전 코드 기준 적용 등 다양한 안정성 보장, 실제로 문헌상 데이터 손실이 명확한 Postgres 시나리오에 대해 TigerBeetle은 탐지 및 복구 가능, 좀 더 자세한 내용은 Kyle의 helical fault injection 섹션 혹은 QCon London 강연 영상 참고 권유
    • Kyle의 보고서를 읽을 때마다 분산 시스템 실력 한 단계 성장 느낌 공유

  • TigerBeetle가 aphyr에 의해 검증되어 약속을 지키는 모습에 기쁨 표출, 올바른 접근이 제대로 된 결과로 이어질 수 있다는 희망 사항, 실제 현장에서는 Account나 Transfer 외의 데이터는 외부 시스템 및 별도의 데이터베이스에 남는 경우가 많은데, 이러한 신뢰도 낮은 외부 시스템과 TigerBeetle 간 consistency 문제나 복구가 실제로 어떻게 이루어지는지 질문

    • TigerBeetle의 조란, 통합 패턴 설명, 일반적으로 control plane(일반 OLGP, 예: Postgres)과 data plane(OLTP, 예: TigerBeetle)으로 분리 아키텍처 권장, 사용자 정보 등은 OLGP라는 ‘서류함’에, 트랜잭션 데이터(재고→장바구니→결제 등)는 OLTP라는 ‘금고’에 저장 형태로 역할 분담, 계정 또는 이체별로 최대 3개 사용자 데이터 식별자 연결 후 OLGP 엔티티와 이벤트 연계 가능, 이 분리는 독립적 규모 확장·운영·관리 이점 제공, 예를 들어 은행처럼 현금(금고)과 정보(서류함)를 구분해야 적합한 사례 설득, 실제 트랜잭션 빈도와 정보 변경 빈도(이름/이메일 등)는 다르기 때문에 이 구조 합리적 설명, 데이터 일관성을 위해서는 write 경로에서는 OLGP(및 S3 등 필요한 외부 저장소)에 의존 관계 데이터 기록 후 마지막에 TigerBeetle로 커밋하는 방식 권장, read 경로에서는 항상 TigerBeetle을 source of record로 조회, strict serializability 유지로 신뢰 확보 방식 제안, 아키텍처 문서 첨부 안내

  • Jepsen의 fuzzer blind spot 포스트를 읽었다면 이번 TigerBeetle 보고서가 훨씬 더 흥미롭다고 느낀다는 의견, JNI 쪽 segfault 사례는 Rust 등 메모리 세이프 언어 사용 시 보호되지 않을 수도 있지만, TigerBeetle의 Zig/TigerStyle 접근이 메모리 안전성에서는 좋은 증명 제공 평가

    • Rust로도 방어할 수 있는 버그 하나 경험 사례, 실제로는 assertion으로 대부분 방지, TigerStyle이 아니었으면 더 위험한 상황 발생 가능성 언급

  • "Panic! At the Disk 0" 섹션의 제목 센스에 소소한 골프클랩 감탄

  • Jepsen 인증받은 이번 상세 보고서에 깊은 감명 표현, 아직 v1.0 출시 전임에도 기대감 높은 상태, 창업자들이 스레드에서 인사이트 적극 공유하는 모습에 별도 칭찬

    • Kyle의 섬세함과 리포트의 예술적 세심함에 대해, SD25 Amsterdam에서 새로운 발표 소식도 기대

  • 분산시스템 테스트에서는 실제로 시스템 내부에서 발생 순서/시간을 시스템이 직접 리포팅하여 외부 모델과 정확히 대조하는 것이 정확한 검증을 위한 필수 요건임이 흥미롭고 ‘뚜렷하게 당연’하게 느껴진다는 소감

    • strict serializability 환경에서는 이런 방식이 가능한데, 약한 일관성 보장 하에서는 단일 글로벌 타임라인이 불가능 예시 안내, 어려운 문제를 도입했기에 시스템이 오히려 단순해지는 메타 패턴 흥미, 예를 들어 디스크 장애/복구 프로토콜을 기본으로 추가하면 느린 replica의 state sync도 ‘공짜’로 얻을 수 있는 상황 등 설명

  • Jepsen 보고서, 관련 블로그, Antithesis 연동 코드 등을 검토한 후 테스트 범위와 효과에 대한 학습 취지 질문, TigerBeetle에서는 이미 Antithesis로도 포괄적 테스트를 진행한다고 알고 있었는데, Jepsen이 발견한 버그가 Antithesis에서는 어떻게 못 잡았는지 궁금, Antithesis와 Jepsen 테스트의 차이, 그리고 내부 테스트 범위가 궁극적으로 어떻게 다른지 구체적으로 질문

    • aphyr의 보충 설명으로, 분산 시스템의 generative testing을 위해서는 1) 시스템 실행 환경 2) 로드 제너레이터 3) 오디터 3가지 요소 필요 설명, Antithesis는 주로 1번으로, 결정론적 시뮬레이션 환경 제공 기능 담당, Jepsen은 실제 머신·OS 레벨 장애 삽입, TigerBeetle의 VOPR은 한 스레드 내에서 전체 클러스터 운용, 각 시뮬레이션 방식은 서로 장단점 보완 설명, 이번 버그 사례는 결국 2), 3)인 workload 발생·검증자 오디터가 핵심, aphyr의 TigerBeetle 전용 Clojure 코드가 해당 버그 야기 및 탐지, 이 후 자체 동등 코드도 패치, 디비 자체보다 VOPR에서 더 핵심적인 문제였다는 사실, 분산 디비는 항상 버그 가능성 존재, 근본적으로 여러 생성기·테스트 전략 설계 중요
    • TigerBeetle의 블로그에도 이 이슈 상세 안내, 요약하자면 Antithesis에서 사용된 테스트가 이번 버그에 필요한 교차 쿼리와 out-of-order 값 조건을 다루지 않아 해당 버그를 놓쳤고, Jepsen 쪽은 그 조합을 맞춰 탐지에 성공, Jepsen의 test generator에도 어느 정도 한계는 있다는 점과 다양한 생성기 설계 필요 강조
    • 내부 지연 시뮬레이션 테스트의 90%는 VOPR(자체 시뮬레이터)에서 수행, 1,000개 CPU 코어로 24/7 가동, Antithesis는 추가적인 레이어로 사용, 쿼리 엔진 버그가 왜 빠져나갔는지는 이 포스트 참고 안내

  • TigerBeetle에 관심이 있다고 밝히며, 클라이언트 문서상 C나 Zig 클라이언트가 없는 점 의아함 표현, 직접 Zig로 작성된 만큼 이 클라이언트가 존재하지 않거나 개발 중인지 질문

  • TigerBeetle을 이미 대형 은행이나 증권사에서 사용하는지 궁금

    • TigerBeetle의 조란, 현재 Gates Foundation과의 협력으로 루안다의 국가 디지털 결제 시스템 2.0 전자중앙은행 구축에 활용 예정, 엔터프라이즈 차원에선 월 1억+ 트랜잭션 처리 고객 실서비스 이미 운영 중, 최근 유럽 20억 달러 규모 핀테크 유니콘과 계약, 미국에서는 추가 계약이 진행 중, 전 세계적으로 실시간 트랜잭션 처리 수요로 TigerBeetle 도입 니즈 증가, 실제 월스트리트의 중대형 브로커리지 Clear Street 창립자들이 투자에 참여, 관련 링크는 mojaloop.io, TigerBeetle의 블로그, 회사 소개 안내
    • 대형 은행이나 거래소는 아니지만, 본인이 대형 핀테크에서 새로운 상품에 이미 사용 중
    • 홈페이지에 자랑하지 않는다는 이유로 빅 네임 레퍼런스가 없을 것으로 추정, 현재로선 영향력 있는 유튜버의 추천 정도가 가장 큰 endorsement로 보인다는 의견
답변달기