単一のデータベースによるブルーグリーンの導入
お客様にダウンタイムなしのアップグレードを提供するために、ブルーグリーンの展開戦略を分析しています。データストアとしてOracleを使用するエンタープライズJavaベースのモノリシックWebアプリケーションがあります。専門家の意見を得るためにいくつかの課題があります。
すべてのデータベースオブジェクトタイプ（プロシージャ、テーブル、インデックス、制約など）では、特別な処理が必要です。それらのほとんどは ここ と記述されています。最終的には、ユースケースごとに細かいコード処理が必要になります。
ブルーグリーンの展開では、アクティブユーザーのWebセッションをどのように処理しますか？セッション終了イベントを検出しますか？
このようなアプローチの実装作業には、時間（約1年の投稿が示唆するとおり）と、それが正しく行われるように細心の注意が必要です。これに代わるシンプルで優れた方法はありますか？
ありがとう！
ロードバランサー
2番目のポイントについては、適切なロードバランサーを使用します。トラフィックの一部をシフトして、最初に新しい展開を証明し、次に徐々に展開することができます。また、迅速なバックアウト戦略も可能になります。
データベースのバージョン管理
これには2つの方法があります。
- Authoritive Dataフォーム（SQLスキーマ）をGreen/Blueバージョン間で下位互換性を持たせます（schema/procs/etcの古いバージョンは破棄/削除/ダンプできます）。
- データの信頼できるソースを別の場所に移動し、SQLスキーマを動的に更新されるビューとして扱います。すべてのprocs/schema/etcに何らかのバージョンプレフィックスを付けて、各デプロイメントでそのビューを再構築するだけです。
最初の方法では、アプリケーションをデータ表現から遠ざけ、すべてのデータ転送をストアドプロシージャ経由で移動することは理にかなっています。これにより、転送可能なクリーンなインターフェースが保証されます。これにより、移行パスは次のようになります。
- 新しいタイプ/テーブルを作成し、現在のテーブルに新しい列のみを追加し、古いバージョンのクリーンアップを実行します。
- 新しいデータ構造と古いデータ構造を処理できるストアドプロシージャを展開します。すべて読んで、新しく書いてください。
- 新しい展開に不可欠なデータの移行とマッサージを実行します。
- 新しくデプロイしたアプリケーションにトラフィックを入れ替えます。
- 追加のデータ移行とマッサージを実行して、新しいデータ構造に移植します。
- 新しいデプロイメントを待つか、新しいデータ構造のみを処理できるストアドプロシージャをデプロイしてください。
- 待機していない場合は、古いデータ、ストアドプロシージャ、テーブルなどのクリーンアップを実行します。
これが複雑すぎるように聞こえる場合、またはライブデータの操作を行うことが危険すぎる場合は、信頼できるものの定義を別のデータソースに移動することが必要な場合があります。これにより、SQLデータストアの内容は問題になりません（イベントログを格納している場合を除き、その部分を除きます）。デプロイメントは次のようになります。
- 新しいスキーマ、ストアドプロシージャ、タイプなどを新しい名前空間の下に、またはプレフィックスを付けて作成します。
- 最初のレコードからイベントログをスキャンし、関連するスキーマを更新します。
- ほぼ追いついたら、トラフィックをゆっくりと新しい展開に切り替えます。
- 古い展開のユーザーは引き続き新しい展開のユーザーとやり取りできます。どちらもイベントログを読み取り、更新を受信しています。
- 全員が新しいデプロイメントに満足し、ロールバックが不要な場合は、古いシステムを停止します。
- 古いスキーマ、プロシージャなどを削除します...
アプリケーションは、最初にイベントログでデータをダブル入力する必要があります。次に、イベントログを読み取り、関連するテーブルデータを更新する必要があります。プラス面では、これにより、追加の作業を犠牲にして、いくつかのバージョンの製品が一時的に一緒に動作することが可能になります。