Amazon Aurora Global Database の書き込み転送を使用してグローバルに分散された MySQL アプリケーションを構築する

AWS は 2018 年に Amazon Aurora Global Database をリリースしました。Aurora Global Database は主に 2 つのユースケースで使えます。最初のユースケースは、災害復旧ソリューションをサポートすることです。これにより、低目標復旧時点 (RPO) と低目標復旧時間 (RTO) でリージョン全体の障害に対処しながら、保護対象のデータベースクラスターへのパフォーマンスへの影響を最小限に抑えることができます。Aurora Global Database を使用すると、通常、RPO は 5 秒未満、RTO は 1 分未満に抑えることができます。書き込みワークロードが大きい場合でも、ソースクラスターとターゲットクラスターの両方に対するパフォーマンスへの影響は無視できるほどに小さいものです。

Aurora Global Database の 2 番目の主なユースケースは、最大 5 つのリモートリージョンに Amazon Aurora クラスターの読み取り専用コピーを供給して、そのリージョンに近いユーザーにサービスを提供することです。これにより、リモートリージョンのユーザーは、さらに離れたプライマリリージョンに接続する必要がある場合よりも低いレイテンシーで読み取りが行えます。

次のグラフは、2 つのリージョン間で MySQL 論理レプリケーションを使用した例を示しています。クエリの数が段階的に増加すると、ターゲットクラスターで観察されるレプリケーションタイムラグは指数関数的に増加します。さらに、テスト済みの設定で処理できる 1 秒あたりのクエリ数は、ピーク時に約 35,000 でした。

対照的に、次のグラフは、Aurora Global Database を使用したのと同じワークロードとインスタンスのサイジングを示しています。レプリケーションは 1 秒未満のタイムラグを維持し、1 秒あたりのクエリ数はピーク時に約 200,000 (+ 5.7x) でした。

リードレプリカ書き込み転送

複数のリージョンのユーザーに近い場所で低レイテンシーの読み取りを提供することに加えて、リモートリージョンで実行されているアプリケーションもデータベースに書き込む必要がある場合があります。これを行うには、アプリケーションで次のことを行う必要があります。

各リモートリージョンからプライマリリージョンへの接続を確立すること
読み取りと書き込みのトラフィックをアプリケーションコードで分割し、読み取りトラフィックはリージョンのローカルのクラスターに送信され、書き込みトラフィックはプライマリリージョンに送信されるようにすること
書き込みと後続の読み取りの間の整合性を管理すること。これは、Aurora Global Database のレプリケーションは非同期であり、(大きくはなくても) レプリケーションタイムラグがあるためです。これが正しく行われない場合、ローカルクラスターに対する読み取りでは、アプリケーションが実行したプライマリリージョンに対する以前の書き込みが観察されない場合があります。

Aurora Global Database の新しいリードレプリカ書き込み転送機能により、リモートリージョンでの書き込みがはるかに簡単に行えるようになります。書き込み転送により、アプリケーションはローカルの読み取り専用クラスターに書き込みを送信できるようになります。これにより、先の手順がアプリケーションに対して透過的に処理されます。これにより、アプリケーションは Aurora Global Database リモートクラスターに書き込みを送信できるようになり、アプリケーション開発が簡素化されます。書き込み転送の主な利点は次のとおりです。

マネージドソリューション – リモートクラスターで発行された書き込みは、透過的にプライマリクラスターに転送されます。
レプリケーションの競合はありません – すべての書き込みはプライマリクラスターによって適用されるため、レプリケーションに関連する更新の競合は発生しません。
簡単 – リモートクラスターへの書き込みを発行した後、以前の書き込みを監視する読み取りを実行できます。
柔軟性 – 複数の読み取り整合性レベルから選択して、整合性とパフォーマンスのバランスをとることができます。

アプリケーション開発を簡素化し、リモートの Aurora Global Database クラスターへの書き込みを可能にするために、書き込み転送には次の機能があります。

リモートクラスターとプライマリクラスター間の接続は、Amazon バックボーン全体の安全な接続を使用して自動的に管理されます。
リモートクラスタ内の同じインスタンスに読み取りと書き込みを発行できます。読み取りと書き込みのトラフィックを分割したり、読み取りと書き込みのために接続、セッション、またはトランザクションを個別に管理したりする必要はありません。
複数の整合性モードが用意されていて、整合性とパフォーマンスのバランスを取ることができます。

Aurora Global Database の書き込み転送は、リモートクラスター内のインスタンスでアプリケーションからの書き込みステートメントを受け入れ、そのステートメントを必要なコンテキストと共にプライマリクラスターに転送することで行われます。書き込みステートメントは、その後プライマリインスタンスで実行されます。警告やエラーなど、ステートメントの実行結果はすべてリモートインスタンスに返され、その後アプリケーションに返されます。このプロセス全体は、アプリケーションに対して透過的です。必要な操作は、クラスターの書き込み転送を有効にし、書き込みを実行するセッションごとに整合性モードを設定することだけです。

書き込み転送を使用する際、次の点に注意する必要があります。

aurora_replica_read_consistency オプションを設定して、セッションで書き込み転送を有効にする必要があります。
INSERT、UPDATE、および DELETE はすべてサポートされています。ただし、一時テーブルの結果に基づいて永続テーブルを変更するものは除きます。
ロック読み取りを使用できます (SELECT…FOR UPDATE、SELECT…LOCK IN SHARE MODE)。
PREPARE および EXECUTE 構文を使用した準備済みステートメントがサポートされています。
ストアドプロシージャはサポートされていないため、プライマリクラスターで実行する必要があります。
DDL ステートメントはサポートされていないため、プライマリクラスターで実行する必要があります。

詳細については、「Amazon Aurora Global Database の操作」を参照してください。

整合性モード

アプリケーションがリモートクラスターに対して書き込みステートメントを実行すると、そのステートメントの結果は、プライマリクラスターでの実行直後にアプリケーションに返されます。つまり、トランザクションは、使用する整合性モードに関係なく永続的です。ただし、変更がプライマリクラスターに適用された後、その変更がリモートクラスターにレプリケートされてリモート読み取りを処理するには、時間がかかります。アプリケーションの特定のトランザクションに応じて、書き込み後読み取りの整合性が必要な場合とそうでない場合があります。レプリケーションが完了するのを待って、前の書き込みを読み取れることを確認するか、またはパフォーマンスを向上させて、レプリケーションが完了するのを待たずに次のステートメントを続行することができます。そのため、書き込み転送は設定可能な読み取り整合性モードをサポートしています。

整合性モードはセッションレベルで設定され、aurora_replica_read_consistency パラメータによって制御されます。デフォルトでは、このパラメータは空の値に設定されています。書き込み転送を使用する前に、このオプションを session、global、または eventual に設定する必要があります。

セッションの整合性

aurora_replica_read_consistency を session に設定する場合は、同じセッション内の書き込みに続く読み取りクエリが、レプリケーションがその以前の書き込みに追いつくまで待機するようにします。これにより、セッションはそれ自体の変更を確認できます。けれども、他のセッションによって発行された変更を確認できるとは限りません。

グローバルな整合性

aurora_replica_read_consistency を global に設定する場合、読み取りクエリが、レプリケーションが読み取りを開始した時点に追いつくまで待機するようにします。つまり、リモートクラスターからの読み取りでは、読み取りクエリがリモートクラスターで開始された時点までの、プライマリクラスターにコミットされたすべての変更が表示されます。このモードでは、書き込み後の読み取りの整合性は最も強くなりますが、パフォーマンスが低下します。このモードを使用する場合、クエリの待機時間は少なくともレプリケーションラグと同じ長さです。

結果整合性

aurora_replica_read_consistency を eventual に設定すると、読み取りクエリにレプリケーションタイムラグが発生します。これにより、リモートレプリカはレプリケーションの完了を待たないため、書き込みレイテンシーが減少しますが、次の読み取りで前の書き込みが確実に表示されるようにしないと、トレードオフになります。これにより書き込みが失われる可能性があるわけではありません。クエリが継続する場合は、プライマリクラスターが書き込みを適用し、それをよりリモートなクラスターに確認応答したことを意味します。ただし、その書き込みによって生成された結果のデータ変更は、読み取りが実行されたときにリモートクラスターにレプリケートされていない可能性があります。

Aurora Global Database で書き込み転送をセットアップする

既存のクラスターがある場合、Aurora Global Database で書き込み転送を有効にする最初のステップは、グローバルクラスターを作成することです。次の手順を実行します。

Amazon RDS コンソールで、[データベース] を選択します。
ソースクラスタを選択します。
[アクション] ドロップダウンメニューから、[リージョンの追加] を選択します。
[AWS リージョンの追加] ページの [グローバルデータベース識別子] で、グローバルデータベースの名前を入力します。たとえば、globalcluster などです。
これは、ライターリージョンとリーダーリージョンの両方を含むグローバルクラスターの名前です。
[セカンダリリージョン] では、ターゲットリージョンを選択します。
この記事では、[欧州 (アイルランド)] を選択します。
このページの残りの設定については、Aurora DB クラスターを作成するのと同じ設定を使用します。ただし、次の例外を除きます。
- [リードレプリカの書き込み転送] の場合は、[リードレプリカの書き込み転送を有効にする] を選択します。
  グローバルクラスターの作成が完了すると、コンソールのビューは次のスクリーンショットのようになります。
  この時点で、書き込みクラスターと読み取りクラスターの両方がオンラインであり、トラフィックを受け入れる準備ができています。

リージョン間の書き込み

リーダーリージョンで書き込みを実行するには、以下を実行します。

ライターリージョンのクラスターに接続し、次のコードで新しいスキーマを作成します。
```
mysql> create schema globaldb;
Query OK, 1 row affected (0.00 sec)
```
書き込み転送は、DML コマンドのみを転送します。つまり、ライターリージョンで CREATE TABLE のような DDL コマンドを実行する必要があります。次のコードを参照してください。
```
mysql> use globaldb;
Database changed

mysql> CREATE TABLE `test_table` (
    ->   `row_id` int(11) NOT NULL AUTO_INCREMENT,
    ->   `column01` varchar(45) DEFAULT NULL,
    ->   PRIMARY KEY (`row_id`)
    -> ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Query OK, 0 rows affected (0.02 sec)
```

新しいテーブルで新しいスキーマを作成した後、ライターリージョンのそのテーブルに 1 つの行を挿入し、結果を選択します。次のコードを参照してください。

mysql> INSERT INTO `globaldb`.`test_table`
    -> (`column01`)
    -> VALUES
    -> ('writer region column 01');
Query OK, 1 row affected (0.01 sec)

mysql> SELECT * FROM `globaldb`.`test_table`;
+--------+-------------------------+
| row_id | column01                |
+--------+-------------------------+
|      1 | writer region column 01 |
+--------+-------------------------+
1 row in set (0.00 sec)

これで、ライターリージョンに 1 つの行を含む 1 つのテーブルを持つ 1 つのスキーマが存在します。

リーダーリージョンに接続して、これらすべてのアイテムがリーダーリージョンに存在することを確認します。次のコードを参照してください。

mysql> use globaldb;
Database changed

mysql> SELECT * FROM `globaldb`.`test_table`;
+--------+-------------------------+
| row_id | column01                |
+--------+-------------------------+
|      1 | writer region column 01 |
+--------+-------------------------+
1 row in set (0.07 sec)

読み取り整合性モードを設定し、行を挿入して、現在のテーブルの内容を確認します。次のコードを参照してください。

mysql> set @@aurora_replica_read_consistency = 'session';
Query OK, 0 rows affected (0.07 sec)

mysql> INSERT INTO `globaldb`.`test_table`
    -> (`column01`)
    -> VALUES
    -> ('reader region column 01');
Query OK, 1 row affected (0.15 sec)

mysql> SELECT * FROM `globaldb`.`test_table`;
+--------+-------------------------+
| row_id | column01                |
+--------+-------------------------+
|      1 | writer region column 01 |
|      2 | reader region column 01 |
+--------+-------------------------+
2 rows in set (0.08 sec)

サポート対象のステートメントを実行する前に、セッションレベルで @@ aurora_replica_read_consistency モードを設定する必要があります。このパラメータを設定しない場合、次の例外がスローされます。

mysql> INSERT INTO `globaldb`.`test_table`
    -> (`column01`)
    -> VALUES
    -> ('reader region column 01');
ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement

まとめ

Amazon Aurora Global Database では、リモートリージョンでローカル読み取りを行えるグローバルに分散したアプリケーションを作成できます。最小限の RPO と RTO で災害対策ソリューションを維持でき、さらに世界中のリージョンで低レイテンシーの読み取りが行えます。書き込み転送では、グローバルアプリケーションがコードの変更を最小限に抑えてリモートリージョンで書き込みを実行できるようにもなりました。

Amazon Aurora Global Database を使用開始し、書き込み転送を今すぐ始めましょう。

著者について

Steve Abraham はアマゾンウェブサービスのプリンシパルソリューションアーキテクトです。お客様と協力してデータベースプロジェクトに関する助言や技術支援を行い、AWS を使用する場面でソリューションの価値を向上させる手助けをしています。

Amazon Web Services ブログ