Amazon Aurora MySQL の Blue/Green Deployments機能をつかってクラスタのアップグレードをシュッとした話

CyberAgent Group SRE Advent Calendar 2023の20日目の記事です。

 
技術本部 サービスリライアビリティグループ(SRG)の鬼海(@fat47)です。
#SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
本記事は、SRG 内にある DBWG(DBワーキンググループ)が全社内向けに提供しているデータベースに関する資料を公開します。
なにかの役に立てば幸いです。
本記事では、Aurora のBlue/Green Deployments機能を利用し、Aurora MySQL Version2(MySQL5.7互換)からVersion3(MySQL8.0互換)にアップグレードをおこなったことについて書いています。
 

Aurora Blue/Green Deploymentsとは


昨年2022年のRe:Inventで発表されたRDS,Auroraで利用できる機能です。
 
今現在稼働しているRDSクラスタをBlueとして、Greenクラスタの作成・切り替えをマネージメントコンソール上から行えます。
機能の流れを要約すると、
  • コンソール上から簡単に本番環境(Blue)からミラー環境(Green)が作れる
    • このときGreen用のエンドポイントも作成されるのでアプリケーションのDB向き先をGreenに向けることで動作確認が可能
  • Blue-Green間は論理レプリケーションが貼られるので更新も同期される
  • コンソール上からBlueからGreenへの切り替えが可能
    • アプリケーションが参照するエンドポイントは変更不要でエンドポイント内部の向き先が切り変わる
  • 切り替え中はBlue/Green両者書き込みブロック
  • 指定した時間内にB/G切り替えが完了しなかったら自動で切り戻される
  • 切り替え後のBlue環境はスタンドアロン環境として残る
    • Blue環境のクラスタ名やインスタンス名には-old1が追加されます
というような感じになります。
AWS公式ドキュメントから引用
AWS公式ドキュメントから引用

アップグレードの手順


開発環境やステージング環境での手順を記載します。
今回、実際にアップグレードをおこなったアプリケーション環境は、Goでつくられているものでした。
  • B/G Deployments機能でGreenクラスタをAurora MySQL Version3で作成する
  • Green用のエンドポイントにアプリケーションの向き先を変更して動作確認を行う
    • このとき書き込みの向き先を変えた場合は、Blue環境との整合性がとれていない状態になるので、動作確認終了後にGreenクラスタは一度削除して、再度Greenクラスタを新規でつくったほうがよいです。
  • 動作確認で問題がなかったらアプリケーションの向き先を、元のエンドポイントに戻す
  • B/Gの切り替えを実行する
    • 切り替え完了まで約1分のダウンタイムあり
  • アップグレード完了

B/G機能をつかったアップグレードの注意点


読み取り・書き込みのダウンタイムは約1分程度

B/Gの切り替えを実行すると、裏側でエンドポイントの向き先が変更されます。
その際、DBに接続しているアプリケーションは約1分程度、読み取り・書き込みが失敗します。
利用しているサービスやアプリケーションで、この1分程度のダウンタイムが許容できるかどうか、事前に判断しておく必要があります。
もし、この時間が許容できない場合はサービス全体を事前にメンテナンスモードに入れるなどの検討をする必要があります。

パラメータグループの反映状況に注意

B/G機能でGreenクラスタを作成する際に、パラメータグループを指定できます。
デフォルトの内容から変更したパラメータグループを指定した場合、パラメータの内容によっては
インスタンスの再起動が要求されている場合があります。
この場合、このパラメータはインスタンス起動時点では適用されておらず、デフォルト値のままになっているので、適用させるには切り替え前に手動で再起動しておく必要があります。

カスタムエンドポイントも利用可能

Blue側でカスタムエンドポイントを利用いた場合、Green側にも同様のカスタムエンドポイントが自動で設定されます。
 

切り替え成功後、切り戻しはできない

なにかしらの理由でバージョンアップ後の問題で、旧環境に切り戻したいとなってもできません。
切り替え成功後には旧Blueインスタンスは独立した環境として残っているだけです。
 
ですので、アプリケーションのDB向き先をBlueに向ければ切り戻しはできるのですが、
Greenからのレプリケーションは貼られていないので、切り替え実行時のデータまで巻き戻ることになります。
完全に元に切り戻すには、サービスをメンテナンスモードにいれてDBへの更新を止めた状態で、Green環境からmysqldump等の論理バックアップをとり、元のバージョンのクラスタへリストアする必要があります。
Version3のクラスタで取得したスナップショットを、Version2のクラスタで利用して起動することもできません。
 
これらを許容できない場合はB/G機能は使わずに従来どおり、別のクラスタを作成してクラスタ間レプリケーションを自前で構築し、切り替え後に逆方向のレプリケーションを構築する必要があります。
 

Aurora Version3では多くのパラメータや挙動が変わっているので注意が必要

B/G機能は関係ないですが、Aurora Version3では多くのパラメータや挙動が変わっているのでよく調査や確認するようにしましょう。
一部ですが別の記事で紹介しています。
 

終わりに


いままでバージョンアップをするには別クラスタをつくって、クラスタ間レプリケーションを自前で設定する必要がありましたが、
このBlue/Green Deployment機能がでたおかげでかなり楽をすることができるようになりました。
便利ですが、注意しておかなければいけない点もありますので、しっかり調査した上で利用するようにしたいですね。
 
SRG では一緒に働く仲間を募集しています。 ご興味ありましたらぜひこちらからご連絡ください。
 
このエントリーをはてなブックマークに追加