서론

고성능 데이터베이스 아키텍처를 평가할 때, 논의는 흔히 수평적 확장(horizontal scaling), 분산 파티셔닝(distributed partitioning), 그리고 쿼리 최적화(query optimization)에 집중됩니다. 하지만 금융 원장(financial ledgers)과 같이 미션 크리티컬한 트랜잭션 시스템의 경우, 실제 병목 현상은 네트워크나 쿼리 플래너(query planner)에서 발생하는 경우가 드뭅니다. 진짜 병목은 운영체제 커널(operating system kernel), 메모리 파편화(memory fragmentation), 그리고 예측 불가능한 꼬리 지연 시간(tail latency)입니다. Zig 언어로 작성된 특화된 금융 원장 데이터베이스인 TigerBeetle은 극단적인 기계적 공감(mechanical sympathy), 정적 자원 할당(static resource allocation), 그리고 커스텀 제로 카피(zero-copy) 인터페이스를 우선시함으로써 기존의 데이터베이스 설계를 혁신합니다.

저는 수년간 분산 스토리지 엔진(distributed storage engines)을 분석해 왔으며, TigerBeetle의 아키텍처 선택은 현대 성능 엔지니어링(performance engineering)의 마스터클래스로 돋보입니다. 런타임 시 동적 메모리 할당(dynamic memory allocation)을 거부하고, 직접 I/O(direct I/O)를 통해 커널 캐시(kernel cache)를 우회하며, Viewstamped Replication (VSR)에 의해 뒷받침되는 단일 스레드 실행 루프(single-threaded execution loop)를 활용함으로써, TigerBeetle은 예측 가능한 밀리초 미만(sub-millisecond)의 꼬리 지연 시간과 함께 초당 수십만 건 이상의 트랜잭션 처리량을 달성합니다.

이 글에서 저는 TigerBeetle의 핵심 아키텍처 기둥을 해체해 보겠습니다. 정적 할당(static allocation)이 어떻게 런타임 가비지 컬렉션(garbage collection)과 메모리 파편화를 제거하는지, 커스텀 제로 카피(zero-copy) 인터페이스가 어떻게 CPU-메모리 버스 오버헤드를 최소화하는지, 그리고 Zig의 컴파일 타임(compile-time) 기능이 어떻게 원시 하드웨어 성능을 희생하지 않으면서 엄격한 안전 보장(safety guarantees)을 강제하는지 살펴볼 것입니다. 저의 목표는 엔지니어링 리더와 시스템 아키텍트들에게 이러한 저수준(low-level) 설계 패턴에 대한 실행 가능한 통찰력을 제공하여, 여러분의 고처리량(high-throughput) 시스템에도 유사한 성능 엔지니어링 원칙을 적용할 수 있도록 돕는 것입니다.

TigerBeetle의 핵심 아키텍처에 대한 심층적인 기술 분석으로, 정적 메모리 할당 (Static memory allocation), 제로 카피 (Zero-copy) io_uring 인터페이스, 그리고 Zig 기반의 성능 엔지니어링 (Performance engineering)이 어떻게 런타임 오버헤드를 제거하는지 탐구합니다.

정적 할당 (Static Allocation): 런타임 메모리 오버헤드 제거

전통적인 데이터베이스 시스템에서 메모리 관리 (Memory management)는 매우 동적입니다. 쿼리가 도착함에 따라 데이터베이스는 연결 버퍼 (Connection buffers), 쿼리 계획 (Query plans), 임시 정렬 버퍼 (Temporary sort buffers), 그리고 트랜잭션 상태 (Transaction state)를 위한 메모리를 할당합니다. jemalloc 또는 tcmalloc과 같은 현대적인 메모리 할당자 (Memory allocators)는 매우 최적화되어 있지만, 스레드 경합 (Thread contention), 메모리 파편화 (Memory fragmentation), 그리고 피크 부하 (Peak loads) 동안 발생하는 예측 불가능한 지연 시간 급증 (Latency spikes)으로부터 자유롭지는 않습니다. 단 하나의 지연된 트랜잭션이 다운스트림 결제 파이프라인을 중단시킬 수 있는 금융 원장 (Financial ledger) 환경에서, 이러한 지연 시간 급증(흔히 "노이지 네이버 (Noisy neighbor)" 또는 "롱 테일 (Long tail)" 문제라고 불림)은 용납될 수 없습니다.

TigerBeetle은 초기화 단계 (Initialization phase) 이후에 동적 메모리 할당 (malloc, free 또는 그에 상응하는 기능)을 완전히 제거함으로써 이 문제를 해결합니다. TigerBeetle 프로세스가 시작될 때, 시스템은 수명 동안 필요하게 될 모든 메모리를 계산하고 할당합니다. 여기에는 네트워크 버퍼 (Network buffers), 스토리지 캐시 (Storage cache), 트랜잭션 로그 (Transaction logs), 그리고 합의 상태 머신 (Consensus state machines)을 위한 메모리가 포함됩니다. 초기화 단계가 완료되면 할당자는 사실상 동결되며, 시스템은 완전히 사전 할당된 정적 배열 (Static arrays)과 링 버퍼 (Ring buffers) 내에서 작동합니다.

이러한 설계 선택은 시스템의 예측 가능성 (Predictability)과 신뢰성 (Reliability)에 심오한 영향을 미칩니다:

• 메모리 파편화 제로 (Zero Memory Fragmentation): 런타임 시 메모리가 해제되거나 재할당되지 않기 때문에, 힙 파편화 (Heap fragmentation)가 물리적으로 불가능합니다. 시스템은 파편화된 프리 리스트 (Free lists)로 인해 트랜잭션 도중 메모리 부족 (OOM, Out of Memory) 현상을 겪지 않습니다.
• 결정론적 꼬리 지연 시간 (Deterministic Tail Latency): 메모리 관리자가 빈 블록을 검색하거나 가비지 컬렉션 (Garbage collection) 사이클을 실행할 필요가 없으므로, 실행 경로가 매우 결정론적 (Deterministic)으로 유지됩니다. 모든 CPU 사이클은 메모리 메타데이터를 관리하는 대신 트랜잭션을 처리하는 데 전념합니다.
• 하드웨어 수준의 예측 가능성 (Hardware-Level Predictability): 사전 할당된 메모리 블록은 CPU 캐시 라인 (Cache lines, 일반적으로 64바이트) 및 페이지 경계 (Page boundaries, 4KB 또는 Huge pages)에 정밀하게 정렬될 수 있습니다. 이러한 정렬은 TLB (Translation Lookaside Buffer) 미스와 캐시 라인 바운싱 (Cache line bouncing)을 최소화합니다.

이러한 정적 패러다임과 전통적인 동적 데이터베이스 아키텍처 간의 차이를 설명하기 위해, 다음과 같은 구조적 비교를 고려해 보십시오:

하지만 정적 할당이 공짜 점심은 아닙니다. 이는 주요한 엔지니어링 트레이드오프 (Trade-off)인 경직성 (Rigidity)을 초래합니다. 모든 버퍼의 크기가 고정되어 있기 때문에, 시작 시점 또는 컴파일 타임에 최대 동시 연결 수, 최대 배치 크기 (Batch size), 그리고 최대 스토리지 캐시 크기를 정의해야 합니다. 만약 워크로드 (Workload)가 이러한 사전 정의된 제한을 초과하면, TigerBeetle는 메모리 사용량을 동적으로 확장하지 않습니다. 대신 백프레셔 (Backpressure)를 적용하거나 들어오는 요청을 거부합니다. 저는 예측 가능성과 안전성이 탄력적이고 예측 불가능한 확장성보다 훨씬 더 가치 있는 금융 시스템의 경우, 이러한 트레이드오프가 매우 수용 가능하다는 것을 알 수 있습니다.

커스텀 제로 카피 인터페이스 (Custom Zero-Copy Interfaces) 및 커널 바이패스 (Kernel Bypass)

정적 메모리 할당 (Static memory allocation)을 사용하더라도, 데이터베이스는 운영체제(OS)의 I/O 스택에 의해 쉽게 병목 현상이 발생할 수 있습니다. 표준적인 데이터베이스에서 트랜잭션을 디스크에 기록할 때는 사용자 공간 (User-space) 버퍼에서 커널 공간 (Kernel-space) 페이지 캐시 (Page cache)로 데이터를 복사하고, 최종적으로 해당 페이지들을 물리적 저장 장치로 플러시 (Flush)하는 과정을 거칩니다. 이 과정에는 여러 번의 시스템 콜 (System call), 컨텍스트 스위칭 (Context switch), 그리고 메모리 복사가 수반되며, 이 모든 요소는 귀중한 CPU 사이클과 메모리 대역폭 (Memory bandwidth)을 소모합니다.

TigerBeetle은 커스텀 제로 카피 (Zero-copy) I/O 경로를 구현함으로써 이러한 병목 현상을 우회합니다. 이는 직접 I/O (O_DIRECT)와 Linux의 현대적인 비동기 I/O 인터페이스인 io_uring을 결합하여 달성됩니다.

TigerBeetle이 네트워크를 통해 트랜잭션 배치를 수신하면, 데이터는 미리 할당된 정적 버퍼로 직접 읽힙니다. 이 버퍼는 io_uring에 직접 등록됩니다. 이 트랜잭션들을 디스크의 쓰기 전용 로그 (Write-ahead log, WAL)에 영구 저장해야 할 시점이 되면, TigerBeetle은 정확히 동일한 메모리 주소를 가리키는 I/O 요청을 io_uring에 제출합니다. 커널의 스토리지 드라이버는 이 사용자 공간 메모리 블록에서 직접 데이터를 읽어 직접 메모리 접근 (Direct Memory Access, DMA)을 통해 NVMe 컨트롤러에 기록하며, 이 과정에서 OS 페이지 캐시를 완전히 우회합니다.

이러한 제로 카피 파이프라인 (Zero-copy pipeline)은 데이터가 네트워크 인터페이스 카드 (NIC)에서 CPU를 거쳐 물리적 저장 매체로 이동하는 동안, 서로 다른 메모리 위치 간에 데이터가 절대 복사되지 않도록 보장합니다.

이 제로 카피 (zero-copy) 메커니즘을 매우 신뢰할 수 있고 성능이 뛰어나게 만들기 위해, TigerBeetle은 핵심 데이터 엔티티인 계정 (Accounts)과 이체 (Transfers)를 128바이트 크기의 고정 크기 구조체 (structs)로 구성합니다. 이러한 정확한 크기 설정은 매우 의도적인 것입니다. 128바이트는 표준 CPU 캐시 라인 (cache lines, 64바이트) 및 섹터 크기 (sector sizes, 일반적으로 512바이트 또는 4096바이트)의 배수이기 때문에, TigerBeetle은 이러한 구조체들을 메모리 페이지 (memory pages)와 디스크 섹터 (disk sectors)에 완벽하게 채워 넣을 수 있습니다. JSON, Protocol Buffers, 또는 심지어 커스텀 바이너리 인코더와 같은 복잡한 직렬화 (serialization) 또는 역직렬화 (deserialization) 프로토콜이 필요하지 않습니다. Zig에서의 Account 구조체의 메모리 표현은 디스크 상의 표현과 동일합니다. 계정을 영구 저장하는 것은 해당 메모리 주소를 디스크 컨트롤러에 직접 전달하는 것만큼 간단합니다.

다음은 TigerBeetle이 Zig의 타입 시스템 (type system)을 활용하여 이러한 고정 크기 구조체를 정의하고, 런타임 할당 (runtime allocations) 없이 안전하게 제로 카피 배칭 (zero-copy batching)을 관리하는 개념적 구현 예시입니다:

const std = @import("std");

/// 금융 계정의 고도로 최적화된 128바이트 표현.
...

이 코드는 Zig가 어떻게 타입 레벨에서 메모리 정렬 (align(4096))을 강제할 수 있는지 보여줍니다. 정적 배치 (static batch)를 4KB 페이지 경계에 맞춤으로써, O_DIRECT 및 DMA 전송의 엄격한 정렬 요구 사항을 충족합니다. as_bytes 함수는 컴파일 타임에 검증된 안전한 포인터 캐스트 (pointer cast)를 수행하여, 구조체 배열의 원시 백킹 메모리 (raw backing memory)를 바이트 슬라이스 (byte slice)로 노출하며, 이는 제로 카피로 네트워크를 통해 전송되거나 디스크에 기록될 준비가 된 상태가 됩니다.

싱글 스레드 실행 루프와 VSR 합의 (VSR Consensus)

많은 현대적인 데이터베이스들은 복잡한 잠금 메커니즘 (Locking mechanisms), MVCC (Multi-Version Concurrency Control, 다중 버전 동시성 제어), 또는 액터 모델 (Actor models)을 사용하여 여러 CPU 코어에 걸쳐 트랜잭션 실행을 병렬화함으로써 처리량 (Throughput)을 극대화하려고 시도합니다. 하지만 트랜잭션 상태 업데이트를 병렬화하는 것—특히 계좌 잔액이 엄격하게 순차적으로 확인되고 업데이트되어야 하는 금융 원장 (Financial ledgers)의 경우—은 심각한 잠금 경합 (Lock contention), 스레드 동기화 오버헤드 (Thread synchronization overhead), 그리고 데드락 (Deadlocks)의 위험을 초래합니다.

TigerBeetle은 LMAX Disruptor 패턴에서 큰 영감을 받은 단일 스레드 실행 모델 (Single-threaded execution model)을 핵심 상태 머신 (State machine)에 채택함으로써 이러한 문제들을 우회합니다. 모든 트랜잭션 검증, 잔액 확인, 그리고 원장 업데이트는 단일 전용 CPU 스레드에서 순차적으로 실행됩니다.

단일 스레드 아키텍처가 병목 현상처럼 들릴 수 있지만, 스레드 컨텍스트 스위칭 (Thread context switching), 뮤텍스 획득 (Mutex acquisition), 그리고 캐시 무효화 (Cache invalidation)의 오버헤드로부터 자유로워지면 믿을 수 없을 정도로 빨라집니다. 오직 하나의 스레드만이 원장 상태를 수정하기 때문에, TigerBeetle은 잠금 (Locks), 세마포어 (Semaphores), 또는 복잡한 동시성 제어 (Concurrency controls)를 필요로 하지 않습니다. 실행 스레드는 최대 CPU 주파수로 동작하며, 잠금 없는 링 버퍼 (Lock-free ring buffer)에서 트랜잭션 배치를 가져와 L1/L2 캐시 내에서 순차적으로 처리할 수 있습니다.

이 단일 스레드가 작업으로 완전히 포화 상태를 유지할 수 있도록, TigerBeetle은 공격적인 배치 처리 (Batching)와 Viewstamped Replication (VSR)에 기반한 커스텀 합의 프로토콜 (Custom consensus protocol)에 의존합니다.

TigerBeetle은 트랜잭션을 하나씩 처리하는 대신, 이를 대규모 배치(batch)로 그룹화합니다 (예: 배치당 최대 8,192개의 이체). 합의 계층(consensus layer)은 이러한 배치들을 네트워크를 통해 팔로워 노드(follower nodes)로 복제합니다. 합의 정족수(consensus quorum)에 의해 배치가 커밋되면, 해당 배치는 단일 스레드 실행 루프(single-threaded execution loop)로 전달됩니다. 실행 루프는 전체 배치를 단 한 번의 패스로 처리하며, 인메모리 상태(in-memory state)를 업데이트하고 그 결과를 단일 순차 디스크 쓰기(single, sequential disk write)를 통해 스토리지 엔진(storage engine)에 기록합니다. 이러한 배치 전략은 수천 개의 작은 무작위 디스크 및 네트워크 I/O 작업을 단일하고 매우 효율적인 순차 작업으로 변환하여, NVMe 드라이브와 네트워크 인터페이스의 물리적 처리량(throughput)을 극대화합니다.

🏗️ 메모리 레이아웃(Memory Layout), 캐시 지역성(Cache Locality), 그리고 Zig의 타입 시스템(Type System)

하드웨어 수준에서 코드의 속도는 CPU의 캐시 계층(cache hierarchy)을 얼마나 효율적으로 활용하느냐에 따라 크게 결정됩니다. 현대적인 CPU는 레지스터(register)에 1나노초(nanosecond) 미만, L1 캐시(L1 cache)에 약 1나노초 내에 접근할 수 있습니다. 그러나 메인 메모리(RAM)에 접근하는 데는 약 50~100나노초가 소요되는데, 이는 고성능 시스템에서 영겁과도 같은 시간입니다. 만약 데이터베이스 엔진이 힙(heap) 전역에서 끊임없이 포인터(pointer)를 추적한다면 (Java, Go, Python과 같이 객체 참조가 많은 언어에서 흔히 발생하는 현상), CPU는 RAM으로부터 데이터가 도착하기를 기다리며 대부분의 시간을 스톨(stall, 정지) 상태로 보내게 됩니다.

TigerBeetle은 메모리 내에서 데이터를 연속적으로 유지함으로써 캐시 지역성(cache locality)을 극대화하도록 설계되었습니다. 계정(accounts)과 이체(transfers)가 연속적인 정적 배열(static arrays)에 빽빽하게 채워진 평면적인 고정 크기 구조체(flat, fixed-size structs)로 표현되기 때문에, CPU의 하드웨어 프리페처(hardware prefetcher)가 메모리 액세스 패턴을 쉽게 예측할 수 있습니다. 실행 루프가 이체 배치를 처리할 때, CPU는 실행 스레드가 요청하기도 전에 후속 이체 데이터를 L1/L2 캐시로 미리 가져오며(pre-fetch), 이를 통해 CPU 스톨을 사실상 제거합니다.

Zig의 타입 시스템(type system)은 이러한 방식의 성능 엔지니어링(performance engineering)에 독보적으로 적합합니다. 암시적인 메모리 할당(implicit memory allocations)과 복잡한 복사 생성자(copy constructors)를 허용하는 C++와 달리, Zig는 메모리의 모든 바이트에 대해 명시적인 제어(explicit control)를 강제합니다. 숨겨진 제어 흐름(hidden control flow)이 없으며, 복사를 유발할 수 있는 암시적 타입 변환(implicit type coercion)도 없고, 명시적으로 설계되지 않는 한 가상 메서드 테이블(vtable)로 인한 런타임 오버헤드(runtime overhead)도 발생하지 않습니다.