[re:Invent 2022] ゲームバックエンドによく使われるRDSのBlue/Greenデプロイ新機能を使ってみた

こちらは AWS for Games Advent Calendar 2022 の12月6日分のエントリーです。

はじめに

ゲームのバックエンドにプレイヤーやゲームのデータなどを保存するためにSQL系データベースはよく使われてますね。しかし、ローンチ後、ゲームに追加要素を加えるとデータの構成も当然変わります。基本的にゲームのアップデートを行う時、メンテナンス作業が必要になって、プレイヤーが遊べない時間が出てしまいます。

その問題を解決するには、つい先日のre:Invent 2022で発表された「RDSのBlue/Greenデプロイ」という新しい機能です。

簡単に説明すると、

1. 本番環境にあるデータベース（Blue）をレプリケーションすることで、開発環境・ステージング（Green）が作成される
2. 本番環境のデータ変更（INSERT・UPDATEなど）が開発環境に リアルタイムで同期される
3. 開発環境に テーブルのスキーマを変更するのは可能 （※ 一部不可能の変更もある）
4. 開発環境の変更作業が終わったら、ほぼゼロダウンタイムで 数分に本番環境にデプロイ が可能

AWS ドキュメンテーションからの引用ですが、構成図がこんな感じです。

しかも、アプリケーション側には切り替えなどの変更は必要ありません。デプロイ後、本番環境で使ってたサーバー名はそのまま継続で使い続けられます。

実際切り替え中にDBサーバーへの接続は切断され、 数秒間 接続不可にはなりますが、アプリケーション側での接続リトライ機能があればほとんど影響は感じません。切り替え中には書き込みが一時停止されるので、データを失うことはありません。

このとても便利な機能を実際使って、スキーマ変更も試してみたので、必要な設定とかちょっと引っかかったところなどを紹介したいと思います。

対応データベース種類

AWSからの発表記事では、Blue/GreenデプロイはGA（一般公開）となってます。一応日本語版のRDSコンソールでは「ブルー/グリーンデプロイの作成 - ベータ」と表示されるからベータ版かと思われるかもですが、英語版のコンソールでは「Create Blue/Green Deployment - new」と表示されます。

2022年12月の現時点では、対応データベースの種類はMySQL互換性（MariaDBを含む）のRDSかAuroraのみとなります：

1. RDS for MySQL
2. RDS for MariaDB
3. Amazon Aurora with MySQL

Amazon Auroraでは、レプリケーションを正常に行うためにはパラメータグループ設定の binlog_format を OFF → MIXED に変更する必要があります。（RDS/MySQLは MIXED がデフォルトとなってるので、RDSの場合はこちらの設定は変更する必要ありません。）

ちなみに、上の構成図のようにマルチAZのDBインスタンスだけではなく、単一のDBインスタンスでもBlue/Greenデプロイは可能です。DBのインスタンスタイプはバースト可能クラス（db.t4g.microなど）でも問題ありません。

実際使ってみた

今回試したいのはスキーマ変更なので、例えばゲームアプリケーションの追加要素で既存の users テーブルに列を増やす必要があるとします。列を増やしたら、本番環境へのデプロイまでやります。

検証のための事前準備

実際スキーマの変更を試すには既存データが必要のため、事前準備としてDBにシンプルに users テーブルを作成します。

mysql> CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(64) ) ENGINE=InnoDB;
Query OK, 0 rows affected (0.09 sec)

mysql> DESC users;
+-------+-------------+------+-----+---------+----------------+
| Field | Type        | Null | Key | Default | Extra          |
+-------+-------------+------+-----+---------+----------------+
| id    | int         | NO   | PRI | NULL    | auto_increment |
| name  | varchar(64) | YES  |     | NULL    |                |
+-------+-------------+------+-----+---------+----------------+
2 rows in set (0.02 sec)

そしてユーザーのレコードも少し追加します。

mysql> INSERT INTO users ( name ) VALUES ( 'fred' );
Query OK, 1 row affected (0.03 sec)

mysql> INSERT INTO users ( name ) VALUES ( 'betty' );
Query OK, 1 row affected (0.02 sec)

mysql> SELECT * FROM users;
+----+-------+
| id | name  |
+----+-------+
|  1 | fred  |
|  2 | betty |
+----+-------+
2 rows in set (0.02 sec)

これで本番環境にデータが存在するので、事前準備は完了です。

Blue/Greenデプロイを作成

RDSコンソールからBlue/Greenデプロイを作成したい本番環境のDBを選択し、右上の「アクション」から「ブルー/グリーンデプロイの作成」を選びます。「Blue-Green環境識別子」に好きな名前を入力し、右下の「ステージング環境の作成」をクリックします。

ステージング環境のDBエンジンバージョンは本番環境より新しく設定できるので、DBエンジンのアップグレードは本番にデプロイする前にテストを行うのも可能です。

これでステージング環境のDBは新しく作成され、本番環境からのレプリケーションが設定されます。

ステージング環境を作成するには約15分程度かかりますが、この間は本番環境に影響はまったくありません。

開発・ステージング（Green）環境を見てみよう

ステージング環境が「利用可能」になったので、まずは接続して users テーブルを見てみましょう。

ステージング環境

$ mysql -u admin -h bgtest-green-bzh9ry.cXXXXXXXXXX9.ap-northeast-1.rds.amazonaws.com -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 16
Server version: 8.0.31 Source distribution

Copyright (c) 2000, 2022, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> use bgtest
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> show tables;
+------------------+
| Tables_in_bgtest |
+------------------+
| users            |
+------------------+
1 row in set (0.02 sec)

mysql> SELECT * FROM users;
+----+-------+
| id | name  |
+----+-------+
|  1 | fred  |
|  2 | betty |
+----+-------+
2 rows in set (0.02 sec)

本番環境からのデータは問題なくコピーされましたね。

本番環境からのレプリケーション同期を確認

ステージング環境のデータコピーができたので、リアルタイム同期のレプリケーションが正常に動いてることを確認しましょう。まずは本番環境で新規ユーザーが作成されるとします。

本番環境

mysql> INSERT INTO users ( name ) VALUES ( 'max' );
Query OK, 1 row affected (0.02 sec)

mysql> SELECT * FROM users;
+----+-------+
| id | name  |
+----+-------+
|  1 | fred  |
|  2 | betty |
|  3 | max   |
+----+-------+
3 rows in set (0.02 sec)

ステージング環境で同じSELECTだけを行うと、

ステージング環境

mysql> SELECT * FROM users;
+----+-------+
| id | name  |
+----+-------+
|  1 | fred  |
|  2 | betty |
|  3 | max   |
+----+-------+
3 rows in set (0.02 sec)

本番環境で行ったINSERTが正しくレプリケーションされてるの確認が取れました。

ステージング環境のスキーマを変更する（その１）

レプリケーション中にスキーマを変更する場合はいくつか制限があります。基本的にステージング環境での変更は可能なのは以下の通りです。

1. テーブルの列を増やす（DEFAULT必須・テーブルの最後に追加のみ、列の順番・名前の変更や削除は不可）
2. テーブルの新規作成
3. インデックスの新規作成
4. インデックスの削除

詳しく知りたい方はMySQLのソースとレプリカで異なるテーブル定義を使用したレプリケーションをご参考にしてください。

いよいよ、ステージング環境の users テーブルのスキーマを変更してみましょう。今回のゲームアプリケーションの追加要素では、ユーザーの勝ち負けのゲーム数を記録する必要になったので users テーブルに2つの列を追加します。

ステージング環境

mysql> ALTER TABLE users ADD (wins INT DEFAULT 0, losses INT DEFAULT 0);
ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot execute this statement
mysql> 

って、あれ...？

ステージング環境の書き込みを有効化にする

見逃しやすいのですが、ブルー/グリーンデプロイのドキュメンテーションにはちゃんと書いてあって、レプリケーションされたステージング環境（Green）はデフォルトで 読み取り専用 になってます。

そして、この読み取り専用の状態を 書き込み可能 に変更するのは可能です。

Blue/Greenデプロイを作成する際にはパラメータグループを指定することが可能なので、予め書き込み可能のパラメータグループを作成しておいてからBlue/Greenデプロイの作成を行うと適用・再起動の必要はなくなります。

新規パラメータグループを作成

書き込み可能に変更するにはDBインスタンスのパラメータグループを変更する必要があります。ただ、作成した時点のデフォルトで使った default.mysql8.0 というパラメータグループは編集できないので、新規作成する必要があります。

パラメータグループファミリーの正しいDBエンジンのバージョンを選択して、グループ名と説明を入力し作成します。新規作成したパラメータグループを選択し、パラメータ編集画面が開きます。

フィルタパラメータのフィルドに read_only を入力すると、すぐに変更する必要であるパラメータは表示されます。

この read_only パラメータ値が {TrueIfReplica} になってるので、レプリケーションされたDBインスタンスは True (1) となって、読み取り専用になります。

この値を 0 に変更して、右上の 変更の保存 ボタンをクリックするを忘れずに。

ステージング環境に新しいパラメータグループを適用する

RDSコンソールに戻って、ステージング環境のDBインスタンス（Green）を選択し、右上の変更ボタンをクリックします。

「追加設定」までスクロール（だいぶ下の方）し、 DBパラメータグループ を default.mysql8.0 から先ほど新規作成したパラメータグループに変更し、ページの右下の続行ボタンをクリックします。

変更される前には変更される項目の確認画面が出てきます。

確認するのは、

1. DBインスタンスがステージング環境（Green）のインスタンス名になってる
2. DBパラメータグループが新しく作成した書き込み可能のグループ名になってる

の2つだけです。「すぐに適用」を選択し、DBインスタンスを変更のボタンをクリックします。ステージング環境はすぐ「変更中」状態に変わりますが、まだ続きがあります。

数分が経ったらステージング環境は「利用可能」状態に戻りますが、設定タブを見ると 再起動を保留中 が表示されてますので、画面の一番右上の「アクション」ボタンから「再起動」を選択し、再起動をさせましょう。

ステージング環境のスキーマを変更する（その２）

改めて、ステージング環境の users テーブルのスキーマを変更してみましょう。

ステージング環境

mysql> SELECT * FROM users;
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    16
Current database: bgtest

+----+-------+
| id | name  |
+----+-------+
|  1 | fred  |
|  2 | betty |
|  3 | max   |
+----+-------+
3 rows in set (0.23 sec)

mysql> ALTER TABLE users ADD (wins INT DEFAULT 0, losses INT DEFAULT 0);
Query OK, 0 rows affected (0.03 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM users;
+----+-------+------+--------+
| id | name  | wins | losses |
+----+-------+------+--------+
|  1 | fred  |    0 |      0 |
|  2 | betty |    0 |      0 |
|  3 | max   |    0 |      0 |
+----+-------+------+--------+
3 rows in set (0.01 sec)

これでステージング環境でスキーマ変更ができたので、本番環境も見てみましょう。

本番環境

mysql> SELECT * FROM users;
+----+-------+
| id | name  |
+----+-------+
|  1 | fred  |
|  2 | betty |
|  3 | max   |
+----+-------+
3 rows in set (0.01 sec)

本番環境は以前のスキーマのままです。

ステージング環境の変更したスキーマとレプリケーション同期を確認

さって、スキーマが変更されたステージング環境ですが、この状態で本番環境に新規ユーザーが作成されるとどうなりますか？やってみましょう。

本番環境

mysql> INSERT INTO users ( name ) VALUES ( 'david' );
Query OK, 1 row affected (0.02 sec)

mysql> SELECT * FROM users;
+----+-------+
| id | name  |
+----+-------+
|  1 | fred  |
|  2 | betty |
|  3 | max   |
|  4 | david |
+----+-------+
4 rows in set (0.02 sec)

そしてステージング環境で同じSELECTだけを行うと、

ステージング環境

mysql> SELECT * FROM users;
+----+-------+------+--------+
| id | name  | wins | losses |
+----+-------+------+--------+
|  1 | fred  |    0 |      0 |
|  2 | betty |    0 |      0 |
|  3 | max   |    0 |      0 |
|  4 | david |    0 |      0 |
+----+-------+------+--------+
4 rows in set (0.02 sec)

スキーマが変更されたステージング環境でも、本番環境での新しいユーザーのレコードは正常にレプリケーションされますね。実際の検証画面がこちらです。

繰り返しにはなりますが、この時点までは本番環境には一切影響はありません。途中で何か失敗した場合はステージング環境とBlue/Greenデプロイを削除し、やり直してもまったく問題ありません。

本番環境へのデプロイ

ステージング環境のスキーマ変更作業が終わったので、切り替えをすることで変更された内容が本番環境にすぐに反映されることができます。RDSコンソールからブルー/グリーンデプロイを選択し、右上の「アクション」ボタンから「切り替え」を選択します。

本番環境はBlueからGreenに切り替えたいので、そのまま「切り替え」ボタンをクリックします。

切り替えを待ってる間は本番環境に連続で同じSELECTを実行してみましょう。

本番環境

mysql> SELECT * FROM users;
+----+-------+
| id | name  |
+----+-------+
|  1 | fred  |
|  2 | betty |
|  3 | max   |
|  4 | david |
+----+-------+
4 rows in set (0.02 sec)

mysql> SELECT * FROM users;
+----+-------+
| id | name  |
+----+-------+
|  1 | fred  |
|  2 | betty |
|  3 | max   |
|  4 | david |
+----+-------+
4 rows in set (0.02 sec)

mysql> SELECT * FROM users;
【＊＊＊　ここで9秒間の待機時間が発生　＊＊＊】
ERROR 2013 (HY000): Lost connection to MySQL server during query
No connection. Trying to reconnect...
Connection id:    67
Current database: bgtest

+----+-------+------+--------+
| id | name  | wins | losses |
+----+-------+------+--------+
|  1 | fred  |    0 |      0 |
|  2 | betty |    0 |      0 |
|  3 | max   |    0 |      0 |
|  4 | david |    0 |      0 |
+----+-------+------+--------+
4 rows in set (9.06 sec)

できました！「切り替え」ボタンを押してから1分以内で、たった9秒間の待機時間がありましたが、本番環境には新しく変更したスキーマが無事にデプロイされました。

切り替えのあと

切り替えが終わったら、RDSコンソールはこんな感じになります。

注目すべきなのが、

1. 切り替え前のステージング環境の「DB識別子」が切り替え前の本番環境に変更された
2. 切り替え前の本番環境が 「〇〇-old」 に変更された
3. ブルー/グリーンデプロイが「切り替え完了」状態になった

以前の本番環境が名前変更され、残っているということです。必要がなくなったら、ブルー/グリーンデプロイと一緒に削除しましょう。

まとめ

読み返してみると結構な量になってしまいましたが、必要な設定さえ準備しておけば、非常にシンプルなシステムになってます。

1. Blue/Greenデプロイを作成
2. Greenのスキーマを変更
3. 作業が終わったら切り替え

デプロイを作成した際に書き込みを有効にするパラメータグループを設定するを忘れた場合は、

1. Greenにパラメータグループを適用
2. Greenを再起動

もしくは、Blue/Greenデプロイを削除し、新しく作り直すのも可能です。

これよりもっと詳しく知りたい方はこちらの記事もぜひ。

宣伝

JAWS-UG GameTech専門支部はゲームに関する情報交換、技術紹介、Tips、テクノロジーアップデート紹介を通じてGameTech界隈を盛り上げていくことを目的としたコミュニティです。コミュニティスペースとして Discord を活用していますので、ゲームとAWSの交流したい方はぜひご参加ください。

12月8日(木)は 第3回: re:Invent 2022 re:Cap のオンライン勉強会も行いますので、都合がよかったらご参加ください。