(57)【要約】【課題】システムが高負荷となった場合であっても、新たにログインしてきたユーザがコンテンツを参照できないという状況を回避し、サービスの提供を行うことを可能とするＷｅｂサーバシステムを提供する。【解決手段】Ｗｅｂサーバ３００およびコンテンツが格納されたボリュームからなるＷｅｂサーバシステムであって、前記ボリュームはリッチコンテンツを格納しているボリュームＳ１（４０１）とプアコンテンツを格納しているボリュームＳ２（４０２）とからなり、Ｗｅｂサーバ３００は、Ｗｅｂサーバシステムの負荷により使用するコンテンツを判断するコンテンツ判断エンジン３１１と、コンテンツ判断エンジン３１１によって判断されたコンテンツの種類の情報に基づいてボリュームＳ１（４０１）またはＳ２（４０２）からコンテンツを取得する振り分けエンジン３１０とを有する。【選択図】図１
2010123015.tif 000002
【特許請求の範囲】
【請求項１】
クライアント端末に対してコンテンツによりサービスを提供する複数のＷｅｂサーバおよび前記コンテンツが格納された複数のボリュームからなるＷｅｂサーバシステムであって、
前記複数のボリュームは、前記複数のＷｅｂサーバからそれぞれアクセス可能であり、前記サービスについてのリッチコンテンツを格納している第１のボリュームと、前記サービスについてのプアコンテンツを格納している第２のボリュームとからなり、
該Ｗｅｂサーバシステムの負荷が所定の基準よりも高いか否かにより、前記サービスの提供に際して使用する前記コンテンツの種類を前記プアコンテンツとするか前記リッチコンテンツとするかを判断するコンテンツ判断部と、
前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記コンテンツ判断部によって判断された前記コンテンツの種類の情報に基づいて、前記第１または第２のボリュームから前記コンテンツを取得する振り分け部とを有することを特徴とするＷｅｂサーバシステム。
【請求項２】
請求項１に記載のＷｅｂサーバシステムにおいて、
前記Ｗｅｂサーバは、前記リッチコンテンツが格納されている前記ボリュームとして前記第１のボリュームを特定し、前記プアコンテンツが格納されている前記ボリュームとして前記第２のボリュームを特定する定義情報を有し、
前記振り分け部は、前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記コンテンツ判断部によって判断された前記コンテンツの種類の情報に基づいて、前記定義情報から、使用する前記コンテンツの参照先となる前記第１または第２のボリュームを特定して、前記第１または第２のボリュームから前記コンテンツを取得することを特徴とするＷｅｂサーバシステム。
【請求項３】
請求項２に記載のＷｅｂサーバシステムにおいて、
前記Ｗｅｂサーバは、前記コンテンツ判断部によって判断された前記コンテンツの種類の情報を前記クライアント端末に送信し、
前記振り分け部は、前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記アクセス要求に含まれる前記コンテンツの種類の情報に基づいて、前記定義情報から使用する前記コンテンツの参照先となる前記第１または第２のボリュームを特定して、前記第１または第２のボリュームから前記コンテンツを取得することを特徴とするＷｅｂサーバシステム。
【請求項４】
請求項１〜３のいずれか１項に記載のＷｅｂサーバシステムにおいて、
前記コンテンツ判断部は、該Ｗｅｂサーバシステムの負荷が所定の基準よりも高いか否かに加えて、少なくとも前記クライアント端末の該Ｗｅｂサーバシステムへの接続環境に関する情報もしくは前記サービスの提供を受けるユーザの属性に関する情報のいずれかを含む情報に基づいて、前記サービスの提供に際して使用する前記コンテンツの種類を前記プアコンテンツとするか前記リッチコンテンツとするかを判断することを特徴とするＷｅｂサーバシステム。
【請求項５】
請求項１〜４のいずれか１項に記載のＷｅｂサーバシステムにおいて、
前記複数のボリュームは、さらに、前記リッチコンテンツおよび／または前記プアコンテンツについて処理負荷のレベルが異なる複数種類のものをそれぞれ保持するボリュームを有し、
前記コンテンツ判断部は、複数種類の前記コンテンツから前記サービスの提供に際して使用する前記コンテンツの種類を判断することを特徴とするＷｅｂサーバシステム。
【請求項６】
請求項１〜５のいずれか１項に記載のＷｅｂサーバシステムにおいて、
前記コンテンツ判断部は、前記クライアント端末からの前記コンテンツへのアクセス要求に対して、該Ｗｅｂサーバシステムの負荷が所定の基準よりも高いために前記コンテンツの種類を前記プアコンテンツとするよう判断した後、該Ｗｅｂサーバシステムの負荷が所定の基準よりも低くなった場合、もしくは、該Ｗｅｂサーバシステムの負荷が所定の基準よりも低いために前記コンテンツの種類を前記リッチコンテンツとするよう判断した後、該Ｗｅｂサーバシステムの負荷が所定の基準よりも高くなった場合は、前記クライアント端末に対して、その後の前記クライアント端末からのアクセス要求に対して前記リッチコンテンツを使用するか前記プアコンテンツを使用するかを選択させることを特徴とするＷｅｂサーバシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂコンテンツによりユーザに対してサービスを提供するＷｅｂサーバシステムに関し、特に、高負荷時であってもサービスの提供を可能とするＷｅｂサーバシステムに適用して有効な技術に関するものである。
【背景技術】
【０００２】
Ｗｅｂサーバシステムを構築する際には、各サーバやネットワーク、データベースなどのキャパシティプランニングを行い、ピーク時等においてシステムの負荷が高くなった場合であっても応答時間やＴＡＴ（Turn Around Time）、スループットなどにおいて所定のパフォーマンスを維持できるようにシステム設計が行われる。しかし、予想外の突発的なイベントによるアクセスの集中やシステム障害などにより、想定した以上にシステムが高負荷となってしまう場合も起こり得る。
【０００３】
このような場合、従来では、レスポンスを遅くしてでもアクセスを受け付けるか、システムの負荷を下げるために、新たなアクセスに対して「しばらく待ってから再度ログインして下さい」などと表示された画面を表示し、アクセスを拒否して流量制限を行っていた。
【０００４】
これに対して、例えば、特開２００１−２６５６９３号公報（特許文献１）には、整理券発行機能を有し、Ｗｅｂサイトが混雑した場合に、混雑の度合いや待ち時間に関する情報をユーザに提供し、また、アクセス順序に応じてトラフィックの制御を行うことにより、利便性を向上させ、また、ユーザからのアクセスのリトライによるさらなる混雑状態の悪化を防ぐＷｅｂサーバシステムが開示されている。
【特許文献１】特開２００１−２６５６９３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかし、従来技術のＷｅｂサーバシステムでは、ユーザは混雑の度合いや待ち時間に関する情報を知ることができるため、ユーザにとっての利便性は高くなるが、コンテンツにアクセスすることはできず、実際にサービスの提供を受けられるようになるまで待つ必要があることには変わりはない。
【０００６】
一方、高負荷の状態でアクセスを受け付けた場合には、例えば、サーバでの画像データの取得が重くなり、結果としてクライアント端末での画面表示が完了するまでのＴＡＴが大きく増加するといったことが発生する。また、クライアント端末の接続環境の違いにより、例えばモバイル環境など画面表示能力が低いもしくは接続回線速度が遅い場合には、リッチなコンテンツでは画面表示が非常に重くなる場合がある。また、サービス提供のための種々の処理自体が大きく遅延したり異常な結果となったりして、ほとんどのアクセス要求が正常に処理できなくなる場合もある。
【０００７】
このような状況では、コンテンツを実質的に参照できておらず、Ｗｅｂサーバシステムに対して接続してきたユーザ全体に対して、ログイン不可や処理遅延など、サービスを実質的に提供することができないという障害に発展する可能性が高い。
【０００８】
そこで本発明の目的は、システムが高負荷となった場合であっても、新たにログインしてきたユーザがコンテンツを参照できないという状況を回避しつつ、サービスの提供を継続して行うことを可能とするＷｅｂサーバシステムを提供することにある。
【０００９】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【００１０】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【００１１】
本発明の代表的な実施の形態によるＷｅｂサーバシステムは、クライアント端末に対してコンテンツによりサービスを提供する複数のＷｅｂサーバおよび前記コンテンツが格納された複数のボリュームからなり、前記複数のボリュームは、前記複数のＷｅｂサーバからそれぞれアクセス可能であり、前記サービスについてのリッチコンテンツを格納している第１のボリュームと、前記サービスについてのプアコンテンツを格納している第２のボリュームとからなり、前記Ｗｅｂサーバは、該Ｗｅｂサーバシステムの負荷が所定の基準よりも高いか否かにより、前記サービスの提供に際して使用する前記コンテンツの種類を前記プアコンテンツとするか前記リッチコンテンツとするかを判断するコンテンツ判断部と、前記クライアント端末からの前記コンテンツへのアクセス要求に対して、前記コンテンツ判断部によって判断された前記コンテンツの種類の情報に基づいて、前記第１または第２のボリュームから前記コンテンツを取得する振り分け部とを有することを特徴とするものである。
【発明の効果】
【００１２】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【００１３】
本発明の代表的な実施の形態によれば、Ｗｅｂサーバシステムが高負荷の場合には、新たにログインしてきたユーザには負荷の低いプアコンテンツを参照させるようコンテンツの参照先を制御してシステムの負荷の増大を抑制することによって、新たにログインしてきたユーザがコンテンツを参照できないという状況を回避しつつ、サービスの提供を継続して行うことが可能となる。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１５】
図１は、本発明の一実施の形態であるＷｅｂサーバシステムの構成および処理の概要の例を示した図である。図１において、Ｗｅｂサーバシステムは、クライアント端末１００に対してコンテンツによりサービスを提供する複数のＷｅｂサーバ３００、およびコンテンツが格納された複数のボリューム（ボリュームＳ１（４０１）、Ｓ２（４０２））からなっている。
【００１６】
クライアント端末１００は、インターネット等のネットワーク２００を経由してＷｅｂサーバ３００に接続し、サービスの提供を受けるためにアクセス要求を送信する。Ｗｅｂサーバシステムでは、例えば、複数のＷｅｂサーバ３００に対して、図示しない負荷分散サーバ等によってクライアント端末１００からのアクセス要求を負荷分散して振り分けることにより、大量の処理を可能とし、かつシステムの可用性を高める。
【００１７】
ボリュームＳ１（４０１）、Ｓ２（４０２）は、ネットワーク経由で各Ｗｅｂサーバ３００からそれぞれアクセス可能なボリュームであり、図１の例では、ボリュームＳ１（４０１）はリッチコンテンツを格納しており、ボリュームＳ２（４０２）はプアコンテンツを格納している。
【００１８】
ここで、リッチコンテンツとは、通常のサービス提供の際に用いられるコンテンツであり、動画、静止画による装飾により表現を高めたり、情報参照のためのチャートなどを多用したりしたいわゆる「重い」コンテンツである。また、プアコンテンツとは、過剰な装飾を廃し、情報参照のためのチャートなども用いずにテキストベースにしたり、利用可能な機能を例えば「注文」などの必須機能のみに絞ったりした、必要最小限のいわゆる「軽い」コンテンツである。
【００１９】
なお、ボリュームＳ１（４０１）、Ｓ２（４０２）には、例えばファイルサーバやＮＡＳ（Network Attached Storage）などを用いることができる。また、各ボリュームは物理的に別のディスク上に構成されていてもよいし、同一のディスク上の別の領域として構成されていてもよい。ボリュームＳ１（４０１）、Ｓ２（４０２）を、各Ｗｅｂサーバ３００から共通でアクセス可能なボリュームとすることにより、各Ｗｅｂサーバ３００のローカルディスクにそれぞれコンテンツを格納する場合と比較して、コンテンツの入れ替えに伴う作業負荷の増大や、入れ替え作業中の各Ｗｅｂサーバ３００間でのコンテンツの不整合を回避することができる。
【００２０】
Ｗｅｂサーバ３００は、振り分けエンジン３１０とコンテンツ判断エンジン３１１および定義ファイル３１３を有している。図１の例では、コンテンツ判断エンジン３１１および定義ファイル３１３は振り分けエンジン３１０の内部に配置されるように記載されているがこれに限るものではない。
【００２１】
また、振り分けエンジン３１０とコンテンツ判断エンジン３１１および定義ファイル３１３を便宜上１つだけ記載しているが、振り分けエンジン３１０およびコンテンツ判断エンジン３１１は、各Ｗｅｂサーバ３００上でそれぞれ個別に稼働するプログラムとして実装されるものである。また、定義ファイル３１３は、各Ｗｅｂサーバ３００上でそれぞれ個別に保持していてもよいし、共有ディスクなどに各Ｗｅｂサーバ３００が共有する形で保持していてもよい。
【００２２】
定義ファイル３１３は、リッチコンテンツが格納されているボリュームおよびプアコンテンツが格納されているボリュームをそれぞれ特定する情報を保持するテーブルである。図１の例では、リッチコンテンツが格納されているボリュームとしてボリュームＳ１（４０１）を特定するエントリと、プアコンテンツが格納されているボリュームとしてボリュームＳ２（４０２）を特定するエントリとを保持していることを示している。
【００２３】
コンテンツ判断エンジン３１１は、Ｗｅｂサーバシステムの負荷が所定の基準よりも高いか否かにより、サービスの提供に際して使用するコンテンツの種類をプアコンテンツとするかリッチコンテンツとするかを判断する機能を有する。システムの負荷が所定の基準よりも高くない、すなわち高負荷でない場合は通常のリッチコンテンツとし、システムの負荷が所定の基準よりも高い、すなわち高負荷である場合はサイズが小さく処理負荷の低いプアコンテンツとする。これにより、システムの負荷の増大を抑制し、新たにログインしてきたユーザがコンテンツを参照できないという状況を回避しつつサービスの提供を継続して行うことが可能となる。
【００２４】
Ｗｅｂサーバシステムが高負荷であるか否かは、例えば、システム内の各コンポーネントの性能指標を測定もしくは取得し、その値を基準となる閾値等と比較することで判断することができる。システム内の各コンポーネントの性能指標を測定もしくは取得する手段は特に限定しないが、種々の方法を利用することができる。一般的に取得可能な性能指標として、例えば、サーバのＣＰＵやメモリの使用率、ネットワークの帯域利用率、アプリケーションやデータベース、ストレージの応答時間などがある。これらを測定もしくは取得するために、コンテンツ判断エンジン３１１自身が測定のためのコマンドの実行などを行ってもよいし、別の性能監視システムや性能測定プログラムなどが測定した性能指標を参照して判断してもよい。
【００２５】
振り分けエンジン３１０は、クライアント端末１００からのコンテンツへのアクセス要求に対して、コンテンツ判断エンジン３１１によって判断されたコンテンツの種類の情報に基づいて、定義ファイル３１３から使用するコンテンツの参照先となるボリュームを特定して、特定されたボリュームからコンテンツを取得する機能を有する。
【００２６】
図１の例では、振り分けエンジン３１０は、クライアント端末１００からのアクセス要求を受けると、コンテンツ判断エンジン３１１にてシステムの負荷の状況に基づいて使用するコンテンツの判断を行う。ここで、例えば、Ｗｅｂサーバシステムが現在高負荷であり、当該ユーザからのアクセスについてはプアコンテンツを使用するという判断がされたものとする。このとき、振り分けエンジン３１０は、定義ファイル３１３からプアコンテンツを格納しているボリュームとしてボリュームＳ２（４０２）を特定する情報を取得し、コンテンツの参照先のボリュームをボリュームＳ２（４０２）に設定して、ボリュームＳ２（４０２）からプアコンテンツを取得する。このように、Ｗｅｂサーバシステムの負荷の状況により、使用するコンテンツの参照先を振り分けることができる。
【００２７】
なお、本実施の形態では、定義ファイル３１３にコンテンツの種類と格納されているボリュームの対応を保持しているため、定義ファイル３１３の設定内容を変更することにより、同一種類のコンテンツについて、その参照先のボリュームを一斉に変更することが可能である。一方、定義ファイル３１３を有さず、コンテンツ判断エンジン３１１が内部に固定的に参照先のボリュームの情報を保持して振り分けるようにしてもよい。
【００２８】
上述した例では、コンテンツ判断エンジン３１１は、Ｗｅｂサーバシステムが高負荷であるか否かのみを判断基準としてコンテンツの種類を判断している。しかしこの場合には、Ｗｅｂサーバシステムが高負荷である場合には、新たにログインする全てのユーザに対して一律にプアコンテンツが使用されることになる。
【００２９】
そこで、本実施の形態では、コンテンツ判断エンジン３１１において、Ｗｅｂサーバシステムが高負荷であるか否かに加えてさらに判断基準を追加し、アクセス環境やユーザの属性情報などの情報も加味して、コンテンツの種類をリッチコンテンツとするかプアコンテンツとするかを判断する。これにより、たとえＷｅｂサーバシステムが高負荷であっても、所定の条件に該当する場合にはリッチコンテンツを使用するように判断結果を変更し、柔軟なコンテンツの振り分けを可能とする。
【００３０】
判断基準としては、例えば、ユーザのアクセス回線（光ファイバーかＡＤＳＬ（Asymmetric Digital Subscriber Line）かモバイルアクセスかなど）に関する情報や、ユーザの属性（富裕層などの優遇顧客や特定の商品の購入頻度の高い顧客など）に関する情報等を個別にもしくは組み合わせて追加することができる。これにより、ユーザのアクセス環境の処理能力が高い場合や、優先的にリッチコンテンツを参照させたいユーザなどの場合に、Ｗｅｂサーバシステムが高負荷であってもリッチコンテンツを使用することができる。この判断基準の情報は、例えば基準ファイル３１２等に格納しておき、コンテンツ判断エンジン３１１による判断時に参照可能とすることができる。
【００３１】
コンテンツ判断エンジン３１１によって判断された使用するコンテンツの種類の情報は、要求元のクライアント端末１００に送信されて保持される。これには、例えば、Ｗｅｂサーバ３００とクライアント端末１００のＷｅｂブラウザとの間での状態情報の授受に一般的に用いられるＣｏｏｋｉｅなどを用いることができる。これ以降、当該クライアント端末１００からのアクセス要求には、クライアント端末１００のＷｅｂブラウザによって、コンテンツ判断エンジン３１１によって判断されたコンテンツの種類の情報が設定されたＣｏｏｋｉｅが含まれることになる。
【００３２】
図２は、クライアント端末１００からＣｏｏｋｉｅによりコンテンツの種類の情報を受け取る場合の処理の概要の例を示した図である。クライアント端末１００のＷｅｂブラウザは、ログイン時にコンテンツ判断エンジン３１１によって判断されたコンテンツの種類の情報が設定されたＣｏｏｋｉｅを保持している。
【００３３】
ここで、例えば、プアコンテンツを使用するよう設定されたＣｏｏｋｉｅを保持するクライアント端末１００からのアクセス要求を受けたＷｅｂサーバ３００では、振り分けエンジン３１０により、アクセス要求に含まれるコンテンツの種類の情報に基づいて、定義ファイル３１３からプアコンテンツの参照先のボリュームとして定義されているボリュームＳ２（４０２）を特定して、ボリュームＳ２（４０２）からプアコンテンツを取得する。
【００３４】
これにより、ログイン時のコンテンツ判断エンジン３１１での判断において、Ｗｅｂサーバシステムが高負荷であるとしてプアコンテンツを使用するように判断されたユーザは、その後負荷が低下して高負荷ではなくなった場合であってもプアコンテンツの使用を継続し、新たにログインしてきたユーザのみリッチコンテンツを使用するように誘導する。また同様に、ログイン時に高負荷ではないとしてリッチコンテンツを使用するように判断されたユーザは、その後負荷が増大して高負荷となった場合であってもリッチコンテンツの使用を継続し、新たにログインしてきたユーザのみプアコンテンツを使用するように誘導する。
【００３５】
このように、本実施の形態では、Ｃｏｏｋｉｅにコンテンツの種類の情報を設定することにより、ログイン以降のアクセス要求に対しては、コンテンツ判断エンジン３１１による判断を行わずに振り分けエンジン３１０により直接コンテンツの参照先のボリュームを特定する構成としているが、ログイン以降のアクセス要求に対してもその都度もしくは定期的にコンテンツ判断エンジン３１１により使用するコンテンツの種類を判断するようにしてもよい。
【００３６】
この場合は、例えば、ログイン時に高負荷であるとしてプアコンテンツを使用するように判断されたユーザであっても、その後負荷が低下して高負荷ではなくなった場合には、リッチコンテンツを提供することを優先して当該ユーザからのその後のアクセス要求に対してコンテンツ判断エンジン３１１での判断によってリッチコンテンツを使用するよう切り替えることも可能である。また同様に、ログイン時に高負荷ではないとしてリッチコンテンツを使用するように判断されたユーザであっても、その後負荷が増大して高負荷となった場合には、高負荷状態を解消することを優先してプアコンテンツを使用するよう切り替えることも可能である。
【００３７】
また、このとき、強制的にリッチコンテンツ／プアコンテンツを切り替えるのではなく、例えば、ユーザにリッチコンテンツ／プアコンテンツを切り替えるか否かを選択する画面を提示して選択させることにより、それまでのセッションを維持してサービスの提供を継続することも可能である。
【００３８】
なお、振り分けエンジン３１０およびコンテンツ判断エンジン３１１については、例えば、ＡｐａｃｈｅなどのＷｅｂサーバソフトウェアにおいて、Ｗｅｂサーバ３００上でコンテンツを参照する際のルートディレクトリが設定されるDocumentRootの設定値と、クライアント端末１００からのアクセス要求のＵＲＬ（Uniform Resource Locator）とからコンテンツの実際の格納場所の物理パスを生成してコンテンツを取得する処理を行う部分にプログラムとして組み込んで実装することができる。
【００３９】
具体的には、例えば、ＷｅｂサーバソフトウェアにおいてDocumentRootの設定値とアクセス要求のＵＲＬとからコンテンツの格納場所の物理パスを生成する処理を行う部分にプログラムを組み込むことによって実現することができる。当該プログラムでは、クライアント端末１００からの要求に含まれるＣｏｏｋｉｅに設定されたコンテンツの種類の情報に基づいて、必要に応じてコンテンツ判断エンジン３１１による判断処理を呼び出す。さらに、定義ファイル３１３から使用するコンテンツの種類に対応した参照先のボリュームの情報を取得し、当該ボリュームの情報に基づいてコンテンツの格納場所の物理パスを新たに生成する処理を行う。
【００４０】
図３は、コンテンツ判断エンジン３１１における使用するコンテンツの判断結果をリッチコンテンツかプアコンテンツかの二者からさらに細分化した場合の例を示した図である。図３では、プアコンテンツを格納するボリュームがプアコンテンツ１を格納するボリュームＳ２（４０２）と、プアコンテンツ２を格納するボリュームＳ３（４０３）に分かれている。また、定義ファイル３１３にも、これに対応してプアコンテンツ１を格納するボリュームＳ２（４０２）を特定するエントリと、プアコンテンツ２を格納するボリュームＳ３（４０３）を特定するエントリを有している。
【００４１】
ここで、プアコンテンツ１は、例えば、テキストベースで必要最小限の機能のみを有するプアコンテンツであり、プアコンテンツ２は、例えば、リッチコンテンツが有する機能は維持するが動画などの過剰な装飾を廃した中間のプアコンテンツであるものとする。このように、プアコンテンツを処理負荷のレベルに応じて複数種類保持している。図３の例では処理負荷のレベルが異なるプアコンテンツを複数種類保持しているが、リッチコンテンツを複数種類保持してもよい。
【００４２】
Ｗｅｂサーバシステムが高負荷である状態でプアコンテンツを使用する場合であっても、一律に同じプアコンテンツを使用するのではなく、例えば、上述したユーザのアクセス回線や属性情報などに基づいて、所定の条件に合致するユーザには中間レベルのプアコンテンツ２を参照させることが可能である。また、例えば、Ｗｅｂサーバシステムの負荷の状態をレベルで判断し、負荷のレベルが中間レベルの場合にはプアコンテンツ２を参照させたりすることも可能である。このように、コンテンツ判断エンジン３１１での判断結果を細分化し、それに応じて使用するコンテンツをきめ細かく振り分けて制御することも可能である。
【００４３】
以上に説明したように、本発明の実施の形態であるＷｅｂサーバシステムによれば、振り分けエンジン３１０およびコンテンツ判断エンジン３１１により、Ｗｅｂサーバシステムが高負荷の場合には、新たにログインしてきたユーザには負荷の低いプアコンテンツを参照させるようコンテンツの参照先を制御してシステムの負荷の増大を抑制することによって、新たにログインしてきたユーザがコンテンツを参照できないという状況を回避しつつ、サービスの提供を継続して行うことが可能となる。
【００４４】
また、システムの負荷の状態だけではなくユーザのアクセス環境や属性情報も加味してコンテンツの参照先の判断を行い、また、参照先のコンテンツをきめ細かく振り分けて制御することで、Ｗｅｂサーバシステムが高負荷の状態であっても、状況に応じて参照するコンテンツを柔軟に振り分けてサービスの提供を継続して行うことが可能となる。
【００４５】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【００４６】
本発明は、Ｗｅｂコンテンツによりユーザに対してサービスを提供するＷｅｂサーバシステムに利用可能である。
【図面の簡単な説明】
【００４７】
【図１】本発明の一実施の形態であるＷｅｂサーバシステムの構成および処理の概要の例を示した図である。
【図２】本発明の一実施の形態におけるクライアント端末からＣｏｏｋｉｅによりコンテンツの種類の情報を受け取る場合の処理の概要の例を示した図である。
【図３】本発明の一実施の形態における使用するコンテンツの判断結果を細分化した場合の例を示した図である。
【符号の説明】
【００４８】
１００…クライアント端末、２００…ネットワーク、３００…Ｗｅｂサーバ、３１０…振り分けエンジン、３１１…コンテンツ判断エンジン、３１２…基準ファイル、３１３…定義ファイル、４０１…ボリュームＳ１、４０２…ボリュームＳ２、４０３…ボリュームＳ３。
【図１】
2010123015.tif 000003
【図２】
2010123015.tif 000004
【図３】
2010123015.tif 000005