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

Abstract

【課題】 サービスの無停止バージョンアップを行うためのＢｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔにおいて、ＤＮＳの切り替え中のタイミングでは新旧どちらのサーバーに接続されるか不定の時間がある。そのため、新バージョンのＨＴＭＬから旧バージョンのＡＰＩ呼び出しが発生してしまいアプリケーションが正しく動作しない。【解決手段】 ＡＰＩ用のホスト名とＨＴＭＬ用のホスト名を別々に定義しＡＰＩ用のＤＮＳ切り替えを完了させてからＨＴＭＬ用のＤＮＳ切り替えるという時間差での切り替えを行うことで、新バージョンのＨＴＭＬが旧バージョンのＡＰＩを呼び出さないようにする。【選択図】 図６

Description

本発明は、Ｗｅｂアプリケーションサービスを備えたサーバーを管理する管理サーバーシステム、システム、システムの方法およびプログラムに関する。

近年インターネットのサーバー上から提供されるサービスの普及が進んでいる。サービスは世界各国のユーザーから利用される運用形態も考えられ、特定の期間の間にシステムを停止しサービスのメンテナンスを行うといったことが難しい。そのため、サービスを停止することなくメンテナンス作業をするよう要求が高まっている。従来技術として、特許文献１および２に開示されているようにクライアントからのリクエストをどのサーバーへ振り分けるかを制御することでサーバーのメンテナンスや切り替えをサービス無停止で実現している技術がある。

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

特許第４０８３０４９号 特開２００４−２９５６０５号

サービスを停止することなくシステムを切り替えるための手法の１つとして、Ｂｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔという方法が考えられる。これは現在稼働しているシステムを稼働させた状態で、新規にシステムをもう一つ構築し、そのシステムにクライアントとの接続を切り替えるといった手法である。このＢｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔによるシステムの切り替えは、ＤＮＳに登録されたホスト名のＩＰアドレス設定を変更することでシステムの切り替えが可能になる。

ただし、この際に課題が発生する。名前解決に使用するＤＮＳサーバーが複数ある場合、ＤＮＳ間でのＩＰアドレスの設定同期には時差があるため、名前解決のリクエスト元が新システムのＩＰアドレスと旧システムのＩＰアドレスの両方を取得できてしまう状況が発生する。これにより、ＤＮＳに登録したホスト名のＩＰアドレスを切り替えたとしても、即座に全てのアクセスが新システムに対して行われるわけではなく、新旧どちらのシステムに対して行われるかが不透明な状態となる。

本発明の目的は上記課題を解決するために、新システムが提供するＨＴＭＬ画面を介し、旧システムに対するＡＰＩの呼び出しが発生しないようにするシステムを提供することを目的の１つとする。

本発明を実施するための一実施形態に係る管理サーバーシステムは、名前解決のリクエストとともに受信したホスト名に対応するＩＰアドレスを返却するＤＮＳサーバーと、前記ＤＮＳサーバーから返却されたＩＰアドレスに対応するシステムに対しクライアントからのＨＴＭＬリクエストおよびＡＰＩリクエストの処理依頼を送信する振り分けサーバーと、通信することが可能な管理サーバーシステムであって、システム環境を構築するためのプログラムを情報処理装置に配備しシステムを構築する構築手段と、前記ＤＮＳサーバーに登録されたホスト名であるＨＴＭＬリクエストに対応したホスト名およびＡＰＩリクエストに対応したホスト名の夫々のホスト名に対し、前記構築手段により構築されたシステムのＩＰアドレスを設定する設定手段と、を有し、前記設定手段は、前記構築手段により新たなシステムが構築された後、前記ＡＰＩリクエストに対応したホスト名に設定されている現在のＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始め、前記振り分けサーバーの名前解決のリクエストに対応する全ての前記ＤＮＳサーバーの書き換えが完了したことを確認したことに応じて、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とする。

本発明により、新システムが提供するＨＴＭＬ画面を介し、旧システムに対するＡＰＩの呼び出しが発生しないようにすることが可能となる。

システム構成図 各装置のハードウェア構成図 各装置のソフトウェアモジュール構成図 クライアント端末からアプリケーションサーバーの接続の模式図 クライアント端末がアプリケーションを実行する際の流れの図 バージョンアップ処理のフロー図 バージョンアップ処理中のそれぞれのシステム構成図 バージョンアップ処理のフロー図 バージョンアップ処理のフロー図

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

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

本実施例に係るシステム構成を図１に示す。本発明のバージョンアップシステムは管理サーバー１４０、ＤＮＳ１８０、振り分けサーバー１３０から成る。サービスはアプリケーションサーバー１１０／１２０により提供する。なお、図では夫々のサーバーが１台の情報処理装置で構成されるように描かれているが、各サーバーを構成する情報処理装置の台数を限定しているわけではないことに留意されたい。サービスはクライアント端末１５０より利用される。

１００は、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＡＮ１００）であり、本実施例ではＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）システムが構築されている。１０１は各構成要素を接続するＬｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０１）である。１０２もＬＡＮ１０１と同様Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＬＡＮ１０２）であるが、ＷＡＮ１００経由でのアクセスができない内部ネットワークの場合が多い。なお、ＬＡＮ１０２もＬＡＮ１０１と同様、ＷＡＮ１００に直接接続されアクセスできるような構成でも良い。

アプリケーションサーバー１１０／１２０は１つまたは複数台の情報処理装置から成り、図１に示すような構成のネットワーク上に実現される。アプリケーションサーバー１１０が現在サービスを提供中のサーバーであり、アプリケーションサーバー１２０が次にサービスを提供するシステムである。また、アプリケーションサーバー１１０と１２０の切り替えは必ずしもバージョンアップのためだけにシステムを切り替えるものではない。

１３０は振り分けサーバーであり、複数の情報処理装置から構成されるのが一般的であるが１台であっても良い。振り分けサーバー１３０はクライアント端末１５０からのアクセスを適切なアプリケーションサーバー１１０に振り分けて処理をさせる機能を有する。１４０は管理サーバーであり、それぞれ複数の情報処理装置から構成されるのが一般的であるが１台であっても良い。管理サーバー１４０はアプリケーションサーバー１１０、１２０を構成するプログラムの管理、アプリケーションサーバー１１０、１２０の構築や切り替え処理を行う。

１５０はクライアント端末であり、パーソナルコンピューター、スマートフォンといったモバイル端末など、Ｗｅｂブラウザがインストールされている情報処理装置である。１８０はＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ（ＤＮＳ）であり、ネットワーク上のサーバーのホスト名を解決しアクセス先のＩＰアドレスを返却するシステムである。１８０の情報処理装置を単にＤＮＳと称する場合と、ＤＮＳサーバーと称する場合があるが、何れも名前解決リクエストに対してＩＰアドレスをリクエスト元へ返却する機能を有するシステムである。Ｂｌｕｅ−Ｇｒｅｅｎ Ｄｅｐｌｏｙｍｅｎｔにおけるサービス切り替えは、ＤＮＳに登録されたホスト名に対応したＩＰアドレスを、アプリケーションサーバー１１０のＩＰアドレスからアプリケーションサーバー１２０のＩＰアドレスに書き換えることで実現する。振り分けサーバー１３０はクライアント端末１５０のリクエストをアプリケーションサーバーに送信するが、具体的にはクライアント端末１５０のリクエストに対応するデータをＤＮＳで名前解決されたアプリケーションサーバー１１０または１２０の何れか１つへ送信する。振り分けサーバー１３０は、設定されている転送先ホスト名に対応したサーバーのＩＰアドレスをＤＮＳ１８０から取得し、稼働中のアプリケーションサーバー１１０または１２０の何れか１つに接続されることを意味する。

以上が、本システムを構成する各装置の説明である。なお、上述した通り各サーバーは１台で構成されていても複数台で構成されていても良いため、本願明細書ではサーバーシステムと称することでどちらの構成も含むサーバーを意図しているものとする。例えば、管理サーバーシステムと称した場合、管理サーバー１４０が１台の情報処理装置、および複数台の情報処置装置から構成されるサーバー群の何れか１つ任意の形態を意味していることになる。

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

尚、後述の全ての説明において、特に断りのない限りソフトウェアを実行するハード上の主体はＣＰＵ２３１であり、ソフトウェアの主体は外部メモリ２４１にインストールされたアプリケーションプログラムである。アプリケーションプログラムが各情報処理装置にインストールされることで配備され、ＣＰＵ２３１が配備されたアプリケーションプログラムを実行することで後述する図３のソフトウェア構成を具備したシステム環境が実現する。

図３は本実施例に係る、アプリケーションサーバー１１０、１２０、振り分けサーバー１３０、管理サーバー１４０、クライアント端末１５０、ＤＮＳ１８０、それぞれのソフトウェア構成を示す図である。

アプリケーションサーバー１１０、１２０はアプリケーションサービス３１９を持ち、アプリケーションサービス３１９はＷｅｂサーバーモジュール３１０とＡＰＩモジュール３１１を持つ。Ｗｅｂサーバーモジュール３１０は、一般的にＪｅｔｔｙやＡｐａｃｈｅ Ｔｏｍｃａｔ等を利用し、ＨＴＭＬやＪａｖａＳｃｒｉｐｔ（登録商標）の配信、および／またはＡＰＩモジュール３１１の実行環境を提供する。アプリケーションサーバー１１０、１２０は、Ｗｅｂサーバーモジュール３１０を実行することで、ＨＴＴＰに関する処理、例えば、ＨＴＭＬ形式の表示画面の生成および生成した表示画面のクライアント端末１５０への提供を実現する。さらには、ＡＰＩモジュール３１１を実行することでＡＰＩの処理を実現する。Ｗｅｂサーバーモジュール３１０、およびＡＰＩモジュール３１１ともクライアントからのリクエストに対する処理依頼を受信したことに伴い、各種処理を実行する。

振り分けサーバー１３０は振り分けサービス３３０を持ち、振り分けモジュール３３１と振り分け設定３３２を持つ。振り分けモジュール３３１は、クライアント端末１５０が振り分けサーバー１３０へアクセスしてきた際に用いたＵＲＬを元に、振り分け設定３３２に従ってアプリケーションサーバー１１０または１２０へのクライアント端末１５０によるアクセスを決定する。振り分け設定３３２の詳細は後述する。

管理サーバー１４０は管理サービス３４９を有し、管理サービス３４９はプログラム管理モジュール３４０とビルドモジュール３４１と配備モジュール３４２を持つ。プログラム管理モジュール３４０はアプリケーションサーバー１１０、１２０のシステム環境を構築するためのプログラムの管理を行う。ビルドモジュール３４１はプログラム管理モジュール３４０で管理されているプログラムを実行形式のモジュールに構成する。配備モジュール３４２はビルドモジュール３４１で生成した実行形式のモジュールを情報処理装置に配備し、アプリケーションサーバー１１０、１２０のシステム環境を構築することでアプリケーションサービスのバージョンアップ処理を実施する。

ＤＮＳ１８０はＤＮＳサービス３８０を持ち、ＤＮＳサービス３８０は名前解決のリクエストに対して、ＩＰアドレス設定３８１を元にＩＰアドレスをレスポンスする。ＩＰアドレス設定３８１の詳細に関しては後述する。クライアント端末１５０はアプリケーションサーバー１１０、１２０にアクセスするためのＷｅｂブラウザ３５０を持つ。

図４は、本実施例に係る、クライアント端末１５０がアプリケーションサーバー１１０にアクセスするための通信経路を模式的に表した図である。アプリケーションサーバー１１０の実施形態として、それぞれ異なるサービスを提供するアプリケーションサーバー４０１、４０２、４０３がある。本図では、振り分けサーバー１３０の動きを説明する。
アプリケーションサーバー４０１のホスト名は「ａｐｐ１．ｌｏｃａｌ」と「ａｐｐａｐｉ１．ｌｏｃａｌ」の２種類を割り当てている。同様に、アプリケーションサーバー４０２のホスト名が「ａｐｐ２．ｌｏｃａｌ」、「ａｐｐａｐｉ２．ｌｏｃａｌ」、アプリケーションサーバー４０３のホスト名が「ａｐｐ３．ｌｏｃａｌ」、「ａｐｐａｐｉ３．ｌｏｃａｌ」である。それぞれ２種類のホスト名が割り当てられているのは、ＨＴＭＬリクエストと、ＡＰリクエストを分離するためであり、その処理の詳細に関しては後述する。また、振り分けサーバー１３０のホスト名は「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」となっている。

クライアント端末１５０はＷｅｂブラウザ３５０にて振り分けサーバー１３０に割り当てられているホスト名とアクセスパスを入力する。例えば、「ｈｔｔｐｓ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｐｐ１／ｌｏｇｉｎ」といったＵＲＬである。クライアント端末１５０のＷｅｂブラウザ３５０は振り分けサーバー１３０へリクエストを行う。

リクエストを受信した振り分けサーバー１３０は振り分け設定３３２を参照し、振り分け先のサーバーを決定する。振り分け設定３３２の具体例を表１で説明する。下記設定では、「／ａｐｐ１」で始まるパスへのアクセスは、「ｈｔｔｐｓ：／／ａｐｐ１．ｌｏｃａｌ」サーバーへ転送するといった設定がなされており、アプリケーションサーバー４０１へアクセスされる。また、「／ａｐｐａｐｉ１」で始まるパスへのアクセスは、「ｈｔｔｐｓ：／／ａｐｐａｐｉ１．ｌｏｃａｌ」サーバーへ転送するといった設定がなされており、こちらもアプリケーションサーバー４０１へアクセスされる。

図５は、本実施例に係るクライアント端末１５０のＷｅｂブラウザ３５０がアプリケーションサーバー１１０より画面を取得しアプリケーションを実行するまでの処理の流れを示したフローである。

クライアント端末１５０のＷｅｂブラウザ３５０は、ステップＳ５０１にてＨＴＭＬのリクエストを行う。ＨＴＭＬのリクエストを受け付けた振り分けサーバー１３０はステップＳ５０２にて、リクエストのあったＵＲＬと振り分け設定３３２を元に振り分け先のアプリケーションサーバー１１０を決定する。「／ａｐｐ１」で始まるパスのＵＲＬでクライアント端末１５０が振り分けサーバー１３０にアクセスした場合は、「ｈｔｔｐｓ：／／ａｐｐ１．ｌｏｃａｌ」のアプリケーションサーバー１１０に決定される。続いて、振り分けサーバー１３０は「ｈｔｔｐｓ：／／ａｐｐ１．ｌｏｃａｌ」へ要求を出すためにステップＳ５０３にてＤＮＳ１８０に対して名前解決のリクエストを送信する。ＤＮＳ１８０では表２に示すようにホスト名とＩＰアドレスが管理されており、その設定情報を元にＩＰアドレスがステップＳ５０４で返却される。「ａｐｐ１．ｌｏｃａｌ」の場合は「１９２．１６８．０．１」が返却される。なお、ホスト名の指定方法は本実施例に限られるものではなくＵＲＬ内に含まれるホスト名の一部をＤＮＳ１８０に送信する形態であっても良く、ホスト名と称した場合にホスト名の中にドメイン名が含まれない場合もある。

ＩＰアドレスを取得した振り分けサーバー１３０はそのＩＰアドレスのサーバーに対してステップＳ５０５にてＨＴＭＬリクエストの処理依頼を行い、ステップＳ５０６で取得したＨＴＭＬデータをステップＳ５０７にてＷＥＢブラウザ３５０にレスポンスする。ＷＥＢブラウザ３５０はレスポンスされたＨＴＭＬデータを表示する際、ＨＴＭＬに記述されたＪａｖａＳｃｒｉｐｔ（登録商標）によってステップＳ５１１にてＡＰＩ呼び出しを行う。なおＡＰＩの呼び出しは「ｈｔｔｐｓ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｐｐａｐｉ１／ｖ１／ｆｕｎｃｔｉｏｎ１」といった形で、画面とは違うＵＲＬのパスに対して行われる。ＡＰＩ呼び出しのであるＡＰＩリクエストを受けた振り分けサーバー１３０は、ＨＴＭＬ取得時と同様にステップＳ５１２にて振り分け先を「ｈｔｔｐｓ：／／ａｐｐａｐｉ１．ｌｏｃａｌ」のアプリケーションサーバー１１０に決定する。続いて、振り分けサーバー１３０は「ｈｔｔｐｓ：／／ａｐｐａｐｉ１．ｌｏｃａｌ」へＡＰＩリクエストの処理依頼を送信するためにステップＳ５１３にてＤＮＳ１８０に対し名前解決のリクエストを行う。表２の例では「ａｐｐ１．ｌｏｃａｌ」と「ａｐｐａｐｉ１．ｌｏｃａｌ」は同様のＩＰアドレスであるため、ステップＳ５１４ではステップＳ５０４と同じ値が返る。ただし、設定値を変えることによりＨＴＭＬの取得とＡＰＩの呼び出しのアクセス先サーバーを異なるサーバーにすることが可能となる。ステップＳ５１５からステップＳ５１７の一連の処理でＷＥＢブラウザ３５０に処理結果をレスポンスする。ＷＥＢブラウザ３５０はステップＳ５２０において、ステップＳ５１７のＡＰＩの処理結果をもとに画面を表示する。

次に、図６から図７を用いて本実施例のシステムにおいて、管理サーバー１４０の配備モジュール３４２がアプリケーションサーバー１１０から１２０への切り替えを行う方法を示す。なお、図６および図７では、アプリケーションサーバー１１０のサービスを、アプリケーションサーバー１２０に配備された新バージョンのサービスへバージョンアップする方法を示す。図６は配備モジュール３４２が行うバージョンアップ処理のフローを示し、図７はバージョンアップ処理中のシステム構成を示す。

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

配備モジュール３４２はステップＳ６０２にて、モジュールの配備を実施する。ステップＳ６０１にて生成された情報処理装置にＷｅｂサーバーモジュール３１０とＡＰＩモジュール３１１を配備していく。なお、バージョンアップを想定する場合、Ｗｅｂサーバーモジュール３１０には新規のＨＴＭＬ画面が追加され、ＡＰＩモジュール３１１には新規のＡＰＩが追加され、新規のＨＴＭＬ画面は新規のＡＰＩの呼び出し動作が可能となる。以上で、図７（ａ）に示したアプリケーションサーバー７０１の構築が完了する。この段階では、システムに対してバージョンアップ後のアプリケーションサーバー７０１が追加されただけの状態であり、アプリケーションサーバー７０１に振り分けサーバー１３０による処理依頼は送信されない。

本実施例ではＤＮＳ１８０はＰｒｉｍａｒｙ ＤＮＳ７０２とＳｅｃｏｎｄａｒｙ ＤＮＳ７０３の２台から構成されている。ＤＮＳ１８０は可用性や性能などの理由から１台で構成されるのではなく複数で構成されるのが一般的である。Ｐｒｉｍａｒｙ ＤＮＳ７０２がメインとなるＤＮＳであり、Ｓｅｃｏｎｄａｒｙ ＤＮＳ７０３はＰｒｉｍａｒｙ ＤＮＳ７０２と同様の設定が同期されるサブＤＮＳとなる。振り分けサーバー１３０は名前解決の際Ｐｒｉｍａｒｙ ＤＮＳ７０２、Ｐｒｉｍａｒｙ ＤＮＳ７０３のどちらで名前を解決しても良い。この段階では、Ｐｒｉｍａｒｙ ＤＮＳ７０２のＩＰアドレス設定３８１には、ＨＴＭＬ用ホストの設定もＡＰＩ用ホストの設定もアプリケーションサーバー４０１のＩＰアドレスである「１９２．１６８．０．１」が設定されている。また、Ｓｅｃｏｎｄａｒｙ ＤＮＳ７０３の設定もＰｒｉｍａｒｙ ＤＮＳ７０２との同期が完了しているので「１９２．１６８．０．１」が設定されている。この段階では、バージョンアップ前と同様、振り分けサーバー１３０は７１１、７１２のパスでアプリケーションサーバー４０１に対してリクエストの処理依頼を送信する。

次に、配備モジュール３４２はステップＳ６０３にてＡＰＩ用ホスト名のＤＮＳの切り替え処理を行う。具体的にはＰｒｉｍａｒｙ ＤＮＳ７０２のＡＰＩリクエストに対応したホスト名「ａｐｐａｐｉ１．ｌｏｃａｌ」に設定されている現在のＩＰアドレスを、アプリケーションサーバー７０１のＩＰアドレスの値「１９２．１６８．０．２」に書き換える。図７（ｂ）がステップＳ６０３まで完了した状態での構成図である。この時、振り分けサーバー１３０は、ＨＴＭＬの取得は７１１、７１２のパスでアプリケーションサーバー４０１に対してリクエストの処理依頼を送信する。ＡＰＩの呼び出しはＰｒｉｍａｒｙ ＤＮＳ７０２にてステップＳ５１３の名前解決を実施した場合、７１３、７１４のパスでアプリケーションサーバー７０１に対してリクエストの処理依頼を送信する。また、Ｓｅｃｏｎｄａｒｙ ＤＮＳ７０３にてステップＳ５１３の名前解決を実施した場合は、７１１、７１２のパスでアプリケーションサーバー４０１に対してリクエストの処理依頼を送信する。つまり、本タイミングでは、ＡＰＩの呼び出しはアプリケーソンサーバー４０１、７０１の何れか１つに送信される状態であり、どちらのＡＰＩを呼び出すかはリクエストごとに変化する。

なお、アプリケーションサーバー７０１にはアプリケーションサーバー４０１と同じＡＰＩが存在するため、アプリケーションサーバー４０１から提供されたＨＴＭＬで指定されたＡＰＩの呼び出しは問題なく処理される。なぜなら、ＨＴＭＬホストに関する切り替えはＰｒｉｍａｒｙ ＤＮＳ７０２および Ｓｅｃｏｎｄａｒｙ ＤＮＳ７０３ともアプリケーションサーバー４０１のＢｌｕｅのＩＰアドレスを参照するため、クライアント端末１５０に表示される画面は新しいＡＰＩに対応していない表示画面だからである。また、アプリケーションサーバー７０１にのみ追加されているＡＰＩは、アプリケーションサーバー７０１の新規に追加されたＨＴＭＬがクライアント端末１５０に提供されないため使われない。

次に、配備モジュール３４２はステップＳ６０４にてＡＰＩ用ホスト名のＤＮＳが同期されたかをチェックする。具体的には、Ｐｒｉｍａｒｙ ＤＮＳ７０１とＳｅｃｏｎｄａｒｙ ＤＮＳ７０２に対して「ａｐｐａｐｉ１．ｌｏｃａｌ」の名前解決を行い、ステップＳ６０４にて設定した「１９２．１６８．０．２」の値が両方のＤＮＳから取得されたか否かを判別する。取得された値がアプリケーションサーバー４０１のＩＰアドレス「１９２．１６８．０．１」であった場合はステップＳ６０４を繰り返す。アプリケーションサーバー７０１のＩＰアドレス「１９２．１６８．０．２」であった場合は次の処理に進む。なお、ＤＮＳの構成が３台以上だった場合、ＩＰアドレスを書き換えたＤＮＳを除く全てのＤＮＳのＩＰアドレスのチェックを行うことになる。図７（ｃ）がステップＳ６０４の処理を抜け、Ｓ６０５の処理を開始する前の段階での構成図である。Ｐｒｉｍａｒｙ ＤＮＳ７０２のＩＰアドレス設定３８１がＳｅｃｏｎｄａｒｙ ＤＮＳ７０３のＩＰアドレス設定に同期している。この時、振り分けサーバー１３０は、ＨＴＭＬの取得を７１１、７１２のパスでアプリケーションサーバー４０１に対して転送する。また、ＡＰＩの呼び出しは、全て７１３、７１４のパスでアプリケーションサーバー７０１に対して転送する。

次に、配備モジュール３４２はステップＳ６０５にてＨＴＭＬ用ホスト名のＤＮＳの切り替え処理を行う。具体的にはＰｒｉｍａｒｙ ＤＮＳ７０２のＨＴＭＬに対応したホスト名「ａｐｐ１．ｌｏｃａｌ」のＩＰアドレスをアプリケーションサーバー７０１のＩＰアドレスの値「１９２．１６８．０．２」に書き換える。図７（ｄ）がステップＳ６０５まで完了した状態での構成図である。この時、振り分けサーバー１３０は、ＨＴＭＬの取得でＰｒｉｍａｒｙ ＤＮＳ７０２にてステップＳ５０３の名前解決を実施した場合は、７１３、７１４のパスでアプリケーションサーバー７０１に対して転送する。Ｓｅｃｏｎｄａｒｙ ＤＮＳ７０３にてステップＳ５０３の名前解決を実施した場合は、７１１、７１２のパスでアプリケーションサーバー４０１に対して転送する。つまり、本タイミングでは、ＨＴＭＬの取得に関して、アプリケーションサーバー４０１、７０１のどちらに転送されるかはリクエストごとに変化する。ただし、ＡＰＩの呼び出しは必ずアプリケーションサーバー７０１に転送するため、アプリケーションサーバー７０１から取得された新規ＨＴＭＬからの、ＡＰＩ呼び出しは問題なく処理される。

以上で、配備モジュール３４２の処理は完了する。その後、さらに一定時間経過するとＰｒｉｍａｒｙ ＤＮＳ７０２のＩＰアドレス設定３８１がＳｅｃｏｎｄａｒｙ ＤＮＳ７０３のＩＰアドレス設定３８１に同期され、ＨＴＭＬ用ホスト名のＩＰアドレス設定も「１９２．１６８．０．２」に設定される。そのため、最終的には図７（ｅ）に示す構成となる。この段階では振り分けサーバー１３０は全てのリクエストを７１３、７１４のパスでアプリケーションサーバー７０１に対して転送する。

以上で、アプリケーションのバージョンアップ処理は完了する。ＡＰＩ用のホスト名とＨＴＭＬ用のホスト名を別々に定義しＡＰＩ用のＤＮＳ切り替えを完全に完了してからＨＴＭＬ用のＤＮＳ切り替えを時間差で行うことで、新システムのＨＴＭＬ画面から、旧システムのＡＰＩを利用することを防ぐことが可能となる。その効果の一例として以下の状況を解決することも可能となる。クライアントにはバージョンアップ後の新システムが提供したＨＴＭＬ形式の画面が表示されており、その画面からバージョンアップ前の旧システムのＡＰＩが呼び出される状況である。即ち、画面取得の際にはＤＮＳの名前解決によって新システムに振り分けられたが、その画面を介してＡＰＩを使用した際にはＤＮＳの名前解決によって旧システムに振り分けられるのである。この時、旧システムには、新システムで新たに提供された新機能用のＡＰＩは存在しないため、クライアントからのリクエストは正しく処理されずユーザーには所望の結果を返すことができない。

実施例１において、振り分けサーバー１３０はホスト名のＤＮＳ１８０による名前解決の処理ステップＳ５０３、Ｓ５１３を毎回実施すると説明した。この場合、ＤＮＳ１８０に対し多くの名前解決処理のリクエストが送信され負荷が高まるといった問題や、毎回名前解決をするため、その分システム全体のスループットが低下するという問題がある。そのため振り分けサーバー１３０はステップＳ５０４、Ｓ５１４で取得したＩＰアドレスを一定時間保持し、同じホスト名でのアクセスの場合はステップＳ５０３、Ｓ５１３の処理を行わず、以前取得したＩＰアドレスを再利用するという設定を行う場合も想定される。

この場合、ステップＳ６０４にてＡＰＩ用ホスト名のＤＮＳ同期が完了しても、振り分けサーバー１３０はＤＮＳに対し名前解決のリクエストを送信せず、以前取得したＩＰアドレスで名前解決をする期間がある。そのため、振り分けサーバーによるアクセス先ＩＰアドレスが新システムへすぐには切り替わらない一方で、ＤＮＳの切り替えは表示画面に関して新システムへ切り替えられてしまっている状況が発生する。その結果、特定の振り分けサーバーはＤＮＳによる名前解決により新システムへ表示画面に関するリクエストを振り分け、別の振り分けサーバーはキャッシュしている旧システムのＩＰアドレスを利用し旧システムへＡＰＩに関するリクエストを振り分けてしまう。これは、振り分けサーバー１３０を構成するサーバー群それぞれのＩＰアドレスを保持するタイミングが異なるため、新しい設定値が全ての振り分けサーバー１３０に反映されるまでには時差が発生するためである。これにより、新システムのＨＴＭＬ画面から、旧システムのＡＰＩ利用を防ぐことができない課題がある。本実施例ではこの課題を解決する方法について説明するが、説明を行わない部分については実施例１と同様である。

図８は、本実施例における図６は配備モジュール３４２が行うバージョンアップ処理のフローである。ステップＳ６０１からＳ６０５は図６で説明した処理と同様である。配備モジュール３４２はステップＳ８０１にて一定時間の待機処理を行う。例えば、振り分けサーバー１３０のＤＮＳ名前解決のキャッシュ時間の設定が６０秒であった場合、ステップＳ８０１では６０秒以上の時間何もせずに待機する。なお、本願発明ではキャッシュ時間の６０秒に加え、更に一定時間の待機処理を行うことを想定しており、これにより確実に振り分けサーバー１３０のキャッシュが更新されることになる。結果、管理サーバー１４０が処理を待機している間に全ての振り分けサーバー１３０のＤＮＳ名前解決のキャッシュが無効になる。キャッシュが無効になれば、ステップＳ５１３の名前解決が発生するため、アプリケーションサーバー７０１のＩＰアドレスが取得されることとなる。この待機時間は、ユーザーの手により事前に設定される、もしくは振り分けサーバー１３０と通信を行いキャッシュ時間の設定を確認することで設定される形態を想定しているが、これに限られるモノではない。発明の本質は、バージョンアップシステムにおける全ての振り分けサーバー１３０のキャッシュが無効になり、振り分けサーバー１３０が切り替えの完了したＤＮＳ１８０に対して名前解決を行う状態になるまで待機することにある。

以上、一定時間の待機時間を設けることで、振り分けサーバー１３０で名前解決のキャッシュを持つ場合でも、新システムのＨＴＭＬ画面から、旧システムのＡＰＩを利用することを防ぐことが可能となる。

本実施例ではより確実に課題を解決する別の方法について説明するが、説明を行わない部分については実施例１と同様である。図９は、本実施例における図６は配備モジュール３４２が行うバージョンアップ処理のフローである。ステップＳ６０１からＳ６０５は図６で説明した処理と同様である。配備モジュール３４２はステップＳ９０１にてアクセスログ解析処理を行う。アプリケーションサーバー４０１は一般的に、クライアントからのＨＴＭＬリクエスト、およびＡＰＩリクエストの全てに対して、どのＵＲＬのパスにいつアクセスされたかのログが出力される。このログを解析し、例えば、「／ａｐｐ１＊」のパスで始まるＨＴＭＬ画面へのアクセスがあり、「／ａｐｐａｐｉ１＊」のパスで始まるＡＰＩの呼び出しが無い状態であることを一定時の間確認する。そして、ログに一定時間ＡＰＩリクエストによるＡＰＩの呼び出しが記録されなくなれば、振り分けサーバー１３０はＡＰＩリクエストの処理依頼をアプリケーションサーバー７０１に送信していることとなる。

以上、アクセスログの解析を設けることで、振り分けサーバー１３０で名前解決のキャッシュを持つ場合でも、新システムのＨＴＭＬ画面から、旧システムのＡＰＩを利用することを防ぐことが可能となる。

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

１１０ アプリケーションサーバー（Ｂｌｕｅ）
１２０ アプリケーションサーバー（Ｇｒｅｅｎ）
１３０ 振り分けサーバー
１４０ 管理サーバー
１５０ クライアント端末
１８０ ＤＮＳ
４０１ アプリケーションサーバー（Ｂｌｕｅ）
７０１ アプリケーションサーバー（Ｇｒｅｅｎ）
７０２ Ｐｒｉｍａｒｙ ＤＮＳ
７０３ Ｓｅｃｏｎｄａｒｙ ＤＮＳ

Claims (12)

1. 名前解決のリクエストとともに受信したホスト名に対応するＩＰアドレスを返却するＤＮＳサーバーと、前記ＤＮＳサーバーから返却されたＩＰアドレスに対応するシステムに対しクライアントからのＨＴＭＬリクエストおよびＡＰＩリクエストの処理依頼を送信する振り分けサーバーと、通信することが可能な管理サーバーシステムであって、
   システム環境を構築するためのプログラムを情報処理装置に配備しシステムを構築する構築手段と、
   前記ＤＮＳサーバーに登録されたホスト名であるＨＴＭＬリクエストに対応したホスト名およびＡＰＩリクエストに対応したホスト名の夫々のホスト名に対し、前記構築手段により構築されたシステムのＩＰアドレスを設定する設定手段と、を有し、
   前記設定手段は、前記構築手段により新たなシステムが構築された後、前記ＡＰＩリクエストに対応したホスト名に設定されている現在のＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始め、前記振り分けサーバーの名前解決のリクエストに対応する全ての前記ＤＮＳサーバーの書き換えが完了したことを確認したことに応じて、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とする管理サーバーシステム。
2. 前記設定手段は、全ての前記ＤＮＳサーバーに対し名前解決のリクエストともに前記ＡＰＩリクエストに対応したホスト名を送信し、全ての前記ＤＮＳサーバーが前記新たなシステムのＩＰアドレスを返却したか否かを判別し書き換えの完了を確認することを特徴とする請求項１に記載の管理サーバーシステム。
3. 前記振り分けサーバーは、前記ＤＮＳサーバーから返却されたＩＰアドレスをキャッシュする機能を有し、前記ＤＮＳサーバーに名前解決のリクエストを送信することなく、ホスト名に対応するキャッシュされたＩＰアドレスを読み込み、読み込まれたＩＰアドレスに対応するシステムに対し処理依頼を送信する振り分けサーバーであって、
   前記設定手段は、全ての前記ＤＮＳサーバーの書き換えが完了したことを確認した後、更に、前記振り分けサーバーが前記ＤＮＳサーバーに名前解決のリクエストを送信することでキャッシュしたＩＰアドレスを前記新たなシステムのＩＰアドレスに更新する処理が完了するまで待機し、その後、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とする請求項１または２に記載の管理サーバーシステム。
4. 前記設定手段は、前記振り分けサーバーが前記ＤＮＳサーバーに名前解決のリクエストを送信することでキャッシュしたＩＰアドレスを前記新たなシステムのＩＰアドレスに更新する処理が完了するまで待機し、待機した後にさらに一定時間の待機を行い、その後、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とする請求項３に記載の管理サーバーシステム。
5. 前記設定手段は、全ての前記ＤＮＳサーバーの書き換えが完了したことを確認した後、更に、書き換え前の前記ＩＰアドレスに対応するシステムにおいて、ＡＰＩリクエストの処理依頼を受信したことで出力するログを一定時間の間に出力されていないことを確認したことに応じて、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とする請求項１または２に記載の管理サーバーシステム。
6. クライアントと、名前解決のリクエストとともに受信したホスト名に対応するＩＰアドレスを返却するＤＮＳサーバーと、前記ＤＮＳサーバーから返却されたＩＰアドレスに対応するシステムに対し前記クライアントからのＨＴＭＬリクエストおよびＡＰＩリクエストの処理依頼を送信する振り分けサーバーと、管理サーバーシステムとから構成されるシステムであって、
   システム環境を構築するためのプログラムを情報処理装置に配備しシステムを構築する構築手段と、
   前記ＤＮＳサーバーに登録されたホスト名であるＨＴＭＬリクエストに対応したホスト名およびＡＰＩリクエストに対応したホスト名の夫々のホスト名に対し、前記構築手段により構築されたシステムのＩＰアドレスを設定する設定手段と、を有し、
   前記設定手段は、前記構築手段により新たなシステムが構築された後、前記ＡＰＩリクエストに対応したホスト名に設定されている現在のＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始め、前記振り分けサーバーの名前解決のリクエストに対応する全ての前記ＤＮＳサーバーの書き換えが完了したことを確認したことに応じて、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とするシステム。
7. 前記設定手段は、全ての前記ＤＮＳサーバーに対し名前解決のリクエストともに前記ＡＰＩリクエストに対応したホスト名を送信し、全ての前記ＤＮＳサーバーが前記新たなシステムのＩＰアドレスを返却したか否かを判別し書き換えの完了を確認することを特徴とする請求項６に記載の管理サーバーシステム。
8. 前記振り分けサーバーは、前記ＤＮＳサーバーから返却されたＩＰアドレスをキャッシュする機能を有し、前記ＤＮＳサーバーに名前解決のリクエストを送信することなく、ホスト名に対応するキャッシュされたＩＰアドレスを読み込み、読み込まれたＩＰアドレスに対応するシステムに対し処理依頼を送信する振り分けサーバーであって、
   前記設定手段は、全ての前記ＤＮＳサーバーの書き換えが完了したことを確認した後、更に、前記振り分けサーバーが前記ＤＮＳサーバーに名前解決のリクエストを送信することでキャッシュしたＩＰアドレスを前記新たなシステムのＩＰアドレスに更新する処理が完了するまで待機し、その後、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とする請求項６または７に記載の管理サーバーシステム。
9. 前記設定手段は、前記振り分けサーバーが前記ＤＮＳサーバーに名前解決のリクエストを送信することでキャッシュしたＩＰアドレスを前記新たなシステムのＩＰアドレスに更新する処理が完了するまで待機し、待機した後にさらに一定時間の待機を行い、その後、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とする請求項８に記載の管理サーバーシステム。
10. 前記設定手段は、全ての前記ＤＮＳサーバーの書き換えが完了したことを確認した後、更に、書き換え前の前記ＩＰアドレスに対応するシステムにおいて、ＡＰＩリクエストの処理依頼を受信したことで出力するログを一定時間の間に出力されていないことを確認したことに応じて、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とする請求項６または７に記載の管理サーバーシステム。
11. クライアントと、名前解決のリクエストとともに受信したホスト名に対応するＩＰアドレスを返却するＤＮＳサーバーと、前記ＤＮＳサーバーから返却されたＩＰアドレスに対応するシステムに対し前記クライアントからのＨＴＭＬリクエストおよびＡＰＩリクエストの処理依頼を送信する振り分けサーバーと、管理サーバーシステムとから構成されるシステムで実行される方法であってあって、
    構築手段は、システム環境を構築するためのプログラムを情報処理装置に配備しシステムを構築し、
    設定手段は、前記ＤＮＳサーバーに登録されたホスト名であるＨＴＭＬリクエストに対応したホスト名およびＡＰＩリクエストに対応したホスト名の夫々のホスト名に対し、前記構築手段により構築されたシステムのＩＰアドレスを設定し、
    さらに、前記設定手段は、前記構築手段により新たなシステムが構築された後、前記ＡＰＩリクエストに対応したホスト名に設定されている現在のＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始め、前記振り分けサーバーの名前解決のリクエストに対応する全ての前記ＤＮＳサーバーの書き換えが完了したことを確認したことに応じて、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とする方法。
12. 名前解決のリクエストとともに受信したホスト名に対応するＩＰアドレスを返却するＤＮＳサーバーと、前記ＤＮＳサーバーから返却されたＩＰアドレスに対応するシステムに対しクライアントからのＨＴＭＬリクエストおよびＡＰＩリクエストの処理依頼を送信する振り分けサーバーと、通信することが可能な管理サーバーシステムにて実行されるプログラムであって、
    システム環境を構築するためのプログラムを情報処理装置に配備しシステムを構築する構築ステップと、
    前記ＤＮＳサーバーに登録されたホスト名であるＨＴＭＬリクエストに対応したホスト名およびＡＰＩリクエストに対応したホスト名の夫々のホスト名に対し、前記構築ステップにおいて構築されたシステムのＩＰアドレスを設定する設定ステップと、を含み、
    前記設定ステップは、前記構築ステップにおいて新たなシステムが構築された後、前記ＡＰＩリクエストに対応したホスト名に設定されている現在のＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始め、前記振り分けサーバーの名前解決のリクエストに対応する全ての前記ＤＮＳサーバーの書き換えが完了したことを確認したことに応じて、ＨＴＭＬリクエストに対応したホスト名に設定されているＩＰアドレスを前記新たなシステムのＩＰアドレスに書き換え始めることを特徴とするプログラム。

Images