新年あけましておめでとうございます。

初詣への移動中、気がついたら年を越していたインフラエンジニア @sasashuuu です。

2023年1本目の記事をお届けしたいと思います。

本日は、Amazon RDS、Amazon Auoraでリリースされた新しい機能である Amazon RDS Blue/Green Deployments 利用時に躓いたエラーやハマったポイントがいくつかあったので、それらをまとめた内容を取り上げました。本機能を利用する方々の一助になれば幸いです。

はじめに

本記事は2022年12月時点で検証していた際の内容となります。記事公開の時点では当時と状況が変わっている可能性がありますので、最新情報等はAWS公式サイト（Using Amazon RDS Blue/Green Deployments for database updates 等）を参照してください。

Amazon RDS Blue/Green Deploymentsとは

Amazon RDS、Amazon AuroraにおいてBlue/Green デプロイが行える機能です。細かい仕様については触れませんが、ざっくりと機能利用時のワークフローを説明すると、下記のような流れです。

※Auroraの場合の例

対象のAurora（Blue環境）から新しいリソース（Green環境）がクローンで複製される
Blue/Green環境間でレプリケーションが開始される
クラスターの識別子やエンドポイントの変更なしに、Green環境のリソースをスイッチオーバーで稼働中のBlue環境リソースと入れ替える

※画像は公式ドキュメント Overview of Amazon RDS Blue/Green Deployments for Aurora より転載

このように本番環境からステージング環境を作成し、レプリケーションにより同期、さらにスイッチオーバーでエンドポイントの変更などなしに新規Auroraリソースの本番環境への昇格までもおこなってくれるという便利な機能です。

詳細については公式を参考にしていただければと思います。

躓いたエラーやハマりポイント

前提

まず前提として、公式ドキュメント Limitations for blue/green deployments に書かれているように、以下の条件下ではそもそも本機能自体が利用できません。

Amazon RDS Proxy
Cross-Region read replicas
Aurora Serverless v1 DB clusters
DB clusters that are part of an Aurora global database
AWS CloudFormation

具体的な内容

そしてここからは、実際に本機能を使ってみて躓いたエラーやハマりポイントについてまとめます。ざっくり以下のような内容です。

パラメータグループにおけるバイナリログ出力の有効化が必要（binlog_format ⇒ MIXED）
パラメータグループ変更時の適用（リブート）漏れがあるとGreen環境を作成できない
クラスタに紐づけているサブネットグループにおいて3az以上の指定が必要
Green環境作成前のBlue環境に対する何らかの書き込み操作が必要

ひとつずつ解説していきます。

1. パラメータグループにおけるバイナリログの出力の有効化が必要（binlog_format ⇒ MIXED）

本機能はバイナリログを使用したレプリケーションを伴うので、バイナリログ出力を有効にしておく必要があります。クラスター用のパラメータグループの設定値に binlog_format があるので、その設定値を MIXEDにしておく必要があります。これを行わなければ下記のようなエラーが発生します。

Blue Green Deployments requires cluster parameter group has binlog enabled.

ちなみにこちらは公式ドキュメントの Preparing an Aurora DB cluster for a blue/green deployment で解説されていました。

Before you create a blue/green deployment for an Aurora MySQL DB cluster, the DB cluster must be associated with a custom DB cluster parameter group with binary logging turned on. For example, set the binlog_format parameter to ROW.

ただ、上記の説明では ROW を例に出していますが、中には ROW だとうまくいかなかった事例などもあるそう（Aurora の Blue/Green デプロイで少し遊んでみた（Aurora MySQL v1 → v3 Blue/Green 失敗編））で、また、公式ブログ（新機能 – Amazon Aurora と Amazon RDS でのフルマネージド型 Blue/Green Deployments）でも MIXED を指定するように促していることから、MIXED を指定する方が良さそうです。

2. パラメータグループ変更時の適用（リブート）漏れがあるとGreen環境を作成できない

Blue環境側でクラスターパラメータグループを変更したのち（適用タイプがstaticのものなど）、本機能を使用してGreen環境を作成しようとすると、下記のエラーが出ることがあります。変更したパラメータグループが適用されていないために起こるエラーです。これは本機能利用以前の話（詳細はAWS公式ドキュメントパラメータグループを使用するなどを参照）にはなりますが、失念するとGreen環境が作成できないため、対象クラスター内のインスタンスのリブートを忘れないように行う注意が必要です。

Blue Green Deployments requires writer instance to be in-sync with cluster parameter group.

3. クラスタに紐づけているサブネットグループにおいて3az以上の指定が必要

公式ドキュメント等での言及については見当たらずだったのですが、どうやらクラスターにアタッチしているサブネットグループには3つ以上のAZを指定しないといけないという仕様がある模様です。 Amazon RDSのBlue/Green Deploymentsを実験して気づいたハマりポイントまとめや Amazon AuroraでBlue/Greenデプロイを検証する。のブログの記事で取り上げられていたおかげで問題に対処することができました。

4. Green環境作成前のBlue環境に対する何らかの書き込み操作が必要

Green環境の作成前に、Blue環境で何かしらの書き込み処理を行わなければ、下記のエラーが発生してしまいます。

Correct the replication errors and then switch over.

Read Replica Replication Error - IOError: 1236, reason: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

これは一般的にはレプリケーション先（Green側）が参照しようとするバイナリログがレプリケーション元（Blue側）に存在しないことで起きてしまうエラーであり、Amazon RDS Blue/Green DeploymentsにおいてAWS側の内部動作上の問題として認知されているそうです。（※サポートへ確認済み）

対策として、バイナリログの出力を有効にしたのち、Green環境作成前にBlue側のデータベースに対して何かしらの書き込み処理を行う必要があるとのことです。（任意のテーブルに任意のレコードINSERT等）

その他のエラーやハマりポイントについて

本記事で紹介した事例以外に他にもいくつか取り上げられているものがあるみたいです。下記のブログなどが参考になるので、併せて参考にしていただければと思います。

おわりに

Amazon RDS Blue/Green Deploymentsは、リリースされて日が浅い新機能ですので、オープンにはなっていない細かい部分の仕様などによる不具合が見られますが、これから改善されていく見込みかと思われます。弊社では本機能を使用し、Aurora MySQL 5.6 (Amazon Aurora MySQL Version 1)のEOL対応（詳細は Amazon Aurora MySQL 互換エディションバージョン 1 のサポート終了に向けて準備するなどを参照）などに活用していければと思っている期待の機能です。皆様も機会があればぜひ利用してみてください。

コネヒト開発者ブログ