[re:Invent 2022] Using RDS Blue/Green Deployments

Slide 1

Slide 1 text

re:Invent 2022で発表されたRDSのBlue/Green デプロイ新機能を使ってみた第28回 JAWS-UG札幌勉強会 2022年12月9日 (金) 株式会社コールド・フュージョンテッダー　マイケル JAWS-UG札幌支部

Slide 2

Slide 2 text

$ whoami > テッダー　マイケル（昭和51年生まれ / 2000年アメリカから日本） > 25年以上ゲーム業界でリアルタイム3Dと最適化中心のゲーム開発　　（初代PS 〜 Switchゲーム機 / モバイル端末 / PC / Oculus VR） > 10年以上AWSのクラウドアプリケーション開発（現在はサーバーレス / コンテナ） > JAWS-UG GameTech+札幌運営 / Tokyo Demo Fest実行委員 / AWSコミュニティビルダー > できること: ゲームエンジン開発 / 開発者向けツール開発 / DevOps (CI/CD) アプリ+バックエンド開発 / クラウドアーキテクチャ設計 > 好きな言語: C++17 / GLSL / ASM (x64/ARM/MIPS) / PHP / TypeScript > 好きなゲーム: Satisfactory / Final Fantasy XI > 好きなAWSサービス: Lambda

Slide 3

Slide 3 text

今日お話しすること ● はじめに ○ Blue/Greenデプロイとは ○ RDSでのBlue/Greenデプロイ ● 使ってみた ○ Blue/Greenデプロイを作成 ○ ステージング環境の確認 ○ ステージング環境のスキーマを変更 ○ 本番環境へのデプロイ ● ライブデモ

Slide 4

Slide 4 text

はじめに

Slide 5

Slide 5 text

Blue-Green Deploymentは、検証環境をそのまま本番環境として利用することで、システムの停止時間を最小にするデプロイ手法です。” “ Blue/Greenデプロイとは https://www.iij.ad.jp/svcsol/category/cloud/bp/ra005.html - IIJより

Slide 6

Slide 6 text

Blue/Greenデプロイはなぜ便利か ● 現代アプリケーションはローンチが終わりじゃない ● ローンチ後、追加要素・新機能増やす必要がある ○ コードはもちろん、データ構成変更もよくある ● 切り替え作業に時間かかる ○ メンテナンス作業でダウンタイム ○ 深夜にやる？途中で問題が発生したら...？ Blue/Greenを使うことで全て解決してくれます！

Slide 7

Slide 7 text

RDSでのBlue/Greenデプロイ ● 本番環境のデータベース（Blue）をレプリケーションすることで、ステージング環境（Green）が作成 ● 本番環境のデータ変更（INSERT・UPDATEなど）がステージング環境にリアルタイムで同期 ● ステージング環境のスキーマ変更は可能（※ 一部不可能の変更もある） ● ステージング環境の作業が終わったら、ほぼゼロダウンタイムで本番環境にデプロイが可能 ● アプリケーション側の変更は必要なし

Slide 8

Slide 8 text

対応データベース種類（現状） ● RDS for MySQL ● RDS for MariaDB ● Amazon Aurora with MySQL MySQL互換性（MariaDBを含む）のRDSかAurora

Slide 9

Slide 9 text

使ってみた

Slide 10

Slide 10 text

サンプルデータの作成（本番環境）

Slide 11

Slide 11 text

Blue/Greenデプロイを作成 ● ステージング環境作成には15分程度かかる

Slide 12

Slide 12 text

● 本番環境からデータが正常にコピーされたかステージング環境の確認本番環境と同じデータステージング環境のホスト名

Slide 13

Slide 13 text

● 本番環境から正常にレプリケーションされるかステージング環境の確認本番環境でINSERT ステージング環境にリアルタイム同期

Slide 14

Slide 14 text

いくつか制限がある ● テーブルの列を増やす ○ DEFAULT必須・テーブルの最後に追加のみ ○ 列の順番・名前の変更や削除は不可 ● テーブルの新規作成 ● インデックスの新規作成 ● インデックスの削除ステージング環境のスキーマを変更

Slide 15

Slide 15 text

ステージング環境のスキーマを変更 ● users テーブルに2列を増やしてみる …あれ？

Slide 16

Slide 16 text

ステージング環境の書き込み有効化 ● ステージング環境はデフォルト読み取り専用 ● 書き込み可能に変更するのは可能 ○ ステージング環境のパラメータグループ変更 ○ Blue/Greenデプロイ作成時にパラメータグループを指定

Slide 17

Slide 17 text

パラメータグループ設定変更 ● read_only という値を {TrueIfReplica } → 0 ● 書

Slide 18

Slide 18 text

ステージング環境のスキーマを変更 ● 改めて users テーブルに2列を増やしてみるステージング環境

Slide 19

Slide 19 text

ステージング環境のスキーマを変更 ● 改めて users テーブルに2列を増やしてみる本番環境（変更されてない）

Slide 20

Slide 20 text

変更されたスキーマとのデータ同期 ● 本番環境にデータ追加 ● スキーマ変更のステージング環境に同期

Slide 21

Slide 21 text

変更されたスキーマとのデータ同期 ● 本番環境にデータ追加 ● スキーマ変更のステージング環境に同期この時点までは本番環境には一切影響はない。途中で何か間違った場合はステージング環境を削除し、やり直してもまったく問題ありません。

Slide 22

Slide 22 text

本番環境へのデプロイ ● RDSコンソールで「切り替え」押すだけ ● クリックしてから1分以内 ● 実際検証ではたった9秒間接続不可状態になってた ● アプリケーション側でリトライ機能があればほぼ気づかないかも？