こんにちは。コネヒトのプラットフォームグループでインフラエンジニアをしている@sasashuuuです。

本日は、今年2月に対応した弊社の主力サービスであるmamariをはじめとする各種アプリケーションで使用している本番環境Amazon Aurora MySQL v1(MySQL 5.6 互換)のEOL対応において、まだリリースされてから間もない新機能であるAmazon RDS Blue/Green Deploymentsを本番導入した際の流れや所感についてまとめたいと思います。

はじめに

本記事の内容は実際にEOL対応に向けての検証を行っていた際や、EOL当日対応時の状況などを含んでおり、取り扱っているAWSサービスの仕様やその他記載内容は当時のものとなっています。最新の情報などはAWSの公式ドキュメントを参照してください。（公式ドキュメント先リンクは次項「Amazon RDS Blue/Green Deploymentsとは」を参照してください。）

Amazon RDS Blue/Green Deploymentsとは

Amazon RDS Blue/Green Deploymentsは2022年の12月にGAでリリースされた新機能です。

新機能 – Amazon Aurora と Amazon RDS でのフルマネージド型 Blue/Green Deployments

数ステップで本番環境と同期されたステージング環境を作ることができ、また、本番環境への昇格なども行えます。補足として、以降「ステージング環境」と「Green環境」という2つの用語が出てきますが、基本的に同義だと思っていただいて大丈夫です。

今回の弊社でのユースケースのようにEOL対応に伴うアップグレードに利用する他、パラメータのチューニングやスキーマ変更のテストなどさまざまなシチュエーションで利用することができます。詳しい内容は下記の公式ドキュメントを参考にしてください。（RDSとAuroraではドキュメントのページが変わりますのでご注意ください。）

RDS
- Using Amazon RDS Blue/Green Deployments for database updates
Aurora
- Using Amazon RDS Blue/Green Deployments for database updates

また、本記事ではAuroraを対象に解説を行うため、以降記事内で紹介する公式ドキュメントのリンクはAuroraを対象としたものとなっておりますのでご了承ください。

なぜ使おうと思ったのか

EOL対応を行う上での対応方針として、大枠としてはざっくりと2つの方針に分かれるかと思います。

インプレースアップグレード
待機系の環境を準備した上でのアップグレードおよび切り替え

それぞれ下記のメリデメなどがあるかと思います。

	メリット	デメリット
インプレースアップグレード	・手順がシンプル・アーキテクチャが複雑にならない	・計画停止時間およびダウンタイムが長くなる・アップグレードに失敗した場合のデータ破損に備える必要がある
待機系の環境を準備した上でのアップグレードおよび切り替え	・計画停止時間およびダウンタイムが短くなる・切り戻しが行いやすいような構成を作ることができる	・データの不整合のリスクが生じる・アーキテクチャが複雑になる恐れがある

今回選定したAmazon RDS Blue/Green Deploymentsは後者の方針に近いものですが、それらをマネージドな形で提供してくれる新機能となっています。

上記のような観点なども踏まえ、結果的に下記の理由からAmazon RDS Blue/Green Deploymentsを選定することに決めました。

計画停止およびダウンタイムの時間をなるべく短縮したかった
EOLの期日が迫っていたこと、EOL対応に関するノウハウ・ナレッジが十分にはなかったことなどから、自前でアーキテクチャを構築するコストを削減すべく、それらを提供してくれるマネージドな機能を利用する方が効率的だと考えた
アップデートされた新機能を本番導入するという先進的な事例づくりおよび技術的なチャレンジを行いたかった

Amazon RDS Blue/Green Deploymentsを使ったEOL対応の流れ

下記は事前準備から本番対応完了までのざっくりとした流れです。前提として、Amazon RDS Blue/Green Deploymentsに限らず汎用的にEOL対応で必要になる手順などは、本記事のスコープ外として内容を割愛をしています。

Amazon RDS Blue/Green Deploymentsの利用に必要な事前準備を行う（切り替え実施日以前に余裕を持って実施）
ステージング環境の作成を行う（切り替え実施日の前日に実施）
スイッチオーバーでステージング環境を本番環境と切り替える
ステージング環境を削除する（切り替え実施日の当日に実施）

順を追って説明していきます。

1. Amazon RDS Blue/Green Deploymentsの利用に必要な事前準備を行う（切り替え実施日以前に余裕を持って実施）

事前準備についてざっと以下の対応を行いました。

Amazon RDS Blue/Green Deploymentsの利用条件を満たしているかの確認
技術検証および開発環境でのテスト
binlog_format パラメータの変更
パラメータを変更してからのリブート（再起動）漏れがないかの確認
対象Auroraリソースに紐づくサブネットグループを3az以上にする

Amazon RDS Blue/Green Deploymentsの利用条件を満たしているかの確認

そもそもの利用条件を満たしているかを確認します。これをクリアしないことには機能を利用することができないため、必ずはじめにやりましょう。公式ドキュメントの Limitations for blue/green deployments に制限事項の記載がありますそちらで確認してください。

技術検証および開発環境でのテスト

利用条件をクリアしたのちに技術検証および開発環境でのテストを行いました。大きく分けてざっくり以下のような段階を踏んでの検証作業やテストを行いました。

開発環境や本番環境とは分離された検証用のAuroraリソースを別途作成した上で、実際にAmazon RDS Blue/Green Deploymentsを試し、仕様などをざっくりと把握する
開発環境を用いて、Amazon RDS Blue/Green Deploymentsを含めたEOL対応の流れを可能な限り加味した上で、一連のオペレーションを実施する
Amazon RDS Blue/Green Deploymentsにより切り替わった開発環境のAuroraリソースをもとに稼働しているアプリケーションが問題なく動いているかをテストする

なお、具体的な検証内容やテストについては、本記事では割愛をさせていただきます。

その他の作業

binlog_format パラメータの変更

パラメータを変更してからのリブート（再起動）漏れがないかの確認

対象Auroraリソースに紐づくサブネットグループを3az以上にする

これらに関しては、以前執筆した下記のブログで取り上げていますので、詳しくはそちらをご参照ください。

Amazon RDS Blue/Green Deployments利用時に躓いたエラーやハマりポイントなどをまとめてみた - コネヒト開発者ブログ

2. ステージング環境の作成を行う（切り替え実施日の前日に実施）

EOL対応の対象Auroraクラスターを選択し、ステージング環境の作成を行います。

基本的にスイッチオーバーさえ行わなければ、本番リソースのクローンが作成され、データが同期されるだけという認識であり、稼働中のサービスへの影響はないと判断しました。そのため当日作業の時間短縮を狙い、前日時点でステージング環境の作成を行なっておくことにしました。

AWSコンソールより RDS > データベース > 対象クラスターへ遷移し、「ブルー/グリーンデプロイの作成」を選択します。

ステージング環境の識別子、エンジンバージョン、割り当てるパラメータグループ（クラスター、インスタンスそれぞれ1つずつ）の選択を求められるので、設定を行います。

Amazon Aurora MySQL v2(MySQL 5.7 互換)へのアップグレードのため、エンジンバージョンは当時の最新の 2.11.1 を選択し、v2用に新たに作成していたパラメータグループを設定しました。

ステージング環境作成後は以下のように元のリソースにツリー状にぶら下がる形でGreenと表記されたリソースがAWSコンソール上へ現れます。

また、ステージング環境作成後の注意点ですが、新しく設定したステージング環境のパラメータグループを同期させるためにステージング環境のAuroraインスタンスをリブートする必要があるため、その対応も行いました。結果としてインスタンスごとのパラメータグループのステータスが以下のように「同期中」となっていればOKです。（この対応は先述した事前対応におけるパラメータグループ同期のためのリブート対応とは異なるものであるためご注意ください。）

3. スイッチオーバーでステージング環境を本番環境と切り替える

当日は計画停止をし、ユーザーからのアクセスが途絶えたことを確認したのち切り替えの作業を行いました。

切り替えの手順としては、Blue/Greenのリソースとは別に「ブルー/グリーンデプロイ」というロール名のついたリソースが存在するのでそれを選択し、アクション > 切り替えの順に切り替えを行っていきます。なお、切り替えの際にはタイムアウト値（min）を設定できます。今回は15minを設定しました。尚、タイムアウトの挙動としては、設定値の時間内に切り替えが行われなければ、ロールバックされ、Blue/Greenいずれの環境も変更は加えられないという挙動になります。公式ドキュメントには「ワークロードにもよりますが、通常は 1 分以内ですばやく切り替えます。」との記載があります。詳しくは下記の公式ドキュメントを参照してください。

実際に切り替え実施後は、切り替え完了ステータスになった「ブルー/グリーンデプロイロールのリソース」と「-old1 というサフィックスがついたBlue環境のクラスターおよびインスタンス」が独立します。

弊社の場合、今回は計画停止を伴うため、DBへの疎通確認レベルでダウンタイムを計測するなどの確認は行なっておりませんでした。AWSコンソール上で確認したところ、Blue/Green環境のリソースが分離され、利用可能な状態を確認できるまでに15分弱ほどの時間がかかり、先述したタイムアウト値はギリギリの状態での切り替え実施となりました。

4. ステージング環境を削除する（切り替え実施日の当日に実施）

前項で触れた独立したBlue環境のリソースを計画停止の解除前（サービスイン前）に削除しました。不要になったリソースのため削除のタイミングはいつでも問題ないかと思いますが、万が一古いリソースが参照されてしまったという事故が発生した際にいち早く検知できると考えたため今回は念のためのスナップショットを取得したのち速やかに削除を行いました。

使ってみたメリット・デメリット

メリット

Amazon RDS Blue/Green Deploymentsを使うメリットに関しては公式ドキュメントの Benefits of using Amazon RDS Blue/Green Deployments にも記載されていますが、実際に使ってみて感じた弊社の実務におけるメリットに関しては以下のような点があると思いました。

複雑なアーキテクチャや段取りを自前で組む必要がない
オペレーションが簡素
インプレースアップグレードに比べ計画停止の時間を短縮できる

順に説明をしていきます。

複雑なアーキテクチャや段取りを自前で組む必要がない

Green環境の作成とレプリケーションの開始、スイッチオーバー時の書き込みロックや切り替え失敗時のロールバック等々、マネージドな形で行ってくれるので、事前に複雑なアーキテクチャや段取りを準備するコストがカットできました。また、スイッチオーバーと共にBlue環境で使用していた識別子やエンドポイントなどはそのまま本番昇格後のGreen環境へと引き継がれるため、参照元の洗い出しおよび参照先の切り替え作業等が不要になり、アプリケーション側の変更などを意識しなくてもよくなる点も大きな魅力でした。

オペレーションが簡素

新機能ということもあり、事前準備や検証などには苦労しましたが、ステージング環境作成〜切り替えまでのオペレーションについては、わずか数ステップの手順を踏むだけで、一連のフローを実施できるため、オペレーションが簡素で扱いやすかったです。

インプレースアップグレードに比べ計画停止およびダウンタイムの時間を短縮できる

例えば、インプレースアップグレードなどを行う場合にはざっくり下記のような手順になるかと思います。

計画停止
本番環境リソースのインプレースアップグレード
計画停止解除

しかし、先述した手順にも記載のようにAmazon RDS Blue/Green Deploymentsを使って事前にステージング環境を作成し、当日は切り替える作業のみを行う段取りとすれば、「2. 本番環境リソースのインプレースアップグレード」のアップグレードの待ち時間がカットできるため計画停止およびダウンタイムの時間を短縮することができます。

デメリット

逆にデメリットについては下記のような点を感じました。

本番導入することの懸念要素
切り戻しを考慮する場合は別途自前のアーキテクチャや段取りの準備が必要
スイッチオーバーの所要時間が予想外にかかり見積もれない場合がある

本番導入することの懸念要素

検証時に気になった挙動や不可解なエラーなどはサポートへの問い合わせを行うなどし、対応しておりました。例えば下記の内容のものなどです。

Green環境作成前のBlue環境に対する何らかの書き込み操作が必要となる問題
作成したステージング環境のインスタンスの aurora_server_id の値がスイッチオーバー後もグリーン環境の値が引き継がれ、残ってしまう問題

Green環境作成前のBlue環境に対する何らかの書き込み操作が必要となる問題

これに関しては、先述した Amazon RDS Blue/Green Deployments利用時に躓いたエラーやハマりポイントなどをまとめてみた - コネヒト開発者ブログにも記載しており、担当部署にて修正すべき問題として認知済みとのことでした。

作成したステージング環境のインスタンスの aurora_server_id の値がスイッチオーバー後もグリーン環境の値が引き継がれ、残ってしまう問題

これに関しては、本記事や以前紹介したブログなどで詳しくは取り上げておりませんが、スイッチオーバー後もGreen環境の aurora_server_id の値が、リブート済みであるにもかかわらず、昇格した本番環境に適用されてしまうという現象が見られたため、サポートへ問い合わせておりました。結果、AWS様で抱える問題だったようで、開発担当部署にフィードバックを行うとの返答を受けました。とはいえ、aurora_server_id の値を使用するケースはそれほどないかと思いますので、あまりクリティカルな問題ではないかと思われます。

このように、機能特有の問題がいくらか見られました。そのため、まだ認知されていない問題などが本番作業時に発覚するリスクも0とは言えないため、本番導入するにあたり多少の懸念要素などは少し残りそうという印象でした。

切り戻しを考慮する場合は別途自前のアーキテクチャや段取りの準備が必要

こちらはメリットに挙げた内容の裏返しです。Amazon RDS Blue/Green Deploymentsは非常に便利なマネージドな機能ですが、切り戻しを考慮した仕様はありません。（切り替えに失敗した場合のロールバック機能は有）そのため、切り戻しを考慮する場合は双方向のレプリケーションの設計やバックアップからの復元および差し替え手順の準備などを自己責任で準備し、実施する必要があります。

スイッチオーバーの所要時間が予想外にかかり見積もれない場合がある

先述したように、ドキュメントには「ワークロードにもよりますが、通常は 1 分以内ですばやく切り替えます。」との記載がありますが、通常の目安以上の所要時間を超える場合があります。現に今回の対応では切り替えに十数分程度の所要時間がかかりました。このスイッチオーバー自体のオペレーションは強行で実施したり、実行中の状況を確認したりといったことはできかねるものかと思います。そのため、予期せぬ形でスイッチオーバーに多くの時間がかかってしまうことを許容できない場合は対策が必要となります。