SCSKの畑です。
引き続きデータベース関連のトピックです。今回こそ小ネタです。ちなみに、本エントリの内容で言及している RDS は、先般のエントリで言及していたものと同一です。
小ネタ本題
本エントリのタイトルに書いてある通りです！で終わらせられる程度の内容ではあるのですが、幾つか補足しながら説明していきます。
まず、当初は RDS の配下に Aurora Global DB をレプリカとして構成することを検討していました。Aurora Global DB の大阪リージョンのレプリカをバックアップとして使用することで、以下2点の要件を満たすことができると考えました。
- アプリケーションからの read-only トラフィックを同リージョン（東京）の Aurora リードレプリカにオフロード
- 必要に応じてリーダーを増やしてスケールアウト
- 別リージョン（大阪）にバックアップを取得
- 可能な限り障害直前のデータを復旧したいため、RPO 要件は数秒程度（ただしレプリケーション遅延による影響は許容）
が、色々調べたり試したりした限りだと、AWS コンソールや AWS CLI などからの構成はできなさそうということが分かりました。コンソールの操作メニューに該当するものがなく、AWS のドキュメントなどを見ても Aurora Global DB をレプリカとして構成する（できる）ことへの言及が一切なかったためです。そもそものサービスの位置づけからしても、RDS のレプリカとして構成することは想定されていないのかなとも思いました。
そこで、Aurora Global DB の代わりに 同一リージョン内に Aurora レプリカを作った上で、クロスリージョンでのバックアップ用途には RDS のクロスリージョンレプリカを使用する方針としました。
こちらは AWS コンソールからもサクッと試せそうだったので、RDS の配下に Aurora レプリカを構成した状態で、RDS のクロスリージョンレプリカを作ろうとしたところ・・
このようなエラーが出てしまい作成に失敗してしまいました。本エントリのタイトルに記載した通りの文面で、これはひょっとして仕様的にダメなやつなのでは？ということで AWS サポートに裏取りしてみたところやはり NG。やむを得ず別の方式を検討することに。
別リージョンにバックアップを取得するだけであれば、クロスリージョン自動バックアップの仕組みが使えるのでまずその案を持っていこうとしたものの、RPO が最大30分程度になってしまう制約があり、上記バックアップの要件を満たさなかったため NG。
よって、他の方法でクロスリージョン（大阪）に RDS のレプリカを構成する他ないということで、構成案をいくつか検討したところ最終的には以下 2 案が残りました。
案1：RDS クロスリージョンレプリカの前に中継用の RDS リードレプリカを挟む構成
先述したエラーの内容からして「同一」RDS の配下に Aurora レプリカと RDS クロスリージョンレプリカが同居できないだけなのでは？と推測し、以下のように RDS クロスリージョンレプリカとの間に同リージョン内の RDS リードレプリカを挟むような構成にした結果、問題なく構成できました。
全てのレプリケーションをAWS マネージド構成にできるのがメリットな反面、元々の構成案と比較して中継用の RDS が1個増えてしまうというのがデメリットとなります。
案2：大阪リージョンに Aurora MySQL を作成し、手動で MySQL レプリケーションを組む構成
逆に、AWS マネージドのレプリケーション構成にこだわらなければシンプルにこういう構成にできるよね？というのがこちらの案となります。RDS ⇒ Aurora MySQL（大阪リージョン）間は手動で MySQL レプリケーションを構成しています。
メリット・デメリットはちょうど案 1 の裏返しのような内容となりますので割愛します。
お客さんも交えてどちらの案を採用するか検討した結果、構成のシンプルさや 中継用の RDS のコストを重く見て、最終的に案 2 を採用することとなりました。
余談：AWS マネージドレプリケーションと手動レプリケーションの差異について（MySQLの場合）
最後にこの点について軽く言及して終わりたいと思います。私自身も具体的な差異として思いつくのはフェイルオーバ操作の可否くらいだったので、AWS サポートにも確認しながらざっくりまとめてみました。調べながら、データ不整合によるレプリケーション停止からの自動復旧とかを AWS マネージドの範疇でやってくれたら凄いんだけどなーと思いながら見ていたんですけど、さすがにそういう機能はないようです。（レプリケーションのエラーを契機にレプリカを再作成するくらいの力技であれば一応できてしまいそうですけど）
なお、Aurora に閉じた項目については記載していません。
| AWS マネージドレプリケーション | 手動レプリケーション |
|---|---|
| AWS コンソールや AWS CLI などを使用して構成可能 | RDS/Aurora 内のストアドプロシージャを使用して構成 ※MySQL 自体のレプリケーション構成用 SQL 文は使用できない |
| AWS コンソールや AWS CLI などからフェイルオーバ（昇格）のオペレーションが可能 | レプリカの昇格やアプリケーションの接続先変更など、フェイルオーバに相当する一連の作業を手動で実施 |
| CloudWatch メトリクスによるレプリケーションの統合監視が可能（レプリケーション遅延の監視やアラート通知なども可能） | MySQL ログやレプリケーション監視用の SQL を使用した監視・通知の作りこみが必要 |
上記内容で最もインパクトがあるのはフェイルオーバ周りの挙動だと思いますが、上記案 2 における影響は実質的に監視部分のみであるため、特に大きな問題はないよねという結論になりました。本構成における別リージョンの RDS/Aurora はあくまでデータバックアップ用であり、DR 発動時の切替先ではないためです。
まとめ
本エントリのタイトルのような構成を取りたいケースは珍しいとは思いますが、現時点においては仕様としてできないのは確かなので、レプリケーション種別における差異も含め備忘も兼ねてまとめておきたかった次第です。
本記事がどなたかの役に立てば幸いです。
ちなみに、手動でレプリケーションを構成することを許容するのであれば、一番最初に検討していた構成についても同様に実現できてしまいます。（RDS ⇒ Aurora Global DB 間を手動でレプリケーション構成）
一応この案も上記案と合わせて俎上に上げてみたのですが、案2と比較して構成が複雑になること、同リージョン内の Aurora リードレプリカに対するレプリケーションも手動構成となってしまう点が少し気になる（アプリケーションが使用することもあり、マネージドレプリケーションで構成したい）ことの2点より、案2を採用することとなりました。