Amazon Web Services ブログ
Amazon Aurora DSQL の裏側：知っておくとおもしろい技術解説 Part 5 – DSQL でのクロック使用
本記事は 2025/11/25 に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 5 – How the service uses clocks を翻訳した記事です。
Amazon Aurora DSQL は、アクティブ-アクティブの分散データベース設計を採用しており、リージョン内およびリージョン間で、すべてのデータベースリソースが等しく読み取りと書き込みの両方のトラフィックを処理します。この設計により、シングルおよびマルチリージョンの Aurora DSQL クラスターにおいて同期データレプリケーションとデータ損失ゼロの自動フェイルオーバーが可能になります。
Aurora DSQL に関する5部構成の本シリーズでは、これまでに基本概念、機能と注意点、Aurora DSQL におけるトランザクションの動作、そして個々のコンポーネントについて説明しました。今回の投稿では、Amazon Aurora DSQL が Amazon Time Sync Service を使用してどのようにハイブリッド論理クロックソリューションを構築しているのかを探ります。
Aurora DSQL がリージョン内およびリージョン間で広範な調整なしにスケーラブルな方法で動作できる能力は、Amazon Time Sync Service の活用とその上に構築されたハイブリッド論理クロックソリューションの構築によるものです。
分散システムにおけるハイブリッド論理クロックの重要性
物理クロックは直感的で私たちの自然な時間認識に合致していますが、分散システムでは同期に課題があります。一方、Lamport タイムスタンプのような論理クロックは因果関係の追跡に優れていますが、実世界のタイミング要件を満たすのに苦労します。
ハイブリッド論理クロック（HLC）は、両方のアプローチの利点を調和させる洗練されたソリューションを提供します。Aurora DSQL では、HLC は次のように動作します：
- システムは物理クロックと論理クロックの両方のコンポーネントを維持します
- クロック値は各読み取り操作の前に更新されます
- 物理クロックがより速いペースで動作する場合（典型的なシナリオ）、論理時間が同期するよう進みます
- 逆に、物理クロックが遅れている場合、論理時間はおおよそ物理クロックのレートで進行します
このハイブリッドアプローチにより、物理的な現実との強い結びつきを維持しながら、時間が後退することがないよう保証されます。CockroachDB や MongoDB などの他の分散データベースも、時間管理のニーズにハイブリッドクロックを採用しており、Aurora DSQL におけるこのアプローチの関連性を示しています。HLC には以下のようないくつかの利点があります：
- 一貫性の保証 – クライアントが複数のデータベースノードからデータを読み取る場合、HLC はデータの一貫したビューを保証します。これにより、Aurora DSQL は同期の必要なく複数のリージョンにあるストレージノードから読み取ることができます。
- トランザクション管理 – 各トランザクションは開始タイムスタンプとコミットタイムスタンプを受け取り、これらの値に基づいて信頼性の高い競合検出を容易にします。
読み取り専用トランザクションの線形化可能性（linearizability）
実際には、クロック同期は完璧ではありません。現代のシステムはこの現実に対処するために洗練されたエラー境界追跡を採用しています。Amazon EC2 の clockbound API からの時間測定には、現在時刻の推定値、上限エラー境界、下限エラー境界が含まれます。これにより 3 つの時間間隔が区別されます：既知の過去（エラー境界以下）、未知の現在（エラー境界内）、そして既知の未来（エラー境界以上）。QP は上限エラー境界を選択することで、ストレージからリクエストするデータにコミット済みのすべてのトランザクションが含まれることを保証します。これが読み取り専用トランザクションが線形化可能である理由です。これにより、オペレーションがシステム内での並列性なしに、一貫したリアルタイム順序で実行されるように見えることが保証されます。
Amazon Aurora DSQL におけるトランザクションタイミングの理解
Aurora DSQL は、トランザクションタイムスタンプの洗練された処理を通じて強力な一貫性保証を提供しています。システムがどのようにトランザクションタイミングを管理して線形化可能性（linearizability）を確保するか ー つまり、トランザクション B がトランザクション A のコミット後に開始される場合、B はつねに A の変更を見ることができるということ ー を探ってみましょう。この概念は読み書きトランザクションのみを対象に探っていきます。なぜなら、このシリーズの第 3 回で説明したように、読み取り専用トランザクションは論理的な時間がゼロであり、このタイプのトランザクションにはこの概念は必要ないからです。
トランザクションが開始されると、QP は未来にあることが保証されている開始タイムスタンプ（τ-start）を割り当てます。トランザクション内のあらゆる読み取りに対して、このタイムスタンプがストレージに渡され、読み取り操作を実行する前にすべての先行トランザクションが処理されていることを確認します。
トランザクションのコミット中：
- アジュディケータがコミットタイムスタンプ（τ-commit）を割り当てます。
- QP は、ユーザーにコミットを確認する前に、このタイムスタンプが検証可能な過去にあることを確認します。
実際の例
2 つの連続するトランザクション、A と B の流れを見てみましょう：
- トランザクション A が開始：
- 開始タイムスタンプ τ3 が割り当てられます
- このトランザクション内のすべてのアクションは、一貫したビューを確保するためにこのタイムスタンプを使用します
- コミット時に、タイムスタンプ τ5 を受け取ります
- システムは、コミットを確認する前に τ5 が検証可能な過去になるまで待機します
- トランザクション B（A のコミット後）が開始：
- A のコミットタイムスタンプより大きいことが保証される開始タイムスタンプが割り当てられます
- これにより B は常にAの変更を見ることができます
システムは、クロックの不確実性がタイミングの異常を引き起こす可能性があるシナリオを慎重に管理する必要があります。例えば、トランザクション A が広いタイムスタンプウィンドウを取得し、トランザクション B がより狭いウィンドウを取得した場合、B が A のコミット後に開始したにもかかわらず、B の開始タイムスタンプが A のものより小さくなるリスクがあります。
このような異常を防ぐため、Aurora DSQLは追加のセーフガードを実装しています：QP は、τ-start と τ-commit のタイムスタンプ境界が過去にあることが検証されるまでクライアントへの応答を遅らせます。
トランザクションタイミングに対するこの堅牢なアプローチにより、Aurora DSQL は分散環境で高いパフォーマンスを維持しながら、強力な一貫性保証を提供することができます。
Amazon Time Sync Service を使用したタイミング情報の提供
分散システムにおける時間同期は、特に複数のリージョンにまたがる場合、非常に複雑な問題として知られています。Aurora DSQL はこの課題に対して、Amazon Time Sync Service を使用することで対処しています。このサービスはすべての EC2 インスタンスからアクセス可能で、GPS 衛星と同期した原子時計を使用してマイクロ秒レベルの精度を実現します。この精度レベルは、グローバルに分散したノード間で強力な一貫性を維持するために不可欠です。論理クロックのみに依存する従来のアプローチやNetwork Time Protocol（NTP）などのプロトコルとは異なり、Aurora DSQL のハイブリッドモデルは因果関係と実世界の整合性の両方を提供します。このイノベーションはトランザクションの整合性を向上させるだけでなく、グローバルな書き込み時のレイテンシーも最小化し、Aurora DSQL を業界内で際立たせています。
ユースケースの可能性
ハイブリッド論理クロックシステムは、複数の業界で Aurora DSQL に新たな可能性をもたらします。例えば、金融機関はトランザクションの保証された線形化可能性の恩恵を受け、正確な監査証跡と規制遵守を確保できます。同様に、複数のリージョンにまたがって運営される e コマースプラットフォームは、一貫した在庫管理とリアルタイムの注文処理のために Aurora DSQL に依存することができます。
まとめ
この投稿では、Amazon Aurora DSQL におけるハイブリッドクロックモデルの活用について探りました。このモデルは Amazon Time Sync Service を活用してグローバルな強力な一貫性を保証しています。Aurora DSQL についてさらに詳しく知りたい場合は、AWS re:Invent 2024 の入門および詳細解説の録画、または Marc Brooker のブログシリーズをご参照ください。