アマゾン ウェブ サービスは、ニーズに応じて、Elastic Beanstalk、OpsWorks、Cloud Formation、Code Deploy などの継続的なデプロイおよび管理ツールを多数提供しています。基本的な考え方は、ダウンタイムなしでコードの展開とアップグレードを容易にすることです。また、AWS リソースを使用してベスト アーキテクチャ プラクティスを管理するのにも役立ちます。
簡単にするために、2 つのティア構造を持つ基本的なアーキテクチャを想定します。ロード バランサーの背後にあるアプリケーション サーバーのコレクションと、マルチゾーン RDS DB を使用した永続レイヤー。
インスタンス (アプリ サーバー) のフリート全体での実際のコード アップグレードは、理解しやすいものです。非常に単純化した概要として、AWS のサービスは各ノードを順番にアップグレードし、接続を引き渡すため、問題のインスタンスは使用されません。
しかし、DB のアップグレードがどのように管理されているのか理解できません。アプリケーションのバージョンを 1.0.0 から 2.0.0 に移行しようとしており、DB 構造を変更する必要があるとします。通常は、スクリプトまたは Flyway などのライブラリを使用してアップグレードを実行します。ただし、アップグレードするサーバーのフリートがある場合、フリート全体に 1.0.0 と 2.0.0 の両方のアプリケーションが存在し、それぞれが異なる DB 構造を必要とするポイントがあります。
DB移行を実行する最良の方法/時間は何かを知るために、これが実際にどのように達成されるか(高レベル)を理解する必要があります。彼らがこれを達成する方法はいくつかあると思いますが、どうすればそれを実現し、1.0.0 と 2.0.0 の両方でデータを失うことなく永続化できるようにするのか、私は苦労しています。
最初のアプリ ノードのアップグレードで DB 構造を移行し、同時に 1.0.0 のキャッシュ バージョンを作成するとします。1.0.0 アプリに接続しているユーザーはキャッシュされたバージョンの DB を使用して維持され、2.0.0 アプリに接続しているユーザーは新しく移行された DB に維持されます。すべてのアプリ ノードが移行されると、キャッシュされたデータが DB にマージされます。
マージはかなり複雑になるため、これを実行できる可能性は低いようですが、別の方法がわかりません。ポインタ/ヘルプをいただければ幸いです。