본문 바로가기
WIKI 기술 지식 베이스

내구성 보장

원문 보기 위키 갱신

내구성 보장 (Durability Guarantees)

데이터가 정말 안전하게 보관되는지 궁금하시죠? Turso Cloud는 요금제별로 데이터 내구성(durability)을 보장하고, 그 뒤에는 S3 기반 아키텍처와 철저한 검증 기법이 있어요.

출처: 문서

본문

다음은 2025년 3월 17일 이후 가입하거나 업그레이드한 사용자에게 Turso Cloud 플랫폼이 제공하는 내구성 보장이에요:

내구성 커밋 지연 시간 추가
Free 99.999999999% 최대 100ms
Developer 99.999999999% 최대 50ms
Scaler 99.999999999% 최대 25ms
Pro 이상 99.999999999% 최대 10ms

모든 Turso AWS 리전에서는 데이터가 S3-Express One Zone과 S3의 조합으로 백업되는 디스크리스(diskless) 아키텍처를 사용해요.

커밋은 데이터가 S3 또는 S3-express에 안전하게 저장된 이후에만 승인(acknowledged)돼요. 컴퓨트 노드는 언제든 생겼다 사라질 수 있고, 로컬 디스크는 로컬 캐시 역할을 해요. 그래서 AWS 최고 수준의 S3 스토리지와 동일한 내구성을 보장할 수 있는 거예요.

Pro 및 Enterprise 고객은 자체 S3 / S3-express 버킷을 사용해 데이터가 자신의 인프라 안에 있음을 보장할 수 있어요. 로드맵에는 컴퓨트도 여러분의 계정 안에서 실행되는 완전한 BYOC 솔루션이 포함되어 있어요.

단기 및 장기 보장

SQLite 호환 데이터베이스는 크게 두 가지 스토리지 구성 요소가 있어요. 가장 최근의 커밋을 담고 있는 Write-Ahead Log(WAL)와, 데이터베이스 파일이에요. 주기적으로 WAL의 데이터가 메인 데이터베이스 파일에 병합(fold)돼요.

Turso Cloud로 보내진 새 커밋은 애플리케이션에 승인되기 전에 S3-express One Zone에 저장돼요. 그리고 주기적으로 데이터가 메인 데이터베이스 파일에 병합되어 S3에 저장돼요. AWS 서비스 약정에 따라 두 기술 모두 99.999999999%의 내구성을 보장해요.

커밋 지연 시간

S3 기반 아키텍처가 분석(analytical) 워크로드만큼 트랜잭션 워크로드에 널리 쓰이지 않는 이유 중 하나는 오브젝트 스토어 쓰기 비용이 높기 때문이에요. Turso Cloud의 멀티 테넌트 아키텍처 덕분에 커밋을 여러 데이터베이스에 걸쳐 일괄 처리(batch)해서 이 비용을 분산해요.

또한 커밋은 시간 단위로도 일괄 처리돼요. 이것이 표 1에 설명된 커밋 지연 시간이에요.

커밋 지연 시간은 모든 커밋에서 기대되는 지연이 아니라, 각 커밋에 추가될 수 있는 지연의 상한(ceiling)이에요.

동작 방식을 이해하기 위해 다음 시나리오를 살펴봐요:

sequenceDiagram
    participant Timeline
    participant DB1 as Database 1
    participant DB2 as Database 2

    Note over Timeline: 0ms - Commit Window Starts

    Timeline->>DB1: Commit c1 arrives
    Note over DB1: Waits 10ms for batch

    Note over Timeline: 4ms

    Timeline->>DB2: Commit c1 arrives
    Note over DB2: Waits 6ms for batch

    Note over Timeline: 10ms - Commit Window Ends

    Timeline->>DB1: Commit c2 arrives
    Note over DB1: No wait (batch is ready)

    Timeline-->>DB1: Acknowledge c1 and c2
    Timeline-->>DB2: Acknowledge c1

하나씩 살펴볼게요:

  • 10ms 커밋 윈도우의 시작 시점에 데이터베이스 d1으로 들어온 첫 커밋(c1)은 10ms 전체를 기다려야 해요
  • 윈도우 시작 4ms 후에 데이터베이스 d2로 들어온 커밋(c1)은 남은 6ms만 기다리면 돼요
  • 커밋 윈도우가 끝나는 정확한 시점에 데이터베이스 d1으로 들어온 두 번째 커밋(c2)은 추가 지연이 전혀 없어요

테스트 방법론

Turso Cloud 서버는 처음부터 Deterministic Simulation Testing(DST)을 사용하도록 작성됐어요. DST는 가능한 여러 무작위 생성 입력에 걸쳐 코드를 자동으로 테스트하고, 실패가 발생하면 모든 사전 조건과 함께 문제를 결정론적으로 재현하는 시드를 생성하는 기법이에요.

시뮬레이터 외에도 Antithesis의 전체 시스템 결정론 시뮬레이션 하이퍼바이저를 사용해 AWS S3, S3-Express One Zone 같은 외부 구성 요소와 시스템의 상호작용을 테스트해요.

바닥부터 만든 DST 서버와 Antithesis의 조합 덕분에 단 몇 시간 만에 수년치 가능한 시나리오 조합을 테스트할 수 있고, 시스템이 명세대로 동작하는지 확인할 수 있어요.

더 알아보기 (Learn more)