【セッションレポート】Amazon Aurora Limitless Database 内部アーキテクチャ詳解 〜 スケーラビリティと高可用性の秘密 〜（AWS-40） #AWSSummit

コーヒーが好きな emi です。

本記事は 2024 年 6 月 20 - 21 日の 2 日間開催された AWS Summit Japan 2024 のセッションレポートとなります。

オンデマンド配信の動画リンクと資料のダウンロードは以下です。
動画の視聴と資料のダウンロードには AWS Summit Japan のマイページのログインが必要です。

• オンデマンド配信リンク - Amazon Aurora Limitless Database 内部アーキテクチャ詳解 〜 スケーラビリティと高可用性の秘密 〜
• AWS Summit Japan - セッション資料一覧

概要

• 6/21(金) 13:50 - 14:30
• テーマ：AWS for Data
• セッションタイトル：「Amazon Aurora Limitless Database 内部アーキテクチャ詳解 〜 スケーラビリティと高可用性の秘密 〜」

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

スピーカー

星野 豊

アマゾン ウェブ サービス ジャパン合同会社 Principal Database Solutions Architect Amazon Aurora 開発チーム

レベル

Level 400: 上級者向け

アジェンダ

• Managed Database
• New Technology for Database
• Amazon Aurora Limitless Database（Limited Preview）
• Shard management
• Internal Architecture
• Challenges in a distributed database

先に全体のまとめ

• Amazon Aurora Limitless Database の開発のコンセプトと裏側の機能の紹介
• Amazon Aurora Limitless Database は利用者の運用負荷を下げる新しいマネージドシャーディングの機能
  • Write Scalability を向上
• これまで Aurora 開発チームで開発してきた Grover、Caspian といった技術を使い更に Bounded Clocks という技術を融合
• Aurora の機能と PostgreSQL で使える機能はそのままに、マネージドシャーディングの機能がエンドポイント経由で提供される

Amazon Aurora Limited Database は Limited Preview（限定プレビュー）中です。気になっている、触ってみたい方は以下から申請してみてください。

Managed Database

• DB の運用には様々なタスクがある
  • モニタリング、クエリ作成、セキュリティ、メンテナンス…
  • DB の煩雑なタスクを AWS に任せることで減らす
• Amazon Aurora のバリュー
  • パフォーマンス、容量、セキュリティなど性能の向上はもちろん、特にマネージャビリティ（扱いやすさ）、運用管理性の向上を目指して開発
  • 昨今では「生成 AI とのシームレスなインテグレーション」「既存の DB から簡単に Aurora にマイグレできる」よう意識している

New Technology for Databases in the Cloud

Amazon Aurora 専用ストレージ「Grover」を開発

• 昨年の re:Invent 2023 で発表された Amazon Aurora 専用ストレージ「Grover（グローバー）」
• DB サーバーから送られてくる更新ログを集めて保管、処理等することで機能・性能向上を実現し、通常 DB より Disk I/O を 80% 削減
• Aurora は Grover（ストレージ）とコンピュート（クエリエンジン）の役割両方を持つ

サーバレス DB のためのコンポーネント「Caspian」を開発

• Aurora Serverless v2 の裏で動く仕組み「Caspian（カスピアン）」
• ハイパーバイザ、ヒートマネジメントを行うコンポーネント
• 物理 HW 上で追加のリソースが必要になった際、ダウンタイム不要で自動オンデマンドリソース割り当て
• リソース割り当てはミリ秒単位
• DB のワークロードに影響なし！
• スケールアップしたいが物理筐体（HW）の限界でリソースが足りない場合、Live Migration が行われる
  • Live Migration の中でバッファプールやコネクションなどの状態をすべてコピーするのでここもワークロードに影響がない
  • どのインスタンスを別の筐体に移動すれば最速でスケールアップが完了するか Caspian コントロールプレーンが判断する
  • キャパシティコントロールはリージョン単位で行われる
  • リージョン全体を見て各物理筐体のキャパシティを一定に保つように Live Migration している

Amazon Aurora Limitless Database（Limited Preview）

• Grover や Caspian を使って Amazon Aurora Limitless Database を開発中
• 事業がスケールし一個の Writer では足りないとなった時、よくあるのはシャーディングして Write スケーラビリティを担保する
• シャーディングの課題
  • 物理的に違う Aurora クラスターが存在する場合、どのクラスターにクエリすべきなのかアプリケーションが判断する必要がある
  • 複数シャードにわたってクエリが必要な時、一貫性、整合性（consistency）を取る方法を検討する必要がある
  • メンテナンスが必要なクラスターが増えてしまう
    • 手作業でカバーしたりスクリプトを組んで対応したり

「マネージドでシャーディングの機能を提供しよう！」→→→ Amazon Aurora Limitless Database

• Amazon Aurora Limitless Database
  • 現在 PostgreSQL 互換でリミテッドプレビュー中
  • 1 つのエンドポイントにクエリを投げるだけで、裏側で自動シャーディングしてくれる！
  • 数百万トランザクション、ペタバイトクラスのストレージを提供
  • 分散トランザクション、分散クエリ等複数のシャードにまたがった機能もサポート
  • Serverless v2 のテクノロジーをもとにしたサーバレスアーキテクチャになっている
  • 利用者は最大キャパシティを設定するだけ
  • これまでの Aurora で提供されてきた機能もそのまま使える
• PostgreSQL との完全互換を大事にしている
  • PostgreSQL の機能をそのままサポート、エクステンションもサポートしていく
  • PostgreSQLの Foreign Table と Foreign Data Wrapper は、外部データソースとの連携を可能にする機能です。

Shard management

• Amazon Aurora Limitless Database の中で作られるテーブル
  • シャードテーブル（Sharded tables）
    • シャーディングが行われる
      • 分散 DB においては 1 つのシャード（シングルシャード）にすべてのクエリが実行されると最もパフォーマンスが良い
      • 複数ノードが関わるとノード間のデータのやり取り・NW のやり取りが発生してスループットが出にくい
      • 関連するレコードは同じシャードに分配するようにできる = コロケーション（Collocation）ができる
  • リファレンステーブル（Reference tables）
    • 更新量が少なくデータサイズが小さいもの、シャードキーの設定が難しいものなどは 全部のテーブルにコピーできる
      • 全部のシャードにコピーしてしまうと更新時に時間がかかるので、更新量が少なくデータサイズが小さいもの、シャードキーの設定が難しいものを設定するのが良い
  • シャードテーブル、リファレンステーブルを活用することで簡単にシングルシャードを実現できる

※具体的なテーブルの例とクエリを用いた分かりやすい説明あり

• 特定のテーブルを Limitless Database として使いたい場合はセッション変数で定義
  • セッション変数で制御することのメリット
    • 手元の開発端末で検証をする際、セッション変数を流さなければ通常の PostgeSQL の操作と全く同じで検証できる
• マネージドだからと言ってブラックボックスにならないよう、可能な限りユーザーも内側が見えるようになっている
• Limitless Database ではハッシュパーティショニングを使っている
  • データが特定のシャードに偏るのを防ぐため

Internal Architecture

• Limitles Database は Aurora のエンドポイントの一つとして提供される
• 「シャードグループ」を導入して Limitless エンドポイントを作っている
  • クラスタ内に作られ、Limitless Database を使うのに必要な設定や機能が含まれている
  • 指定したキャパシティ内でダウンタイムなく自動で水平・垂直スケーリングする

内部のアーキテクチャ

• Limitless Database には 2 つのレイヤーが存在
  • Distributed transaction routers（ルーターのレイヤー）
  • Data access shards（コンピュートのレイヤー）

Distributed transaction routers（ルーターのレイヤー）

• ルーター + DB エンジンとしてふるまう
• エンドポイントを提供
• メタデータを管理（どのデータがどのシャードに入っているか）
• 時間ベースのトランザクションを使用した時間の払い出し（コーディネート、と呼ぶみたいです）
• クエリ実行プランの解析
• マルチシャードクエリの結果を集約して返す

Data access shards（コンピュートのレイヤー）

• ユーザーには隠ぺいされたレイヤー
• メタデータのみを管理
  • データの本体は Grover に入っている
• ルーターのレイヤーから時刻情報とクエリプランを受け取って最終的な実行計画を立て、自身が受け持つシャードでクエリを実行しルーターのレイヤーに返す
• 分散クエリではないもの、シングルシャードで処理が終わるものに関してはコミットやロールバックなどもここでおこなわれる
• シングルシャード構成にしてコンピュートのレイヤーで処理しきれることを増やせば、処理の並列度が上がりパフォーマンスが向上する

実行プランを見るとどのシャードにアクセスしていてどんな計画になっているのかなど全部ユーザーからも確認できるようになっている

• ハッシュパーティショニングはどうしてるのか？
  • データ本体は「テーブルフラグメント」、メタデータは「テーブルフラグメントリファレンス」と呼ぶ
  • テーブルフラグメントをシャーディングしている
  • ルーターのレイヤーもコンピュートのレイヤーもデータ本体を管理せず、メタデータのみを管理している
• テーブルフラグメントは複数の小さなテーブル（スライス）に分割
  • シャード内部で複数テーブルにスライスすることで並列性向上
  • ユーザーからは完全に見えない内部の工夫！
• Horizontal scale out（水平スケール、スケールアウト）
  • ユーザーが指示することもできるし自動スケールアウトもできる
  • shard split（シャード分割）が起こってもコロケーション設定がされていれば同じシャードに入るようになっている
  • Grover の技術である Aurora cloning（クローニング）とストレージ間でのデータのレプリケーションの仕組みを活用してオンラインで高速データ同期し、ルーターからの向き先を変える
    • データ本体のレプリケーションやコピーは Grover が超優秀なのでおまかせ！
  • ルーターのレイヤーではメタデータしか管理していないため「どこにどのデータがあるか？」というやりとりが高速
• create-db-shard-group で設定可能
  • 最大 ACU や redundancy mode を設定
    • Redundancy（リダンダンシー）とはデータの冗長性や重複を意味する
  • Compute redundancy 0：Data Access Shard には各 AZ に 1 台ずつインスタンスができる（Single AZ）
    • Distributed transaction routers（ルーターのレイヤー）のインスタンスはもともと自動で冗長性を担保しており 1 AZ がなくなっても自動でスケールアップしてくれる。メタデータしか持たないので高速
  • Compute redundancy 1：各 AZ に 2 台ずつインスタンスができる（Mluti AZ）
  • Compute redundancy 2：各 AZ に 3 台ずつインスタンスができる
    • 通常の Aurora よりフェイルオーバーターゲットを 1 インスタンス多く持てる

Challenges in a distributed database

• 複数のクエリ結果が複数のルーターからやってくる、どのように整合性を保つか？各シャードのバックアップやリストアはどうするか？
• 以下のトランザクションをサポート、どのように分散 DB で実現するか？
  • READ COMMITED
  • REPEATABLE READ

Bounded clocks（バウンディッドクロック）で解決

• EC2 TimeSync service
  • 各 DC に GPS アンテナと原子時計を用意し、AWS の Nitro チップと FPGA のボードを組み合わせて専用に作られたハードウェアを格納したラックがある
  • このラックから大量の EC2 インスタンスにマイクロ秒（μs）レベルの精度の時刻情報を配信している
  • Current time（現在の時刻）の他に、Earlist possible time（最早）、Latest possible time（最遅） という時刻情報の信頼区間も配信している
    • 大量の EC2 に配信する関係で NW 上の Jitter（誤差、ゆらぎ）で微妙にずれてしまうためこうなっている
• PostgreSQL
  • コミットのタイムスタンプとスナップショットのアイソレーションレベル ^*1を作る PostgreSQL のアーキテクチャと合体して Tuple の可視性を管理
• EC2 TimeSync service と PostgreSQL のエンジンを密に連携している
• Bounded clocks ではこの信頼区間の中で整合性を保ってコミットするよう少しの待機時間がある（wait time）

※ READ Commited について具体的なクエリを用いた分かりやすい説明あり

Summary

• Amazon Aurora Limitless Database を使うと Wite Scalability を向上しペタバイトクラスまで拡張できる
• アプリケーションからはエンドポイントを見るだけ、自動でシャーディングしてくれる
• シャードテーブル（Sharded tables）、リファレンステーブル（Reference tables）を活用してほしい
• Amazon Aurora Limitless Database の使いどころ
  • とにかく書き込みの性能を上げてサイズが欲しい
  • MySQL、PostgreSQL をそのまま使いたい
  • 複雑なトランザクション管理を任せたい
  • 複数テーブルをまたいだ処理をおこないたい
  • など…

感想

Amazon Aurora というマネージドデータベースサービスの裏側にかなりに深く踏み込んで解説するセッションでした。
時間ぴったりまで怒涛の DB 解説が続き、ついていくのに必死で息継ぎをする暇もありませんでした。 Bounded clocks で原子時計や時刻の信頼区間の話が出てきたときは「そこまでするのか……！！」と興奮しました。 DB プロフェッショナルの熱量を強く感じる、激アツセッションだったと思います。
最近データベースサービスをよく触るのですが、マネージドサービスの裏側について知ることができてとても面白かったです。

参考

脚注