AWS再入門ブログリレー Amazon Aurora 編

ｺﾝﾆﾁﾊ 後藤です。
当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2020』の 4日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。 AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2020 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。4日目のテーマは『Amazon Aurora』です。

目次

• Amazon Auroraとは？
• MySQLとPostgreSQLの互換性について
• Auroraのアーキテクチャについて
• DBインスタンスについて
  • リードレプリカ
  • エンドポイント
  • フェイルオーバ
  • マルチマスタークラスタ
• ストレージについて
  • バックアップ
  • リカバリ
  • バックトラック
• その他の機能について
  • Aurora Serverless
  • Global Database
  • Parallel Query
  • Database Cloning
• 費用について
  • インスタンス
  • ストレージ
  • バックアップ
  • データ転送
• 最後に

Amazon Aurora とは？

Amazon Auroraとは、Amazon RDSで使用出来るデータベースエンジンの一種であり、AWSがクラウド向けに構築したMySQL及びPostgreSQLに互換性を持った完全マネージド型のリレーショナルデータベースエンジンです。エンタープライズ向けに提供されながらオープンソースデータベースのシンプルさとコスト効率を併せ持っています。
Amazon Auroraの特徴として、以下のようなことが挙げられます。

• 最大で標準的なMySQLの5倍、標準的なPostgreSQLの3倍のスループットを発揮できる性能
• ストレージは必要に応じて10GBから最大64TBまで自動的にスケールする拡張性
• データは3つのAZに渡って6個レプリケーション(1AZで2つ)され、かつS3にバックアップすることで99.99%を超える高可用性、耐障害性
• 完全マネージド型のため、パッチ適用やデータベース構成、バックアップ等の運用負荷を軽減

MySQLとPostgreSQLの互換性について

冒頭でも記述したように、AuroraはMySQLとPostgreSQLに互換性を持っていますが、全てのバージョンに対して互換性は持っていません。 現在 2020/08/06 時点で互換性を持つバージョンは以下の通りです。

• MySQL
  • 5.6
  • 5.7
• PostgreSQL
  • 9.6
  • 10
  • 11

例えば、互換性が無いMySQL 8系等のバージョンを使用したい場合等はAuroraではなく、RDS for MySQLの利用が選択肢として挙げられるかと思います。

PosgreSQL 11の互換性が今年の4月より全AWSリージョンで利用可能になっているため、今後のバージョンアップ次第では更に互換性が増えてくるかもしれません。

Auroraのアーキテクチャについて

Auroraは一般的によく使用されるPrimary/Secondaryの構成とは異なり、クラスタという単位で構成されています。クラスタの構成要素は1つ以上のDBインスタンスから成るインスタンス層とデータを管理するクラスタボリュームから成るストレージ層になります。

画像引用先 : 20190828 AWS Black Belt Online Amazon Aurora with PostgreSQL Compatibilityより

DBインスタンスについて

DBインスタンスは主に書き込み/読み取りのオペレーションで使用出来るプライマリDBインスタンスと、読み取り専用のオペレーションでのみ使用出来るリードレプリカになります。

以下は主にDBインスタンスに関係する機能を説明します。

リードレプリカ

1つのクラスタで最大15個まで増やすことが出来る読み取り専用のインスタンスです。リードレプリカの追加/削除はダウンタイム無く行うことができます。
プライマリDBと参照するクラスタボリュームは同じであるため、レプリカ遅延も低いです。(通常10ms未満)
データベースに対して書き込みや更新より読み取り処理が多いアプリケーションでは、リードレプリカ側に負荷が偏る場合があります。そういったケースに対してリードレプリカの台数を増やすことで負荷を分散することが可能です。

画像引用先 : 20190828 AWS Black Belt Online Amazon Aurora with PostgreSQL Compatibilityより

・AutoScaling機能

リードレプリカはEC2のようにAutoScaling機能が使用出来ます。
AutoScaling機能ではターゲットメトリクスとして以下2つのメトリクス値のどちらか片方を選択し、指定された値に近い数値になるように台数を調整します。

• Auroraレプリカの平均CPU使用率
• Auroraレプリカの平均接続数

例としてターゲットメトリクスとしてAuroraレプリカの平均CPU使用率を選択し、ターゲット値を50%とした場合、各インスタンスのCPU使用率が50%に近い数値で維持されるよう台数を調整するような挙動を取ります。

またAutoScaling機能では台数変更後、一定期間スケールイン/スケールアウトのリクエストをブロックするクールダウン期間を設定することも可能です。
クールダウン期間の指定が無い場合のデフォルト設定は300秒です。

エンドポイント

AuroraではDBインスタンスに接続するにはエンドポイントを使用しますが、エンドポイントには以下の種類があります。

画像引用先 : 20190828 AWS Black Belt Online Amazon Aurora with PostgreSQL Compatibilityより

• クラスターエンドポイント
  クラスタのプライマリDBインスタンスに接続するエンドポイントになります。
  仮にプライマリDBインスタンスで障害が発生して、リードレプリカが昇格した場合もエンドポイントの向き先は自動的に昇格後のプライマリDBインスタンスに向き、接続リクエストに継続して応答するためサービスの中断は最小限に抑えることが出来ます。
  プライマリDBインスタンスに接続出来る唯一のエンドポイントになるため、書き込み等のオペレーションではこちらのエンドポイントを使用します。

• 読み取りエンドポイント
  クラスター内に存在するリードレプリカに接続するエンドポイントになります。
  接続対象はクラスター内に存在する全てのリードレプリカになるため、読み取りのオペレーションの負荷分散ができます。
  クラスター内にリードレプリカが存在しない場合はプライマリDBインスタンスに接続を行います。

• カスタムエンドポイント
  任意のDBインスタントを接続対象としてグループ設定が出来るエンドポイントになります。
  クラスターエンドポイント、読み取りエンドポイントとは異なり、プライマリDBインスタンスとリードレプリカの両方を接続対象として指定することができます。

フェイルオーバ

AuroraではプライマリDBインスタンスで障害が発生した場合、リードレプリカがプライマリDBインスタンスに昇格する自動フェイルオーバを対応しています。
リードレプリカ毎にフェイルオーバの優先度を最も高い値の0から、最も低い値の15の範囲で設定できます。
フェイルオーバ優先度の値は異なるリードレプリカで同値に設定することができます。その場合、プライマリDBインスタンスと同じインスタンスサイズのリードレプリカが優先的に昇格されますが、更に複数のリードレプリカが昇格の候補に挙がった場合は任意のリードレプリカが昇格されます。

マルチマスタークラスタ

こちらは今年の5月より遂に東京リージョンでも利用可能となったマルチマスタークラスタの機能です。従来のシングルマスター構成とは異なり、複数のプライマリDBを使用出来るため、片方のプライマリDBに障害が発生した場合でも、もう片方のプライマリDBで継続的な書き込みができます。

画像引用先 : Amazon Web Servicesブログ Amazon Aurora マルチマスタークラスターが東京リージョンに対応しました より

その特性から、マルチマスターは特に稼働時間に敏感なアプリケーションに対して有効な機能となっています。

しかし、マルチマスタークラスタの機能を使用する際に、気を付けたい幾つかの考慮事項があります。以下一部をピックアップして記載致します。

• マルチマスタークラスタ構成が利用出来るのは MySQL5.6互換性があるバージョン 5.6.10a に限られます。
• DBインスタンス数は最大2つまでしか作成できない。
• 全てのリージョンでサポートはされていない。
• 接続の負荷分散が行われないため、独自の接続管理ロジックを実装する必要がある。

その他の考慮事項についてはこちらからご確認ください。

ストレージについて

Auroraのデータは10GBから最大64TBまで自動スケールアップするクラスタボリュームに保存されています。クラスタボリュームはDBインスタンスとは別に管理されており、各DBインスタンスから接続されます。

データはProtection Groupsと呼ばれる10GBの塊で3AZにまたがる6か所のストレージノードにコピーされています。

画像引用先 : 20190828 AWS Black Belt Online Amazon Aurora with PostgreSQL Compatibilityより

6か所へのコピーは並列処理されているため、処理が遅くなるようなことはありません。また、書き込み処理は6か所中4か所、読み込みは6か所中3か所のストレージで正常に処理が完了したらクライアントに処理結果を返します。この設計から、Auroraは6か所中2か所のストレージで障害が発生しても読み書きに影響は無く、3か所で障害が発生しても読み込みは可能となっています。

画像引用先 : 20190828 AWS Black Belt Online Amazon Aurora with PostgreSQL Compatibilityより

バックアップ

Auroraのストレージは自動的にS3にバックアップが取得されています。自動バックアップの保持期間は1日から35日で任意の期間で指定できます。デフォルトは1日です。

自動バックアップとは別に、任意のタイミングで手動バックアップ（スナップショット）も取得可能です。Auroraでは手動バックアップによるパフォーマンス影響はありません。また、手動バックアップで取得したデータは保持期間の指定はなく、長期間の保存が可能です。

リカバリ

保持期間内のバックアップデータ、もしくはDBクラスタのスナップショットから新しいクラスタを作成することで、バックアップ取得時点のデータをリカバリすることが出来ます。

また現時刻の5分前からバックアップの保持期間までの任意の位置に秒単位で復元可能なポイントインタイムリカバリも使用可能です。

バックトラック

バックアップからクラスタを復元するリカバリとは異なり、より高速にデータベースの状態を特定の時点に戻す機能になります。
バックトラックの機能はMySQLと互換性のあるAuroraでのみ使用可能です。

画像引用先 : 20190428 AWS Black Belt Online Amazon Aurora with MySQL Compatibilityより

バックトラックは『ターゲットバックトラックウィンドウ』に巻き戻す時間を指定して実行することができます(上限72時間)。しかし、ターゲットバックトラックウィンドウで指定した時間はあくまで所望時間であり、実際に巻き戻しされる時間は『実際のバックトラックウィンドウ』の時間に基づいて行われます。

バックトラックのユースケースとしては、簡単なエラー(WHERE句無しのDELETE等)を取り消したり、変更を加えるテストを実行後に状態を復元する場合に有効です。

その他の機能について

Aurora Serverless

Aurora Serverlessはアプリケーションのニーズに応じてそのコンピューティング性能を自動的に起動、シャットダウン、及びスケールアップ/ダウンする機能です。
コンピューティング性能は従量課金となっていて、起動している間は秒課金で費用が発生します。ストレージに関してはコンピューティング性能が立ち上がっていない状態でも費用が発生します。

画像引用先 : AWSドキュメント Auroraのユーザガイド Aurora Serverlessの仕組み より

Serverlessの機能は現在以下のバージョンで使用することができます。

• MySQL5.6と互換性のあるAurora MySQLバージョン
• MySQL5.7と互換性のあるAurora MySQLバージョン(2.07.1)
• PostgreSQLバージョン10.7と互換性のあるAurora

Serverlessの特徴としては、インスタンスとキャパシティの管理が不要であるためシンプルに使用することができ、アプリケーションから利用が無い限り、コンピューティング性能に対して費用が発生しないため、用途によってはサーバありきのクラスタ構成のAuroraに比べ、低コストに使用することが出来ます。

そのため、ユースケースとしては不定期使用のアプリケーションや可変ワークロードのアプリケーション、開発テスト用のデータベースとしての利用が向いています。

Serverlessはクラスタ構成のAuroraとは大きく仕様が異なるため、利用する際には以下のような考慮事項を確認する必要があります。

• PublicIPアドレスを割り当てられないため、VPC外からアクセスが出来ない。
• Serverlessへ1日以上接続が続く場合、自動的に接続は閉じられる。
• クラスタ構成のAuroraで使用出来る一部機能が使用出来ない。

等々。その他考慮事項はこちらからご確認ください。

Global Database

Global Databaseは複数のAWSリージョンにまたがり、低レイテンシなレプリケーションと高速フェイルオーバが可能なAuroraを構築することが出来る機能です。

画像引用先 : 20190428 AWS Black Belt Online Amazon Aurora with MySQL Compatibilityより

Global Databaseの機能は現在以下のバージョン/インスタンスクラスで使用することができます。

• バージョン
  • MySQL5.6と互換性のあるAurora MySQLバージョン(5.6.10a , 1.22以降)
  • MySQL5.7と互換性のあるAurora MySqlバージョン(2.07以降)
  • Aurora PosgreSQlバージョン 10.11 , 10.12 , 11.7以降
• インスタンスクラス
  • db.r4
  • db.r5

Global Databaseは1つのプライマリAWSリージョンと、最大5つのセカンダリAWSリージョンで構築することが出来ます。プライマリAWSリージョンでは唯一プライマリDBインスタンスが作成でき、データをマスターとして管理します。セカンダリAWSリージョンではリードレプリカのみ構築することができます。
ストレージは各リージョン事に保持していますが、レプリケーションによるパフォーマンスの影響はほぼ無いとされています。
他にも最小限の遅延時間(通常1秒未満)でレプリケーションが可能であったり、リージョン間のフェイルオーバは1分未満でセカンダリーAWSリージョンのリードレプリカを昇格することができます。

Global DatabaseのRTO/RPOは以下のように定められています。

• RTO : 1分未満
• RPO : 5秒未満

以上のことから、Global Databaseの機能を使用することでリージョン単位の障害に対応するためのDR対策が実現可能となります。

Parallel Query

Parallel Queryはデータが保存されているストレージ層の各ノードのCPUを並列使用することで高速にクエリを実行する機能になります。
Auroraのストレージ層は上述の通り、複数のノードによってデータが保持されています。各ノードにはストレージとしての機能だけでなく、読み書きの用途のためCPUが積まれています。DBインスタンス側で処理しているクエリ実行等を、ストレージ層のCPUリソースにオフロードすることで高速にクエリを処理することが可能となっています。

画像引用先 : 20190428 AWS Black Belt Online Amazon Aurora with MySQL Compatibilityより

Paralell Queryの機能は現在以下のバージョン/インスタンスクラスで使用することができます。

• バージョン
  • MySQL5.6と互換性のあるAurora MySQLバージョン
• インスタンスクラス
  • db.r3の全てのインスタンスタイプ
  • db.r4の全てのインスタンスタイプ
  • db.r5でAurora MySQLサポートされる全てのインスタンスタイプ

Database Cloning

Database CloningはDBクラスタをバックアップから復元せずに、既存のDBクラスタをソースとしてクローンを迅速に作成することが出来る機能になります。
バックアップからの復元する場合、ストレージを復元する必要があるため復元までに時間を要しますが、Database Cloningでは既存のDBクラスタのストレージを参照する論理ポインタを利用することで高速にクローンを作成できます。

ソースDBクラスタ側でデータに変更がある場合はクローンDBクラスタ側から参照出来ないストレージ領域にデータを作成します。（下記画像の Page 1' が該当）

画像引用先 : AWSドキュメント Auroraのユーザガイド Aurora DB クラスターでのデータベースのクローン作成 より

逆にクローンDBクラスタ側で変更がある場合は、ソースDBクラスタ側から参照出来ないストレージ領域にデータを作成します。（下記画像の Page 4' が該当）

画像引用先 : AWSドキュメント Auroraのユーザガイド Aurora DB クラスターでのデータベースのクローン作成 より

しかし、Database Cloningにも制約事項があるため、要件が合うか確認する必要があります。

費用について

各費用の詳細に関してはこちらをご参照ください。以下はAuroraで発生する主な費用になります。

インスタンス

DBインスタンスを起動している時間単位で費用が発生します。1時間未満のDBインスタンスは10分を最小料金として秒単位で費用が発生します。

Auroraではリザーブドインスタンスを適用することができます。リザーブドインスタンスを利用することで、オンデマンド料金に比べ1年契約の場合最大45%、3年契約の場合最大66%のコスト削減が可能です。

ストレージ

ストレージに保存している容量(GB単位)とIOリクエスト(100万件単位)に対して費用が発生します。

バックアップ

バックアップストレージの容量(GB単位)に対して費用が発生しますが、Auroraデータベースストレージの合計の100%を超えるまで、バックアップストレージに対する追加料金は発生しません。また、バックアップの保持期間が1日で保持期間が超えたスナップショットが無い場合も追加料金は発生しません。

データ転送

受信、送信で転送されるデータに基づいて費用が発生しますが、以下の場合は無料になります。

• 同一AZ内のAuroraとEC2インスタンス間のデータ転送(AZが異なる場合は費用が発生します。
• DBクラスタがレプリケーション目的とするAZ間のデータ転送

最後に

以上、『AWS 再入門ブログリレー 2020』4日目のエントリ『Amazon Aurora』編でした。
明日 (8/6) はもこによる「Amazon SQS」の予定です。 お楽しみに！!