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

今回は昨年末の AWS re:Invent で発表された Amazon Aurora DSQL（以下 Aurora DSQL）について紹介します。ちょうど最近データベースについて調べていたのですが、その最中に AWS re:Invent 2024 での Aurora DSQL の発表を見て、Aurora DSQL がこれまでのデータベースとなぜ、どのように違うのかを知っておくことが非常に重要だと感じました。

近年は伝統的なリレーショナルデータベース（以下 RDB）だけ知っておけば良いという時代ではなく、NoSQL や分散 SQL など様々なデータベース製品が存在しており、それらを適切に使い分ける必要があります。特に DeNA のように大規模に利用する場合、適切なデータベースを適切な方法で利用することはサービスの継続や運用コストに関わる必須事項です。Aurora DSQL も Cloud Spanner（以下 Spanner）を始めこれまでのデータベースにはない特徴を持っており、その性質を理解して選定することが今後重要になるでしょう。

今回は Aurora DSQL の特徴と仕組みを以下の3回に分けて紹介します。RDB を触ったことがある方向けに、主にアーキテクチャの違いと Aurora DSQL のメリットについて説明します。新製品である Aurora DSQL の「新しさ」に焦点を当てていますので、網羅的な比較ではないことにご注意ください。

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

本記事は第1回目の「Aurora DSQL は何が新しいのか？（vs. これまでの Aurora 編）」です。記事の結論を先に書いておくと、Aurora DSQL は分散システム化することで、大規模な利用でもユーザ側の管理が不要になった Aurora データベースです。

これまでの Aurora

はじめに、これまでの Aurora について見ていきます。

コンピュートとストレージが分離した設計

伝統的な RDB（MySQL, PostgreSQL などを念頭に置いています）は、基本的に一つのサーバ（マシン）上に一つのデータベースが動いています。この構成はシンプルですが、ストレージが壊れると全体が停止します。また RDB が乗っているサーバを超える性能を出すことはできないため、性能を上げるにはサーバの性能そのものを上げる（スケールアップ）か、ユーザ側で複数のサーバを組み合わせる（レプリケーションや、以下で紹介するシャーディングなど）しかありません。

対して Aurora はコンピュート機能とストレージ機能が分離した設計となっています。 アーキテクチャを見ると、ストレージが一つの大きな分散ストレージに分離しており、ライター用・リーダー用に分かれたコンピュート部分はこのストレージを共通で使っていることが分かります。

この共通分散ストレージが Amazon Aurora ストレージ です。

このため Aurora はストレージが自動でスケールするほか、データ複製やストレージ障害からの復旧も全て自動で行います。コンピュート部分はストレージを持つ必要がなく、フェイルオーバー時もデータ復旧が不要となるため可用性も高いです。読み取り性能はリーダーインスタンスの追加で対応できるほか、少し細かい点では従来型の RDB よりスループットが高いという特性もあります。これは Amazon Aurora ストレージはライターインスタンスから redo log のみを受け取って自身の中でページデータへの適用やレプリケーションを分散実行するので、ページデータの flush が必要ないためです。

Aurora DSQL は何が新しいのか

これまでの Aurora と比べて、Aurora DSQL はどのように変わったのでしょうか？

書き込みも分散処理される設計

これが Aurora DSQL の概要図です。以下に各機能の概要も記載していますが、大まかには左側から来たユーザからの更新リクエストの内容が右側の Storage に反映される経路を表しています。

注目したいのはこれまでの Aurora ではライターインスタンスのみが担っていた書き込み処理が、Query Processor と Adjudicator というものに分割されたことで、書き込みも分散処理されるようになったことです。

• Query Processor
  • PostgreSQL エンジンが入っているコンピュート部分です
  • ユーザからのリクエストを受けて書き込み・読み取り処理を実行します
• Adjudicator
  • Query Processor が発行した書き込み処理がデータの一貫性を壊さないか（競合するトランザクションがないか）をチェックします
• Journal
  • 書き込むデータを受け取って永続化し、非同期で Storage にその内容を伝達します
• Storage
  • 実データを保存しています

このような設計によって、Aurora DSQL には以下のメリットがあります。

メリット1：シャーディングが不要になる

Aurora DSQL は書き込みも分散処理されるようになったことで柔軟なスケールが可能になりました。

これまでの Aurora では書き込み処理はライターインスタンスのみが担っていたため、書き込み性能のスケールにはフェイルオーバーが必要になり、短いダウンタイムが発生していました。またライターインスタンスのインスタンスクラスを最大にしても書き込み性能が不足する場合は、複数の Aurora クラスターにデータを分散して保存・処理するシャーディングが必要でした¹。

DeNA でもフェイルオーバーやシャーディングを利用していますが、シャーディングの管理はとても大きな運用負荷が掛かります。実装するだけでもスキーマやテーブル設計を正しく行う必要があり、アプリケーション側で対応する処理を実装し、接続先を管理する必要があります。 インフラの観点でも多数のデータベースを効率的に運用する手法が必須であり、ゲームの成長が落ち着いたり、逆にデータが増えてくるなどでスケールアウト・インを行う場合は、シャードの分割や統合といった注意が必要な作業が発生してしまいます。これらの課題については以下の記事でも紹介しています。

しかし Aurora DSQL のように各性能が「実質無制限」にスケールするデータベースでは、そもそもシャーディングを行う必要がありません。これは大規模にデータベースを利用する場合、とても嬉しい特性です。

メリット2：常に最新のデータを利用できる

これまでの Aurora ではリーダーインスタンスは少し古い情報を返す可能性がありました（ レプリカラグ ）。これも DeNA では特に重要な問題であり、オンプレミスの MySQL を利用していた頃からの課題でもあります。例えば2012年に発行された『Mobageを支える技術』でもレプリケーション遅延問題が触れられています²。

通常のWebアプリケーションであれば、ユーザの画面操作には一定の時間間隔がありますから、5～10秒程度の遅延であれば深刻というほどでは無いことが多いでしょう。
しかし、ソーシャルゲームでは多くのユーザがアクティブに活動するため、画面操作も極めて高速になります。
特に時間限定のイベントを開催しているような場合は、限られた時間内で大きな成果を出すためにクリック／画面遷移を頻繁に行うユーザも少なくありません。たとえどれだけ短い間隔でクリックしていたとしても、アイテムを購入したときにその個数が増えていなければ、運営業者に抗議したくなることでしょう。
従って、ソーシャルゲームにおけるMySQLのレプリケーション遅延問題は、ほかのWebサービスよりもずっと深刻になる傾向があります。

この状況は現在も同じで、アプリケーション側でもレプリカラグを前提にした実装にするか、データが最新である必要がある場合はライターインスタンスを使うしかありません。DeNA ではアプリケーション側の実装を確認するため、試験環境では意図的にレプリカラグを大きくする工夫もしています。

しかし Aurora DSQL は常にラグのない情報を取得することができます。これは主に Storage のデータがタイムスタンプでバージョン管理されるようになったことと、Query Processor がローカルで正確なタイムスタンプを取得することによります³。

Query Processor はユーザからのアクセスが来た正確な時刻が分かるため、その時刻に対応するバージョンのデータを Storage から取得するだけで、最新のデータを知ることができるのです⁴。Query Processor にライターやリーダーの区別がなくなり、レプリカラグなく分散実行できる仕組みになっています。

この特性は Aurora DSQL をマルチリージョン構成にしても変わりません。それだけでなく最新のデータを各リージョン内だけで読み取ることができるため、（楽観的排他制御と合わせて）単に別リージョンの DB にクエリを発行するよりもレイテンシが大幅に低減できるというメリットもあります。これは re:Invent の CEO キーノート でも特にアピールされていた点です。

読み取り・書き込み処理のたびに別リージョンの DB との通信が発生する例：

Aurora DSQL はコミット時以外に別リージョンへの通信が発生しない：

メリット3：可用性が上がり、メンテナンス作業も不要になる

これまでの Aurora ではインスタンスへのパッチ適用やバージョンアップのほか、ホスト部分を含めてメンテナンスが行われるタイミング（メンテナンスウィンドウ）を管理する必要がありました。これらは実行時に性能上の影響が出ることが多く、場合によってはダウンタイムや手動でのインスタンス入れ替え作業が発生します。

DeNA では Blue/Green デプロイによる確実な更新のほか、クラスタ内でのフェイルオーバーが必要な場合でもダウンタイムを極力短くする仕組みを構築していますが、このような状況はそもそも起こらない方が望ましいです。

「 サーバーレス設計により、パッチ適用、アップグレード、およびメンテナンスのダウンタイムによる運用上の負担がなくなります 」と明記されているように、Aurora DSQL はこれらの作業が全て不要になります。これはコンピュート部分も分散化され、メンテナンスや更新が発生する際も AWS 内部で必要な部分のみ入れ替えながら更新することが可能になり、ユーザ側で意識することが無くなったためです。

さらにライターインスタンスという SPOF が無くなったこともあり、可用性はマルチリージョン構成で 99.999% まで引き上げられています。

Aurora DSQL の注意点

ここまで Aurora DSQL の新しい部分を紹介してきましたが、注意点もあります。Aurora DSQL はこれまでの Aurora とは全く違う仕組みのため、以下の点も含めてある程度「別物」として検証した方が良いでしょう。

楽観的排他制御を採用している

伝統的な RDB やこれまでの Aurora を触っていた方であれば、悲観的排他制御に慣れている方も多いかと思います。これは書き込み処理を行う際に、対象データのロックを事前に取得しておく（ロックが取れない場合は待機する）仕組みです。

対して Aurora DSQL は楽観的排他制御を採用しているため、データの更新前にはロックを取得しません。その代わり、競合するトランザクションがある場合はコミット時に失敗するためユーザ側での再実行が必要です。競合が多い処理はむしろ遅くなることもあるでしょう。特に長時間かけて大量のデータを更新するバッチ処理は非常に相性が悪いです。

Aurora DSQL はそもそもトランザクションタイムアウトが5分に設定されていることもあり、「互いに競合しない小さなトランザクションを低レイテンシで提供する」ことに重きを置いた設計です。これまでの RDB や Aurora とは根本的に違う使い方や、アプリケーションの設計が必要になる可能性があります。

未サポートの機能が多い

Aurora DSQL は現状未サポートの機能が多いです。2025年3月時点でビューやトリガーの他、外部キー制約など 様々な機能が利用できません 。

プレビュー段階のため今後サポートされる機能は増える見込みですが、暫くはその時点で利用できる機能をよく調査する必要があります。なお MySQL が未対応のため、DeNA でもすぐに大規模利用ができる見込みは今のところありません。

まとめ

このように、Aurora DSQL は書き込みも分散処理する設計により、以下のメリットを得られるデータベースです。これまで細心の注意が必要だったユーザ作業の多くが不要になり、ダウンタイムが許容できないケースや大規模な利用をするケースでは特に恩恵を受けられます。

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

とはいえ Aurora DSQL は万能ではなく、これまでの Aurora の完全な上位互換ではありません。もし上記メリットの重要性が低かったり既存コードとの互換性を重視すべきケースであれば、GA 後も Aurora DSQL を急いで採用するのが得策ではない場合も多いでしょう。今回紹介したのも概要だけなので、ぜひ両者の仕組みと特性を理解した上で使いこなしてください。

次回は「Aurora DSQL は何が新しいのか？（vs. Spanner 編）」です。今回紹介した Aurora DSQL の特徴は（DSQL の名前の通り）分散 SQL の特徴でもあるのですが、同じく分散 SQL である Cloud Spanner との比較を行います。実は Aurora DSQL は Spanner とは異なった仕組みで成立しており、今回紹介した注意点もその仕組みに関係しているので、次回はこの点をさらに深掘ってみたいと思います。