Amazon Aurora DSQL の裏側：知っておくとおもしろい技術解説 Part 3 トランザクション処理

本記事は 2025/11/25に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 3 – Transaction processing を翻訳した記事です。

Amazon Aurora DSQLは、アクティブ-アクティブの分散データベース設計を採用しており、すべてのデータベースリソースが対等であり、リージョン内およびリージョン間の読み取りと書き込みトラフィックの両方に対応します。この設計により、同期データレプリケーションと、単一および複数リージョンのAurora DSQLクラスターに対する自動的なゼロデータ損失フェイルオーバーが可能になります。

このシリーズの3番目の投稿では、Aurora DSQLの2種類のトランザクションタイプ（読み取り専用と読み書き）のエンドツーエンド処理について検証します。Amazon Aurora DSQLには書き込み専用トランザクションはありません。なぜなら、各変更においてテーブルスキーマの確認や主キーの一意性を確保することが不可欠であり、その結果としてこれらも読み書きトランザクションとなるからです。

読み取り専用トランザクション

以下は、読み取り専用トランザクションのデータ処理ワークフローを示すシステムアーキテクチャ図です。

トランザクションフローの異なるフェーズをより深く理解するために、トランザクション開始から始まる複数のステップに分けて説明します。

1. トランザクション開始: トランザクションプロセスは、クライアントが`START TRANSACTION`または`BEGIN`コマンドを発行することから始まります。フロントエンドは専用のクエリプロセッサ（QP）を割り当てます。このQPは、トランザクションのクエリを解析、計画、実行する専用のマイクロ仮想マシン（VM）です。各トランザクションには独自のQPが割り当てられます。この分離は、各トランザクションが他の同時実行トランザクションからの干渉なく独立して動作することを保証するため重要です。ステートメントを実行する前に、QPはAmazon Time Sync Serviceを使用して同期された現在時刻を読み取り、トランザクション開始時間τ-startを割り当てます。このタイムスタンプは、トランザクション全体の基準点となり、Auroraの分散アーキテクチャ全体での一貫性維持に重要な役割を果たします。
2. クエリ実行: 初期化後、QPはSQLステートメントの包括的な解析を実行することでその主要機能を開始します。このフェーズでは、クエリの構文と意味の両方の正確さを検証し、実行計画を作成します。ストレージからデータを読み取るために、QPはシャードマップを参照して、ストレージノード全体で必要なデータの正確な位置を特定します。
3. ストレージノードからのデータ取得: ストレージノードがリクエストを受信すると、各ノードは重要な事前取得チェックを実行します。これらのチェックにより、τ-start以前のタイムスタンプを持つすべてのトランザクションが完全に処理されていることを確認します。必要に応じて、ノードは一貫性保証を維持するための待機メカニズムを実装します。ストレージノードはτ-startタイムスタンプに基づくスナップショット分離を採用しています。このメカニズムにより、すべてのノードがトランザクション開始時点でのデータの一貫したビューを提供することが保証されます。このアプローチは、同時実行トランザクションから生じる可能性のある異常を効果的に防止します。その後、ストレージノードは要求されたデータを返します。データを取得した後、QPは複数のノードからの結果を集約します。Aurora DSQLのアーキテクチャはインタラクティブなトランザクションをサポートし、同じトランザクションコンテキスト内で複数のクエリを実行できるため、単一のトランザクション内でクエリプロセスを複数回繰り返すことができます。システムは、セッション全体を通じて一貫したトランザクション状態を維持し、複数の操作全体で分離保証を保持します。
4. トランザクションのコミット: 読み取り専用トランザクションでは、Aurora DSQLはコミット時間（τ-commit）をトランザクション開始時間（τ-start）に設定するユニークなコミットメカニズムを実装しています。これにより、論理的な観点からは実質的にゼロ期間のトランザクションが作成され、読み取り専用トランザクションが常に一貫したスナップショットを参照し、競合による失敗が発生しないことが保証されます。

読み取り書き込みトランザクション

以下は、Aurora DSQL内のデータ処理ワークフローを示すシステムアーキテクチャ図です。

1. トランザクション開始: 読み書きトランザクションの初期フェーズは、読み取り専用トランザクションと同様です。
2. クエリ実行と書き込み処理: 実行フェーズでは、QPは読み取り専用トランザクションと同様の方法でSQLステートメントを処理します。ただし、読み書きトランザクションでは、変更の処理に追加の複雑さが生じます。書き込み操作が発生すると、QPはこれらのデータベース変更の結果をローカルに保存し、トランザクションの期間中、効果的に書き込みをスプールします。ロールバックや切断が発生した場合、QPはスプールされた書き込みを破棄します。内部的には、Amazon Aurora DSQLでのトランザクションの実行は、同時実行メカニズムに基づいて最適化されています。使用されるMVCCの実装により、早期中止（この概念の詳細は論文MVCCトランザクション間の競合の修復の章3.3.1 書き込み-書き込み競合の処理で確認できます）が可能になり、コミット時に失敗する可能性のある読み書きトランザクションに対応します。QPがストレージから読み取る際、ストレージはデータの最新バージョンを参照しているかどうかを示します。トランザクションがすでに新しいバージョンを持つ行を更新しようとすると、トランザクションは即座に中止されます。
3. コミット処理: コミット時に、QPはシャードマップを参照して、変更したキーを所有するアジュディケータを特定します。QPは書き込みセットを構築し、書き込んだ行（新しく作成された行を含む場合もあります）を含め、それらをポストイメージとともにパッケージ化してアジュディケータに送信します。最後に、この完全な書き込みセットを指定されたアジュディケータに送信します。
4. 裁定フェーズ: 各アジュディケータは、トランザクションの開始時間（τ-start）以降に変更された行に書き込みが発生したかどうかを検証します。いずれかのアジュディケータによって競合が検出された場合、コミットは拒否されます。競合が検出されない場合、アジュディケータはコミットフェーズ中に影響を受ける行に対してロックを配置し、排他的アクセスを確保します。これらのロックは、現在のトランザクションが完了するまで他のトランザクションが同じデータを変更することを防止し、コミットされる更新の整合性を保護します。さらに、アジュディケータはτ-startを超え、以前に発行されたτ-commit値よりも大きいコミットタイムスタンプ（τ-commit）を選択します。ポストイメージとタイムスタンプはジャーナルに書き込まれます。ジャーナルがこれらの変更を確認した後、QPはクライアントにそれらを確認応答します。クライアントの観点からはトランザクションは終了しています。DSQLの観点からは、その内容をストレージノードに書き込む必要があります。
5. ストレージ更新フェーズ: クロスバーコンポーネントはジャーナルからトランザクションの書き込みを受け取り、キースペースの購読部分に基づいて関連する行を適切なストレージノードに転送します。これらのストレージノードはその後、変更を永続化します。

コミットフェーズの動作

データベース内のキースペースはシャード化され、アジュディケータ間で分散されており、アジュディケータの数はキースペースのサイズに比例してスケールします。その結果、各キーはグローバルに見て正確に1つのアジュディケータによって所有されています。読み書きトランザクションのコミット中、各アジュディケータは自身のキースペースがコミット可能かどうかを独立して判断し、その後、同じトランザクションに関与する他のアジュディケータと連携します。ジャーナルへのコミットの書き込みにより、コミットは成功し、永続的に保存されます。逆に、コミットが失敗した場合、関与するすべてのアジュディケータは中止する必要があります。

コミットアルゴリズムについて、このサービスは2フェーズコミットとワープスタイルコミットのハイブリッドアプローチを使用して、不要な往復時間を最小化しています。これは以下の図に示されています：

Aurora DSQLでトランザクションをコミットすると、舞台裏では次のようなことが起こります：

1. QPがトランザクションを担当し、変更されるデータに基づいて、どのアジュディケータが関与する必要があるかを決定します。
2. 次に、関与するアジュディケータのうち1つを除くすべてに対して並行してPREPAREメッセージを送信します。これらのアジュディケータはトランザクションをコミットできるかどうかを確認し、指定された最終アジュディケータに応答を送信します。
3. 最終アジュディケータは意思決定者として機能します：QPからのトランザクションデータと他のアジュディケータからの応答の両方を受け取ります。関与するすべてのアジュディケータによって競合が検出されなかった場合、トランザクションをコミットします。いずれかのアジュディケータが問題を報告した場合、トランザクションを中止し、全員に通知します。

このプロセスは効率的に設計されています – データは一度送信され、応答はシステムを通じて流れ、コミットの決定とリージョン間のデータレプリケーションの両方を1回のパスで処理します。この連携アプローチにより、分散トランザクションはシステム全体で一貫性を維持しながら、不要な往復通信を最小限に抑えることができます。

Amazon Aurora DSQL での SELECT FOR UPDATE の動作

SELECT FOR UPDATEはAmazon Aurora DSQLにおける特殊なSQLステートメントです。読み書きトランザクションでは、Aurora DSQLが読み取りレコードに対して同時実行チェックを実行しないため、書き込みスキューを管理するためにSELECT FOR UPDATEを利用できます。詳細、例、これらのクエリの処理方法については、Amazon Aurora DSQLにおける同時実行制御をご覧ください。

まとめ

この投稿では、Amazon Aurora DSQL内のトランザクション管理の複雑さについて探求しました。コミット処理の内部メカニズムを調査しました。次回の投稿では、Aurora DSQLを構成するコンポーネント（QP、アジュディケータ、ジャーナル、クロスバー、ストレージ）について包括的な分析を提供します。

著者について

翻訳はクラウドサポートエンジニアの新巻が担当しました。原文はこちらです。