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로 보인다는 의견
Hacker News 의견
Fuzzer Blind Spots (Meet Jepsen!) 글도 참고 정보, https://tigerbeetle.com/blog/2025-06-06-fuzzer-blind-spots-meet-jepsen/ 안내
TigerBeetle의 신뢰성과 확장성에 관한 이야기를 항상 Jepsen 보고서로 최종 확인한 경험 공유, 이번 보고서에서 여러 이슈 발견 내용이나 이를 빠르게 수정하고 앞으로 유사 버그가 반복되지 않도록 내부 테스트 스위트도 강화한 엔지니어링 접근 좋아 보인다는 평가, 이런 자세라면 10년 후 금융 특화 데이터베이스 분야에서 ‘그냥 Postgres 써라’급의 기본값 위치 도달 기대, aphyr의 훌륭한 작업으로 많은 공부 인증
TigerBeetle가 aphyr에 의해 검증되어 약속을 지키는 모습에 기쁨 표출, 올바른 접근이 제대로 된 결과로 이어질 수 있다는 희망 사항, 실제 현장에서는 Account나 Transfer 외의 데이터는 외부 시스템 및 별도의 데이터베이스에 남는 경우가 많은데, 이러한 신뢰도 낮은 외부 시스템과 TigerBeetle 간 consistency 문제나 복구가 실제로 어떻게 이루어지는지 질문
Jepsen의 fuzzer blind spot 포스트를 읽었다면 이번 TigerBeetle 보고서가 훨씬 더 흥미롭다고 느낀다는 의견, JNI 쪽 segfault 사례는 Rust 등 메모리 세이프 언어 사용 시 보호되지 않을 수도 있지만, TigerBeetle의 Zig/TigerStyle 접근이 메모리 안전성에서는 좋은 증명 제공 평가
"Panic! At the Disk 0" 섹션의 제목 센스에 소소한 골프클랩 감탄
Jepsen 인증받은 이번 상세 보고서에 깊은 감명 표현, 아직 v1.0 출시 전임에도 기대감 높은 상태, 창업자들이 스레드에서 인사이트 적극 공유하는 모습에 별도 칭찬
분산시스템 테스트에서는 실제로 시스템 내부에서 발생 순서/시간을 시스템이 직접 리포팅하여 외부 모델과 정확히 대조하는 것이 정확한 검증을 위한 필수 요건임이 흥미롭고 ‘뚜렷하게 당연’하게 느껴진다는 소감
Jepsen 보고서, 관련 블로그, Antithesis 연동 코드 등을 검토한 후 테스트 범위와 효과에 대한 학습 취지 질문, TigerBeetle에서는 이미 Antithesis로도 포괄적 테스트를 진행한다고 알고 있었는데, Jepsen이 발견한 버그가 Antithesis에서는 어떻게 못 잡았는지 궁금, Antithesis와 Jepsen 테스트의 차이, 그리고 내부 테스트 범위가 궁극적으로 어떻게 다른지 구체적으로 질문
TigerBeetle에 관심이 있다고 밝히며, 클라이언트 문서상 C나 Zig 클라이언트가 없는 점 의아함 표현, 직접 Zig로 작성된 만큼 이 클라이언트가 존재하지 않거나 개발 중인지 질문
TigerBeetle을 이미 대형 은행이나 증권사에서 사용하는지 궁금