複数のクライアントからのアクセスを受付けるホスティングシステムであって、前記ホスティングシステムは、アパッチHTTPサーバを有し、前記アパッチHTTPサーバはネームベースで作動するバーチャルホスト機能を有し、アパッチHTTPサーバは所定のリソースを有し、前記ホスティングシステムは、前記クライアントからのアクセスを受けるアクセス受付手段と、前記アクセス受付手段が受付けたアクセスによる前記リソースの消費量を測定するリソース消費量測定手段と、前記リソース消費量測定手段が測定したリソース消費量に応じて、利用できるリソースを制限するリソース制限手段とを含む、ホスティングシステム。前記アクセス受付手段はクライアントからのアクセスをリクエスト毎に受けるリクエスト受付手段を含み、前記リソース消費量測定手段はリクエスト受付手段が受付けたリクエスト単位でリソース消費量を測定する、請求項1に記載のホスティングシステム。前記リソース制限手段は、前記バーチャルホスト単位でのリソースの制限を行なう、請求項1または2に記載のホスティングシステム。さらにクライアントからの同時接続数を制限する同時接続数制限手段を含む、請求項1~3のいずれかに記載のホスティングシステム。前記同時接続数制限手段は、ファイルまたはディレクトリに対する同時接続数を制限するファイルまたはディレクトリ同時接続数制限手段を含む、請求項4に記載のホスティングシステム。前記同時接続数制限手段は、アクセスするクライアントに対する同時接続数を制限するクライアント同時接続数制限手段を含む、請求項4または5に記載のホスティングシステム。さらに前記リソースの制限値を設定するリソース制限値設定手段を含む、請求項1~6のいずれかに記載のホスティングシステム。従来のホスティングシステムにおいてリソースを適切に管理するには上記のように行なわれていた。また、このようなホスティングシステムにおいては、一般的に、運用面やセキュリティ面で実績のあるIPベースの構成をWebホスティングシステムに採用してきた。ここでのIPベースとは、OS上で複数のチェンジルート以下、chroot環境を構築し、各chroot環境で別のIPアドレスを設定して各種サービスを稼働させる構成のことである。ここで、chrootとは、現在のプロセスとその子プロセス群に対してルートディレクトリを変更する操作である。ルートディレクトリを別のディレクトリに変更されたプロセスは、その範囲外のファイルにはアクセスできなくなるため、この構成では、セキュリティ面や運用の柔軟性は向上するが、IPアドレスの数やプロセスの数の増加と共に、リソース消費量も増大していくという課題があった。このように、これまではリソースよりもセキュリティの堅牢性や運用の柔軟性を優先していた。しかし、今後はクラウドや低価格ホスティング等が主流となるため、ホスティング企業としては限られたリソースで最大限のセキュリティや運用性を担保する必要がある。そこで、この発明は、限られたリソースで最大限のセキュリティや運用性を担保できるホスティングシステムを提供することを目的とする。この発明に係るホスティングシステムは、複数のクライアントからのアクセスを受付けるホスティングシステムである。ホスティングシステムは、アパッチHTTPサーバを有し、アパッチHTTPサーバはネームベースで作動するバーチャルホスト機能を有し、アパッチHTTPサーバは所定のリソースを有し、ホスティングシステムは、クライアントからのアクセスを受けるアクセス受付手段と、アクセス受付手段が受付けたアクセスによるリソースの消費量を測定するリソース消費量測定手段と、リソース消費量測定手段が測定したリソース消費量に応じて、利用できるリソースを制限するリソース制限手段とを含む。好ましくは、アクセス受付手段はクライアントからのアクセスをリクエスト毎に受けるリクエスト受付手段を含み、リソース消費量測定手段はリクエスト受付手段が受付けたリクエスト単位でリソース消費量を測定する。さらに好ましくは、リソース制限手段は、バーチャルホスト単位でのリソースの制限を行なう。さらにクライアントからの同時接続数を制限する同時接続数制限手段を含んでもよい。同時接続数制限手段は、ファイルまたはディレクトリに対する同時接続数を制限するファイルまたはディレクトリ同時接続数制限手段を含んでもよいし、アクセスするクライアントに対する同時接続数を制限するクライアント同時接続数制限手段を含んでもよい。さらに、リソースの制限値を設定するリソース制限値設定手段を含んでもよい。この発明に係るホスティングシステムは、サーバソフトウエアとしてアパッチを使用し、アパッチが提供するネームベース機能を有するバーチャルホスト機能を利用した。ユーザからのリクエストを受けると、リクエスト単位でリソース消費量を測定し、測定したリソース消費量に応じて、利用できるリソースを制限するようにした。システムとしてネームベースを用いると共に、リソースの消費量に応じてリソースを制限するのうにしたため、限られたリソースで最大限のセキュリティや運用性を担保できるホスティングシステムを提供できる。まず初めに、発明者らがこの発明にいたった考え方について説明する。Webサーバーの構成には、大きく分けてIPベースとネームベースがある。IPベースの概要を示すブロック図を図1Aに、ネームベースの概要を示すブロック図を図1Bに示す。IPベースは工夫次第で可用性の高いシステムを構築することができる。図1Aを参照して、IPベースは、OSの上にchroot環境が複数設けられ、その各々にIPアドレスが与えられ、アパッチが作動する。すなわち、OSのシステム領域とほぼ同等の環境をOS上に作成し、その環境でchrootする。chroot環境内部からOSのシステム領域に到達することはできないため、セキュリティ面で堅牢である。また、chroot環境はOSのシステム領域とほぼ同等のライブラリ群を配置できるため、ソフトウェアやアプリケーションもOSとは区別された領域で独立して起動することができる。ソフトウェアの設定等もほぼ全て扱うことができるため、運用面でも可用性が高い。しかし、各chroot環境で独立してプロセスが起動するため、リソースを多く消費する。図1Bを参照して、ネームベースでは、OSの上に1つのIPアドレスが与えられ、その上でアパッチ以下、Apacheという場合があるが作動し、1つのアパッチの上で複数のバーチャルホスト以下、VirtualHostというが作動する。したがって、リソースを最小限に抑えたシステムを構築することができる。VirtualHostでは、ホスト名に対するアクセスがあった場合、Apache内部でホスト名に対応したドキュメントルートにアクセスするように制御する。そのため、複数のホストに対して1つのApacheの親プロセスが起動していればよく、IPベースのようにホストの数だけプロセスを起動しておく必要がないため、リソースを最小限に抑えることができる。しかし、VirtualHostでは各ホストで可能な設定は限られており、柔軟な設定ができない問題や、1つの親プロセスで起動しており、全てのホストが同じgidで実行されてしまうため、セキュリティ面での工夫が必要となっている。ここで、uidとは、ユーザー識別子UserIdentifierであり、gidとは、ユーザーをグループに属するものとし、このグループを識別するグループ識別子GroupIdentifierである。VitualHost採用にあたり、ネームベース構成の課題を解決するための手法が世の中に数多く存在するが、どれも一長一短の手法となっている。そこで、発明者らは、これを解決するために、ホスティングシステムを次のように構成した。図2は、この実施の形態におけるレンタルサーバシステム10の全体構成を示すブロック図である。図1を参照して、レンタルサーバシステム10は、複数のクライアント40図中41~43で示すと、ホスティングシステム20と、インターネットのようなネットワーク50とから構成されている。ホスティングシステム20は、上記したネームベースのアパッチHTTPサーバ以下、アパッチサーバという30で構成されている。アパッチサーバ30は複数の任意のモジュールを接続可能である。図3はこの実施の形態におけるアパッチサーバ30に接続された機能モジュールを示す図である。ここでは、アパッチサーバ30はクライアント40からの同時接続数を制限する同時接続数制限モジュール31と、プロセス情報から、プロセスが消費したリソース量を測定する処理計測モジュール32と、クライアント40からのリソースの使用を制限するリソース制限モジュール33とを含む。アパッチサーバ30のVirtualHostにおいて、プロセス情報からの高負荷対象の特定や、リソースの測定は困難とされている。そこで、発明者は、クライアント40からApacheへのリクエストがあり、処理を行ってからレスポンスを返すまでに、プロセスが消費したリソース量を測定するモジュールとして処理計測モジュール32を開発した。このモジュールによって、指定したリソース量を超えた場合に、リクエストのあったファイル名、ホスト名、システムCPU使用時間、ユーザーCPU使用時間、メモリ使用量を計測しロギングできる。指定できるリソース量は、システムCPU時間、ユーザーCPU時間、メモリ使用量となっている。このモジュールによって、レンタルサーバシステム10の運用者はVirualHost等を気にすることなく、高負荷ホストやスクリプトを早期に調査、検知し適切にチューニングすることができる。図4にリソース消費量測定機能の設定例を示すプログラム、図5に設定後のログの出力例を示す。次に、同時接続数制限モジュールについて説明する。従来のVirtualHost単位でのチューニング機能はあまり充実していない。たとえば、VirtualHost毎に同時接続可能なクライアント40の数MaxClinetsを設定できない等が挙げられる。そこで、発明者は、ホストやディレクトリ単位、又はスクリプト等のファイル単位で同時接続数を制限できる機能としてこのモジュールを実装した。このモジュールを用いて的確に負荷対象のみをチューニングする方法について以下に説明する。同時接続数制限モジュール31は、ファイル及びディレクトリに対する同時接続数チューニングモジュールとクライアントIPに対する同時接続数チューニングモジュールとを含む。まず、ファイル及びディレクトリに対する同時接続数チューニングモジュールについて説明する。人気サイトでは、しばしば同一スクリプトやメディア、ホストに対して、複数のクライアントから同時に大量のアクセスが発生する。その結果、高負荷となってサーバーのレスポンスが大きく低下し、場合によってはサーバーダウンとなる。そこで、高負荷ホスト全体や高負荷スクリプトへのアクセスをチューニングするために、リクエスト対象への同時接続数をチューニングする機能を実装した。設定対象は、任意のホストやファイル名、ファイルへのフルパス、任意のディレクトリ、正規表現にマッチしたファイルやフォルダ等であり、同時接続数1からの設定が可能である。同時接続数の設定値を超えた場合は、リターンコード503ServiceUnavailableをクライアント40に返す。図6にファイル及びディレクトリに対する同時接続数のチューニング設定例を示す。設定したディレクトリやファイルにアクセスがあった場合、チューニング値の数しか全クライアント40から同時にアクセスできない。例えば、チューニング値を1にしていた場合は、IPアドレスが172。16。0。1と192。168。0。2から同時厳密には172。16。0。1のリクエスト処理中に192。168。0。2からリクエストが発生にアクセスがあった場合、172。16。0。1のリクエスト処理中は192。168。0。2のリクエストに対してリクエスト処理を行わず503を返す。次に、クライアントIPに対する同時接続数チューニングモジュールについて説明する。動画サイトやファイルダウンロードサイトでは、同一IPから様々ファイルに対して並行してダウンロードするような使い方が多く、トラフィックやサーバー負荷を高める原因となる。そこで、クライアントIPから指定のディレクトリやホスト、ファイルに対して同一IPからアクセスがあった場合は、同一IPからの同時接続数をチューニングする機能を実装した。この機能により、同一IPから並行した大量のファイルダウンロードを調整することができる。設定対象は、任意のホストやファイル、ファイルへのフルパス、任意のディレクトリ、正規表現にマッチしたファイルやフォルダ等であり、同時接続数1からの設定が可能である。同時接続数の設定値を超えた場合は、リターンコード503を返す。同様のモジュールとしては、modlimitipconnやmodcbandが存在するが、いずれもディレクトリ単位やファイル単位での正確なチューニングができないため採用していない。図7にファイルやディレクトリに対する、クライアントIP単位の同時接続数をチューニングする場合の設定例を示す。設定したディレクトリやファイルにアクセスがあった場合、アクセス元のクライアントがそれぞれチューニング設定値の数しか同時にアクセスできない。例えば、チューニング値を1にしていた場合は、設定ディレクトリに対して172。16。0。1と192。168。0。2から同時厳密には172。16。0。1のリクエスト処理中に192。168。0。2からリクエストが発生し、さらに172。16。0。1からリクエストが発生にアクセスがあった場合、172。16。0。1のリクエスト処理中は172。16。0。1からのもう1つのリクエストに対してはリクエスト処理を行わず503を返し、192。168。0。2のリクエストに対しては正常に処理を行う。次に、リソース制限モジュール33について説明する。リソース制限モジュール33は、ApacheをインストールしているOS自体の負荷をあらわすロードアベレージという値をOSから取得する。ロードアベレージの値は負荷が高いほど高くなる。そのため、あるロードアベレージの値を閾値に設定し、その値以上になった場合は、Apacheがクライアントにリターンコード503を返す。このようにしてリソース制限を行なう。次に、アパッチサーバ30のCPUが行なう動作について説明する。図8~図10はアパッチサーバ30のCPUがクライアント40からのリクエストを受付てからそのレスポンスの完了までの処理を示すフローチャートである。図8~図10を参照してこの処理について説明する。クライアント40からホスティングシステム20にリクエストが開始されると、ホスティングシステム20はクライアント40からのアクセスリクエストを受付けるステップS11、以下、ステップを省略する。動的設定を取得しS12、クライアントIPの同時接続数制限が存在するか否か、アクセスコンテンツの同時接続数制限が存在するか否か、システムリソース制限値が存在するか否かを判断するS13~S15。これらのいずれかが存在すれば、アクセスコンテンツのパスからリアルパスを解析しS16、設定対象のコンテンツか否かを判断するS17。ここで、設定対象のコンテンツか否かはホスト、ディレクトリ、ファイル単位で行なわれる。一方、これらの制限が存在しなければS13~S15でNO、リクエストの処理を開始するS18。リクエストコンテンツ領域でchrootしS23、リクエストコンテンツのuid、gidのセキュリティをチェックしS24、コンテンツ処理を行ないS25、リクエストコンテンツ領域からchrootを抜けるS26。処理計測機能が有効か否かを判断しS27、有効であればS27でYES、アクセスファイルやアクセスホスト情報とともにリソース結果をログに出力してS28、コンテンツ処理結果をクライアント40に返しS29、処理を終了するS32。処理計測機能が有効でなければS27でNO、S29へ移動して処理を終了するS32。一方、S17で設定対象のコンテンツであればS17でYES、設定閾値を越えているか否かが判断されるS19。S17で設定対象のコンテンツでなかったりS17でNO、S19で設定閾値を越えていないと判断されたときはS19でNO、S18へ移動してリクエストの処理を開始する。S19で設定閾値を超えていればS19でYES、高負荷のためアクセスできない旨をクライアント40に返しS31、処理を終了するS32。以上のように、アパッチサーバ30のCPUは、クライアントからのアクセスを受けるアクセス受付手段と、アクセス受付手段が受付けたアクセスによるリソースの消費量を測定するリソース消費量測定手段と、リソース消費量測定手段が測定したリソース消費量に応じて、利用できるリソースを制限するリソース制限手段と、クライアントからの同時接続数を制限する同時接続数制限手段と、ファイルまたはディレクトリに対する同時接続数を制限するファイルまたはディレクトリ同時接続数制限手段と、アクセスするクライアントに対する同時接続数を制限するクライアント同時接続数制限手段として作動する。次に、リソース変化に対応したチューニング機能について説明する。これは、図8のS15に該当する。この機能は、リソース変化に対応したチューニングを容易にするための新たなアプローチである。VirtualHostは、Apacheの親プロセス一つで起動している。そのため、なんらかの原因で親プロセスが停止した場合は、全てのホストが停止することになる。最も多い原因として、サーバー高負荷によるプロセス停止が挙げられる。そこで、常にサーバーのリソース変化に対応したチューニングが必要となる。Apacheのデフォルトの設定としては、メモリやプロセス数等のチューニングがあるが、CPUのチューニングは限られている。NASやSANによるストレージの統合化に伴いCPU使用量、特にファイルシステムとのIOが大量に発生して高負荷になる場合が多い。なお、これは、複数のサーバのデータ領域を、ストレージに統一し、サーバ間で同様のデータを共有する手法である。そのため、ストレージには複数のサーバからデータの読み込みや書き込みが発生し、負荷がかかる。CPU周りのチューニングとしては、RlimitCPUがあるが、これは指定してCPU使用時間を超過した場合、Apacheの処理ではなくKernelのulimitの機能で処理が強制的に切断されるため、契約等が発生するようなサイトにおいては信頼性が低くなる。そこで、CPU処理やIO処理の負荷の目安となるロードアベレージの数値に着目し、ロードアベレージの数値によってレスポンスを返すかどうかをApacheが判断する機能を実装した。ロードアベレージの数値を閾値として設定し、その数値を超えた場合はリターンコード503を返すことで安全に処理を中断させる。ロードアベレージを用いたチューニングは、任意のファイル、ファイルへのフルパス、任意のディレクトリ、正規表現にマッチしたファイルやフォルダを対象に、1分平均の数値を閾値に設定できる。図11にファイルやディレクトリに対して、ロードアベレージを用いたチューニングの設定例を示す。この場合、指定したディレクトリやファイルにアクセスがあり、かつシステムのロードアベレージがチューニング値を超えていた場合は、リクエスト処理を行わず503を返す。次に、Apacheをリスタートせずに新規ホストを追加するための新たなアプローチについて説明する。新規ホスト納品時にはApacheに設定を追加するため、リスタートが必要となる。しかし、VirtualHostはApacheのリスタートによって全てのホストが一時的に停止するという課題がある。そこで、できる限りApacheのリスタートを実施しないようにするため、ApacheにはDynamicallyConfiguredMassVirtualHosting以降DCMVHとするという設定記述方法がある。本来、ホスト追加時には新規ホスト用のVirtualHost設定を記述する。しかし、VirtualHostの設定はホスト名やドキュメントルート名等が異なるだけで、その他の設定は同じ場合が多い。そこで、DCMVHの設定記述法を利用すると、ドキュメントルートにホスト名を含んだパスになるようにディレクトリを作成しておけば、VirtualHostの設定においてパスのホスト名部分を変数で記述することができる。その記述によって、アクセスのあったホスト名で設定を動的に読み替え、該当のドキュメントルートにアクセスできるようになる。しかし、suEXECの設定はVirtualHostごとにユーザー名とグループ名を指定する必要があり、DCMVHを用いてそれらを動的に設定することができない。そこで、suEXECのユーザー名とグループ名をダミーとして設定し、suEXEC内部でユーザー名とグループ名を解釈するようにsuEXECを改修した。これについては後述する。この改修とDCMVHによって、全てのVirtualHostの設定を一つの設定に書き直すことができる。また、htaccessと同じ機能をもったホスト専用のチューニングファイルを用意した。図12は、htaccessとDCMVHを用いたVirtualHostの動的設定例を示す図である。また、上記したApacheモジュールは。htaccessに記述することでApacheのリスタート無く新たな設定を反映させることができる。以上の動的設定により、運用や新規ホスト追加等の場合に新規設定を追加せず、図12の記述のみでApacheのリスタート無く反映させることができる。次に、この実施の形態に係るホスティングシステムにおいて新たに開発した、シンボリックリンクを含むパスをリアルパスに解釈し直す機能について説明する。マルチドメインサービス等では、複数のホスト名を同じドキュメントルートに紐づける必要がある。上記した動的設定を導入した場合は、ホスト名を表すディレクトリ名に対して、別のホスト名のシンボリックリンクを張ることで簡単にこのサービスを実現することができる。なお、マルチドメインサービスとはWebホスティングにおいて、あるドメインにアクセスした場合と、別のドメインにアクセスがあった場合に、どちらのドメインも同じドキュメントルートにアクセスできるようにするサービスのことである。上記のようにして実装したモジュールでチューニングを行う場合、任意のスクリプトに対するフルパスを指定することがある。Apacheは仕様上、解釈するフルパスがシンボリックリンクを含んでいた場合、リアルパスに解釈し直さない。この設定によって、hogecomやfugajp経由でcpucgiにアクセスがあった場合、両方のホストにチューニング設定が適応される。Filesディレクティブは記述していなくても良いが、記述していた方がcpucgiファイルにマッチした場合でしかディレクティブ内の処理を行わないので、パフォーマンスが上がる。次に、このホスティングシステム20において新たに採用したセキュリティ面の課題解決方法について説明する。セキュリティ問題の課題として、システム領域の覗き見、CGI版PHPの利用に関する課題、suEXECの個別設定がある。それらの問題を解決するために、suEXECを改修した。通常、ApacheにおいてCGIプログラムなどは、コンテンツのユーザーとは関係なく、すべて同じApacheの実行ユーザーデフォルトではnobodyの権限で実行される。例えば、CGIプログラムからアクセスされるデータファイルはnobodyがアクセスできるような権限設定がされていなければならない。しかし、このような権限設定がされたファイルは、CGIを経由してすべてのユーザーによってアクセス可能になってしまう。つまり、別のユーザーによってファイルを閲覧されたり、破壊されたりする恐れがある。そこで、suEXECは、CGIプログラムなどをApacheの実行ユーザー権限ではなく、それぞれのコンテンツユーザーの権限で実行するためのApacheのモジュールである。具体的には、suEXEC時にホスト領域でchrootする機能実装システム領域や他ホスト領域を覗き見できないように、suEXEC時に各ホスト環境でchrootしてからスクリプトを実行するような改修を行った。図14はsuEXEC内部でchrootする仕組みの概要図である。これにより、CGIやPHPはホスト領域内の隔離された領域で実行されるため、ホスト領域より外のファイルを閲覧することができない。そのため、システム領域や他ホスト領域へもアクセスできない。次に、新たな機能として、phpファイルはsuEXEC内部でphpcgiに直接渡して実行する機能について説明する。これは、PHPのシェバン行やパーミッション設定をホスト管理者に強制しないようにするための新たなアプローチである。suEXECを採用するためには、CGI版のPerlとPHPを使用する必要がある。この場合、CGI版PHPにおいては、シェバン行とパーミッション設定をホスト管理者に強制しなければならない課題があった。その課題を解決するため、suEXEC内で。phpファイルはphpcgiに直接渡して実行するように改修した。これによって、phpのシェバン行や実行権限の有無をホスト管理者が意識することなく、CGI版PHPをsuEXEC環境で実行できる。複雑なモジュールやラッパー等を組み込む必要がないという点で非常にシンプルな構成になっている。次に、新たな機能として、ホスト単位でのSuexecUserGroup設定をsuEXECバイナリ内部で解釈する機能について説明する。これは、suEXEC採用によるホスト毎の個別設定を無くすようにするための新たなアプローチである。上記した動的設定において、VirtualHostの設定はほとんどが変数で置き換えることができる。しかし、suEXECを採用した場合は、ホスト単位でユーザー名とグループ名をSuexecUserGroupパラメータに設定する必要がある。これらのパラメータはDynamicallyConfiguredMassVirtualHostingでは対応できない。そこで、suEXECの改修によって、ホスト毎のSuexecUserGroupパラメータに記述するユーザー名とグループ名は全て同一のダミー名を設定し、実行ファイルが存在するディレクトリのuidとgidにsuEXEC内部で読み替えるようにした。また、読み替えの際には、rootのuidとgidであった場合、実行対象のプログラムと実行対象のプログラムが存在するディレクトリとドキュメントルートディレクトリのuidとgidが1つでも異なっていた場合はエラーを返すように実装した。なお、上記実施の形態においては、開発した複数の新たな機能モジュールをアパッチサーバに組み込む場合について説明したが、このうちの任意の機能モジュールのみを実装するようにしてもよい。以上、図面を参照してこの発明の実施形態を説明したが、この発明は、図示した実施形態のものに限定されない。図示された実施形態に対して、この発明と同一の範囲内において、あるいは均等の範囲内において、種々の修正や変形を加えることが可能である。