Amazon Auroraの耐障害性について調べてみた
Amazon Auroraの耐障害性について
プレビュー版のAmazon Aurora使えるようになったので色々試しています。Auroraには耐障害性（フォールト・トレランス）の仕組みがあり、何かしらの障害に対してサービスが継続的に停止しないような設計になっています。新しいDBエンジンということで、障害発生時にどのように対応すれば良いのか分かっていない方も多いかと思います。今回は、Auroraがどのような耐障害性を持っているのかご紹介したいと思います。
AuroraのDBクラスタ概念図
プライマリのインスタンス
Auroraは、複数のAZにまたがったDBクラスタを組むことができます。この際、DBへの接続方法はIPアドレスではなくRDSが発行するホスト名を用います。例）mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306
このホスト名は、プライマリのインスタンスを指していて、読み込みと書き込みの両方に対応しています。プライマリのインスタンスに障害が発生すると、フェイルオーバー先として新しいプライマリのインスタンスが起動します。ホスト名は変わりません。
Auroraのリードレプリカ
Auroraは、AZをまたいで最大15個のリードレプリカを設定することができます。リージョンをまたいだクラスタは作成できません。それぞれのリードレプリカのエンドポイントは独立したホスト名を持っています。（Route53でホスト名のリストを管理しておきたいですね。）
クラスタボリュームは、DBクラスタのデータの複数のコピーから構成されていますが、クラスタボリューム内のデータは、Aurora DBクラスタ内のプライマリ及び、レプリカの単一仮想ボリュームとして表現されています。プライマリのインスタンスが更新された結果として、全てのAuroraのレプリカは、最小のレプリカラグ（遅延）で同じ結果を返します。（通常は、プライマリの更新後から100ms未満で応答）
レプリカラグ（遅延）は、データベースの変化率に応じて変化します。つまり、データベースに書き込みが大量に発生している間は、レプリカラグが増加する場合があります。
Auroraレプリカは、読み込み操作のスケーリングと可用性の向上のためにあります。また、クラスタボリュームの読み込みに専念します。（ただし、レプリカがプライマリに昇格するとこの限りではない。）書き込み操作はプライマリのインスタンスによって管理されています。クラスタボリュームは、Aurora DBクラスタ内の全てのインスタンスで共有されていて、書き込みに関する操作が必要ありません。
Auroraのフェイルオーバー
Auroraは、障害発生時にフェイルオーバーすることができます。そして、Auroraレプリカは、フェイルオーバー先となりえます。もし、プライマリのインスタンスに障害が発生した場合、Auroraレプリカは、プライマリに昇格します。昇格に関する作業中、プライマリへ書き込みまたは読み込み操作を行った場合は処理を失敗して例外を返します。
もし、Auroraレプリカを設定していない場合には、フェイルオーバーの時間中に新規にプライマリのインスタンスを作成します。この場合は、レプリカから昇格するよりも時間が掛かります。
Auroraを利用するにあたって、高い可用性を維持する場合には、複数のAZにまたがって1以上のAuroraレプリカを作成することをオススメします。
Auroraのストレージ
Auroraのデータは、SSDドライブを利用して、単一の仮想ボリュームである、クラスタボリュームに保存されています。クラスタボリュームは、複数のAZ間でデータのコピーで構成されています。データは自動的に利用可能なAZ間で複製されているので、データを損失する可能性が少なく、高い耐久性を持っています。
Auroraのクラスタボリュームは、データ量に合わせて自動的にサイズを成長させることができます。最大で64TBまで対応しています。もし、最大ボリュームサイズを64TB以下に設定すれば、それ以上の成長を防止することができます。
Auroraの信頼性
Auroraは、信頼性・耐久性・耐障害性について設計されています。また、レプリカや複数AZへ配置することで、可用性を向上させるDBクラスタを組むこともできます。
ストレージの自動修復
Auroraは複数のAZでデータのコピーを保持しているため、ディスク障害に伴うデータ損失の可能性を最小化しています。Auroraは、自動的にクラスタボリュームの障害を検知します。ディスクボリュームのセグメントに障害が発生すると直ちに修復を開始します。Auroraが、ディスクセグメントを修復する際、セグメント内のデータが最新であることを確認します。その結果、データ損失を回避し、ディスク障害から回復するためのポイントイン・タイムリカバリを実行する必要性を下げることができます。
「残存」キャッシュ·ウォーミング
Auroraは、シャットダウンまたは障害発生後に再起動された後のデータベース再起動時に、「バッファプールキャッシュ」を「ウォームアップ」します。つまり、既知の一般的なクエリのためのページを持つバッファプール（表や索引のデータ・ページをディスクから読み取る際や変更する際に，そのデータをキャッシュに入れておくためのメモリー領域）をプリロード（事前読み込み）します。通常のデータベース利用で発生するバッファプールの必要性をウォームアップによりバイパス（迂回）することでパフォーマンスを向上させます。
Auroraのページキャッシュは、データベースと別のプロセスで管理されており、データベースから独立して「残存」することを可能にしています。データベースに障害が発生した場合、ページキャッシュは、データベース再起動時にバッファプールが最新の状態でウォーミングされたことを保証してメモリ内に残ります。
クラッシュリカバリ
Auroraは、ほぼ瞬時にクラッシュから回復し、アプリケーションにデータを提供するように設計されています。（さらっとスゴイこと言うね。。。）データベースがクラッシュした場合、直ぐに利用可能な状態にできるように、並行スレッドで非同期なクラッシュリカバリを実行します。
Auroraのフェイルオーバー時間
Auroraは、障害が発生すると、自動的に新しいプライマリのインスタンスにフェイルオーバーします。もし、レプリカが設定されていない場合、新しいプライマリのインスタンスを作成するため、約10分未満で完了します。もし、レプリカを設定済みであれば、レプリカを昇格させることでフェイルオーバーすることができるので、約120秒未満で完了しますが、多くの場合、60秒未満で完了します。このため、Auroraのレプリカを別AZに作成しておくことをオススメします。
Auroraのバックアップ
Auroraは、自動的にバックアップする機能が付いていて、継続的に差分で取っているため、リストアも高速です。この間、データベースへの接続は通常どおりできて、パフォーマンスへの影響もありません。バックアップ保持期間は、1〜35日まで指定できます。もちろん、任意のタイミングでスナップショットを作成することもできます。
MySQLとAuroraの比較
最後に、Amazon RDS for MySQLとAmazon RDS for Auroraの比較について表にしたいと思います。
| 機能 | Amazon RDS for Aurora | Amazon RDS for MySQL |
|---|---|---|
| 読み込みスケーリング | 最大15個。書き込み時のパフォーマンスへの影響は小さい | 最大5個。書き込み時のパフォーマンスへの影響は注意が必要。 |
| フェイルオーバーターゲット | 自動フェイルオーバー。データ損失無し。 | リードレプリカを手動で昇格させることで可能。データ損失の可能性あり。（MultiAZ構成ならデータ損失の可能性は低いけど書き込みのパフォーマンスに影響あり） |
| フェイルオーバー時間 | シングル構成なら10分未満。レプリカ構成なら2分秒未満（多くの場合1分未満）。 | 1-2分程度で完了することが多い。大きなインスタンスタイプを指定することで高速化。データサイズやテーブル数、コミットされていないトランザクションなどにも左右されます。 |
| MySQLバージョン | MySQL 5.6 | MySQL 5.1、5.5、5.6 |
| AWSリージョン対応 | プレビュー中のため、US East (N. Virginia：us-east-1) リージョンのみ | 全てのリージョン |
| MySQLストレージエンジン対応 | InnoDBのみ。他からのインポート時はInnoDBに強制変換されます。 | MyISAMとInnoDB |
| リードレプリカのストレージエンジン対応 | InnoDBのみ。 | MyISAMとInnoDB |
まとめ
簡単にまとめます。Auroraを利用する際は、レプリカを1つ以上作成して別AZに配置すること。書き込みはプライマリのみ。クラスタボリュームは、単一の仮想ボリューム。同時に複数のディスクに書き込まれる。キャッシュ機構は別管理で効率良い。レプリカラグは小さい。クラッシュリカバリ早い。フェイルオーバーは60秒未満。自動バックアップ。以上です。Amazon Auroraスゴイね！
