JP2017062620A - 配信制御プログラム、配信制御方法、及び情報処理装置 - Google Patents

Abstract

【課題】他の装置からのアクセスに応じて処理を実行する装置の負荷を適切に制御する。【解決手段】特定の情報処理装置の負荷の情報を取得しＳ１９、取得した特定の情報処理装置の負荷の情報に基づく特定の情報処理装置の負荷の予測値の変動に応じてＳ２３、特定の情報処理装置をアクセス先とするアクセス先情報を含むメッセージの単位時間あたりの配信先の数を決定するＳ２７。【選択図】図１１

Description

本発明は、データの配信技術に関する。

ＥＣ（Electronic Commerce）サイトを運営する事業者は、メールマガジン或いはプッシュ通知等によってワントゥワンマーケティング（One to One marketing）を行う。ワントゥワンマーケティングとは、個々の顧客の趣向等に基づいて、顧客に対して個別に行うマーケティングのことである。

但し、メールマガジン或いはプッシュ通知等を受け取ったユーザが一度にＥＣサイトを訪問した場合、ＥＣサイト用のウェブサーバの負荷が上昇し、レスポンスの低下やウェブサーバのダウンといった事態を招くことがある。従来技術は、メール等の配信に起因して発生するウェブサーバの負荷の制御には着目していない。

特開２００１−２１７８６４号公報

従って、本発明の目的は、１つの側面では、他の装置からのアクセスに応じて処理を実行する装置の負荷を適切に制御するための技術を提供することである。

１つの態様では、特定の情報処理装置の負荷の情報を取得し、取得した特定の情報処理装置の負荷の情報に基づく特定の情報処理装置の負荷の予測値の変動に応じて、特定の情報処理装置をアクセス先とするアクセス先情報を含むメッセージの単位時間あたりの配信先の数を決定する処理を含む。

１つの側面では、他の装置からのアクセスに応じて処理を実行する装置の負荷を適切に制御できるようになる。

図１は、本実施の形態の概要を説明するための図である。 図２は、本実施の形態の概要を説明するための図である。 図３は、本実施の形態の概要を説明するための図である。 図４は、第１の実施の形態のシステム概要を示す図である。 図５は、仮想ウェブサーバの機能ブロック図である。 図６は、負荷データ格納部に格納されるデータの一例を示す図である。 図７は、仮想バッチサーバの機能ブロック図である。 図８は、顧客データ格納部に格納されるデータの一例を示す図である。 図９は、仮想配信サーバの機能ブロック図である。 図１０は、仮想ウェブサーバが実行する処理の処理フローを示す図である。 図１１は、仮想バッチサーバが実行する処理の処理フローを示す図である。 図１２は、第１データ格納部に格納されるデータの一例を示す図である。 図１３は、第２データ格納部に格納されるデータの一例を示す図である。 図１４は、配信計画データ格納部に格納されるデータの一例を示す図である。 図１５は、仮想配信サーバが実行する処理の処理フローを示す図である。 図１６は、仮想バッチサーバの機能ブロック図である。 図１７は、顧客データ格納部に格納されるデータの一例を示す図である。 図１８は、仮想バッチサーバが実行する処理の処理フローを示す図である。 図１９は、仮想バッチサーバが実行する処理の処理フローを示す図である。 図２０は、配信計画データ格納部に格納されるデータの一例を示す図である。 図２１は、仮想配信サーバが実行する処理の処理フローを示す図である。 図２２は、仮想バッチサーバの機能ブロック図である。 図２３は、顧客データ格納部に格納されるデータの一例を示す図である。 図２４は、仮想バッチサーバが実行する処理の処理フローを示す図である。 図２５は、第３データ格納部に格納されるデータの一例を示す図である。 図２６は、情報処理システムの構成を示す図である。 図２７は、コンピュータの機能ブロック図である。

［本実施の形態の概要］
例えば、ＥＣサイト用のウェブサーバの負荷（ここでは、ＣＰＵ（Central Processing Unit）負荷）が、おおよそ図１に示すように変動するとする。図１においては、縦軸がウェブサーバの負荷を表し、横軸が時刻を表す。

ここで、ＥＣサイトのＵＲＬ（Uniform Resource Locator）を含む、特売情報或いはタイムセール等を顧客に通知するためのメールが、ＥＣサイトの多数の顧客の端末に一斉に配信されたとする。これにより、顧客の端末からウェブサーバへのアクセスによって発生する負荷が通常時の負荷に上乗せされることになる。

例えば、１０時においてメールが一斉に配信され、配信先からウェブサーバへのアクセスが発生した場合、ウェブサーバの負荷は図２の破線に示すように変動する。すなわち、メール配信の直後から負荷が急激に上昇し、１３時あたりまで負荷が高い状態が続いた後、負荷が低い状態に戻る。図２及び図３においては、長方形の図形はメール配信を表し、縦の長さが長いほどメールの配信先数が多いとする。

このように、多数の顧客に対してメールを一斉に配信すると、ウェブサーバの負荷が非常に高い状態に達し、許容される負荷の基準を超えてしまうことがある。許容される負荷の基準を超えると、レスポンスの低下或いはウェブサーバのダウンといった事態を招くことがあるため好ましくない。

そこで本実施の形態においては、メールを一斉に配信するのではなく、配信時点を分散する。但し、単純に各配信時点において同じ数のメールを配信するのではなく、ウェブサーバの負荷に応じて配信先数を変える。例えば図３に示すように、ウェブサーバの負荷が低い状態にある場合には相対的に多数のメールを配信し、ウェブサーバの負荷が高い状態にある場合には相対的に少数のメールを配信する。これにより、図３の破線に示すように、ウェブサーバの負荷を平準化することが可能になる。以下では、より具体的に本実施の形態を説明する。

［実施の形態１］
図４に、第１の実施の形態のシステム概要を示す。第１実施の形態の主要な処理を実行する情報処理装置１は、ＥＣサイトを運営する事業者の物理サーバであり、インターネット３に接続される。顧客端末５ａ乃至５ｃは、事業者の顧客が操作する端末であり、例えばパーソナルコンピュータ及びスマートフォン等である。顧客端末５ａ乃至５ｃは、インターネット３に接続される。なお、図４の例では顧客端末の数は３であるが、数に限定は無い。

情報処理装置１においては、仮想ウェブサーバ１０と、仮想バッチサーバ１１と、仮想配信サーバ１２とが実行される。仮想ウェブサーバ１０と、仮想バッチサーバ１１と、仮想配信サーバ１２とは仮想マシンであり、互いに通信を行うことができる。

仮想ウェブサーバ１０は、顧客端末５ａ乃至５ｃから受信したウェブアクセスのメッセージ（例えば、ＨＴＴＰ（HyperText Transfer Protocol）のリクエストメッセージ）を処理する。仮想バッチサーバ１１は、仮想配信サーバ１２が配信するメール（例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）のメッセージ）の各時間帯の配信先数を決定する処理を実行する。仮想配信サーバ１２は、仮想バッチサーバ１１の処理結果に従って又は予め定められた設定に従って、配信先の顧客端末に対してメールを配信する。

図５に、仮想ウェブサーバ１０の機能ブロック図を示す。仮想ウェブサーバ１０は、負荷取得部１０１と、負荷データ格納部１０２とを含む。負荷取得部１０１は、仮想ウェブサーバ１０の負荷のデータ（第１の実施の形態においては、ＣＰＵ負荷。より具体的には、ＣＰＵ使用率）を、例えば仮想ウェブサーバ１０のＯＳ（Operating System）から取得し、負荷データ格納部１０２に格納する。なお、ＣＰＵ負荷は、情報処理装置１のＣＰＵのうち仮想ウェブサーバ１０に割り当てられたＣＰＵの負荷のことである。但し、仮想ウェブサーバ１０に対しては、コア単位でＣＰＵが割り当てられてもよい。

図６に、負荷データ格納部１０２に格納されるデータの一例を示す。図６の例では、日時のデータと、ＣＰＵ負荷（単位は％）のデータとが格納される。なお、仮想バッチサーバ１１の負荷データ格納部１１２にも同様のフォーマットでデータが格納される。

図７に、仮想バッチサーバ１１の機能ブロック図を示す。仮想バッチサーバ１１は、テンプレート格納部１１０と、顧客データ格納部１１１と、負荷データ格納部１１２と、処理部１１３と、第１データ格納部１１４と、第２データ格納部１１５と、配信計画データ格納部１１６とを含む。処理部１１３は、第１算出部１１３０と、第２算出部１１３１とを含む。

第１算出部１１３０は、テンプレート格納部１１０に格納されたデータ及び負荷データ格納部１１２に格納されたデータに基づき処理を実行し、処理結果を第１データ格納部１１４及び第２データ格納部１１５に格納する。第２算出部１１３１は、第２データ格納部１１５に格納されたデータ及び顧客データ格納部１１１に格納されたデータに基づき処理を実行し、処理結果を配信計画データ格納部１１６に格納する。

図８に、顧客データ格納部１１１に格納されるデータの一例を示す。図８の例では、各エントリの番号と、顧客番号と、顧客のメールアドレスとが格納される。なお、仮想配信サーバ１２の顧客データ格納部１２１にも同様のフォーマットでデータが格納される。

図９に、仮想配信サーバ１２の機能ブロック図を示す。仮想配信サーバ１２は、テンプレート格納部１２０と、顧客データ格納部１２１と、配信計画データ格納部１２２と、配信部１２３とを含む。配信部１２３は、テンプレート格納部１２０に格納されたデータ、顧客データ格納部１２１に格納されたデータ、及び配信計画データ格納部１２２に格納されたデータに基づき、配信先の顧客端末に対してメールを配信する処理を実行する。

次に、図１０乃至１５を用いて、第１の実施の形態におけるシステムにおいて行われる処理を説明する。

まず、仮想ウェブサーバ１０が実行する処理を説明する。本処理は、例えば一定時間毎に実行される。

仮想ウェブサーバ１０の負荷取得部１０１は、仮想ウェブサーバ１０のＣＰＵ負荷データをＯＳから取得する（図１０：ステップＳ１）。

仮想ウェブサーバ１０の負荷取得部１０１は、ステップＳ１において取得したＣＰＵ負荷データを負荷データ格納部１０２に格納する（ステップＳ３）。そして処理は終了する。

以上のような処理を実行しておけば、ＣＰＵ負荷データを後の処理に利用できるようになる。

次に、図１１乃至１４を用いて、仮想バッチサーバ１１が実行する処理を説明する。本処理は、例えば、対象とする時間帯（第１実施の形態においては、９時から１８時）の開始より前に実行される。

まず、仮想バッチサーバ１１の第１算出部１１３０は、テンプレート格納部１１０に格納されている、配信すべきメールのテンプレートが、仮想ウェブサーバ１０が提供するＥＣサイトのＵＲＬを含むか判定する（図１１：ステップＳ１１）。

配信すべきメールのテンプレートがＵＲＬを含まない場合（ステップＳ１１：Ｎｏルート）、第１算出部１１３０は、メール配信の要求を生成する（ステップＳ１３）。ステップＳ１３においては、予め定められた設定（例えば、所定の時刻に一括配信をするという設定）に従ったメール配信の要求が生成される。

そして、第１算出部１１３０は、生成したメール配信の要求を、仮想配信サーバ１２に送信する（ステップＳ１５）。そして処理は終了する。

これに対し、配信すべきメールのテンプレートがＵＲＬを含む場合（ステップＳ１１：Ｙｅｓルート）、第１算出部１１３０は、ＣＰＵ負荷データの要求を仮想ウェブサーバ１０に送信する（ステップＳ１７）。これに応じ、仮想ウェブサーバ１０はＣＰＵ負荷データの要求を仮想バッチサーバ１１から受信し、負荷データ格納部１０２に格納されたＣＰＵ負荷データを読み出す。ここでは、例えば、直近の所定期間についてのＣＰＵ負荷データが読み出される。

仮想ウェブサーバ１０は、読み出したＣＰＵ負荷データを仮想バッチサーバ１１に送信する。これに応じ、仮想バッチサーバ１１は、ＣＰＵ負荷データを仮想ウェブサーバ１０から受信し（ステップＳ１９）、負荷データ格納部１１２に格納する。

仮想バッチサーバ１１の第１算出部１１３０は、負荷データ格納部１１２に格納されたＣＰＵ負荷データから、前日について平均ＣＰＵ負荷のデータを時間帯毎に生成し（ステップＳ２１）、第１データ格納部１１４に格納する。図１２に、第１データ格納部１１４に格納されるデータの一例を示す。図１２の例では、日付のデータと、時間帯を表すデータと、平均ＣＰＵ負荷のデータとが格納される。ステップＳ２１においては、各時間帯に属する時刻のＣＰＵ負荷の平均に相当する平均ＣＰＵ負荷のデータが生成される。なお、第１の実施の形態においては、０時から９時までの時間帯と１８時から２４時までの時間帯とを対象としていないが、これらの時間帯をも対象としてもよい。

第１算出部１１３０は、第１データ格納部１１４に格納されたデータから、配信先数の比率を時間帯毎に算出し（ステップＳ２３）、第２データ格納部１１５に格納する。図１３に、第２データ格納部１１５に格納されるデータの一例を示す。図１３の例では、日付のデータと、時間帯を表すデータと、平均ＣＰＵ負荷のデータと、１００／平均ＣＰＵ負荷に相当する値と、配信先数の比率（単位は％）とが算出される。配信先数の比率は、対象の（１００／平均ＣＰＵ負荷）を、同一の日付における（１００／平均ＣＰＵ負荷）の合計で割った数に相当する。これにより、平均ＣＰＵ負荷が高い時間帯ほど配信先数を少なくすることができる。

第２算出部１１３１は、顧客データ格納部１１１に登録されている顧客数（すなわち、メールが配信されるべき配信先の数）を計数する（ステップＳ２５）。

第２算出部１１３１は、ステップＳ２５において計数された顧客数に配信先数の比率を乗じる処理を各時間帯について実行することで各時間帯の配信先数を算出し（ステップＳ２７）、算出結果を配信計画データ格納部１１６に格納する。図１４に、配信計画データ格納部１１６に格納されるデータの一例を示す。図１４の例では、時間帯を表すデータと、配信先数とが格納される。なお、仮想配信サーバ１２の配信計画データ格納部１２２にも同様のフォーマットでデータが格納される。

第２算出部１１３１は、配信計画データ格納部１１６に格納されたデータを含む、メール配信の要求を生成し（ステップＳ２９）、メール配信の要求を仮想配信サーバ１２に送信する（ステップＳ３１）。そして処理は終了する。

以上のような処理を実行すれば、仮想ウェブサーバ１０の負荷が考慮された配信計画に従ってメールを配信できるようになる。

次に、図１５を用いて、仮想配信サーバ１２が実行する処理を説明する。

まず、仮想配信サーバ１２の配信部１２３は、メール配信の要求を仮想バッチサーバ１１から受信し（図１５：ステップＳ４１）、配信計画データ格納部１２２に格納する。

配信部１２３は、配信計画データ格納部１２２に格納されたメール配信の要求が、各時間帯の配信先数の情報を含むか判定する（ステップＳ４３）。メール配信の要求が、各時間帯の配信先数の情報を含む場合（ステップＳ４３：Ｙｅｓルート）、配信部１２３は、テンプレート格納部１２０に格納されたデータ（すなわち、配信すべきメールのテンプレート）に基づきメールを生成する。そして、配信部１２３は、ステップＳ４３の処理時点が属する日の各時間帯において、メール配信の要求において指定された配信先数のメールを配信する（ステップＳ４５）。そして処理は終了する。ステップＳ４５においては、例えば、各時間帯において配信先数分の顧客がランダムに選択される。

一方、メール配信の要求が、各時間帯の配信先数の情報を含まない場合（ステップＳ４３：Ｎｏルート）、配信部１２３は、テンプレート格納部１２０に格納されたデータに基づきメールを生成する。そして、配信部１２３は、メール配信の要求に従って（例えば、１０時に一括で）、顧客データ格納部１２１に登録された各顧客の顧客端末に対してメールを配信する（ステップＳ４７）。そして処理を終了する。

以上のような処理を実行すれば、メールに含まれるＵＲＬのクリック等によって発生する、仮想ウェブサーバ１０へのアクセスが、仮想ウェブサーバ１０の負荷に応じて分散されるようになる。これにより、仮想ウェブサーバ１０の負荷を平準化することができるようになる。

［実施の形態２］
次に、第２の実施の形態について説明する。第２の実施の形態においては、各時間帯において配信するメールの数だけではなく、各時間帯の配信先も決定される。

第２の実施の形態のシステム概要は、第１の実施の形態のシステム概要と同じであるが、第２の実施の形態における仮想バッチサーバ１１が、第１の実施の形態における仮想バッチサーバ１１とは異なる。図１６に、第２の実施の形態における仮想バッチサーバ１１の機能ブロック図を示す。仮想バッチサーバ１１は、テンプレート格納部１１０と、顧客データ格納部１１１と、負荷データ格納部１１２と、処理部１１３と、第１データ格納部１１４と、第２データ格納部１１５と、配信計画データ格納部１１６とを含む。処理部１１３は、第１算出部１１３０と、第２算出部１１３１と、配信先決定部１１３２とを含む。

第１算出部１１３０は、テンプレート格納部１１０に格納されたデータ及び負荷データ格納部１１２に格納されたデータに基づき処理を実行し、処理結果を第１データ格納部１１４及び第２データ格納部１１５に格納する。第２算出部１１３１は、第２データ格納部１１５に格納されたデータ及び顧客データ格納部１１１に格納されたデータに基づき処理を実行し、処理結果を配信先決定部１１３２に通知する。配信先決定部１１３２は、顧客データ格納部１１１に格納されているデータ及び第２算出部１１３１から受け取った処理結果に基づき処理を実行し、処理結果を配信計画データ格納部１１６に格納する。

図１７に、第２の実施の形態における顧客データ格納部１１１に格納されるデータの一例を示す。図１７の例では、エントリの番号と、顧客番号と、顧客のメールアドレスと、顧客が購入した商品の金額の合計（期間は、例えば直近の１か月）を表すデータとが格納される。第２の実施の形態においては、購入金額合計が多い顧客が優先度が高い顧客であるとみなされ、より早い時間帯にメールが配信される。なお、第２の実施の形態における仮想配信サーバ１２の顧客データ格納部１２１にも同様のフォーマットでデータが格納される。

次に、図１８乃至２０を用いて、第２の実施の形態のシステムにおいて行われる処理を説明する。但し、仮想ウェブサーバ１０が実行する処理は第１の実施の形態において説明したとおりであるので、仮想バッチサーバ１１が実行する処理及び仮想配信サーバ１２が実行する処理を説明する。

まず、仮想バッチサーバ１１が実行する処理を説明する。本処理は、例えば、対象とする時間帯（第２実施の形態においては、９時から１８時）の開始より前に実行される。

仮想バッチサーバ１１の第１算出部１１３０は、テンプレート格納部１１０に格納されている、配信すべきメールのテンプレートが、仮想ウェブサーバ１０が提供するＥＣサイトのＵＲＬを含むか判定する（図１８：ステップＳ５１）。

配信すべきメールのテンプレートがＵＲＬを含まない場合（ステップＳ５１：Ｎｏルート）、第１算出部１１３０は、メール配信の要求を生成する（ステップＳ５３）。ステップＳ５３においては、予め定められた設定（例えば、所定の時刻に一括配信を行うという設定）に従ったメール配信の要求が生成される。本ステップにおいて生成されるメール配信の要求に、メール配信の時間帯を指定するデータを含ませるようにしてもよい。

そして、第１算出部１１３０は、生成したメール配信の要求を、仮想配信サーバ１２に送信する（ステップＳ５５）。そして処理は終了する。

これに対し、配信すべきメールのテンプレートがＵＲＬを含む場合（ステップＳ５１：Ｙｅｓルート）、第１算出部１１３０は、ＣＰＵ負荷データの要求を仮想ウェブサーバ１０に送信する（ステップＳ５７）。これに応じ、仮想ウェブサーバ１０はＣＰＵ負荷データの要求を仮想バッチサーバ１１から受信し、負荷データ格納部１０２に格納されたＣＰＵ負荷データを読み出す。ここでは、例えば、直近の所定期間についてのＣＰＵ負荷データが読み出される。

仮想ウェブサーバ１０は、読み出したＣＰＵ負荷データを仮想バッチサーバ１１に送信する。これに応じ、仮想バッチサーバ１１は、ＣＰＵ負荷データを仮想ウェブサーバ１０から受信し（ステップＳ５９）、負荷データ格納部１１２に格納する。

仮想バッチサーバ１１の第１算出部１１３０は、負荷データ格納部１１２に格納された負荷データから、前日について平均ＣＰＵ負荷のデータを時間帯毎に生成し（ステップＳ６１）、第１データ格納部１１４に格納する。ステップＳ６１においては、各時間帯に属する時刻のＣＰＵ負荷の平均に相当する平均ＣＰＵ負荷のデータが生成される。なお、第２の実施の形態においても、０時から９時までの時間帯と１８時から２４時までの時間帯とを対象としていないが、これらの時間帯をも対象としてもよい。

第１算出部１１３０は、第１データ格納部１１４に格納されたデータから、配信先数の比率を時間帯毎に算出し（ステップＳ６３）、第２データ格納部１１５に格納する。配信先数の比率の算出方法は、第１の実施の形態の説明において述べたとおりである。

第２算出部１１３１は、顧客データ格納部１１１に登録されている顧客数（すなわち、メールが配信されるべき配信先の数）を計数する（ステップＳ６５）。

第２算出部１１３１は、ステップＳ６５において計数された顧客数に配信先数の比率を乗じる処理を各時間帯について実行することで各時間帯の配信先数を算出し（ステップＳ６７）、算出結果を配信先決定部１１３２に通知する。そして、処理は端子Ａを介して図１９のステップＳ６９の処理に移行する。

図１９の説明に移行し、配信先決定部１１３２は、顧客データ格納部１１１のエントリを、購入金額合計をキーにして降順に並べ替える（図１９：ステップＳ６９）。

配信先決定部１１３２は、並べ替え後の順番が先である（すなわち、購入金額合計が多い）顧客ほど先に配信されるように、各時間帯の配信先を決定し（ステップＳ７１）、決定の結果を配信計画データ格納部１１６に格納する。例えば、最も早い時間帯である９時から１０時までの時間帯の配信先数が１０である場合には、購入金額合計が最も多い顧客から順に１０名が選択され、１０時から１１時までの時間帯の配信先数が５である場合には、購入金額合計が１１番目に多い顧客から順に５名が選択される。

図２０に、第２の実施の形態の配信計画データ格納部１１６に格納されるデータの一例を示す。図２０の例では、時間帯を表すデータと、配信先を表すデータ（ここでは、顧客番号）とが格納される。なお、仮想配信サーバ１２の配信計画データ格納部１２２にも同様のフォーマットでデータが格納される。

処理部１１３は、配信計画データ格納部１１６に格納されたデータを含む、メール配信の要求を生成し（ステップＳ７３）、メール配信の要求を仮想配信サーバ１２に送信する（ステップＳ７５）。そして処理は終了する。

以上のような処理を実行すれば、仮想配信サーバ１２が、ＥＣサイトでの購入金額合計が高い顧客（すなわち優良顧客）に対して優先的に配信を行えるようになる。

次に、図２１を用いて、仮想配信サーバ１２が実行する処理を説明する。

まず、仮想配信サーバ１２の配信部１２３は、メール配信の要求を仮想バッチサーバ１１から受信し（図２１：ステップＳ８１）、配信計画データ格納部１２２に格納する。

配信部１２３は、配信計画データ格納部１２２に格納されたメール配信の要求が、各時間帯の配信先の情報を含むか判定する（ステップＳ８３）。メール配信の要求が、各時間帯の配信先の情報を含む場合（ステップＳ８３：Ｙｅｓルート）、配信部１２３は、テンプレート格納部１２０に格納されたデータ（すなわち、配信すべきメールのテンプレート）に基づきメールを生成する。そして、配信部１２３は、ステップＳ８３の処理時点が属する日の各時間帯において、メール配信の要求において指定された配信先に対してメールを配信する（ステップＳ８５）。そして処理は終了する。

一方、メール配信の要求が、各時間帯の配信先の情報を含まない場合（ステップＳ８３：Ｎｏルート）、配信部１２３は、テンプレート格納部１２０に格納されたデータに基づきメールを生成する。そして、配信部１２３は、メール配信の要求に従って（例えば、１０時に一括で）、顧客データ格納部１２１に登録された各顧客の顧客端末に対してメールを配信する（ステップＳ８７）。そして処理を終了する。

以上のような処理を実行すれば、メールに含まれるＵＲＬのクリック等によって発生する、仮想ウェブサーバ１０へのアクセスが、仮想ウェブサーバ１０の負荷に応じて分散されるようになる。これにより、仮想ウェブサーバ１０の負荷を平準化することができるようになる。また、優良顧客に対して優先的に配信を行うことができるので、コンバージョン率を向上させることができるようになる。また、例えば数量限定セール及び期間限定セールの情報を含むメールの場合、できるだけ早くメールを受け取ることが顧客にとっても好ましいため、優良顧客の顧客満足度向上にもつながる。

［実施の形態３］
次に、第３の実施の形態について説明する。第３の実施の形態においては、第２の実施の形態の方法とは異なる方法によって各時間帯の配信先が決定される。

第３の実施の形態のシステム概要は、第１の実施の形態のシステム概要と同じであるが、第３の実施の形態における仮想バッチサーバ１１が、第１の実施の形態における仮想バッチサーバ１１とは異なる。図２２に、第３の実施の形態における仮想バッチサーバ１１の機能ブロック図を示す。仮想バッチサーバ１１は、テンプレート格納部１１０と、顧客データ格納部１１１と、負荷データ格納部１１２と、処理部１１３と、第１データ格納部１１４と、第２データ格納部１１５と、配信計画データ格納部１１６と、第３データ格納部１１７とを含む。処理部１１３は、第１算出部１１３０と、第２算出部１１３１と、配信先決定部１１３２とを含む。

第１算出部１１３０は、テンプレート格納部１１０に格納されたデータ及び負荷データ格納部１１２に格納されたデータに基づき処理を実行し、処理結果を第１データ格納部１１４及び第２データ格納部１１５に格納する。第２算出部１１３１は、第２データ格納部１１５に格納されたデータ及び顧客データ格納部１１１に格納されたデータに基づき処理を実行し、処理結果を配信先決定部１１３２に通知する。配信先決定部１１３２は、顧客データ格納部１１１に格納されているデータ及び第２算出部１１３１から受け取った処理結果に基づき処理を実行し、処理結果を配信計画データ格納部１１６に格納する。なお、配信先決定部１１３２の処理途中のデータは、第３データ格納部１１７に格納される。

図２３に、第３の実施の形態における顧客データ格納部１１１に格納されるデータの一例を示す。図２３の例では、各エントリに付された通番と、顧客番号と、顧客のメールアドレスと、顧客が購入した商品の金額の合計（期間は、例えば直近の１か月）を表すデータと、顧客がＥＣサイトを訪問する頻度（例えば、直近の１か月においてＥＣサイトを訪問した回数）を表すデータとが格納される。なお、第３の実施の形態における仮想配信サーバ１２の顧客データ格納部１２１にも同様のフォーマットでデータが格納される。

次に、図２４及び２５を用いて、第３の実施の形態のシステムにおいて行われる処理を説明する。但し、仮想ウェブサーバ１０が実行する処理及び仮想配信サーバ１２が実行する処理は第２の実施の形態において説明したとおりである。また、仮想バッチサーバ１１が実行する処理のうち、端子Ａまでの処理が第２の実施の形態と同じであるので、端子Ａ以降の処理を説明する。

まず、配信先決定部１１３２は、顧客データ格納部１１１のエントリを、購入金額合計をキーにして降順に並べ替える（図２４：ステップＳ９１）。

配信先決定部１１３２は、顧客データ格納部１１１に格納された、ＥＣサイトの訪問頻度に対して一定の値を乗じることで、アクセス指標値を顧客毎に算出する（ステップＳ９３）。そして、顧客データ格納部１１１に格納されているデータに算出されたアクセス指標値を付したデータを、第３データ格納部１１７に格納する。なお、一定の値とは、例えば、メールが配信されるべき配信先の数（すなわち、顧客の数）を各顧客の訪問頻度の合計値で除した値である。

図２５に、第３データ格納部１１７に格納されるデータの一例を示す。図２５の例では、各エントリに付された通番と、顧客番号と、顧客のメールアドレスと、顧客が購入した商品の金額の合計（期間は、例えば直近の１か月）を表すデータと、顧客がＥＣサイトを訪問する頻度（例えば、直近の１か月においてＥＣサイトを訪問した回数）を表すデータと、アクセス指標値とが格納される。

配信先決定部１１３２は、各時間帯においてアクセス指標値の合計がその時間帯の配信先数以下であるという条件が満たされるように、且つ、並べ替え後の順番が先である（すなわち、購入金額合計が多い）顧客ほど先に配信されるように、各時間帯の配信先を決定し（ステップＳ９５）、決定の結果を配信計画データ格納部１１６に格納する。配信計画データ格納部１１６に格納されるデータのフォーマットは、第２の実施の形態の説明で述べたとおりである。

処理部１１３は、配信計画データ格納部１１６に格納されたデータを含む、メール配信の要求を生成し（ステップＳ９７）、メール配信の要求を仮想配信サーバ１２に送信する（ステップＳ９９）。そして処理は終了する。

訪問頻度が高い配信先は訪問頻度が低い配信先よりも仮想ウェブサーバ１０の負荷を上昇させるので、たとえ１の配信先であっても１以上の配信先に相当するとみなすことができる場合がある。逆に、訪問頻度が低い配信先は訪問頻度が高い配信先よりも仮想ウェブサーバ１０の負荷を上昇させないので、たとえ１の配信先であっても１以下の配信先に相当するとみなすことができる場合がある。そこで、上で述べたようにすれば、ＥＣサイトへの訪問頻度を考慮しつつ各時間帯の配信先を適切に決定できるようになる。

以上本発明の一実施の形態を説明したが、本発明はこれに限定されるものではない。例えば、上で説明した情報処理装置１の機能ブロック構成は実際のプログラムモジュール構成に一致しない場合もある。

また、上で説明した各テーブルの構成は一例であって、上記のような構成でなければならないわけではない。さらに、処理フローにおいても、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

また、ＵＲＬではなく、ウェブサイトに到達するための検索キーワード又はウェブサイト名等であってもよい。

また、仮想ウェブサーバ１０が負荷データの要求を受信した場合に、ステップＳ１７の処理時点が属する日の前日の負荷データだけを読み出してもよい。また、使用する負荷データは、前日の負荷データには限られない。例えば、ステップＳ１７の処理時点の曜日と同じ曜日の負荷データであって直近の負荷データを読み出してもよい。さらに、複数の日の負荷データを使用するようにしてもよい。

また、仮想バッチサーバ１１は顧客データ格納部１１１内のデータ及びテンプレート格納部１１０内のデータを使用する場合に、仮想配信サーバ１２から取得してもよい。このようにすれば、仮想バッチサーバ１１が顧客データ格納部１１１及びテンプレート格納部１１０を有しなくて済む。

また、ＣＰＵ負荷ではなく、仮想ウェブサーバ１０に対するアクセスの状況（例えば、時間帯毎のアクセス数）に基づき仮想バッチサーバ１１が処理を実行してもよい。

また、ウェブサーバ、バッチサーバ及び配信サーバが物理サーバであってもよい。例えば図２６に示すように、物理サーバであるウェブサーバ７０、バッチサーバ７１及び配信サーバ７２を有する情報処理システム７に対しても本実施の形態を適用することが可能である。

なお、上で述べた情報処理装置１は、コンピュータ装置であって、図２７に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ：Hard Disk Drive）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。ＣＰＵ２５０３は、アプリケーション・プログラムの処理内容に応じて表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、所定の動作を行わせる。また、処理途中のデータについては、主としてメモリ２５０１に格納されるが、ＨＤＤ２５０５に格納されるようにしてもよい。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及びアプリケーション・プログラムなどのプログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。

以上述べた本発明の実施の形態をまとめると、以下のようになる。

本実施の形態に係る配信制御方法は、（Ａ）特定の情報処理装置の負荷の情報を取得し、（Ｂ）取得した特定の情報処理装置の負荷の情報に基づき、特定の情報処理装置がアクセス先であることを表すアクセス先情報を含むメッセージの配信先の数を、時間帯毎に決定する処理を含む。

アクセス先の情報を含むメッセージが送信されると、特定の情報処理装置に対するアクセスが発生し、特定の情報処理装置の負荷が上昇する可能性がある。そこで、上で述べたような処理を実行すれば、特定の情報処理装置の負荷を適切に制御できるようになる。

また、本配信制御方法は、（Ｃ）データ格納部に配信先毎に格納されている、配信の優先度に相当する情報に基づき、配信の優先度がより高い配信先に対してより早い時間帯に配信を行うように、決定された数の配信先を時間帯毎に決定する処理をさらに含んでもよい。このようにすれば、例えば早く受け取った方が有利な情報等を、優先度が高い配信先に対してより早く配信できるようになる。

また、上で述べたデータ格納部は、特定の情報処理装置へのアクセスの頻度を配信先毎にさらに格納してもよい。そして、本配信制御方法は、（Ｄ）データ格納部に格納されているアクセスの頻度に対して所定の値を乗じることで、第１の値を配信先毎に算出する処理をさらに含んでもよい。そして、決定された数の配信先を時間帯毎に決定する処理において、（ｃ１）各時間帯において第１の値の合計が配信先の数以下であるという条件が満たされるように、且つ、配信の優先度がより高い配信先に対してより早い時間帯に配信を行うように、決定された数の配信先を時間帯毎に決定してもよい。アクセスの頻度が高い配信先はアクセスの頻度が低い配信先よりも特定の情報処理装置の負荷を上昇させるので、たとえ１の配信先であっても複数の配信先に相当するとみなすことができる場合がある。そこで、上で述べたようにすれば、アクセスの頻度を考慮しつつ各時間帯の配信先を決定できるようになる。

また、本配信制御方法は、（ｄ）メッセージのテンプレートがアクセス先情報を含むか判定する処理をさらに含んでもよい。そして、（ｃ２）メッセージのテンプレートがアクセス先情報を含むと判定された場合、配信先の数を時間帯毎に決定する処理において、取得した特定の情報処理装置の負荷の情報に基づき、メッセージの配信先の数を時間帯毎に決定してもよい。メッセージのテンプレートがアクセス先情報を含まない場合、メッセージのテンプレートがアクセス先情報を含む場合と比べると、特定の情報処理装置へのアクセスが発生する可能性が低い。そこで、上で述べたようにすれば、処理の実行機会を制限し、コンピュータの処理負荷を軽減できるようになる。

また、メッセージの配信先の数を時間帯毎に決定する処理において、（ｂ１）特定の情報処理装置の負荷が高い時間帯ほどメッセージの配信先の数が少なくなるように、メッセージの配信先の数を時間帯毎に決定してもよい。このようにすれば、特定の情報処理装置の負荷が極端に上昇するような事態を防げるようになる。

また、特定の情報処理装置の負荷の情報は、前日又は同じ曜日の特定の情報処理装置の負荷の情報であってもよい。前日の負荷は本日の負荷と同じように変動する場合があり、また、同じ曜日の負荷は同じように変動する場合がある。従って、上で述べたようにすれば、配信先の数を適切にすることができるようになる。

また、メッセージの配信先の数を時間帯毎に決定する処理において、（ｂ２）取得した特定の情報処理装置の負荷の情報に基づき、特定の情報処理装置の負荷を時間帯毎に算出してもよい。

また、メッセージの配信先の数を時間帯毎に決定する処理において、（ｂ３）取得した特定の情報処理装置の負荷の情報に基づき、特定の情報処理装置の負荷を時間帯毎に算出し、（ｂ４）算出された特定の情報処理装置の時間帯毎の負荷の逆数に基づき、配信先の数の比率を時間帯毎に算出し、（ｂ５）各時間帯について、算出された配信先の数の比率とメッセージが配信されるべき配信先の数とを乗じることによって、メッセージの配信先の数を時間帯毎に決定してもよい。

なお、上記方法による処理をプロセッサに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

以上の実施例を含む実施形態に関し、さらに以下の付記を開示する。

（付記１）
コンピュータに、
特定の情報処理装置の負荷の情報を取得し、
取得した前記特定の情報処理装置の負荷の情報に基づく前記特定の情報処理装置の負荷の予測値の変動に応じて、前記特定の情報処理装置をアクセス先とするアクセス先情報を含むメッセージの単位時間あたりの配信先の数を決定する、
処理を実行させる配信制御プログラム。

（付記２）
前記コンピュータに、
データ格納部に配信先毎に格納されている、配信の優先度に相当する情報に基づき、配信の優先度がより高い配信先に対してより早い時間に配信を行うように、決定された前記数の配信先を各単位時間について決定する、
処理をさらに実行させる付記１記載の配信制御プログラム。

（付記３）
前記データ格納部は、前記特定の情報処理装置へのアクセスの頻度を配信先毎にさらに格納し、
前記コンピュータに、
前記データ格納部に格納されているアクセスの頻度に対して所定の値を乗じることで、第１の値を配信先毎に算出する、
処理をさらに実行させ、
決定された前記数の配信先を各単位時間について決定する処理において、
各単位時間において前記第１の値の合計が配信先の数以下であるという条件が満たされるように、且つ、配信の優先度がより高い配信先に対してより早い時間に配信を行うように、決定された前記数の配信先を各単位時間について決定する、
付記２記載の配信制御プログラム。

（付記４）
前記コンピュータに、
前記メッセージのテンプレートが前記アクセス先情報を含むか判定する、
処理をさらに実行させ、
前記メッセージのテンプレートが前記アクセス先情報を含むと判定された場合、前記単位時間あたりの配信先の数を決定する処理において、取得した前記特定の情報処理装置の負荷の情報に基づき、前記単位時間あたりの配信先の数を決定する
付記１乃至３のいずれか１つ記載の配信制御プログラム。

（付記５）
前記単位時間あたりの配信先の数を決定する処理において、
前記特定の情報処理装置の負荷が高い単位時間ほど配信先の数が少なくなるように、前記単位時間あたりの配信先の数を決定する、
付記１乃至４のいずれか１つ記載の配信制御プログラム。

（付記６）
前記特定の情報処理装置の負荷の情報は、前日又は同じ曜日の前記特定の情報処理装置の負荷の情報である、
付記１乃至５のいずれか１つ記載の配信制御プログラム。

（付記７）
前記単位時間あたりの配信先の数を決定する処理において、
取得した前記特定の情報処理装置の負荷の情報に基づき、前記特定の情報処理装置の負荷を各単位時間について算出する、
付記１乃至６のいずれか１つ記載の配信制御プログラム。

（付記８）
前記単位時間あたりの配信先の数を決定する処理において、
取得した前記特定の情報処理装置の負荷の情報に基づき、前記特定の情報処理装置の負荷を各単位時間について算出し、
算出された前記特定の情報処理装置の各単位時間の負荷の逆数に基づき、配信先の数の比率を各単位時間について算出し、
各単位時間について、算出された前記配信先の数の比率と前記メッセージが配信されるべき配信先の数とを乗じることによって、前記単位時間あたりの配信先の数を決定する、
付記１乃至６のいずれか１つ記載の配信制御プログラム。

（付記９）
コンピュータが、
特定の情報処理装置の負荷の情報を取得し、
取得した前記特定の情報処理装置の負荷の情報に基づく前記特定の情報処理装置の負荷の予測値の変動に応じて、前記特定の情報処理装置をアクセス先とするアクセス先情報を含むメッセージの単位時間あたりの配信先の数を決定する、
処理を実行する配信制御方法。

（付記１０）
特定の情報処理装置の負荷の情報を取得する取得部と、
取得した前記特定の情報処理装置の負荷の情報に基づく前記特定の情報処理装置の負荷の予測値の変動に応じて、前記特定の情報処理装置をアクセス先とするアクセス先情報を含むメッセージの単位時間あたりの配信先の数を決定する決定部と、
処理を実行する情報処理装置。

１ 情報処理装置 １０ 仮想ウェブサーバ
１１ 仮想バッチサーバ １２ 仮想配信サーバ
１０１ 負荷取得部 １０２ 負荷データ格納部
１１０ テンプレート格納部 １１１ 顧客データ格納部
１１２ 負荷データ格納部 １１３ 処理部
１１３０ 第１算出部 １１３１ 第２算出部
１１３２ 配信先決定部 １１４ 第１データ格納部
１１５ 第２データ格納部 １１６ 配信計画データ格納部
１１７ 第３データ格納部 ３ インターネット
５ａ，５ｂ，５ｃ 顧客端末

Claims (8)

1. コンピュータに、
   特定の情報処理装置の負荷の情報を取得し、
   取得した前記特定の情報処理装置の負荷の情報に基づく前記特定の情報処理装置の負荷の予測値の変動に応じて、前記特定の情報処理装置をアクセス先とするアクセス先情報を含むメッセージの単位時間あたりの配信先の数を決定する、
   処理を実行させる配信制御プログラム。
2. 前記コンピュータに、
   データ格納部に配信先毎に格納されている、配信の優先度に相当する情報に基づき、配信の優先度がより高い配信先に対してより早い時間に配信を行うように、決定された前記数の配信先を各単位時間について決定する、
   処理をさらに実行させる請求項１記載の配信制御プログラム。
3. 前記データ格納部は、前記特定の情報処理装置へのアクセスの頻度を配信先毎にさらに格納し、
   前記コンピュータに、
   前記データ格納部に格納されているアクセスの頻度に対して所定の値を乗じることで、第１の値を配信先毎に算出する、
   処理をさらに実行させ、
   決定された前記数の配信先を各単位時間について決定する処理において、
   各単位時間において前記第１の値の合計が配信先の数以下であるという条件が満たされるように、且つ、配信の優先度がより高い配信先に対してより早い時間に配信を行うように、決定された前記数の配信先を各単位時間について決定する、
   請求項２記載の配信制御プログラム。
4. 前記コンピュータに、
   前記メッセージのテンプレートが前記アクセス先情報を含むか判定する、
   処理をさらに実行させ、
   前記メッセージのテンプレートが前記アクセス先情報を含むと判定された場合、前記単位時間あたりの配信先の数を決定する処理において、取得した前記特定の情報処理装置の負荷の情報に基づき、前記単位時間あたりの配信先の数を決定する
   請求項１乃至３のいずれか１つ記載の配信制御プログラム。
5. 前記単位時間あたりの配信先の数を決定する処理において、
   前記特定の情報処理装置の負荷が高い単位時間ほど配信先の数が少なくなるように、前記単位時間あたりの配信先の数を決定する、
   請求項１乃至４のいずれか１つ記載の配信制御プログラム。
6. 前記特定の情報処理装置の負荷の情報は、前日又は同じ曜日の前記特定の情報処理装置の負荷の情報である、
   請求項１乃至５のいずれか１つ記載の配信制御プログラム。
7. コンピュータが、
   特定の情報処理装置の負荷の情報を取得し、
   取得した前記特定の情報処理装置の負荷の情報に基づく前記特定の情報処理装置の負荷の予測値の変動に応じて、前記特定の情報処理装置をアクセス先とするアクセス先情報を含むメッセージの単位時間あたりの配信先の数を決定する、
   処理を実行する配信制御方法。
8. 特定の情報処理装置の負荷の情報を取得する取得部と、
   取得した前記特定の情報処理装置の負荷の情報に基づく前記特定の情報処理装置の負荷の予測値の変動に応じて、前記特定の情報処理装置をアクセス先とするアクセス先情報を含むメッセージの単位時間あたりの配信先の数を決定する決定部と、
   処理を実行する情報処理装置。

Images