実用的なデータベース管理システム（database management system; DBMS）のほとんどは先行書き込みログ（write-ahead log; WAL）を備えています。WAL は書き込み効率に優れた追記型の構造を持ち、データのあらゆる変更をストレージ本体（B-Tree や LSM-Tree など）に反映する前にディスクへ記録することで耐久性を保証します。また、WAL は他の DBMS へのデータのレプリケーションにもしばしば用いられます。ワークロードを分散させてレイテンシーを削減したり、データを他リージョンのデータベースに複製することで耐久性や可用性を向上させることができます。"The truth is the log^[1]"、"the log is the database^[2]" と言われるほどに、書き込みログはデータベースにおいて重要な役割を担っています。

これは Amazon Aurora DSQL や Amazon MemoryDB などの、AWS が提供するさまざまな DBMS サービスにも当てはまります。興味深いことに、これらの DBMS は書き込みログ（トランザクションログ）の永続化とレプリケーションを独立したコンポーネントに委譲しています。この AWS 内部のコンポーネントは Journal と呼ばれ、マルチ AZ またはマルチリージョンレベルのトランザクションログ永続化およびレプリケーションをサポートしています。

Journal は AWS の中で約10年に渡って開発されてきました^[3]。しかし、Journal 自体に関する公式な資料はほとんど公開されておらず、その仕組みは未だ謎に包まれています。

本記事では、AWS の技術文書や開発者によって発信された情報をもとに、Journal の設計と機能の核心に迫ります。そしてこのコンポーネントを通じて、近年の大規模分散データベースがどのように設計されているのか、そのトレンドを考察していきます。

Journal を基盤とするサービス

まずはどのような AWS サービスが Journal を基盤として構築されているのかを見ていきましょう。

Journal は単一リージョン内の複数のアベイラビリティゾーン（availability zone; AZ）、あるいは地理的に離れた複数のリージョンへのレプリケーションをサポートしています。後述するように、Journal はレプリカの配置の違いに応じて異なるレプリケーション方式を採用しています。この記事では便宜上、それぞれをマルチ AZ Journal、マルチリージョン Journal と呼称します。

Amazon MemoryDB

Amazon MemoryDB は Valkey/Redis 互換のインメモリデータベースです。MemoryDB に書き込まれたデータは即座に永続化されるため、高い可用性と耐障害性を備えています。

MemoryDB のアーキテクチャ。赤い実線は同期的な書き込み、赤い点線は非同期的な書き込み、青い実線は読み出しのパスを表します。

この永続化はマルチ AZ Journal によって実現されています^[4]^[5]^[6]。MemoryDB は、書き込みを Valkey/Redis シャードに反映した後にその記録を Journal に同期的にコミットし^[7]、コミットの成功をもってクライアントに成功のレスポンスを返します。これにより、MemoryDB はマルチ AZ レベルの耐久性を実現しています。

Journal に記録された MemoryDB のトランザクションログは、セカンダリノードへの非同期レプリケーションや、データリカバリのための定期的なスナップショットの作成に利用されます。またレプリカのリーダー選出は、Journal が提供する条件付き追記 API とリースによって実装されています。

Amazon Aurora DSQL

Amazon Aurora DSQL は PostgreSQL 互換のサーバーレス分散 SQL データベースです。DSQL では、複数の AZ またはリージョンにデプロイされたレプリカがデータの完全なコピーを保持しており、クライアントは自身が属する AZ またはリージョン内のレプリカに対してデータの読み書きが可能です（アクティブ・アクティブ構成）。

Aurora DSQL のアーキテクチャ。赤い実線は同期的な書き込み、赤い点線は非同期的な書き込み、青い実線は読み出しのパスを表します。

DSQL における WAL の保存および AZ・リージョン間のレプリケーションは Journal によって実現されています^[8]。書き込み処理においては、Query Processor によって処理されたトランザクションが Adjudicator によってコンフリクトの有無を検査され、問題がなければ Journal にコミットされます。コミットが成功した時点で、クライアントには成功が通知されます。並行して、Storage は Crossbar を経由してコミットされたトランザクションを取得し、自身が保持するビューを更新します。AZ やリージョンを跨ぐレイテンシーが発生するのは、トランザクションが COMMIT されるタイミング、すなわち Journal がトランザクションを複数の AZ またはリージョンにコミットするときだけです。

Journal はコミットされたトランザクションをそのタイムスタンプに基づいて順序づけします。各トランザクションは任意のキー範囲を対象としうるため、Journal のトランザクションログはキー空間でパーティションされていません。水平スケーリングされた Journal の各インスタンスが、トランザクション単位で書き込みを順序づけして保存します。すべての Journal インスタンスからトランザクションを取得し全順序を決定するのは DSQL（Crossbar）の責務です。

データの読み出しはトランザクション開始時点 $t_\mathrm{start}$ におけるデータベースのスナップショットを参照するように振る舞います（スナップショット分離）。これは MVCC （multiversion concurrency control）によって実現されており、ローカルの Storage 内で完結します。Storage は Journal から時刻 $t_\mathrm{start}$ までのトランザクションを取得・反映したうえで、読み出し処理を行います。この仕組みにより、読み出しはロックやリーダー選出による調整を必要とせず、他の読み出しや書き込みトランザクションをブロックしません。

Amazon DynamoDB global tables

Amazon DynamoDB はサーバーレスの NoSQL データベースサービスです。Amazon DynamoDB global tables はテーブルを複数のリージョンに複製し、各リージョンでのデータの読み書きをサポートしています（マルチアクティブ構成）。

2025年6月から、DynamoDB global tables は複数リージョンにまたがるテーブルの強一貫性（strong consistency）をサポートしています。これにより、クライアントはどのリージョンにアクセスしても常に最新のデータを取得できます。

DynamoDB global tables のアーキテクチャ。赤い実線は同期的な書き込み、赤い点線は非同期的な書き込みを表します。

DynamoDB global tables のリージョン間レプリケーションはマルチリージョン Journal によって実現されています^[9]。あるリージョンでのテーブルへの書き込みはまず Journal にコミットされ、コミットが成功した時点でクライアントに成功が通知されます。その後、書き込みが同じリージョン内の DynamoDB テーブルに反映されます。他のリージョンに存在する DynamoDB は同じ Journal のトランザクションログを共有しており、コミットされた書き込みを取得すると、同様に自身の持つテーブルに反映します。Journal は複数のリージョンからの書き込みを受け付けて順序づけし、データの一貫性を保証します。

あるリージョンでデータの読み出しが行われる際、そのリージョンの DynamoDB テーブルには他のリージョンで書き込まれたデータがまだ反映されていないかもしれません。これに対して強一貫性を保証するため、リクエストを処理する GT Shard Processor は読み出し時にハートビートと呼ばれる特別なレコードを Journal にコミットします。自身のハートビートを Journal から取得した時点で、リクエストの受理時からハートビートの送信時までにコミットされたすべての書き込みがローカルの DynamoDB テーブルに反映されたことが保証できるので、最新の値を返すことができます。

Amazon Elastic Kubernetes Service

Amazon Elastic Kubernetes Service（EKS）はマネージドな Kubernetes クラスターを提供するサービスです。

通常、Kubernetes クラスターはオブジェクトを etcd に保存します。一貫性を保証するため、etcd は内部で合意アルゴリズム（Raft）を使用しています。

EKS における Kubernetes クラスターのアーキテクチャ。

EKS はこの Raft ベースの合意プロトコルをマルチ AZ Journal に置き換えています^[10]。これにより、従来のクオラムの制約を超えて etcd クラスターをスケールアウトすることができます。また、Journal によって AZ レベルの耐久性が保証されているため、etcd のキーバリューストア（Bolt）はデータをメモリ（tmpfs）上に保存することができ、高速な読み書きスループットと安定したレイテンシを実現しています。

Journal の価値

ここまで AWS のさまざまな DBMS サービスが Journal を利用していることを見てきました。では、なぜこれらのサービスはトランザクションの永続化やレプリケーションを Journal に委譲しているのでしょうか？この理由として、主に次の2点が挙げられます。

1つ目は、DBMS サービスの実装をシンプルに保つためです。どのような手法を用いるにせよ、データを複製して一貫した読み書きを実現するには設計や実装に大変な労力が必要です。レプリケーションの責務を Journal に集約することで、各 DBMS サービスはその仕組みを個別に実装する必要がなくなります（関心の分離）。

2つ目は、DBMS サービスを柔軟にスケールするためです。永続化やレプリケーションの責務を Journal に切り出すことで、各 DBMS コンポーネントは需要に応じて個別にスケールすることができます。例えば、MemoryDB は DRAM 使用量に応じてインメモリエンジン（Valkey/Redis）をスケールしたり、書き込み帯域幅に応じて Journal をスケールすることができます。DSQL は Query Processor （Firecracker の MicroVM）や Adjudicator、Crossbar、Storage といったコンポーネントを、それぞれのリソースの使用量に応じて個別にスケールできます。

このような、コンポーネントとそれらに紐づくハードウェアリソースを分離して拡張可能にするアプローチはディスアグリゲーション（disaggregation）^[11]と呼ばれ、近年の DBMS 設計における重要なトレンドになっています^[12]。

Journal の設計

Journal はトランザクションの追記および購読をサポートするシンプルな API を備えていると考えられます。必要な機能やアーキテクチャ特性は以下の通りです。

トランザクションの直列化。Journal に追記されたトランザクションには一意なシーケンス番号が割り振られます。Journal を購読するすべてのクライアントはトランザクションを同じ順序で受け取ります。

トランザクションの条件付き追記。Journal は compare-and-set のような、特定の条件（例：指定したコミット済みトランザクションに基づく条件）が満たされた場合にのみ新しいデータを追記する機能をサポートしています。

スケーラビリティ。Journal は必要な書き込み帯域幅に応じて柔軟にスケールイン・スケールアウトすることができます。
耐久性（durability）。一部の AZ やリージョンでデータが損失しても、他の場所に保存されたデータから復旧できます。
可用性（availability）。一部の AZ やリージョンがダウンしていても、追記や購読の処理が継続できます。
パフォーマンス。Journal へのコミットはデータベースの読み書き処理のクリティカルパス上にあるため、そのレイテンシはサービスの信頼性に直結します。

これらの機能や特性の一部は互いにトレードオフの関係にあります。以降のセクションでは Journal がこれらをどのように実現しているのかを見ていきます。

直列化とスケーラビリティ

Journal へのコミットがボトルネックになるのを防ぐため、書き込みの流量に応じて Journal をスケールアウトする必要があります。

一方で、Journal に追記されたトランザクションはデータの一貫性のために直列化されなくてはなりません。ナイーブな手法として、Multi-Paxos や Raft 等を用いて選出されたリーダーのみに書き込みを許す方法が考えられますが、これではスケールアウトの利点を活かすことができません。また DSQL の例で見たように、Journal のトランザクションログはキー空間でパーティションされていない場合もあります。

スケールされた Journal のインスタンスと直列化されたトランザクションログ。

したがって、スケールアウトされた Journal では各インスタンスが個別にトランザクションログを保持していると考えるのが妥当でしょう。実際、DSQL の Crossbar は各 Journal インスタンスが管理するトランザクションログを全順序を持つ単一のログへと変換するコンポーネントとみなすことができます。では、このときトランザクションの全順序はどのように定めればよいでしょうか。

鍵となるのは、ログに追記されたトランザクションがタイムスタンプによって順序づけされている^[13]という点です。AWS が提供するマシンはマイクロ秒単位での時刻の正確性を保証しており、異なる Journal インスタンスでコミットされたトランザクションであっても、ほとんどの場合その順序を厳密に定めることができます。万が一タイムスタンプが衝突した場合は、DSQL の Adjudicator のようなコンポーネントで検知するか、書き込み元のクライアントや Journal のインスタンスに優先順位を設定してタイブレークを行うなどの戦略が考えられます。

そして裏を返せば、AWS のようなハイパースケーラーにとってノード間の正確な時刻同期がデータベースの根幹を支える構成要素であるということが見て取れます。Google の Spanner が TrueTime によって提供されている誤差保証付き時刻に依存していることはよく知られています。また Meta も自社のデータセンターにおいて、 99.9999% の確度で誤差を500ナノ秒以下に抑える時刻同期のための機器やソフトウェアを導入しており、読み書きの線形性を保証するコミット待機（commit-wait）に利用しています。

耐久性と可用性

耐久性を保証するため、Journal はトランザクションを3つの AZ またはリージョンに複製して永続化します。一方で可用性を担保するためには、すべてのレプリカへの書き込みの完了を待つのではなく、一定数のレプリカに永続化された時点でコミットを成功とみなすのが望ましいです。

この要件を満たすために、Journal はレプリカの配置に応じて以下のレプリケーションプロトコルを利用しています^[14]：

マルチ AZ： Chain Replication の亜種（コントローラーは Paxos ベース）
マルチリージョン：クオラム

個々のプロトコルについては後述しますが、ここで注目すべきは、Journal がレプリケーションにおいて Raft や Multi-Paxos などのリーダー選出を伴う合意アルゴリズムを使用していないという点です。

リーダー選出を伴う合意アルゴリズムはレプリケーションの問題をシンプルに解決できる便利な手法ですが、必ずしも常に最適であるとは限りません^[15]。

耐久性とストレージ効率： $f$ 個のレプリカの破損に耐えることを目指すとします。Raft などの合意アルゴリズムでは $2f+1$ 個のレプリカが必要になる一方で、Chain Replication では $f+1$ 個で済みます。
可用性：1つのレプリカがダウンしたとします。Raft や Multi-Paxos では、ダウンしたノードがリーダーであった場合にコミットが進行できなくなる可能性があります。一方でクオラムを用いる場合は、どのノードがダウンしてもクオラムを満たす限りコミットが継続できます。

このことから、Journal が状況に応じて最適なレプリケーション方式を選択していることが伺えます。次のセクションで、マルチ AZ、マルチリージョンの場合のレプリケーション方式について詳しく見ていきましょう。

マルチ AZ レプリケーション

マルチ AZ レプリケーションには Chain Replication^[16] の亜種が用いられています。 Chain Replication は、データを各ノードにバケツリレーのような形で転送していき、読み出しは末端のノードからのみ行うレプリケーションプロトコルです。亜種としては、 DeepSeek が開発した分散ファイルシステム 3FS で採用されている CRAQ^[17] などが知られていますが^[18]、Journal が具体的にどのようなプロトコルを利用しているかは明らかにされていません。

コントローラープレーンには Paxos が用いられています。 Chain Replication の範疇ではレプリケーショングループへのノードの追加や削除ができないため、このような管理操作（リコンフィギュレーション；reconfiguration）が合意アルゴリズムに委ねられていると考えられます。

このアプローチは、Meta が開発したコントロールプレーン向けのデータベース Delos で用いられている Virtual Consensus^[19]^[20] に類似しています。Virtual Consensus では、ステートマシンレプリケーションを複数のログレット（Loglet）からなる仮想ログ（VirtualLog）によって行います。仮想ログとログレットのマッピングはメタストア（MetaStore）によって管理されており、仮想メモリと物理メモリのような関係性になっています。ログの追記は末尾のログレットに対して行われますが、このとき合意アルゴリズムによる耐障害性を保証する必要はありません。ログレットへの追記が失敗した場合、仮想ログは現在のログレットを封印（seal）し、新しいログレットをリコンフィギュレーションによって追加します。

マルチリージョンレプリケーション

マルチリージョンレプリケーションにはクオラム（quorum）が用いられています。Journal は3つのリージョンをサポートしており、トランザクションのコミットは2つのリージョンへの書き込みが完了した時点で成功とみなされます。読み出しも2つ以上のリージョンから行います。

注意すべき点として、クオラムはそれ単体では線形化可能性（linearizability）を保証しません^[21]。例としてリージョンA、B、Cへの書き込みを考えます。このとき、リージョンAへのデータの書き込みが完了した時点で、クライアントがリージョンAとBから読み出しを行った場合、クライアントは書き込まれたデータを取得することができます。しかし、その直後にリージョンB、Cから読み出しを行ってもクライアントは同じデータを取得できません。

この一貫性の問題を防ぐために、Journal の読み出し処理においても AWS のインフラが提供する正確な時刻が活用されていると推測されます。

また、Journal によるマルチリージョンレプリケーションで注目すべきもう一つの点は、レプリケーションのトポロジーです。例えば、リージョンAにいる Journal のクライアントがリージョンA、B、Cにトランザクションを書き込むとします。ここでリージョンAとBの間にネットワーク分断が発生すると、リージョンAの Journal のレプリカはリージョンBへの書き込みを完了できません。しかしこのとき、リージョンCに存在する Journal のレプリカがデータをリージョンBへ転送することによって、書き込みを代行することができます^[22]。

条件付き追記

Journal はトランザクションの条件付き追記をサポートしています。これは、MemoryDB においてレプリカからプライマリノード（リーダー）を選出し、書き込みをプライマリノードにのみ制限するために用いられます。

Journal の条件付き追記は、書き込みの際にすでにコミットされたトランザクションのシーケンス番号を指定し、それが特定の条件を満たす際にトランザクションをコミットするものと説明されています。あるいは、現在のリーダー情報のような特定の値をアトミックに更新する API としても紹介されています。

この機能が実際にどのようなインターフェースを持ち、どのように実装されているのかは明らかにされていません。しかし理論的には、Journal はログの全順序ブロードキャスト（total order broadcast または atomic broadcast）を提供するシステムとみなせるので、その上で線形化可能な compare-and-set 操作を実現できます^[23]。

例えばリーダー選出を行う場合、各ノードは現在のリーダーの情報を保持するログ上の仮想的なストレージを用いて、以下のような手順で自身のリーダー昇格を試みることができます。

ノードnが自身をリーダーに選出するリクエスト{"leader" : n}をログにコミットする。
ノードnは以降にコミットされたリーダー選出リクエスト{"leader" : l}をログから取得する。
- l == nの場合、ノードnがリーダーに選出される（leader に n がセットされる）。
- l != n の場合、n 以外のノードがすでにリーダーとして選出されている（leader は l のまま変わらない）。

実用的には、リーダー情報とともにその有効期限（リース）を保存することで、リーダーを一つのノードに固定しシステムの安定性を高めることができます。リーダーは定期的にリースを更新することで自身がリーダーである状態を保持します。他のノードは、リースが一定期間内に更新されなかった場合にリーダーへの昇格を試みます。

Journal の検証

Journal は永続性とレプリケーションを担うコンポーネントです。その性質上、システムの正しさを検証することは非常に重要です。

Journal の仕様は TLA+ によって形式的に検証されています^[24]。また、AWS は Must と呼ばれる Rust をベースにした分散システムの検証用フレームワークを開発しており^[25]、Journal はそのベンチマークケースとして Must により検証されています。Journal に限らず、S3 や IAM などの AWS の主要なコンポーネントは形式手法や自動推論のような技術を用いて正当性の検査が行われていることが知られています。

関連手法

レプリカに複製されたデータを中央集権的に管理するミドルウェアとしては、Apache ZooKeeper や etcd、Google の Chubby^[26] などが挙げられます。これらは合意アルゴリズムによってデータの一貫性を保証します。Journal と大きく異なるのは、これらがログ形式のデータではなく（直列化された書き込みによって構築される）キーバリューストアを提供する点です。このデータストアは巨大なデータの保存や高頻度の書き込みには適しておらず、主にサービスの管理情報やメタデータの保持に利用されます。

Journal をログを追記・配信するサービスとして捉えると、Apache Kafka や RabbitMQ といったメッセージブローカーとの類似性も見出せるかもしれません。しかしこれらのサービスは Journal とは異なり、メッセージの配信において順序の一貫性や exactly-once セマンティクスを必ずしも保証しません。

AWS における Journal のように、データベースのような分散システムからログを独立したコンポーネント（層）として分離・抽象化する設計手法は Shared Log Abstraction^[27]^[28] として知られています。この分離により、データベースは複雑なレプリケーションや合意アルゴリズムの実装を共通のコンポーネントに委任し、独立してスケール可能になります。Shared Log Abstraction を実践したミドルウェアとしては Corfu や LogDevice などが知られています。

特に LogDevice は Meta（旧 Facebook）によって開発されたミドルウェアで、2017年から同社のプロダクションレベルのワークロードを支えています。LogDevice は Journal と同様に、追記されたレコードの可用性と耐久性、および直列化を保証し、トランザクションログや WAL の保存、イベントストリーミングなどへの利用が想定されています。Journal と異なる点としては、レコードの直列化に Sequencer と呼ばれる特別なノードを用いていること、また読み書きに flexible Multi-Paxos の亜種が用いられていることなどが挙げられます。

まとめ

本記事では、AWS が同社のさまざまな DBMS サービスの基盤として開発・利用している内部コンポーネント Journal について紹介しました。また、 Journal がどのように設計されているのかについて AWS の開発者によって発信された情報をもとに考察しました。

Journal の設計にはまだ明らかになっていない点がいくつかあります。特に、Journal がどのようにして DBMS の WAL としての利用に耐えうるパフォーマンスを実現しているのか、また不要になったトランザクションログをどのように削除しているのかについては、私の知る限り公開されている情報はありません。今後こうした設計の詳細が明らかになることを期待しましょう。

また Journal の設計を深掘りする過程で、ノード間の正確な時刻同期やディスアグリゲーション、合意アルゴリズムの控えめな使用といった、現代の大規模分散データベースにおいて主流になりつつある設計手法について触れました。これらのテクニックは、大規模なデータセンターの構築やハードウェアの効率的な調達が可能なハイパースケーラーだからこそ実現できるという側面もあります。ですが、今後のエコシステムの発展によってはより一般的な手法として広まっていくかもしれません。

脚注

Pat Helland. 2015. Immutability changes everything. Commun. ACM 59, 1 (January 2016), 64–70. (doi) ↩︎
Alexandre Verbitski, Anurag Gupta, Debanjan Saha, Murali Brahmadesam, Kamal Gupta, Raman Mittal, Sailesh Krishnamurthy, Sandor Maurice, Tengiz Kharatishvili, and Xiaofeng Bao. 2017. Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases. In Proceedings of the 2017 ACM International Conference on Management of Data (SIGMOD '17). Association for Computing Machinery, New York, NY, USA, 1041–1052. (doi), (amazon.science) ↩︎
"Journal is an internal component we’ve been building at AWS for nearly a decade, optimized for ordered data replication across hosts, AZs, and regions." -- DSQL Vignette: Transactions and Durability - Marc's Blog ↩︎
Yacine Taleb, Kevin McGehee, Nan Yan, Shawn Wang, Stefan C. Müller, and Allen Samuels. 2024. Amazon MemoryDB: A Fast and Durable Memory-First Cloud Database. In Companion of the 2024 International Conference on Management of Data (SIGMOD '24). Association for Computing Machinery, New York, NY, USA, 309–320. (doi), (amazon.science) ↩︎
MemoryDB の技術的な詳細については、論文に加え Murat Demirbas による解説記事および Marc Brooker による解説記事が詳しい。 ↩︎
MemoryDB の論文において "transaction log service" と呼ばれているものが実際には Journal であることが Marc Brooker によって明言されています。 ↩︎
この振る舞いは WAL（write-ahead log）ではなく、むしろ write-behind であるといえます。これは Valkey/Redis のレプリケーションが本来、データベースの書き込み後に行われる非同期処理であり、MemoryDB がこの部分を Journal に置き換える必要があったためです。これにより、MemoryDB は大きな変更を加えることなく Valkey/Redis を導入し、SPOP のような非決定的な操作もレプリケーションすることができます。 ↩︎
DSQL に関するフォーマルな技術論文はまだ公開されていません。この解説の作成にあたり、Marc Brooker（DSQL 開発者）による DSQL Vignette シリーズ（1, 2, 3, 4）および AWS re:Invent 2024 のトーク、Marc Bowes （DSQL 開発者）による解説記事、 Werner Vogels （Amazon.com CTO）による開発秘話の紹介などを参考にしました。 ↩︎
Jeff Duffy と Somu Perianayagam による AWS re:Invent 2024 のトーク（特に 32:17 以降）を参照。 ↩︎
以降の EKS に関する改善の内容については Under the hood: Amazon EKS ultra scale clusters を参照。 ↩︎
Jianguo Wang and Qizhen Zhang. 2023. Disaggregated Database Systems. In Companion of the 2023 International Conference on Management of Data (SIGMOD '23). Association for Computing Machinery, New York, NY, USA, 37–44. (doi), (slides) ↩︎
"Storage-compute disaggregation in databases has emerged as a pivotal architecture in cloud environments, as evidenced by Amazon (Aurora), Microsoft (Socrates), Google (AlloyDB), Alibaba (PolarDB), and Huawei (Taurus)." -- Understanding the Performance Implications of Storage-Disaggregated Databases ↩︎
"Each journal is ordered by transaction time" -- Just make it scale: An Aurora DSQL story ↩︎
"In-region replication is a chain replication variant (with a Paxos-based control plane), cross-region is a custom quorum protocol (though Paxos-derived if you look at it the right way)." -- Marc Brooker による X の投稿 ↩︎
Raft などのリーダー選出を伴う合意アルゴリズムのトレードオフについては、Alex Miller によるトーク Enough With All The Raft が詳しいです。また、合意アルゴリズムで何をレプリケーションするかという問題については、Adam Prout による記事 Categorizing How Distributed Databases Utilize Consensus Algorithms が参考になります。 ↩︎
Robbert van Renesse and Fred B. Schneider. 2004. Chain replication for supporting high throughput and availability. In Proceedings of the 6th conference on Symposium on Operating Systems Design & Implementation - Volume 6 (OSDI'04). USENIX Association, USA, 7. (usenix.org) ↩︎
Jeff Terrace and Michael J. Freedman. 2009. Object storage on CRAQ: high-throughput chain replication for read-mostly workloads. In Proceedings of the 2009 conference on USENIX Annual technical conference (USENIX'09). USENIX Association, USA, 11. (usenix.org) ↩︎
Alex Miller による記事 Data Replication Design Spectrum において、Chain Replication 等はレプリカの障害発生時にレプリケーショングループの再構成が必要なプロトコル（failure detection / reconfiguration）として分類されています。同記事では Chain Replication の亜種についても紹介があります。 ↩︎
Mahesh Balakrishnan, Jason Flinn, Chen Shen, Mihir Dharamshi, Ahmed Jafri, Xiao Shi, Santosh Ghosh, Hazem Hassan, Aaryaman Sagar, Rhed Shi, Jingming Liu, Filip Gruszczynski, Xianan Zhang, Huy Hoang, Ahmed Yossef, Francois Richard, and Yee Jiun Song. 2020. Virtual consensus in delos. In Proceedings of the 14th USENIX Conference on Operating Systems Design and Implementation (OSDI'20). USENIX Association, USA, Article 35, 617–632. (usenix.org) ↩︎
Virtual Consensus の詳細については、論文の他に Murat Demirbas による解説記事 Virtual Consensus in Delos、および Jack Vanlightly による解説記事 An Introduction to Virtual Consensus in Delosが参考になります。 ↩︎
Designing Data-Intensive Applications（日本語訳：データ指向アプリケーションデザイン）の「9.2.3.1 線形化可能性とクオラム」を参照。 ↩︎
Jeff Duffy と Somu Perianayagam による DynamoDB global tables に関する AWS re:Invent 2024 のトークの 42:11 以降を参照。 ↩︎
Designing Data-Intensive Applications（日本語訳：データ指向アプリケーションデザイン）の「9.3.3.2 全順序ブロードキャストを利用した線形化可能なストレージの実装」を参照。 ↩︎
"The internal transaction log replication protocol is modelled and verified using TLA+." -- Amazon MemoryDB: A Fast and Durable Memory-First Cloud Database ↩︎
Constantin Enea, Dimitra Giannakopoulou, Michalis Kokologiannakis, and Rupak Majumdar. 2024. Model Checking Distributed Protocols in Must. Proc. ACM Program. Lang. 8, OOPSLA2, Article 338 (October 2024), 28 pages. (doi), (amazon.science) ↩︎
Mike Burrows. 2006. The Chubby lock service for loosely-coupled distributed systems. In Proceedings of the 7th USENIX Symposium on Operating Systems Design and Implementation - Volume 7 (OSDI '06). USENIX Association, USA, 24. (google.com) ↩︎
Mahesh Balakrishnan. 2024. Taming Consensus in the Wild (with the Shared Log Abstraction). SIGOPS Oper. Syst. Rev. 58, 1 (June 2024), 1–6. (doi) ↩︎
Shared Log Abstraction については、論文の他 Murat Demirbas による記事 Taming Consensus in the Wild (with the Shared Log Abstraction) が参考になります。 ↩︎

Discussion