この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Amazon Aurora Global Database はAmazon Aurora クラスターを複数の AWS リージョンにまたがって構築でき
- AWSリージョン障害時の災害復旧(DR;Disaster Recovery)
- 世界中からデータベースを高速に読み書き(データのローカリティ)
などを実現できます。
今回は、大阪リージョンフルオープン記念として、東京・大阪リージョン間で Aurora Global Database のフェイルオーバーを試してみました。
Aurora Global Database の構成パターン
Aurora Global Database はプライマリ・リージョンから別リージョンへ低レイテンシーにデータがレプリケートされます。
プライマリリージョンでは読み書きが可能です。
ストレージベースでレプリケートされるセカンダリリージョンでは主に以下の３パターンがあります。
1. データベースをウォームスタンバイ
障害時に迅速に切り替えられるように、バックアップ先でデータベースを起動しておきます。
データベースへの読み書きはプライマリリージョンに対して行います。
障害時にはAurora Global Database をセカンダリにフェイルオーバーさせます。
フェイルオーバー後、旧プライマリの Writer エンドポイントは Inactive になり、名前を引けなくなります(dig 結果はstatus: NXDOMAIN)。
フェイルオーバー後、以下のエンドポイントの調整を行います。
- アプリケーションのエンドポイントをフェイルオーバー先の書き込み用エンドポイントに変更
2. データのローカリティ目的で書き込み転送を有効
グローバルに展開するサービスでは、ユーザーに近いリージョンでリクエストを処理することで、プライマリリージョンと通信するよりも低いレイテンシーでデータベータ操作が行なえます。
Aurora Global Databaseの書き込み転送機能を有効にすると、セカンダリリージョンでは読み込みだけでなく書き込みも可能になります。 セカンダリではあくまでも Reader エンドポイントだけが存在し、書き込み転送を有効にする場合も、Reader エンドポイントに対して Read/Write します。
読み込みはローカルリージョン、書き込みはプライマリリージョンに分けると、整合性の管理が難しくなりますが、この転送機能を有効にすることで、読み書きは透過的に処理され、アプリケーションは読み書きのエンドポイントの切り替えや整合性の管理から開放されます。
障害時にはAurora Global Database をセカンダリにフェイルオーバーさせます。
フェイルオーバー後、以下のエンドポイントの調整を行います。
- セカンダリからプライマリに切り替わったリージョンでは、エンドポイントをWriterに変更
- プライマリからセカンダリに切り替わったリージョンでは、書き込み転送を有効にし、エンドポイントをReaderに変更
- セカンダリのままのリージョンでは、対応不要
3. ストレージだけリージョン間レプリケートしてTCO削減
Aurora Global Database のレプリケーションはストレージベースです。 この特性を活かし、TCOの低さが優先される場合は、セカンダリリージョンにインスタンスを起動せずに、レプリケーションだけを行います。
この構成(ヘッドレス)はコンソールからは構築できません。
- リージョナルクラスターの構築
- グローバルクラスター化
- セカンダリリージョンの追加
を CLI から操作します。 詳細は次の記事を参照ください。
- Aurora Global Databaseをセカンダリークラスターにインスタンスを立てずに作成してみた | DevelopersIO
- Creating a headless Aurora DB cluster in a secondary Region - Amazon Aurora
障害時には、セカンダリリージョンでインスタンスを起動してフェイルオーバーの準備をします。 この操作もコンソール対応していないため、先の記事を参考ください。
セカンダリでインスタンスが起動後はパターン1と同じ構成になります。あとは、パターン1と同じ方法でフェイルオーバーします。
Aurora Global Database をリージョン間でフェイルオーバーするには?
Aurora Global Databaseの大雑把なフェイルオーバーのパターンを把握したところで、プライマリ-セカンダリ間の切り替え手順を確認します。
Aurora Global Database のリージョン間フェイルオーバーするには
- AWSがマネージドで行う計画的な手順
- ユーザーが手動で行う緊急手順
の2通りがあります。
1. 計画的なフェイルオーバー
計画的なフェイルオーバーは、公共・金融業界などの規制へのコンプライアンスを目的としたプライマリリージョンの変更や災害復旧訓練や計画的なフェイルバックを目的としています。
コンソールからフェイルオーバー命令をするだけです。
データロストはありません(目標復旧時点/RPO=0)。 フェイルオーバー中はデータ更新が行なえず、この切替時間が目標復旧時間(RTO)に該当します。
やってみた
プライマリリージョンで Action から「Fail over global database」を選択します。
次に、フェイルオーバー先リージョンを選択するだけで作業は完了です。
- プライマリのデータ更新停止
- セカンダリへデータをレプリケート
- プライマリの切り替え
といった一連のフェイルオーバー手順がフルマネージドで行われます。
この機能は、フェイルバックにも有用です。
2. 予期しないフェイルオーバー
予期しないフェイルオーバーは 計画的なフェイルオーバーを実施できない場合の緊急用のフェイルオーバー方法です。各操作はユーザーが行います。
利用可能なセカンダリリージョンの中から新たなプライマリリージョンを選定し、Aurora Global Database として再構築します。AWSの公式ドキュメントでは "detach and promote" と表現されることもあります。
新プライマリにどこまでレプリケートされていたかによって RPO が決定し、ユーザー主体の再構築時間によって RTO が決定します。
やってみた
フェイルオーバー先リージョンを選出します。
次に、そのリージョンのDBクラスターを Global Database から切り離し("detach")、リージョナルクラスター化します。
次のこのリージョナルクラスターを Aurora Global Database 化("promote")します。
最後に、このクラスターをソースとして、複数リージョンにまたがって Aurora Global Database を再構築します。
まとめ
Aurora Global Database を利用すると、Amazon Aurora クラスターを複数の AWS リージョンにまたがって構築でき
- AWSリージョン障害時の災害復旧(DR;Disaster Recovery)
- 世界中からデータベースに高速に読み書き(データのローカリティ)
を簡単に実現できます。
今回は、Aurora Global Database のいくつかの構成例を元に、Aurora Global Database をリージョン間でフェイルオーバーする手順を紹介しました。
複数リージョンにまたがってデータベースを展開する方法は、Aurora Global Database以外にも
- RDS/Aurora をリージョン間レプリケーション
- Amazon Aurora Multi-Master
- Amazon DynamoDB global table
- 独自に構築
など、豊富にあります。
RDB 系に限定すると、最近開催された次のセミナー資料は情報がまとまっています。
システムをマルチリージョン展開する場合、データベースだけでなく、ネットワーク・アプリケーションなども絡むため、複雑度は膨れ上がります。
複数リージョン展開する理由、障害時の優先事項などをよく検討の上、構成や運用手順を詰めていただければと思います。
それでは。
27
