Zenn
🦯

RDS Proxyを入れておくとRDS復旧時にエンドポイントが変わらないというメリットがあるよって話

2024/03/10に公開
AWS
proxy
RDS
aurora
SRE
tech

概要

小ネタです。
RDS Proxyにはそういう側面もあるのかみたいな気づきがあれば幸いです。
話の概要としては、RDSをsnapshotやバックアップから復旧する際の手順がRDS Proxyを入れている場合では入れていない場合と違う手順を取ることができるという話になります。

RDS Proxyとは

RDS Proxyのイメージ:

詳細は、公式ドキュメントを参照ください。
https://aws.amazon.com/jp/rds/proxy/

自分の中での印象かもしれませんが、上記ドキュメントにもあるようにLambdaとRDSを接続する際にコネクションが枯渇する問題(当時はLambdaでRDSを使うことがアンチパターンとされていた)を解決するためにRDS Proxyを導入することが多い印象です。

アプリケーションがデータベースと確立した接続をプールおよび共有でき、データベースの効率とアプリケーションのスケーラビリティが向上します。

RDS Proxyのページを見ていると基本的にメリットを感じることが多く書かれていますが、そのメリットの恩恵を本当に受けられそうかについてはよく考えた方が良く(自戒)、こちらの記事などを見て見ることでフラットに判断することをお勧めします。

https://dev.classmethod.jp/articles/do-you-really-need-rds-proxy/

RDSを復元する

RDSをsnapshotやbackupから復元する方法/手順について見ていきたいと思います。

前提知識:

  • DBインスタンス(クラスタ)はidentifier(db識別子)がAWSリージョン内でユーザー別に一意にする必要があります。
  • 復元する際は、既存のDBの中身が変わるわけではなく、新規のDBインスタンス(クラスタ)が立ち上がります
    • 復元DBのidentifier(db識別子)を指定して新規DBを立ち上げる
    • 自分も最初復元=既存のDBの中身が変わることかと思いましたが、初見でそういう方は多い印象です

RDS Proxyなしの場合

既存DB：identifier = 'db-before'

identifierを変えない方法①:

  1. 既存DBのidentifierを別の名前にrenameする
    • 既存DB：identifier = 'db-before-xxx'
  2. 復元DBをsnapshotやbackupから復元する
    • 復元DB：identifier = 'db-before'

identifierを変えない方法②:

  1. 復元DBをsnapshotやbackupから復元する
    • 復元DB：identifier = 'db-after'
  2. 既存DBのidentifierを別の名前にrenameする
    • 既存DB：identifier = 'db-before-xxx'
  3. 復元DBのidentifierを変更する
    • 復元DB: identifier = 'db-before'

identifierを変える(エンドポイントが変わることを許容)する方法:

  1. 復元DBをsnapshotやbackupから復元する
    • 復元DB：identifier = 'db-after'
  2. アプリケーション側のDBエンドポイントを既存DBのものから復元DBのものに変える

①②では使っているDBのエンドポイントが一時的に変えるのでダウンタイムが発生します。
②の方がDBが2台同時に立っている状態で作業をするので短いダウンタイムで済みますが、作業時間としては長くなります。
アプリケーションに設定されているDBエンドポイントを変える方法ではDBのダウンタイムは発生しませんが、アプリケーションに手を入れたくない等の判断もあるかもしれません。

※後述の注意点でも触れますが、処理中のクライアントをどうするか等は共通の課題なのでここでは触れません

RDS Proxyありの場合

既存DB：identifier = 'db-before'

  1. 復元DBをsnapshotやbackupから復元する
    • 復元DB：identifier = 'db-after'
  2. RDS Proxyのターゲットグループで紐づけているDBを変更する
    • 既存DB→復元DB

注意点

既存DBが何かしらの理由で完全に使えない状態になっていて新規DBを早く立ち上げないといけない場合は旧DBで処理しているクライアントもいないし、停止時点 or それ以前に復旧することができれば問題ないかと思います。
一方で、既存DBが動いている状態でDBを復元する、DBを切り替える際には、

  • 新旧DBでデータの同期が必要か
  • 処理中のクライアントに影響はないか、ダウンタイムを許容できるか
    のようなことを気にする必要があるかと思います。

その辺り調べていたら色々なケースが想定されて書かれているこちらの記事が参考になりそうでしたので、良ければご参照ください。
https://developers.freee.co.jp/entry/online-rdbms-switchover-with-rds-proxy

まとめ

RDS Proxyを入れているとRDSを復元する際にRDS Proxyがない場合と違う方法を取れるということを紹介しました。
この方法を採用できることがメリットになるかや、コストを払ってでも必要か、そもそもRDS Proxy必要だっけ？という色々な観点でRDS Proxyの導入は考えられると良いと思っていますが、よく言われるコネクションプール以外にもこういうメリットがあるんだと知ってもらうきっかけになれば幸いです。

Discussion