JP2017004120A - システム、サーバーシステム、方法、およびプログラム - Google Patents

Abstract

【課題】サービスを無停止で提供するための仕組みを持つシステムにおいて、Ｉ／Ｆの互換性の他に画面のＨＴＭＬに関しても互換性を保つことが可能となるシステム、サーバーシステム、方法及びプログラムを提供する。【解決手段】ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭに記憶された、或いはハードディスク等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳやアプリケーション等のプログラムを実行する。また、システムバス２３４に接続される各ブロックを制御する。ＲＡＭ２３２は、ＣＰＵ２３１の主メモリやワークエリア等として機能する。操作部Ｉ／Ｆ２３５は、操作部２３９からの入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。ディスクコントローラ（ＤＫＣ）２３７は各種データを記憶するハードディスク等の外部メモリ２４１におけるデータクセスを制御する。【選択図】図２

Description

本発明は、クラウドサービスを提供するシステム、サーバーシステム、方法、およびプログラムに関する。

近年インターネット上で提供されるクラウドサービスの普及が進んでいる。クラウドサービスは世界各国から常に利用されるため、従来のサービスのように利用者の少ない夜間にシステムを停止し、サービスのメンテナンスを行うといったことが難しい。そのため、サービスの停止をすることなくメンテナンス作業をするよう要求が高まっている。従来、特許文献１および２に開示されているように無停止でのバージョンアップをセッション管理で行いセッションによる振り分け処理を行うことで実現している。

また、Ｗｅｂアプリケーションの技術も進み、従来型のサーバーサイドで画面の生成の処理を行いクライアントに処理結果を返却する構成から、ＲＥＳＴｆｕｌ ＭＶＣやクライアントサイドＭＶＣといった技術に変化してきている。これらのサーバーはＲＥＳＴ Ｉ／Ｆ経由で処理を実行する構成であり、クライアントにデータのみを返し画面生成はクライアント側で実行するといった構成である。

特開２０１３−１８２４１３ 特開２０１３−１８２３９７

無停止でのバージョンアップを実現するための新たな手法として、Ｂｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔという方法が知られている。これは現在稼働しているサービスを稼働させたまま、バージョンアップしたサービスをもう一つ別のシステムで構築し、サービスの提供元を構築したシステムに切り替えるといった手法である。

このＢｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔは、二つのシステムをＤＮＳの設定を変更することで一気に切り替えることになる。ただし、クライアント側のＷｅｂブラウザやインターネット経路上でキャッシュされたＨＴＭＬおよび／またはＪａｖａＳｃｒｉｐｔ（登録商標）といったコンテンツは、サーバーが切り替わったとしても即座に最新のコンテンツへ更新されるとは限らない。その場合、バージョンアップ前の旧アプリケーションのＨＴＭＬから、バージョンアップ後の新アプリケーションのＲＥＳＴ ＡＰＩへ処理要求が行われる可能性がある。それは、ＲＥＳＴ ＡＰＩのＩ／Ｆに互換性を持たせてバージョンアップすることでＡＰＩの呼び出しが可能となるようにしているからである。

問題は、ＲＥＳＴ ＡＰＩで取得する画面のリソースデータ（表示文言など）といった画面のＨＴＭＬと密接に関係しているものはＩ／Ｆの互換性だけでは対処できない点である。例えば、旧バージョンのＨＴＭＬが新バージョンのＲＥＳＴ ＡＰＩから互換性のない新バージョンのアプリケーションのリソースを取得してしまった場合、適正な画面表示が行われない。

そこで、本願発明はサービスを無停止で提供するための仕組みを持つシステムにおいて、Ｉ／Ｆの互換性の他に画面のＨＴＭＬに関しても互換性を保つことを目的とする。

本願発明の一実施形に係るサーバーシステムは、端末に備えられたＷｅｂブラウザからの要求に応じてサービスを提供するアプリケーションサーバーシステムを含むサーバーシステムであって、第１のアプリケーションサーバーシステムに配備された前記サービスを実現するための複数のモジュールとは少なくとも一部の構成が異なる複数のモジュールを第２のアプリケーションサーバーシステムに配備する配備手段と、ストレージサービスに対し、前記Ｗｅｂブラウザにより表示される画面の表示に必要なリソースであって、前記第１のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第１のリソースおよび第２のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第２のリソースを保存させる保存手段と、前記配備手段による配備が行われた後、前記サービスの提供元を前記第１のアプリケーションサーバーシステムから前記第２のアプリケーションサーバーシステムへ切り替える切り替え手段と、を有し、前記切り替え手段による切り替えの後、前記Ｗｅｂブラウザから画面の表示に関する要求を受け付けた際に、前記要求に含まれるデータが前記第１のリソースに関連することを確認した場合、前記第２のアプリケーションサーバーシステムは前記保存手段から前記第１のリソースを取得し前記Ｗｅｂブラウザに送信することを特徴とする。

本発明によれば、サービスを無停止で提供するための仕組みを持つシステムにおいて、Ｉ／Ｆの互換性の他に画面のＨＴＭＬに関しても互換性を保つことが可能になる。

システム構成図 各装置のハードウェア構成図 各装置のソフトウェアモジュール構成図 プログラムを実行形式にビルドする処理を示すフロー ビルド処理において生成されたＨＴＭＬとＪａｖａＳｃｒｉｐｔ（登録商標）の一例 モジュールを配備する処理を示すフロー クライアント端末がアプリケーションサービスを利用するシーケンス 想定外のリクエストを受信した際のＲＥＳＴ ＡＰＩの処理を示すフロー プログラムのビルドから配備までの処理の模式図 クライアント端末がアプリケーションサービスを利用するシーケンスの模式図

以下、本発明を実施するための形態について図面を用いて説明する。

本実施の形態においては、インターネット上の各サーバーにアプリケーションが設置されていることを想定している。アプリケーションはクライアント端末と連携し、様々な機能を提供することを想定している。このような機能を提供する実体をサービスと称し、機能をクライアント端末に提供することをサービスの提供と称する。

本実施の形態に係るクラウドサービスを提供する情報処理装置は、図１に示すような構成のネットワーク上に実現される。１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本発明ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。１０２もＬＡＮ１０１と同様Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０２）であるが、ＷＡＮ１００経由でのアクセスができない内部ネットワークの場合が多い。なお、ＬＡＮ１０２もＬＡＮ１０１と同様、ＷＡＮ１００に直接接続されアクセスできるような構成でも良い。１１０、１２０はアプリケーションサーバーであり、それぞれ複数の情報処理装置から構成されるのが一般的である。アプリケーションサーバー１１０が現在クラウドサービスを提供中のシステムであり、アプリケーションサーバー１２０がバージョンアップ後のクラウドサービスを提供するシステムである。１３０はストレージサーバーであり、それぞれ複数の情報処理装置から構成されるのが一般的である。

ストレージサーバー１３０はアプリケーションサーバー１１０、１２０からアクセスされ、アプリケーションサーバーのためのリソースデータを保持する。１４０は管理サーバーであり、それぞれ複数の情報処理装置から構成されるのが一般的である。管理サーバー１４０はアプリケーションサーバー１１０、１２０を構成するプログラムの管理、アプリケーションサーバー１１０、１２０の構築やサービスを提供している提供元のサーバーシステムの切り替え処理を行う。１５０はクライアント端末であり、パーソナルコンピューター、スマートフォンといったモバイル端末など、Ｗｅｂブラウザがインストールされている情報処理装置である。

１８０はＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ（ＤＮＳ）であり、インターネット上のサーバーのホスト名を解決しアクセス先のＩＰを返却するシステムである。Ｂｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔにおけるサービス切り替えは本ＤＮＳに登録されたホスト名に対応したＩＰアドレスをアプリケーションサーバー１１０のものからアプリケーションサーバー１２０のものに切り替えることで実現する。クライアント端末１５０は、クラウドサービスを利用する際、Ｗｅｂブラウザ上で入力したホスト名に対応したサーバーのＩＰアドレスをＤＮＳ１８０で取得し、取得したＩＰアドレスを基にその時稼働中のアプリケーションサーバーにアクセスする。

なお、実施例ではサーバーに関する夫々の装置は１台で構成されているように示しているが、上述した通り、複数の装置で構成されていても良い。よって、１台または複数台の装置で構成されているサーバーをサーバーシステムと本実施例では称することとする。例えば、アプリケーションサーバーシステムと称した場合、１台または複数台の装置で構成されたアプリケーションサービスを提供するシステムということになる。

図２は本実施例にかかわる、アプリケーションサーバー１１０、１２０、ストレージサーバー１３０、管理サーバー１４０、クライアント端末１５０、ＤＮＳ１８０を構成する情報処理装置の一般的な構成である。ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳやアプリケーション等のプログラムを実行する。またＣＰＵ２３１は、システムバス２３４に接続される各ブロックを制御する。ここでＯＳとはコンピューター上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳと呼ぶ。後述する各シーケンスの処理はこのプログラムの実行により実現できる。ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。操作部Ｉ／Ｆ２３５は、操作部２３９からの入力を制御する。ＣＲＴコントローラ（ＣＲＴＣ）２３６は、ＣＲＴディスプレイ２４０の表示を制御する。ディスクコントローラ（ＤＫＣ）２３７は各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータクセスを制御する。ネットワークコントローラ（ＮＣ）２３８はＷＡＮ１００もしくはＬＡＮ１０１、１０２を介して接続されたサーバーコンピューターや他の機器との通信制御処理を実行する。

尚、後述の全ての説明においては、特に断りのない限り実行のハード上の主体はＣＰＵ２３１であり、ソフトウェア上の主体は外部メモリ２４１にインストールされたモジュールである。モジュールはＣＰＵ２３１により実行されることで機能を発揮する。

図３は本実施の形態に係る、アプリケーションサーバー１１０、１２０、ストレージサーバー１３０、管理サーバー１４０、クライアント端末１５０、ＤＮＳ１８０、それぞれのモジュール構成を示す図である。夫々のモジュールはメモリ２４１に保存さておりＣＰＵ２３１により実行されるモジュールである。

アプリケーションサーバー１１０、１２０はアプリケーションサービス３１９を持ち、アプリケーションサービス３１９はＷｅｂサーバーモジュール３１０とＡＰＩモジュール３１１により実現される。Ｗｅｂサーバーモジュール３１０は、一般的にＪｅｔｔｙやＡｐａｃｈｅ Ｔｏｍｃａｔ等を利用し、ＨＴＭＬやスクリプトであるＪａｖａＳｃｒｉｐｔ（登録商標）の配信や、ＡＰＩモジュール３１１の実行環境を提供する。アプリケーションサーバー１１０、１２０は、Ｗｅｂサーバーモジュール３１０を実行することで、ＨＴＴＰに関する処理を実現し、また、ＡＰＩモジュール３２０を実行することで、ＡＰＩの処理を実現する。なお、本願発明ではバージョンアップの為のＢｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔを想定しているため、切り替え前のアプリケーションサーバーのモジュールと切り替え後のアプリケーションサーバーのモジュールとの構成には一部の差異があることを想定している。例えば、ＨＴＭＬの表現を変えたことによるＷｅｂモジュールの構成の変更である。

ストレージサーバー１３０はストレージサービス３３０を持ち、データの管理やアプリケーションサーバー１１０、１２０へのデータ管理機能の提供を行う。ストレージサービス３３０はストレージモジュール（不図示）により実現される。管理サーバー１４０は管理サービス３４９をもち、管理サービス３４９はプログラム管理モジュール３４０とビルドモジュール３４１と配備モジュール３４２を持つ。プログラム管理モジュール３４０はアプリケーションサーバー１１０、１２０を提供するプログラムの管理を行う。ビルドモジュール３４１はプログラム管理モジュール３４０で管理されているプログラムを実行形式のモジュールに構成する。配備モジュール３４２はビルドモジュール３４１で生成した実行形式のモジュールを利用し、アプリケーションサーバー１１０、１２０の環境を構築し、アプリケーションサービスのバージョンアップ処理を実施する。

クライアント端末１５０はアプリケーションサーバー１１０、１２０にアクセスするためのＷｅｂブラウザ３５０を持つ。Ｗｅｂブラウザ３５０はアプリケーションサーバー１１０、１２０から画面表示のための各種データを受信する。ＤＮＳ１８０は、ＤＮＳサービス３８０を持ち後述するサーバーシステムの切り替えを実現する。ＤＮＳサービス３８０はＤＮＳモジュール（不図示）により実現される。

図４から図６を用いて本実施の形態にかかわる、アプリケーションサーバー１１０、１２０の構築の詳細なフローを説明する。また、処理フローを模式的に示した図９を合わせて説明する。図４は本実施の形態にかかわる、管理サーバー１４０のビルドモジュール３４１がアプリケーションサーバー１１０、１２０を構成するモジュールのプログラムを実行形式にビルドする処理のフローを示した図である。

ビルドモジュール３４１はステップＳ４０１にて、ビルド処理を一意に識別することが可能な識別情報としてビルドバージョンを生成する。例えば「２０１５０５１５．１」といった日付＋シーケンシャル値といった組み合わせの文字列を生成する。これは、アプリケーションサーバー１１０、１２０を実現するためのプログラムが配備される際にプログラムをビルドする毎にユニークな識別情報が生成されるようになっており、重複は許されない。

ビルドモジュール３４１はステップＳ４０２にてプログラム管理モジュール３４０にて管理されているアプリケーションサービス３１９の最新プログラム一式を取得する。図９で示すアプリケーションサービスプログラム９０１であり、画面表示用のＨＴＭＬ、画面表示に利用するリソースを取得する命令およびＨＴＭＬを描画するための命令が記載されたスクリプトであるＪａｖａＳｃｒｉｐｔ（登録商標）、ＡＰＩモジュール３１１のプログラム、画面表示に使う文言データや画像データといったリソースからなる。

ビルドモジュール３４１はステップＳ４０３にてビルド処理をおこなう。プログラムコードの実行形式へのコンパイルや、ＨＴＭＬやＪａｖａＳｃｒｉｐｔ（登録商標）中に含まれるＡＰＩ呼び出し処理に対して、ステップＳ４０１にて生成したビルドバージョンを埋め込む処理を実施する。図５は実際に生成したＪａｖａＳｃｒｉｐｔ（登録商標）とＨＴＭＬの一例の抜粋である。ＪａｖａＳｃｒｉｐｔ（登録商標） ５００にてＲＥＳＴ ＡＰＩを呼び出す処理のパラメータ５０１にステップＳ４０１で生成されたビルドバージョン「２０１５０５１５．１」を埋め込んでいる。また、ＨＴＭＬ ５１０にてＪａｖａＳｃｒｉｐｔ（登録商標） ５００を読み込むように、読込先のパス５１１にステップＳ４０１で生成されたビルドバージョン「２０１５０５１５．１」を埋め込んでいる。これによりＨＴＭＬ ５１０は常に同時に生成されたＪａｖａＳｃｒｉｐｔ（登録商標） ５００を利用することとなり、さらにはＪａｖａＳｃｒｉｐｔ（登録商標） ５００経由でＲＥＳＴ ＡＰＩに対してビルドバージョンを含んだリクエストを送信できるようになる。ビルドモジュール３４１は、ステップＳ４０４にて、ステップ４０３で生成した成果物をステップ４０１にて生成したビルドバージョンと関連付けて保存を行う。

図９の９０２がビルドバージョン「２０１５０５１５．１」で生成された成果物であり、９０３が「２０１５０５１７．２」で生成された成果物である。どちらもそのビルド時点での最新プログラムから構成されており、ＨＴＭＬやＪａｖａＳｃｒｉｐｔ（登録商標）にはそれぞれのビルドバージョンが埋め込まれている。例えば、図９の９０２がアプリケーションサーバー１１０を構成する成果物であり、９０３がアプリケーションサーバー１２０を構成する成果物である。このようにバージョンアップ毎に成果物を生成し管理する。以上が、管理サーバー１４０のビルドモジュール３４１がアプリケーションサーバー１１０、１２０のプログラムを実行形式にビルドする処理の説明である。

図６は本実施の形態にかかわる、管理サーバー１４０の配備モジュール３４２がアプリケーションサーバー１１０、１２０を配備する処理のフローを示した図である。配備モジュール３４２は、ステップＳ６０１にて、配備すべき成果物を決定する。具体的には配備対象のビルドバージョンを特定する。配備モジュール３４２は、ステップＳ６０２にて、配備先となる情報処理装置群を構築する。具体的にはプログラムをホスティングするための情報処理装置を構成することである。Ｂｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔを実施する場合、仮想的な情報処理装置で構成するのが一般的である。仮想的な情報処理装置は、情報処理装置ハードウェア上に仮想的な複数の情報処理装置を生成する技術であり、仮想的な情報処理装置の生成や削除をプログラムで制御可能となる。例えば、配備のたびに仮想的な情報処理装置を必要なだけ生成し、その仮想的な情報処理装置に対してプログラムを配備していくということが可能となる。さらには、不要になった情報処理装置を即座に削除することが可能となる。これにより、Ｂｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔを迅速かつ容易に実現可能となる。なお、本発明は仮想的な情報処理装置に限らず、物理的な情報処理装置で構成してもよい。その場合、情報処理装置をアプリケーションサーバー１１０用と１２０用の環境を事前に構築しておく必要があり、それらに対してモジュールの配備作業を行う。即ち、システムを構成する対象から削除されたアプリケーションサーバーが外れる。

配備モジュール３４２はステップＳ６０３にて、モジュールの配備を実施する。ステップＳ６０２にて構築された情報処理装置に対象となるモジュールを配備していく。図９で示すアプリケーションサーバー１１０、１２０がそれぞれのバージョンで構成される。アプリケーションサービス３１９には、それぞれ対応したビルドバージョンのモジュールより、ＨＴＭＬやＪａｖａＳｃｒｉｐｔ（登録商標）、さらにはＡＰＩモジュールが配備される。

配備モジュール３４２はステップＳ６０４にて、リソースの配備を実施する。リソースの配備処理では、ストレージサーバー１３０にビルドバージョンを特定できる情報を付与し、ステップ４０３で生成された成果物のうち文言や画像のリソースを保存する。例えば、一般的なファイル共有サーバーなどのように、ディレクトリ構成でデータを管理できるストレージサービスでは、図９の９０４で示す通り、ビルドバージョンでディレクトリを作成し、その配下に文言や画像のファイルを保存していく。

以上が、アプリケーションサーバー１１０、１２０の配備処理である。なお、バージョンアップ作業による配備では、既存のアプリケーションサーバー１１０の環境とは別に新たにアプリケーションサーバー１２０の環境を追加することになる。ステップＳ６０４の段階では、ＤＮＳ１８０の設定はそのままであるため、クライアント端末１５０は変わらずアプリケーションサーバー１１０へアクセスを行う。

ステップＳ６０５にて、ＤＮＳサービス３８０による切り替えを実施する。本処理はステップＳ６０４実施後、アプリケーションサーバー１２０が正常に稼働していることを確認した後に実施することが一般的である。ＤＮＳ切り替え処理では、ＤＮＳ１８０に登録されているアプリケーションサーバー１１０、１２０のホスト名に対応したＩＰアドレスをアプリケーションサーバー１１０の値からアプリケーションサーバー１２０の値に変更する。

図７は本実施の形態にかかわる、クライアント端末１５０からアプリケーションサーバー１１０を利用する場合の一般的な流れを示した図である。まず、Ｗｅｂブラウザ３５０にてＲＥＳＴｆｕｌ ＭＶＣで構成されたアプリケーションを利用する場合の処理の概要を示す。Ｗｅｂブラウザ３５０は画面を描画するためのＨＴＭＬをアプリケーションサーバー１１０より取得する。ＨＴＭＬにはＪａｖａＳｃｒｉｐｔ（登録商標）へのリンクが記載されているので引き続きＪａｖａＳｃｒｉｐｔ（登録商標）を取得する。Ｗｅｂブラウザ３５０上では取得したＪａｖａＳｃｒｉｐｔ（登録商標）が実行され、アプリケーションサーバー１１０で公開されているＲＥＳＴ ＡＰＩを呼び出しデータの取得を行う。例えば画面表示用の文言を、表示したい言語を指定してＡＰＩを呼び出し、対応する言語の文言データを取得するといった処理となる。Ｗｅｂブラウザ３５０はＨＴＭＬの表示文言を取得した言語のデータで書き換えることで、画面を生成し表示を行う。また、Ｗｅｂブラウザ３５０にて各種操作を行った場合もＲＥＳＴ ＡＰＩが呼び出され、その結果を取得して画面の更新が行われる。つまり、ＨＴＭＬで定義されている表示文言と、ＲＥＳＴ ＡＰＩで取得した文言データにずれが生じると、ＨＴＭＬに適切な文言が表示されないことが発生する。この発生要因については課題の欄にて述べた通りである。

引き続き詳細な処理の流れを説明する。Ｗｅｂブラウザ３５０にてアプリケーションサーバー１１０の利用を開始した場合、ステップＳ７０１にてアプリケーションサーバー１１０のＨＴＭＬがキャッシュに存在するか確認する。存在する場合はキャッシュを利用するが、存在しない場合はＨＴＭＬの取得の処理を行う。ＨＴＭＬを取得する場合、ステップＳ７０２にて名前解決のリクエストをＤＮＳ１８０に行う。ＤＮＳ１８０はステップＳ７０３にてアプリケーションサーバー１１０に対応したＩＰアドレスをレスポンスする。なお、ステップＳ７０２、Ｓ７０３の処理はＷｅｂブラウザ３５０起動後、アプリケーションサーバー１１０にリクエストを発行する際に実施される。つまり、ステップＳ７０４、ステップＳ７０７、ステップＳ７０９の直前で実施される。なお、一般的なブラウザでは一度ＤＮＳよりＩＰアドレスを取得するとしばらくはキャッシュされるため、ＤＮＳの問い合わせは省略される場合もある。そのため、ＤＮＳ切り替えの反映タイミングはクライアント端末１５０の種類によってさまざまである。

Ｗｅｂブラウザ３５０がＨＴＭＬを取得したことに応じてＨＴＭＬに対応したＪａｖａＳｃｒｉｐｔ（登録商標）の取得を行う。ＨＴＭＬ同様ＪａｖａＳｃｒｉｐｔ（登録商標）に関してもステップＳ７０６にてキャッシュに存在するかの確認を行う。存在する場合はキャッシュを利用するが、存在しない場合はＪａｖａＳｃｒｉｐｔ（登録商標）の取得処理ステップＳ７０７、Ｓ７０８をＨＴＭＬと同様に行う。ＪａｖａＳｃｒｉｐｔ（登録商標）を取得したことに応じ、ステップＳ７０９ にてＪａｖａＳｃｒｉｐｔ（登録商標）に記載されたＲＥＳＴ ＡＰＩの呼び出しが行われる。本ＡＰＩ呼び出しではパラメータにビルドバージョンが含まれる。アプリケーションサーバー１１０はＡＰＩ呼び出しにて指定されたビルドバージョンのリソースをステップＳ７１０、Ｓ７１１にてストレージサーバー１３０より取得し、ステップＳ７１２にて、Ｗｅｂブラウザ３５０へレスポンスする。レスポンスを受けたＷｅｂブラウザ３５０はステップＳ７１３にて、ＨＴＭＬとＨＴＭＬに対応したリソースを元に画面表示をおこなう。以上が、クライアント端末１５０からアプリケーションサーバー１１０を利用する場合の処理である。このサービスの利用中にバージョンアップ処理が行われることになる。

図７にて、クライアント端末１５０がバージョンアップ処理後にアプリケーションサーバー１２０を利用した場合の処理の一例をさらに説明する。また、図１０は本処理の流れを模式的に表した図である。例えば、Ｗｅｂブラウザ３５０はすでに旧バージョンを利用しているので図１０の様にアプリケーションサーバー１１０より取得したＨＴＭＬやＪａｖａＳｃｒｉｐｔ（登録商標）をキャッシュしている。その結果、図７のステップＳ７０２、Ｓ７０３の名前解決処理は実施されず、ステップＳ７０４、Ｓ７０５のＨＴＭＬ取得処理、ステップＳ７０７、Ｓ７０８のＪａｖａＳｃｒｉｐｔ（登録商標）取得処理もスキップされる。次にステップＳ７０９にてＡＰＩ呼び出しが行われるが、この際初めてＷｅｂブラウザ３５０はＤＮＳにてアプリケーションサーバーのＩＰを取得するためにステップＳ７０２、Ｓ７０３の名前解決処理を実施する。本処理で取得できるＩＰアドレスは図１０で示す通り、アプリケーションサーバー１２０のＩＰアドレスとなり、ステップＳ７０９のＡＰＩ呼び出しはアプリケーションサーバー１２０に対して行われる。この呼び出しの際、パラメータとしてはアプリケーションサーバー １１０に対応したビルドバージョンが渡されることとなる。図１０で示す通り、本実施例では「２０１５０５１５．１」というアプリケーションサーバー１１０で提供されていたビルドバージョンが渡される。よって、ビルドバージョンの一致を確認したアプリケーションサーバー１２０はステップＳ７１０、Ｓ７１１の処理でストレージサーバー１３０からアプリケーションサーバー１１０に対応したリソースを取得し、Ｓ７１２でレスポンスすることとなる。Ｗｅｂブラウザ３５０はキャッシュされたアプリケーションサーバー１１０から取得したＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）とアプリケーションサーバー１２０から取得した、それに対応したリソースを元に、ステップＳ７１３の処理を正常に実施し、画面を表示できる。

以上、本実施例によれば、サービスを無停止で提供するための仕組みを持つシステムにおいて、Ｉ／Ｆの互換性の他に画面のＨＴＭＬに関しても互換性を保つことが可能になる。

本発明の実施例１に追加して実施可能な処理を説明する。本処理は、バージョンアップ終了後一定時間経過した後、アプリケーションサーバー１１０の環境を削除するための処理と、削除後にアプリケーションサーバー１１０のリソースが要求された場合の処理に関する。

管理サーバー１４０の配備モジュール３４２はバージョンアップ終了後のアプリケーションサーバー１１０を削除する処理を実施する。サービスを提供するために構成されているシステムの対象からアプリケーションサーバー１１０を外すことで、アプリケーションサーバー１１０が削除される。この際、アプリケーションサーバー１１０に対応したビルドバージョンのリソースデータもストレージサーバー１３０より削除する。本処理でアプリケーションサーバー１１０は全て削除される。削除指定はユーザーによる指定によって任意のタイミングで行われる。

次に、アプリケーションサーバー１１０のリソースが要求された場合の処理に関する処理について説明するが、ＨＴＭＬ等のキャッシュの有効期限がきれ、アプリケーションサーバー１１０に対応したリソース要求が無くなった時点を想定する。この際、インターネット上のキャッシュの制御はサーバーシステムからはできないので、想定外の原因でリソース削除後にアプリケーションサーバー１１０に対応したリソースの要求が来る場合がある。

図８は、想定外のリクエストを受けたことを考慮したＡＰＩモジュール３１１の処理の流れを示す。ＡＰＩモジュール３１１はＷｅｂブラウザ３５０からのＡＰＩ呼び出しステップ７０９を受けた際、ステップＳ８０１にてパラメータで指定されたビルドバージョンに対応したリソースの取得処理を実施する。対応したリソースがストレージサーバー１３０に存在すればそのリソースをレスポンスする。もし存在しない場合は、ステップＳ８０３にてエラー応答を生成しレスポンスを行う。本エラー応答にはＷｅｂブラウザ３５０に対してキャッシュを破棄して再度ＨＴＭＬを取得するような意味を含める。エラー応答を受け取ったＷｅｂブラウザ３５０はＪａｖａＳｃｒｉｐｔ（登録商標）にて自身のリロードを実施する。リロード処理を実施することでキャッシュのＨＴＭＬが無くなりアプリケーションサーバー１２０より新たにＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ（登録商標）が新規に取得される。さらには、アプリケーションサーバー１２０に対応したリソースを取得するためのＡＰＩ呼び出しが行われ、Ｗｅｂブラウザ３５０はアプリケーションサーバー１２０の正しい画面を表示することが可能となる。

〔その他の実施例〕
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１１０ アプリケーションサーバー
１２０ アプリケーションサーバー
１３０ ストレージサーバー
１４０ 管理サーバー
１５０ クライアント端末
１８０ ＤＮＳ

Claims (10)

1. 端末に備えられたＷｅｂブラウザからの要求に応じてサービスを提供するアプリケーションサーバーシステムを含むサーバーシステムであって、
   第１のアプリケーションサーバーシステムに配備された前記サービスを実現するための複数のモジュールとは少なくとも一部の構成が異なる複数のモジュールを第２のアプリケーションサーバーシステムに配備する配備手段と、
   ストレージサービスに対し、前記Ｗｅｂブラウザにより表示される画面の表示に必要なリソースであって、前記第１のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第１のリソースおよび第２のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第２のリソースを保存させる保存手段と、
   前記配備手段による配備が行われた後、前記サービスの提供元を前記第１のアプリケーションサーバーシステムから前記第２のアプリケーションサーバーシステムへ切り替える切り替え手段と、を有し、
   前記切り替え手段による切り替えの後、前記Ｗｅｂブラウザから画面の表示に関する要求を受け付けた際に、前記要求に含まれるデータが前記第１のリソースに関連することを確認した場合、前記第２のアプリケーションサーバーシステムは前記保存手段から前記第１のリソースを取得し前記Ｗｅｂブラウザに送信することを特徴とするサーバーシステム。
2. 前記要求に含まれるデータとは識別情報であり、
   前記保存手段は、前記第１のリソースおよび前記第２のリソースの夫々に対しユニークな識別情報と対応づけて保存させており、前記システムは識別情報の一致の確認により前記第１のリソースまたは前記第２のリソースを前記Ｗｅｂブラウザに送信することを特徴とする請求項１に記載のサーバーシステム。
3. 前記画面の表示のためのＨＴＭＬおよび前記ＨＴＭＬを基に前記画面を描画するためのスクリプトおよび前記リソースを前記Ｗｅｂブラウザに送信し、前記スクリプトには識別情報が含まれており、前記Ｗｅｂブラウザが前記スクリプトを実行することによって送信される前記識別情報を受信する請求項２に記載のサーバーシステム。
4. 前記識別情報は複数のモジュールが前記アプリケーションサーバーシステムに配備される毎に生成される識別情報であって、日付とシーケンシャル値から生成される識別情報であることを特徴とする請求項２または３に記載のサーバーシステム。
5. 前記切り替え手段による切り替えの後、前記システムを構成する対象から前記第１のアプリケーションサーバーを外し、前記第１のリソースを前記ストレージサービスから削除することを特徴とする請求項１乃至４の何れか１項に記載のサーバーシステム。
6. 前記ストレージサービスから前記第１のリソースが削除されていた場合、前記Ｗｅｂブラウザに対し、前記画面に関するキャッシュを破棄させ前記第２のアプリケーションサーバーシステムが送信する前記画面の表示のためのＨＴＭＬおよび前記ＨＴＭＬを基に前記画面を描画するためのスクリプトおよび前記リソースを受信させるためのデータを送信することを特徴とする請求項１乃至５の何れか１項に記載のサーバーシステム。
7. Ｗｅｂブラウザを備えた端末と、前記端末のＷｅｂブラウザからの要求に応じてサービスを提供するアプリケーションサーバーシステムを含むシステムであって、
   第１のアプリケーションサーバーシステムに配備された前記サービスを実現するための複数のモジュールとは少なくとも一部の構成が異なる複数のモジュールを第２のアプリケーションサーバーシステムに配備する配備手段と、
   ストレージサービスに対し、前記Ｗｅｂブラウザにより表示される画面の表示に必要なリソースであって、前記第１のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第１のリソースおよび第２のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第２のリソースを保存させる保存手段と、
   前記配備手段による配備が行われた後、前記サービスの提供元を前記第１のアプリケーションサーバーシステムから前記第２のアプリケーションサーバーシステムへ切り替える切り替え手段と、を有し、
   前記切り替え手段による切り替えの後、前記Ｗｅｂブラウザから画面の表示に関する要求を受け付けた際に、前記要求に含まれるデータが前記第１のリソースに関連することを確認した場合、前記第２のアプリケーションサーバーシステムは前記保存手段から前記第１のリソースを取得し前記Ｗｅｂブラウザに送信することを特徴とするシステム。
8. 端末に備えられたＷｅｂブラウザからの要求に応じてサービスを提供するアプリケーションサーバーシステムを含むサーバーシステムで実行される方法であって、
   配備手段は、第１のアプリケーションサーバーシステムに配備された前記サービスを実現するための複数のモジュールとは少なくとも一部の構成が異なる複数のモジュールを第２のアプリケーションサーバーシステムに配備し、
   保存手段は、ストレージサービスに対し、前記Ｗｅｂブラウザにより表示される画面の表示に必要なリソースであって、前記第１のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第１のリソースおよび第２のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第２のリソースを保存させ、
   切り替え手段は、前記配備手段による配備が行われた後、前記サービスの提供元を前記第１のアプリケーションサーバーシステムから前記第２のアプリケーションサーバーシステムへ切り替える切り替え、
   前記切り替え手段による切り替えの後、前記Ｗｅｂブラウザから画面の表示に関する要求を受け付けた際に、前記要求に含まれるデータが前記第１のリソースに関連することを確認した場合、前記第２のアプリケーションサーバーシステムは前記保存手段から前記第１のリソースを取得し前記Ｗｅｂブラウザに送信することを特徴とする方法。
9. Ｗｅｂブラウザを備えた端末と、前記Ｗｅｂブラウザからの要求に応じてサービスを提供するアプリケーションサーバーシステムを含むシステムで実行される方法であって、
   配備手段は、第１のアプリケーションサーバーシステムに配備された前記サービスを実現するための複数のモジュールとは少なくとも一部の構成が異なる複数のモジュールを第２のアプリケーションサーバーシステムに配備し、
   保存手段は、ストレージサービスに対し、前記Ｗｅｂブラウザにより表示される画面の表示に必要なリソースであって、前記第１のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第１のリソースおよび第２のアプリケーションサーバーシステムに配備される複数のモジュールに対応した第２のリソースを保存させ、
   切り替え手段は、前記配備手段による配備が行われた後、前記サービスの提供元を前記第１のアプリケーションサーバーシステムから前記第２のアプリケーションサーバーシステムへ切り替える切り替え、
   前記切り替え手段による切り替えの後、前記Ｗｅｂブラウザから画面の表示に関する要求を受け付けた際に、前記要求に含まれるデータが前記第１のリソースに関連することを確認した場合、前記第２のアプリケーションサーバーシステムは前記保存手段から前記第１のリソースを取得し前記Ｗｅｂブラウザに送信することを特徴とする方法。
10. 請求項８に記載の方法をサーバーシステムで実行させるためのプログラム。

Images