Zenn
🤖

RDSをアップクレードする(RDS Proxyあり)

2022/03/25に公開
AWS
RDS
rdsproxy
tech

RDSのアップグレード

現在業務でRDS(Aurora Mysql)を利用しているのですが、バージョンが2系(Mysql5.7互換)のもので、EOLが来る前に3系(Mysql8.0互換)にあげときたいねって話をしていました。そこで実際にあげようと思ったのですが、RDS Proxy構成でやっている記事があまりなかったので備忘録として残しておきます。

構成

構成は以下の通りです。LambdaでRDSを使いたい場合、RDS Proxyを挟むのは定番構成かなと思います。なぜRDS Proxyを使うべきかは以下の記事がわかりやすかったので合わせてご覧ください。
https://www.keisuke69.net/entry/2017/06/21/121501
厳密な構成は、LambdaからRDS Proxyに接続する際に、AWS Secrets Managerを使っているのですが、今回は無くても特段問題ないので省略します。(別途、記事化予定)

本記事で記載しないこと

  • ソースコードの記載
  • ネットワーク周りの設定

手順

1系から2系へのアップグレードとは異なり、2系から3系へのアップグレードはインプレースアップグレードが出来ません。なので、スナップショットリストア方式で進めていきたいと思います。

クラスターのスナップショットの取得

移行元のクラスターのスナップショットを取得します。GUIからやれば簡単にスナップショットを取得できます。ポチポチポチ...

ただ結構場所がわかりづらくて、データベース一覧のページから、クラスターのリンクをクリックして、[メンテナンスとバックアップ]というタブを開き、下までスクロールすると、[スナップショット]という項目があります。[スナップショットの取得]という右上のボタンを押しましょう。

スナップショットの復元

スナップショットを取得したら、[左のナビゲーションペイン]>[スナップショット]の項目に出てきてくるかと思います。容量次第ですが、数分~数十分程度でステータスが利用可能になります。そしたら、対象のスナップショットを選択して、[スナップショットの復元]を実行します。今回は3系にアップグレードしたいので、復元実行時に3系で利用可能なバージョンを選択します。

その他、接続に関する設定や、DBインスタンスクラスの設定をしてDBクラスターを復元を実行します。復元が開始されると、クラスターと1つのライターインスタンスが立ち上がります。復元には長くておおよそ1時間程度かかります。クラスターとライターインスタンスのステータスがどちらも利用可能になったら復元完了です。

リーダーインスタンスの追加(任意)

この項目は任意になります。RDS Proxyでリードオンリーのエンドポイントを作成する場合、ターゲットのクラスター内にリーダーインスタンスがないと作成できません。なので、リーダーの追加から、リーダーインスタンスを作成します。この項目はこれで完了です。

RDS Proxyの付け替え作業

RDS Proxyはターゲットグループにデータベースを関連づけることができ、新しくProxyを作成する必要はありません。向き先を移行先のデータベースに変更してあげるだけで大丈夫です。

データベースを関連づけることができたら、念の為AWS CLIでも確認しておきます。以下の describe-db-proxy-targets コマンドはProxyがDBに接続可能かどうかを調べることができます。

$ aws rds describe-db-proxy-targets --db-proxy-name ${proxy_name}
# 以下実行結果
{
    "Targets": [
        {
            "Endpoint": "xxxxxxx.ap-northeast-1.rds.amazonaws.com",
            "TrackedClusterId": "xxxxxxx",
            "RdsResourceId": "xxxxxxx",
            "Port": 3306,
            "Type": "RDS_INSTANCE",
            "Role": "READ_WRITE",
            "TargetHealth": {
                "State": "AVAILABLE"
            }
        },
        {
            "RdsResourceId": "xxxxxxx",
            "Port": 3306,
            "Type": "TRACKED_CLUSTER"
        },
        {
            "Endpoint": "xxxxxxx.ap-northeast-1.rds.amazonaws.com",
            "TrackedClusterId": "xxxxxxx",
            "RdsResourceId": "xxxxxxx",
            "Port": 3306,
            "Type": "RDS_INSTANCE",
            "Role": "READ_ONLY",
            "TargetHealth": {
                "State": "AVAILABLE"
            }
        }
    ]
}

実行結果のTargetHealthを確認します。読み取り/書き込みのロールと、書き込みのロールを作成しているので、READ_WRITEと、READ_ONLYのそれぞれのTargetHealthを見ると、AVAILABLE になっておりProxy-RDS間の接続は問題ないことを確認できました。

古いRDSクラスターの削除

ほとんどのサービスが、停止をまず最初にしてから削除するなりデタッチするのが一般的なのかなと思っていたのでちょっと困惑しました。なので、ステータスが利用可能の状態で、インスタンスを削除していきます。クラスターに関しては、インスタンスが全て消されると自動的に削除されるようになっているので、順次インスタンスを削除していけば問題ないと思います。

ハマりポイント(一部勘違い)

ポートを変えてやってあげたらいけるんじゃない？ → Proxy経由ではダメ

移行元はデフォルトポートである3306番ポートを利用していました。そこで、移行元に接続可能なまま、移行先DBにも直接繋げるようにしたいと思い、移行先のポートは3306以外に設定しました。その場合、RDSに対しては接続できたのですが、Proxy経由だと繋ぐことができませんでした。(timed outになってしまう)

ちなみに、Systems Managerを通してRDSに接続する記事は以下に書いてます。ご興味があればご覧ください。
https://zenn.dev/hamo/articles/2bbf831f7b99e6

スナップショットからの復元で起きた謎現象

復元時の設定で、削除保護：有効 にしても復元完了時に確認するとなぜか無効になってしまっていました。開発・ステージング・本番と3環境で今回実施したわけなんですが、3分の3で無効になってしまいました。後からでも設定変更は可能なので、後から変更すれば済む話ですが、削除保護がないと簡単に消してしまえるので気をつけておいたほうがいいかなと思いました。

GitHubで編集を提案

Discussion