[レポート] Amazon Aurora Limitless Database によるスケールの実現 #AWSreinvent #DAT344

ウィスキー、シガー、パイプをこよなく愛する大栗です。

私はアメリカのラスベガスで開催している Amazon Web Services のグローバル カンファレンス re:Invent に来ています。書き込みをスケールすることができる Amazon Aurora Limitless Database についてのセッションに参加したためレポートします。

Monday Night Live で Aurora のストレージを司る Grover やスケールアップが可能なハイパーバイザの Caspain が発表されて、その先にある Aurora Limitless Database が発表されたばかりという状態で、現時点で最も詳しい情報のセッションだったと思われます。

Achieving scale with Amazon Aurora Limitless Database

セッション概要

Amazon Aurora はクラウドに向けて構築されたリレーショナルデータベースサービスであり、グローバルスケールで比類のないハイパフォーマンスと可用性を実現するように設計されており、MySQL と PostgreSQL の完全な互換性を備えています。本セッションでは、Amazon Aurora Limitless Database が、ペタバイト級のデータに対して毎秒数百万トランザクションのスケーリングを可能にするアプリケーションの実現方法について学びます。Aurora Limitless Database のアーキテクチャ、分散トランザクション管理、サーバレススケーリング機能について説明します。また、Aurora Limitless Database に適したアプリケーションパターンと避けるべきパターンを紹介します。Aurora Limitless Database がどのように Aurora のスケーリングをより簡単になるかと学びます。

スピーカー

• Christopher Heim -
• David Wein -

データベースのスケーリング

データベースのスケーリングは、データベースをスケールアップするか、Amazon Aurora の最新のイノベーションを使用するか、多くのワーカーでジョブを実行してスケールアウトするか、などが考えられます。スケールアウトは読み取りの場合は比較的簡単でリードレプリカを使用します。書き込みでスケールアウトをする場合にはシャーディングが一般的ですが、単一のデータベースと異なり、クエリ、一貫性、メンテナンスなど複数の問題を引き起こします。

そこで Amazon Aurora Limitless Database を開発しました。現在 PostgreSQL 互換が限定プレビューです。シャードされたデータベースの機能をシンプルに提供します。単一インスタンスの制限を超えて自動でスケールするサーバーレスデプロイメントで、分散アーキテクチャでスケールしますが、単一のインタフェースを提供します。これはシステム全体に渡るトランザクションの一貫性を提供します。

Limitless Database の利用

説明のために顧客テーブル、注文テーブル、税率テーブルあるとします。これをシャーディングします。注文テーブルでは顧客 ID をシャードキーとして使用できます。顧客テーブルは注文テーブルは結合するばあい同じキーのデータがあると便利です。税率テーブルはリファレンス テーブルとして各シャードにあるのがて聞いています。

実際にテーブルを作成するときには、CREATE TABLE モードという概念を導入して、パラメータを設定します。

シャードテーブルである顧客テーブルは CREATE TABLE モードをshardedにし、シャードキーに顧客 ID を指定してテーブルを作成します。

SET rds_aurora.limitless_create_table_mode='sharded';

SET rds_aurora.limitless_create_table_shard_key='{"cust_id"}';

CREATE TABLE customer (
    cust_id INT PRIMARY KEY NOT NULL,
    name    TEXT
    email   VARCHAR(100)
    );

シャードテーブルである注文テーブルは CREATE TABLE モードをshardedにし、シャードキーに顧客 ID を指定して、紐付きに顧客テーブルを指定して、テーブルを作成します。

SET rds_aurora.limitless_create_table_mode='sharded';
SET rds_aurora.limitless_create_table_shard_key='{"cust_id"}';

SET rds_aurora.limitless_create_table_collocate_with='customer';

CREATE TABLE order (
    order_id    INT NOT NULL,
    cust_id     INT NOT NULL,
    amount      DOUBLE NOT NULL,
    tax_rate_id DOUBLE,
    PRIMARY KEY (order_id, cust_id)
);

リファレンス テーブルである税率テーブルは

SET rds_aurora.limitless_create_table_mode='reference';

CREATE TABLE tax_rate (
    tax_rate_id INT PRIMARY KEY NOT NULL,
    city        TEXT NOT NULL,
    state       TEXT,
    country     TEXT NOT NULL,
    tax_rate    DOUBLE NOT NULL
);

SET rds_aurora.limitless_create_table_mode='standard';

CREATE TABLE 文をそのまま残しているため、PostgreSQL と完全に互換性があります。

Amazon Aurora Limitless Database のアーキテクチャ

標準的な Aurora のアーキテクチャは以下で構成されています

1. 分散ストレージ上の Aurora のボリューム
2. 一つの Aurora 書き込みインスタンス
3. オプションのリーダーインスタンスによる可用性と読み取りスケーリング
4. Limitless Database で「シャードグループ」の概念を導入

Limitless Database のシャードグループは以下にトランザクション ルータとデータ アクセス シャードから構成されています。

各コンポーネントは AZ に分散してコンポーネントが配置されて冗長性が確保されます。

データを分散させるためにハッシュレンジ パーティショニングを使用します。シャードキーで分散された範囲をテーブル フラグメントと呼びデータ アクセス シャードごとに所有権が割り当てられます。データ自体は Aurora の分散ストレージに保存されます。トランザクション ルータはテーブル フラグメントの参照を持ちますがデータは保持しません。

トランザクション

READ COMMITEDとREPEATABLE READの分離レベルをサポートしています。

分散データベースでは様々は困難があります。

• 協調が拡張性を制限
• トランザクションスコープはコミットするまで不明
• クエリの断片が異なるタイミングで実行される
• 順序の維持
• 一貫性のあるリストア

Limitless Database ではクロックの範囲で解決しています。マイクロ秒単位の精度を持つようになった TimeSync Service を元に、概算の現在時刻、最早な可能性のある時刻。最遅な可能性のある時刻を取得します。

分散された Repeatable Read のトランザクション

分散された Read Commited のトランザクション

トランザクションは PostgreSQL と同じ Read Commited/Repeatable Read セマンティクスであり、クォーラムを使用せずフェイルオーバー時にも読み込みに一貫性があり、単一シャードへの書き込みによるコミットはリニアににスケールして、分散コミットはアトミックになっています。

クエリ

クエリ実行時には以下のように処理が流れます。

ルータ	シャード
1. クライアントからのクエリーを受信
2. シャードに送信できるクエリと、実行しなければならない結合を計画する。
3. トランザクション・コンテキストで部分クエリをシャードに送信 シャード
	4. ルーターから部分クエリーを受信
	5. ローカル結合とスキャンを計画
	6. 実行し、結果をルーターに送信
7. ルーターは必要に応じて最終的な結合、フィルター、集約を行う。

さいごに

以前から Amazon Aurora に関するアーキテクチャなどを調べていたため、Aurora Limitless Database のセッションを興味深く見ていました。類似の機能として、以前 Multi-Master がありましたが、マスタ間にデータがまたがるときの一貫性が単一マスタの Aurora と異なるため扱いが難しくあまり利用されなかったという悲しい過去があります。Limitless Database ではマイクロ秒単位へ精度が向上した TimeSync Service を使って通常の PostgreSQL と同様のトランザクション分離レベルを実現するので、既存の Aurora からも移行しやすいと思われます。

CREATE TABLE モードの設定のためにテーブルの構成を理解している必要性がありますが、Aurora の書き込み性能に問題を抱えているユースケースでは極めて有力な選択肢になると思います。現在限定プレビュー中なので、ご興味がある方は申し込みましょう。

https://pages.awscloud.com/Aurora-Limitless-Database-Preview.html