レベル: 初級 岩品 友徳, ワークプレース, ISE
2009年 6月 15日 WebSphere Virtual Enterprise (以下WVE) v6.1 では、同一コンテキストのアプリケーションを複数エディション導入することが可能です。複数エディションの保持は、WebSphere Application Server Network Deployment (以下、WAS ND) v6.1およびv7.0ではサポートされていません。WVEを採用しアプリケーションを複数エディション導入することで、システム・デザイン上どのようなメリットがあるのか、どのような新たな運用が可能になるのか、またそれがWVEではどのような仕組みによって実現されているのかをご説明いたします。
はじめに
アプリケーションを更新する際に、古いバージョンも残しておきたいと考えたことはありませんか?WebSphere Application Server Network Deployment (以下WAS ND)では同一のコンテキスト・ルートを持つアプリケーションを複数導入することはサポートされていません。正確に言うと、アプリケーション名を変更さえすれば、同一コンテキスト・ルートのアプリケーションを複数導入すること自体はできますが、WAS NDではそれらを区別して割振る方法が提供されていません。WAS NDのWebサーバー・プラグインはコンテキスト･ルートで割振り先を区別しているため、同じコンテキスト・ルートへの要求を複数のエディションに区別して割振りすることができず、常に片方のアプリケーションに片寄せされてしまいます。
一方、WebSphere Virtual Enterprise (以下WVE) v6.1では、アプリケーション・バージョニング機能により、同一コンテキストのアプリケーションを複数エディション導入することが可能です。この記事では、WVEを採用しアプリケーションを複数エディション導入することで、システム・デザイン上どのようなメリットがあるのか、どのような運用が可能になるのか、またそれがWVEではどのような仕組みによって実現されているのかを、解説していきます。
WASシステム運用上の課題点
WAS NDを利用されているお客様から、運用に関して相談されることが多いのはアプリケーション更新時のメンテナンス時間の課題です。
ユーザーのシステム利用時間が限定されていて、メンテナンスのためにシステム停止時間を十分取れる場合はあまり問題とはなりません。しかし、できる限り24時間365日の運用を求められるシステムも多くなってきています。このような中、本番サービス・イン後、発見されてしまったバグに対する修正のリリースは、システム管理者の頭痛の種でした。修正のリリースを実施するためには、どうしてもメンテナンス時間を確保する必要があるからです。
WAS ND環境において、アプリケーションの修正をリリースするためには、通常以下のようなステップを踏みます。
- 前段に配置された負荷分散装置において、修正対象アプリケーションへの割振りを停止する(この間、Sorryサーバーで代替応答メッセージを返す)
- アプリケーションの更新を実施する
- 更新済みアプリケーションで最終チェックを実施する
- 正常稼動が確認された段階で、前段の負荷分散装置から、更新済みアプリケーションへの割振りを再開する
このような修正アプリケーションの更新オペレーションは、アプリケーションのモジュールが大きい場合、数分程度時間がかかってしまう場合もあります(EJBモジュールのデプロイが含まれる場合は、さらに時間がかかることがあります)。また最終チェックでの不具合を考えた場合、修正前のバージョンに戻すフォールバックの時間も考える必要があるため、システムの停止時間はどんなに短くても30分～数時間が必要となってしまっています。
WVEのアプリケーション・バージョニング機能
WVEのアプリケーション・バージョニング機能は、このようなアプリケーション更新に関わる問題の解決策の1つとして利用できます。まず、WVEのアプリケーション・バージョニング機能自体についてご説明いたします。
WVEでは、WAS NDのアプリケーション管理の仕組みを拡張し、エディションという概念が新たに導入されています。WAS NDでは1アプリケーション1エディションしか導入できませんでしたが、WVEでは1アプリケーションに対して 複数エディションを導入することができます。ただし、各デプロイ・ターゲット(サーバーやクラスター)で、一時点でアクティブであることができるエディションは1つのみです。
図1は、WVEの管理コンソールで提供されるエディション・コントロール・センターの画面です。2つのエディションのSimpleAppというアプリケーションが導入されています。特にエディション名を指定せずに導入されたアプリケーションは「Base Edition」として管理されます。
図 1 エディション・コントロール・センター
複数エディションの並列稼動
複数エディションを同一のデプロイ・ターゲットにマップすることもできますが、それぞれ別のデプロイ・ターゲットにマップすることもできます。デプロイ・ターゲットが異なれば、1つのセル内において複数エディションをアクティブとすることも可能です(図2参照)。
図 2エディション・コントロール・センター(複数エディション・アクティブ)
このように複数にエディションが並行稼動している場合、Webサーバー・プラグインでは、同一コンテキストのアプリケーションを区別して割振ることができませんでしたが、WVEではアプリケーション・サーバーの前段に配置するインテリジェントなプロキシー・コンポーネント、On Demand Router (以下ODR)がルーティング・ポリシーに基づいて割振りを制御します。
ルーティング・ポリシーは、クライアントのIPアドレス、認証時のUSERIDやGROUPID、またはCookieの値などによって、割振り先を制御するためのポリシー設定です。このルーティング・ポリシーを設定することにより、同一コンテキスト・ルートのアプリケーションであっても、特別顧客と一般顧客を別のアプリケーションに割振りを行うといったことや、システム管理者からのIPアドレスだけ検証用アプリケーションに割振りを行うといったことが可能です。
アプリケーション・ロールアウト機能
ここで、改めてアプリケーション更新の問題を考えてみます。
WVEにおいては複数エディションの仕組みとルーティング・ポリシーを利用することによって、アプリケーションのロールアウト機能をサポートしています。ODRがリクエストを制御しながらロールアウトしますので、サービス提供時間中でも、アプリケーションの更新を実施することが可能です。
アプリケーションの更新を実施する場合には、まず修正対象エディションがデプロイされている同一のデプロイ・ターゲットに、事前に修正版アプリケーションをデプロイしておきます。事前にアプリケーションをデプロイし、各ノードに配布しておくことができますので、アプリケーションの更新にかかる時間を短縮することができます。もちろん、新規エディションの導入は提供中のサービスに影響を与えません。
ODRがリクエストを制御しながらロールアウトを行う方法には2つのポリシーがサポートされています。
グループ・ロールアウト
このポリシーでは、クラスターを任意の台数のグループに分けて、グループ毎にロールアウトを実施していきます。このポリシーの場合、途中で新旧エディションが並行稼動する時間帯があります。この場合、あるユーザーは旧エディションの画面を見ているにも関わらず、別のユーザーは新エディションの画面を見ているということが起こります。このような新旧混在を起こしたくない場合には、次のアトミック・ロールアウトを選択します。
アトミック・ロールアウト
このポリシーでは、クラスターを半分ずつに分けてロールアウトを実施します。このポリシーの場合、旧エディションのアプリケーションが停止してから新エディションが稼動し始めるまでの間、ODRがリクエストのキューイングを行いますので、新旧エディションが混在する時間はありません。
いずれのロールアウト・ポリシーを選択した場合も、新エディションを反映させる方法として、ソフト・リセット(アプリケーションの再起動)とハード・リセット(サーバー全体の再起動)の2つから選ぶことが可能です。ネイティブのモジュールを使用しておりJVM毎再起動する必要がある、などの理由がない限り、より短い再起動時間で済むソフト･リセットがお奨めです。
ODRが実施するロールアウト中のリクエスト制御の挙動や、細かいパラメータについては、機能詳細をご参照ください。
妥当性検査機能
これまでお話した複数エディションの並行稼動とアプリケーション・ロールアウトの双方を組み合わせた機能が妥当性検査です。
アプリケーションをリリースする前に、修正モジュールの最終確認を本番環境で実施したいというお客様に対して有効な機能といえます。ミッション・クリティカルなシステムを運用されているお客様には、サービス提供中の本番環境での検証など考えられないという方も多いとは思いますが、中小規模のシステムにおいてはテスト環境の確保も難しいため、サービスを提供している裏で稼動確認をされたいというお客様もいらっしゃいます。妥当性検査機能は、そのようなお客様のために、アプリケーション稼動確認用のクラスターまたは単体サーバーを自動的に作成してくれる機能です。
まずWVEは稼動確認対象となるアプリケーションが導入されている動的クラスターまたは単体アプリケーション・サーバーのコピーを同じマシン・リソース上に作成します。そして作成された妥当性検査用ターゲット(動的クラスターまたは単体サーバー)に、妥当性検査実施エディションのアプリケーションがデプロイされます。そこで、ユーザーはルーティング・ポリシーを作成し、システム管理ユーザーのみ妥当性検査実施エディションへとリクエストを割り振るよう定義を実施します。なお、妥当性検査機能は、WVEが提供する動的クラスターのテンプレート機能を使用しているため、本番環境がWAS NDの静的クラスターで構成されている場合はサポートされません。
図 3 妥当性検査機能概要
挙動詳細
アプリケーション・バージョニング機能を使用した場合も、アプリケーション管理は従来のWAS NDの管理とほぼ同じであり、システム管理者がエディションを意識することは通常それほどありません。エディションを意識するのは、アプリケーション・デプロイ時やルーティング・ポリシーの設定時、およびアプリケーション・ロールアウトなどバージョニング機能を使用したときのみです。
しかし、システム管理者として、実際にWAS/WVEの中でどのようにエディションが管理され、バージョニングの機能が動いているかを知っておくことは、設計・デザインの際などに非常に役立ちます。
ここからは、WVEのバージョニング機能が実際にどのように動いているのか具体的に見ていきます。
複数エディションはどのように管理されているか
インストールする前のアプリケーションは特にエディション情報は持っていません。特にアプリケーション開発者はエディションについて意識せず、従来どおりパッケージングを行えば問題ありません。エディション情報は、アプリケーションのインストール時にインストール・オプションの一つとして指定して導入します。
図 4 アプリケーション・インストール時の画面(抜粋)
エディションを指定してアプリケーションを導入した場合も基本的にモジュール管理の仕組みはWAS NDの場合と変わらず、<Profile_Root>/config/cells/ <CellName>/applications/ ディレクトリの配下に、デプロイしたオリジナルのEAR名でフォルダが作成されます。その配下で <EAR名>-edition<EDITION名>.ear とアプリケーション名が変更されて導入されます。
図 5 アプリケーションの構成ファイル
アプリケーション名は更新されて管理されますが、特にEARやWAR内のデプロイメント記述子などにはエディションに関する情報は含まれません。複数のエディションのうち、いずれのアプリケーションが現在アクティブ・ステータスであるか否かは、同じディレクトリにある ibm-edition-metadata.props というファイルの中に記述され、管理されています。
ルーティング・ポリシーの作成
WVEにおいては、リクエストのフロー制御に関わる情報を作業クラス(WorkClass)として定義します。作業クラスには、アプリケーションの優先制御を行うためのサービス・ポリシーと、割振り先の制御を行うためのルーティング・ポリシーがあります。作業クラスの情報は、アプリケーション毎に管理されるため、先ほどと同じディレクトリの、workclassesディレクトリ配下にある workclass.xml というXMLファイルで管理されています。ここでは、リクエストの情報に基づいて割振り先を制御するためのルーティング・ポリシーについてみていきます。
まず、アプリケーションをインストールした際に デフォルトの作業クラス(Default_HTTP_WC)が作成されます。この作業クラスには、当該アプリケーションのコンテキスト・ルート以下の全ての要求をデフォルトのエディションに割振るというルーティング・ポリシーが設定されています。
特定の条件によって割振りの挙動を変更したい場合には、この作業クラスにルーティング・ルールとして条件を追加し、その条件が満たされた場合のアクションを指定します。たとえば2つの検証用端末(IP192.168.10.10および192.168.10.11)からのリクエストのみ、エディション2.0に割振りたい場合は、以下のようなルーティング・ルールを作成します。
ルール: clientipv4 IN (‘192.168.10.10','192.168.10.11')
アクション: ルーティングの許可 SimpleApp-edition2.0
図 6 ルーティング・ルールの設定画面
ルールの条件としては、IPアドレスやUSERIDやGROUPID、要求パラメータや要求ヘッダーの値、クッキーの値など、多様な要素を使用することができます。割振りのアクションとしては、異なるエディションに割振りを行うことのほか、Sorryサーバーなどへのリダイレクトや応答コードを指定しての要求の拒否などのアクションを取ることができます。
このようなルーティング・ルールは複数設定することができ、ルールの適用順序ももちろん設定することができます。
アプリケーション・ロールアウトの詳細挙動
アプリケーション・ロールアウトの挙動の詳細についてみていきましょう。
グループ・ロールアウト
クラスター・メンバーを数台ずつのグループに分割してロールアウトを実施する グループ・ロールアウト を例に挙動をご説明します。
まずグループ・ロールアウトの大きな流れを見ていきましょう。
① ロールアウトが開始されると、ターゲットが動的クラスターであった場合は、動的クラスター・モードが手動に設定され、関連する全ノードに対して同期処理が走ります。これは、サーバーの起動停止をアプリケーション・エディション・マネジャーが制御できるようにするためです。
② 次にibm-edition-metadata.propsに保持されているアクティブなエディションに関する情報が更新され、関連するノードに対して同期処理が走ります。これによりアプリケーションの再起動により起動してくるバージョンを切替えています。
③ 実際に最初のグループにおいて、エディションの切替え処理(停止および起動)が実施されます。エディションの切替え処理自体にも5つのPhaseがありますが、これは後で詳しくご説明します。
④ 最初のグループのエディション切替えが終了すると、デフォルトの割振り先が新エディションとなるようようルーティング・ポリシーが更新され、関連するノードに対して同期処理が行われます。
この時点で、新規リクエストに関しては、すべて最初のグループの新エディションに割振られます。一方でアフィニティが効いたリクエストに関しては、ルーティング・ポリシーよりもアフィニティが優先されますので、そのままアフィニティの効いているサーバーに割振られ続けます。
⑤ 2番目のグループにおいて、エディションの切替え処理が実施されます。この際も後述する5つのPhaseを経て、エディションの切替えが行われます。
ルーティング・ルールの更新は④で完了していますので、特にこのタイミングでは実施されません。同様に全てのグループのエディションの切替えを行っていきます。
⑥ 全てのグループでエディションの切替えが終了すると、手動モードに設定されていた動的クラスター・モードを元のモードに戻して、ロールアウト処理は完了です。
次に各グループ内で個々のアプリケーションのエディションが切り替わるまでの挙動をご説明します。以下の5つのフェーズが存在します。
Phase1. 通常処理
現在稼動中のエディションでサービスを提供している通常の状態です。
Phase2. ドレーン間隔(Drain Age Interval)
ODRは、ロールアウトを開始したグループへの新規リクエストの割振りを停止し、アフィニティの効いたリクエストのみ割振りを継続します。この時間は、アフィニティが効いたクライアントからの一連のリクエストの終了を待機するために存在します。このドレーン間隔の長さは、ロールアウト開始時に秒単位で指定することが可能です。
Phase3. WVE静止時間
ODRはアフィニティの効いたリクエストを含め、全てのリクエストの割振りを停止します。WVEは最大60秒、既に仕掛かり中のリクエストの処理終了を待機します。仕掛かり中リクエストが存在しない場合、または全ての仕掛かり中リクエストが終了した場合には、即座に次のフェーズに移ります。
Phase4. アプリケーション停止およびWAS停止待機時間
このフェーズでは、実際にアプリケーションに停止命令が出されます。この処理は通常のWAS の挙動となりますので、アプリケーション停止命令よりデフォルト60秒間は仕掛かり中リクエストの終了を待機します。Phase3を経過してもまだ処理を行っている仕掛中のリクエストは、さらに処理終了が待機されます。もし、このタイムアウトを経過しても終了しないリクエストがいた場合には、その要求に対しては見切りが付けられ、アプリケーションは停止します。
なお、この待機時間の長さは、Webコンテナーのカスタム・プロパティcom.ibm.ws.webcontainer.ServletDestroyWaitTime で変更可能です
Phase5. 新エディションの起動
新エディションのアプリケーションが起動し処理を開始します。
これら、グループ・ロールアウトの大きな流れと、各グループのサーバーにおけるエディション切替えの各フェーズを踏まえた上で、図7を確認してください。
図 7 グループ・ロールアウトの状態遷移
図7はクラスターを2つのグループに分割した場合の、グループ・ロールアウトの状態遷移を図示しています。
新規リクエストおよびグループ1・2のサーバーにアフィニティの効いたリクエストのそれぞれが、どのフェーズで、どこで稼動するどのエディションのアプリケーションに割振られるかをご確認ください。
アトミック・ロールアウト
次に、クラスター・メンバーを2つのグループに分割して実施するアトミック・ロールアウトの挙動についてご説明します。
グループ・ロールアウトとの最大の差異は、新旧エディションの共存するタイミングがあるか否かです。この差異が出てくるのは、グループ2のエディション切替え(④)とルーティング・ポリシーの更新のタイミング(⑤)です。
① ロールアウトが開始されると、ターゲットが動的クラスターであった場合は、動的クラスター・モードが手動に設定され、関連するノードに対して同期処理が走ります。
② 次に、ibm-edition-metadata.propsに保持されているアクティブなエディションに関する情報が更新され、関連するノードに対して同期処理が走ります。
③ 最初のグループにおいて、エディションの切替え処理(停止および起動)が実施されます。
④ ここで、ルーティング・ポリシーの更新よりも先に、まず2番目のグループにおいてエディションの切替え処理が開始されます。
⑤ 2番目のグループにおいて、新規リクエストの割振りを停止した段階で、ルーティング・ポリシーの更新が実施されます。
④で割振りが停止されてから、このルーティング・ポリシーの更新が完了するまで、まったく割振り先が存在しない状況となりますので、この間ODRはリクエストをキューイングします。ルーティング・ポリシーが更新されると、すべてのリクエストはグループ1に片寄せされます。
⑥ 2番目のグループでエディションの切替え処理が終了すると、手動モードに設定されていた動的クラスター・モードを元のモードに戻して、ロールアウト処理は完了となります。
アトミック・ロールアウトの場合、各グループのサーバーにおいてエディションの切替えのフェーズについては基本的には同じです。但し、先の④～⑤でODRがキューイングを実施しなければならない時間を短縮してODRのキュー溢れを防止するため、アトミック・ロールアウトの2番目のグループにおいてはドレーン間隔が存在しませんのでご注意ください。
アトミック・ロールアウトの状態遷移を図8に示しました。まず、グループ2におけるリクエスト静止のタイミングとルーティング・ポリシー更新のタイミングをご確認ください。また各フェーズで、新規リクエストおよびグループ1・2のサーバーにアフィニティの効いたリクエストのそれぞれが、どこで稼動するどのエディションのアプリケーションに割振られるかをご確認ください。
図 8 アトミック・ロールアウト
妥当性検査の仕組み
妥当性検査は、本番環境と同一環境において最終確認をするための機能を提供します。妥当性検査は以下の仕組みで行われます。
- エディション・コントロール・センターからアプリケーションを指定して妥当性検査を開始します。
- デプロイメント・マネジャーは、当該アプリケーションがデプロイされている動的クラスターのクラスター・テンプレートを使用して、妥当性検査用動的クラスターを作成します。この際、妥当性検査用クラスターは <元動的クラスター名>-Validation という名前で作成されます。
もし妥当性検査アプリケーションが単体サーバーにデプロイされていた場合は、そのサーバーの構成ファイルを使用して、妥当性検査用単体サーバーが作成されます。この際、妥当性検査用サーバーは <元サーバー名>-Validation という名前で作成されます。
図 9 作成された妥当性検査用クラスター
このようにして新規作成された妥当性検査用ターゲット(動的クラスターまたは単体サーバー)に、妥当性検査対象のエディションがデプロイされ、アプリケーションのステータスは「妥当性検査」となります。
図 10 エディション・コントロール・センター(妥当性検査)
この時点では妥当性検査用ターゲットおよびアプリケーションは、まだ起動していません。また妥当性検査用ターゲットを起動した場合も、ルーティング・ポリシーを定義するまでは、妥当性検査用ターゲットには割振りは行われません。
- 次にテスターからのリクエストのみ、妥当性検査エディションへと割振りを行うようにルーティング・ポリシーを作成します。
- 妥当性検査用ターゲットを起動します。この時点で新旧エディションが並存しますが、3で作成したルーティング・ポリシーに従い、システム管理者からのリクエストは妥当性検査中のアプリケーションに、一般ユーザーのリクエストは旧エディションに割振られます。
なお、あくまで最終評価用であるため、妥当性検査用動的クラスターは、マシン・リソース浪費を回避するため、デフォルトでは最大2メンバーまでしか起動しないよう定義されています。
- ここからは、アプリケーションの稼動確認結果によって、処理が異なります。
① 稼動確認結果が正常であった場合
エディション・コントロール・センターから、「ロールアウト」を指定します。アプリケーション・ロールアウトでご説明した挙動と同様のシナリオにより、ODRがリクエストを制御しながら、妥当性検査済みのアプリケーションを本番用ターゲットへと反映します。
② 稼動確認結果が異常であった場合
エディション・コントロール・センターから、「Cancel Validation」を指定します。この場合、妥当性検査を実施していたエディションのアプリケーションは本番用ターゲットへとマッピングされなおし、再び非アクティブ・ステータスとなります。
- 妥当性検査用ターゲットを手動にて停止します。作成されたサーバーおよび動的クラスターは自動では削除されませんが、不要であれば削除して頂くことも可能です。妥当性検査用ターゲットが作成されていれば、次の妥当性検査を実施した際に、作成済みのターゲットが再利用されます。
 |
考慮点
よくご質問いただく点に、WAS NDのアプリケーション・ロールアウト機能との差異があります。差異を表1にまとめました。
| | WVE | WAS ND |
|---|
| HTTP要求割振り制御 | オン･デマンド・ルーター | Webサーバー・プラグイン |
|---|
| 更新単位 | EAR | EAR、モジュール、ファイル |
|---|
| 更新反映方法 | アプリケーション再起動または プロセス再起動 | プロセス再起動 |
|---|
| リリース時間 | 短い | 比較的長くなり得る |
|---|
| 手戻り時間 | 短い | 比較的長くなり得る |
|---|
| 新旧バージョンの混在 | アトミック・ロールアウトでは発生しない。グループ・ロールアウトでは発生 | 発生する |
|---|
まず更新にかかる時間についてです。WAS NDのアプリケーション・ロールアウトは、デプロイメント・マネジャーとの同期によるアプリケーション配布とサーバー・プロセスの再起動により更新反映を行います。したがって、WVEのアプリケーション・ロールアウトを実施した場合よりもロールアウト完了までの時間が長くかかります。一方、WVEの場合は既に各ノードに既にアプリケーションを配布した状態からロールアウトを開始し、変更反映もアプリケーション再起動で行うこともできますので、ロールアウト完了までの時間は短縮できます。また旧エディションもノード上に残っていますので、たとえ修正に不具合が発見された場合でも、速やかに手戻りを実施することが可能です。
次に更新単位についてです。WVEのアプリケーション・ロールアウトはEAR単位の更新が前提です。一方、WAS NDのアプリケーション・ロールアウトは、Fine Grained Update 機能を利用して EARレベルだけではなくWARやJARなどのモジュール単位およびCLASS単位でもリリースを行うことができます。これはWVEのアプリケーション・ロールアウト機能を使用した場合には得られないメリットです。しかしWVEが導入された環境においても、WAS NDの Fine Grained Update を使用することはもちろん可能ですので、状況に応じて使いわけて頂くことができます。但し、エディションはWebモジュール単位や特定クラス単位で指定することはできないため、Fine Grained Updateと併用する場合は、アプリケーションのバージョン管理には注意を払う必要があります。
WVEのアプリケーション・バージョニングはWAS NDのアプリケーション管理機能を否定するものではなく、拡張するものです。それぞれの機能にメリットがありますので、お客様の要件に応じて、使い分けていくことが必要です。
その他、WVEのアプリケーション・バージョニング機能についての考慮点をあげます。
WVEのアプリケーション・ロールアウトはWebモジュールへのリクエストを制御しながらリリースを行う形式であるため、Webモジュールの更新には非常に有益ですが、共有ライブラリ等への修正リリースには対応できません。このような場合には、ODRにおいて保守モードを使い手動にてリクエストを制御してリリース作業を実施する必要があります。
また、エディションの切替え前後で、割振られるサーバーが切り替わってもクライアントに影響を与えないためには、セッション共有が必要になります。但しセッション内に保管されるオブジェクトの型が変更されるような場合は、WVEおよびWAS NDいずれの場合も、ロールアウト機能を用いてサービス無停止でアプリケーション・リリースを行うことは困難です。このような場合には、メンテナンス時間を設けてリリースを実施する必要があります。
WVEのアプリケーション・ロールアウトは、ODRが割振りを制御しながらリリースを行うため、サービス提供時間であっても新エディションのリリースを行うことは可能です。しかし高負荷状況での切替えはお奨めしません。実際上の考慮点として、24時間サービスを提供しているシステムであっても、負荷が少ない時間帯などでのリリースをお奨めします。
まとめ
WVEで提供されたアプリケーション・バージョニング機能は、1つのセル内で同一アプリケーションの複数エディションの稼動を可能にしました。
これにより、同じコンテキスト・ルートであってもユーザーにより違うエディションのアプリケーションを提供することや、本番環境のリソースを使用して修正エディションの最終検証を実施することなど、システム運用に柔軟性をもたらしました。またロールアウト機能を用いることで、ユーザーへの影響を最小限に抑えて、サービス時間中にアプリケーションをリリースすることも可能になっています。さらに、工夫次第では、お客様の課題を解決することができるシステム・トポロジーが可能となるかもしれません。ぜひ一度、WVEのアプリケーション・バージョニング機能をご担当されているシステムで活かすことができないか考えてみてください。また、WVEを適用することで解決できそうなお客様の課題などがあれば、お手伝いをさせて頂きますので、ぜひご相談ください。
著者について | | | 岩品 友徳, ワークプレース, ISE |
記事の評価
| 
