Aurora DSQLとは何か——仕組みと、本当に自社に合うのかを見極める

Aurora DSQLはどう動くのか

Aurora DSQLの強みは、データベースの構成要素を独立した複数のスケーラブルなサービスへと分解（disaggregate）した革新的な設計にあります。最新のクラウドネットワークが持つ圧倒的な速度と帯域幅、そして分散アーキテクチャを組み合わせることで、スケーラビリティ、パフォーマンス、整合性のバランスを両立しています。まずは、Aurora DSQLを構成する5つのコンポーネントを示すアーキテクチャ全体図から見ていきましょう。

分解型アーキテクチャ

Aurora DSQLは、クエリ実行・トランザクション管理・ストレージを、それぞれ専用のサービスに分離しています。

• クエリ実行層：SQLクエリを並列実行し、需要の増加に応じて水平スケールします。
• トランザクション管理層：楽観的ロックなどの手法を用いて分散トランザクションを調整し、整合性を担保します。
• ストレージ層：シェアードナッシング型の分散システムで、複数ノードにデータを複製して耐久性と耐障害性を確保します。

各サービスはそれぞれ独立してスケールできるよう設計されており、負荷の異なるworkloadsもボトルネックなく処理できます。

トランザクションを分離するMicroVM

Aurora DSQLは、トランザクションごとに専用のmicroVMを立ち上げて実行し、完全な分離を実現します。これにより、トランザクション間の競合が解消され、特に次のような効果が得られます。

• 読み取り中心のworkloads：読み取り処理ではロックもundoログも発生しないため、軽量かつ高速です。
• 並行トランザクション：複数のトランザクションが互いに干渉せず同時に実行でき、高い並行性を発揮します。

楽観的ロック

Aurora DSQLのトランザクションモデルは楽観的ロックを採用しています。

• 競合はほとんど発生しないという前提に立ち、コミット時にのみ競合をチェックします。
• 競合が検出された場合（例：別のトランザクションが同じデータを更新済みの場合）はトランザクションが失敗するため、アプリケーション側でリトライ処理を行う必要があります。

楽観的ロックは書き込み競合の少ないworkloadsで最も効果を発揮しますが、競合が多いシナリオではしっかりとしたリトライロジックが欠かせません。

AdjudicatorとJournal

Aurora DSQLの整合性と耐久性を支える主要コンポーネントは次のとおりです。

• Adjudicator：トランザクションのコミット順序をグローバルに一貫させ、競合を解消して強整合性を維持します。
• Journal：トランザクションの変更内容を記録する分散ログ。耐久性を確保し、障害からの復旧を可能にします。

Aurora DSQLと相性の良いデータパターンは？

Aurora DSQLは、分散・分解型という特性に合致したデータパターンで真価を発揮します。ここでは特に相性の良いパターンと、自社のworkloadsで見極めるためのポイントを詳しく見ていきます。

1. 高並行性のworkloads

Aurora DSQLは、同時アクセスするユーザーやプロセスが多いアプリケーションに最適です。たとえば次のようなケースが挙げられます。

• ECプラットフォーム：在庫更新、購入、ユーザー行動など同時多発的なトランザクションを処理。
• ソーシャルメディアアプリ：数百万人規模のアクティブユーザーによる「いいね」、コメント、各種アクションを管理。
• SaaSアプリケーション：同一のデータベース基盤を共有しつつ、テナントごとにworkloadsを分離して提供。

自社のworkloadsがこのパターンに該当するかを判断するポイントは次のとおりです。

• 同時接続ユーザー数のピークとクエリの稼働状況を確認する。
• 競合（例：複数プロセスが同じデータに書き込む状況）が、楽観的ロックで対応可能な範囲かを分析する。

2. 読み取り中心のアプリケーション

Aurora DSQLでは読み取り処理がロックやundoの生成を伴わないため、読み取り中心のworkloadsで非常に高い性能を発揮します。たとえば次のような例があります。

• ダッシュボードと分析：リアルタイムデータの更新頻度より閲覧頻度が高いアプリケーション。
• コンテンツ配信プラットフォーム：ユーザーが主にコンテンツを消費するストリーミングやニュースアプリ。

読み取りと書き込みの比率を評価するには次の方法が有効です。

• クエリログを監視し、全体に占める読み取り操作の割合を把握する。
• Auroraのパフォーマンスインサイトやデータベース監視ツールを使い、読み取りクエリのレイテンシとスループットを計測する。

3. 地理的に分散したデータアクセス

Aurora DSQLは分散型のアーキテクチャゆえに、グローバルなユーザーベースを抱えるアプリケーションにも適しています。

• ゲーミングプラットフォーム：異なるリージョンのプレイヤーがリアルタイムで対戦するマルチプレイヤーゲーム。
• コラボレーションツール：大陸をまたぐ低レイテンシなアクセスが求められるドキュメント共有・チャットアプリ。

このパターンを見極めるには次の観点が役立ちます。

• ユーザー分布を地理的にマッピングし、レイテンシに敏感なクエリが複数リージョンから発生しているかを確認する。
• 集中型データベース構成が、遠隔地のユーザーにレイテンシ上の問題を引き起こしていないかを評価する。

4. 書き込み競合の少ないworkloads

Aurora DSQLの楽観的ロックは、書き込み競合が少ない状況で真価を発揮します。具体的には次のようなケースです。

• パーティション化されたデータ：ユーザー単位やテナント単位の更新など、書き込みが特定のパーティションに自然に分離されるアプリケーション。
• イベントログ：イベントが重複なく独立して書き込まれるシステム。

自社のworkloadsが該当するかを確認するには次のステップが有効です。

• 書き込み処理を分析し、同じ行やオブジェクトに集中していないかを確認する。
• スキーマに自然なパーティショニングの余地がないかを点検する（例：ユーザーIDやテナント単位でのシャーディング）。

5. トランザクション処理と分析処理のハイブリッド（HTAP）

トランザクション処理と分析クエリが混在するアプリケーションは、両workloadsを効率的に処理できるAurora DSQLの強みを活かせます。

• 金融ダッシュボード：リアルタイムのトランザクション更新と、分析サマリーを同一画面で扱うケース。
• 在庫管理システム：運用上の更新を行いながら、在庫状況をリアルタイムに可視化するケース。

このパターンに当てはまるかを確認するポイントは次のとおりです。

• リアルタイム更新と分析クエリの両方を伴うworkloadsを洗い出す。
• 長時間にわたる分析クエリを、Aurora DSQLの5分間のクエリタイムアウト内に収まるよう最適化できるかを確認する。