JP2008191938A - 負荷軽減化処理方法及び装置 - Google Patents

Abstract

【課題】一斉にアクセスが集中する可能性のあるサービス提供サーバの負荷を安価に軽減する。
【解決手段】本方法は、負荷を軽減すべきサービス提供サーバとは異なる負荷軽減化サーバにより実行され、ユーザからの要求に応答して、ユーザのメールアドレスと上記要求の受付日時とを受付データ格納部に格納する工程と、受付データ格納部に格納されているレコードを上記要求の受付日時でソートし、上位から所定のルールに従って順番にグループ化して、グループ毎にレコードをサービス用データ格納部に格納する工程と、サービス用データ格納部に格納されている上位のグループに属するレコードから順番に読み出し、サービス提供サーバによる、当該グループに対するサービス時間についてのデータを含むメールを、当該レコードに含まれるメールアドレス宛に送信する工程とを含む。
【選択図】図７

Description

本発明は、特定のサービスを提供するサーバの負荷を軽減するための技術に関する。

インターネット上では、通信販売や施設利用予約、チケット販売など様々なサービスが提供されている。しかし、人気のある商品の販売や人気のあるイベントなどのチケット販売、人気のある施設の利用予約受け付けを行う際には、サーバにアクセスが集中してサーバの処理が遅延したり、サーバがダウンしたりするなどの問題が発生する場合がある。このため、処理能力が高く高価なサーバを導入したり、サーバの台数を増やしてロードバランサを導入するなど、サービス提供にかかる費用が増大してしまう。一方、処理能力を増大させなければ、サービスの利用者は長時間待たされたり、購入などをあきらめるより仕方が無く、サービス提供者にとっても機会損失に繋がる。

また、例えば、特開２００３−１７３３１９号公報には、インターネットを使ったＷｅｂ（ウェブ）アクセスにおいてＳＳＬ（Secure Socket Layer）を使用したサービス申し込みや動画コンテンツなどにおいてアクセスが集中した場合、サイトのサーバの処理能力を超えてしまうという事項に対処するための技術が開示されている。具体的には、ユーザのＷｅｂサーバへのアクセスに対して、実際にコンテンツが配信されるコンテンツ配信ページに直接アクセスすることはできなくして、必ず受付ページへアクセスするようにする。そして、受付ページにアクセスしてきたユーザに有効期間付きの整理券を発行する。そして有効期間内の整理券を所持したユーザが再び受付ページにアクセスしてきたとき、ユーザを目的のコンテンツ配信ページに誘導することでコンテンツ配信ページへのアクセス数を制限するものである。しかしながら、本公報では受付ページとコンテンツ配信ページとが同一Ｗｅｂサーバに存在していて、受付ページにアクセスが集中すればＷｅｂサーバ自体がダウンしかねないという問題がある。特に、整理券を持っていても最初に受付ページにアクセスするため、整理券を取得するため及びコンテンツ配信ページに移行するための両方の目的で受付ページにアクセスが集中するようになっている。すなわち、実質的にページ単位で負荷を分散させる意味はない。さらに、アクセス可能期間をどのように設定するのか不明であり、さらに適宜整理券を発行するような状態を想定しているように見えるため、利用者によって一斉に出される要求をグループ化したり、当該グループを動的に変更したりすることについては考慮されていない。また、発行した整理券の有効期間のみを変更するようなことを想定していない。さらに、整理券は一度利用すると二度と使えないようになっていたり、様々な付加機能が不足しており、実現のための工夫がなされていない。
特開２００３−１７３３１９号公報

上で述べたような公報では十分にサービス提供サーバの負荷を軽減することはできず、上で述べたようなチケット販売などで一斉にアクセスが行われた場合における対処が不十分である。

従って、本発明の目的は、一斉にアクセスが集中する可能性のあるサービス提供サーバの負荷を安価に軽減できるようにするための新規の負荷軽減化技術を提供することである。

さらに、本発明の他の目的は、負荷軽減策を講じたサービス提供サーバの負荷状況に応じてサービス提供スケジュールを変更できるようにするための技術を提供することである。

本発明に係る負荷軽減化処理方法は、負荷を軽減すべきサービス提供サーバとは異なる負荷軽減化サーバにより実行され、ユーザからの要求に応答して、ユーザのメールアドレスと上記要求の受付日時とを受付データ格納部に格納するステップと、受付データ格納部に格納されているレコードを上記要求の受付日時でソートし、上位から所定のルールに従って順番にグループ化して、グループ毎にレコードをサービス用データ格納部に格納するステップと、サービス用データ格納部に格納されている上位のグループに属するレコードから順番に読み出し、サービス提供サーバによる、当該グループに対するサービス時間についてのデータを含むメールを、当該レコードに含まれるメールアドレス宛に送信する送信ステップとを含む。

一斉にアクセスが集中する場合には、例えばサービス提供サーバの能力に応じてグループ化を行い、当該グループに対するサービス時間のスケジューリングを適切に行うことによって、安価に且つ適切にサービス提供サーバの負荷を軽減することができるようになる。なお、送信ステップで送信されるメールには、パスワードが含まれる場合もある。パスワードは、ユーザが入力する場合もあれば例えばグループ化する前又は後で負荷軽減化サーバにより付与するようにしても良い。

また、上で述べた送信ステップが、第１のグループに属するレコードについて処理した後所定の送信異常が検出された場合、第１のグループより１つ下位の第２のグループにおいて上記要求の受付日時の早いレコードの順に所定の送信異常に係るレコード数のレコードだけ第１のグループにグループ変更するように、サービス用データ格納部を更新するステップと、第１のグループに対するサービス時間についてのデータを含むメールと、グループ変更に係るレコードに含まれるメールアドレス宛に送信するステップとを含むようにしてもよい。例えば、メール不着やサービス要求の撤回が明示的に通知された場合など、グループを再編することによってユーザへの早期のサービス提供という目的を達成しつつ、サービス提供サーバの能力に応じたサービス提供という負荷軽減も図られている。なお、パスワードが上で述べたようにメールに含まれるようにしてもよい。

さらに、上で述べたサービス用データ格納部に、グループ毎に当該グループに対するサービス時間についてのデータが格納されるようにしてもよい。その際、グループに対するサービス時間についてのデータを変更可能とする場合もある。このようにすると、サービス提供サーバの負荷状況に応じてサービス提供スケジュールを前倒しにしたり、後ろにずらしたりすることが可能となる。スケジュールの変更については、管理者の判断によっても良いし、想定されるサービス提供状況と実際のサービス提供状況との差に応じて自動的に且つ動的にスケジュール変更を行うようにしても良い。

なお、上記グループに対するサービス時間が変更になった場合に、当該グループに属するレコードを読み出し、当該グループに対するサービス時間のデータを含むメールを、当該レコードに含まれるメールアドレス宛に送信するステップをさらに含むようにしてもよい。変更を周知させるためである。

なお、本方法をコンピュータに実行させるためのプログラムを作成することができ、このプログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等の記憶媒体又は記憶装置に格納される。また、ネットワークなどを介してデジタル信号として配信される場合もある。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

本発明によれば、一斉にアクセスが集中する可能性のあるサービス提供サーバの負荷を安価に軽減することができるようになる。

さらに、本発明の他の側面によれば、負荷軽減策を講じたサービス提供サーバの負荷状況に応じてサービス提供スケジュールを変更できるようになる。

図１に本発明の一実施の形態に係るシステムの概要を示す。例えばインターネットであるネットワーク１には、複数のユーザ端末（図１ではユーザ端末Ａ乃至Ｃ。但し３台に限定するものではない。）と、ユーザ端末に対して例えばチケット販売などのサービスを提供し、負荷を軽減すべきサービス提供サーバ５と、サービス提供サーバ５の管理者によって操作される管理者端末７と、本実施の形態における主要な処理を実施する負荷軽減化サーバ３とが接続されている。なお、ユーザ端末は、ウェブ（Ｗｅｂ）ブラウザ及びメール・クライアント・プログラムがインストールされているパーソナルコンピュータであってもよいし、同じくＷｅｂブラウザ及びメール・クライアント・プログラムがインストールされている携帯電話機その他の携帯端末であってもよい。また、負荷軽減化サーバ３にアクセスする場合とサービス提供サーバ５にアクセスする場合とで端末が異なるようにしても良い。管理者端末７は、サービス提供サーバ５及び負荷軽減化サーバ３の両方にアクセスして、必要な設定を行う端末である。

また、負荷軽減化サーバ３は、受付処理部３１と、受付処理部３１によって受信及び生成されたデータを格納する受付データ格納部３２と、受付データ格納部３２に格納されたデータを用いて処理を実施する後処理部３３と、後処理部３３の処理結果を格納するサービス用データ格納部３４と、サービス用データ格納部３４に格納されたデータを例えば管理者端末７に送信し、管理者端末７からの指示に従ってサービス用データ格納部３４に格納されているデータの変更などを行う管理処理部３５とを含む。

サービス提供サーバ５は、例えばネットワーク１を介して負荷軽減化サーバ３のサービス用データ格納部３４にアクセスできるようになっており、サービス用データ格納部３４に格納されているデータを用いて処理を行う。なお、サービス用データ格納部３４のデータを、必要に応じてサービス提供サーバ５にダウンロードして用いるような形式であっても良い。

本実施の形態では、ユーザは、サービス提供サーバ５におけるチケット販売などのサービスの提供を欲する場合には、まず負荷軽減化サーバ３にアクセスして、メールにてパスワードを予め発行してもらわなければならない。パスワードには有効期限が設定されており、有効期限内でなければサービス提供サーバ５からサービスの提供を受けることはできない。以下、図１に示したシステムの処理の詳細を図２乃至図１４を用いて説明する。

まず、ユーザはユーザ端末（例えばユーザ端末Ａ）を操作して負荷軽減化サーバ３のメニューページにアクセスさせる（図２：ステップＳ１）。負荷軽減化サーバ３の受付処理部３１は、ユーザ端末Ａからメニューページへのアクセスを受けると、メニューページ・データを生成して、ユーザ端末Ａに送信する（ステップＳ３）。ユーザ端末Ａは、負荷軽減化サーバ３からメニューページ・データを受信すると、表示装置に表示する（ステップＳ５）。

例えば図３に示すような画面がユーザ端末Ａの表示装置に表示される。図３の画面例では、○○コンサートについて３会場５回の公演が列挙されており、大阪会場以外の公演については申し込みボタンがクリック可能な状態で表示されており、申し込みが可能となっている。大阪会場については申し込みボタンがクリック不可能な状態で表示されており、まだ申し込み可能日時になっていないことを示している。このように以下で説明する利用権申請ページを不必要に提示しないようにして、プログラムなどを用いた大量申請や、いたずらを排除する。

ユーザはこのような画面を見て、いずれかの申し込みボタンをクリックする。そうすると、ユーザ端末Ａは、当該申し込みボタンのクリックを、対応するメニュー項目の選択入力として受け付け（ステップＳ７）、選択メニュー項目に係るイベント番号を負荷軽減化サーバ３に送信する（ステップＳ９）。イベント番号は、公演毎に割り当てられており、例えば申し込みボタンに対応してメニューページ・データに含まれている。負荷軽減化サーバ３の受付処理部３１は、ユーザ端末Ａから選択メニュー項目に係るイベント番号を受信し（ステップＳ１１）、以下で述べる利用権申請ページ用の画面識別番号（例えばランダム番号）を発行し、イベント番号と対応付けて受付データ格納部３２に格納する（ステップＳ１３）。例えば、図４に示すようなデータが、受付データ格納部３２に格納される。図４のテーブル例のように、イベント番号と画面識別番号とが対応付けられている。

そして、受付処理部３１は、イベント番号及び画面識別番号を隠しパラメータとして含む利用権申請ページ・データを生成し、ユーザ端末Ａに送信する（ステップＳ１５）。ユーザ端末Ａは、イベント番号及び画面識別番号を隠しパラメータとして含む利用権申請ページ・データを受信し、表示装置に表示する（ステップＳ１７）。

例えば図５に示すような画面がユーザ端末Ａの表示装置に表示される。図５の画面例は、図３の画面において青森会場１月１日の公演について申し込みボタンがクリックされた場合に表示される画面例である。このように選択された公演を特定する情報を提示すると共に、本実施の形態ではログインＩＤともなるメールアドレスの入力欄及び再入力欄が設けられている。なお、本実施の形態では、図５のような画面では、ＨＴＭＬ（Hyper Text Markup Language）のソースコードを開示しないような設定を行っておき、送信先のＵＲＬ（Uniform Resource Locator）及び送信情報を隠蔽しておく。また、イベント番号及び画面識別番号については、利用権申請ページ・データには含まれるが表示されることはなく、またＨＴＭＬのソースコードは開示しないような設定となっているので、隠しパラメータとなっている。さらに、一度送信ボタンがクリックされると、当該利用権申請ページ・データを再度ロードしても送信ボタンを再度表示することがないように設定を行っておく。このようにすることによって、プログラム等による大量申請を防止し、この利用権申請ページからでないと申請できないようにする。

ユーザは、メールアドレスをメールアドレスの入力欄及び再入力欄に入力し、送信ボタンをクリックする。ユーザ端末Ａは、ユーザからのメールアドレスの入力及び送信指示を受け付け（ステップＳ１９）、利用権申請ページ・データに従って例えば２度入力されているメールアドレスが一致するかを判断し、一致するようであれば、入力されたメールアドレス並びに隠しパラメータとして送信されてきたイベント番号及び画面識別番号を負荷軽減化サーバ３に送信する（ステップＳ２１）。なお、２度入力されているメールアドレスが不一致である場合には、入力を確認するように促すメッセージを表示させる。

負荷軽減化サーバ３の受付処理部３１は、ユーザ端末Ａから、入力されたメールアドレス並びに隠しパラメータとしてイベント番号及び画面識別番号を受信し、受付時刻と共に受付データ格納部３２に格納する（ステップＳ２３）。例えば図６に示すようなデータが、受付データ格納部３２に格納される。図６のテーブル例では、イベント番号と、メールアドレスと、受付時刻と、画面識別番号とが登録されるようになっている。なお、図１では負荷軽減化サーバ３が１台の例を示しているので、受信した順番に図６のようなテーブルに登録すれば受付時刻がなくとも問題が生じないが、受付処理部３１及び受付データ格納部３２を有する複数のサーバで利用権申請のみを並行して受け付ける場合もあるので、図６のように受付時刻のデータについても保持するようにして、後処理でソートできるようにする。また、アクセスが集中することもあるので、ここでは直ぐにはイベント番号と画面識別番号の対が正しいかについては判断しない。

そして負荷軽減化サーバ３の受付処理部３１は、利用権申請の完了ページ・データを生成し、ユーザ端末Ａに送信する（ステップＳ２５）。そしてユーザ端末Ａは、負荷軽減化サーバ３から利用権申請の完了ページ・データを受信し、表示装置に表示する（ステップＳ２７）。このようにして、ユーザは利用権申請が一応完了したことを認識することができる。

このような処理を繰り返すことによって、受付データ格納部３２にはデータが蓄積されてゆく。その後、利用権申請の受付期間終了後に、図７に示す処理フローを実施する。

まず、負荷軽減化サーバ３の後処理部３３は、受付データ格納部３２に格納されているテーブル（図６）に含まれるイベント番号と画面識別番号の対が、同じく受付データ格納部３２に格納されているテーブル（図４）に含まれるイベント番号と画面識別番号の対と一致しているかチェックする処理を実施する（ステップＳ３１）。図６のテーブルに含まれるイベント番号と画面識別番号の対が、図４のテーブルに含まれるイベント番号と画面識別番号との対に一致しないと判断された場合には、当該レコードを処理対象から除外して削除する。一方、一致すると判断されたレコードについては以下の処理を実施する。なお、上でも述べたが、複数のサーバにて利用権申請の受け付けを行う場合には、図６のようなテーブルが複数存在するが、各テーブルについて上で述べた処理を実施すると共に、以下の処理ではテーブルをマージして用いる。また、ステップＳ３１の処理については、受付処理部３１が、イベント番号と画面識別番号の対をユーザ端末Ａから受信した後に実施するようにしても良い。

そして、後処理部３３は、問題のない（すなわち一致すると判断された）申請に係るレコードを受付時刻の順番にソートして受付番号をシリアルに付与する（ステップＳ３３）と共に、各レコードに対してパスワードを付与する（ステップＳ３５）。そして、設定に従って、初期グループ分けを実施して、サービス用データ格納部３４に処理結果を格納する（ステップＳ３７）。例えば、サービス提供サーバ５の能力に応じて予めグループに属するユーザ数を決定しておく。グループに属するユーザ数は各グループについて同一であってもよいし、例えば最上位グループには特典保持者に限定して人数を少なく設定するなどを行っても良い。

サービス用データ格納部３４に格納されるデータの一例を図８に示す。図８の例では、１つのイベント番号の配下に、グループ数だけグループデータ・ユニットがリンクしており、各グループデータ・ユニットの配下には、当該グループに所属する利用権申請データ・ユニットが申請者数分（又は申請数分）リンクされている。グループデータ・ユニットには、少なくともグループ識別データ（例えばグループＡなど）、サービス提供時間（開始日時を含む。終了時刻も含む場合もある。）及び受付番号の範囲のデータが含まれる。利用権申請データ・ユニットには、受付番号、受付時刻、及びログイン情報（ＩＤ（メールアドレス）及びパスワード）を含む。ＩＤについてはメールアドレス以外に発行するようにしても良い。例えば受付番号をＩＤの代わりに用いるようにしても良い。その場合にはメールアドレスを利用権申請データ・ユニットに別途含める必要がある。また、イベント番号が１つではなく複数存在する場合には、図８に示すようなデータ構造が複数サービス用データ格納部３４に格納されることになる。

そして、後処理部３３は、ｎを１に初期化して（ステップＳ３９）、サービス用データ格納部３４において第ｎグループの利用権申請データ・ユニットにおいてＩＤとして登録されているメールアドレスを読み出し、第ｎグループ所属の申請者に対して予め定められたフォーマットの通知をメールで送信する（ステップＳ４１）。

例えば図９に示すような内容のメールを送信する。図９の例では、サービス開始日時（終了日時を含む場合もある）と、受付番号と、ログイン情報（ＩＤ及びパスワード）とが含まれる。

本実施の形態では、利用権申請データが有効に登録されていない場合もあるということを想定している。すなわち、利用権の申請者が間違ったメールアドレスを登録してステップＳ４１で送信したメールが不着としてメールサーバから返信されたり、図９のメール例において最終行に示したように他人が勝手に他人のメールアドレスを用いて申請したりするような場合が想定される。

このようなメールの送信異常が例えばステップＳ４１を実施後所定時間内に判明する場合、すなわちメールサーバからメールの不着を通知するメールを受信したり、例えば管理者端末７から特定の受付番号の利用権申請データ・ユニットの削除が指示された場合、後処理部３３は、該当する利用権申請データ・ユニット（メール不着を通知するメールに係る利用権申請データ・ユニットや削除指示がなされた利用権申請データ・ユニット）を第ｎグループからの削除を実施すると共に、第ｎ＋１グループから送信異常に係る利用権申請データ・ユニットの数分の利用権申請データ・ユニットを受信時刻の順番に第ｎグループへ繰り上げるように、サービス用データ格納部３４に格納されているデータを更新する（ステップＳ４３）。

例えば図１０に示すように、Ａグループの受付番号０１０のためのメールに送信異常が発生した場合、当該受付番号０１０についての利用権申請データ・ユニットを削除すると共に、Ｂグループの受付番号０１１についての利用権申請データ・ユニットを、Ｂグループについてのグループデータ・ユニットからＡグループについてのグループデータ・ユニットの配下になるように、データの更新を実施する。また、Ａグループのグループデータ・ユニットに含まれる受付番号の範囲を変更する。

そして、後処理部３３は、ｎが最大値に達したか判断する（ステップＳ４５）。ｎの最大値はステップＳ３７で特定される。そして、ｎが最大値に達していない場合には、ｎを１インクリメントして（ステップＳ４７）ステップＳ４１に戻る。一方、ｎが最大値に達した場合には、例えば後処理部３３は、サービス用データ格納部３４に格納されたデータに基づきサービスタイムテーブルを生成し、例えば負荷軽減化サーバ３において例えばＷｅｂページで公開する（ステップＳ４９）。

例えば、図１１に示すようなサービスタイムテーブルを生成して公開する。図１１の例では、各グループに属する申請者の受付番号の範囲と、サービス開始日時（図１１の例では日）とが、サービス用データ格納部３４に格納されているグループデータ・ユニットに基づき、グラフ上に示されるようになっている。なお、オープンとは、利用権申請を行わなかった一般のユーザのグループを示す。このようなデータを開示することによって、ユーザに対して公平性を強調することができる。

以上のような処理を実施すれば、基本的に先着順に申請者をグループ化して、サービス提供時間をグループ単位でずらすことが可能になる。図１１の例では終了時期が規定されていないので期間が重複していたが、重複しないように設定することも可能である。これによって、サービス提供サーバ５の負荷を軽減できるようになる。すなわち、サービス提供サーバ５に高価なロードバランサーを用意したり、処理能力の非常に高いサーバを用意したりする必要がなくなる。

なお、グループ単位でサービス提供時間を設定すれば、個別の申請毎に設定するよりサービス提供時間の設定処理が簡単になる。また、このようなグループ単位でサービス提供時間を設定するようにしても、グループに属する申請数を調整することによってサービス提供サーバ５の能力に応じた負荷に納めることは難しくない。但し、グループの人数は１人とすることも可能である。

また、上で述べた処理では特別なクッキーを用いることはない。従って、以下で説明するような処理を別のユーザ端末（例えばユーザ端末Ｃ）で行うようにしても問題なく実施できる。

さらに、サービス用データ格納部３４には、図９に示したようなメールを生成するのに必要なデータが格納されているので、例えば管理者端末７から再送信要求を送信して、管理処理部３５に、図９に示したようなメールの再送信を実施させることも可能である。例えば、特定の申請者から再送信を要求された場合に対応可能となる。

また、サービス用データ格納部３４に格納されたデータについては、負荷軽減化サーバ３に保持してサービス提供サーバ５がアクセスするようにしてもよいし、コピーを作成してサービス提供サーバ５に格納するようにしても良い。

次に、図１２を用いてサービス提供サーバ５の処理内容について説明する。まず、ユーザは、ユーザ端末（例えばユーザ端末Ａ）を操作してサービス提供サーバ５の特定のイベントについてのログインページにアクセスさせる（ステップＳ５１）。サービス提供サーバ５は、ユーザ端末Ａからのアクセスに応答してログインページ・データを、ユーザ端末Ａに送信する（ステップＳ５３）。ユーザ端末Ａは、サービス提供サーバ５からログインページ・データを受信し、表示装置に表示する（ステップＳ５５）。例えば、ＩＤ及びパスワードの入力欄を有する画面が表示装置に表示される。

ユーザは、画面における入力欄にＩＤ（例えば登録済みメールアドレス及び通知されたパスワード）を入力し、送信ボタンをクリックする。ユーザ端末Ａは、ユーザからのＩＤ及びパスワードの入力を受け付け、ＩＤ及びパスワードをサービス提供サーバ５に送信する（ステップＳ５７）。

サービス提供サーバ５は、ユーザ端末ＡからＩＤ及びパスワードを受信し（ステップＳ５９）、サービス用データ格納部３４をＩＤで検索してパスワードを読み出し、受信したＩＤ及びパスワードの組み合わせが正しいか判断する（ステップＳ６１）。組み合わせが正しくない場合には、サービス提供サーバ５は、認証失敗通知をユーザ端末Ａに送信する。ユーザ端末Ａは、サービス提供サーバ５から認証失敗通知を受信し、表示装置に表示する（ステップＳ６３）。これによってユーザはＩＤ又はパスワード若しくはその両方の入力ミスを認識することができる。一方、ＩＤ及びパスワードの組み合わせが正しい場合、サービス用データ格納部３４をＩＤで検索して当該ＩＤにリンクされているグループデータ・ユニットに含まれるサービス提供時間のデータを読み出し、今回のアクセス時刻がサービス提供時間内であるか判断する（ステップＳ６４）。もし、今回のアクセス時刻がサービス提供時間外であると判断された場合には、サービス提供時間外通知をユーザ端末Ａに送信する。ユーザ端末Ａは、サービス提供サーバ５からサービス提供時間外通知を受信し、表示装置に表示する（ステップＳ６５）。これによってユーザは現在サービス提供時間外であることを認識することができる。

今回のアクセス時刻がサービス提供時間内である場合には、サービス提供サーバ５は、ユーザ端末Ａに申し込みページ・データを送信する等の申し込み処理を実施する（ステップＳ６７）。ユーザ端末Ａも、必要なデータをサービス提供サーバ５に送信するなどの申し込み処理を実施する（ステップＳ６９）。申し込み処理自体は、従来と同じなので、これ以上述べない。

このような処理を実施することによって、サービス提供サーバ５では、サービス提供時間内の適正な申し込みにのみ対応するようになる。すなわち、アクセスが集中して処理に遅延を生じたりすることを避け、サービス提供サーバ５のダウンなどを防止することができる。なお、一度ログインしてしまっても、申し込みを行わずにログオフすれば、サービス提供時間内であれば再度ログインして申し込みを行うことが可能である。

次に、サービス提供時間の事後的な変更について説明する。サービス提供時間は予め管理者などによって設定されるものであるが、実際にサービス提供を開始すると、該当申請者の申し込みがスムーズに進み今後負荷が下がって次のグループについてのサービス提供時間が開始するまでにサービス提供サーバ５に余裕があると予測される場合や、該当申請者の申し込みがなかなか進まずこのままでは次のグループについてのサービス提供時間が開始すると申し込み時期が重なってサービス提供サーバ５が過負荷となるような場合がある。そのような場合には、例えば管理者などは、管理者端末７を操作して負荷軽減化サーバ３の管理処理部３５にサービス提供時間の変更を指示できる。

例えば管理者などが管理者端末７を操作して負荷軽減化サーバ３の管理処理部３５に、イベント番号とグループ名と変更後のサービス提供時間とをサービススケジュールの変更指示として通知させる。これに対して、負荷軽減化サーバ３の管理処理部３５は、管理者端末７から、イベント番号とグループ名と変更後のサービス提供時間とを含む、サービススケジュールの変更指示を受信し（図１３：ステップＳ７１）、サービス用データ格納部３４をイベント番号及びグループ名で検索して該当グループデータ・ユニットを特定し、受信したサービス提供時間を登録する（ステップＳ７３）。なお、複数のグループについてサービス提供時間の変更を行う場合には、複数のデータセットがサービススケジュールの変更指示に含まれるので、それぞれについてサービス提供時間の登録を行う。また、最初に管理者が管理者端末７を操作して、管理処理部３５からサービス用データ格納部３４に格納されているデータを読み出して参照するようにしても良い。

図１４では、Ａグループのサービス提供時間が、その開始時刻が２００７／１／２０ ８：００から２００７／１／２０ １２：００に変更された場面を示している。本例では、開始時刻の変更であるが終了時刻の変更や、開始時刻及び終了時刻の変更を行うようにしても良い。また、複数のグループの時刻が一度に変更されることもある。このような登録変更が行われれば、サービス提供サーバ５においても適切にサービス提供時間内であるか否かを判断することができる。

そして、管理処理部３５は、サービス提供時間の登録が行われたグループデータ・ユニット配下の利用権申請データ・ユニットを特定することによって、本サービススケジュールの変更指示の影響を受ける申請者を抽出して、特定された利用権申請データ・ユニットに含まれるメールアドレスにサービス提供時間の変更通知を送信する（ステップＳ７５）。これによって影響を受ける申請者は、サービス提供時間の変更を認識して、サービス提供サーバ５へのアクセスする時期を変更する。

そして、管理処理部３５は、ステップＳ４９で公開されたサービスタイムテーブルを、変更指示に応じて変更して公開する（ステップＳ７７）。このようにすれば、メールだけではなくＷｅｂページからも変更を確認することができるようになる。

以上のような処理を実施すれば、フレキシブルにサービス提供時間を変更することができ、サービス提供サーバ５の負荷を平準化することができるようになる。

なお、図１３の処理フローでは管理者などが管理者端末７からサービススケジュールの変更指示を送信する例を示したが、管理処理部３５が自動的にサービススケジュールの変更指示を生成するようにしても良い。例えば、管理処理部３５は、サービス提供サーバ５から、申し込みを行った申請者の累計数などのデータを例えば定期的に取得し、実際に申し込みを行った申請者の累計数が予め予測されている申請者の累計数カーブを上回っている場合には、例えば現在サービス提供時間中のグループより後のグループのサービス提供時間を後ろに所定時間だけずらすようにするサービススケジュールの変更指示を生成するようにしても良い。同様に、実際に申し込みを行った申請者の累計数が予め予測されている申請者の累計数カーブを下回っている場合には、例えば現在サービス提供時間中のグループより後のグループのサービス提供時間を前に所定時間だけずらすようにするサービススケジュールの変更指示を生成するようにしても良い。

以上述べたような処理を行うことによって、サービス提供サーバ５からサービスの提供を受けるユーザは、サービス提供サーバ５に繋がらない、サービス提供サーバ５が遅いなどのストレスから解放される。また、利用権を負荷軽減化サーバ３から取得することによって、サービス提供サーバ５が過負荷状態にある場合に比して短時間で作業が完了するようになる。さらに、サービス提供サーバ５の運営者は高価なロードバランサーを導入したりする必要がないため、費用負担が軽くなる。また、上で述べたようにユーザのストレスを軽減しているため顧客満足度が高まり、ユーザからのクレームが減るため、対応コストを減らすことができる。

以上本発明の実施の形態を説明したが、本発明はこれに限定されるものではない。上でも述べたが、負荷軽減化サーバ３は１台のコンピュータで実施するのではなく、複数台のコンピュータによって上記機能を実現するようにしても良い。このようにすれば利用権の申請時アクセスが集中する場合があるが、容易に対処できるようになる。なお、もともと利用権の申請のための処理負荷は非常に軽いものであって、ある程度１台のコンピュータでも対処可能である。

また、図１の機能ブロック図は一例であって必ずしも実際のプログラムモジュール構成とは同じにはならない。

上ではパスワードを負荷軽減化サーバ３で発行する例を示したが、ユーザによって設定するようにしても良い。また、上で述べた例では、画面識別番号を画面表示毎に発行してイベント番号と対応付けて保持する例を示したが、例えばイベント番号毎に予め発行しておき、イベント番号が同じであれば同じ画面識別番号が用いられる簡易な手法を採用するようにしても良い。

なお、ユーザ端末、管理者端末７、サービス提供サーバ５、負荷軽減化サーバ３は、コンピュータ装置であって、図１５に示すように当該コンピュータ装置においては、メモリ２５０１（記憶部）とＣＰＵ２５０３（処理部）とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ）及びＷｅｂブラウザを含むアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。このようなコンピュータは、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

本発明の実施の形態に係るシステム概要図である。 利用権申請のための処理フローを示す図である。 メニューページの画面例を示す図である。 受付データ格納部に格納されるデータの一例を示す図である。 利用権申請ページの画面例を示す図である。 受付データ格納部に格納されるデータの一例を示す図である。 後処理部の処理フローを示す図である。 サービス用データ格納部に格納されるデータの一例を示す図である。 利用権を通知するためのメールの一例を示す図である。 サービス用データ格納部に格納されるデータの変更を説明するための図である。 サービスタイムテーブルの一例を示す図である。 サービス提供サーバにおける処理の処理フローを示す図である。 サービス提供時間の変更を行う際の処理フローを示す図である。 サービス用データ格納部に格納されるデータの変更を説明するための図である。 コンピュータの機能ブロック図である。

符号の説明

１ ネットワーク ３ 負荷軽減化サーバ
５ サービス提供サーバ ７ 管理者端末
３１ 受付処理部 ３２ 受付データ格納部
３３ 後処理部 ３４ サービス用データ格納部
３５ 管理処理部

Claims (6)

1. 負荷を軽減すべきサービス提供サーバとは異なる負荷軽減化サーバにより実行される負荷軽減化処理方法であって、
   ユーザからの要求に応答して、前記ユーザのメールアドレスと前記要求の受付日時とを受付データ格納部に格納するステップと、
   前記受付データ格納部に格納されているレコードを前記要求の受付日時でソートし、上位から所定のルールに従って順番にグループ化して、グループ毎に前記レコードをサービス用データ格納部に格納するステップと、
   前記サービス用データ格納部に格納されている上位のグループに属するレコードから順番に読み出し、前記サービス提供サーバによる、当該グループに対するサービス時間についてのデータを含むメールを、当該レコードに含まれる前記メールアドレス宛に送信する送信ステップと、
   を含む負荷軽減化処理方法。
2. 前記送信ステップが、
   第１のグループに属するレコードについて処理した後所定の送信異常が検出された場合、前記第１のグループより１つ下位の第２のグループにおいて前記要求の受付日時の早いレコードの順に前記所定の送信異常に係るレコード数のレコードだけ前記第１のグループにグループ変更するように、前記サービス用データ格納部を更新するステップと、
   前記第１のグループに対するサービス時間についてのデータを含むメールと、前記グループ変更に係るレコードに含まれる前記メールアドレス宛に送信するステップと、
   を含む請求項１記載の負荷軽減化処理方法。
3. 前記サービス用データ格納部には、前記グループ毎に当該グループに対するサービス時間についてのデータが格納されており、
   前記グループに対するサービス時間についてのデータが変更可能である
   請求項１又は２記載の負荷軽減化処理方法。
4. 前記グループに対するサービス時間が変更になった場合に、当該グループに属するレコードを読み出し、当該グループに対するサービス時間のデータを含むメールを、当該レコードに含まれる前記メールアドレス宛に送信するステップ
   をさらに含む請求項３記載の負荷軽減化処理方法。
5. 請求項１乃至４のいずれか１つ記載の負荷軽減化処理方法をコンピュータに実行させるためのプログラム。
6. 負荷を軽減すべきサービス提供サーバとは異なる負荷軽減化サーバであって、
   ユーザからの要求に応答して、前記ユーザのメールアドレスと前記要求の受付日時とを受付データ格納部に格納する手段と、
   前記受付データ格納部に格納されているレコードを前記要求の受付日時でソートし、上位から所定のルールに従って順番にグループ化して、グループ毎に前記レコードをサービス用データ格納部に格納する手段と、
   前記サービス用データ格納部に格納されている上位のグループに属するレコードから順番に読み出し、前記サービス提供サーバによる、当該グループに対するサービス時間についてのデータを含むメールを、当該レコードに含まれる前記メールアドレス宛に送信する送信手段と、
   を有する負荷軽減化処理装置。

Images