JP4087427B2 - データ処理システム - Google Patents

Description

本発明は、データ処理技術に関し、特に、複数のデータベースを運用する技術に関する。

インターネットのインフラが整備され、携帯電話端末、パーソナルコンピュータ、ＶｏＩＰ（Voice over Internet Protocol）電話端末などの通信端末が広く普及した現在、インターネットの利用者は爆発的に増加している。このような状況下、コンピュータウイルス、ハッキング、スパムメールなど、セキュリティに関する問題が顕在化しており、通信を適切に制御する技術が求められている。

インターネットを利用して、膨大な情報に容易にアクセスすることができるようになったが、有害な情報が氾濫してきているのも事実であり、有害な情報の発信元に対する規制が追いつかない状況にある。誰もが安心して効果的にインターネットを利用する環境を整えるために、有害なコンテンツに対するアクセスを適切に制御する技術が求められる。

例えば、アクセス許可サイトのリスト、アクセス禁止サイトのリスト、禁止語キーワード、有益語キーワードなどのデータベースを用意し、インターネットを介して外部情報へアクセスする際に、これらのデータベースを参照して、アクセスを制御する技術が提案されている（例えば、特許文献１参照）。
特開２００１−２８２７９７号公報

特許文献１に記載されたようなアクセス制御を実現するシステムにおいて、ユーザ数が増加した場合、データベースが膨大になって、格納可能な容量を超える可能性がある。このときに、システム全体を交換しなければならないような構成であったら、無駄な費用がかかり、効率的ではない。また、データベースを更新するなど、運用を停止しなければならないときに、代わりに運用するためのシステムをもう１台設けておくのは、システムが大規模になればなるほど無駄が多く、効率的ではない。

本発明はこうした状況に鑑みてなされたものであり、その目的は、複数のデータベースを適切に運用する技術の提供にある。

本発明のある態様は、データ処理装置に関する。このデータ処理システムは、取得したデータを処理するデータ処理ユニットと、前記データの処理に用いられるデータベースを格納するための複数のデータ保持ユニットと、を備えるデータ処理システムにおいて、前記複数のデータ保持ユニットは、第１のデータベースを共通に保持するとともに、第２のデータベースを分割してそれぞれ保持し、前記データ処理システムは、前記第１のデータベース及び分割された前記第２のデータベースを保持可能な前記データ保持ユニットを更に少なくとも１つ備えることを特徴とする。

複数のデータ保持ユニットにデータベースを分割して保持させ、それらを協働させて運用することにより、個々のデータ保持ユニットの規模を抑えることができるので、データ量の増大などに伴ってシステムの規模を増大させるときの費用や工数を低減することができる。また、データベースの更新などのために、大規模なデータ処理装置全体を二重化して待機させる必要はなく、比較的小規模なデータ保持ユニットを少なくとも１台余分に設けて待機させればよいので、システムの構成が簡素化され、初期投資や運用費用を抑えることができる。

前記第１のデータベースには、分割された前記第２のデータベースのいずれを用いて前記データが処理されるべきかを判定するためのデータが格納されてもよい。例えば、第１のデータベースには、ユーザを認証するためのデータが格納され、第２のデータベースには、ユーザごとにデータ処理の内容などの情報が格納されてもよい。

データ処理システムは、前記複数のデータ保持ユニットの運用状況を管理する運用管理ユニットを更に備えてもよく、前記運用管理ユニットは、前記第２のデータベースを分割して保持するのに必要な数のデータ保持ユニットを運用させるとともに、それ以外のデータ保持ユニットを待機させ、前記運用管理ユニットは、前記データ保持ユニットに保持されたデータベースを更新するときに、待機中のデータ保持ユニットに、運用中のデータ保持ユニットのうちいずれかのデータ保持ユニットが保持しているデータベースの更新データを格納した後、更新前のデータベースを保持する前記データ保持ユニットから、更新後のデータベースを保持する前記データ保持ユニットへ、運用を切り替えてもよい。これにより、運用を停止することなく、データベースを更新することができる。

前記運用管理ユニットは、運用中のデータ保持ユニットが運用不可能な状態になったことを検知したときに、そのデータ保持ユニットが保持していたデータベースを、待機中のデータ保持ユニットに保持させ、待機中のデータ保持ユニットに運用を切り替えてもよい。これにより、いずれかのデータ保持ユニットが故障などにより停止してしまった場合であっても、適切に運用を継続することができる。

前記待機中のデータ保持ユニットに、前記第１のデータベースが予め格納されてもよい。共通に用いられ、また、分割された第２のデータベースのいずれを用いてデータが処理されるべきかを判定するためのデータが格納された第１のデータベースを予め格納しておくことにより、いずれかのデータ保持ユニットが運用不可能な状態になったときに、即座に待機中のデータ保持ユニットに運用を切り替えることができる。

前記データ処理ユニットは、前記複数のデータ保持ユニットのそれぞれに対応して複数設けられてもよく、前記データ処理システムは、取得したデータを前記複数のデータ処理ユニットへ並行して供給するデータ供給ユニットを更に備えてもよい。これにより、データ保持ユニットを追加しても、また、データベースの更新などによりそれぞれのデータ保持ユニットが保持するデータベースの内容が変わっても、適切にデータ処理ユニットによりデータを処理することができる。

前記データ供給ユニットは、取得したデータを加工することなく、そのままの形で前記複数のデータ処理ユニットへ並行して供給してもよい。これにより、データ供給ユニットにおいてデータを加工する処理を省き、データ処理速度を向上させることができる。

前記複数のデータ処理ユニットは、前記データ供給ユニットからデータを取得したとき、対応する前記データ保持ユニットが保持するデータベースを参照して、自身が処理すべきデータであるか否かを判定してもよい。これにより、処理すべきデータ処理ユニットに、適切にデータを処理させることができる。

前記データ処理ユニットは、パケットを取得して通信を制御する通信制御装置であり、前記データ供給ユニットからパケットを取得したとき、自装置宛のパケットであるか否かを判定せずにパケットを取得し、対応する前記データ保持ユニットが保持するデータベースを参照して、自身が処理すべきパケットであるか否かを判定してもよい。これにより、データ処理ユニットにおいて、ＭＡＣアドレスやＩＰアドレスなどのチェックを行う処理を省き、パケットの処理速度を向上させることができる。

前記通信制御装置は、前記パケットのヘッダ部に格納された情報ではなく、データ部に格納された情報を用いて、自身が処理すべきパケットであるか否かを判定してもよい。前記通信制御装置は、対応する前記データ保持ユニットが保持する第１のデータベースを参照して、自身が処理すべきパケットであるか否かを判定してもよい。

自身が処理すべきパケットであると判定したデータ処理ユニットは、そのパケットを処理し、自身が処理すべきパケットではないと判定したデータ処理ユニットは、そのパケットを破棄してもよい。

前記データ供給ユニットは、取得したパケットをブロードキャストに変換することなく、ユニキャストのまま前記複数の通信制御装置へ並行して供給してもよい。これにより、データ供給ユニットがパケットをブロードキャストに変換するためにヘッダを加工するなどの処理を省き、パケットの処理速度を向上させることができる。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、複数のデータベースを適切に運用する技術を提供することができる。

前提技術に係る通信制御システムの構成を示す図である。 従来の通信制御装置の構成を示す図である。 前提技術に係る通信制御装置の構成を示す図である。 パケット処理回路の内部構成を示す図である。 位置検出回路の内部構成を示す図である。 第１データベースの内部データの例を示す図である。 第１データベースの内部データの別の例を示す図である。 第１データベースの内部データのさらに別の例を示す図である。 バイナリサーチ回路に含まれる比較回路の構成を示す図である。 第２データベースの内部データの例を示す図である。 第２データベースの内部データの別の例を示す図である。 ＵＲＬフィルタリングのためのパケット処理回路の内部構成を示す図である。 図１３（ａ）は、ウイルスリストの内部データの例を示す図であり、図１３（ｂ）は、ホワイトリストの内部データの例を示す図であり、図１３（ｃ）は、ブラックリストの内部データの例を示す図である。 共通カテゴリリストの内部データの例を示す図である。 図１５（ａ）（ｂ）（ｃ）（ｄ）は、第２データベースの内部データの例を示す図である。 ウイルスリスト、ホワイトリスト、ブラックリスト、及び共通カテゴリリストの優先度を示す図である。 実施の形態に係る通信制御システムの構成を示す図である。 実施の形態に係る通信制御装置の構成を示す図である。 運用監視サーバに設けられた管理テーブルの内部データの例を示す図である。 通信制御装置が故障したときの運用方法を説明するための図である。 図２１（ａ）（ｂ）（ｃ）は、通信制御装置のデータベースを更新する方法を説明するための図である。 複数の通信制御装置によりパケットを処理するために設けられた通信経路制御装置の構成を示す図である。

符号の説明

１０ 通信制御装置、２０ パケット処理回路、３０ 検索回路、３２ 位置検出回路、３３ 比較回路、３４ インデックス回路、３５ 比較回路、３６ バイナリサーチ回路、４０ 処理実行回路、５０ 第１データベース、５７ ユーザデータベース、６０ 第２データベース、１００ 通信制御システム、１１０ 運用監視サーバ、１１１ 管理テーブル、１２０ 接続管理サーバ、１３０ メッセージ出力サーバ、１４０ ログ管理サーバ、１５０ データベースサーバ、１６０ ＵＲＬデータベース、１６１ ウイルスリスト、１６２ ホワイトリスト、１６３ ブラックリスト、１６４ 共通カテゴリリスト、２００ 通信経路制御装置、２１０ スイッチ、２２０ 光スプリッタ、２３０ スイッチ。

（前提技術）
まず、前提技術として、データ処理装置の一例である通信制御装置と、その周辺装置の構成及び動作の概要について説明し、更に、通信制御装置を用いたＵＲＬフィルタリング技術について説明した後、実施の形態として、複数の通信制御装置を運用する技術について説明する。

図１は、前提技術に係る通信制御システムの構成を示す。通信制御システム１００は、通信制御装置１０と、通信制御装置１０の動作を支援するために設けられた各種の周辺装置を含む。前提技術の通信制御装置１０は、インターネットサービスプロバイダなどにより提供されるＵＲＬフィルタリング機能を実現する。ネットワークの経路に設けられた通信制御装置１０は、コンテンツに対するアクセス要求を取得して、その内容を解析し、コンテンツに対するアクセスの許否を判断する。コンテンツに対するアクセスが許可される場合は、通信制御装置１０は、そのアクセス要求を、コンテンツを保持するサーバへ送出する。コンテンツに対するアクセスが禁止される場合は、通信制御装置１０は、そのアクセス要求を破棄し、要求元に対して警告メッセージなどを返信する。前提技術では、通信制御装置１０は、ＨＴＴＰ（HyperText Transfer Protocol）の「ＧＥＴ」リクエストメッセージ等のアクセス要求を受信し、アクセス先のコンテンツのＵＲＬが、アクセスの許否を判断するための基準データのリストに合致するか否かを検索して、コンテンツに対するアクセスの許否を判断する。

周辺装置は、運用監視サーバ１１０、接続管理サーバ１２０、メッセージ出力サーバ１３０、ログ管理サーバ１４０、及びデータベースサーバ１５０を含む。接続管理サーバ１２０は、通信制御装置１０に対する接続を管理する。接続管理サーバ１２０は、例えば、携帯電話端末から送出されたパケットを通信制御装置１０で処理する際に、パケットに含まれる携帯電話端末を一意に識別する情報を用いて、通信制御装置１０のユーザであることを認証する。いったん認証されると、その携帯電話端末に一時的に付されたＩＰアドレスから送出されたパケットは、一定の期間は接続管理サーバ１２０で認証せずに通信制御装置１０へ送られて処理される。メッセージ出力サーバ１３０は、通信制御装置１０により判定されたアクセスの許否の結果に応じて、アクセスの要求先又は要求元に対するメッセージを出力する。ログ管理サーバ１４０は、通信制御装置１０の運用履歴を管理する。データベースサーバ１５０は、ＵＲＬデータベース１６０から最新のデータベースを取得し、通信制御装置１０に入力する。通信制御装置１０の運用を止めずにデータベースを更新するために、通信制御装置１０はバックアップ用のデータベースを有してもよい。運用監視サーバ１１０は、通信制御装置１０と、接続管理サーバ１２０、メッセージ出力サーバ１３０、ログ管理サーバ１４０、データベースサーバ１５０などの周辺装置の運用状況を監視する。運用監視サーバ１１０は、通信制御システム１００の中で最も優先度が高く、通信制御装置１０及び全ての周辺装置の監視制御を行う。通信制御装置１０は、後述するように、専用のハードウェア回路により構成されるが、運用監視サーバ１１０は、本出願人による特許第３０４１３４０号などの技術を利用して、バウンダリスキャン回路を利用して監視のためのデータを通信制御装置１０などとの間で入出力することにより、通信制御装置１０の運用中にも運用状況を監視することができる。

前提技術の通信制御システム１００は、以下に説明するように、高速化のために専用のハードウェア回路により構成された通信制御装置１０を、周辺に接続された各種の機能を有するサーバ群により制御する構成とすることにより、サーバ群のソフトウェアを適当に入れ替えることで、同様の構成により各種の機能を実現することができる。前提技術によれば、このような柔軟性の高い通信制御システムを提供することができる。

図２は、従来の通信制御装置１の構成を示す。従来の通信制御装置１は、受信側の通信制御部２と、パケット処理部３と、送出側の通信制御部４とを備える。通信制御部２及び４は、それぞれ、パケットの物理層の処理を行うＰＨＹ処理部５ａ及び５ｂと、パケットのＭＡＣ層の処理を行うＭＡＣ処理部６ａ及び６ｂとを備える。パケット処理部３は、ＩＰ（Internet Protocol）のプロトコル処理を行うＩＰ処理部７、ＴＣＰ（Transport Control Protocol）のプロトコル処理を行うＴＣＰ処理部８など、プロトコルに応じた処理を行うプロトコル処理部と、アプリケーション層の処理を行うＡＰ処理部９とを備える。ＡＰ処理部９は、パケットに含まれるデータに応じて、フィルタリングなどの処理を実行する。

従来の通信制御装置１では、パケット処理部３は、汎用プロセッサであるＣＰＵと、ＣＰＵ上で動作するＯＳとを利用して、ソフトウェアにより実現されていた。しかしながら、このような構成では、通信制御装置１の性能はＣＰＵの性能に依存することになり、高速に大容量のパケットを処理可能な通信制御装置を実現しようとしても、自ずと限界がある。例えば、６４ビットのＣＰＵであれば、一度に同時に処理可能なデータ量は最大で６４ビットであり、それ以上の性能を有する通信制御装置は存在しなかった。また、汎用的な機能を有するＯＳの存在を前提としていたので、セキュリティホールなどが存在する可能性が絶無ではなく、ＯＳのバージョンアップなどのメンテナンス作業を必要としていた。

図３は、前提技術の通信制御装置の構成を示す。通信制御装置１０は、図２に示した従来の通信制御装置１においてはＣＰＵ及びＯＳを含むソフトウェアにより実現されていたパケット処理部３に代えて、ワイヤードロジック回路による専用のハードウェアにより構成されたパケット処理回路２０を備える。汎用処理回路であるＣＰＵにおいて動作するＯＳとソフトウェアにより通信データを処理するのではなく、通信データを処理するための専用のハードウェア回路を設けることにより、ＣＰＵやＯＳなどに起因する性能の限界を克服し、処理能力の高い通信制御装置を実現することが可能となる。

例えば、パケットフィルタリングなどを実行するために、パケットに含まれるデータに、フィルタリングの判断基準となる基準データが含まれるか否かを検索する場合に、ＣＰＵを用いて通信データと基準データを比較すると、一度に高々６４ビットしか比較することができず、処理速度を向上させようとしてもＣＰＵの性能で頭打ちになるという問題があった。ＣＰＵでは、通信データから６４ビットをメモリへ読み上げ、基準データとの比較を行い、つづいて、次の６４ビットをメモリへ読み上げる、という処理を何度も繰り返し行う必要があるので、メモリへの読み上げ時間が律速となり、処理速度に限界がある。

それに対し、前提技術では、通信データと基準データとを比較するために、ワイヤードロジック回路により構成された専用のハードウェア回路を設ける。この回路は、６４ビットよりも長いデータ長、例えば、１０２４ビットのデータ長の比較を可能とするために、並列に設けられた複数の比較器を含む。このように、専用のハードウェアを設けることにより、同時に並列して多数のビットマッチングを実行することができる。従来のＣＰＵを用いた通信制御装置１では一度に６４ビットしか処理できなかったところを、一度に１０２４ビットの処理を可能にすることで、飛躍的に処理速度を向上させることができる。比較器の数を多くすれば処理能力も向上するが、コストやサイズも増大するので、所望の処理性能と、コスト、サイズ、などを考慮して、最適なハードウェア回路を設計すればよい。専用のハードウェア回路は、ＦＰＧＡ（Field Programmable Gate Array）などを用いて実現されてもよい。

また、前提技術の通信制御装置１０は、ワイヤードロジック回路による専用のハードウェアにより構成されるので、ＯＳ（Operating System）を必要としない。このため、ＯＳのインストール、バグ対応、バージョンアップなどの作業が必要なく、管理やメンテナンスのためのコストや工数を低減させることができる。また、汎用的な機能が求められるＣＰＵとは異なり、不必要な機能を包含していないので、余計なリソースを用いることがなく、低コスト化、回路面積の低減、処理速度の向上などが望める。さらに、ＯＳを利用していた従来の通信制御装置とは異なり、余分な機能を有しないので、セキュリティホールなどが発生する可能性が低く、ネットワークを介した悪意ある第三者からの攻撃に対する耐性に優れている。

図４は、パケット処理回路の内部構成を示す。パケット処理回路２０は、通信データに対して実行する処理の内容を決定するための基準となる基準データを記憶する第１データベース５０と、受信された通信データの中に基準データが含まれているか否かを、通信データと基準データとを比較することにより検索する検索回路３０と、検索回路３０による検索結果と通信データに対して実行する処理の内容とを対応づけて記憶する第２データベース６０と、検索回路３０による検索結果と第２データベース６０に記憶された条件とに基づいて通信データを処理する処理実行回路４０とを含む。

検索回路３０は、通信データの中から基準データと比較すべき比較対象データの位置を検出する位置検出回路３２と、第１データベース５０に記憶された基準データを３以上の範囲に分割したとき、比較対象データがそれらの範囲のうちいずれに属するかを判定する判定回路の一例であるインデックス回路３４と、判定された範囲の中で比較対象データと合致する基準データを検索するバイナリサーチ回路３６とを含む。比較対象データを基準データの中から検索する方法としては、任意の検索技術を利用可能であるが、前提技術ではバイナリサーチ法を用いる。

図５は、位置検出回路の内部構成を示す。位置検出回路３２は、比較対象データの位置を特定するための位置特定データと通信データとを比較するための複数の比較回路３３ａ〜３３ｆを含む。ここでは、６個の比較回路３３ａ〜３３ｆが設けられているが、後述するように、比較回路の個数は任意でよい。それぞれの比較回路３３ａ〜３３ｆには、通信データが、所定のデータ長、例えば、１バイトずつずらして入力される。そして、これら複数の比較回路３３ａ〜３３ｆにおいて、同時に並列して、検出すべき位置特定データと通信データとの比較がなされる。

前提技術においては、通信制御装置１０の動作を説明するための例として、通信データ中に含まれる「Ｎｏ． ＃＃＃」という文字列を検出し、その文字列中に含まれる数字「＃＃＃」を基準データと比較して、基準データに合致した場合はパケットの通過を許可し、合致しなかった場合はパケットを破棄する処理を行う場合について説明する。

図５の例では、通信データの中から、数字「＃＃＃」の位置を特定するための位置特定データ「Ｎｏ．」を検出するために、通信データ「０１Ｎｏ． ３６１・・・」を、１文字ずつずらして比較回路３３ａ〜３３ｆに入力している。すなわち、比較回路３３ａには「０１Ｎ」が、比較回路３３ｂには「１Ｎｏ」が、比較回路３３ｃには「Ｎｏ．」が、比較回路３３ｄには「ｏ． 」が、比較回路３３ｅには「． ３」が、比較回路３３ｆには「 ３６」が、それぞれ入力される。ここで、比較回路３３ａ〜３３ｆが同時に位置特定データ「Ｎｏ．」との比較を実行する。これにより、比較回路３３ｃがマッチし、通信データの先頭から３文字目に「Ｎｏ．」という文字列が存在することが検出される。こうして、位置検出回路３２により検出された位置特定データ「Ｎｏ．」の次に、比較対象データである数字のデータが存在することが検出される。

ＣＰＵにより同様の処理を行うならば、まず、文字列「０１Ｎ」を「Ｎｏ．」と比較し、続いて、文字列「１Ｎｏ」を「Ｎｏ．」と比較する、というように、先頭から順に１つずつ比較処理を実行する必要があるため、検出速度の向上は望めない。これに対し、前提技術の通信制御装置１０では、複数の比較回路３３ａ〜３３ｆを並列に設けることにより、ＣＰＵではなしえなかった同時並列的な比較処理が可能となり、処理速度を格段に向上させることができる。比較回路は多ければ多いほど同時に比較可能な位置が多くなるので、検出速度も向上するが、コスト、サイズ、などを考慮の上、所望の検出速度を得られるのに十分な数の比較回路を設ければよい。

位置検出回路３２は、位置特定データを検出するためだけでなく、汎用的に文字列を検出する回路として利用されてもよい。また、文字列だけでなく、ビット単位で位置特定データを検出するように構成されてもよい。

図６は、第１データベースの内部データの例を示す。第１データベース５０には、パケットのフィルタリング、ルーティング、スイッチング、置換などの処理の内容を決定するための基準となる基準データが、何らかのソート条件にしたがってソートされて格納されている。図６の例では、１０００個の基準データが記憶されている。

第１データベース５０の先頭のレコードには、通信データ中の比較対象データの位置を示すオフセット５１が格納されている。例えば、ＴＣＰパケットにおいては、パケット内のデータ構成がビット単位で定められているため、パケットの処理内容を決定するためのフラグ情報などの位置をオフセット５１として設定しておけば、必要なビットのみを比較して処理内容を決定することができるので、処理効率を向上させることができる。また、パケットのデータ構成が変更された場合であっても、オフセット５１を変更することで対応することができる。第１データベース５０には、比較対象データのデータ長を格納しておいてもよい。これにより、必要な比較器のみを動作させて比較を行うことができるので、検索効率を向上させることができる。

インデックス回路３４は、第１データベース５０に格納されている基準データを３以上の範囲５２ａ〜５２ｄに分割したとき、比較対象データがそれらの範囲のうちいずれに属するかを判定する。図６の例では、１０００個の基準データは、２５０個ずつ４つの範囲５２ａ〜５２ｄに分割されている。インデックス回路３４は、範囲の境界の基準データと比較対象データとを比較する複数の比較回路３５ａ〜３５ｃを含む。比較回路３５ａ〜３５ｃにより比較対象データと境界の基準データとを同時に並列して比較することにより、比較対象データがいずれの範囲に属するかを１度の比較処理で判定することができる。

前述したように、ＣＰＵによりバイナリサーチを実行する場合は、同時に複数の比較を実行することができないが、前提技術の通信制御装置１０では、複数の比較回路３５ａ〜３５ｃを並列に設けることにより、同時並列的な比較処理を可能とし、検索速度を格段に向上させることができる。

インデックス回路３４により範囲が判定されると、バイナリサーチ回路３６がバイナリサーチ法により検索を実行する。バイナリサーチ回路３６は、インデックス回路３４により判定された範囲をさらに２分割し、その境界位置にある基準データと比較対象データとを比較することにより、いずれの範囲に属するかを判定する。バイナリサーチ回路３６は、基準データと比較対象データとをビット単位で比較する比較回路を複数個、例えば前提技術では１０２４個含んでおり、１０２４ビットのビットマッチングを同時に実行する。２分割された範囲のいずれに属するかが判定されると、さらに、その範囲を２分割して境界位置にある基準データを読み出し、比較対象データと比較する。以降、この処理を繰り返すことにより範囲をさらに限定し、最終的に比較対象データと合致する基準データを検索する。

前述した例を用いてさらに詳細に動作を説明する。図５に示した通信データにおいて、位置特定データ「Ｎｏ．」につづく比較対象データは「３６１」という数字である。位置特定データ「Ｎｏ．」と比較対象データ「３６１」との間には１文字分のスペースが存在しているので、このスペースを比較対象データから除くために、オフセット５１が「８」ビットに設定されている。バイナリサーチ回路３６は、位置特定データ「Ｎｏ．」につづく通信データから、「８」ビット、すなわち１バイト分をスキップし、さらにつづく「３６１」を比較対象データとして読み込む。

インデックス回路３４の比較回路３５ａ〜３５ｃには、比較対象データとして「３６１」が入力され、基準データとして、比較回路３５ａには、範囲５２ａと５２ｂの境界にある基準データ「３７８」が、比較回路３５ｂには、範囲５２ｂと５２ｃの境界にある基準データ「７０４」が、比較回路３５ｃには、範囲５２ｃと５２ｄの境界にある基準データ「９３７」が、それぞれ入力される。比較回路３５ａ〜３５ｃにより同時に比較が行われ、比較対象データ「３６１」が範囲５２ａに属することが判定される。以降、バイナリサーチ回路３６が基準データの中に比較対象データ「３６１」が存在するか否かを検索する。

図７は、第１データベースの内部データの別の例を示す。図７に示した例では、基準データのデータ数が、第１データベース５０に保持可能なデータ数、ここでは１０００個よりも少ない。このとき、第１データベース５０には、最終データ位置から降順に基準データが格納される。そして、残りのデータには０が格納される。データベースのローディング方法として、先頭からデータを配置せずにローディングエリアの後方から配置し、ローディングエリア先頭に空きが生じた場合は全ての空きをゼロサプレスすることで、データーベースは常にフルの状態になり、バイナリー検索する場合の最大時間を一定にすることができる。また、バイナリサーチ回路３６は、検索中に基準データとして「０」を読み込んだときには、比較結果が自明であるから、比較を行わずに範囲を特定して、次の比較にうつることができる。これにより、検索速度を向上させることができる。

ＣＰＵによるソフトウェア処理においては、第１データベース５０に基準データを格納する際に、最初のデータ位置から昇順に基準データが格納される。残りのデータには、例えば最大値が格納されることになるが、この場合、バイナリサーチにおいて、上述したような比較処理の省略はできない。上述した比較技術は、専用のハードウェア回路により検索回路３０を構成したことにより実現される。

図８は、第１データベースの内部データのさらに別の例を示す。図８に示した例では、基準データを均等に３以上の範囲に分割するのではなく、範囲５２ａは５００個、範囲５２ｂは１００個というように、範囲に属する基準データの数が不均一になっている。これらの範囲は、通信データ中における基準データの出現頻度の分布に応じて設定されてもよい。すなわち、それぞれの範囲に属する基準データの出現頻度の和がほぼ同じになるように範囲が設定されてもよい。これにより、検索効率を向上させることができる。インデックス回路３４の比較回路３５ａ〜３５ｃに入力される基準データは、外部から変更可能になっていてもよい。これにより、範囲を動的に設定することができ、検索効率を最適化することができる。

図９は、バイナリサーチ回路に含まれる比較回路の構成を示す。前述したように、バイナリサーチ回路３６は、１０２４個の比較回路３６ａ、３６ｂ、・・・、を含む。それぞれの比較回路３６ａ、３６ｂ、・・・、には、基準データ５４と比較対象データ５６が１ビットずつ入力され、それらの大小が比較される。インデックス回路３４の各比較回路３５ａ〜３５ｃの内部構成も同様である。このように、専用のハードウェア回路で比較処理を実行することにより、多数の比較回路を並列して動作させ、多数のビットを同時に比較することができるので、比較処理を高速化することができる。

図１０は、第２データベースの内部データの例を示す。第２データベース６０は、検索回路３０による検索結果を格納する検索結果欄６２と、通信データに対して実行する処理の内容を格納する処理内容欄６４とを含み、検索結果と処理内容とを対応づけて保持する。図１０の例では、通信データに基準データが含まれている場合は、そのパケットの通過を許可し、含まれていない場合は、そのパケットを破棄するという条件が設定されている。処理実行回路４０は、検索結果に基づいて第２データベース６０から処理内容を検索し、通信データに対して処理を実行する。処理実行回路４０も、ワイヤードロジック回路により実現されてもよい。

図１１は、第２データベースの内部データの別の例を示す。図１１の例では、基準データごとに、処理内容が設定されている。パケットの置換を行う場合、置換先のデータを第２データベース６０に格納しておいてもよい。パケットのルーティングやスイッチングを行う場合、経路に関する情報を第２データベース６０に格納しておいてもよい。処理実行回路４０は、検索回路３０による検索結果に応じて、第２データベース６０に格納された、フィルタリング、ルーティング、スイッチング、置換などの処理を実行する。図１１のように、基準データごとに処理内容を設定する場合、第１データベース５０と第２データベース６０とを統合してもよい。

第１のデータベース及び第２のデータベースは、外部から書き換え可能に設けられる。これらのデータベースを入れ替えることにより、同じ通信制御装置１０を用いて、さまざまなデータ処理や通信制御を実現することができる。また、検索対象となる基準データを格納したデータベースを２以上設けて、多段階の検索処理を行ってもよい。このとき、検索結果と処理内容とを対応づけて格納したデータベースを２以上設けて、より複雑な条件分岐を実現してもよい。このように、データベースを複数設けて多段階の検索を行う場合に、位置検出回路３２、インデックス回路３４、バイナリサーチ回路３６などを複数設けてもよい。

上述した比較に用いられるデータは、同じ圧縮ロジックにより圧縮されてもよい。比較に際して、比較元のデータと比較先のデータが同じ方式で圧縮されていれば、通常と同様の比較が可能である。これにより、比較の際にローディングするデータ量を低減することができる。ローディングするデータ量が少なくなれば、メモリからデータを読み出すのに要する時間が短縮されるので、全体の処理時間も短縮することができる。また、比較器の量を削減することができるので、装置の小型化、軽量化、低コスト化に寄与することができる。比較に用いられるデータは、圧縮された形式で格納されていてもよいし、メモリから読み出した後、比較の前に圧縮されてもよい。

上述のデータ処理装置として、以下のような態様が考えられる。
［態様１］
取得したデータに対して実行する処理の内容を決定するための基準となる基準データを記憶する第１記憶部と、
前記データの中に前記基準データが含まれているか否かを、前記データと前記基準データとを比較することにより検索する検索部と、
前記検索部による検索結果と前記処理の内容とを対応づけて記憶する第２記憶部と、
前記検索結果に基づいて、前記検索結果に対応づけられた処理を前記データに対して実行する処理部と、を含み、
前記検索部は、ワイヤードロジック回路により構成される
ことを特徴とするデータ処理装置。

［態様２］
上記態様１のデータ処理装置において、前記ワイヤードロジック回路は、前記データと前記基準データとをビット単位で比較する第１比較回路を複数含むことを特徴とするデータ処理装置。

［態様３］
上記態様１のデータ処理装置において、前記検索部は、前記データの中から前記基準データと比較すべき比較対象データの位置を検出する位置検出回路を含むことを特徴とするデータ処理装置。

［態様４］
上記態様３のデータ処理装置において、前記位置検出回路は、前記比較対象データの位置を特定するための位置特定データと前記データとを比較する第２比較回路を複数含み、前記複数の第２比較回路に前記データを所定のデータ長ずつ位置をずらして入力し、前記位置特定データと同時に並列して比較することを特徴とするデータ処理装置。

［態様５］
上記態様１から態様２のいずれかのデータ処理装置において、前記検索部は、バイナリサーチにより前記データの中に前記基準データが含まれているか否かを検索するバイナリサーチ回路を含むことを特徴とするデータ処理装置。

［態様６］
上記態様５のデータ処理装置において、前記第１記憶部に保持可能なデータ数よりも前記基準データのデータ数の方が少ない場合、前記第１記憶部の最終データ位置から降順に前記基準データを格納し、残りのデータに０を格納することを特徴とするデータ処理装置。

［態様７］
上記態様１から態様６のいずれかのデータ処理装置において、前記検索部は、前記第１記憶部に記憶された複数の基準データを３以上の範囲に分割したとき、前記基準データと比較すべき比較対象データがそれらの範囲のうちいずれに属するかを判定する判定回路を含むことを特徴とするデータ処理装置。

［態様８］
上記態様７のデータ処理装置において、前記判定回路は、前記範囲の境界の基準データと前記比較対象データとを比較する第３比較回路を複数含み、前記複数の第３比較回路により前記比較対象データが前記３以上の範囲のいずれに属するかを同時に並列して判定することを特徴とするデータ処理装置。

［態様９］
上記態様７又は態様８のデータ処理装置において、前記範囲は、前記データ中における前記基準データの出現頻度の分布に応じて設定されることを特徴とするデータ処理装置。

［態様１０］
上記態様１から態様９のいずれかのデータ処理装置において、前記第１記憶部は、前記データ中の比較対象データの位置を示す情報を更に記憶し、前記検索部は、前記位置を示す情報に基づいて前記比較対象データを抽出することを特徴とするデータ処理装置。

［態様１１］
上記態様１から態様１０のいずれかのデータ処理装置において、前記第１記憶部又は前記第２記憶部は、外部から書き換え可能に設けられることを特徴とするデータ処理装置。

つづいて、上述した通信制御装置１０を利用したＵＲＬフィルタリング技術について説明する。

図１２は、ＵＲＬフィルタリングのためのパケット処理回路２０の内部構成を示す。パケット処理回路２０は、第１データベース５０として、ユーザデータベース５７、ウイルスリスト１６１、ホワイトリスト１６２、ブラックリスト１６３、及び共通カテゴリリスト１６４を備える。ユーザデータベース５７は、通信制御装置１０を利用するユーザの情報を格納する。通信制御装置１０は、ユーザからユーザを識別する情報を受け付け、検索回路３０により受け付けた情報をユーザデータベース５７とマッチングして、ユーザを認証する。ユーザを識別する情報として、ＴＣＰ／ＩＰパケットのＩＰヘッダに格納されたソースアドレスを利用してもよいし、ユーザからユーザＩＤとパスワードなどを受け付けてもよい。前者の場合、パケット中のソースアドレスの格納位置は決まっているので、検索回路３０においてユーザデータベース５７とマッチングするときに、位置検出回路３２により位置を検出する必要はなく、オフセット５１として、ソースアドレスの格納位置を指定すればよい。ユーザデータベース５７に登録されたユーザであることが認証されると、続いて、コンテンツに対するアクセスの許否を判断するために、コンテンツのＵＲＬが、ウイルスリスト１６１、ホワイトリスト１６２、ブラックリスト１６３、及び共通カテゴリリスト１６４に照合される。ホワイトリスト１６２及びブラックリスト１６３はユーザごとに設けられているので、ユーザが認証されてユーザＩＤが一意に決まると、そのユーザのホワイトリスト１６２及びブラックリスト１６３が検索回路３０に与えられる。

ウイルスリスト１６１は、コンピュータウイルスを含むコンテンツのＵＲＬのリストを格納する。ウイルスリスト１６１に格納されたＵＲＬのコンテンツに対するアクセス要求は拒否される。ホワイトリスト１６２は、ユーザごとに設けられ、アクセスを許可するコンテンツのＵＲＬのリストを格納する。ブラックリスト１６３は、ユーザごとに設けられ、アクセスを禁止するコンテンツのＵＲＬのリストを格納する。図１３（ａ）は、ウイルスリスト１６１の内部データの例を示し、図１３（ｂ）は、ホワイトリスト１６２の内部データの例を示し、図１３（ｃ）は、ブラックリスト１６３の内部データの例を示す。ウイルスリスト１６１、ホワイトリスト１６２、及びブラックリスト１６３には、それぞれ、カテゴリ番号欄１６５、ＵＲＬ欄１６６、及びタイトル欄１６７が設けられている。ＵＲＬ欄１６６には、アクセスが許可される、又は禁止されるコンテンツのＵＲＬが格納される。カテゴリ番号欄１６５には、コンテンツのカテゴリの番号が格納される。タイトル欄１６７には、コンテンツのタイトルが格納される。

共通カテゴリリスト１６４は、ＵＲＬで示されるコンテンツを複数のカテゴリに分類するためのリストを格納する。図１４は、共通カテゴリリスト１６４の内部データの例を示す。共通カテゴリリスト１６４にも、カテゴリ番号欄１６５、ＵＲＬ欄１６６、及びタイトル欄１６７が設けられている。

通信制御装置１０は、「ＧＥＴ」リクエストメッセージの中に含まれるＵＲＬを抽出し、そのＵＲＬが、ウイルスリスト１６１、ホワイトリスト１６２、ブラックリスト１６３、又は共通カテゴリリスト１６４に含まれるか否かを検索回路３０により検索する。このとき、例えば、位置検出回路３２により「http://」という文字列を検出し、その文字列に続くデータ列を対象データとして抽出してもよい。抽出されたＵＲＬは、インデックス回路３４及びバイナリサーチ回路３６により、ウイルスリスト１６１、ホワイトリスト１６２、ブラックリスト１６３、及び共通カテゴリリスト１６４の基準データとマッチングされる。

図１５（ａ）、（ｂ）、（ｃ）、及び（ｄ）は、ＵＲＬフィルタリングのための第２データベース６０の内部データの例を示す。図１５（ａ）は、ウイルスリスト１６１に対する検索結果と処理内容を示す。ＧＥＴリクエストに含まれるＵＲＬが、ウイルスリスト１６１に含まれるＵＲＬに合致した場合、そのＵＲＬに対するアクセスは禁止される。図１５（ｂ）は、ホワイトリスト１６２に対する検索結果と処理内容を示す。ＧＥＴリクエストに含まれるＵＲＬが、ホワイトリスト１６２に含まれるＵＲＬに合致した場合、そのＵＲＬに対するアクセスは許可される。図１５（ｃ）は、ブラックリスト１６３に対する検索結果と処理内容を示す。ＧＥＴリクエストに含まれるＵＲＬが、ブラックリスト１６３に含まれるＵＲＬに合致した場合、そのＵＲＬに対するアクセスは禁止される。

図１５（ｄ）は、共通カテゴリリスト１６４に対する検索結果と処理内容を示す。図１５（ｄ）に示すように、共通カテゴリリスト１６４に対する検索結果に対して、ユーザは、カテゴリごとに、そのカテゴリに属するコンテンツに対するアクセスを許可するか禁止するかを、個別に設定することができる。共通カテゴリリスト１６４に関する第２データベース６０には、ユーザＩＤ欄１６８及びカテゴリ欄１６９が設けられている。ユーザＩＤ欄１６８には、ユーザを識別するためのＩＤが格納される。カテゴリ欄１６９には、５７種に分類されたカテゴリのそれぞれについて、カテゴリに属するコンテンツに対するアクセスをユーザが許可するか否かを示す情報が格納される。ＧＥＴリクエストに含まれるＵＲＬが、共通カテゴリリスト１６４に含まれるＵＲＬに合致した場合、そのＵＲＬのカテゴリと、ユーザＩＤに基づいて、そのＵＲＬに対するアクセスの許否が判定される。なお、図１５（ｄ）では、共通カテゴリの数が５７であるが、それ以外であってもよい。

図１６は、ウイルスリスト１６１、ホワイトリスト１６２、ブラックリスト１６３、及び共通カテゴリリスト１６４の優先度を示す。前提技術では、ウイルスリスト１６１、ホワイトリスト１６２、ブラックリスト１６３、共通カテゴリリスト１６４の順に優先度が高く、例えば、ホワイトリスト１６２に格納されたアクセスが許可されるコンテンツのＵＲＬであったとしても、そのＵＲＬがウイルスリスト１６１に格納されていれば、コンピュータウイルスを含むコンテンツであるとしてアクセスが禁止される。

従来、ソフトウェアを用いて、このような優先度を考慮したマッチングを行うときは、例えば、優先度の高いリストから順にマッチングを行って最初にヒットしたものを採用するか、優先度の低いリストから順にマッチングを行って後からヒットしたものを上書きするか、いずれかの方法がとられていた。しかしながら、前提技術では、専用のハードウェア回路により構成された通信制御装置１０を利用することにより、ウイルスリスト１６１のマッチングを行う検索回路３０ａと、ホワイトリスト１６２のマッチングを行う検索回路３０ｂと、ブラックリスト１６３のマッチングを行う検索回路３０ｃと、共通カテゴリリスト１６４のマッチングを行う検索回路３０ｄとを設けて、それぞれの検索回路３０において同時に並列してマッチングを行う。そして、複数のリストでヒットした場合は、優先度の高いものを採用する。これにより、複数のデータベースが設けられ、それらに優先度が設定されている場合であっても、検索時間を大幅に短縮することができる。

ウイルスリスト１６１、ホワイトリスト１６２、ブラックリスト１６３、及び共通カテゴリリスト１６４のいずれを優先してアクセスの許否を判断するかは、例えば、第２データベース６０に設定されていてもよい。いずれのリストを優先するかに応じて第２データベース６０の条件を書き換えてもよい。

コンテンツに対するアクセスが許可された場合は、処理実行回路４０は、メッセージ出力サーバ１３０にその旨を通知するための信号を出力する。メッセージ出力サーバ１３０は、コンテンツを保持するサーバに向けて「ＧＥＴ」リクエストメッセージを送出する。コンテンツに対するアクセスが禁止された場合は、処理実行回路４０が、メッセージ出力サーバ１３０にその旨を通知するための信号を出力すると、メッセージ出力サーバ１３０は、アクセス先のサーバに「ＧＥＴ」リクエストメッセージを送信せずに破棄する。このとき、アクセスが禁止された旨の応答メッセージを要求元に送信してもよい。また、強制的に別のウェブページに転送させてもよい。この場合、処理実行回路４０は、デスティネーションアドレスとＵＲＬを転送先のものに書き換えて送出する。応答メッセージや転送先のＵＲＬなどの情報は、第２データベース６０などに格納されていてもよい。

以上の構成及び動作により、不適切なコンテンツに対するアクセスを禁止することができる。また、検索回路３０がＦＰＧＡなどにより構成された専用のハードウェア回路であるから、上述したように高速な検索処理が実現され、トラフィックに与える影響を最小限に抑えつつ、フィルタリング処理を実行することができる。インターネットサービスプロバイダなどが、このようなフィルタリングのサービスを提供することにより、付加価値が高まり、より多くのユーザを集めることができる。

ホワイトリスト１６２又はブラックリスト１６３は、全てのユーザに対して共通に設けられてもよい。

（実施の形態）
つづいて、通信制御システム１００において、複数の通信制御装置１０を設けたときの運用技術について説明する。例えば、上述したＵＲＬによるフィルタリング制御を行う通信制御装置１０において、データベースを格納するためのＲＡＭ（Random Access Memory）などの記憶装置が、１０万人分のユーザに対応するデータを格納可能な容量を有するものとする。このとき、通信制御システム１０のユーザが１０万人を超えると、従来は、１０万人以上のユーザデータを格納可能な記憶装置を設けた通信制御装置１０に置き換える必要があった。しかしながら、本実施の形態の技術によれば、複数の通信制御装置を設け、それらの通信制御装置の記憶装置にホワイトリスト１６２やブラックリスト１６３などのデータベースを分割して保持させ、それらを協働させて運用することにより、１台の大規模な通信制御装置１０として機能させることが可能となる。したがって、ユーザ数が通信制御装置１０の容量を超えたとしても、新たに通信制御装置を追加することにより、ユーザの増加に対応することができる。このように、本実施の形態では、汎用性及び柔軟性の高い通信制御装置１０の運用技術を提案する。この技術によれば、利用者の増大に伴うシステムの改変に要する工数及び費用を低減することができるとともに、当初から利用者の増大を見込んで大規模なシステムを構築する必要がなく、利用者数に応じて適切な数の通信制御装置を設ければよいので、初期投資も抑えることができる。

図１７は、実施の形態に係る通信制御システム１００の構成を示す。本実施の形態の通信制御システム１００では、複数の通信制御装置１０ａ、１０ｂ、１０ｃ、・・・、が設けられており、それらを協働させて、前提技術で説明した通信制御装置１０として機能させる。その他の構成及び動作は、図１に示した前提技術に係る通信制御システム１００と同様である。

本実施の形態の通信制御システム１００では、通信制御装置は、パケットの処理に必要なデータベースの少なくとも一部を分割して保持するのに必要な台数よりも少なくとも１台以上余分に設けられる。例えば、上述した例において、ユーザ数が３０万人以上４０万人未満である場合、運用に必要な通信制御装置の台数は４台であるが、いずれかの通信制御装置が故障したときに代わって運用させるための待機用として、また、通信制御装置に含まれるデータベースを更新するときの待機用として、１台以上の通信制御装置を設け、合計で最低５台の通信制御装置を設ける。従来は、フォールトトレラントのために、システム全体を二重化させる必要があったが、本実施の形態の技術によれば、分割された単位の通信制御装置１０を余分に設けておけばよいので、コストを低減することができる。これら複数の通信制御装置１０ａ、１０ｂ、１０ｃ、・・・、の運用状況は、運用監視サーバ１１０により管理される。本実施の形態の運用監視サーバ１１０は、通信制御装置の運用状況を管理するための管理テーブルを有する。

図１８は、本実施の形態に係る通信制御装置１０の構成を示す。図１８に示した構成において、検索回路３０及び処理実行回路４０が、本発明におけるデータ処理ユニットに相当し、第１データベース５０及び第２データベース６０を保持する構成が、データ保持ユニットに相当する。図１８に示した例では、それぞれの通信制御装置１０ａ、１０ｂ、１０ｃに、データ保持ユニットと、それに対応するデータ処理ユニットが設けられているが、これらの通信制御装置は一体的に１つの装置内に設けられてもよい。また、１つのデータ処理ユニットが、複数のデータ保持ユニットに保持されたデータベースを参照してデータを処理する構成であってもよい。また、データ保持ユニットは、ＲＡＭなどの記憶装置に相当してもよいし、記憶装置の内部の一部の領域に相当してもよいし、複数の記憶装置が１つのデータ保持ユニットに相当してもよい。

通信制御装置１０におけるパケット処理に用いられるデータベースのうち、第１データベース５０のホワイトリスト１６２（図１３（ｂ））及びブラックリスト１６３（図１３（ｃ））、及び第２データベース６０のユーザごとに共通カテゴリリストのアクセス許否を格納したもの（図１５（ｄ））は、ユーザ数に比例して大きな容量を必要とする。したがって、これらのデータベースを分割して通信制御装置１０ａ、１０ｂ、１０ｃ、・・・、のデータ保持ユニットに保持させる。すなわち、ホワイトリスト１６２やブラックリスト１６３は、本発明における第２のデータベースに相当する。ウイルスリスト１６１（図１３（ａ））及び共通カテゴリリスト１６４（図１４）は、全てのユーザに共通に用いられ、さほど容量が大きくないので、全ての通信制御装置１０ａ、１０ｂ、１０ｃ、・・・、のデータ保持ユニットに共通に保持させる。

後述するように、本実施の形態の通信制御システム１００では、処理すべき通信パケットを、運用中の全ての通信制御装置１０ａ、１０ｂ、１０ｃ、・・・、に供給し、それぞれの通信制御装置が、供給されたパケットを処理するか否かを判断する。そのパケットの処理を担当する通信制御装置、すなわち、そのパケットを送信したユーザのデータを保持する通信制御装置のみがパケットを処理し、その他の通信制御装置はパケットを破棄する。そのため、いずれの通信制御装置が処理すべきパケットであるかを判定するためのデータを格納するユーザデータベース５７は必須であり、これがないとパケットを処理することができない。したがって、ユーザデータベース５７は、全ての通信制御装置に共通に保持される。すなわち、ユーザデータベース５７は、本発明における第１のデータベースに相当する。

本実施の形態では、全ての通信制御装置１０ａ、１０ｂ、１０ｃ、・・・、に、全てのユーザのデータを格納したユーザデータベース５７が保持される。通信制御装置は、運用監視サーバ１１０から、自身が担当すべきユーザのユーザＩＤの範囲を通知され、ユーザデータベース５７のうち、通知された範囲のユーザＩＤのデータを用いてユーザの認証を行い、受信したパケットを処理するか否かを判断する。

図１９は、運用監視サーバ１１０に設けられた管理テーブル１１１の内部データの例を示す。管理テーブル１１１には、装置ＩＤ欄１１２、運用状況欄１１３、ユーザＩＤ欄１１４が設けられている。装置ＩＤ欄１１２には、通信制御装置１０ａ、１０ｂ、・・・、の装置ＩＤが格納され、運用状況欄１１３には、その通信制御装置の運用状況が格納され、ユーザＩＤ欄１１４には、その通信制御装置が担当すべきユーザＩＤの範囲が格納される。運用状況には、例えば、「運用中」、「スタンバイ」、「故障中」、「データ更新中」などがある。運用状況欄１１３は、通信制御装置１０ａ、１０ｂ、・・・、の運用状況が変更されるたびに、運用監視サーバ１１０により更新される。図１９に示した例では、「４６５１８３」人のユーザが通信制御システム１００を利用しているので、装置ＩＤ「１」〜「５」の５台の通信制御装置１０が運用されており、装置ＩＤ「６」の通信制御装置１０はスタンバイ状態となっている。

運用監視サーバ１１０は、複数の通信制御装置１０の運用状況を監視し、いずれかの通信制御装置１０においてトラブルが発生して運用不可能な状態になったことを検知したときには、スタンバイ状態となっている通信制御装置１０に、運用が停止した通信制御装置１０と同じデータを格納し、その通信制御装置１０に運用を切り替える。例えば、図２０に示すように、装置ＩＤ「２」の通信制御装置１０が故障により運用停止した場合、スタンバイ状態であった装置ＩＤ「６」の通信制御装置１０に、ユーザＩＤ「１００００１〜２０００００」のデータを格納して運用を開始させる。これにより、何らかのトラブルで通信制御装置１０が停止されるような状況になっても、適切に運用を継続することができる。スタンバイ中の通信制御装置１０には、予めいずれかのデータを格納しておき、ホットスタンバイ状態にしておいてもよいし、コールドスタンバイ状態にしておいてもよい。

本実施の形態では、待機中の通信制御装置１０のデータ保持ユニットに、予めユーザデータベース５７を格納しておく。これにより、ある通信制御装置１０が運用不可能な状態になっても、すぐに待機中の通信制御装置１０に運用を切り替えることができる。前述したように、それぞれの通信制御装置１０は、ユーザＩＤを用いてパケットを処理するか否かを判断するので、ある通信制御装置１０が運用不可能な状態になると、その通信制御装置１０が担当していたユーザのパケットを受信したときに、そのパケットを処理する通信制御装置１０が存在しない状態となり、パケットが処理されない事態が生じてしまう。このような事態からできる限り早急に復旧するために、待機中の通信制御装置１０のデータ保持ユニットにもユーザデータベース５７を予め格納しておき、運用監視サーバ１１０は、運用不可能となった通信制御装置１０が担当していたユーザを待機中の通信制御装置１０に担当させるべく、ユーザＩＤの範囲を通知する。これにより、待機中の通信制御装置１０を即座に運用開始させることができ、パケットが処理されないという事態を最小限に抑えることができる。

ホワイトリスト１６２やブラックリスト１６３などのデータベースを全て待機中の通信制御装置１０に格納してから運用を切り替えると、データベースの格納に時間を要し、パケットが処理されない状態が長期間継続してしまう可能性があるので、ユーザデータベース５７のみが格納された状態で待機中の通信制御装置１０に運用を切り替えてもよい。これにより、完全なＵＲＬフィルタリングサービスは提供できないものの、パケットが処理されないという事態は回避することができる。格納されていないデータベースは、メンテナンス時や、後述するデータベースの更新時などに格納すればよい。ウイルスリスト１６１や共通カテゴリリスト１６４などの共通に用いられるデータベースも、予め待機中の通信制御装置１０に格納しておいてもよい。これにより、運用を切り替えたときに、ウイルスリスト１６１に格納されているＵＲＬへのアクセスを拒否するなどの一部のサービスを提供することができる。

次に、通信制御装置１０に含まれるデータベースを更新する手順について説明する。データベースサーバ１５０は、所定のタイミングでＵＲＬデータベース１６０から最新のデータベースを取得して保持する。また、ユーザの新規登録や退会に伴って、ユーザデータベースを更新して保持する。運用監視サーバ１１０は、所定のタイミングで、データベースサーバ１５０に保持された最新のデータベースを通信制御装置１０に反映させるために、データベースサーバ１５０から通信制御装置１０にデータを転送して格納させる。

図２１（ａ）（ｂ）（ｃ）は、データベースを更新する様子を説明するための図である。図２１（ａ）は、図１９と同様に、装置ＩＤ「１」〜「５」の通信制御装置１０が運用中であり、装置ＩＤ「６」の通信制御装置１０がスタンバイ中である状況を示す。運用監視サーバ１１０は、データベースを更新するタイミングが到来すると、現在スタンバイ状態である通信制御装置１０を特定し、その通信制御装置１０に対してデータを格納するようデータベースサーバ１５０に指示する。図２１（ａ）の例では、装置ＩＤ「６」の通信制御装置１０がスタンバイ中であるから、この通信制御装置１０にデータベースサーバ１５０からデータが格納される。このとき、運用監視サーバ１１０は、装置ＩＤ「６」の運用状況欄１１３を「データ更新中」に変更する。

図２１（ｂ）は、通信制御装置１０のデータベースが更新中である状況を示す。データベースサーバ１５０は、運用中の通信制御装置１０のいずれかが担当するユーザのデータを、スタンバイ中であった装置ＩＤ「６」の通信制御装置１０のユーザデータベース５７に格納する。また、ウイルスリスト１６１、ホワイトリスト１６２、ブラックリスト１６３、共通カテゴリリスト１６４、第２データベース６０のデータも格納する。図２１（ｂ）の例では、装置ＩＤ「１」の通信制御装置１０が担当していた、ユーザＩＤ「０００００１〜１０００００」のユーザのデータを、装置ＩＤ「６」の通信制御装置１０に格納している。

図２１（ｃ）は、装置ＩＤ「６」の通信制御装置１０のデータベースが更新されて運用が開始され、代わって装置ＩＤ「１」の通信制御装置１０がスタンバイ状態となった状況を示す。運用監視サーバ１１０は、装置ＩＤ「６」の通信制御装置１０に対するデータの格納が終了すると、更新後のデータベースを保持する装置ＩＤ「６」の通信制御装置１０の運用を開始すると同時に、更新前のデータベースを保持する装置ＩＤ「１」の通信制御装置１０の運用を停止してスタンバイ状態にする。これにより、データベースが更新された通信制御装置１０に運用が切り替えられる。つづいて、装置ＩＤ「１」の通信制御装置１０に、ユーザＩＤ「１００００１〜２０００００」のユーザのデータを格納した後、装置ＩＤ「１」の通信制御装置１０を運用開始し、装置ＩＤ「２」の通信制御装置１０の運用を停止する。以降、同様に、巡回的にデータベースを更新していくことで、通信制御システム１００の運用を停止することなく、全ての通信制御装置１０のデータベースを背後で更新することができる。

このように、本実施の形態の通信制御装置１０では、各通信制御装置１０に格納されているデータは固定的ではなく、あるユーザのデータが、いずれの通信制御装置１０に格納されているかは、時間によって移り変わる。各通信制御装置１０にパケットを送る前に、いずれの通信制御装置１０にそのユーザのデータが存在するかを判定する処理を行うと、その処理に要する時間が余分にかかる。そのため、本実施の形態では、受信したパケットを全ての通信制御装置１０へ供給し、各通信制御装置１０が、そのパケットを発したユーザのデータを保持しているか否かを判定し、保持していた通信制御装置１０のみがパケットを処理し、保持していなかった通信制御装置１０はパケットを無視する。以下、このような仕組みを実現するための技術について説明する。

図２２は、複数の通信制御装置１０によりパケットを処理するために設けられた通信経路制御装置の構成を示す。通信経路制御装置２００は、スイッチ２１０、データ供給ユニットの一例である光スプリッタ２２０、及びスイッチ２３０を備える。スイッチ２１０は、受信したパケットを通信制御装置１０へ送信する。ここで、スイッチ２１０と通信制御装置１０の間には、複数の通信制御装置１０ａ、１０ｂ、１０ｃにパケットを並行して供給するための光スプリッタ２２０が設けられており、スイッチ２１０は、実際には光スプリッタ２２０へパケットを送信し、光スプリッタ２２０が各通信制御装置へパケットを並行して送信する。

複数の通信制御装置１０ａ、１０ｂ、１０ｃへパケットを送信するために、パケットをブロードキャストに変換すると、例えばヘッダにタイムスタンプを追加するなどの余分な処理が発生し、処理速度が低下してしまう。そのため、パケットに変更を加えずに、光スプリッタ２２０により分割して、ユニキャストのまま複数の通信制御装置１０ａ、１０ｂ、１０ｃへパケットを送信する。この方式を、本明細書では「パラレルキャスト」と呼ぶ。

各通信制御装置は、自装置のＭＡＣアドレス宛のパケットのみを受信するモードではなく、宛先のＭＡＣアドレスに関係なく全てのパケットを受信するプロミスキャスモードに設定される。各通信制御装置は、光スプリッタ２２０からパラレルキャストされたパケットを受信すると、ＭＡＣアドレスのマッチング処理を省き、全てのパケットをいったん取得して、データ保持ユニットに保持されたユーザデータベース５７を参照して前提技術で説明したユーザＩＤのマッチング処理を行い、自身が処理すべきパケットか否かを判定する。図２２に示した例では、パケットを発信したユーザのデータが通信制御装置１０ｃに存在していたので、通信制御装置１０ａ及び１０ｂは、そのパケットを破棄し、通信制御装置１０ｃは、上述したＵＲＬフィルタリング処理を実行する。

通信制御装置１０ｃは、アクセスが禁止された場合など、ユーザ宛にパケットを返信する場合には、光スプリッタ２２０を介さずにスイッチ２１０へ応答パケットを送信する。通信制御装置１０ｃは、パケットを処理した結果、アクセスが許可された場合は、そのパケットをコンテンツの要求先へ送信する。ここで、通信制御装置１０と上流の通信回線の間には、複数の通信制御装置１０ａ、１０ｂ、１０ｃから送出されるパケットを集約するためのスイッチ２３０が設けられており、通信制御装置１０ｃは、実際にはスイッチ２３０へパケットを送信し、スイッチ２３０が上流の通信回線へパケットを送出する。

コンテンツの要求先から返信されたパケットをスイッチ２３０が受信すると、このパケットは通信制御装置１０による処理を必要としないので、スイッチ２３０のポート２３２からスイッチ２１０のポート２１２へ送信され、スイッチ２１０からユーザに向けて送出される。通常、インターネットでは、パケットに対する応答パケットが確実に送信元に返信されるよう、返信経路を確保するために、送信時の経路がパケットに記録される。しかし、本実施の形態では、通信制御経路装置２００内における返信経路が予め用意されているので、経路を記録せずに、すなわち、パケットを加工せずに装置間の通信を行う。これにより、無駄な処理を省き、処理速度を向上させることができる。

図２２の例では、ユーザから発信されたコンテンツの取得要求を含むパケットをコンテンツを保持するサーバへ送出する場合にのみパケットを処理し、コンテンツを保持するサーバからユーザへ送出されたパケットは処理せずに通過させる場合の構成を示しているが、通信制御装置１０が両方向のパケットを処理するように構成してもよい。この場合、通信制御装置１０の両側に光スプリッタ２２０を設ければよい。また、スイッチ２３０からスイッチ２１０へのバイパス経路は設けなくてもよい。

このように、複数の通信制御装置のうち、パケットを処理すべき通信制御装置を予め特定しなくても、全ての通信制御装置に同じパケットをパラレルキャストすることにより、処理すべき通信制御装置に適切にパケットを処理させることができる。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

実施の形態では、複数台の通信制御装置のそれぞれにデータ処理ユニットとデータ保持ユニットが設けられた通信制御システムについて説明したが、本発明の技術は、１台のデータ処理装置の内部に複数のデータ保持ユニットを備えた場合にも同様に適用可能である。また、１つのデータ処理ユニットが複数のデータ保持ユニットに保持されたデータベースを参照してデータを処理する場合にも同様に適用可能である。また、待機用のデータ保持ユニットは、２つ以上設けられてもよい。

本発明は、複数のデータベースを含むデータ処理システムに適用することができる。

Claims (4)

1. アクセス制御の対象となるユーザがアクセス先にアクセスするために送信したパケットを取得し、前記ユーザによる前記アクセス先に対するアクセスの許否を判定する処理を行う複数の通信制御装置と、
   取得したパケットをブロードキャストに変換することなく、ユニキャストのまま複数の前記通信制御装置へ並行して供給するデータ供給ユニットと、を備え、
   前記通信制御装置は、
   複数の前記通信制御装置のそれぞれが処理すべき前記ユーザの識別情報が格納された第１のデータベースと、前記ユーザごとに、前記アクセス先に対するアクセスの許否を格納した第２のデータベースと、を含むデータ保持ユニットと、
   自装置宛のパケットであるか否かを判定せずにパケットを取得し、前記第１のデータベースを参照して、前記パケットのヘッダ部に格納された情報ではなくデータ部に格納された識別情報を用いて、自装置が処理すべきユーザが送信したパケットであるか否かを判定する判定部と、
   自装置が処理すべきユーザが送信したのではないと判定されたパケットを破棄し、自装置が処理すべきユーザが送信したと判定されたパケットに対して、前記第２のデータベースを参照して、前記アクセス先に対するアクセスの許否を判定する処理を実行する処理部と、を含み、
   複数の前記通信制御装置は、前記第１のデータベースを共通に保持するとともに、前記第２のデータベースを分割してそれぞれ保持し、
   前記第１のデータベース及び分割された前記第２のデータベースを保持可能な前記データ保持ユニットを更に少なくとも１つ備えることを特徴とするデータ処理システム。
2. 前記複数のデータ保持ユニットの運用状況を管理する運用管理ユニットを更に備え、
   前記運用管理ユニットは、前記第２のデータベースを分割して保持するのに必要な数のデータ保持ユニットを運用させるとともに、それ以外のデータ保持ユニットを待機させ、
   前記運用管理ユニットは、前記データ保持ユニットに保持されたデータベースを更新するときに、待機中のデータ保持ユニットに、運用中のデータ保持ユニットのうちいずれかのデータ保持ユニットが保持しているデータベースの更新データを格納した後、更新前のデータベースを保持する前記データ保持ユニットから、更新後のデータベースを保持する前記データ保持ユニットへ、運用を切り替える
   ことを特徴とする請求項１に記載のデータ処理システム。
3. 前記運用管理ユニットは、運用中のデータ保持ユニットが運用不可能な状態になったことを検知したときに、そのデータ保持ユニットが保持していたデータベースを、待機中のデータ保持ユニットに保持させ、待機中のデータ保持ユニットに運用を切り替えることを特徴とする請求項２に記載のデータ処理システム。
4. 前記待機中のデータ保持ユニットに、前記第１のデータベースが予め格納されることを特徴とする請求項２又は３に記載のデータ処理システム。

Images