Amazon Web Services ブログ
Amazon Aurora DSQL の裏側：知っておくとおもしろい技術解説 Part 1 – 背景説明
本記事は 2025/11/25に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 1 – Setting the scene を翻訳した記事です。
2014年に発表された Amazon Aurora は、高性能な商用データベースのスピードと可用性、オープンソースデータベースのシンプルさとコスト効率を組み合わせたリレーショナルデータベースエンジンで、MySQL と PostgreSQL との互換性や強化されたパフォーマンスを提供しています。re:Invent 2024 において、AWS はさらに顧客中心のイノベーションを進め、Amazon Aurora DSQL を発表しました—これはクラウドベースの設計でトランザクション処理に最適化された新しいサーバーレス SQL データベースです。このブログ投稿シリーズでは、Aurora DSQL の技術的詳細を共有し、基盤となるコンポーネントとサービス開発全体で行われた設計上の選択について深く掘り下げていきます。
この投稿では、Aurora DSQL のメリット、機能セット、および基盤となるコンポーネントを理解するために重要な基本概念について詳しく説明します。
Amazon Aurora DSQL は、マルチリージョン、アクティブ-アクティブ、分散データベースエンジンを実装し、データベースクラスターのすべてのリージョンで読み取りと書き込みのワークロードの両方を容易にします。このサービスはサーバーレスかつ PostgreSQL 互換 であり、その機能のサブセットを提供しています。あなたが消費するリソースと保存するデータの量に応じて課金されます。
クラウドにおける可用性と耐久性
クラウドサービスは、確実性、パフォーマンス、そして信頼性を確保するために、可用性と耐久性といった重要な指標に依存しています。可用性とは、システムやデータへのアクセスのしやすさを指し、多くの場合、稼働率の割合として測定されます。例えば、可用性が 99.99% のデータベースは、年間のダウンタイムが1時間未満となります。耐久性は、データの損失や破損なしに長期的なデータ保存を保証します。Amazon Web Services (AWS) では、顧客がインフラストラクチャ管理ではなくイノベーションに集中できるよう、サービスは高可用性と高耐久性を念頭に置いて設計されています。Aurora DSQL は、マルチリージョン構成で 99.999% の可用性を持つサービスレベルアグリーメント（SLA）を提供し、これは年間5分16秒の許容ダウンタイムに相当します。また、複数のリージョンにデータを保存することでデータの耐久性を提供し、コミットが成功した後にデータが失われないことを保証します。
可用性と耐久性はクラウドサービスにとって不可欠ですが、最適なパフォーマンスを得るためには、データベースが処理するように設計された特定のワークロードのタイプを理解することも同様に重要です。これにより、オンライントランザクション処理（OLTP）とオンライン分析処理（OLAP）システムの違いについて考える必要があります。
OLTP と OLAP
OLTP は、高速なクエリ処理による大量の日常的なトランザクション処理に優れています。例えば、顧客の注文を処理する e コマースプラットフォームは、通常 OLTP データベースに依存しています。対照的に、OLAP は複雑なクエリとデータ分析に最適化されており、チームが膨大なデータセットを分析して実用的な洞察を導き出すビジネスインテリジェンス（BI）アプリケーションに理想的です。Aurora DSQL は OLTP ワークロード向けに設計されています。
可用性と耐久性というこれらの基本的な指標を超えて、データベースシステムの成功は、特に OLTP と OLAP の操作観点から、特定のタイプのワークロードをどれだけうまく処理できるかにも大きく依存しています。
ACID
原子性、一貫性、独立性、永続性（ACID）は、データベースがトランザクションにおけるデータの整合性と信頼性を維持するために必要な一連の特性です。
- 原子性（Atomicity）は、トランザクションが単一の単位として扱われ、完全に成功するか失敗するかのいずれかになることを保証します。
- 一貫性（Consistency）は、トランザクションがデータベースを一つの有効な状態から別の有効な状態へ移行させることを意味します。この概念は、書き込み後の読み取り整合性などの他の一貫性モデルとは異なります。後者では「一貫性」とは、クライアントが書き込んだデータを読み取ることへの期待を指し、データベースの状態自体を指すものではありません。
- 独立性（Isolation）は、並行トランザクションが逐次実行と同じ効果を持つことを保証します。
- 永続性（Durability）は、コミットされた変更が失われないことを保証します。
Aurora DSQL はインタラクティブな ACID 準拠のトランザクションを提供します。「インタラクティブ」とは、トランザクションを開始し、データを要求、取得し、追加のコードを実行できることを意味します。これらの原則、特に独立性の実装には、高度な同時実行制御メカニズムが必要です。
トランザクション分離レベル
トランザクション分離レベルは、1つのトランザクションによって行われた変更が他のトランザクションにどのように見えるかを定義します。標準的な分離レベルには以下が含まれます：
- Read uncommitted – トランザクションがまだコミットされていないデータを読み取ることを許可します。
- Read committed – トランザクションがコミットされたデータのみを読み取ることを保証しますが、ノンリピータブルリードやファントムリードの可能性があります。ファントムリードは、トランザクションが特定の条件に基づいて行のセットを取得したが、トランザクションが完了する前に、別のトランザクションがその条件に影響する行を挿入または削除した場合に発生します。例えば、トランザクション A が今日の注文をすべてカウントするクエリを実行し、その後トランザクション B が新しい注文を追加してコミットした場合、トランザクション A がカウントクエリを再度実行すると、この新しい「ファントム」行が表示されます。
- Repeatable read – トランザクションが行を読み取ると、同じトランザクション内の後続の読み取りで同じデータを取得することを保証し、ノンリピータブルリードを防止しますが、ファントムリードは依然として許可されます。これは、個々の行にロックをかけますが、新しい行が挿入される可能性のある「ギャップ」をロックしないためです。
- Snapshot isolation – トランザクションに対して、トランザクション開始時点のデータベースの一貫したスナップショットを表示することを許可し、完全な直列化のオーバーヘッドなしに、ダーティリード、ノンリピータブルリード、およびファントムリードを防止します。その背後にある概念は、トランザクション T の開始時間とコミット時間の間にタイムスタンプを持つ T の書き込みセットに書き込みが受け入れられていない場合、トランザクション T はコミットするというものです。言い換えれば、現在のトランザクションが書き込もうとしている行に変更が加えられている場合、トランザクションは中止されます。
- Serializable – トランザクションを一つずつ実行することで最高の分離レベルを提供し、ダーティリード、ノンリピータブルリード、およびファントムリードを防止します。その背後にある概念は、トランザクション T の開始時間とコミット時間の間にタイムスタンプを持つ T の読み取りセットに書き込みが受け入れられていない場合、トランザクション T はコミットするというものです。言い換えれば、現在のトランザクションが読み取っている行が変更されている場合、トランザクションは中止されます。
Amazon Aurora DSQL は snapshot isolation レベルで動作しており、トランザクションタイプレベルでの説明は後のブログ記事で説明します。
同時実行制御
現代のデータベースはしばしば、より洗練された同時実行制御メカニズムを実装しており、マルチバージョン同時実行制御（MVCC）は最も広く採用されているソリューションの1つです。
MVCC はデータベースにおいて、データへの同時アクセスと変更を管理するために使用される技術です。MVCC はデータの異なるバージョンを作成することでロックの必要性を減らし、読み取り側と書き込み側が互いにブロックすることなく同時に操作できるようにします。PostgreSQL では、各行の複数のバージョンを維持することでこれを実現しており、各バージョンには作成（xmin）と削除または更新（xmax）を担当するトランザクションを記録する隠しシステムカラムが含まれています。トランザクションがデータを更新すると、元のバージョンを保持しながら行の新しいバージョンを作成します。これは、古いバージョンに xmax 値をマークし、新しい行は新しい xmin（古いバージョンのxmaxと一致）を取得し、この新しいエントリには xmax 値が設定されないことで行われます。他のトランザクションがデータを読み取る際、これらのトランザクション ID によって決定される開始時に有効だったバージョンを表示し、進行中のトランザクションによって行われた変更は無視されます。これにより、ブロックなしで同時に読み取りと書き込みが可能になり、バックグラウンドプロセスが最終的にどのトランザクションからもアクセスできなくなった古いバージョンの行を削除します。
Amazon Aurora DSQL も MVCC を使用しており、データベース内に複数のデータバージョンを格納することを意味します。
MVCC の実装では、データベースは同時変更を処理するために、悲観的ロックスキームと楽観的ロックスキームという異なる高レベルのアプローチを採用しています：悲観的同時実行制御は、競合を防ぐためにリソースを事前にロックし、現在のトランザクション内ですでに変更またはロックされたデータを同時実行トランザクションによって変更できないようにします。しかし、このアプローチは過剰なリソースロックによりパフォーマンスのボトルネックを引き起こす可能性があります。対照的に、楽観的同時実行制御は競合が稀であると仮定し、トランザクションコミット時にそれらをチェックします。これは3つのフェーズで構成されます：
- クライアントからのすべての SQL 文が処理され、すべての書き込みはトランザクション内でローカルに記録されます。
- クライアントのコミット時に、データベースはトランザクションの読み取りと変更を評価して、コミット能力を判断します。2つの検証方法が可能です：前方検証と後方検証。
- 前方検証は、現在進行中のトランザクションとの競合をチェックします。
- 後方検証は、以前にコミットされたトランザクションとの競合をチェックします。
- その後、変更はストレージに書き込まれます。競合が検出されなければ、変更はストレージに書き込まれ、そうでなければ中止されます
Amazon Aurora DSQL と標準 PostgreSQL はどちらも MVCC を使用していますが、ロックに対するアプローチが異なります。Amazon Aurora DSQL は後方検証による楽観的同時実行制御を採用しているのに対し、標準 PostgreSQL は悲観的アプローチを使用しています。
まとめ
この投稿では、基本的なデータベース概念と Amazon Aurora DSQL への適用について探索し、サービスの予備的な概要を提供しました。Aurora DSQL はマルチリージョン構成で 99.999% の可用性を持つサービスレベルアグリーメント（SLA）を提供し、インタラクティブな ACID 準拠のトランザクションを提供し、楽観的同時実行制御を伴う MVCC を使用しながら snapshot isolation レベルで動作しています。このシリーズの次の投稿では、サービス自体の包括的な理解、その利点と制限、および基盤となるアーキテクチャについて説明します。