TigerBeetle コアシステムアーキテクチャ：パフォーマンスエンジニアリングの解剖

2026-07-28 | 10 分で読む | 一般 Shuvo著 システムプログラミング Zig データベース設計 パフォーマンスエンジニアリング 低レイテンシ はじめに 高性能データベースアーキテクチャを評価する際、議論はしばしば水平スケーリング、分散パーティショニング、クエリ最適化に集中します。しかし、金融レジャーのようなミッションクリティカルなトランザクションシステムでは、真のボトルネックはネットワークやクエリプランナーであることは稀であり、オペレーティングシステムカーネル、メモリフラグメンテーション、予測不可能なテールレイテンシです。Zigで書かれた特殊な金融レジャーデータベースであるTigerBeetleは、極端なメカニカルシンパシー、静的なリソース割り当て、カスタムゼロコピーインターフェースを優先することで、従来のデータベース設計に挑戦しています。私は分散ストレージエンジンの分析に長年費やしてきましたが、TigerBeetleのアーキテクチャ上の選択は、現代のパフォーマンスエンジニアリングにおけるマスタークラスとして際立っています。実行時の動的なメモリ割り当てを拒否し、ダイレクトI/Oを介してカーネルキャッシュをバイパスし、Viewstamped Replication (VSR) に裏打ちされた単一スレッド実行ループを活用することで、TigerBeetleは予測可能なサブミリ秒のテールレイテンシで、毎秒数十万トランザクションを超えるスループットレートを達成します。この記事では、TigerBeetleのコアアーキテクチャの柱を解体します。静的割り当てが実行時のガベージコレクションとメモリフラグメンテーションをどのように排除するか、カスタムゼロコピーインターフェースがCPUからメモリへのバスオーバーヘッドをどのように最小限に抑えるか、そしてZigのコンパイル時機能が生のハードウェアパフォーマンスを犠牲にすることなく厳格な安全性保証をどのように強制するかを調べます。私の目標は、エンジニアリングリーダーやシステムアーキテクトに、これらの低レベル設計パターンに関する実行可能な洞察を提供し、同様のパフォーマンスエンジニアリング原則を独自の高スループットシステムに適用できるようにすることです。 静的割り当て：実行時のメモリオーバーヘッドの排除 従来のデータベースシステムでは、メモリ管理は非常に動的です。クエリが到着すると、データベースは接続バッファ、クエリプラン、一時ソートバッファ、トランザクション状態のためにメモリを割り当てます。jemallocやtcmallocのような最新のメモリアロケータは高度に最適化されていますが、スレッド競合、メモリフラグメンテーション、ピークロード時の予測不可能なレイテンシスパイクの影響を受けません。単一の遅延トランザクションが下流の支払いパイプラインを混乱させる可能性のある金融レジャーでは、これらのレイテンシスパイク（しばしば「ノイジーネイバー」または「ロングテール」問題と呼ばれる）は許容できません。TigerBeetleは、初期化フェーズ以降、動的なメモリ割り当て（malloc、free、またはその同等物）を完全に排除することで、これに対処します。TigerBeetleプロセスが開始されると、その寿命中に必要となるすべてのメモリを計算して割り当てます。これには、ネットワークバッファ、ストレージキャッシュ、トランザクションログ、コンセンサス状態マシン用のメモリが含まれます。初期化フェーズが完了すると、アロケータは事実上フリーズされ、システムは完全に事前に割り当てられた静的な配列とリングバッファ内で実行されます。この設計上の選択は、システムの予測可能性と信頼性に大きな影響を与えます。 ゼロメモリフラグメンテーション：メモリは実行時に解放および再割り当てされないため、ヒープフラグメンテーションは物理的に不可能です。システムは、フラグメント化されたフリーリストのために、トランザクション中にメモリ不足（OOM）になることはありません。 決定論的なテールレイテンシ：メモリマネージャーがフリーブロックを検索したり、ガベージコレクションサイクルを実行したりすることなく、実行パスは高度に決定論的であり続けます。すべてのCPUサイクルは、メモリメタデータを管理するのではなく、トランザクションの処理に専念します。 ハードウェアレベルの予測可能性：事前に割り当てられたメモリブロックは、CPUキャッシュライン（通常64バイト）およびページ境界（4KBまたは巨大ページ）に正確にアラインメントできます。このアラインメントは、TLB（Translation Lookaside Buffer）ミスとキャッシュラインバウンスを最小限に抑えます。 この静的パラダイムと従来の動的データベースアーキテクチャの違いを説明するために、次の構造比較を検討してください。 アーキテクチャ属性 | 従来の動的データベース | TigerBeetle 静的アーキテクチャ メモリ割り当て | 動的（実行時ヒープ割り当て） | 静的（起動時に事前割り当て） テールレイテンシ（p99.99） | 変動的（GC/フラグメンテーションの影響を受ける） | 決定論的（サブミリ秒の範囲） I/Oパス | カーネルページキャッシュを介したバッファリングI/O | io_uring を使用したダイレクトI/O (O_DIRECT) 並行性モデル | ロック/ラッチを持つマルチスレッド | 単一スレッドイベントループ（Disruptorパターン） データレイアウト | 可変長行/ドキュメント | 固定サイズ構造体（128バイトのアカウント/転送） 障害ドメイン | 動的なメモリ不足（OOM）リスク | 予測可能なコンパイル時/起動時制限 しかし、静的割り当てには代償が伴います。それは、硬直性という大きなエンジニアリング上のトレードオフをもたらします。すべてのバッファは固定サイズであるため、起動時またはコンパイル時に同時接続の最大数、バッチサイズの最大数、ストレージキャッシュサイズの最大数を定義する必要があります。ワークロードがこれらの事前定義された制限を超える場合、TigerBeetleはメモリ使用量を動的にスケーリングしません。代わりに、バックプレッシャーを適用するか、受信リクエストを拒否します。このトレードオフは、予測可能性と安全性が、弾力的で予測不可能なスケーリングよりもはるかに価値のある金融システムにとって、非常に許容できるものだと私は考えています。 カスタムゼロコピーインターフェースとカーネルバイパス 静的なメモリ割り当てを使用しても、データベースはオペレーティングシステムのI/Oスタックによって簡単にボトルネックになる可能性があります。標準的なデータベースでは、トランザクションをディスクに書き込むには、ユーザースペースバッファからカーネルスペースのページキャッシュへのデータのコピー、そして最終的にそれらのページを物理ストレージにフラッシュすることが含まれます。このプロセスには、複数のシステムコール、コンテキストスイッチ、メモリコピーが含まれ、これらすべてが貴重なCPUサイクルとメモリ帯域幅を消費します。TigerBeetleは、カスタムゼロコピーI/Oパスを実装することで、これらのボトルネックを回避します。これは、ダイレクトI/O (O_DIRECT) とLinuxの最新の非同期I/Oインターフェースであるio_uringを組み合わせることで実現されます。TigerBeetleがネットワーク経由でトランザクションのバッチを受信すると、データは事前に割り当てられた静的バッファに直接読み込まれます。このバッファはio_uringに直接登録されます。トランザクションを書き込み先頭ログ（WAL）にディスクに永続化する時期が来ると、TigerBeetleはio_uringに、まったく同じメモリ位置を指すI/Oリクエストを送信します。カーネルのストレージドライバは、このユーザースペースメモリブロックから直接読み取り、ダイレクトメモリアクセス（DMA）を介してNVMeコントローラに書き込みます。これにより、OSのページキャッシュが完全にバイパスされます。このゼロコピーパイプラインにより、データはネットワークインターフェースカード（NIC）からCPUを通過し、物理ストレージメディアに到達するまで、異なるメモリ位置間でコピーされることはありません。 このゼロコピーメカニズムを非常に信頼性が高くパフォーマンスの高いものにするために、TigerBeetleはコアデータエンティティ（アカウントと転送）を固定サイズの128バイト構造体として構成します。この正確なサイジングは非常に意図的です。128バイトは標準的なCPUキャッシュライン（64バイト）およびセクターサイズ（通常512バイトまたは4096バイト）の倍数であるため、TigerBeetleはこれらの構造体をメモリページおよびディスクセクターに完全にパックできます。JSON、Protocol Buffers、さらにはカスタムバイナリエンコーダーのような複雑なシリアライゼーションまたはデシリアライゼーションプロトコルは不要です。ZigにおけるAccount構造体のメモリ表現は、ディスク上の表現と同一です。アカウントを永続化することは、そのメモリアドレスをディスクコントローラに直接渡すのと同じくらい簡単です。 以下は、TigerBeetleがZigの型システムを活用してこれらの固定サイズ構造体を定義し、実行時割り当てなしで安全にゼロコピーバッチ処理を管理する方法の概念的な実装です。 const std = @import("std"); /// 高度に最適化された128バイトの金融アカウント表現。 /// 明示的なアラインメントにより、この構造体の配列がCPUキャッシュラインに完全にアラインメントされることが保証されます。 pub const Account = struct { id: u128, user_data: u128, reserved: [48]u8, // 正確な128バイトサイズと将来の互換性のためにパディング ledger: u32, code: u16, flags: u16, debits_p };