はじめに
「人生をかけて仕事をするのではなく、
私は人生をかけて生活をして、それを仕事に落とし込みたい」
こんにちは、矢田です。本記事では、稼働中のAmazon Aurora MySQLデータベースからディザスターリカバリー（DR）用のクロスリージョンレプリカを作成する方法と作成時の注意点についてご紹介します。
AuroraのDR環境構築の方法として、Amazon Aurora Global Databaseが採用されることが多いですが、今回クロスリージョンレプリカを作成する機会があったため、作成方法と注意点をご紹介します。
Global Databaseについては、以下をご参照ください。
用語解説
DR（Disaster Recovery）
災害復旧のことで、自然災害やシステム障害が発生した際に、システムやデータを迅速に復旧させるための仕組みや手順を指します。
バイナリログ
MySQL標準の機能であり、データベースに対する全ての変更履歴（データの追加・更新・削除、テーブル構造の変更など）を記録するログファイルです。Auroraでは、主にデータベースのレプリケーションで使用されます。
AWS Secrets Manager
データベースの認証情報やAPIキーなどの機密情報を安全に保存・管理するAWSサービスです。アプリケーションからSecrets ManagerにAPI接続を行い、データベースの認証情報を安全に取得、利用する用途などで使用されます。自動的なパスワードローテーション機能なども提供します。
参考：Amazon Auroraで、IAMデータベース認証とAWS Secrets Managerによるパスワードの自動ローテーションを設定してみる - サーバーワークスエンジニアブログ
Amazon Auroraとは
Amazon Auroraは、AWSが提供するフルマネージドなリレーショナルデータベースサービスです。複数のデータベースインスタンスから構成される クラスター という単位で管理されます。データベースエンジンとしてMySQLとPostgreSQLに互換性があり、AWSの物理インフラに最適化されているため、従来のデータベースと比べても高いパフォーマンスと可用性を実現します。
| データベースインスタンスの種類 | 説明 |
|---|---|
| Writerインスタンス | クラスターの中で読み書き処理を担当するデータベースインスタンス |
| Readerインスタンス | クラスターの中で読み取り処理だけを担当するデータベースインスタンス |
主な機能
自動スケーリング
データベースのストレージは、最大128TBまで自動で拡張するためスケーリングの運用作業などは不要になります。
自動バックアップ
自動バックアップは、最大35日間保持することができます。それ以上の期間保管したい場合は、手動スナップショット（期限なし）を取得し、必要に応じて任意のS3バケットにエクスポートします。
バックトラック機能
データベースを過去の特定の時点まで巻き戻すことができるため、作業ミスなどの切り戻しが可能となる。Aurora MySQLでのみ使用できる。
ポイントインタイムリカバリー
自動バックアップのデータを使用して、既設のデータベースクラスターとは別に新しいデータベースクラスターを作成することができる。最短5分〜35日前まで。
クロスリージョンレプリカとは
AWSの異なるリージョンにAuroraクラスターのコピーを作成することのできるAurora MySQLエディションの機能です（PostgreSQLエディションは非対応）。プライマリデータベースとクロスリージョンレプリカ間でデータ同期を行うことで、リージョン規模の障害発生時にも対応することができます。
実際にクロスリージョンレプリカを作成してみる
（※注意：実際の作業時は事前に手動でのバックアップ取得を推奨します）
1. クラスターパラメーターグループの確認
「データベース」のメニューからデータベースクラスターを選択し「設定」タグから紐づいているDBクラスターを確認できます。
2. クラスターパラメーターグループでバイナリログの有効化
「パラメーターグループ」のメニューからクラスターパラメーターグループを選択し、「編集」をクリックします。 検索窓に検索窓にbinlog_formatと入力することで、バイナリログの設定値が表示されます。 値がOFFになっている場合は、以下のように設定変更が必要となります。
| パラメータ名 | 値 |
|---|---|
| binlog_format | MIXED ※ |
※ ロギング形式の詳細については、MySQLの公式ページをご参照ください
- バイナリログのログの保持期間について：今回、バイナリログの保持期限（binlog retention hours）はしていませんが、設定することが推奨されています。 Aurora では保持期間を指定せずとも少しの間はバイナリログが保持されます。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/mysql-stored-proc-configuring.html
3. データベースインスタンスの再起動
バイナリログ設定の変更を反映するため、データベースインスタンスの再起動を行います。 「データベース」のメニューからデータベースインスタンスを選択して、「アクション」→「再起動」を実行します。
プライマリインスタンス（ライター）の再起動を実施した時点で、数十秒から数分のダウンタイムが発生します。
4. クロスリージョンレプリカの作成
Amazon Auroraの管理画面から稼働中のデータベースクラスターを選択して、「アクション」→「クロスリージョンリードレプリカの作成」を選択します。
！！！
データベースクラスターの作成時にSecret Managerによるパスワード管理を有効にしていると、クロスリージョンリードレプリカの作成ができません。
5. 認証情報管理を変更して、再作成
「データベース」のメニューからデータベースクラスターを選択し「変更」、認証情報管理を「セルフマネージド」に変更します。
再度、データベースクラスターを選択して、「アクション」→「クロスリージョンリードレプリカの作成」を選択します。
6. クロスリージョンリードレプリカの詳細設定
リージョンの選択
クロスリージョンレプリカを配置するリージョンを選択します。 配置先となるリージョンには、あらかじめVPCとデータベースサブネットを作成しておく必要があります。
ソースとなるデータベースインスタンスの選択
クロスリージョンレプリカを構成する元となるデータベースインスタンスを選択します。 インスタンス識別子、クラスター識別子を設定したら、画面下部の「作成」をクリックします。
そのほかの設定値については、以下のAWS公式ドキュメントをご参照ください。
7. クロスリージョンレプリカの確認
大阪リージョンに移動して、クロスリージョンレプリカの作成を確認します。
クロスリージョンレプリカ作成時の注意点
バイナリログの有効化によるデータベースの再起動
- バイナリログの有効化が必要: クロスリージョンレプリカを作成するためにバイナリログの有効化が必要です
- バイナリログはデフォルトでは無効: デフォルトのパラメーターグループではバイナリログは無効です
- バイナリログの反映に再起動が必要: 稼働中のデータベースクラスターのバイナリログ設定を変更するためには、データベースの再起動が必要となります。データベースの再起動には数分程度のダウンタイムが発生するため、計画的な設定変更が必要です
AWS Secrets Managerにより認証情報の管理
稼働中のデータベースクラスターがAWS Secrets Managerで管理されている場合、クロスリージョンレプリカを作成することができません。 データベースクラスターがSecrets Managerを認証情報管理に使用している場合、対応を慎重に検討する必要があります。
まとめ
Amazon AuroraのクロスリージョンレプリカをDR環境として活用することで、手軽にデータの安全性を高めることができます。 ただし、DR環境構築の検討段階で、以下のようなポイントを考慮する必要があります。
ポイント
- 計画的な実行: バイナリログ有効化による再起動を考慮したスケジューリングが重要です
- 認証情報管理: Secrets Managerの管理対象除外への適切な対応が必要です
- 事前検証: テスト環境での動作確認とフェイルオーバー手順の検証を行いましょう
ミッションクリティカルなシステムのDR環境の構築は、Business Continuity Plan（BCP）の観点から非常に重要です。システム要件に沿って適切にAmazon AuroraのDR環境を構築することでデータの安全性を高めることができます。
それでは、またお会いしましょう。
