アプリケーション・エディション・マネージャーにより、 ご使用のアプリケーションのさまざまなバージョンおよびエディションを管理できます。 このトピックでは、アプリケーション・エディション・マネージャーのバージョンとエディションの違い、 ご使用のアプリケーションのアップグレードの方法、およびエディションの妥当性検査と互換性について説明します。
バージョン とはインターフェース、機能、実装、またはアプリケーション全体などの連続した世代のことです。 バージョンは開発とビルドの概念ともいえます。 エディション とは連続したデプロイメントの世代であり、例えば、 バージョンの成果物の特定のセットのデプロイメントです。 エディションは、デプロイメントと操作に関する概念ともいえます。 これらの用語により、開発とビルドの環境で起こっていることと、デプロイメントと操作の環境で起こっていることを区別できます。
多くのビジネス・アプリケーションには、一定の可用性が必要です。 連続可用性に対応した WebSphere Application Server 構成の選択項目の関する資料は、 WebSphere Application Server Network Deployment インフォメーション・センターや、IBM Redbooks のようなその他のソースから得られます。 アプリケーションの可用性に関する標準では、 アプリケーションがアプリケーション・サーバー・クラスターにデプロイされるものと表明されています。 クラスターの冗長性は、連続可用性を提供する上で不可欠です。
中断のないアプリケーションのアップグレード とは、アプリケーションの連続可用性を維持しながらアップグレードを実行する機能を意味します。 アプリケーションのアップグレード中にも、アプリケーションのユーザーにサービスが提供されます。
アプリケーション・エディション とは、特定のアプリケーションの固有のデプロイメントのことです。 WebSphere Application Server の管理環境において、アプリケーション・エディションとは、アプリケーション名とエディション名の組み合わせで一意的に識別されるアプリケーションです。 同じアプリケーションの複数のエディションには、同一のアプリケーション名が付けられますが、エディション名は異なります。 エディション名には、1.0 や 2.0 などの数値を使用することも、 first edition や blue edition などの記述的なものを使用することもできます。
ベース・エディション とは、関連するエディション情報のない、デプロイ済みアプリケーションのことです。 例えば、WebSphere Extended Deployment セルにエディション・マネージャー・サポートを追加する前にインストールされたアプリケーションは、ベース・エディションとしてエディション・マネージャーに表示されます。
エディションの活動化 では、アプリケーションのエディションが保持できる 2 つの状態を区別します。 あるエディションは、最初のインストール時には非アクティブ状態になっています。 非アクティブ ・エディションは開始することができません。エディションをアクティブ 状態にするには、明示的なアクションが必要です。 アクティブ状態のエディションは、開始可能です。 非アクティブからアクティブへの移行を、活動化 と呼びます。
並行した活動化 とは、同一のアプリケーションの複数のエディションが並行してアクティブであり、
開始された場合のことです。
並行してアクティブなエディションでは、あるユーザーが 1
つ目のエディションにアクセスし、別のユーザーが他のエディションにアクセスすることが可能になります。
例えば、あるアプリケーションの新規エディションの導入時に、
選択したユーザーのグループのみにそれをテストさせるが、
すべてのユーザーにはアクセスを提供しない場合などです。
並行した活動化では、エディションにアクセスするユーザーを区別するように、ルーティング・ポリシー
を設定する必要があります。
ルーティング・ポリシーにより、あいまいさを排し、制御を受け取るエディションを判別します。
以下の図は、並行した活動化の例です:
WebSphere Extended Deployment には、アプリケーション用のルーティング・ポリシーが用意されています。 ルーティング・ポリシーは、アプリケーションの構成メタデータの一部として保管されています。 ルーティング・ポリシーにより、一連の基準に基づいて特定のアプリケーション要求をあるエディションや別のエディションに送信するよう、オンデマンド・ルーター (ODR) に指示するルールを表現できます。 さまざまな基準を使用して、特定のアプリケーション・エディションに送信する要求を指定できます。 これにより、特定のユーザーがあるエディションに要求を送信し、他のユーザーが別のエディションに要求を送信することが可能になります。
エディション・ロールアウト とは、サーバー・クラスター全体にアプリケーション・エディションをデプロイし、活動化することを意味します。 中断のないアプリケーションのアップグレードを提供するため、アプリケーションのロールアウトには、特定のサーバー内のアプリケーションに対する要求の静止、そのサーバーによる新規要求の受信の防止、現行の活動中エディションの停止、新規エディションの開始、およびそのエディションへの要求の流れの再開が含まれます。 サーバー・クラスター全体でのエディション・ロールアウトでは、そのクラスター内の一連のサーバー全体に対して上記のアクティビティーが実行されます。
グループ・ロールアウト では、あるグループ内のターゲット・クラスターのメンバーのエディションを置き換えます。 グループ・ロールアウト時には、置き換えが完了するまで、要求は新旧いずれかのエディションにより処理されます。 グループ・ロールアウトにより、サーバーの新規エディションへのアップグレードが同時に実行される結果になります。 そのグループ内の各サーバーは、静止状態となり、ドレーンされ、停止されて、さらにリセットされます。 管理コンソールでは、同時に 1 つのグループのみがロールアウトできます。 代わりにスクリプトを使用して、複数のグループをロールアウトすることもできます。
グループ・ロールアウト時には、 アプリケーションの新旧両方のエディションが使用可能になり、同時にユーザー要求を処理する期間があります。 エディション・ロールアウトの実行時には、クラスター内の一部のサーバーは旧エディションから新規エディションへ移行され、一部のサーバーは移行中であり、その他のサーバーは移行を開始していません。 ルーティング・ルールが適用されていない限り、アプリケーション要求は、要求されたアプリケーションの任意のエディションのインスタンスが実行されている、アクティブな任意のサーバーに送信されます。 例えば、エディション 1.0 から 1.1 にロールアウトする場合、 ロールアウトが完了するまでの間、アプリケーション要求はエディション 1.0 または 1.1 のいずれかにより処理される可能性があります。
以下の図は、グループ・ロールアウトの例です。
アトミック のロールアウト・オプションは、同時にクラスター上の半数のエディションを置き換え、アプリケーションの一貫性のあるエディションですべてのアプリケーション要求を処理するようにします。 どの時点においても、すべてのユーザー要求が新旧エディションのいずれか一方で処理され、ユーザー要求が両方のエディションで処理されることはありません。
アトミック・ロールアウトでは、すべてのアプリケーション要求が確実に一貫性のあるエディションで処理されます。 例えば、1.0 または 1.1 のいずれかであり、両方ではありません。 現行で使用可能なエディションが、クラスターを構成するサーバーの半数でオフラインになります。 それらのサーバーでは新規エディションが活動化され、開始されますが、次のステップが完了するまで、サーバーはオフラインのまま保持されます。 次のステップでは、残りのサーバーで現在活動中のエディションがオフラインになります。 この時点で、サーバーには、アプリケーション要求の処理に使用可能などちらのエディションのインスタンスもありません。 この期間では、ODR が一時的に、そのアプリケーションに対して受信したすべての要求をキューに入れます。 アプリケーションが完全にオフラインになった後、クラスターの最初の半数がオンラインに戻されます。 クラスターの残りの半数は、以前のエディションから次のエディションに移行し、オンラインに戻されます。
以下の図は、アトミック・ロールアウトの例です。
エディションの妥当性検査 とは、並行した活動化の特殊なケースであり、 エディションの割り当てられたデプロイメント・ターゲット (例えば、動的クラスター) が複製され、そのエディションが複製されたデプロイメント・ターゲット上で開始できるようにされます。 複製されたデプロイメント・ターゲットは、妥当性検査ターゲット と呼ばれます。 ルーティング・ルールを使用して、妥当性検査が実行されているエディションにどのアプリケーション要求を送信するか指定する必要があります。 エディションが妥当性検査中の場合は、妥当性検査モード になっています。
妥当性検査モードにより、現在使用可能なエディションをオフラインにすることなく、アプリケーションの新規エディションがその実稼働環境で確実に機能します。 通常、テストの負荷が妥当性検査モードのエディションに送信され、接続性やデータベース・アクセスなどが予想通り動作するなど、アプリケーション環境の性質およびセットアップを確認します。 エディションの妥当性検査モードがロールアウトされると、最初にそのエディションがインストールされたデプロイメント・ターゲットでロールアウトが実行されます。 これにより、そのエディションは妥当性検査モードを終了します。 妥当性検査モードが終了すると、妥当性検査ターゲットは削除されます。
以下の図は、妥当性検査の例です。
アプリケーションの変更には、ユーザーに対して透過的であるものと、そうでないものがあります。 あるアプリケーションのアップグレードによって、少なくとも前回の変更と同じアプリケーション・プログラミング・インターフェースが提供され、本質的な振る舞いに対する意味的な変更がない場合、そのアプリケーション・エディションは後方互換 のあるアップグレードです。 既存のユーザーは、使用方法を変更することなく、アップグレードされたアプリケーションを使用でき、現行と以前のエディションの違いを認識しません。
既存のユーザーがアプリケーションの使用方法を変更する必要があるアプリケーション・アップグレードは、非互換 のアップグレードです。 保守容易性やその他のファクターを改善のため、例えば、従来の機能の除去、またはインターフェースの変更が必要な場合など、デプロイメント環境へ非互換の変更を導入する場合があります。 非互換変更では、既存ユーザーに対する影響を管理するための注意深い計画が必要です。