JPWO2018037893A1

JPWO2018037893A1 - ポータルサーバを管理する方法、装置およびシステム

Info

Publication number: JPWO2018037893A1
Application number: JP2018535580A
Authority: JP
Inventors: 鈴木　健弘; 健弘鈴木
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2016-08-23
Filing date: 2017-08-07
Publication date: 2019-06-20
Also published as: US20190191415A1; WO2018037893A1

Abstract

ネットワークの運用面での柔軟性を維持しつつ、加入者に負荷をかけることなくポータルサーバの複数化を可能にする、ポータルサーバの管理方法、装置およびシステムを提供する。ポータルサーバを管理する装置（１１）は、加入者端末（Ｔ１）から受信したアクセス要求から当該加入者端末の加入者識別情報を検出する検出部（１０４）と、加入者識別情報に基づいて、アクセス要求の収容先を複数のポータルサーバ（２０、２０ａ、２０ｂ）の一つに振り分ける制御部（１０５，１０７）と、を有する。

Description

本発明は加入者端末からのアクセスを受けるポータルサーバの管理技術に関する。

現在のインターネット環境において、ポータルサイトはＷｅｂ利用の入口であり、ユーザが容易にサービス提供サーバへアクセスできるようにＷｅｂ上の種々のサービスや情報を集約してＷｅｂ画面上に提示する。通常、加入者は、通信事業者から事前に配布されたアクセス先のＵＲＬ(Uniform Resource Locator)、加入者識別番号等の設定情報を用いてポータルサーバへアクセスする。したがって、加入者は通信事業者が指定したポータルサーバに固定されていると云える。これまで提案されてきたサービス提供システムやポータルサーバは、このアーキテクチャに基づいた種々の応答例である。たとえば、特許文献１には、ポータルサーバでユーザ認証を行い、所望のソフトウエア提供サーバへリダイレクトさせることにより、パッケージソフトの取得を容易にするシステムが提案されている。

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

しかしながら、加入者数が増大してポータルサーバの最大収容数を超える可能性が出てくると、通信事業者はポータルサーバを増設して加入者増に対応しなければならない。この場合、複数のポータルサーバは各々異なるＵＲＬを持つために、通信事業者は、ポータルサーバが増設される毎あるいは別のポータルサーバへ変更する毎に、加入者に対してアクセス先の変更を通知する必要がある。加入者側は、その通知に従って、アクセス先を自らが属するポータルサーバに変更しなければならない。このようなシステム側の事情によって発生する設定変更は、加入者にとって大きな負担である。

また、複数のポータルサーバが存在するシステムで通信事業者が各加入者向けの保守作業を行う場合には、加入者識別番号をキーとして全ポータルサーバに対して検索を実行する必要がある。このために、ポータルサーバ数が増えるにつれて検索負荷が増大し、加入者毎の保守作業の迅速化が困難になると云う新たな課題が発生する。

さらに、キャリアネットワークでは、近年、ＢＲＡＳ(Broadband Remote Access Server)、ルータ、ファイヤウォール等のネットワーク機能を汎用サーバ上で実現するネットワーク機能の仮想化(Network Function Virtualization)が大きな流れとなっている。ネットワーク機能の仮想化は、ネットワーク機能の増設および処理能力のアップグレード等が容易になり、加入者数の増大に容易に対応できるという点でも大いに期待されている。

ところが、上述したように、加入者とポータルサーバとが固定的な関係にあると、複数のポータルサーバ間で負荷分散を行ったり、加入者を他のポータルサーバへ移動させたり、という仮想化のメリットが大きく損なわれる。このような運用面での柔軟性の低減も解決すべき大きな課題である。

そこで、本発明の目的は、ネットワークの運用面での柔軟性を維持しつつ、加入者に負荷をかけることなくポータルサーバの複数化を可能にする、ポータルサーバの管理方法、装置およびシステムを提供することにある。

本発明の一態様にかかるポータルサーバを管理する装置は、加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出する検出手段と、前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける制御手段と、を有する。

本発明によるポータルサーバを管理する方法は、検出手段が加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出し、制御手段が、前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける。

本発明の一態様にかかるポータルサーバを管理するシステムは、加入者識別情報と複数のポータルサーバとの対応情報を格納する第一サーバと、加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出し、前記加入者識別情報と前記第一サーバの前記対応情報とに基づいて、当該アクセス要求の収容先を前記複数のポータルサーバの一つに振り分ける第二サーバと、を有する。

本発明の一態様にかかるポータルサーバを管理する装置としてコンピュータを機能させるプログラムを記録するプログラム記録媒体は、加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出する機能と、前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける機能と、を前記コンピュータに実現するプログラムを記録する。

本発明によれば、ネットワークの運用面での柔軟性を維持しつつ、加入者に負荷をかけることなくポータルサーバの複数化を可能にする。

図１は本発明の一実施形態による管理システムを含むネットワークの機能構成の一例を示すネットワーク図である。図２は本発明の第一具体例による管理システムにおける集中管理サーバの構成例を示すブロック図である。図３は第一具体例における加入者情報管理サーバの構成例を示すブロック図である。図４は第一具体例におけるＷｅｂポータルサーバの構成例を示すブロック図である。図５は第一具体例による管理方法の第一例を示すシーケンス図である。図６は第一具体例による管理方法の第二例を示すシーケンス図である。図７は本発明の第二具体例による管理システムにおけるＩＰＦＥの構成例を示すブロック図である。図８は第二具体例による管理方法の第一例を示すシーケンス図である。図９は第二具体例による管理方法の第二例を示すシーケンス図である。図１０は本発明の第三具体例による管理システムにおける集中管理サーバの構成例を示すブロック図である。図１１は本発明の第四具体例による管理装置の構成例を示すブロック図である。図１２は各実施形態または具体例によるサーバを実現するコンピュータ装置のハードウェア構成の一例を示す図である。

＜実施形態の概要＞
本発明の一実施形態によれば、ポータルサーバへのアクセス要求を集約する管理装置を設け、管理装置が当該アクセス要求を複数のポータルサーバのうちの適切なものへ誘導するようにアクセス要求を制御する。この管理装置により、複数のポータルサーバ間の負荷分散が可能となり、仮想化システムの運用面での柔軟性を維持することができる。また加入者数の増加に対応するためのシステム変更、たとえばポータルサーバの増設あるいは変更があっても、そのシステム変更を加入者および保守作業者に対して隠蔽することが可能となる。すなわち、加入者および保守作業者にとっては、単一のポータルサーバの場合と同様に操作が可能となる。このように、加入者側に対する設定変更の負担がなくなり、また加入者ごとに保守作業を行う際の検索も高速化できる。

以下、固定系アクセスネットワークで用いられるＢＲＡＳ(Broadband Remote Access Server)を仮想化した機能を含む仮想ＢＲＡＳシステムを一例として取りあげる。ネットワーク機能の仮想化は、通信事業者にとって、設備投資（ＣＡＰＥＸ）および運用コスト（ＯＰＥＸ）の縮小、設備の設置スペースや消費電力の抑制、新サービスへの対応の容易さといったメリットがある。また、加入者にとっては、加入者の宅内のブロードバンドルータが具備するＤＨＣＰ(Dynamic Host Configuration Protocol)機能、ＮＡＴ(Network Address Translation)機能、各機能の設定処理や状態表示に用いられるＷｅｂポータル（Portal）機能が、宅内の機器から通信事業者のネットワーク内のサーバ上に集約されるために、宅内機器ＣＰＥ（Customer Premises Equipment）が簡略化され、アップグレードなどのサポートが容易になる等のメリットがある。したがって、本実施形態を仮想ＢＲＡＳシステムに適用することで、仮想化ネットワークのメリットを維持しつつ、複数のポータルサーバに対するアクセス要求の振り分けが可能となる。以下、図１を参照しながら、本実施形態について説明する。

図１に示すように、本実施形態による仮想ＢＲＡＳシステム１０は、複数のポータルサーバ２０、２０ａ・・・からなるＷｅｂポータルサーバ群と各加入者端末との間に配置される。仮想ＢＲＡＳシステム１０は、端末からのアクセス要求を集約し適切なポータルサーバへ振り分ける機能を含む集中管理サーバ１１と、接続認証および加入者情報の管理を行う加入者情報管理サーバ１２と、複数のＣＰＥを収容して仮想ＢＲＡＳシステム１０の入口となる複数のＩＰＦＥ(Internet Protocol Front End)１３と、加入者端末からインターネット２４への通信時のアドレス変換を行う複数のＮＡＴ１４を有する。

保守用端末２２は集中管理サーバ１１に接続され、各加入者からの調査依頼に応じてポータルサーバにアクセス要求を行う。各ＣＰＥ２３は、複数の加入者宅内端末を収容し、仮想ＢＲＡＳシステム１０のＩＰＦＥ１３へ接続される。また、集中管理サーバ１１はインターネット２４に接続し、インターネット経由のアクセス要求を集約して適切なポータルサーバへ振り分けることもできる。

加入者情報管理サーバ１２には、加入者情報に対応した収容先ポータルサーバを特定する情報が格納されている。したがって、端末からのアクセス要求を適切なポータルサーバへ振り分ける機能は、加入者情報管理サーバ１２を参照することで、各加入者からのアクセス要求をそれぞれの収容先ポータルサーバへ誘導することができる。このようなアクセス要求の誘導は、たとえば端末に対してリダイレクト先を通知することにより行うことができる。

端末からのアクセス要求を適切なポータルサーバへ振り分ける機能は、ポータルサーバ群の手前に位置するネットワークエンティティに設けることができ、たとえば仮想ＢＲＡＳシステム１０における集中管理サーバ１１およびＩＰＦＥ１３の少なくとも一つに設けることができる。

後述するように、本発明の第一具体例によれば、集中管理サーバ１１だけに振り分け機能が装備される。したがって、集中管理サーバ１１は、固定系アクセスネットワークを通した加入者宅内端末からのアクセス要求、保守用端末２２からのアクセス要求およびインターネット２４を通した加入者端末からのアクセス要求を適切なポータルサーバへ振り分けることができる。

また、本発明の第二具体例によれば、ＩＰＦＥ１３にも振り分け機能が設けられ、ＩＰＦＥ１３が加入者宅内端末からのアクセス要求を振り分け、集中管理サーバ１１が、保守用端末２２からのアクセス要求およびインターネット２４を通した加入者端末からのアクセス要求を適切なポータルサーバへ振り分けることができる。

上述したように、本実施形態によれば、収容する加入者数が増加し、複数のポータルサーバが必要となった場合においても、加入者及び通信事業者の保守者が仮想ＢＲＡＳシステムの変更を意識せずに複数のポータルサーバを運用することが可能となる。また、アクセス要求が振り分けられることで、複数のポータルサーバ間の負荷分散が可能となり、仮想化システムの運用面での柔軟性を維持することができる。以下、本発明の第一及び第二具体例について図面を参照しながら詳細に説明する。

１．第一具体例
本発明の第一具体例によれば、図１に示すシステムにおける集中管理サーバ１１に、加入者宅内端末からのアクセス要求、保守用端末２２からのアクセス要求およびインターネット２４を通した加入者端末からのアクセス要求を適切なポータルサーバへ振り分ける機能が設けられる。以下、集中管理サーバ１１、加入者情報管理サーバ１２およびポータルサーバ２０の構成及び機能について図２〜図４を参照しながら説明する。

１．１）集中管理サーバ
図２に例示するように、集中管理サーバ１１は、３つの異なるネットワークインターフェースとしてＨＴＴＰ送受信部１０１〜１０３と加入者識別番号検出部１０４とを有する。ＨＴＴＰ送受信部１０１は、加入者が宅内から仮想ＢＲＡＳシステム１０を通じてアクセスする際の通信（Ｉｎｔｅｒｎａｌ）に使用される。ＨＴＴＰ送受信部１０２は、加入者がインターネット２４を通してアクセスする際の通信（Ｉｎｔｅｒｎｅｔ）に使用される。ＨＴＴＰ送受信部１０３は、通信事業者が加入者の保守操作の為にアクセスする際の通信（保守）に使用される。加入者識別番号検出部１０４は、各ＨＴＴＰ送受信部で受信されたアクセス要求から加入者識別番号を検知する。

加入者識別番号検出部１０４は、ＨＴＴＰ送受信部を通してアクセス要求を受信すると、当該アクセス要求の発信元端末の加入者識別番号を検出し、収容先確認部１０５へ出力する。収容先確認部１０５は、加入者情報管理サーバ１２に対して、加入者識別番号に対応する収容先ポータルサーバのＵＲＬを問い合わせ、その応答として収容先ＵＲＬを取得し、当該収容先ＵＲＬをＨＴＴＰリダイレクト先通知部１０６へ出力する。

加入者情報管理サーバ１２から収容先ＵＲＬを取得できなかった場合、収容先確認部１０５は収容先決定部１０７へ当該加入者識別番号に対応する収容先を決定するように指示する。収容先決定部１０７は、所定の選択基準に従って、配下のポータルサーバ２０、２０ａおよび２０ｂから一つを選択し、そのＵＲＬを収容先ＵＲＬとして収容先確認部１０５およびＨＴＴＰリダイレクト先通知部１０６へそれぞれ出力する。収容先ＵＲＬを受け取った収容先確認部１０５は、収容先ＵＲＬと対応する加入者識別番号とを加入者情報管理サーバ１２に登録する。なお、収容先決定部１０７による収容先のポータルサーバの選択基準は、たとえば負荷分散の観点から設定すればよい。

ＨＴＴＰリダイレクト先通知部１０６は、収容先確認部１０５あるいは収容先決定部１０７から受け取った収容先ＵＲＬを用いてＨＴＴＰリダイレクト先通知を生成しアクセス要求を行った加入者端末へ送信する。当該アクセス要求をした加入者端末は、ＨＴＴＰリダイレクト先通知を受信すると、その収容先ＵＲＬを用いてポータルサーバへアクセスする。なお、加入者情報管理サーバ１２の機能は、集中管理サーバ１１内に設けられてもよい。

なお、図２に示すブロック構成は集中管理サーバ１１の機能構成を図示したものであり、各機能はハードウエアあるいはソフトウエアにより実現されうる。たとえば、集中管理サーバ１１のＣＰＵ(Central Processing Unit)上で、図示しないメモリに格納されたプログラムを実行することにより同等の機能構成を実現することができる。あるいは、汎用サーバで動作する仮想マシン上に、仮想ネットワーク機能として集中管理サーバ１１を実現することもできる。

１．２）加入者情報管理サーバ
図３に例示するように、加入者情報管理サーバ１２は、加入者情報を格納するデータベース１１０と認証部１１１とを有し、制御部１１２の制御のもとで、通信部１１３を通して集中管理サーバ１１あるいはＩＰＥＦ１３と通信を行う。データベース１１０には、加入者識別番号と当該加入者端末が収容されるポータルサーバのＵＲＬとが対応付けて格納されている。制御部１１２は、集中管理サーバ１１から収容先取得要求があれば、その加入者識別番号をキーとしてデータベース１１０を検索し、対応する収容先ＵＲＬを読み出して集中管理サーバ１１へ返す。

また、集中管理サーバ１１から新たなエントリ（加入者識別番号と決定された収容先ＵＲＬとの組）の登録要求があれば、制御部１１２はデータベース１１０に当該新たなエントリを追加する。

たとえば、ポータルサーバ群に新たなポータルサーバ２０ｂが増設され、他のポータルサーバに収容されていた加入者を新たなポータルサーバ２０ｂへ移動させる場合を考える。この場合、他のポータルサーバに収容されていた加入者のエントリを削除し、新たな収容先ＵＲＬと対応付けたエントリをデータベース１１０に登録すればよい。このように、データベース１１０に対してエントリの更新、登録あるいは削除を行うという簡単な制御だけで、ポータルサーバ群の変更、ポータルサーバの増設あるいは消去等のシステム変更を加入者側および保守作業者側が意識することなく実行することができる。

１．３）Ｗｅｂポータルサーバ
図４に例示するように、Ｗｅｂポータルサーバ（２０／２０ａ／２０ｂ）は、ＨＴＴＰパケットの受け口となる負荷分散サーバ２０１と、複数対のサーバ（フロントエンドサーバ２０２およびビジネスロジックサーバ２０３）と、データベースサーバ２０４と、を有する。フロントエンドサーバ２０２は、受信したＨＴＴＰパケットをビジネスロジックサーバ２０３へ転送し、画面生成や画面遷移を制御する。ビジネスロジックサーバ２０３は、フロントエンドサーバ２０２から受け取った種々の要求を実行する。データベースサーバ２０４は、ビジネスロジックサーバ２０３により実行され、あるいは更新された情報を保存する。

Ｗｅｂポータルサーバ内で最も処理負荷が大きいのはビジネスロジックサーバ２０３である。フロントエンドサーバ２０２は、対になるビジネスロジックサーバ２０３と負荷分散サーバ２０１との間のパケット転送処理および処理結果の画面生成に限られる為、処理負担はより低い。

加入者数が増大してビジネスロジックサーバ２０３の負荷が大きくなると、図４に示すように、フロントエンドサーバ２０２およびビジネスロジックサーバ２０３の新たな対を増設することで対応する。このような一対のサーバの増設が上限に達すると、さらなる加入者の収容にはＷｅｂポータルサーバ自体の増設が必要となる。既に述べたように、複数のＷｅｂポータルサーバが設置された構成では、負荷分散のために既存の加入者を他のポータルサーバへ移動させたり、新たな加入者を増設したポータルサーバへ収容したりするが、本具体例によるアクセス管理により、このようなシステム側の変更が加入者／保守者側からは見えないようになる。以下、複数ポータルサーバ構成での本具体例によるアクセス管理について詳細に説明する。

１．４）動作
＜Ｉｎｔｅｒｎａｌアクセス＞
図５を参照しながら、複数のポータルサーバが設定されているシステムにおいて、端末Ｔ１が仮想ＢＲＡＳシステム１０を通してＷｅｂポータルサーバへアクセス要求を行う場合（Ｉｎｔｅｒｎａｌアクセス）のアクセス管理について説明する。

図５において、加入者が端末Ｔ１のＷｅｂブラウザ上で、集中管理サーバ１１に紐づくＵＲＬ（たとえばポータルサーバ２０）を指定してＨＴＴＰリクエストによりアクセス要求を行う（動作Ｓ３０１）。集中管理サーバ１１は、当該ＨＴＴＰリクエストを受信すると、その送信元ＩＰアドレスを基にＮＡＴ１４から加入者識別番号を取得する（動作Ｓ３０２）。

続いて、集中管理サーバ１１は、加入者情報管理サーバ１２に対して、取得した加入者識別番号に対応する収容先ＵＲＬの取得要求を行い、加入者情報管理サーバ１２から当該加入者の収容先ポータルサーバのＵＲＬを取得する（動作Ｓ３０３）。図３に示すように、加入者情報管理サーバ１２の制御部１１２は、加入者識別番号を含む収容先ＵＲＬの取得要求を受信すると、当該加入者識別番号をキーとしてデータベース１１０を検索する。対応する収容先ＵＲＬが見つかれば、制御部１１２は通信部１１３を通して収容先ＵＲＬを要求した集中管理サーバ１１へ返し、対応する収容先ＵＲＬが未登録であれば、未登録であることを示す応答を返す。

対応する収容先ＵＲＬが未登録である場合とは、加入者が初めてポータルサーバに接続要求を行う場合である。集中管理サーバ１１は、対応する収容先ＵＲＬが取得できなかった場合、既に述べたように、配下のポータルサーバ（この例では、３つのポータルサーバ２０、２０ａ、２０ｂ）から収容先ポータルサーバを決定する処理を行い（動作Ｓ３０３ａ）、決定された収容先ＵＲＬを加入者情報管理サーバ１２へ通知する（動作Ｓ３０３ｂ）。加入者情報管理サーバ１２は、決定された収容先ＵＲＬを当該加入者識別番号に対応付けてデータベース１１０に登録する（動作Ｓ３０３ｃ）。

こうして収容先ＵＲＬが取得されると、集中管理サーバ１１は、ＨＴＴＰリダイレクトにより、端末Ｔ１に対して収容先のポータルサーバ（たとえばポータルサーバ２０ａ）へ接続するように通知する（動作Ｓ３０４）。こうして、ＨＴＴＰリダイレクトを受信した端末Ｔ１は、当初の紐付けられたポータルサーバ２０ではなく、リダイレクトされたポータルサーバ２０ａへのアクセスを実行する（動作Ｓ３０５）。

＜Ｉｎｔｅｒｎｅｔ／保守アクセス＞
図６を参照しながら、インターネット経由でのアクセス（Ｉｎｔｅｒｎｅｔアクセス）あるいは通信事業者が加入者からの依頼を受けて実施する保守操作の為のアクセス（保守アクセス）について説明する。なお、Ｉｎｔｅｒｎｅｔアクセスおよび保守アクセスは、アクセス元の端末の所属するネットワークが異なるだけで、シーケンスとしては同様である。したがって、Ｉｎｔｅｒｎｅｔアクセスの場合を一例として説明する。

図６において、加入者端末はインターネット２４を介して集中管理サーバ１１に紐づくＵＲＬにアクセス要求を行う（動作Ｓ４０１）。集中管理サーバ１１は、ＨＴＴＰ送受信部１０２で受信処理を行い、加入者端末に対して加入者識別番号を要求する（動作Ｓ４０２）。これに応じて、加入者端末は集中管理サーバ１１へ加入者識別番号を通知する（動作Ｓ４０３）。

集中管理サーバ１１は、加入者情報管理サーバ１２に対して、取得した加入者識別番号に対応する収容先ＵＲＬの取得要求を行い、加入者情報管理サーバ１２から当該加入者の収容先ポータルサーバのＵＲＬを取得する（動作Ｓ３０３）。以下、図５で説明したように、収容先ＵＲＬが取得できなかった場合の処理（動作Ｓ３０３ａ〜Ｓ３０３ｃ）、ＨＴＴＰリダイレクト先の通知（動作Ｓ３０４）および加入者端末からのアクセス（動作Ｓ３０５）が順次実行される。

１．５）効果
上述したように、本具体例によれば、Ｗｅｂポータルサーバが複数台設置された環境においても、アクセス元の端末の加入者は、仮想ＢＲＡＳシステム１０により、収容される複数のポータルサーバを意識することなく、アクセスすることが可能となり、加入者あるいは保守作業者にとって利便性向上につながる。また、通信事業者側にとっては、加入者契約時に提示するアクセス先が全ユーザで共通であるにもかかわらず、収容先ポータルサーバを固定とすることなく柔軟に運用可能となるために、運用管理面での融通性が向上し、コスト削減につながるメリットがある。

２．第二具体例
上述した第一具体例では集中管理サーバ１１がアクセス要求の振り分け管理を実行するが、これに限定されるものではなく、集中管理サーバ１１の処理負荷を仮想ＢＲＡＳシステム１０内の他のエンティティとの間で分担することもできる。

上述したポータルサーバへのアクセスとしては、加入者宅内からのアクセス（Ｉｎｔｅｒｎａｌアクセス）が大半を占め、Ｉｎｔｅｒｎｅｔアクセスや保守アクセスは緊急時等に限定される。したがって、仮想ＢＲＡＳシステム１０の収容加入者が増大すれば、主としてＩｎｔｅｒｎａｌアクセス数が増大し、集中管理サーバ１１の処理負荷の急増が考えられる。

そこで、本発明の第二具体例では、仮想ＢＲＡＳシステム１０の入口で加入者情報管理サーバ１２と連携しているＩＰＦＥ１３にＨＴＴＰリダイレクト機能を設けて負荷分散を図る。すなわち、ＩＰＦＥ１３がアクセス管理の一部を分担することで集中管理サーバ１１への投資を軽減しＣＡＰＥＸ改善につなげる。以下、本具体例について図７〜図９を参照しながら詳細に説明する。

図７に例示するように、本具体例によるＩＰＦＥ１３は、加入者情報管理サーバ１２と通信を行う加入者情報管理サーバ通信部１２０を有し、加入者情報管理サーバ通信部１２０を通して加入者情報管理サーバ１２から取得した加入者情報を加入者情報蓄積部１２１に蓄積する。この加入者情報には、図３に例示した加入者識別番号とその収容先ＵＲＬからなるエントリが少なくとも含まれる。

さらに、ＩＰＦＥ１３は、加入者宅内端末および集中管理サーバ１１と通信を行うインターフェースである通信部１２２およびＨＴＴＰリダイレクション部１２３を有する。ＨＴＴＰリダイレクション部１２３は、加入者端末から受信したＨＴＴＰパケットにおいて集中管理サーバ１１向けのＵＲＬが指定されているか否かを判定し、指定されていれば、加入者情報蓄積部１２１から対応する収容先ＵＲＬを取得し、ＨＴＴＰリダイレクト先である収容先ＵＲＬを加入者端末へ通知する。

以下、図８を参照しながら、ＩＰＦＥ１３に収容先ＵＲＬが蓄積されていなかった場合のＩｎｔｅｒｎａｌアクセス（たとえば加入者宅内端末から初めてポータルサーバへアクセスする場合）について説明し、図９を参照しながら２回目以降のＩｎｔｅｒｎａｌアクセスについて説明する。

図８において、加入者が端末Ｔ１のＷｅｂブラウザ上で、集中管理サーバ１１に紐づくＵＲＬ（たとえばポータルサーバ２０）を指定してＨＴＴＰリクエストによりアクセス要求を行う（動作Ｓ５０１）。端末Ｔ１からＨＴＴＰリクエストを受信すると、ＩＰＦＥ１３のＨＴＴＰリダイレクション部１２３は、当該受信パケットが集中管理サーバ１１向けであり、かつ自局でリダイレクト処理可能か否かを判断する（動作Ｓ５０２）。より詳しくは、集中管理サーバ１１向けであれば、ＨＴＴＰリダイレクション部１２３は、ＨＴＴＰリクエストの送信元である端末Ｔ１の加入者識別番号をキーとして加入者情報蓄積部１２１を検索し、対応する収容先ＵＲＬの有無を判定する。ここでは初回のアクセスであるから、加入者情報蓄積部１２１には収容先ＵＲＬは登録されていない。したがって、ＨＴＴＰリダイレクション部１２３は、ＨＴＴＰリクエストを集中管理サーバ１１へ転送する（動作Ｓ５０３）。

集中管理サーバ１１は、当該ＨＴＴＰリクエストを受信すると、その送信元ＩＰアドレスを基にＮＡＴ１４から加入者識別番号を取得する（動作Ｓ３０２）。続いて、集中管理サーバ１１は、既に述べたように、加入者情報管理サーバ１２に対して、取得した加入者識別番号に対応する収容先ＵＲＬの取得要求を行い、加入者情報管理サーバ１２から当該加入者の収容先ポータルサーバのＵＲＬを取得する（動作Ｓ３０３）。加入者情報管理サーバ１２では、加入者識別番号を含む収容先ＵＲＬが登録済みであれば、当該収容先ＵＲＬを要求した集中管理サーバ１１へ返す。対応する収容先ＵＲＬが未登録である場合、集中管理サーバ１１は、既に述べたように、配下のポータルサーバから収容先ポータルサーバを決定し（動作Ｓ３０３ａ）、決定された収容先ＵＲＬを加入者情報管理サーバ１２へ通知する（動作Ｓ３０３ｂ）。加入者情報管理サーバ１２は、決定された収容先ＵＲＬを当該加入者識別番号に対応付けて登録する（動作Ｓ３０３ｃ）。

加入者情報管理サーバ１２に登録されていた、あるいは新たに登録された収容先ＵＲＬは、ＩＰＦＥ１３へ通知され（動作Ｓ５０４）、ＩＰＦＥ１３の加入者情報蓄積部１２１に当該加入者識別番号に対応付けて登録される（動作Ｓ５０５）。

こうして収容先ＵＲＬが取得されると、集中管理サーバ１１は、ＨＴＴＰリダイレクトにより、端末Ｔ１に対して収容先のポータルサーバへ接続するように通知し（動作Ｓ３０４）、ＨＴＴＰリダイレクトを受信した端末Ｔ１はリダイレクトされたポータルサーバへのアクセスを実行する（動作Ｓ３０５）。

図９において、ＩＰＦＥ１３の加入者情報蓄積部１２１には加入者識別番号に対応付けた収容先ＵＲＬが既に登録されているものとする。加入者が端末Ｔ１のＷｅｂブラウザ上で、集中管理サーバ１１に紐づくＵＲＬを指定しアクセス要求を行うと（動作Ｓ６０１）、ＩＰＦＥ１３は当該受信パケットが集中管理サーバ１１向けであり、かつ自局でリダイレクト処理可能か否かを判断する（動作Ｓ６０２）。集中管理サーバ１１向けであれば、ＩＰＦＥ１３は受信パケットの加入者識別番号から収容先ＵＲＬを検索する。ここでは収容先ＵＲＬが既に登録されているので、ＨＴＴＰリダイレクション部１２３は、ＨＴＴＰリダイレクト先として収容先ＵＲＬを含む通知を要求した端末Ｔ１へ通知する（動作Ｓ６０３）。ＨＴＴＰリダイレクトを受信した端末Ｔ１はリダイレクトされたポータルサーバへのアクセスを実行する（動作Ｓ６０４）。

上述したように、本発明の第二具体例によれば、第一具体例と同様の効果を得ることができる上に、Ｉｎｔｅｒｎａｌアクセスが実行された加入者宅内端末に対して、２回目以降は集中管理サーバ１１の手前のＩＰＦＥ１３においてリダイレクト処理が実行され、ＨＴＴＰリクエストが端末側へ折り返される。したがって、集中管理サーバ１１の処理負担を大幅に建言することができる。

３．第三具体例
本発明の第三具体例によれば、ポータルサーバ群に予備サーバを用意しておき、集中管理サーバが、ポータルサーバ群の負荷状況等に応じて、予備サーバを増設ポータルサーバとして機能させることができる。これにより、ポータルサーバの増設を人手を介さずに自動的に行うことが可能となる。

図１０に例示するように、第三具体例による集中管理サーバ１１ａが図２に示す集中管理サーバ１１と異なる点は、ポータルサーバ群の負荷状況、リソース利用状況を監視し、予備サーバの自動増設を実行するポータルサーバ管理部１０８を設けたことである。その他は図２と同様の構成および機能であるから、同じブロックに同一参照番号を付して説明は省略する。

たとえば、図１におけるポータルサーバ２０および２０ａが現用のポータルサーバとして動作し、ポータルサーバ２０ｂが予備サーバとして待機しているものとする。ポータルサーバ管理部１０８は、現用のポータルサーバ群の負荷状況やリソース利用状況を監視しており、加入者数の増加等に起因して負荷が増大し新たなポータルサーバが必要であると判断すれば、ポータルサーバ（予備サーバ）２０ｂを増設ポータルサーバとして起動する。このように増設されたポータルサーバ群を用いたアクセス管理も上記第一および第二具体例で述べたように実行することができる。

４．第四具体例
図１１は本発明の第四具体例による管理装置３０の構成例を示すブロック図である。図１１に示すように、管理装置３０は、検出部３０１および制御部３０２を備える。管理装置３０は、ポータルサーバを管理する装置である。

検出部３０１は、加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出する。制御部３０２は、加入者識別情報に基づいて、アクセス要求の収容先を複数のポータルサーバの一つに振り分ける。

なお、検出部３０１、および制御部３０２は、それぞれ一例として、上記実施形態において説明する加入者識別番号検出部１０４、および収容先確認部１０５と収容先決定部１０７により実現される。

上記構成を採用することにより、本第四具体例によれば、ネットワークの運用面での柔軟性を維持しつつ、加入者に負荷をかけることなくポータルサーバの複数化を可能にすることができる。

なお、上述したサーバの各部は、図１２に例示するハードウエア資源において実現される。すなわち、図１２に示す構成は、プロセッサ４０１、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）４０２、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）４０３、外部接続インタフェース４０４、記録装置４０５および各構成要素を接続するバス４０６を備える。

上述した各実施形態では、図１２に示すプロセッサ４０１が実行する一例として、サーバに対して、上述した機能を実現可能なコンピュータ・プログラムを供給した後、そのコンピュータ・プログラムを、プロセッサ４０１がＲＡＭ４０２に読み出して実行することによって実現する場合について説明した。しかしながら、サーバの各ブロックに示す機能は、一部または全部を、ハードウエアとして実現してもよい。

かかる供給されたコンピュータ・プログラムは、読み書き可能なメモリ（一時記憶媒体）またはハードディスク装置等のコンピュータ読み取り可能な記憶デバイスに格納すればよい。そして、このような場合において、本発明は、かかるコンピュータ・プログラムを表すコード或いは係るコンピュータ・プログラムを格納した記憶媒体によって構成されると捉えることができる。

５．付記
上述した実施形態の一部あるいは全部は、以下の付記のようにも記載されうるが、これらに限定されるものではない。

（付記１）
ポータルサーバを管理する装置であって、
加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出する検出手段と、
前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける制御手段と、
を有する管理装置。
（付記２）
前記制御手段が、加入者識別情報と収容先ポータルサーバとの対応情報を参照することで前記アクセス要求の収容先を前記複数のポータルサーバの一つに決定する、付記１に記載の管理装置。
（付記３）
通信可能なサーバに前記対応情報が格納され、前記サーバから前記対応情報を取得する、付記２に記載の管理装置。
（付記４）
前記制御手段が、前記加入者識別情報に対応するポータルサーバの位置情報をリダイレクト先として前記加入者端末へ通知する、付記１−３のいずれか１項に記載の管理装置。
（付記５）
前記制御手段が、前記複数のポータルサーバの負荷状況を監視し、前記負荷状況に基づいて前記アクセス要求の収容先を前記複数のポータルサーバの一つに振り分ける、付記１−４のいずれか１項に記載の管理装置。
（付記６）
付記１−５のいずれか１項に記載の管理装置を含む仮想ＢＲＡＳ(Broadband Remote Access Server)システム。
（付記７）
付記１−５のいずれか１項に記載の管理装置を含むサーバ。
（付記８）
付記１−５のいずれか１項に記載の管理装置を含むＩＰＦＥ(Internet Protocol Front End)。
（付記９）
ポータルサーバを管理する方法であって、
検出手段が加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出し、
制御手段が、前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける、
管理方法。
（付記１０）
前記制御手段が、加入者識別情報と収容先ポータルサーバとの対応情報を参照することで前記アクセス要求の収容先を前記複数のポータルサーバの一つに決定する、付記９に記載の管理方法。
（付記１１）
通信可能なサーバに前記対応情報が格納され、前記サーバから前記対応情報を取得する、付記１０に記載の管理方法。
（付記１２）
前記制御手段が、前記複数のポータルサーバの負荷状況を監視し、前記負荷状況に基づいて前記アクセス要求の収容先を前記複数のポータルサーバの一つに振り分ける、付記９−１１のいずれか１項に記載の管理方法。
（付記１３）
前記制御手段が、前記加入者識別情報に対応するポータルサーバの位置情報をリダイレクト先として前記加入者端末へ通知する、付記９−１２のいずれか１項に記載の管理方法。
（付記１４）
ポータルサーバを管理するシステムであって、
加入者識別情報と複数のポータルサーバとの対応情報を格納する第一サーバと、
加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出し、前記加入者識別情報と前記第一サーバの前記対応情報とに基づいて、当該アクセス要求の収容先を前記複数のポータルサーバの一つに振り分ける第二サーバと、
を有する管理システム。
（付記１５）
前記第二サーバが、前記第一サーバの前記対応情報を参照することで前記アクセス要求の収容先を前記複数のポータルサーバの一つに決定する、付記１４に記載の管理システム。
（付記１６）
前記第二サーバが、前記複数のポータルサーバの負荷状況を監視し、前記負荷状況に基づいて前記アクセス要求の収容先を前記複数のポータルサーバの一つに振り分ける、付記１４または１５に記載の管理システム。
（付記１７）
前記第二サーバが、前記加入者識別情報に対応するポータルサーバの位置情報をリダイレクト先として前記加入者端末へ通知する、付記１４−１６のいずれか１項に記載の管理システム。
（付記１８）
付記１４−１７のいずれか１項に記載の管理システムを仮想化されたネットワーク機能として含む仮想ＢＲＡＳ(Broadband Remote Access Server)システム。
（付記１９）
ポータルサーバを管理する装置としてコンピュータを機能させるプログラムを記録するプログラム記録媒体であって、加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出する機能と、
前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける機能と、
を前記コンピュータに実現するプログラムを記録するプログラム記録媒体。

以上、上述した実施形態を参照して本発明を説明した。しかしながら、本発明は、上述した実施形態には限定されない。即ち、本発明は、本発明のスコープ内において、種々の上記開示要素の多様な組み合わせ乃至選択など、当業者が理解し得る様々な態様を適用することができる。

この出願は、２０１６年８月２３日に出願された日本出願特願２０１６−１６２５１７を基礎とする優先権を主張し、その開示の全てをここに取り込む。

本発明はポータルサイトを保有するシステムに適用可能である。

１０仮想ＢＲＡＳシステム
１１集中管理サーバ
１２加入者情報管理サーバ
１３ＩＰＦＥ
１４ＮＡＴ
２０，２０ａ、２０ｂポータルサーバ
２２保守用端末
２３ＣＰＥ
２４インターネット
１０１、１０２、１０３ＨＴＴＰ送受信部
１０４加入者識別番号検出部
１０５収容先確認部
１０６ＨＴＴＰリダイレクト先通知部
１０７収容先決定部
１０８ポータルサーバ管理部
１１０データベース
１１１認証部
１１２制御部
１１３通信部
２０１負荷分散サーバ
２０２フロントエンドサーバ
２０３ビジネスロジックサーバ
２０４データベースサーバ

現在のインターネット環境において、ポータルサイトはＷｅｂ利用の入口であり、ユーザが容易にサービス提供サーバへアクセスできるようにＷｅｂ上の種々のサービスや情報を集約してＷｅｂ画面上に提示する。通常、加入者は、通信事業者から事前に配布されたアクセス先のＵＲＬ(Uniform Resource Locator)、加入者識別番号等の設定情報を用いてポータルサーバへアクセスする。したがって、加入者は通信事業者が指定したポータルサーバに固定されていると云える。これまで提案されてきたサービス提供システムやポータルサーバは、このアーキテクチャに基づいた種々の応用例である。たとえば、特許文献１には、ポータルサーバでユーザ認証を行い、所望のソフトウエア提供サーバへリダイレクトさせることにより、パッケージソフトの取得を容易にするシステムが提案されている。

本発明の一態様にかかるポータルサーバを管理する装置としてコンピュータを機能させるプログラムは、加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出する機能と、前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける機能と、を前記コンピュータに実現する。

なお、上述したサーバの各部は、図１２に例示するハードウエア資源において実現される。すなわち、図１２に示す構成は、プロセッサ４０１、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）４０２、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）４０３、外部接続インタフェース４０４、記憶装置４０５および各構成要素を接続するバス４０６を備える。

Claims

ポータルサーバを管理する装置であって、
加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出する検出手段と、
前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける制御手段と、
を有する管理装置。
前記制御手段が、加入者識別情報と収容先ポータルサーバとの対応情報を参照することで前記アクセス要求の収容先を前記複数のポータルサーバの一つに決定する、請求項１に記載の管理装置。
通信可能なサーバに前記対応情報が格納され、前記サーバから前記対応情報を取得する、請求項２に記載の管理装置。
前記制御手段が、前記加入者識別情報に対応するポータルサーバの位置情報をリダイレクト先として前記加入者端末へ通知する、請求項１−３のいずれか１項に記載の管理装置。
前記制御手段が、前記複数のポータルサーバの負荷状況を監視し、前記負荷状況に基づいて前記アクセス要求の収容先を前記複数のポータルサーバの一つに振り分ける、請求項１−４のいずれか１項に記載の管理装置。
請求項１−５のいずれか１項に記載の管理装置を含む仮想ＢＲＡＳ(Broadband Remote Access Server)システム。
請求項１−５のいずれか１項に記載の管理装置を含むサーバ。
請求項１−５のいずれか１項に記載の管理装置を含むＩＰＦＥ(Internet Protocol Front End)。
ポータルサーバを管理する方法であって、
検出手段が加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出し、
制御手段が、前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける、
管理方法。
前記制御手段が、加入者識別情報と収容先ポータルサーバとの対応情報を参照することで前記アクセス要求の収容先を前記複数のポータルサーバの一つに決定する、請求項９に記載の管理方法。
通信可能なサーバに前記対応情報が格納され、前記サーバから前記対応情報を取得する、請求項１０に記載の管理方法。
前記制御手段が、前記複数のポータルサーバの負荷状況を監視し、前記負荷状況に基づいて前記アクセス要求の収容先を前記複数のポータルサーバの一つに振り分ける、請求項１０−１２のいずれか１項に記載の管理方法。
前記制御手段が、前記加入者識別情報に対応するポータルサーバの位置情報をリダイレクト先として前記加入者端末へ通知する、請求項９−１２のいずれか１項に記載の管理方法。
ポータルサーバを管理するシステムであって、
加入者識別情報と複数のポータルサーバとの対応情報を格納する第一サーバと、
加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出し、前記加入者識別情報と前記第一サーバの前記対応情報とに基づいて、当該アクセス要求の収容先を前記複数のポータルサーバの一つに振り分ける第二サーバと、
を有する管理システム。
前記第二サーバが、前記第一サーバの前記対応情報を参照することで前記アクセス要求の収容先を前記複数のポータルサーバの一つに決定する、請求項１４に記載の管理システム。
前記第二サーバが、前記複数のポータルサーバの負荷状況を監視し、前記負荷状況に基づいて前記アクセス要求の収容先を前記複数のポータルサーバの一つに振り分ける、請求項１４または１５に記載の管理システム。
前記第二サーバが、前記加入者識別情報に対応するポータルサーバの位置情報をリダイレクト先として前記加入者端末へ通知する、請求項１４−１６のいずれか１項に記載の管理システム。
請求項１４−１７のいずれか１項に記載の管理システムを仮想化されたネットワーク機能として含む仮想ＢＲＡＳ(Broadband Remote Access Server)システム。
ポータルサーバを管理する装置としてコンピュータを機能させるプログラムを記録するプログラム記録媒体であって、
加入者端末から受信したアクセス要求から当該加入者端末の加入者識別情報を検出する機能と、
前記加入者識別情報に基づいて、当該アクセス要求の収容先を複数のポータルサーバの一つに振り分ける機能と、
を前記コンピュータに実現するプログラムを記録するプログラム記録媒体。