Amazon RDS のDBエンジンアップデートとブルー/グリーンデプロイ

ことのはじまり

Amazon RDS にて利用しているMySQL、MariaDB、PostgreSQLなどのDBエンジンの
一部バージョンのサポート終了期限が 2025年3月末となっております。

対象のDBエンジンバージョンとサポート期限終了の情報は、
下記AWSドキュメントをご参照ください。
(※日本語版と英語版で差異がある場合は、英語版が正しいものとなります)

DBエンジン 公式情報URL
MySQL MySQL on Amazon RDS versions - Amazon Relational Database Service
MariaDB MariaDB on Amazon RDS versions - Amazon Relational Database Service
PostgreSQL Release calendars for Amazon RDS for PostgreSQL - Amazon Relational Database Service

このDBエンジンのアップデート方法の一つに「ブルー/グリーンデプロイ」が利用できます。
こちらを利用することで「約1分のダウンタイムで、新バージョンのDBエンジンが利用可能になる」
という機能となります。

とはいえ、その内容の複雑さが故に、ご提案後にお客様から多数ご質問をいただくことがございました。そこで本稿では、「ブルー/グリーンデプロイ」の技術的な内容のご紹介と、実際のアップデート方法の流れ、注意点をご紹介します。

実際の画面操作等は、下記のブログ記事をご参照ください。
Amazon RDS Blue/Green Deployments を使ってみた | クラウド・AWSのIT技術者向けブログ SKYARCH BROADCASTING

目次

RDSにおける 「ブルー/グリーンデプロイ」の構成

一般的な「ブルー/グリーンデプロイ」とRDSにおける「ブルー/グリーンデプロイ」は、
多少仕組みが異なります。まずはこちらからご紹介していきます。

公式ドキュメント :Amazon RDS ブルー/グリーンデプロイの概要 - Amazon Relational Database Service

上記ドキュメントにある ブルー/グリーンデプロイのワークフロー の部分が、
RDSにおける「ブルー/グリーンデプロイ」の正体となります。

Amazon RDSのコントロールパネルから作成できる「ブルー/グリーンデプロイ」を実行すると、
現在稼働しているインスタンスと同じインスタンスタイプ・構成をした
リードレプリカ 環境が作成されます。

下記画像における 「青色の背景(blue = 本番稼働中。以下blue環境)」 に追加して、
「緑色の背景(green = 新規環境。以下green環境)」が作成され、
blue環境 → green環境には、レプリケーションによってデータ同期がされています。

ブルー/グリーンデプロイ 環境作成時

そのため、green環境を作成した後、blue環境にてデータの更新があった際には、
自動的にgreen環境にデータが同期(レプリケーション)されることになります。

実際に確認してみた

今回は簡単に、データの同期がされているかを EC2(Linux)とRDS for MySQL を使って確認してみます。
同一のVPC内に EC2とRDS for MySQLを用意し、EC2には mysql のクライアントを導入しております。

RDS for MySQL は、blue環境を 8.0.34 、green環境を 8.0.41 と指定して作成しています。

まずは blue環境へ接続し、状態を確認します。

現在の本番機となっているので、特段問題はないですね。

続いて、green環境へ接続します。
セキュリティグループなども特段設定は不要で、接続が可能です。

ここで、リードレプリカとなっていることを確認してみましょう。

show slave status; のコマンドが表示されますね。
これで、リードレプリカ状態であるのが確認できると思います。

ということは、green環境への書き込みもできないということなので、確認しましょう。

上書きが許可されていないため、エラーになりました。

逆に、blue環境に接続し、DBを作成してみましょう。

その後、green環境に接続し、内容を見てみると

というように、しっかりとデータがレプリケーションされ同期しています。

環境作成時の注意点

作成にはいくつか注意点があります。
基本は下記のAWSドキュメントをご参照ください。
Amazon RDS のブルー/グリーンデプロイの制限と考慮事項 - Amazon Relational Database Service

特に気をつけているポイントを下記に記載いたします。

  • ブルー/グリーンデプロイの環境構築ができない場合がある
    • 特にメジャーバージョンアップであり。エラーログを確認してエラーを解消してください。
  • RDS for MySQLのインスタンスにて、オプショングループがdefaultではなくカスタマイズされたものを利用している場合
    • メジャーバージョンアップが実施できません
  • RDS for PostgreSQL のレプリケーション方式に指定あり
    • メジャーバージョンアップの際には、論理レプリケーション
    • マイナーバージョンアップの際には、物理レプリケーション
      • サポートされている全バージョンで利用可能

本稿の冒頭で記載しているブログ記事当時では、利用可能なバージョンに指定がありましたが、
本稿記載現在では、基本的にはサポートされているすべてのバージョンで
ブルー/グリーンデプロイが利用可能となっております。

過去に「バージョンの制約で利用できなかった」という場合でも、
現在は利用可能になっている場合がありますので、ご確認してみてください!

また、「ブルー/グリーンデプロイ」で作成される環境はリードレプリカ環境のため、
green環境に書き込みは基本不可 であることに注意が必要です。

※設定で書き込み可能に変更は可能だが、切り替え前提の場合は非推奨です。
動作確認用の環境は別に用意する必要があります。


RDSにおける 「ブルー/グリーンデプロイ」の切り替えを利用したアップデートの流れ

DBによるレプリケーションを組んでいる状態でgreen環境のDBエンジンをアップデートすると、
blue環境 = 旧バージョン / green環境 = 新バージョン
という構成で、「ブルー/グリーンデプロイ」環境が整います。

バージョンアップ用の環境を作成後、実際に「ブルー/グリーンデプロイ」環境が具体的にどのような処理をしているのかを簡単にご紹介します。

(※ AWSドキュメントの「ワークフロー」の5に当たる部分になります。)
Amazon RDS ブルー/グリーンデプロイの概要 - Amazon Relational Database Service

AWSマネジメントコンソールなどで、「ブルー/グリーンデプロイの切り替え」を実行すると、
内部的にはざっくりと下記の動作が実行されます。

(参考 : Amazon RDS でのブルー/グリーンデプロイの切り替え - Amazon Relational Database Service)

  1. 環境全体への接続が停止
  2. green環境のレプリケーションが同期するまでスタンバイ
  3. green環境のリードレプリカを昇格(書き込み可能な状態にさせる)
  4. blue環境のインスタンス識別子が、末尾に -old1 という文字列が付与されたものになります。
  5. green環境のインスタンス識別子が、本番環境利用と同じ識別子 (1のblue環境の変更前のインスタンス識別子) に変更されます
ブルー/グリーンデプロイ 切り替え

RDSにおける「インスタンス識別子」の変更を実施するということは、
接続するための「エンドポイント名」の変更と同義になります。

つまり、RDS側で「ブルー/グリーンデプロイの切り替え」を実施することで、
アプリケーション内の接続先情報を変更することなく、新バージョンのインスタンスが
利用可能になります。

実際に確認してみた

環境構築時に使用したのと同じ環境で、今度はブルー/グリーンデプロイの切り替えを実施してみることで、実際に接続先環境が変わることを確認しましょう。

まずは、現在のエンドポイント(blue環境) を名前引きしたときのIPアドレスを確認します。

これは、サブネットグループで設定しているサブネットにて定義している
IPアドレスレンジが表示されています。
パブリックアクセスが有効ではない限り、基本はプライベートIPアドレスになっていますね。

続いて、green環境のエンドポイントを名前引きした際のIPアドレスを確認します。

こちらもgreenと同様のIPレンジを持っていますね。
もちろん環境が違うので、IPアドレスが別のものになっています。

それでは切り替えのボタンを押しまして・・・
ブルー/グリーンデプロイ 切替時マネコン画像

AWSマネジメントコンソール上では、切り替えが完了しました。
それでは色々と情報を確認してみましょう。

ブルー/グリーンデプロイ 切り替え後マネコン画像

エンドポイントとIPアドレスの組み合わせ

接続元のEC2より、本番環境のエンドポイント名のIPアドレスを確認します

先ほどのgreen環境のIPアドレスが表示されていますね。

続いては -old1 のエンドポイント名のIPアドレスを確認します。

こちらは先程のblue環境のIPアドレスが表示されますね。
つまり、切り替えを実行したことで 本番環境のエンドポイント名で接続した際に
green側の環境に接続できるようになっているということです。

では、本番環境のエンドポイント名にログインして、バージョンを確認してみましょう。

green環境側、つまりアップデートされたバージョンが表示されました。
DNSのレコード変更を使った仕組みで、エンドポイント名を変更させることなく、
接続先の機器情報が変更できるという仕組みですね!

リードレプリカの状態

切り替え後のgreen環境に接続して、リードレプリカの状態を見てみましょう。

この結果から、green環境はリードレプリカではなく、
書き込み可能なスタンドアロン状態であることが確認できます。
実際に、DBに書き込みをしてみましょう

先程は新バージョンのDBではできなかった書き込みが可能になっています。
このことからも、リードレプリカが解除され、昇格した状態であることが確認できますね。

旧環境とのデータ連携

では最後に、 -old1 という名前がついた旧環境にログインして、
先ほど書き込んだデータが連携されているかを見てみましょう。

切り替えが完了したあとは、ブルー/グリーンの関係性は解除され、
それぞれがスタンドアロンで動作します。
そのため、green環境で書き込んだ内容は、blue側に書き込まれることはありません。

この時点で、blue環境は、バージョンアップしたgreen環境にて動作不良があった際の切り戻し用のインスタンスの役割を担います。
(※切り戻しは、手動でインスタンス識別子を変更することで対応可能。)
ただし、greenで書き込んだ内容は反映されないため、仮に切り戻した後には、
greenで書き込まれた内容は別途blue側に書き込む必要がありますので注意が必要です。

そして、特に問題がなくなった際には、blue環境はお役御免ということで、
インスタンスの削除を実施しましょう。
(残しておくと、インスタンスの料金が2台分課金され続けることになります)

切替時の注意点

ブルー/グリーンデプロイの切り替え時における注意点をいくつかご紹介します。

詳細は、こちら↓のAWSドキュメントに記載がありますのでご参照ください。
Amazon RDS でのブルー/グリーンデプロイの切り替え - Amazon Relational Database Service

  • 切り替えのタイムアウト

    • 基本は5分以内に切り替わるまで待ちます。もし切り替わらない場合はデプロイは実行されず、ロールバックされます。
  • レプリケーションのラグ

    • レプリケーションのラグが大きい場合は、切り替えまでに時間がかかる、もしくは切り替えに失敗する可能性があります。負荷のかからない時間帯に切り替えを実施するのがおすすめです。
  • アプリケーションの動作確認

    • 切り替え後のDBエンジンバージョンで問題なく動作するかの確認を実施してください。

まとめ

今回は、「ブルー/グリーンデプロイ」を利用したバージョンアップの
技術的な仕様を中心にお届けしました。

ダウンタイムも短く非常に便利な半面、技術的には複雑な内容が含まれていたかと思います。
この記事が、そのような状況の皆様の理解の手助けになれば幸いです。

また、弊社でRDSの保守運用契約があるお客様におかれましては、
お気軽にサポート担当者へお気軽にご相談ください。

投稿者プロフィール

n_fukuda
16年5月からアルバイトとして入社。
様々な新しい発見や個人的に興味を持ったことを
わかりやすくお伝えできればと思います。

ABOUTこの記事をかいた人

16年5月からアルバイトとして入社。 様々な新しい発見や個人的に興味を持ったことを わかりやすくお伝えできればと思います。