こんにちは、IT 基盤部第4グループの西崎です。主に DeNA がグローバルに展開するゲームのインフラ管理を担当しています。

本記事は以下構成の第3回です。最終回の今回はこれまでの記事を振り返った上で、Aurora DSQL の設計がデータベース技術としてどのように新しいのかを説明します。

1. Aurora DSQL は何が新しいのか？（vs. これまでの Aurora 編）
2. Aurora DSQL は何が新しいのか？（vs. Spanner 編）
3. Aurora DSQL は何が新しいのか？（まとめ + 内部技術編）

第1回：分散 SQL である

第1回ではこれまでの Aurora と比較しました。Aurora DSQL は分散 SQL¹ であるため以下のメリットがあることを、DeNA でのデータベース運用の課題と併せて紹介しました。

• シャーディングが不要になる
• 常に最新のデータを利用できる
• 可用性が上がり、メンテナンス作業も不要になる

第2回：コンポーネント分割が進んでいる + 楽観的排他制御を採用している

第2回では Cloud Spanner（以下 Spanner） との比較を行いました。Aurora DSQL は同じ分散 SQL である Spanner よりもトランザクションに関係するコンポーネントの分割がより細かくなっています。さらに楽観的排他制御を採用しているため、以下のメリットがありました。

• レイテンシが低い
  • 特にマルチリージョン展開や、複数のシャードに跨るデータを更新する場合
• スケール性能に優れる
  • ただし、具体的なメリットは今後の発表を待つ必要がある

第3回（本記事）：Aurora DSQL の新しさを支える技術設計

Aurora DSQL について考える場合、まず気になるのは「結局 Aurora DSQL を使うと何ができるようになるの？」という点だと思います。何よりも自分自身がそのような疑問を持って調べ始めたこともあり、前回までは既存製品との機能比較をアーキテクチャの観点から行いました。

しかしさらに細かく見ると違う景色が見えてきます。Aurora DSQL の技術の多くはこれまでにも存在したものであり、全く新しいというわけではないのです。これは Aurora DSQL の一番新しい部分はまだ発表されていない… ということでもありますが、今回は現在判明している部分について、Aurora DSQL が既存のデータベース技術をどのように利用しており、その結果どのようなメリットを得ているのかを追ってみます。

ただし既存技術への参照については自分の知識と推測に拠る部分が大きく、出典は示しますが正確性や網羅性を保証するものではありません。データベース技術は非常に広く複雑な分野のため、あくまで自分が考えたことを元に新規サービスへの理解を深める趣旨としてご理解ください。

コンポーネント分割 + 楽観的排他制御

メリット：柔軟なスケールができる低レイテンシな分散 SQL になった

前回紹介した Aurora DSQL のコンポーネント分割とトランザクション管理の方式は Apple が開発・公開している FoundationDB とよく似ています（FoundationDB も楽観的排他制御を採用しています）。FoundationDB はそれ自体では Key-Value Store ですが、強いトランザクション整合性を提供し、書き込みを含む各性能が柔軟にスケールします。また追加で layer と呼ばれるソフトウェアを利用することでリレーショナルデータも扱うことができるため、分散 SQL のように利用できる製品です²。

FoundationDB との比較

まず Aurora DSQL の読み取り + 書き込みトランザクションの図を再掲します。

FoundationDB のコンポーネント分割とトランザクション（読み取り + 書き込み）を同様に図にすると以下のように書くことができます³。

• Sequencer
  • FoundationDB 全体でユニークなバージョンを発行します
  • FoundationDB クラスタ全体で１つしかありません
• Proxy
  • トランザクションのバージョンを Sequencer から取得します
  • 書き込みトランザクションの場合、競合するトランザクションがないか Resolver に問い合わせます
  • 競合するトランザクションがない場合、書き込み処理を LogServer に送信します
• Resolver
  • Proxy が発行する書き込み処理がデータの一貫性を壊さないか（競合するトランザクションがないか）をチェックします
• Log Server
  • Proxy が 書き込むデータを受け取って永続化し、非同期で Storage Server にその内容を伝達します
• Storage Server
  • 実データを保存しています

両方を見比べると以下の点が同じであることが分かります。

• コンポーネント（機能）分割の単位
  • ユーザからのリクエストを受け取り、データの読み取りや計算を行う
    • Client / Query Processor
  • トランザクションバージョン情報（タイムスタンプ）の発行
    • Sequencer / Query Processor
  • 競合トランザクションの検知
    • Resolver / Adjudicator
  • 書き込むデータの永続化（Write-Ahead-Log）
    • LogServer / Journal
  • 分散ストレージ
    • StorageServer / Storage
• 楽観的排他制御
  • コミット時に Resolver / Adjudicator で競合検知を行い、競合時は Abort する

FoundationDB の各コンポーネントも（Sequencer などユニークなもの以外は）独立してスケール可能で、そのため Aurora DSQL のように読み取り/書き込みなどの各性能が独立してスケールします。Aurora DSQL も同様のコンポーネント構成と楽観的排他制御を採用することで、スケール性能が高くレイテンシを抑えた分散 SQL の特性を得ています。

また Aurora DSQL ではトランザクションタイムアウトの上限が5分であることを前々回に書きましたが、FoundationDB にもトランザクションタイムアウトが設定されており、その長さは何と5秒です⁴。Aurora DSQL もこの設計に由来する制限があるものの、比較的使いやすくなっていると言えます。

グローバルで正確なタイムスタンプの利用

メリット：マルチリージョン展開ができるようになった

上記の図を見ると FoundationDB の Sequencer 部分が Aurora DSQL では無くなっていることが分かります。これは Aurora DSQL とは異なり、FoundationDB は全体で利用できる正確な（誤差の小さな）タイムスタンプを想定しておらず、それに相当するバージョン情報を Client が Proxy を介して Sequencer という専用のコンポーネントから取得する必要があるためです。Sequencer は FoundationDB クラスタでユニークなバージョンを発行する機構であり、Sequencer 自体もクラスタ内で１つしかありません。

仮に FoundationDB を Aurora DSQL のようなマルチリージョンの active-active 構成にしようとしても、この Sequencer がボトルネックになりレイテンシのトレードオフが発生します。

一方で Aurora DSQL は Query Processor がローカルで正確な（誤差の小さな）タイムスタンプを取得できるようになり、バージョン情報（タイムスタンプ）を特定の場所に取りに行く必要がなくなりました。この修正によって、前回・前々回でも紹介した「Aurora DQL はマルチリージョン構成にした場合でもコミット時まで別リージョンとの通信が発生しない」という特性が実現されています。Aurora DSQL はグローバル規模で正確な（誤差の小さな）タイムスタンプを導入したため、低レイテンシのままマルチリージョン対応できるようになったと言えます。さらに Sequencer に問い合わせるレイテンシが無くなったためさらに高速になったことや、バージョン発行も分散処理されるようになったことでスケール上限のボトルネックが無くなったというメリットも得ています。

グローバルで同期したタイムスタンプは Spanner も利用しており、そのために TrueTime API という仕組みを用意していました。前々回に紹介したように Aurora DSQL はこの機能を Amazon Time Sync Service を利用して実現しています⁵。

ストレージへのプッシュダウン

メリット：リレーショナルデータを高い性能で扱えるようになった

Aurora DSQL の Storage は Query Processor からの読み取り要求にページデータではなく、ある程度計算された後の行データを返すようになりました。これは Storage で選択・結合・射影などのデータ操作がされるということであり、よりデータに近い位置で処理がされるためレイテンシの削減につながります。この改善によって Aurora DSQL は(FoundationDB のような) Key-Value Store を RDB 的に利用するよりも高い性能を実現できると明言されているほか、単にページデータを返す方式と比べてもコンピュート機能の迅速なスケールが可能になりました（Query Processor 上でページデータのキャッシュを持たなくなり、Query Processor 間での同期も不要になるため）⁶。

データ処理をできるだけストレージ側で行うことで効率を上げることは分散 SQL ではよく利用される技術です。Spanner も従来の Key-Value Store 的なストレージ実装から、よりリレーショナルなデータに合ったストレージ実装に改善すると同時に、クエリ処理も各データを持つサーバ上で選択や射影などの処理を並列で行った結果を別レイヤでまとめる処理に変わったという経緯があります⁷。

一方でこの改善は Amazon Aurora らしいとも言えます。Amazon Aurora ではクラウド環境に最適化するため、大規模分散環境でボトルネックになりやすいネットワークの使用量を抑えるために Amazon Aurora ストレージが開発されました⁸。今回の Storage へのプッシュダウンはストレージからコンピュート側へのデータをさらに削減するという点でこの延長上にあるとも言え、リレーショナルなデータを分散環境で扱うための好例として非常に興味深いです。

様々な AWS の内部技術

メリット：開発効率が上がり、Aurora DSQL 自体の性能と信頼性も高まった

Aurora DSQL は AWS 社内の様々な技術を再利用しています⁹。

Query Processor には PostgreSQL エンジンの入った Firecracker MicroVM が利用されていますが、これは AWS Lambda や AWS Fargate で開発・利用されているものです。その他にも、Caspian （仮想サーバのリソースを動的に増減させる仕組み。Aurora Serverless v2 にも利用されている）や Lambda SnapStart に利用されているスナップショット技術などの仮想化技術も活用されています。

その他、Journal 自体も AWS 内部で利用されていた分散トランザクションログの仕組みであり、Aurora DSQL の開発には AWS 社内で利用されている形式手法や自動推論を利用して効率的に行われました。このような実績ある技術の再利用によって、高性能で信頼性の高いシステムが構築されています。

まとめ：高速なグローバル分散 SQL として設計されていることが新しい

このような技術とメリットが組み合わされることで、Aurora DSQL という「高速でスケール性能の高いグローバル分散 SQL」が生まれました。

• コンポーネント分割 + 楽観的排他制御
  • 柔軟なスケールができる低レイテンシな分散 SQL になった
• グローバルで正確なタイムスタンプの利用
  • マルチリージョン展開ができるようになった
  • バージョン取得によるレイテンシとスケール上限も撤廃された
• ストレージへのプッシュダウン
  • リレーショナルデータを高い性能で扱えるようになった
• 様々な AWS の内部技術
  • 開発効率が上がり、Aurora DSQL 自体の性能と信頼性も高まった

今後新規技術も含めてさらなる情報が明らかになるものと思いますが、Aurora DSQL が AWS 社内外の様々な技術を結集して作られていることは非常に興味深く、学びが多いことではないでしょうか。

また、このように見ると Aurora DSQL はリレーショナルデータをマルチリージョンで、かつそれぞれのリージョンからのレイテンシが最小になる形で利用できるよう最適化された分散 SQL と見ることができます。実際、本連載の主な情報源とした Aurora DSQL 開発者のブログでも、これまでの顧客からそのような分散 SQL が特に求められていた背景があり、まさにその目的を果たすよう Aurora DSQL が設計されたことが書かれています¹⁰。

最後に：Aurora DSQL をどう捉えるか

全3回で Aurora DSQL について紹介しました。ちょうど業務でデータベースについて調べる機会があり、その最中に Aurora DSQL の発表があったためよい機会だと思い筆を執りました。自分にとって初めての技術ブログであり非常に大変でしたが、一旦全て執筆することができて安心しています。

最後に個人的な所感になりますが、 AWS が Aurora の分散 SQL 製品を、楽観的排他制御と小さく競合の少ないトランザクションを前提とした方式で開発したこと自体がとても興味深いです。これはマルチリージョンでも低レイテンシで利用できるようにするためというのが本連載の結論ですが、プレビュー製品でまだまだ分からない部分が多く、今後の開発方針（トランザクションタイムアウトは緩和されるのか、悲観的排他制御が必要なケースは完全にこれまでの Aurora に任せる方針なのか？）も非常に気になります。

新製品をどのように理解し今後の展開を占うかという点は、興味深いだけではなく実際の技術選定に影響を与える可能性もあります。DeNA のように大規模かつ長期間にわたってデータベースを利用する場合、その選択にはゲームタイトルなどプロジェクトそのものの命運が掛かってきます。そこで得たノウハウは今後も社内で再利用されるため、今後の採用技術やチーム戦略にも影響を与えます。AWS のサービスを利用する場合はその提供の有無、コスト、今後の開発方針に依存することになるため、AWS がそのサービスをどう位置付けており、今後どのように開発する方針で、それが DeNA の使い方に沿っているのか、というのも判断材料となる重要な情報です。

Aurora DSQL はまだプレビュー機能ですが、新しい技術に対しても既存の技術をベースに比較ができることは紹介できたと思います。システムの種類や規模にかかわらず、またクラウドサービスが前提になった環境でも、利用する技術を理解して使い分けることは常に重要です。IT 基盤部ではこれからも様々な技術に対して、調査と検証を実施していきます。