Zenn
📑

Amazon RDSのBlue/Green Deploymentsを実験して気づいたハマりポイントまとめ

2022/12/10に公開
AWS
RDS
aurora
tech

はじめに

先日のAWS re:Invent 2022でさまざまな新機能の発表がありましたが、
その中でも特に注目度が高いRDSのBlue/Green Deploymentsを実験していく中で気づいたハマりポイントをまとめました。

特に、著者が調査を進めた背景に2023/02に控えたAurora V1サポート終了があります。
今回はスナップショット＆リストア方式でのV2移行を考えていますが、
切り替え時にスナップショットを作成することからユーザアクセスを遮断する必要があり長時間のサービス停止が発生することが見込まれており、
次回以降はもっと短時間で移行できる方法がないか調べていたところ渡りに船とばかりに公式から新機能発表があったため色々調べました。

注意

  • 本記事の内容は2022/12/09時点で、著者が手元で実験した際の結果をまとめたものになります。
  • 「AWSから公式に提示されていない裏条件のようなものに起因してBlue/Green Deployments動かない」といったことにも遭遇したため、
    これから実験しようと考えている皆さんが時間を浪費しないで済むようにまとめました。
  • 発表から2週間程度しかたっていないため、これから先どんどん改良されていき、最終的に本記事の見え消しが増えていくと理想だと考えています。

実験環境

  • Aurora MySQL V2(2.10.3)クラスター
  • 日本リージョンで実施
  • V2 -> V3のバージョンアップを含むGreen環境構築を実施

環境構築が進んでいるように見えて、進んでないケース

本記事で一番書きたかった部分です。
Green環境の構築は数クリックでお手軽にできるのですが、いつまで経っても環境構築が終わらないというケースに複数遭遇しました。
現段階では構築時にエラー表示もされないため、このケースに該当すると1日経っても変化なしといった状態で、悪戯に時間を浪費してしまいます。

ケース1: Auroraクラスタに付与しているサブネットグループに3つのアベイラビリティゾーン(az-1a,1c,1d)全てを含めていない

事象

Blue/Green deploymentsの作成をした後、green環境のクラスターがいつまで経っても作成開始されない。
error

上記のように、ブルー/グリーンデプロイのプロビジョニングが表示されるが、どれだけ待ってもgreen環境のクラスタの行が表示されません。
通常であれば1分程度でgreen環境のクラスタが表示されます。
この状態で、ブルー/グリーンデプロイの削除を行うと数秒で消えることから、実質何も動いていないと思われます。

原因

  • Auroraクラスタに関連付けているサブネットが日本リージョンのアベイラビリティゾーンを全て網羅してない
    • 公式にはこのような制約は記載されていないためバグもしくは今後そのような情報が公開されるかもしれません
    • 1a-1cのみ、1a-1dのみ、1c-1dのみを試しましたがいずれもダメで、1a-1c-1d全て含めた場合のみOKでした

解決方法

  • 新規作成するクラスタで実験するのであれば関連付けるサブネットグループの設定内容に注意する
  • 作成済みクラスタで実験するのであれば、関連済みのサブネットグループの設定を編集する

気づいた背景

既存クラスタに対して実験したが何度やってもgreen環境が構築されず、ふとdefault VPCに新しいAuroraクラスタを作成したところ
すんなり環境構築完了したため、うまくいかない環境との差分を調査しました。
既存クラスタはサブネットグループにアベイラビリティゾーン1aと1cだけが含まれており、試しに1dを追加したところ無事動くようになりました。

ハマりそうなケース

  • 昔から使っているクラスタで実験しようとした

ケース2: db.t3.smallを使ったAuroraクラスターでV3へのバージョンアップを含めた環境構築をした

事象

Aurora V2からV3へのバージョンアップを含んだGreen環境構築を実行したが、DBエンジンバージョンのアップグレードが進行中のまま進まない。
error

原因

Aurora V3はdb.t3.smallに非対応であるため。
インスタンスタイプと対応するDBエンジンバージョンについてはこちらに記載があります。

解決方法

  • db.t3.medium以上のインスタンスタイプで実験する
  • V3へのバージョンアップを含めずにGreen環境構築を行う

ハマりそうなケース

  • 個人のAWS環境で実験するので費用をなるべく抑えたいという時

環境構築を開始する前にエラーが表示されるケース

こちらは、環境構築の際エラーメッセージが表示されるので回避するのは容易だと思いますが、備忘録的に記載します

ケース3: binlog_formatがMIXED以外のAuroraクラスタで環境構築をした

事象

環境構築画面で作成ボタンを押すと以下のエラーが表示される。
error
※binlog_format=offの状態で実験しています。

解決方法

ハマりそうなケース

  • エラーメッセージと実際の設定不備があっていないので、違う原因を調査してしまいそう

ケース4: rds_proxyと関連付けがあるAuroraクラスタで環境構築した

事象

環境構築画面で作成ボタンを押すと以下のエラーが表示される。
error

原因

  • rds_proxyは非対応であるため、関連付けを外して環境構築をする
  • 公式に記載あり

ハマりそうなケース

  • Lambdaからのアクセスを含むAuroraクラスタで実験している

気になったこと

  • rds_proxyを使うのはLambdaに対するコネクションプールの役割が主だが、そのようなAuroraクラスタでBlue/Greenデプロイを行う際はどうするのか？
  • 一時的にrds_proxyの関連付けを外すとしても、lambda側のDB接続エンドポイントの修正も同時に行う必要があるので、サービス停止時間が少し長く発生しそう

Green環境構築に影響しなかった事項

今回調査していく中で、特に設定値の影響がなかった項目をさらっとまとめます。

DBセキュリティグループ

  • 3306ポートが空いていれば大丈夫そう(通常であればポートを開けているはず)
  • ソースを著者の会社のIPのみに限定しても問題なく環境構築できた

DBインスタンスが配置されたのがパブリックサブネットかプライベートサブネットか

  • どちらのサブネットでも問題なく環境構築できた

Blue環境のAuroraをGUIから手作成したかCloudFormationから作成したか

  • 公式にCloudformationはサポート外という記載があり、ケース1が原因だと気づいていない時に同僚からのコメントを受け念の為検証した。
  • 公式の記載は、Cloudformationを介してBlue/Greenデプロイメントを開始できないよという意味だと思います(Green環境のクラスタには新しいarnが付与されるので、Cloudformationが追従できないということに起因していそうです)

あとがき

Blue/Greenデプロイメントを行う一番のハードルは「binlog_formatをMIXEDにするためにDB再起動が必要」という部分だと思います。
今後どこかのタイミングでDBを停止する機会がある場合はbinlog_formatの設定変更を忘れずにやっておきたいところです。

Discussion