Amazon RDS を使った災害復旧戦略の実装

Amazon RDS (Relational Database Service) は、リレーショナルデータベースのセットアップ、運用、スケーリングを容易にできるマネージドサービスです。AWS のハイパフォーマンスなコンピューティングとストレージを基本としている Amazon RDS は、MySQL、SQL Server、PostgreSQL、MariaDB、および Oracle のデータベースエンジンをサポートしています。このサービスは、プロビジョニング、パッチング、モニタリング、そしてディザスターリカバリー (DR) のための、ソリューションを完備しています。このブログ記事では、自動バックアップ、手動バックアップ、そしてリードレプリカという、Amazon RDS が DR 対応のために提供する 3 つの機能をご紹介していきましょう。

DR プランの必要性とは？

実稼動状態にあるシステムにとって、想定外のイベント発生からも復旧を可能にするための、注意を怠らないことは重要です。Amazon RDS は、Multi-AZ の非常に豊富な設定項目を提供しています。とはいえ、自然災害、悪意のある利用者、そしてデータベースの論理的な破損などの、全ての可能性に対処できるわけではありません。ビジネス機会を失わないためには、DR プランのデザインとテストをしっかり行うべきでしょう。

RTO と RPO について知る

DR プランを作り上げる時、リカバリータイムオブジェクティブ (RTO) と、リカバリーポイントオブジェクティブ (RPO) の 2 つは、考慮すべき主要なメトリクスとなります。RTO は、災害が発生した後、業務再開にどの位の時間を要するかを表します。RPO も同じ様に時間で表現されますが、こちらは、災害が発生した際にどの規模のデータが失われるかを表します。例えば、RPO が 1 時間であるということは、災害の発生により 1 時間分に相当するデータが失われる可能性があるという意味です。

Amazon RDS の各機能は、それぞれ違うコストポイントにおいて、違うRTO と RPO をサポートします。

機能	RTO	RPO	コスト	スコープ
自動バックアップ	グッド	ベター	低	単一リージョン内
手動スナップショット	ベター	グッド	中	異なるリージョン間
リードレプリカ	ベスト	ベスト	高	異なるリージョン間

この表からお分かりの通り、自動バックアップは単一の AWS リージョン内だけに制限されています。一方、手動スナップショットとリードレプリカは、複数リージョンをまたぐことができます。

Amazon Aurora

今回のブログ記事では、Amazon Aurora を明示的には扱いません。Amazon Aurora の DR 機能は微妙に違っているからです。それでも、ここでお伝えするテクニックの多くは、Aurora DB クラスターにも応用可能です。詳細については、 Amazon Aurora のドキュメントをご参照ください。

Amazon RDS バックアップ

データベースの DR プランにとって、バックアップは中核となる要素です。Amazon RDS は、自動バックアップと手動スナップショトという、異なる 2 種類のバックアップ方法をサポートしています。

Amazon RDS バックアップには、次のようなルールがあります。

バックアップが実行されるには、DB インスタンスの状態を ACTIVE にする必要があります。
同じリージョン内の同じ DB インスタンスに対しコピーが実行されている間は、自動バックアップおよび自動スナップショットは実行されません。
DB インスタンスの最初のスナップショットには、その DB インスタンスのすべてのデータが保持されます。
最初のスナップショット後のスナップショットは、インクリメンタルスナップショットです。つまり、最も後に変更されたデータだけが、キャプチャーおよび保存されます。
Multi-AZ 設定である場合は、本体への影響を少なくするため、バックアップはスタンドバイ中に実行されます。

注: 自動バックアップと手動スナップショットは、Amazon RDS サービスが所有および管理をする S3 バケット内に保存されます。つまり、Amazon S3 コンソールからこれらを見ることはできません。

バックアップメカニズムとバックアップストレージに関する詳細情報については、「バックアップの使用」をAmazon RDS ユーザーガイドでご確認ください。

自動バックアップ

Amazon RDS の自動バックアップ機能は、デフォルトで有効化されます。Amazon RDS は、DB インスタンスのストレージボリュームスナップショットを作成し、個々のデータベースではなく DB インスタンス全体をバックアップします。つまり、最初に行われるバックアップは、インスタンス全体の情報で構成されます。その後に続くバックアップは本質的にインクリメンタルで、前回バックアップの後に変更されたブロックだけを含むスナップショットを保存します。それぞれのスナップショットは、再構築に必要な全スナップショットデータブロックを指すポインターを保持しています。初期に記録されたスナップショットを削除しても、最低 1 つのスナップショットがデータを参照している限り、そのデータが失われることはありません。

自動バックアップはなぜ必要?

自動バックアップを使うことには、いくつかのメリットが存在します。

データは、Amazon RDS サービスにより所有および管理される、S3 バケット内に格納されます。
手動でバックアップを行い、それを安全な場所に保管するための時間確保に迫られることはありません。
実行されるタイムラインは、日ごと、週ごと、月ごとの中から選択できます。
人為的および自然に発生する事件 (例えば、ウイルス、ソフトウエアの不具合、停電など) の影響が軽減されます。
そして何より、価値あるデータを失う事がもたらす不利益を防げます。

自動バックアップウィンドウ

自動バックアップウィンドウは、自動バックアップを作成するための、週に一度のタイムピリオドです。このウィンドウは、各 AWS リージョン内の 8 個の時間ブロックからランダムに選択されます。しかし、サーバーの過剰負荷を避けるために、このバックアップウィンドウは処理量が最小になる時間に設定することを強く推奨します。各リージョンごとの時間ブロック一覧表については、「バックアップウィンドウ」を Amazon RDS ユーザーガイドでご確認ください。

自動バックアップの保存期間

バックアップの保存期間は、その間にポイントインタイムのリストア (PITR) を行う事ができる時間ウィンドウです。DB インスタンスを作成する度に、異なるバックアップ保存期間を設定できます。また、この保存期間はいつでも修正が可能です。

詳細情報については、「バックアップの保存期間」をご参照ください。

手動スナップショットと自動バックアップの間には、いくつかの違いがあります。

手動スナップショットの制限 (1 つのリージョンで 100 スナップショットまで) は、自動バックアップには適用されません。
バックアップ保存期間は、手動スナップショットに適用されません。
手動スナップショットは自動的に削除されないので、明示的に削除する必要があります。

インスタンス作成時に自動バックアップを設定する

[Backup★] タブがConfigure advanced settings★セクションにあるので、[Backup retention period★] と [Backup window★] を設定します。
バックアップのための [Start time★] を設定し、[Duration★] には、バックアップ終了までデータベースが許す長さを時間単位で設定します。バックアップウィンドウは、ピークアワーを外して設定する方が望ましいでしょう。

自動バックアップの設定の変更

自動バックアップの設定を変更するには、次のステップに従います。

自動バックアップの設定を変更したい DB インスタンスをクリックし、[Modify ★] ボタンをクリックします。
[Backup★] のところまでスクロールダウンし、必要な変更を [Backup retention period★] タブと [Backup window★] で行います。
[When to apply modifications★] の下で必要なオプションを選択し、[Modify DB instance★] をクリックします。

時間上の特定ポイントにリストアする

ポイントインタイムリカバリ (PITR) は、データベースを特定の日時と同じ状態に復元する処理です。

ご使用の DB インスタンスで自動バックアップが有効化されていると、Amazon RDS は 1 日の全データをスナップショットとして自動的に保存します。このスナップショットは、設定されたバックアップウィンドウの間に実行されます。同時にこの処理は、Amazon S3 へのトランザクションログを、(DB インスタンスが更新される) 5 分間に一度キャプチャーします。トランザクションログの記録は、DR のプロセスと PITR にとって重要な事項です。ポイントインタイムリカバリを初期化すると、指定する特定の時刻に DB インスタンスを復元するため最適な日次バックアップに、トランザクションログが適用されます。

このインストラクションについては、「特定の時点への DB インスタンスの復元」をAmazon RDS ユーザーガイドでご確認ください。

自動バックアップの保持

DB インスタンスの削除を行う際に、自動バックアップの保持を選ぶことができます。この機能は、後に DB インスタンスを復元するか決断する場合に便利です。保持されている自動バックアップには、DB インスタンスからの自動スナップショットとトランザクションログが含まれています。同時に、アクティブなインスタンスとして復元する際に必要な、(割り当てられたストレージや DB インスタンスクラスなどの) DB インスタンスに関するプロパティも含まれます。保持されている自動バックアップは、AWS マネジメントコンソールや、Amazon RDS API、そして AWS CLI を使って復元もしくは削除することができます。「自動バックアップの保持」がAmazon RDS ユーザーガイドで解説されているので、制限事項や自動バックアップ保持の推奨事項については、そちらをご参照ください。

データベーススナップショット

データベーススナップショットは、 (ユーザーが起動する) 手動のフルバックアップとして機能する DB インスタンスの完全なバックアップです。このバックアップは Amazon S3 内に保存され、明示的に削除するまで保持されます。これらのスナップショットは、異なるリージョンやアカウントにコピーおよび共有が可能です。DB スナップショットには、データファイルや一時ファイルなどすべての DB インスタンスが含まれるため、インスタンスのサイズがスナップショット作成に要する時間に影響を与えます。

Single-AZ DB 上で DB スナップショットを作成すると、短いI/O 中断の原因になります。この I/O 中断は、インスタンスのサイズやご使用になっている DB インスタンスのクラスに応じて、数秒から数分間継続することがあります。Multi-AZ DB インスタンスは、この I/O 中断から影響を受けません。このバックアップはスタンバイから取得されるからです。

Amazon RDS ユーザーガイド で「DB スナップショットの作成」についてご確認ください。

スナップショットの表示

Amazon RDS コンソールで、スナップショットを見る事ができます。[Snapshots★] をクリックし [Manual Snapshots★] を選択します。一覧の中からスナップショットを 1 つ選びます。

スナップショットのコピーと共有

Amazon RDS では、自動もしくは手動の DB スナップショットをコピーできます。コピーされたスナップショットは手動スナップショットとなります。スナップショットのコピーは、同じ AWS リージョン内でもリージョンをまたいでも行え、さらに、AWS アカウントをまたいでもコピーが可能です。DB スナップショットを別の AWS リージョンにコピーした場合、その AWS リージョンに保持される手動 DB スナップショットを作成することになります。DB スナップショットを元の AWS リージョン外にコピーすると、Amazon RDS のデータ転送料金が発生します。

自動スナップショットは、別の AWS アカウントへそのままコピーすることはできません。代わりに、先ずスナップショットを共有し、次に別アカウントへコピーする、2 ステップの処理でコピーできます。

コピーとそれに含まれる制限事項についての詳細は、「スナップショットのコピー」を Amazon RDS ユーザーガイドでご確認ください。

Amazon RDS スナップショットのアカウントをまたぐ共有

Amazon RDS では、DB スナップショットもしくはクラスタースナップショットを、別の AWS アカウントと共有することができます。「良くない利用者」に稼働中アカウントの運用が妨害される懸念がある場合、安全が保障された他のアカウントとスナップショットを共有することは助けとなります。手動 DB スナップショットは、20 個までの他のアカウントと共有できます。

自動 Amazon RDS スナップショットは、そのまま他の AWS アカウントと共有はできません。自動スナップショットを共有するには、まず手動バージョンとなるコピーをそのスナップショットについて作成します。その後、コピーは他のアカウントと共有が可能になります。
Transparent Data Encryption (TDE) やタイムゾーンなど、永続もしくは固定オプションを含むカスタムオプショングループを使用する、 DB インスタンスの手動スナップショットは共有できません。
デフォルトの Amazon RDS エンクリプションキー (aws/rds) を使用するスナップショットも、そのまま共有することはできません。代わりに、カスタムのエンクリプションキーを選択してスナップショットをコピーした後に、カスタムキーとそのスナップショットを共有することができるようになります。

アカウントをまたぐスナップショットの共有の詳細については、「DB スナップショットの共有」を Amazon RDS ユーザーガイドでご確認ください。

DB スナップショットからの復元

何かの災害が発生した時は、DB スナップショットから復元することで、新しい DB インスタンスを作成することができます。DB インスタンスの復元には、DB スナップショットの中から復元したい名称を選択します。次に、新たに作成した DB インスタンスの名前を指定します。復元プロセスに関しては、いくつかの注意事項があります。

既存の DB インスタンスには、DB スナップショットを復元できません。復元の際は、新しい DB インスタンスを作成してください。既存の DB インスタンスと同じ名前を使いたい時は、先に既存インスタンスを削除するか名前を変更する必要があります。
DB スナップショットを、元のインスタンスとは違うストレージタイプで DB インスタンスに復元することは可能ですが、復元の処理には時間がかかります。新しいストレージタイプへのデータ移行には、追加的な処理が必要だからです。
暗号化された上で共有された DB スナップショットから、 DB インスタンスに復元する事はできません。ただし、その DB スナップショットのコピーを作り、そのコピーから DB インスタンスに復元することは可能です。
また、保存してある DB スナップショットから、パラメータグループを維持するのは良い方法です。そうすることで、DB インスタンスを正しいパラメータグループで復元できます。
デフォルトでは、DB スナップショットから復元を行う場合、そのスナップショットに関連付けられたオプショングループが、復元される DB インスタンスにも関連付けられます。そこで復元された DB インスタンスには、別のオプショングループを関連付けることもできます。しかし、新しいオプショングループには、元のオプショングループと同じ、固定もしくは永続のオプションを設定する必要があります。

詳細な方法については、「DB スナップショットの復元」を Amazon RDS ユーザーガイドでご確認ください。

クロスリージョンでの復元

先に述べた通り、リージョンをまたいで DB スナップショットを復元するには、まず移動先のリージョンにスナップショットをコピーする必要があります。次に、DB スナップショットを DB インスタンスに復元できるようになります。

AWS Backup との統合

Amazon RDS DB スナップショットは、AWS Backup との統合が可能です。AWS Backup は、クラウド上やオンプレミスで、AWS サービスをまたぐデータバックアップを一元化および自動化できるよう作られた、総合的なバックアップサービスです。AWS Backup を使うことで、AWS リソースについてのバックアップポリシーの設定やバックアップ動作の監視が、一元的に行えるようになります。詳細については、「AWS Backup」をご参照ください。

リードレプリカ

MariaDB、MySQL、 PostgreSQL、Oracle 向けの Amazon RDS は、ソースデータベースのリードレプリカ作成に対応しています。Amazon RDS は、リードレプリカを作成する時、ソースである DB インスタンスのスナップショットをまず作成し、それから読み込み専用のインスタンスを作成します。さらに、Amazon RDS は DB エンジンの非同期レプリケーション手法を用いることで、ソース DB インスタンスに変更があった時は必ず、リードレプリカの更新を行います。リードレプリカは、読み込み専用として接続が可能な DB インスタンスとして動作します。アプリケーションは、通常の DB インスタンスと同じ方法で、リードレプリカに接続できます。Amazon RDS は、ソース DB インスタンス内の全オブジェクトを複製します。デフォルトでは、ソース DB インスタンスと同じインスタンスとストレージタイプを使い、リードレプリカも作成されます。しかし、ソース DB インスタンスと異なるストレージタイプを持つリードレプリカを作成することも可能です。一つの DB インスタンスについて、最大 5 個のリードレプリカを作成することができます。

ソース DB インスタンスの負荷を軽減する目的でリードレプリカを使うことに加え、稼動中の DB 環境のための DR ソリューションを、リードレプリカにより実装することもできます。ソース DB インスタンスに障害が起きた時、リードレプリカをスタンドアロンのソースサーバーに昇格することが可能です。また、リードレプリカは、ソースデータベースと違うリージョンに作成することもできます。別リージョンにリードレプリカを置くことで、リージョン内で可用性の問題が発生した場合にも、確実なバックアップとなり運用を維持できるようになります。

リードレプリカを監視する上で重要なメトリクスに、レプリカラグがあります。これは、レプリカがソースデータベースからどの程度の時間を遅延しているか示す値です。このレプリカラグは、復旧に影響します。レプリカラグは、ソースおよびデスティネーションのリージョン間にあるネットワークレーテンシーにより変化します。また、これは複製中のトラフィックの量によっても影響を受けます。リードレプリカは実行できる DB インスタンスを持つため、災害が発生した後の復旧に要する時間は短めです。しかし、この目的でリードレプリカを使用することは、自動バックアップやデータベーススナップショットを用いる場合より基本的にコストがかかります。

リードレプリカの作成や、リージョンをまたぐリードレプリカのインストラクションについては、「リードレプリカの使用」を Amazon RDS ユーザーガイドでご確認ください。

リードレプリカの昇格

Amazon RDS の Multi-AZ 設定とは違い、リードレプリカのフェイルオーバーは自動プロセスではありません。リージョンをまたいでリードレプリカを使用している場合は、リージョン間で AWS リソースをスイッチしようとしていることを認識する必要があります。リージョン間のトラフィックには遅延が発生し得ますし、アプリケーションの再設定も複雑なものとなります。

インストラクションについては、「MariaDB、MySQL、および PostgreSQL DB インスタンスのリードレプリカの使用」を Amazon RDS User Guideでご確認ください。

リージョンをまたいで、リードレプリカをスタンドアロンのインスタンスとして昇格した後、これを元のリージョンに戻す必要が生じた時は、新しいリードレプリカを作成する必要があります。Amazon RDS の Multi-AZ 設定とは違い、この動作は自動では行われません。

DR プランのテスト

DR プランが役に立つのは、定期的にテストと検証が行われる場合だけです。DR プランをテストすることで、潜在的な問題やギャップの特定につながり、修正対策を取ることができます。完全な DR プランには、データベースリソースだけでなく、アプリケーションインフラストラクチャ―のすべてが含まれます。DR プランの完全なテストには、大きな時間とリソースを割く必要がありますが、実際に必要となった時には、その動作へ信頼を寄せられるようになります。

まとめ

今回の記事では、Amazon RDS を使って DR 戦略を実装する上でのベストプラクティスをいくつかお話してきました。ここでは、自動バックアップ、手動バックアップ、およびリードレプリカを使う DR のため、Amazon RDS 上に実装できる基本的なフレームワークを提供しています。また、ポイントインタイムリカバリー、Amazon RDS のアカウントをまたいだスナップショット共有、そしてリージョンをまたいだリードレプリカの作成など、主要なコンセプトを取り上げました。

このブログ記事についてのご意見やご質問は、コメントセクションからお寄せ下さい。

著者について

Anuraag Deekonda は、AWS Professional Services チームのアソシエートコンサルタントです。彼は、AWS クラウドにおけるスケーラブルかつ可用性と安全性の高いソリューションを、お客様のために構築する仕事に従事しています。彼の専門分野は、同種および異種のオンプレミスデータベースをAmazon RDS や Aurora PostgreSQL へ移行する技術です。

Amazon Web Services ブログ