Aurora DSQL: スケーラブルでマルチリージョン対応のOLTP

Aurora DSQL: スケーラブルでマルチリージョン対応のOLTP リンクを取得 Facebook X Pinterest Email その他のアプリ - 2026年7月23日 Aurora DSQLの論文がついに公開されました。昨日それを読んだのは興味深い体験でした。なぜなら、私はAurora DSQLを設計・構築したAWSチームと2年間（2022-23年）一緒に仕事をしたからです。アーキテクチャには非常に精通していたため、論文の概要説明にはあまり興奮しませんでした。正直に言うと、論文を読むのは少し退屈に感じました。おそらく、論文のアイデアを探求・理解するために普段行っているような余分な思考をしていないからでしょう。 しかし、今日一歩引いて、私の主観的な経験はさておき、DSQLアーキテクチャが実際には野心的で意見の分かれるエンジニアリング上の賭けのセットの上に構築されているかを説明しようと思います。もし私がこのアーキテクチャを一文で説明するとしたら（AWSの他のチームのためにいつもやっていたように）、それはこうなるでしょう：従来のモノリシックなデータベースを取り、すべてのコンポーネントを独立した、水平スケーラブルなサービスに爆発させました。 モノリスの爆発 DSQLはデータベースを以下の専門化されたサービスに分割します： クエリプロセッサ (QP): クエリを解析し、書き込みをローカルにバッファリングするカスタムPostgreSQLエンジンを実行するステートレス仮想マシン。 ストレージノード: データを保持し、マルチバージョン同時実行制御(MVCC)を使用してQPに履歴データを即座に提供するシャード化されたノード。 アドジュディケーター: QPから渡されたトランザクションがコミット可能かどうかをチェックする競合解決レイヤー。 ジャーナル: ゾーンまたはリージョン全体でトランザクションを永続的に保存する、高可用性レプリケーションログ。（ストレージノードに到達する前の短期間の耐久性に優れています。私のMemoryDBレビューを参照してください。） クロスバー: ジャーナルから更新を読み取り、変更を適切なストレージノードに送信するルーティングレイヤー。 DSQL設計における大きなアーキテクチャ上の賭け さて、非集約化の原則に完全にコミットすることに加えて、DSQL設計におけるその他の大きな賭けは以下の通りです。 同期クロックの賭け: コーディネーションなしで読み取りを行うために、DSQLは完全に同期化された物理クロック、この場合はAWS TimeSyncに依存しています。QPはローカルクロックをチェックし、その正確なマイクロ秒のデータをストレージに要求します。 悲観的ロックなし: 楽観的同時実行制御(OCC)はデータベースで高いアボート率につながる可能性がありますが、DSQLはこれをスナップショット分離下のMVCCとペアにすることで機能させます。リーダーは過去のスナップショットを参照するため、読み書きの競合は不可能です。素晴らしいですが、書き込みスキューはどうでしょうか？ 必要に応じて、顧客はFOR UPDATEを使用し、ビジネスロジック違反のための書き込み-書き込み競合を強制するようにスキーマを設計する必要があります。 最終整合性は死んだ: DSQLは強力な整合性（リニアライザビリティ）を提供し、開発者は最終整合性システム上で正しいビジネスロジックを書くことができないと主張しています。これは微妙な点ですが、リニアライザビリティ（単一オブジェクトのリアルタイム操作に関する保証）とスナップショット分離（複数オブジェクトのトランザクション可視性に関する保証）は異なるものを制御します。Jepsenの整合性モデルが概説しているように、DSQLはスナップショット分離されたトランザクションに対して整合性のあるスナップショットを提供し、個々のキー操作は厳密にリアルタイム順序を尊重します。 ガードレールを強制する: DSQLはトランザクションを3,000行と10MiBにハードキャップします。論文ではリトルズの法則を引用してこれを正当化しており、本質的にユーザーに、予測可能性の高い安定したテールレイテンシと引き換えに、より小さなトランザクションを受け入れることを強制しています。 リニアライズド2PC: 複数のアドジュディケーターにまたがるトランザクションの場合、従来の2相コミット(2PC)は広域ネットワーク上では遅すぎます。なぜなら、2RTTを必要とするからです。DSQLは「Warpにインスパイアされた」トリックを使用しており、アドジュディケーターは投票しますが、リーダーのみが最終コミットを単一のジャーナルに書き込みます。これにより、複数のログのコーディネーションが回避されます。 ペイオフ 独立したスケーラビリティ: コンピュート、コミットロジック、ストレージは完全に分離されています。読み取り容量を増やす必要がある場合は、ストレージノードを追加します。接続のスパイクがある場合は、システムがより多くのQPを起動します。たとえば、アクセスパターンに基づいてアドジュディケーター範囲の配置を再構成するなど、個別にチューニング/最適化することもできます。 0-RTT整合性読み取り: QPがローカルタイムスタンプを割り当て、ストレージが残りを処理するため、データの読み取りにはリーダーとのコーディネーションがゼロで済みます。これは、ストレージノードへのネットワークレイテンシとほぼ同じくらい高速です。OLTP SQLでは、読み取りは書き込みよりもはるかに一般的であるため、これは大きな利点です。ほとんどの書き込み（UPDATEやユニークインデックスを持つINSERTなど）も実際にはまず読み取りです。 1-RTT（または1.5 RTT）コミット: 1行を書き込むか100行を書き込むかに関わらず、コーディネーションはコミット時に一度だけ発生し、コストはわずか1RTT（またはマルチシャードコミットの場合はわずかに増加）です。 「遅いロックホルダー」問題なし: 悲観的ロックがないため、オープンなトランザクション端末を持ってランチに出かけた開発者（論文からの正確な引用）がデータベースをダウンさせることはできません。リーダーはライターをブロックせず、ライターはリーダーをブロックしません。 古いチームを批判するのは難しいですが、トレードオフと論文の欠点を指摘せずに、真のMurat Buffalo（現在はベイエリア？）レビューにはなりません。トランザクション中の長い読み取り-変更-コミット期間のため、DSQLはホットキーでの書き込み-書き込み競合を起こしやすい可能性があります。これは、単一の行に詰め込める連続操作の数を制限します（いずれにせよ、これは悪いアプリケーション設計です）。高い競合下では、トランザクションはアボートしますが、従来のデータベースはそれらをキューイングした可能性があります。2つのリージョンが同じキーに書き込む場合、OCCは一方をアボートし、残念ながらこの競合はコミット時にのみ検出されるため、リトライする必要があることを知る前にWANネットワークレイテンシのペナルティを支払うことになります。 論文は広範な評価、ユーザー採用またはビジネス上の成果に関する定量的データを提供できませんでしたが、外部キー制約と高ローカリティシーケンスに関する摩擦について語る、率直な「教訓」セクションを提供しています。 大規模構築 最後に、やや直感に反するテイクアウェイが1つあります。完全に新しいグローバルプロダクションデータベースの構築は、実際には予想されるほど大変ではありませんでした。 確かに多くの作業はありましたが、チームが軌道に乗ってからは、実行は驚くほどスムーズに感じられました。私はこれを2つの要因に帰します。優れた初期設計と、車輪の再発明を避けるという意図的な選択です。すべてをゼロから構築するのではなく、チームはPostgreSQLエンジンをSQL解析、実行、およびクライアントプロトコルに使用し、そのローカルストレージとトランザクション処理レイヤーは破棄しました。新しいレプリケーションログを構築しませんでした。AWSの既存の内部ジャーナルサービスを使用しました。また、JournalDBや残念ながら名前が付けられたQLDB（Quantum Ledger Database）のような、先行するAWSデータベースプロジェクトからの苦労して得た教訓も備えていました。ツールのほかに、チームのダイナミクスも素晴らしかったです。Marc Brookerは技術的に優秀であり、才能あるプリンシパルエンジニアのチームを率いるという素晴らしい仕事をした。毎週のホワイトボードでの思考セッションはとても楽しかった。基盤となるアーキテクチャが非常によく設計されていたため、実際の開発は、この規模の製品で私が予想するであろうことよりもはるかに容易に感じられました。（しかし、プロジェクトの最後の1年間はチームと一緒にいませんでした！） databases distributed transactions distSQL paper-review リンクを取得 Facebook X Pinterest Email その他のアプリ コメント コメントを投稿 分散システム設計のヒント - 2023年10月2日 これは、40年前にSOSP'83で「コンピュータシステム設計のヒント」という論文を発表したButler Lampsonに謝罪するものです。もちろん、その業績に匹敵すると主張するつもりはありません。単に、分散システム設計に関する私の考えを整理し、他者からのフィードバックを得るために、この投稿を作成できると思っただけです。Lampsonが与えたのと同じ免責事項から始めます。これらのヒントは斬新ではなく、万能のレシピではなく、設計の法則ではなく、正確に定式化されておらず、常に適切であるとは限りません。それらは単なるヒントです。それらは文脈依存であり、一部は