こんにちは。Cold-Airflow です。
本記事は、AWS Summit Japan 2024 のセッション「Amazon Aurora Limitless Database 内部アーキテクチャ詳解 〜 スケーラビリティと高可用性の秘密 〜」のレポート記事です。

データベース開発をしている方や、Aurora のスケール性能に課題を持っている方はご覧頂くと勉強になるセッションだと思います。

セッション概要

Amazon Aurora Limitless Database 内部アーキテクチャ詳解 〜 スケーラビリティと高可用性の秘密 〜(AWS-40)

AWS セッション(Level 400: 上級者向け)
テーマ：AWS for Data

スピーカー

アマゾン ウェブ サービス ジャパン合同会社 星野 豊

概要

AWS re:Invent 2023 で発表された、Amazon Aurora Limitless Database について、AWS が Aurora Limitless Database をリリースした背景を Aurora Limitless Database が解決する課題を交えてお話します。
また、Aurora Limitless Database を実現するための要素技術や Aurora Limitless Database の内部アーキテクチャ・動作に関する詳細情報をご説明します。

レポート

Managed サービスを活⽤してイノベーションを

• Database management
  • スキーマデザイン
  • クエリ最適化
  • クエリの作成
  • モニタリング
  • パッチ適⽤
  • コンプライアンス
  • セキュリティ
  • Backup & Recovery
  • High availability
  • メンテナンス
  • スケーリング
  • アップデート
• データベースの管理には様々なタスクがある
• 自社に DBA がいない場合や対象とするデータベースが多いなどでタスクが大量にあるケースが存在する
• そういったときにマネージドで機能を提供している
• クエリの作成、最適化に注力できる

Amazon Aurora core values

1. Performance & scalability
2. Availability & durability
3. Security
4. Manageability at scale
5. Operational Analytics
6. generative AI
7. Ease of migration

Recent innovation

• 新機能・機能改善を継続的にリリース
  • Amazon Bedrock integration
    • AWS が生成 AI 向けに Aurora MySQL と Amazon Bedrock の統合を発表
  • Amazon GuardDuty RDS Protection
    • Amazon GuardDuty RDS Protection for Amazon Aurora の一般提供を開始
  • Amazon DevOps Guru Proactive Insights
    • Amazon DevOps Guru for RDS が予測的インサイトをサポート
  • On-demand Database performance analyzing
    • Performance Insights を使用した Amazon RDS データベースの負荷分析 | Amazon Web Services ブログ
  • I/O Optimized storage
    • AWS が Amazon Aurora I/O 最適化をリリース
  • Advanced JDBC Wrapper Driver for Amazon Aurora
    • Amazon Aurora 向け Advanced JDBC Wrapper Driver のご紹介 | Amazon Web Services ブログ
  • Amazon Aurora MySQL database restart time optimizations
    • Amazon Aurora MySQL にデータベースの再起動時間を最大 65% 短縮する最適化機能が搭載される

New Technology for Databases in the Cloud

AWS database innovations

Grover

• Amazon Aurora 専⽤のストレージ Grover を開発
  • The log is the Database
  • Grover はログをストアするだけでなく処理も⾏うことで、多くの機能や性能向上を実現
  • Amazon Aurora では、Disk I/O を 80% 削減
• Aurora 当時からローンチされている仕組み
• 更新のログをすべて集めている
• ディスク IO の削減が実現できている

Caspian

• Serverless Database のために Caspian を開発
  • ハイパーバイザ、ヒートマネジメントを⾏うコンポーネント
  • オーバサブスクリプションでデータベースインスタンスを配置し、リクエストされたリソースを ms 単位で割り当てる
  • スケール後のリソースが確保出来ない場合は Live migration を実施
• ダウンタイムを与えずにリソースを増やすことができる
• ワークロードの影響は無いようになっている
• 物理筐体を超えるスケールはライブマイグレーションが行われる
• ダウンタイムの影響はない
• データベースを拡張するのに⼗分な容量はあるのか︖
  • どうスケールすればいいかやどれを移動させればスケールアップできるかを考えている
  • バッファープールもコピーされる
• リージョン単位で見る

Amazon Aurora Limitless Database(Limited Preview)

今までの課題

• データサイズが増えたり、一つのライターで耐えられなくなったりする際にシャーディングという手法がよく使われる
• シャーディングして物理的に違うクラスターが存在
• アプリ側でどこにデータがあるか判断しないといけない
• 複数にクラスターにわたって JOIN したいこともある
• バックアップのポイントをどうするかを考えないといけない
• 都度のメンテナンスが発生する
• スクリプト管理ツールを作成している顧客が多い

マネージドのシャーディングを開発

• コンセプト
  • 一つのエンドポイント
  • アプリでカスタムロジックはいらない
  • マネージドで提供
• 分散クエリ、複数のシャードのクエリも対応
• Serverless v2 をベース
• インスタンスのプロビジョニングは不要
• 最大のキャパシティを設定だけ
• その範囲でスケールアップダウンが行われる
• これらの機能を Aurora のプラットフォームで提供
• 今までの機能を継承している
• コミュニティとの互換性も備えている
• アプリのドライバーを Aurora 用に変えないといけないことはない
• トランザクションのセマンティックの動きも変わらない
• PostgreSQL の機能を活用
• 不足している機能は PostgreSQL エンジンに手を加えた

Use Limitless Database

• どうやって使われるか
  • どれをシャードキーにするかを決める
  • よく JOIN するキー
• Sharded と Reference が存在する
• Sharded は複数のノードに分散される
• 複数ノードだとやりとりがあった場合にスループットが発生する
• よく JOIN されるキーを同じシャードに格納する
  • コロケーションと呼ぶ
  • 同じシャードキーは同じシャードに
• Referenceはすべてのシャードにコピーされる
  • これでいいと思われるが更新処理のときは全てにアクセスが必要になる
• セッション変数で制御できる
  • 利点としてラップトップで作業するときは通常の PostgreSQL
  • 本番で流すときだけ Limitless になる
• 特別なセマンティックをいれない
  • 拡張として使う
• 通常のテーブルをあとからコンバートすることはできる
• ブラックボックスなことはない
• ハッシュパーティショニングを使用している
  • ハッシュのレンジに分ける
• 単調増加のときに特定のシャードに偏ることがよくある
• ランダムや UUID といった方法があるがハッシュでちらしてパーティショニングする方法を取っている
• 単調でもホットにならない

Internal Architecture

• Standard Aurora architecture
  • 分散ストレージの Aurora ボリューム(Grover)
  • Aurora Writer instance
  • 可⽤性と読み取りスケーリングのための Reader instance
  • Limitless Database はシャードグループの概念を導⼊
• Limitless Database shard group
  • Aurora cluster 内に作成
  • Limitless Database に必要な機能が全て所属
  • 単⼀エンドポイントを提供
  • 指定されたキャパシティ内で⾃動でダウンタイムなく⽔平・垂直スケーリング
• エンドポイントが追加される
  • 5 つめのエンドポイント追加
  • DB shard group
  • これにつなぐとシャーディングの恩恵が受けられる

Distributed transaction routers

• Database shard group エンドポイント
• スキーマと shard key に関するメタデータを管理
• 時間ベースのトランザクションを使⽤し、トランザクション分離と⼀貫性を保つ
• クエリを解析し、シャード全体に分散させる最適な⽅法を決定
• マルチシャードトランザクションでは、分散コミットを実⾏
• マルチシャードクエリでは、各シャードの結果を集約
• ただのプロキシレイヤーじゃない
• ユーザーにエンドポイントを提供
• どのシャードでメタデータを管理しているのかを見る
• クエリの解析も行う
• ルーターと DB エンジンとしての振る舞いをする

Data access shards

• メタデータだけを管理
• 計画立てて実行して返す
• 一つのシャードの場合はコミットも行う
• 複数のシャードで並列できる → スループットが出やすい
• シングルシャードクエリ
  • 実行計画でどのシャードにアクセスしているか見える
  • すべて見れるようになっている
• access shards 呼んでいる理由
  • データを持っていない
  • データにアクセスためのシャード
• Table slicing
  • サブレンジはユーザーから確認できない
  • ユーザーの意識はいらない

Transaction support (Isolation level)

• READ COMMITTED
  • クエリ開始前にコミットされた最新のデータを参照可能
  • トランザクション内のクエリごとに異なるデータが表⽰される可能性がある
• REPEATABLE READ
  • トランザクション開始前にコミットされた最新のデータを参照可能
  • トランザクション内のすべてのクエリには同じデータが表⽰される
• PostgreSQL のトランザクション セマンティクスを維持

Solved with bounded clocks

• EC2 TimeSync service (μs)
  • Amazon Time Sync Service がマイクロ秒単位の正確な時間のサポートを開始
  • 専用のハードラック
  • マイクロ秒で時間を管理できる
  • 時刻信頼区間を配信
  • ネットワークの実態としてゆらぎが存在する
  • マイクロ秒レベルだと誤差が生まれる
  • 時刻信頼区間が一定数を超えていないとコミットを待つ
  • 時刻信頼区間が入った → 成功すると判断

Summary

Amazon Aurora Limitless Database (Limited Preview)

• Amazon Aurora Limitless Database を利⽤することで、shard key をもとに⾃動的にシャーディングが⾏われる
  • Write scalability の向上
  • ストレージリミットの緩和
• 1 つのエンドポイントに対しクエリを実⾏することで、⾃動的に適切なシャードに対しデータの更新・取得が⾏える
  • アプリケーションにシャーディングロジックを追加する必要がなくなる
• 各コンポーネントは負荷に応じて⾃動的にダウンタイム無くスケールアップ・ダウンが⾏われる
  • Serverless テクノロジを採⽤し、最⼤キャパシティを超えた場合は、シャードを担当するコンピュートノードを分割
  • シャード毎に負荷が異なる環境においてもコスト最適化を容易に⾏える
  • ストレージサイズの上限を⼤幅に向上
• データアクセスパターンに応じてテーブルの配置戦略を選択可能
  • Sharded tables: Shard key に応じて⾃動で data access shard にシャーディングされるテーブル
  • Reference tables: 全ての data access shard に配置されるテーブル
    • データサイズが⼩さく更新頻度が低いテーブルが適している
• Distributed query / Distributed transactions
  • シングルシャードクエリとして実⾏し、クロスシャードクエリのレイテンシを軽減するために
    • 頻繁に JOIN されるテーブルは collocation
    • Reference tables を活⽤
• Aurora Limitless Database の使い所
  • Write scaling / Storage size 上限を引き上げることにプラスして
    • MySQL / PostgreSQL インターフェースを利⽤したい
    • BEGIN-COMMIT / ROLLBACK を使った複数ステートメントのような複雑なトランザクション管理をデータベースレイヤに任せたい
    • JOIN など複数のテーブルをまたいだデータを処理したい
    • 各エンジンの組込関数 / Extension を利⽤したい

感想

めちゃくちゃレベルの高いセッションでとても満足しました。
Limitless Database の背景も RDB が抱える課題としてありますし、それを解決する手法をユーザー側でコントロールする大変さも頷けます。

クラウドのメリットであるマネージドという点をフル活用できる機能だと思いました。

さらに、内部的にどうやって実装しているかという視点の解説が丁寧にされており、仕組みの理解が深まりました。
あとなにより、互換性の部分や単一のエンドポイントといったユーザーの体験を損なわない工夫を随所に感じられました。

こういった機能を活用することで、よりユーザーはサービスの利益になる活動に注力できると思いました。

また、プレビュー中なので GA されたら触ってみたいと思わせるセッションでした。