JP2010122804A - Ｗｅｂサーバシステム - Google Patents

Abstract

【課題】２４時間継続してサービスの提供を行うＷｅｂサーバシステムにおいて、営業日の切り替わり等においてコンテンツをリリースする際に、セッションが切れることなくシームレスにアクセスを継続可能とする。
【解決手段】複数のＷｅｂサーバ３００およびコンテンツが格納された複数のボリュームからなるＷｅｂサーバシステムであって、前記複数のボリュームはＷｅｂサーバ３００からそれぞれアクセス可能であり、複数世代の前記コンテンツをそれぞれ格納しており、Ｗｅｂサーバ３００は、クライアント端末１００からのログインの日付毎に、前記コンテンツの参照先となる前記ボリュームを指定する定義ファイル３１１と、アクセス要求に含まれるクライアント端末１００からのログインの日付の情報に基づいて、定義ファイル３１１からコンテンツの参照先となるボリュームを特定してコンテンツを取得する振り分けエンジン３１０とを有する。
【選択図】図１

Description

本発明は、Ｗｅｂコンテンツによりユーザに対してサービスを提供するＷｅｂサーバシステムに関し、特に、２４時間継続してサービスの提供を行うＷｅｂサーバシステムに適用して有効な技術に関するものである。

近年、インターネットを経由したＷｅｂコンテンツによる金融取引や商品購入などのサービスが数多く提供されており、その中には原則として２４時間３６５日サービスの提供を継続するものも存在する。しかし、このようなシステムにおいてもサービスの機能拡張や修正等のため、Ｗｅｂサーバにおいてコンテンツの追加や入れ替えといったリリース作業を行う必要がある。

このとき、一般的には、深夜・早朝などのユーザからのアクセスの少ない時間帯において、金融機関等のサービス提供主体の営業日が切り替わる際などにメンテナンス時間を設けて、その間にコンテンツのリリース作業を行う。また、複数台のＷｅｂサーバで負荷分散を行うようなシステムの場合は、１台ずつ本番環境から切り離してリリース作業を行い、本番環境に切り戻すといった手順が取られる。

しかし、従来技術によるコンテンツのリリースにおいては、メンテナンス時間を設けるか否かに関わらず新しいコンテンツに切り替えるタイミングにおいてクライアント端末との間のセッションがいったん切れてしまうという問題がある。従って、コンテンツのリリース作業は深夜・早朝などのユーザからのアクセスの少ない時間帯に行われているが、ユーザの数が少ないとはいうものの、セッションが切れたユーザに対して再度ログインからの処理の繰り返しを強いるのはユーザにとっての利便性を損ねる。

そこで本発明の目的は、２４時間継続してサービスの提供を行うＷｅｂサーバシステムにおいて、営業日の切り替わり等においてコンテンツをリリースする際に、新たにログインしたユーザには新しいコンテンツを参照させると共に、既にログインしているユーザについては従前のコンテンツを継続して参照可能とすることにより、セッションが切れることなくシームレスにアクセスを継続可能とすることにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるＷｅｂサーバシステムは、クライアント端末に対してコンテンツによりサービスを提供する複数のＷｅｂサーバおよび前記コンテンツが格納された複数のボリュームからなり、前記複数のボリュームは、前記複数のＷｅｂサーバからそれぞれアクセス可能であり、リリースされる日付が異なる複数世代の前記コンテンツをそれぞれ格納しており、前記Ｗｅｂサーバは、前記クライアント端末からの前記Ｗｅｂサーバへのログインの日付毎に、対象の日付において使用する前記コンテンツの参照先となる前記ボリュームを指定する定義情報と、前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記アクセス要求に含まれる前記クライアント端末からの前記Ｗｅｂサーバへのログインの日付の情報に基づいて、前記定義情報から、前記日付において使用する第１のコンテンツの参照先となる第１のボリュームを特定して、前記第１のボリュームから前記第１のコンテンツを取得する振り分け部とを有することを特徴とするものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、複数世代のコンテンツに対してユーザのログインのタイミングによりアクセス先を振り分けることによって、営業日の切り替わり等においてコンテンツをリリースする際に、新たにログインしたユーザには新しいコンテンツを参照させると共に、既にログインしているユーザについては従前のコンテンツを継続して参照させることが可能となり、セッションが切れることなくシームレスにアクセスを継続することが可能となる。また、コンテンツのリリース作業や不具合時の戻し作業をスムーズに行うことが可能となる。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。

＜概要＞
図９は、従来技術によるＷｅｂサーバシステムの構成およびコンテンツのリリース手順の概要の例を示した図である。図９において、上段はコンテンツリリース前の営業日「2008/08/31」の状況を示した図であり、下段はコンテンツリリース後の営業日「2008/09/01」の状況を示した図である。

両図において、Ｗｅｂサーバシステムはローカルディスク４００を有する複数のＷｅｂサーバ３００からなり、これらに対してインターネット等のネットワーク２００を経由して複数のクライアント端末１００が接続されている構成となっている。なお、複数のＷｅｂサーバ３００は、それぞれ同じサービスを提供するサーバであり、それぞれのローカルディスク４００には同じコンテンツが格納されている。これら複数のＷｅｂサーバ３００に対して、例えば、図示しない負荷分散サーバ等によってクライアント端末１００からのアクセス要求を負荷分散して振り分けることにより、大量の処理を可能とし、かつシステムの可用性を高める。

上段の図では各Ｗｅｂサーバ３００のローカルディスク４００には全て営業日「2008/08/31」まで有効なコンテンツが格納されており、各Ｗｅｂサーバ３００は、クライアント端末１００からのアクセス要求に対してそれぞれのローカルディスク４００からコンテンツを参照してサービスの提供を行っている。

ここで、翌営業日「2008/09/01」から有効となるコンテンツをリリースする際には、営業日が切り替わる際のメンテナンス時間などを利用して全てのローカルディスク４００に対して営業日「2008/09/01」から有効となるコンテンツを配布する。これにより、下段の図に示すように、営業日「2008/09/01」からは、各Ｗｅｂサーバ３００は、クライアント端末１００からのアクセス要求に対してそれぞれのローカルディスク４００から新しい世代のコンテンツを参照してサービスの提供を行うようになる。

このようなコンテンツのリリース方法をとる場合、複数のＷｅｂサーバ３００のローカルディスク４００に対してそれぞれコンテンツを配布もしくは書き換えしなければならないため、作業手順としては、メンテナンス時間を設けてサービスを全面的に停止してコンテンツを配布するという手順や、サービスを継続しつつ、各Ｗｅｂサーバ３００を順次本番環境から切り離し、コンテンツを配布した後に本番環境に切り戻すといった手順となる。このとき、コンテンツのリリースのタイミングで既にログイン中のクライアント端末１００との間のセッションがいったん切れてしまい、クライアント端末１００からユーザが再度ログインしなければならないという問題が生ずる。

また、Ｗｅｂサーバ３００の台数が数百台など多数になった場合はリリース作業に長時間を要する。また、リリース後にコンテンツに不具合が発見された場合、その戻し作業にも長時間を要し、システムの不具合も長時間継続されることとなる。また、サービスを継続しつつ行う場合は、リリース作業中に各Ｗｅｂサーバ３００の間で複数世代のコンテンツが混在し、リンク不正などが発生する可能性がある。

そこで、本発明の実施の形態であるＷｅｂサーバシステムでは、コンテンツの格納場所を各Ｗｅｂサーバ３００のローカルディスク４００ではなく、ネットワーク経由で各Ｗｅｂサーバ３００がアクセス可能な共有ディスクに格納して参照する構成とする。また、共有ディスクでは本番で使用しているコンテンツとリリースされるコンテンツの複数世代がそれぞれ格納されるボリュームを有し、リリースのタイミングやクライアント端末１００からのログインのタイミングなどによりコンテンツの参照先のボリュームを切り替える構成を有する。

＜実施の形態１＞
以下に、本発明の実施の形態１であるＷｅｂサーバシステムについて説明する。図２は、本実施の形態のＷｅｂサーバシステムの構成およびコンテンツのリリース手順の概要の例を示した図である。図２において、上段はコンテンツリリース前の営業日「2008/08/31」の状況を示した図であり、下段はコンテンツリリース後の営業日「2008/09/01」の状況を示した図である。

両図においては、図９に示した従来技術によるＷｅｂサーバシステムの構成と比較して、コンテンツの格納場所が各Ｗｅｂサーバ３００のローカルディスク４００ではなく、ネットワーク経由で各Ｗｅｂサーバ３００からそれぞれアクセスすることが可能なボリュームＳ１（５０１）、Ｓ２（５０２）になっている点が異なっている。なお、ボリュームＳ１（５０１）、Ｓ２（５０２）には、例えばファイルサーバやＮＡＳ（Network Attached Storage）などを用いることができる。また、各ボリュームは物理的に別のディスク上に構成されていてもよいし、同一のディスク上の別の領域として構成されていてもよい。

上段の図では、ボリュームＳ１（５０１）には営業日「2008/08/31」まで有効なコンテンツが格納されており、各Ｗｅｂサーバ３００は、クライアント端末１００からのアクセス要求に対してボリュームＳ１（５０１）からコンテンツを参照してサービスの提供を行っている。

ここで、翌営業日「2008/09/01」から有効となるコンテンツをリリースする場合、その準備としてボリュームＳ２（５０２）に営業日「2008/09/01」から有効となるコンテンツを格納しておく。このとき、事前にボリュームＳ１（５０１）とボリュームＳ２（５０２）の内容を同期させてから格納するようにしてもよい。

コンテンツの実際のリリースは、営業日の切り替わり等のタイミングで、各Ｗｅｂサーバ３００がコンテンツの格納先として参照するボリュームをボリュームＳ１（５０１）からボリュームＳ２（５０２）に変更して切り替える。これにより、下段の図に示すように、営業日「2008/09/01」からは、各Ｗｅｂサーバ３００は、クライアント端末１００からのアクセス要求に対してボリュームＳ２（５０２）から新しいコンテンツを参照してサービスの提供を行う。

各Ｗｅｂサーバ３００において参照するボリュームを切り替えるには、ボリュームを仮想ドライブとして参照している場合は、仮想ドライブの実体であるボリュームをコマンド等により切り替えることで実現することができる。例えば、Ｗｉｎｄｏｗｓ（登録商標）サーバの場合は、ボリュームＳ１（５０１）およびボリュームＳ２（５０２）の共有名を切り替えることで、各Ｗｅｂサーバ３００からは同一の共有名で異なるボリュームにアクセスすることが可能となる。

リリースしたコンテンツに不具合が発見された場合は、各Ｗｅｂサーバ３００がコンテンツの格納先として参照するボリュームをボリュームＳ２（５０２）からボリュームＳ１（５０１）に変更して切り替えることにより瞬時に戻し作業が完了する。

このように、本実施の形態のＷｅｂサーバシステムでは、２４時間継続してサービスの提供を行いつつ複数台のＷｅｂサーバ３００に使用されるコンテンツのリリースをする際に、メンテナンス時間を設ける必要がなく、また、各Ｗｅｂサーバ３００を順次本番環境から切り離し、コンテンツを配布もしくは書き換えした後に本番環境に切り戻すといった手順を必要とせず、クライアント端末１００との間のセッションを維持したままコンテンツのリリースを行うことが可能となる。また、リリースおよびその戻しを整合性を保ちつつ瞬時に行うことが可能となる。

＜実施の形態２＞
以下に、本発明の実施の形態２であるＷｅｂサーバシステムについて説明する。実施の形態１で示したＷｅｂサーバシステムでは、各Ｗｅｂサーバが参照するコンテンツの格納場所を新旧二世代の間で一斉に切り替える構成をとっている。一方、本実施の形態のＷｅｂサーバシステムでは、二世代以上の複数世代のコンテンツを保持することが可能であり、さらに、コンテンツのリリース時に既にログインしているユーザについては、その時点で参照していた旧世代のコンテンツを継続して参照可能としつつ、新たにログインしてきたユーザについては新しい世代のコンテンツを参照可能とするものである。

［コンテンツリリース時のアクセスの継続］
図１は、本実施の形態のＷｅｂサーバシステムの構成およびコンテンツのリリース手順の概要の例を示した図である。図１において、上段はコンテンツリリース前の営業日「2008/08/31」の状況を示した図であり、下段はコンテンツリリース後の営業日「2008/09/01」の状況を示した図である。

両図においては、図２に示した実施の形態１のＷｅｂサーバシステムの構成と比較して、Ｗｅｂサーバ３００が振り分けエンジン３１０および定義ファイル３１１を有し、また、ボリュームを二世代以上の複数世代有している点が異なっている。さらに、各クライアント端末１００のＷｅｂブラウザには、Ｗｅｂサーバ３００にログインした営業日を示すＣｏｏｋｉｅが設定されている。

なお、図中では振り分けエンジン３１０および定義ファイル３１１を便宜上１つだけ記載しているが、振り分けエンジン３１０は、各Ｗｅｂサーバ３００上でそれぞれ個別に稼働するプログラムとして実装されるものである。また、定義ファイル３１１は、各Ｗｅｂサーバ３００上でそれぞれ個別に保持していてもよいし、共有ディスクなどに各Ｗｅｂサーバ３００が共有する形で保持していてもよい。

図１において、ボリュームは、営業日「2008/08/30」まで有効なコンテンツを格納しているボリュームＳ１（６０１）、営業日「2008/08/31」に有効なコンテンツを格納しているボリュームＳ２（６０２）、営業日「2008/09/01」に有効となるコンテンツを格納しているボリュームＳ３（６０３）、営業日「2008/09/02」に有効となるコンテンツを格納しているボリュームＳ４（６０４）を有している。さらに多数の世代のコンテンツを有していてもよい。

なお、実施の形態１のＷｅｂサーバシステムと同様に、ボリュームとしては、例えばファイルサーバやＮＡＳなどを用いることができる。また、各ボリュームは物理的に別のディスク上に構成されていてもよいし、同一のディスク上の別の領域として構成されていてもよい。

上段の図では、営業日「2008/08/31」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対して、Ｗｅｂサーバ３００では、振り分けエンジン３１０によってＣｏｏｋｉｅに設定されたログイン営業日の情報を取得する。振り分けエンジン３１０が有する定義ファイル３１１には、クライアント端末１００からのＷｅｂサーバ３００へのログインの日付（営業日）毎に、コンテンツの参照先となるボリュームを指定する情報が設定されている。

振り分けエンジン３１０は、Ｃｏｏｋｉｅから取得したログイン営業日の情報をもとに定義ファイル３１１からアクセスすべきボリュームの情報（図１の例では「Ｓ２」）を取得し、コンテンツの参照先のボリュームをボリュームＳ２（６０２）に設定して、ボリュームＳ２（６０２）から営業日「2008/08/31」に有効なコンテンツを取得する。

ここで、翌営業日「2008/09/01」から有効となるコンテンツをリリースする場合、その準備としてボリュームＳ３（６０３）に営業日「2008/09/01」から有効となるコンテンツをあらかじめ格納しておく。なお、営業日「2008/09/02」など、さらに未来の日付のコンテンツをあらかじめ準備しておいても構わない。

これにより、例えば、営業日が「2008/08/31」から「2008/09/01」に変更されると、下段の図に示すように、各Ｗｅｂサーバ３００では、営業日「2008/09/01」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対して、振り分けエンジン３１０により、定義ファイル３１１を参照してコンテンツの参照先のボリュームをボリュームＳ３（６０３）に設定し、ボリュームＳ３（６０３）から営業日「2008/09/01」から有効となる新しい世代のコンテンツを取得する。

このとき、営業日「2008/08/31」から既にログインしていたクライアント端末１００からのアクセスについては、振り分けエンジン３１０によりコンテンツの参照先のボリュームがボリュームＳ２（６０２）に設定される。従って、ボリュームＳ２（６０２）から営業日「2008/08/31」に有効なコンテンツを参照し、セッションが切れることなく継続して以前と同様のサービスを提供することが可能である。

なお、このとき、ボリュームＳ２（６０２）のコンテンツを継続して参照するのではなく、営業日「2008/09/01」付の新しいコンテンツがリリースされたことをクライアント端末１００のユーザに通知する画面をＷｅｂサーバ３００から提示し、ユーザがどちらのコンテンツにアクセスするかを自発的に選択できるようにして、新しい世代のコンテンツに誘導するようにしてもよい。

このように、クライアント端末１００から見たアクセス先のコンテンツは同じであっても、ログイン営業日によって参照先のボリュームを振り分けて別の世代のコンテンツを参照することにより、コンテンツのリリース時においてシームレスにアクセスを継続することが可能となる。また、あらかじめリリース対象のコンテンツを格納したボリュームを準備し、定義ファイル３１１に有効となる営業日の設定をしておくことで、夜間等のリリース作業に伴う作業負荷を軽減し、スムーズなリリースを行うことが可能となる。

なお、振り分けエンジン３１０については、例えば、ＡｐａｃｈｅなどのＷｅｂサーバソフトウェアにおいて、Ｗｅｂサーバ３００上でコンテンツを参照する際のルートディレクトリが設定されるDocumentRootの設定値と、クライアント端末１００からのアクセス要求のＵＲＬ（Uniform Resource Locator）とからコンテンツの実際の格納場所の物理パスを生成してコンテンツを取得する処理を行う部分にプログラムとして組み込んで実装することができる。

具体的には、例えば、ＷｅｂサーバソフトウェアにおいてDocumentRootの設定値とアクセス要求のＵＲＬとからコンテンツの格納場所の物理パスを生成する処理を行う部分に、クライアント端末１００からの要求に含まれるＣｏｏｋｉｅのログイン営業日の情報に基づいて、定義ファイル３１１から当該営業日についての参照先のボリュームの情報を取得し、当該ボリュームの情報に基づいてコンテンツの格納場所の物理パスを新たに生成する処理を行うプログラムを組み込むことによって実現することができる。

［定義ファイルの更新による参照先変更］
図３は、本実施の形態のＷｅｂサーバシステムの構成および定義ファイル３１１を更新した場合の処理の概要の例を示した図である。図３において、上段は定義ファイル３１１の更新前の営業日「2008/09/01」の状況を示した図であり、下段は定義ファイル３１１の更新後の営業日「2008/09/02」の状況を示した図である。

上段の図では、営業日「2008/08/31」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対して、Ｗｅｂサーバ３００では、振り分けエンジン３１０によってコンテンツの参照先のボリュームをボリュームＳ２（６０２）に設定して、ボリュームＳ２（６０２）からコンテンツを取得する。同様に、営業日「2008/09/01」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対しては、ボリュームＳ３（６０３）からコンテンツを取得する。

ここで、営業日の切り替わり等のタイミングで定義ファイル３１１の内容を下段の図に示すように更新すると、営業日「2008/08/31」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対しては、コンテンツの参照先のボリュームが「−」と設定されているため、アクセス不可である旨をクライアント端末１００のユーザに通知する画面をＷｅｂサーバ３００から提示してアクセスを拒否することができる。これにより、新しいコンテンツのリリースから一定期間以上経過してログインを継続しているユーザについては、強制的にアクセスを拒否して新しいコンテンツに誘導することができる。

また、営業日「2008/09/01」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対しては、継続してボリュームＳ３（６０３）からコンテンツを取得する。また、営業日「2008/09/02」に新たにログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対しては、Ｗｅｂサーバ３００では、振り分けエンジン３１０によってコンテンツの参照先のボリュームを新たに定義されているボリュームＳ４（６０４）に設定して、ボリュームＳ４（６０４）からコンテンツを取得する。

このように、定義ファイル３１１の内容を更新することで、コンテンツの参照先のボリュームの設定内容を変更することが可能である。

［リリース戻し］
図４は、本実施の形態のＷｅｂサーバシステムの構成および障害時のリリース戻しの概要の例を示した図である。図４において、上段は営業日「2008/09/02」におけるリリース戻し前の状況を示した図であり、下段は営業日「2008/09/02」におけるリリース戻し後の状況を示した図である。

上段の図では、営業日「2008/09/02」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対して、Ｗｅｂサーバ３００では、振り分けエンジン３１０によってコンテンツの参照先のボリュームをボリュームＳ４（６０４）に設定して、ボリュームＳ４（６０４）からコンテンツを取得する。

ここで、当該コンテンツに何らかの不具合が発見されたものとすると、緊急のリリース戻しとして、定義ファイル３１１の内容を下段の図のように更新する。ここでは、営業日「2008/09/02」にログインしたユーザからのアクセスに対してリリース前の旧世代のコンテンツが格納されているボリュームＳ３（６０３）からコンテンツを取得するように定義ファイル３１１を更新する。これにより、緊急のリリース戻しを整合性をもって瞬時に行うことが可能となる。

このように、本実施の形態のＷｅｂサーバシステムでは、複数世代のコンテンツに対してユーザのログインのタイミングにより参照先を振り分けることによって、コンテンツをリリースする際に、営業日の切り替わりにおいて、新たにログインしたユーザには新しい世代のコンテンツを参照させると共に、既にログインしているユーザについては旧世代のコンテンツを継続して参照させることが可能となる。これにより、既にログインしているユーザについては、セッションが切れることなくシームレスにアクセスを継続することが可能となる。また、コンテンツのリリース作業や不具合時の戻し作業を効率的に行うことが可能となる。

なお、実施の形態１に示したＷｅｂサーバシステムにおいて、本実施の形態のＷｅｂサーバシステムにおける振り分けエンジン３１０および定義ファイル３１１によるコンテンツの参照先のボリュームを切り替える手段を適用して、ユーザのログインのタイミングに関わらず一斉にコンテンツの参照先のボリュームを切り替えるようにすることも可能である。

また、本実施の形態では、ユーザがログインした営業日を特定する手段としてＣｏｏｋｉｅを用いているが、Ｃｏｏｋｉｅの書式等については本実施の形態で示した例に限らない。また、Ｃｏｏｋｉｅに限らず他の手段によってユーザがログインした営業日を特定できるようにしてもよい。

＜実施の形態３＞
以下に、本発明の実施の形態３であるＷｅｂサーバシステムについて説明する。本実施の形態のＷｅｂサーバシステムは、実施の形態２で示したＷｅｂサーバシステムの応用例として、Ｗｅｂサーバ３００において、振り分けエンジン３１０および定義ファイル３１１によって、ユーザがログインした時間帯毎にコンテンツの参照先のボリュームを振り分けて、参照するコンテンツを変更することを可能とするものである。

これにより、例えば、「１０：００〜１２：００にログインしたユーザに限り、商品購入時の獲得ポイントを２倍にするキャンペーンを利用可能とする」といったことや、「１２：００から１４：００にログインしたユーザに限り、前場のマーケットについての分析レポートを参照可能とする」といったようなタイムバーゲンのサービスが容易に提供可能となる。

図５は、本実施の形態のＷｅｂサーバシステムの構成およびタイムバーゲン処理の概要の例を示した図である。Ｗｅｂサーバ３００の定義ファイル３１１の定義内容は、ログイン営業日毎ではなくログイン時間帯毎に、コンテンツの参照先となるボリュームを指定する情報が設定されている。

また、ボリュームは、時間帯「8/31 10:00-12:00」に有効なコンテンツを格納しているボリュームＳ１（７０１）、時間帯「8/31 12:00-14:00」に有効なコンテンツを格納しているボリュームＳ２（７０２）、時間帯「8/31 14:00-16:00」に有効なコンテンツを格納しているボリュームＳ３（７０３）、時間帯「8/31 16:00-」に有効なコンテンツを格納しているボリュームＳ４（７０４）を有している。

各Ｗｅｂサーバ３００では、例えば、「8/31 11:00」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対して、振り分けエンジン３１０が定義ファイル３１１を参照して、コンテンツの参照先のボリュームをボリュームＳ１（７０１）に設定して、ボリュームＳ１（７０１）から時間帯「8/31 10:00-12:00」に有効なコンテンツを取得する。

同様に、「8/31 15:00」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対して、振り分けエンジン３１０が定義ファイル３１１を参照して、コンテンツの参照先のボリュームをボリュームＳ３（７０３）に設定して、ボリュームＳ３（７０３）から時間帯「8/31 14:00-16:00」に有効なコンテンツを取得する。

また、「8/31 17:00」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対して、振り分けエンジン３１０が定義ファイル３１１を参照して、コンテンツの参照先のボリュームをボリュームＳ４（７０４）に設定して、ボリュームＳ４（７０４）から時間帯「8/31 16:00-」に有効なコンテンツを取得する。

このように、本実施の形態のＷｅｂサーバシステムでは、定義ファイル３１１の定義内容を時間帯で区切り、時間帯毎に用意された複数世代のコンテンツに対してユーザのログインのタイミングにより参照先を振り分けることによって、短いスパンで表示されるコンテンツを変更してタイムバーゲンのようなサービスを提供することが可能となる。

＜実施の形態４＞
以下に、本発明の実施の形態４であるＷｅｂサーバシステムについて説明する。本実施の形態のＷｅｂサーバシステムは、実施の形態２で示したＷｅｂサーバシステムの応用例として、Ｗｅｂサーバ３００において、定義ファイル３１１に特殊な定義を設定することにより、一般のユーザが通常はアクセスすることができない未来日付のコンテンツにアクセス可能とするものである。

これにより、例えば、ある特定のユーザに限り、新商品を試験的に利用できるようなモニターとして正式リリース前の新しい世代のコンテンツにアクセス可能としたり、コンテンツのリリース作業の一環として、リリース確認用の端末から正式リリース前の新しい世代のコンテンツについて本番環境で事前に動作確認したりすることが可能となる。

図６は、本実施の形態のＷｅｂサーバシステムの構成およびモニターアクセス処理の概要の例を示した図である。図６では、営業日「2008/09/01」にログインしたことを示すＣｏｏｋｉｅ（「20080901」）を有するクライアント端末１００からのアクセス要求に対して、Ｗｅｂサーバ３００では、振り分けエンジン３１０によってコンテンツの参照先のボリュームをボリュームＳ３（６０３）に設定して、ボリュームＳ２（６０２）からコンテンツを取得する。

一方、営業日「2008/09/01」にモニターユーザとしてログインしたことを示すＣｏｏｋｉｅ（「M20080901」）を有するクライアント端末１００からのアクセス要求に対して、Ｗｅｂサーバ３００では、振り分けエンジン３１０によってコンテンツの参照先のボリュームをボリュームＳ４（６０４）に設定して、モニターユーザ向けとして、ボリュームＳ４（６０４）から正式リリース前の営業日「2008/09/02」から有効となるコンテンツを取得する。

図７は、本実施の形態のＷｅｂサーバシステムの別の構成およびコンテンツ事前動作確認処理の概要の例を示した図である。図７では、定義ファイル３１１とは別に、リリースされたコンテンツの確認用として確認用定義ファイル３１２を有している。営業日「2008/09/01」において、営業日「2008/09/02」にリリースされるコンテンツについて事前に動作確認するためにログインしたことを示すＣｏｏｋｉｅ（「T20080902」）を有する事前確認用端末８００からのアクセス要求に対して、Ｗｅｂサーバ３００では、振り分けエンジン３１０によってコンテンツの参照先のボリュームをボリュームＳ４（６０４）に設定して、ボリュームＳ４（６０４）から正式リリース前の営業日「2008/09/02」から有効となるコンテンツを取得する。

これにより、事前確認用端末８００では、営業日「2008/09/01」において、営業日「2008/09/02」から有効となるコンテンツの本番環境での事前の動作確認を行うことが可能となる。このとき、営業日「2008/09/01」で有効なコンテンツが格納されているボリュームＳ３（６０３）と、確認対象の営業日「2008/09/02」から有効となるコンテンツが格納されているボリュームＳ４（６０４）とは物理的に異なるファイルシステムである。従って、営業日「2008/09/01」における本番環境でのサービスに影響を与えることなく、リリースされるコンテンツの動作確認を行うことが可能となる。

なお、図７に示す構成では、確認用定義ファイル３１２を定義ファイル３１１とは別に設けているが、図６に示す構成と同様に、確認用定義ファイル３１２の定義内容を定義ファイル３１１に直接定義するようにしてもよい。

このように、本実施の形態のＷｅｂサーバシステムでは、定義ファイル３１１に、例えばモニターユーザによるアクセスの場合や、リリースコンテンツの事前動作確認のためのアクセスの場合などを示す特殊な定義を設定することにより、一般のユーザが通常はアクセスすることができない未来日付にリリースされるコンテンツに対して、本番環境での通常のアクセスに影響を与えることなくアクセスすることが可能となる。

＜実施の形態５＞
以下に、本発明の実施の形態５であるＷｅｂサーバシステムについて説明する。本実施の形態のＷｅｂサーバシステムは、実施の形態２で示したＷｅｂサーバシステムに対して、保持するコンテンツの世代数が大きく増加した場合に、仮想ボリュームを利用して物理ボリュームを有効利用するものである。

実施の形態２で示したＷｅｂサーバシステムでは、複数世代のコンテンツを保持するボリュームに対して、ユーザのログインのタイミングにより参照先を振り分けることを可能とする。しかし、先々の未来日付におけるコンテンツのリリースまで考慮して、用意するコンテンツの世代数を多くすればするほど、各世代のコンテンツを格納するボリューム（物理ボリューム）も多く必要となり莫大なコストがかかることとなる。

そこで、本実施の形態のＷｅｂサーバシステムでは、物理ボリュームとしては１つもしくは少数のボリュームのみ有し、当該物理ボリュームに格納されているコンテンツよりも未来日付に有効となる複数世代のコンテンツについては、各日付毎の差分データのみを複数の仮想ボリュームにそれぞれ保持する構成とする。

図８は、本実施の形態のＷｅｂサーバシステムの構成およびコンテンツの参照手順の概要の例を示した図である。図８では、図１に示した実施の形態２のＷｅｂサーバシステムの構成と比較して、Ｗｅｂサーバ３００の振り分けエンジン３１０が未来検索エンジン３１３および差分管理ＤＢ３１４を有する点が異なっている。

また、物理ボリュームとしてはボリュームＳ１（６０１）のみを有し、さらに仮想ボリュームとして、ボリュームＳ１（６０１）と同じ内容のデータが格納されている仮想ボリュームＳ１’（９０１）、および未来日付にリリースされて有効となるコンテンツの差分情報のみがそれぞれ格納されている仮想ボリュームＶＳ２（９０２）〜仮想ボリュームＶＳｎ（９０６）、および仮想ボリュームＶＳｘ（９０７）を有する点が異なっている。

なお、図８では、営業日が「2008/09/01」であり、営業日「2008/08/31」まで有効なコンテンツの全体がボリュームＳ１（６０１）に格納されており、営業日「2008/08/31」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対しては、定義ファイル３１１により、振り分けエンジン３１０がボリュームＳ１（６０１）からコンテンツを取得する設定となっている状態を示している。ここで、定義ファイル３１１では、さらに、ユーザが営業日「2008/09/01」以降の未来日付でログインしている場合は一律に未来検索エンジン３１３による処理を行うように設定がされている（図８の例では「ＳＦ」という設定）。

例えば、営業日「2008/09/01」にログインしたことを示すＣｏｏｋｉｅを有するクライアント端末１００からのアクセス要求に対して、Ｗｅｂサーバ３００では定義ファイル３１１の設定に基づいて未来検索エンジン３１３による処理が行われる。未来検索エンジン３１３では、例えば、差分管理ＤＢなどを参照して、営業日「2008/09/01」から有効となるコンテンツの差分情報が格納されている仮想ボリュームの情報を取得する。この情報に基づいて、ベースとなるコンテンツの全体分が格納されている仮想ボリュームＳ１’（９０１）および営業日「2008/09/01」についての差分情報が格納されている仮想ボリュームＶＳ２（９０２）にアクセスして、営業日「2008/09/01」から有効となるコンテンツを取得する。

また、例えば、営業日「2008/09/01」において、営業日「2008/12/25」におけるコンテンツについて事前に動作確認するためにログインしたことを示すＣｏｏｋｉｅ（「T20081225」）を有する事前確認用端末８００からのアクセス要求に対しても同様に、Ｗｅｂサーバ３００では、定義ファイル３１１の設定に基づいて未来検索エンジン３１３による処理が行われる。

未来検索エンジン３１３では、差分管理ＤＢなどを参照して営業日「2008/12/25」から有効となるコンテンツの差分情報が格納されている仮想ボリュームの情報を取得する。この情報に基づいて、ベースとなるコンテンツの全体分が格納されている仮想ボリュームＳ１’（９０１）および営業日「2008/12/25」についての差分情報が格納されている仮想ボリュームＶＳｎ（９０６）にアクセスして、営業日「2008/12/25」から有効となるコンテンツを取得する。

このとき、仮想ボリュームＶＳｎ（９０６）に差分情報が格納されていなかった場合は、当該営業日にリリース対象のコンテンツが無いものとして、差分情報が見つかるまで順次日付を遡って仮想ボリュームを参照していく。全ての仮想ボリュームに差分情報が格納されていなかった場合は、ベースとなるコンテンツの全体分が格納されている仮想ボリュームＳ１’（９０１）からコンテンツを取得することになる。

このように、本実施の形態のＷｅｂサーバシステムでは、物理ボリュームとしては１つもしくは少数のボリュームのみ有し、当該物理ボリュームに格納されているコンテンツよりも未来日付に有効となる複数世代のコンテンツについては、当該未来日付にリリースされる差分データのみを仮想ボリュームにそれぞれ保持する構成とすることで、少ない物理ボリュームで多くの世代のコンテンツを保持し、物理ボリュームを有効利用することが可能となる。

これにより、例えば、先々の未来日付まで対応したコンテンツの事前リリースや、細かな時間帯でコンテンツを切り替えるタイムバーゲンなどによって、保持するコンテンツの世代数が大きく増加した場合であっても、物理ボリュームを多数要することなく、ユーザのログインしたタイミングによって参照するコンテンツを適切に切り替えて、シームレスにアクセスを継続してサービスを提供することが可能となる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、Ｗｅｂコンテンツによりユーザに対してサービスを提供するＷｅｂサーバシステムに利用可能である。

本発明の実施の形態２におけるＷｅｂサーバシステムの構成およびコンテンツのリリース手順の概要の例を示した図である。 本発明の実施の形態１におけるＷｅｂサーバシステムの構成およびコンテンツのリリース手順の概要の例を示した図である。 本発明の実施の形態２におけるＷｅｂサーバシステムの構成および定義ファイルを更新した場合の処理の概要の例を示した図である。 本発明の実施の形態２におけるＷｅｂサーバシステムの構成および障害時のリリース戻しの概要の例を示した図である。 本発明の実施の形態３におけるＷｅｂサーバシステムの構成およびタイムバーゲン処理の概要の例を示した図である。 本発明の実施の形態４におけるＷｅｂサーバシステムの構成およびモニターアクセス処理の概要の例を示した図である。 本発明の実施の形態４におけるＷｅｂサーバシステムの別の構成およびコンテンツ事前動作確認処理の概要の例を示した図である。 本発明の実施の形態５におけるＷｅｂサーバシステムの構成およびコンテンツの参照手順の概要の例を示した図である。 従来技術によるＷｅｂサーバシステムの構成およびコンテンツのリリース手順の概要の例を示した図である。

符号の説明

１００…クライアント端末、２００…ネットワーク、３００…Ｗｅｂサーバ、３１０…振り分けエンジン、３１１…定義ファイル、３１２…確認用定義ファイル、３１３…未来検索エンジン、３１４…差分管理ＤＢ、
４００…ローカルディスク、
５０１…ボリュームＳ１、５０２…ボリュームＳ２、
６０１…ボリュームＳ１、６０２…ボリュームＳ２、６０３…ボリュームＳ３、６０４…ボリュームＳ４、
７０１…ボリュームＳ１、７０２…ボリュームＳ２、７０３…ボリュームＳ３、７０４…ボリュームＳ４、
８００…確認用端末、
９０１…仮想ボリュームＳ１’、９０２…仮想ボリュームＶＳ２、９０３…仮想ボリュームＶＳ３、９０４…仮想ボリュームＶＳ４、９０５…仮想ボリュームＶＳ５、９０６…仮想ボリュームＶＳｎ、９０７…仮想ボリュームＶＳｘ。

Claims (6)

1. クライアント端末に対してコンテンツによりサービスを提供する複数のＷｅｂサーバおよび前記コンテンツが格納された複数のボリュームからなるＷｅｂサーバシステムであって、
   前記複数のボリュームは、前記複数のＷｅｂサーバからそれぞれアクセス可能であり、リリースされる日付が異なる複数世代の前記コンテンツをそれぞれ格納しており、
   前記Ｗｅｂサーバは、前記クライアント端末からの前記Ｗｅｂサーバへのログインの日付毎に、対象の日付において使用する前記コンテンツの参照先となる前記ボリュームを指定する定義情報と、
   前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記アクセス要求に含まれる前記クライアント端末からの前記Ｗｅｂサーバへのログインの日付の情報に基づいて、前記定義情報から、前記日付において使用する第１のコンテンツの参照先となる第１のボリュームを特定して、前記第１のボリュームから前記第１のコンテンツを取得する振り分け部とを有することを特徴とするＷｅｂサーバシステム。
2. 請求項１に記載のＷｅｂサーバシステムにおいて、
   前記定義情報には、前記クライアント端末からの前記Ｗｅｂサーバへのログインの時間帯毎に、対象の時間帯において使用する前記コンテンツの参照先となる前記ボリュームが指定され、
   前記振り分け部は、前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記アクセス要求に含まれる前記クライアント端末からの前記Ｗｅｂサーバへのログインの時刻の情報に基づいて、前記定義情報から、前記時刻において使用する第２のコンテンツの参照先となる第２のボリュームを特定して、前記第２のボリュームから前記第２のコンテンツを取得することを特徴とするＷｅｂサーバシステム。
3. 請求項１または２に記載のＷｅｂサーバシステムにおいて、
   前記定義情報には、所定の期間以上過去の日付もしくは時刻において使用する前記コンテンツの参照先となる前記ボリュームが存在しない旨の指定を含み、
   前記振り分け部は、前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記アクセス要求に含まれる前記クライアント端末からの前記Ｗｅｂサーバへのログインの日付もしくは時刻の情報が前記所定の期間以上過去の日付もしくは時刻である場合は、アクセスを拒否することを特徴とするＷｅｂサーバシステム。
4. 請求項１〜３のいずれか１項に記載のＷｅｂサーバシステムにおいて、
   前記定義情報には、前記クライアント端末からの前記Ｗｅｂサーバへのアクセス要求が特定のものである場合に、未来の日付においてリリースされる第３のコンテンツが格納されている第３のボリュームを参照先とする指定を含み、
   前記振り分け部は、前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記アクセス要求に、前記アクセス要求が特定のものであることを示す情報が含まれている場合は、前記定義情報に基づいて、前記第３のコンテンツの参照先となる前記第３のボリュームを特定して、前記第３のボリュームから前記第３のコンテンツを取得することを特徴とするＷｅｂサーバシステム。
5. 請求項４に記載のＷｅｂサーバシステムにおいて、
   前記クライアント端末からの前記Ｗｅｂサーバへのアクセス要求が、前記第３のコンテンツに対する事前の動作確認の要求であり、前記クライアント端末が前記動作確認のための端末であることを特徴とするＷｅｂサーバシステム。
6. 請求項１〜５のいずれか１項に記載のＷｅｂサーバシステムにおいて、
   前記複数のボリュームは、特定の日付において使用される第４のコンテンツの全体を格納する物理ボリュームと、前記特定の日付より未来の日付においてそれぞれリリースされる複数世代の前記コンテンツについての、前記第４のコンテンツからの前記各日付における差分情報をそれぞれ格納する複数の仮想ボリュームとからなり、
   前記定義情報には、前記クライアント端末からの前記Ｗｅｂサーバへのアクセス要求が前記特定の日付より未来の日付である場合に、対象の日付において使用する前記コンテンツを取得するための未来検索処理を行うための指定を含み、
   前記振り分け部は、前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記アクセス要求に含まれる前記クライアント端末からの前記Ｗｅｂサーバへのログインの日付の情報が前記特定の日付より未来の日付である場合は、前記定義情報に基づいて、前記物理ボリュームから取得した前記第４のコンテンツと、前記仮想ボリュームから取得した前記未来の日付から前記特定の日付までのそれぞれの前記差分情報とから、前記未来の日付において使用する第５のコンテンツを取得する前記未来検索処理を行うことを特徴とするＷｅｂサーバシステム。

Images