なに
- 公式ドキュメントを読んで内容をまとめます
- 実機操作はしません
なにができる機能か
- 本稼働データベースをコピーしたステージングを簡単に作れる
- ステージングは本稼働に影響を与えること無く変更を加えることができる
- 本稼働と同データで様々な設定変更および検証が可能
- ステージングを本稼働に昇格させることができ通常ダウンタイムは1分未満
用語
- 本稼働：ブルー
- ステージング：グリーン
本機能を使用するメリット
- 本稼働と同等の環境がすぐに作成可能
- 本稼働へ影響を与えない切り離された安全なステージング環境で設定変更やテストができる
- 本稼働のDB変更をステージングへ自動レプリケーション
- アプリケーション影響無しでステージングを本稼働へ切り替え可能
- 組み込みの切り替えガードレールを使用して安全に切り替え可能
- 切り替え中のデータ損失をなくす
- ダウンタイムは１分以内
ブルー/グリーンのワークフロー
- 更新が必要な本稼働DBクラスターを特定
- ブルー/グリーンデプロイの作成
- ブルーをコピーしてグリーンを作成する
- グリーンのクラスター/インスタンス名には
-green-random-charactersが名前の後ろに付与される - グリーンに任意のエンジンバージョン、パラメータグループなどを設定可能
- ブルーからグリーンへのレプリケーション設定
- グリーンへ任意の設定変更を適用
- パッチ適用
- エンジンバージョン更新
- パラメータグループ更新/変更
- などなど
- グリーンでのテスト
- ブルー/グリーンの切り替え
- ダウンタイムは通常１分未満
- ワークロードによっては長くなることもある
- 不要になったブルー/グリーンデプロイは削除可能
- 残しておいても良い
- が、２倍の料金がかかる
切り替え後のクラスター/インスタンスの状態
- グリーンにブルーの名前が適用される
- そんためアプリケーションやCLIなどの変更を必要としない
- ブルーのクラスター/インスタンス名には
-oldnが名前の後ろに付与される-
nは1から始まる数値でインクリメントされる
-
- 切り替え後の名前例
- ブルー
-
auroradbという名前の DB クラスターはauroradb-old1 -
auroradb-instance1という名前の DB インスタンスはauroradb-instance1-old1
-
- グリーン
-
auroradb-green-abc123という名前の DB クラスターはauroradb -
auroradb-instance1-green-abc123という名前の DB インスタンスはauroradb-instance1
-
- ブルー
権限
- 各処理に必要なポリシーは以下となる
ブルー/グリーンデプロイ作成
rds:AddTagsToResource
rds:CreateDBCluster
rds:CreateDBInstance
rds:CreateDBClusterEndpoint
ブルー/グリーンデプロイ切り替え
rds:ModifyDBCluster
rds:PromoteReadReplicaDBCluster
ブルー/グリーンデプロイ削除
rds:DeleteDBCluster
rds:DeleteDBInstance
rds:DeleteDBClusterEndpoint
注意点/考慮事項
グリーン
- デフォルトでDBクラスターは
書き込み許可となっているが読み取り専用にするのが良い- 仮にグリーン独自の書き込みが発生するとブルーとの入れ替え時にデータ不整合が発生し不具合が生じる可能性が高いため
Resouce ID
-
Resouce IDはブルー/グリーン切り替え後も元々のIDを保持する -
Resouce IDを指定している箇所がある場合は本稼働に向けて修正対応が必要
主な対応例
- CloudTrail で
Resouce IDを使用して追跡している - データベースアクティビティストリームを使用している場合
- パフォーマンスインサイトAPIを使用している場合
- IAMポリシーで
Resouce IDを使用している場合 - IAMデータベース認証を使用している場合
スナップショット
- スナップショットの取得時間を確認し「切り替え後」に取得されたスナップショットから復元すること
インスタンスの追加/削除
- グリーン環境に新規DBインスタンス追加後に切り替えた場合、そのまま本稼働のDBインスタンスとして残り稼働する
- グリーン環境でコピーされたDBインスタンスを削除すると切り替え時に変わりとなるDBインスタンスは作成されない
ベストプラクティス
- 切り替えを行う前に十分にグリーンにてテストを実施する
- グリーンのDBは「読み取り専用」を維持する
- ブルーからのレプリケーションで競合が発生する可能性
- 書き込みは非常に慎重に行う
- スキーマの変更では「レプリケーション互換」がある変更のみを行う
- 「列名変更」「テーブル名変更」はレプリケーションを中断させてしまうので注意
- 「新しい列追加」「インデックス作成/削除」は大丈夫
制限事項
- Aurora MySQL
2.082.09は対象外 - ブルーに
tmpと名の付いたデータベースを含められない- グリーンにコピーもされない
- ブルー/グリーンデプロイは以下機能をサポートしてない
- Amazon RDS Proxy
- クロスリージョンリードレプリカ
- Aurora Serverless v1 DB クラスター
- Aurora Global Database の一部である DB クラスター。
- AWS CloudFormation
- ブルー/グリーンデプロイの制約事項
- 暗号化されてないクラスターを暗号化したクラスターに変更できない
- この逆も出来ない
- グリーンのエンジンバージョンはブルーよりも上位でないと駄目
- ブルーとグリーンは同じAWSアカウントでないと駄目
- ブルーの「Aurora Auto Scalingポリシー」はグリーンにコピーされない
- 暗号化されてないクラスターを暗号化したクラスターに変更できない
ブルー/グリーンデプロイの作成
作成条件
- 本稼働クラスターの「クラスターパラメータグループ」にて「バイナリログ
binlog_format」がONとなっていること- 設定は
ROWがおすすめ - バイナリログをONにするとDBクラスターへの「書き込みディスクI/O」操作が増加する
-
VolumeWriteIOPsCloudWatchメトリクスを使用してIOPSの使用状況をモニタリング
- 設定は
-
binlog_formatを有効にするにはクラスター内インスタンスの再起動が必要
作成時にグリーンへ行える変更
- 上位エンジンバージョンへの変更
- 異なるパラメータグループへの変更
- クラスターパラメータグループ、インスタンスパラメータグループ両方
作成方法
- 作成方法には以下3種類ある
- AWSコンソール
- AWS CLI
- RDS API
ブルー/グリーンデプロイの切り替え
トラフィック
- 切り替え前はブルーのクラスターにルーティングされる
- 切り替え後はグリーンのクラスターにルーティングされる
切り替えタイムアウト
- 切り替え作業のタイムアウト時間は「30秒から３，６００秒」で設定可能
- デフォルトは「３００秒」
- タイムアウトした場合は全ての変更がロールバックされブルー/グリーンどちらにも変更は加わらない
切り替えガードレール
- 切り替え開始するとRDSは切り替え可能かチェックを実施する
- これを「切り替えガードレール」と呼ぶ
- ガードレールにより想定外の失敗を防ぎブルー/グリーン間のデータ損失を防ぐ
ブルーへのチェック
- 切り替え中に書き込みが発生しないように「外部レプリケーション」の「ターゲット」でないことを確認
- レプリカラグの増加可能性から実行時間の長い「アクティブな書き込み」がないことを確認
- レプリカラグの増加可能性から実行時間の長い「DDLステートメント」がないことを確認
グリーンへのチェック
- クラスターのレプリケーションステータスが正常であることを確認
- レプリカラグが許容範囲内であるか確認
- 許容範囲は設定した「タイムアウト時間」に基づく
- レプリカラグは「グリーン」が「ブルー」よりどれだけ遅れているか、を示す
- 「アクティブな書き込み」がないことを確認
切り替えアクション
- ガードレールチェックによる切り替え準備確認
- ブルー/グリーン両方の「書き込みオペレーション」停止
- ブルー/グリーン両方のインスタンスへの接続切断（新規接続NG）
- ブルー/グリーンでレプリケーションが同期されるまで待機
- ブルー/グリーンの名称変更
- ブルーのクラスター、インスタンスの名称を変更
- グリーンのクラスター、インスタンスの名称を変更
- グリーンのエンドポイントをブルーのエンドポイントと一致するように変更
- ブルー/グリーン両方のインスタンスへの接続を許可
- 新本稼働クラスターへの「書き込みオペレーション」を再開
- 元本稼働クラスターは「読み取りオペレーション」のみ許可
Amazon EventBridge
- EventBridgeでブルー/グリーンのスイッチオーバーをモニタリングできる
タグ
- ブルーのタグはグリーンが本稼働になった場合も引き継ぐ
切り替えのベストプラクティス
- 切り替え前にグリーンでのテストを徹底的に行うこと
- Amazon CloudWatachメトリクスのモニタリングを行う（詳細は後述）
- 切り替えのタイミングを検討する
- 切り替え中は「書き込みが遮断」されるためトラフィックが少ない時間帯を選択する
- トランザクションの実行時間が長いとダウンタイムが長くなるため
- ブルー/グリーンのクラスターおよびインスタンスが
Availableであること - グリーンのクラスターが正常かつレプリケートが正常であること
- ネットワークおよびクライアントの設定でTTLを5秒を超えないようにする
- Aurora DNSゾーンのデフォルトTTLは5秒
- それ以上になるとブルーへのトラフィックが続いてしまう
切り替え前の CloudWatachメトリクス 確認
- 切り替え前、特に確認したほうが良いメトリクス
| メトリクス | なに | 切り替え前確認 |
|---|---|---|
AuroraBinlogReplicaLag |
グリーンの現在のレプリケート遅延を特定するメトリクス | ダウンタイム時間を減らすためにも値がゼロに近いことを確認する |
DatabaseConnections |
ブルー/グリーンの現在のアクティブコネクションを特定するメトリクス | サービスで許容可能なアクティブであるか確認する（より正確な値は DBLoad を確認） |
ActiveTransactions |
innodb_monitor_enable が all に設定されている場合に切り替えを妨げるトランザクションを特定するメトリクス |
切り替えを妨げる可能性のあるアクティブなトランザクションの数が多いか確認する |
切り替え後
- 切り替え後もブルー/グリーンのクラスターおよびインスタンスは保持される
- 保持されたクラスターおよびインスタンスには料金がかかる
- ブルー/グリーン間のレプリケーションおよびバイナリログは停止される
ブルー/グリーンデプロイの削除
- ブルー/グリーンデプロイは「切り替え前」「切り替え後」に削除できる
- 「切り替え前」の削除では以下のオプションが選択可能
- グリーンのクラスターを削除する
- グリーンのクラスターを削除せず残す
- ブルー/グリーンデプロイの一部でなくなる
- レプリケーションは継続される
- ブルー/グリーンデプロイを削除しても本稼働クラスターには影響ない
Discussion