【衝撃】AWSのRDSがデータを失わないBlue/Greenデプロイに対応しました #reinvent

「最近は、データベースもB/Gデプロイできるらしいよ？」

「そりゃそうやろ。B/Gデプロイなんて、最近当たり前………　へ？DBが？無理でしょ？ほぇ？どういうこと？」

最初アップデートのタイトルを見たときの、ハマコーの率直な感想です。

Blue/Greenデプロイは、現行バージョンのトラフィックを活かしたまま新バージョンを動作確認し、問題なければ新バージョンをリリースするという、最近の安全なデプロイの概念において無くてはならないものです。

同時に新旧バージョンを稼働させるため、基本的にはステートレスなアプリケーション・サーバーにおいて利用するものという固定概念があったのですが、それをデータベースに対して既存のAWSの技術を組み合わせつつAWSらしいマネージドな仕組みで解決しようという、意欲的なリリースです。制約事項もそれなりにあるので、皆さんの運用ワークロードに当てはまるかは、事前の検証が必須となっています。

この記事では、速報的に概要を把握するために、まずは公式情報をかいつまんでまとめることを目的にしており、実際に動かしてみた内容は含まれていないこと、ご承知おきください。

RDSの新リリースきたか…!!
　 ( ﾟдﾟ)　ｶﾞﾀｯ
　 /　　 ヾ
＿_L| /￣￣￣/＿
　 ＼/　　　/

アップデートのサマリー情報

What's Newで、紹介されています。

上記What's Newの抄訳。

Amazon RDSは、今回のアップデートでBlue/Greenデプロイをサポートし、安全かつシンプルなデータベースの更新に対応します。Blue/Greenデプロイを利用することで、管理されたステージング環境を作成し、現在の本番データベースを維持したまま、本番環境の変更をデプロイしてテストすることが可能です。ワンクリックで、ステージング環境を新しい本番システムに昇格させることができ、アプリケーションの変更も不要で、データの損失も有りません。

Amazon RDS Blue/Green Deployments を使用して、Amazon RDS Console から数クリックでデータベースを更新できます。

データの損失も無いということなので、新旧で更新データの同期がとれるということでしょうか。なかなかにアツいアプデのようです。

対象のリージョンとエンジンバージョン

対象のバージョンは、今はMySQLベースのものになっており、PostgreSQLは対象外のようです。すでに中国リージョン以外の全リージョンで一般提供開始とのことなので、即時利用できます。

• 対象バージョン
  • Amazon Aurora with MySQL compatibility 5.6 以上
  • Amazon RDS for MySQL 5.7 以上
  • Amazon RDS for MariaDB 10.2 以上
• 対象リージョン
  • すべてのAWSリージョン（AWS中国リージョンを除く）とAWS GovCloud（米国リージョン）

RDSのBlue/Greenデプロイの動作概要について

AWSの公式ブログに、もうすこし詳細な内容が記載されています。

B/Gデプロイの凄さの要約

データベース更新における運用を可能な限り安全にかつ的確に実行できるように、既存の技術をマネージドな仕組みでまとめた素晴らしいコンセプトだと思います。

• 数ステップで、本番環境をミラーリングするフルマネージドなステージング環境を作成
• ステージング環境は、本番環境のプライマリデータベースとリージョン内リードレプリカのクローンを作成
• Blue/Greenデプロイメントでは、論理レプリケーションを使用して2つの環境の同期を維持
• ステージングの昇格にかかる時間はわずか1分
• 切替の間、Blue環境もGreen環境も両方、書き込みをブロックしデータ損失を防ぐ
• 最後に、本番環境のトラフィックを昇格したステージング環境にリダイレクト
• あらゆるシチュエーションで利用可能
  • エンジンのアップグレード
  • （重要）スキーマの変更
  • OSやメンテナンスのアップデート対応

スキーマの変更にも、レプリケーションが対応可能な範囲でデータ同期してくれるとのこと。楽だコレ。

B/Gデプロイ for Databaseの公式ドキュメント

RDSの公式ドキュメントに1セクション増えています。

実際の動作イメージは、公式ドキュメント（以下は公式ドキュメントから引用）に画像つきで紹介されているので、まずはこちらをみると理解が捗るかと思います。

B/Gデプロイの利用上の考慮事項

公式ドキュメントには、利用上の考慮事項も記載されています。代表的なものをまとめてみました。

Considerations for blue/green deployments

• Blue/Greenデプロイは、リソースに固有のIDにより、リソースを識別する
• Blue/Greenデプロイにより、Greenリソースが本番リソースに昇格した場合、リソースIDは変更される

そのため、リソースIDに依存した運用がある場合、そのメンテナンスが必要になります。

• RDS APIをリソースIDを利用してフィルタリングしている場合
• リソースの監視に、リソースIDに依存しているCloudTrailを利用している場合
• IAMポリシーでリソースIDを利用している場合
• AWS BackuupでリソースIDをしている場合

リソースIDが変わることによる影響は、だいぶ大きそうですね。IAMポリシーなども、ID指定しているシチュエーションは結構あると思うので、リソースIDが変わって、RDS操作できなくなった！なんてことが無いように、事前の検証はしっかりやっておく必要がありそうです。

B/Gデプロイのベストプラクティス

実際にどのようなシチュエーションで使うのが良いのか、ベストプラクティスが紹介されています。

Best practices for blue/green deployments

自分が気になったのは、スキーマ変更に関する記述。全てのスキーマ変更が、データのレプリケーションに対応しているわけでは有りません。

• レプリケーションに対応しているスキーマ変更
  • テーブル末尾への列追加
  • インデックスの作成と削除
• レプリケーションに対応していないスキーマ変更
  • 列名の変更
  • テーブル名の変更

このあたり、レプリケーションの動作を考えると当たり前の話ですね。スキーマ変更がなんでもB/Gデプロイのデータレプリケーションに対応しているわけではないこと、注意しておきましょう。

B/Gデプロイの主な制約

このあたりのサービス使っていると、利用できないようです。

Limitations for blue/green deployments

• Amazon RDS Proxy
• Cascading read replicas
• Cross-Region read replicas
• Multi-AZ DB clusters
• AWS CloudFormation

個人的にはCloudFormationが対応していないのは、結構きついかもですね。リソース定義を静的にコードで記載するのと、ある程度AWS側のマネージドな仕組みでリソースID含めた変更がはいるのは、運用が破綻しそうなのでしかたないかなとも思います。

制約はある程度あるが、マネージドな仕組みでDB変更に安全性をもたらす夢の技術

このアップデート内容、弊社DBご意見番であるところのGuriさんの所感は、こんな感じでした。

今回のアップデートでやりたいことは、手間は少しかかりますが以前から可能（通常の RDS の Replica 上で DDL を実行して昇格する運用）でした。
今回の運用で昇格が高速になり、手間もかからない点が以前と大きく異なっている点かと思います

というところで衝撃は大きいのですが、一つ一つの技術は特段目新しいものでは無いとのこと。ただ、マネージドな仕組みでユーザーフレンドリーに提供され、昇格が高速になっているのが、B/Gデプロイを実現する上での大きな転換点と言えそうです。

ドキュメントベースに、主な動作内容は制限事項をまとめてみました。まだ詳細は把握できておらず、実際のプロダクション導入前には入念な検証が必須なのは間違いないですが、うまく使うと、本番環境のDB変更のリスクを飛躍的に抑える可能性があるアップデートだと思います。

RDSやAuroraを使っている人は、まずは一回手元で動かしてみて、動作検証してみても良いのではないでしょうか。皆さんの日々の運用がさらに進化する可能性を秘めていると思います。

それでは、今日はこのへんで。濱田（@hamako9999）でした。