はじめに
こんにちは！
any株式会社でプロダクトチームに所属しているエンジニアの @fumiyan です！
この記事は、any Product Team Advent Calendar2024 8日目の記事になります。
本記事は、3日目の前編「Amazon RDS for MySQL 5.7系から8.0系へ！変更点への対応と実践記録」に続く後編です。前編では、 Amazon RDS for MySQL（以下、RDSと表記）の5.7系から8.0系へのアップグレードにおける変更点の確認と、それに対する対応方法を解説しました。後編では、インフラ面に焦点を当て、具体的なアップグレード手順を中心に解説します。
アップグレード作業
アップグレード作業としては、以下になります。
- 5.7系から8.0系への変更点の確認と対応 （※前編で解説）
- RDSアップグレード方針 （※本記事ではここから解説します）
- RDSアップグレード
RDSアップグレード方針
RDSのアップグレード方針を策定する際には、以下のドキュメントを参考にしました。また、細部の確認にあたっては、他のドキュメントや記事も併せて参照しました。
- Upgrading a DB instance engine version
- Upgrades of the RDS for MySQL DB engine
- Parameter groups for Amazon RDS
- Overview of Amazon RDS Blue/Green Deployments
上記のドキュメントの中から、アップグレード方針の策定において特に重要なものを抜粋しました。
Amazon RDS Blue/Green Deployments
方針を策定するにあたり、「アップグレード作業の負荷を軽減し、ダウンタイムをなくし（または限りなく少なくし）、安全にアップグレードを行う」ことを目標としていました。その過程で、RDSのBlue/Green Deploymentsにより、メジャーバージョンのアップグレード時にダウンタイムを最小限に抑え、安全に実行できることを確認しました。これを踏まえ、アップグレード手順にBlue/Green Deploymentsを採用しました。
※ Blue/Green Deploymentsの概念については、AWSの公式ドキュメントで簡潔に説明されています。
Tip
You can minimize the downtime required for a major version upgrade by using a blue/green deployment. For more information, see Using Amazon RDS Blue/Green Deployments for database updates.
参照元：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html
今回のアップグレード方針の目標を達成するうえで、Blue/Green Deploymentsの主な利点は次のとおりです。
- 本番ワークロードに影響を与えることなく、Green（ステージング）環境をアップグレード可能
- アップグレード後のGreen環境を徹底的にテストできる
- 切り替えによるダウンタイムを1分以内に抑えられる（ただし、ワークロードによってはそれ以上になる場合あり）
- Blue（本番）環境の名前とエンドポイントが、Green環境に割り当てられる
Blue環境からGreen環境にレプリケーションされているため、Blue環境を稼働させたまま影響を与えることなく、Green環境でテストを実施でき、切り替えられる構成になっている
参照元：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html
ただし、Blue/Green Deploymentsを採用するにあたり、いくつかの制限事項や注意点があり、事前にこれらを把握し、適切に対応する必要がありました。以下に主な点を抜粋します。
- Blue環境とGreen環境が並行して配置されている場合、スキーマの変更はレプリケーションと互換性のある変更に限られ、互換性のない変更を行うと、レプリケーションが中断される
- 切り替え前に、Green環境へのデータロードが完了していることを確認する必要がある（遅延読み込み処理対応）
- MyISAM などの非トランザクション型ストレージエンジンの使用は避ける
- レプリケーションの競合が発生する可能性があるので、Green環境は読み取り専用にしておく
特にスキーマの変更や遅延読み込みについては、どの環境でも確認が必要かと思っています。弊社ではスキーマ変更は頻繁に行われるものではありませんが、新機能開発が並行して進んでいたため、開発担当者と連携しながら、アップグレード期間中はレプリケーションと互換性のある変更に限り許可していました。また、互換性のあるスキーマ変更と互換性のないスキーマ変更を用いて、レプリケーションが中断されるかどうかのテストも実施しました。次に、遅延ロードについては、レイテンシを低減するため、SELECT * でテーブル全体をスキャンするスクリプトを作成し、テーブルデータをすべて S3 からGreen環境へ流し込む作業もしました。
その他にも細かい制限事項や注意点があるため、ドキュメントを隅々まで確認し、プロダクトの要件と照らし合わせながら確認していきました。
RDSアップグレード
RDSのアップグレード方針が決定したため、アップグレード作業を実施しました。その作業過程を以下にまとめます。
- Blue/Green Deployments作成
- Blue/Green Deployments状態確認
- Blue環境とGreen環境切り替え
- Blue/Green Deploymentsと旧Blue環境削除
Blue/Green Deployments作成
Blue/Green Deploymentsの環境を作成していきます。
アップグレードしたいRDSを対象に、アクションメニューから「ブルー/グリーンデプロイを作成」を選択して、「ブルー/グリーンデプロイの作成」画面に遷移します。
「ブルー/グリーンデプロイ識別子」を入力し、次に進みます。
「ブルー/グリーンデプロイ bg-deployment-1 の設定」画面に遷移したら、バージョンアップグレードのためにアップグレード対象のバージョンを選択します。
この画面ではインスタンス設定やストレージ設定の変更も可能
「見直しと確認」画面で変更内容（アップグレードするバージョン）を確認し、「作成」を押します。
Green環境の月額料金を確認することもできる
DBの一覧画面で以下の画面が表示されれば、作成段階は完了です。
Blue/Green Deployments状態確認
Blue/Green Deploymentsで切り替えを行う前に、状態を確認し、テストを実施します。
DBの一覧画面で「bg-deployment-1」を選択すると、Blue環境とGreen環境の状態を確認できる画面に遷移します。
画面を最下部までスクロールすると、レプリケーションの状態を確認できます。「レプリケーション中」と表示されていれば、Blue環境からGreen環境へのレプリケーションが正常に機能していることを示します。
上記でレプリケーションが正常に動作していることを確認し、Green環境のテストを徹底的に実施しました。
Blue環境とGreen環境切り替え
切り替え作業に入ります。作業を開始する前に、切り替えガードレール、切り替えアクション、切り替えのベストプラクティスを細部まで確認しました。
また切り替え作業の前に、以下の対応を行いました。
- ALBを介してメンテナンス画面を表示する設定
- Blue環境のスナップショットから同じ環境を事前に作成
これらの対応を行った理由は、切り替え中にお客様が処理を実行してデータの不整合が発生する可能性を防ぐため、また、作業完了後に問題が発生し、以前のRDSに切り戻す必要が生じた場合に備えるためです（検証と迅速な対応のために切り戻し作業も実施しました）。
実際に切り替え作業を進めます。bg-deployment-1の画面からbg-deployment-1を選択した状態で、アクションメニューから「切り替え」を選択します。すると、「切り替え」画面に遷移します。
切り替え画面で、切り替え内容を確認します。今回はバージョンアップグレードのため、バージョンが想定通りであることを確認します。
バージョンが想定通りであることを確認したら、「タイムアウト」（切り替えの時間制限）を設定し、「切り替え」をクリックして作業を開始します。
切り替えが成功すると、以下の画面が表示されます。これで切り替えは無事に完了です。
Blue/Green Deploymentsと旧Blue環境削除
最後に、不要になったBlue/Green Deployments環境と旧Blue環境を削除します。
まず、Blue/Green Deployments環境を削除します。bg-deployment-1を選択した状態で、アクションメニューから「削除」を選択すると、削除確認のポップアップが表示されます。
削除確認のポップアップで「delete me」と入力し、「削除」をクリックします。削除が完了すると、DBの一覧画面からBlue/Green Deployments環境が消えます。
次に、古いBlue環境を同様にアクションメニューから「削除」を選択して削除します。なお、削除するには削除保護を無効化する必要があります。削除が完了すると、アップグレード作業はこれで完了です！
まとめ
いかがでしたでしょうか。
本番環境でのRDSメジャーバージョンアップグレードは、非常に慎重さを要する作業です。しかし、事前に入念な準備を行うことで、リスクを最小限に抑え、安全かつスムーズに実施することができました。チームメンバーから「ありがとうございます！」という声を多数いただけたことも、大変嬉しく感じています。
前編の記事にも掲載しましたが、メンバーがとても喜んでくれた場面です！
一方で、反省点もあります。5.7系から8.0系へのアップグレードでどれほどパフォーマンスが向上したのか、詳細なデータを基に定量的に記録しておくべきだったと感じています（アップグレード作業時期はDatadogを本格導入する前でした）。もし記録していれば、事業への具体的なインパクトをより明確に示せたのではないかと思っています。また、コンソール画面での作業が中心だったため、手順をより安全にするためにTerraformなどのIaCを使用して、可能な限り自動化する必要性も感じました。
次のバージョンアップやAmazon Auroraへの移行が控えているため、今回の反省点を活かして取り組みたいと考えています。
前編・後編を通して、最後までお読みいただき、ありがとうございました！！！
Discussion