特開 2022-168948 テナント管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022168948

(43)【公開日】2022-11-09

(54)【発明の名称】テナント管理システム

(51)【国際特許分類】

   G06F 9/50 20060101AFI20221101BHJP

【ＦＩ】

G06F9/50 150Z

【審査請求】未請求

【請求項の数】2

【出願形態】ＯＬ

(21)【出願番号】P 2021074658

(22)【出願日】2021-04-27

(71)【出願人】

【識別番号】000006150

【氏名又は名称】京セラドキュメントソリューションズ株式会社

(74)【代理人】

【識別番号】100140796

【弁理士】

【氏名又は名称】原口 貴志

(72)【発明者】

【氏名】丹波 正登

(57)【要約】

【課題】 ユーザーによるテナントの指定を容易化することができるテナント管理システムを提供する。
【解決手段】 テナント管理システムは、テナント別アプリケーションにユーザーからの要求を着信させるアプリケーション管理部と、テナントの識別情報としてサブドメインを管理するテナント管理部とを備え、アプリケーション管理部は、ユーザーからテナントのサーバー名がＦＱＤＮで問い合わせられた場合（Ｓ１８１）に、このＦＱＤＮにおけるサブドメインによって特定されるテナントに対するテナント別アプリケーションを呼び出す（Ｓ１８８）ことを特徴とする。
【選択図】 図１１

【特許請求の範囲】

【請求項1】

パブリッククラウド上に構築されているソリューションにおけるテナント別に用意されたアプリケーションであるテナント別アプリケーションにユーザーからの要求を着信させるアプリケーション管理部と、
前記テナントの識別情報としてサブドメインを管理するテナント管理部と
を備え、
前記アプリケーション管理部は、ユーザーから前記テナントのサーバー名がＦＱＤＮで問い合わせられた場合に、このＦＱＤＮにおける前記サブドメインによって特定される前記テナントに対する前記テナント別アプリケーションを呼び出すことを特徴とするテナント管理システム。

【請求項2】

前記テナント管理部は、前記テナントを登録する場合に指定された前記サブドメインが既に登録されているとき、前記テナントの登録を中止することを特徴とする請求項１に記載のテナント管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、パブリッククラウド上に構築されているソリューションにおけるテナントを管理するテナント管理システムに関する。

【背景技術】

【0002】

従来、テナントの識別情報によって、顧客毎の環境やデータを切り分けるマルチテナントモデルによるテナント管理システムが知られている（例えば、特許文献１参照。）。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２０１９－１３９５９１号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、従来のテナント管理システムにおいては、ユーザーによるテナントの指定方法については開示されていない。

【0005】

そこで、本発明は、ユーザーによるテナントの指定を容易化することができるテナント管理システムを提供することを目的とする。

【課題を解決するための手段】

【0006】

本発明のテナント管理システムは、パブリッククラウド上に構築されているソリューションにおけるテナント別に用意されたアプリケーションであるテナント別アプリケーションにユーザーからの要求を着信させるアプリケーション管理部と、前記テナントの識別情報としてサブドメインを管理するテナント管理部とを備え、前記アプリケーション管理部は、ユーザーから前記テナントのサーバー名がＦＱＤＮで問い合わせられた場合に、このＦＱＤＮにおける前記サブドメインによって特定される前記テナントに対する前記テナント別アプリケーションを呼び出すことを特徴とする。

【0007】

この構成により、本発明のテナント管理システムは、ユーザーからテナントのサーバー名がＦＱＤＮで問い合わせられた場合に、このＦＱＤＮにおけるサブドメインによって特定されるテナントに対するテナント別アプリケーションを呼び出すので、ユーザーによるテナントの指定を容易化することができる。

【0008】

本発明のテナント管理システムにおいて、前記テナント管理部は、前記テナントを登録する場合に指定された前記サブドメインが既に登録されているとき、前記テナントの登録を中止しても良い。

【0009】

この構成により、本発明のテナント管理システムは、テナントを登録する場合に指定されたサブドメインが既に登録されているとき、テナントの登録を中止するので、テナントと、サブドメインとを適切に対応付けることができる。

【発明の効果】

【0010】

本発明のテナント管理システムは、ユーザーによるテナントの指定を容易化することができる。

【図面の簡単な説明】

【0011】

【図1】本発明の一実施の形態に係るテナント管理システムが管理するテナントの説明図である。

【図2】本発明の一実施の形態に係るテナント管理システムのソフトウェア構成のブロック図である。

【図3】図２に示すテナント管理システムのハードウェア構成のブロック図である。

【図4】図２に示す管理テーブルの一例を示す図である。

【図5】図２に示すＡＰＬ管理マスターテーブルの一例を示す図である。

【図6】図５に示す消費リソース単位の算出の方法の一例を示すフローチャートである。

【図7】テナントを登録する場合の図２に示すテナント管理システムの動作のフローチャートである。

【図8】図７に示す動作において管理者コンピューターの表示部に表示される管理画面の一例を示す図である。

【図9】テナントに対してテナント別アプリケーションを新規に登録する場合の図２に示すテナント管理システムの動作のフローチャートである。

【図10】テナントに対する特定のテナント別アプリケーションに対してユーザーを新規に登録する場合の図２に示すテナント管理システムの動作のフローチャートである。

【図11】ユーザーによってテナント別アプリケーションが利用される場合の図２に示すテナント管理システムの動作のシーケンス図である。

【発明を実施するための形態】

【0012】

以下、本発明の実施の形態について、図面を用いて説明する。

【0013】

まず、本発明の一実施の形態に係るテナント管理システムの構成について説明する。

【0014】

図１は、本実施の形態に係るテナント管理システムが管理するテナントの説明図である。

【0015】

図１に示すように、パブリッククラウド１１上にソリューション１２が構築されている。ここで、ソリューション１２としては、例えば、ドキュメントを管理するドキュメント管理ソリューションが採用されることが可能である。

【0016】

ソリューション１２の提供者は、ソリューション１２の少なくとも一部を他者に貸すことが可能である。ソリューション１２の提供者がソリューション１２の少なくとも一部を貸している単位をテナントという。ソリューション１２には、テナント１３など、複数のテナントが存在することが可能である。

【0017】

テナント１３には、ユーザー１４など、複数のユーザーが存在することが可能である。テナント１３以外のテナントの構成も、テナント１３の構成と同様である。

【0018】

図２は、本実施の形態に係るテナント管理システム２０のソフトウェア構成のブロック図である。

【0019】

図２に示すように、テナント管理システム２０は、パブリッククラウド１１（図１参照。）において、例えばデータセンターの外部など、パブリッククラウド１１の外部に公開されたアクセス可能なエンドポイントである外部アクセスポイント２１と、外部からのＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）／ＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ）などの接続を保持し、後述のＷｅｂサーバーへの負荷分散機能を実現するサービスである外部ロードバランサー２２と、外部ロードバランサー２２からの接続要求を受け付けるサービスである接続要求受け付け部２３と、認証を含む外部からの要求を処理するサービスであるリクエスト処理部２４と、後述のテナント別アプリケーションにユーザーからの要求を着信させるサービスであるアプリケーション管理部２５と、テナント別に用意されたアプリケーションであるテナント別アプリケーション２６と、テナントの各種の情報を管理するテナント管理部２７と、Ｗｅｂサーバーのリソースが不足している場合に、新たなクラウドリソースをプロビジョニングするサービスであるサーバーリソース管理部２８と、テナントの管理に必要なデータテーブルを格納するデータベースサービス２９と、外部アクセスポイント２１のＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）を登録するサービスであるＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サービス３０とを備えている。テナント管理システム２０は、テナント別アプリケーション２６以外にも、少なくとも１つのテナント別アプリケーションを備えることが可能である。

【0020】

テナント別アプリケーションは、１つのテナントに対して複数用意されることが可能である。テナント別アプリケーションとしては、例えば、文書管理アプリケーション、スケジュール帳アプリケーション、チャットツールなど、様々なアプリケーションが採用されることが可能である。

【0021】

データベースサービス２９は、テナントを管理するための管理テーブル２９ａと、テナント別アプリケーションを管理するためのＡＰＬ管理マスターテーブル２９ｂとを、テナントの管理に必要なデータテーブルとして格納する。

【0022】

図３は、テナント管理システム２０のハードウェア構成のブロック図である。

【0023】

図３に示すように、テナント管理システム２０は、外部アクセスポイント２１を実現するための外部アクセスポイント用システム４１と、外部ロードバランサー２２を実現するための外部ロードバランサー用システム４２と、Ｗｅｂサーバーの群４３と、データベースサービス２９を実現するためのデータベースサービス用システム４４と、ＤＮＳサービス３０を実現するためのＤＮＳサービス用システム４５とを備えている。外部アクセスポイント用システム４１と、外部ロードバランサー用システム４２と、Ｗｅｂサーバーと、データベースサービス用システム４４と、ＤＮＳサービス用システム４５とは、インターネットなどのネットワーク４６を介して互いに通信可能である。

【0024】

外部アクセスポイント用システム４１、外部ロードバランサー用システム４２、データベースサービス用システム４４およびＤＮＳサービス用システム４５は、それぞれ、少なくとも１つのコンピューターによって実現されている。

【0025】

Ｗｅｂサーバーの群４３は、接続要求受け付け部２３、リクエスト処理部２４、アプリケーション管理部２５、テナント別アプリケーション２６、テナント管理部２７およびサーバーリソース管理部２８を実現する。接続要求受け付け部２３、リクエスト処理部２４、アプリケーション管理部２５、テナント別アプリケーション２６、テナント管理部２７およびサーバーリソース管理部２８の少なくとも１つは、１つのＷｅｂサーバーのみによって実現されても良いし、複数のＷｅｂサーバーによって実現されても良い。群４３における少なくとも１つのＷｅｂサーバーは、接続要求受け付け部２３、リクエスト処理部２４、アプリケーション管理部２５、テナント別アプリケーション２６、テナント管理部２７およびサーバーリソース管理部２８の少なくとも２つを実現しても良い。

【0026】

図４は、管理テーブル２９ａの一例を示す図である。

【0027】

図４に示す管理テーブル２９ａは、ユーザーの住所と、ユーザーの姓と、ユーザーの名と、ユーザーのメールアドレスと、テナント別アプリケーションの識別情報としてのＡＰＩＤと、テナントの識別情報としてのサブドメインと、ユーザーの識別情報としてのユーザーＩＤと、ユーザーのパスワードとの組み合わせを記憶している。

【0028】

図５は、ＡＰＬ管理マスターテーブル２９ｂの一例を示す図である。

【0029】

図５に示すＡＰＬ管理マスターテーブル２９ｂは、テナント別アプリケーションの名前であるＡＰ名と、ＡＰＩＤと、１人のユーザーがテナント別アプリケーションを使用する際に消費されることが想定されるリソースの量を示す消費リソース単位と、同一のテナント別アプリケーションが同時に使用可能であることを保証するリソースの量の上限である所要消費リソースとの組み合わせを、テナント別アプリケーション毎に記憶している。

【0030】

消費リソース単位は、例えば、テナント別アプリケーションを実現するＷｅｂサーバーのリソースが、テナント別アプリケーションを実現する仮想マシンのＣＰＵ、メモリー、ストレージおよびネットワーク帯域である場合、図６に示すように算出されても良い。

【0031】

図６は、図５に示す消費リソース単位の算出の方法の一例を示すフローチャートである。

【0032】

図６に示すように、消費リソース単位の算出の対象のテナント別アプリケーションを１人のユーザーが使用した際の、仮想マシンのＣＰＵ、メモリー、ストレージおよびネットワーク帯域のそれぞれの使用率が測定される（Ｓ１０１）。

【0033】

そして、Ｓ１０１において測定された、４つの使用率の合計を、数１に示す式によって、最大値１００、最小値０で正規化することによって、消費リソース単位を算出する（Ｓ１０２）。

【数1】

【0034】

数１に示す式において、Ｘは、Ｓ１０１において測定された、４つの使用率の合計を示している。Ｙは、消費リソース単位を示しており、Ｘを４で割った値の小数点部分を切り上げた値である。

【0035】

例えば、消費リソース単位の算出の対象のテナント別アプリケーションを１人のユーザーが使用した際の、仮想マシンのＣＰＵ、メモリー、ストレージおよびネットワーク帯域のそれぞれの使用率が例えば４０％、５０％、３０％および５０％である場合、これらの合計が１７０％であるので、消費リソース単位は、４３％である。

【0036】

所要消費リソースは、例えば、対象のテナント別アプリケーションを同時に使用可能であることを保証するユーザーの人数を、このテナント別アプリケーションの消費リソース単位に掛け合わせることによって、算出されても良い。

【0037】

次に、テナント管理システム２０の動作について説明する。

【0038】

まず、テナントを登録する場合のテナント管理システム２０の動作について説明する。

【0039】

図７は、テナントを登録する場合のテナント管理システム２０の動作のフローチャートである。

【0040】

テナント管理システム２０の管理者は、新たなテナントの登録を希望する場合に、テナントの登録の開始の指示を、図示していないコンピューター（以下「管理者コンピューター」という。）を介してテナント管理部２７に送信することができる。管理者コンピューターは、例えば、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）などのコンピューターによって実現されることが可能である。テナント管理部２７は、テナントの登録の開始の指示を受信すると、図７に示す動作を開始する。

【0041】

図７に示すように、テナント管理部２７は、テナントの登録用の管理画面６０（図８参照。）の表示用のデータを管理者コンピューターに送信することによって、管理者コンピューターに管理画面６０を表示させる（Ｓ１２１）。管理者コンピューターは、管理画面６０の表示用のデータを受信すると、受信したデータに応じた管理画面６０を、管理者コンピューター自身の図示していない表示部に表示する。したがって、管理者は、管理者コンピューターの表示部に表示された管理画面６０を確認することができるとともに、管理者コンピューターの図示していない操作部を介して管理画面６０を操作することができる。

【0042】

図８は、管理者コンピューターの表示部に表示される管理画面６０の一例を示す図である。

【0043】

図８に示すように、管理画面６０は、ユーザーの住所が入力されるテキストボックス６１と、ユーザーの姓が入力されるテキストボックス６２ａと、ユーザーの名が入力されるテキストボックス６２ｂと、ユーザーのメールアドレスが入力されるテキストボックス６３と、ＡＰＩＤが入力されるテキストボックス６４と、サブドメインが入力されるテキストボックス６５と、ユーザーＩＤが入力されるテキストボックス６６と、ユーザーのパスワードが入力されるテキストボックス６７と、テナントの登録を中止するためのキャンセルボタン６８と、テナントを登録するための登録ボタン６９とを含んでいる。

【0044】

管理者は、管理者コンピューターの操作部を介して、テキストボックス６１、６２ａ、６２ｂ、６３、６４、６５、６６および６７に値を入力することができる。なお、テキストボックス６４には、ＡＰＬ管理マスターテーブル２９ｂに記憶されているいずれかのＡＰＩＤのみが入力可能である。

【0045】

管理者は、管理者コンピューターの操作部を介して、キャンセルボタン６８および登録ボタン６９を押すことができる。

【0046】

図７に示すように、テナント管理部２７は、Ｓ１２１の処理の後、キャンセルボタン６８が押されたか否かを判断する（Ｓ１２２）。

【0047】

テナント管理部２７は、キャンセルボタン６８が押されたとＳ１２２において判断すると、管理者コンピューターに管理画面６０の表示を終了させて（Ｓ１２３）、図７に示す動作を終了する。

【0048】

テナント管理部２７は、キャンセルボタン６８が押されていないとＳ１２２において判断すると、登録ボタン６９が押されたか否かを判断する（Ｓ１２４）。

【0049】

テナント管理部２７は、登録ボタン６９が押されていないとＳ１２４において判断すると、Ｓ１２２の処理を実行する。

【0050】

テナント管理部２７は、登録ボタン６９が押されたとＳ１２４において判断すると、管理者コンピューターに管理画面６０の表示を終了させる（Ｓ１２５）。

【0051】

次いで、テナント管理部２７は、登録ボタン６９が押された時点でテキストボックス６５に入力されていたサブドメインが管理テーブル２９ａに記憶されているか否かを判断する（Ｓ１２６）。

【0052】

テナント管理部２７は、登録ボタン６９が押された時点でテキストボックス６５に入力されていたサブドメインが管理テーブル２９ａに記憶されているとＳ１２６において判断すると、図示していないエラー画面の表示用のデータを管理者コンピューターに送信することによって、管理者コンピューターにエラー画面を表示させて（Ｓ１２７）、図７に示す動作を終了する。管理者コンピューターは、エラー画面の表示用のデータを受信すると、受信したデータに応じたエラー画面を、管理者コンピューター自身の表示部に表示する。したがって、管理者は、管理者コンピューターの表示部に表示されたエラー画面を確認することができる。

【0053】

テナント管理部２７は、登録ボタン６９が押された時点でテキストボックス６５に入力されていたサブドメインが管理テーブル２９ａに記憶されていないとＳ１２６において判断すると、登録ボタン６９が押された時点で管理画面６０に入力されていた値を管理テーブル２９ａに登録する（Ｓ１２８）。すなわち、テナント管理部２７は、登録ボタン６９が押された時点でテキストボックス６１に入力されていた住所と、登録ボタン６９が押された時点でテキストボックス６２ａに入力されていた姓と、登録ボタン６９が押された時点でテキストボックス６２ｂに入力されていた名と、登録ボタン６９が押された時点でテキストボックス６３に入力されていたメールアドレスと、登録ボタン６９が押された時点でテキストボックス６４に入力されていたＡＰＩＤと、登録ボタン６９が押された時点でテキストボックス６５に入力されていたサブドメインと、登録ボタン６９が押された時点でテキストボックス６６に入力されていたユーザーＩＤと、登録ボタン６９が押された時点でテキストボックス６７に入力されていたパスワードとの組み合わせを管理テーブル２９ａに登録する。

【0054】

サーバーリソース管理部２８は、Ｓ１２８の処理の後、Ｓ１２８において管理テーブル２９ａに登録したＡＰＩＤにＡＰＬ管理マスターテーブル２９ｂにおいて対応付けられている所要消費リソースだけ、特定のリソースを、Ｓ１２８において管理テーブル２９ａに登録したテナントに対する、このＡＰＩＤによって特定されるテナント別アプリケーションのリソースとして、プロビジョニングする（Ｓ１２９）。なお、プロビジョニングするリソースの種類と、種類毎の量とについては、テナント別アプリケーション毎に事前に定められている。

【0055】

サーバーリソース管理部２８は、Ｓ１２９の処理の後、図７に示す動作を終了する。

【0056】

次に、テナントに対してテナント別アプリケーションを新規に登録する場合のテナント管理システム２０の動作について説明する。

【0057】

図９は、テナントに対してテナント別アプリケーションを新規に登録する場合のテナント管理システム２０の動作のフローチャートである。

【0058】

管理者は、特定のテナント（以下、図９に示す動作の説明において「対象テナント」という。）に対する特定のテナント別アプリケーション（以下、図９に示す動作の説明において「対象テナント別アプリケーション」という。）の新規の登録を希望する場合に、対象テナントに対する対象テナント別アプリケーションの新規の登録の開始の指示を管理者コンピューターを介してテナント管理部２７に送信することができる。ここで、対象テナントに対する対象テナント別アプリケーションの新規の登録の際には、対象テナントに対する対象テナント別アプリケーションの対象のいずれか１人のユーザーの住所、姓、名、メールアドレス、ユーザーＩＤおよびパスワードも指定される。テナント管理部２７は、対象テナントに対する対象テナント別アプリケーションの新規の登録の開始の指示を受信すると、図９に示す動作を開始する。

【0059】

図９に示すように、テナント管理部２７は、特定の動作を実行することによって、対象テナントに対して対象テナント別アプリケーションを管理テーブル２９ａに新規に登録する（Ｓ１４１）。ここで、テナント管理部２７は、対象テナント別アプリケーションのＡＰＩＤと、指定されたユーザーの住所、姓、名、メールアドレス、ユーザーＩＤおよびパスワードと、対象テナントのサブドメインとの組み合わせを管理テーブル２９ａに登録する。

【0060】

サーバーリソース管理部２８は、Ｓ１４１の処理の後、対象テナント別アプリケーションのＡＰＩＤにＡＰＬ管理マスターテーブル２９ｂにおいて対応付けられている所要消費リソースだけ、特定のリソースを、対象テナントに対する対象テナント別アプリケーションのリソースとして、プロビジョニングする（Ｓ１４２）。なお、プロビジョニングするリソースの種類と、種類毎の量とについては、テナント別アプリケーション毎に事前に定められている。

【0061】

サーバーリソース管理部２８は、Ｓ１４２の処理の後、図９に示す動作を終了する。

【0062】

次に、テナントに対する特定のテナント別アプリケーションに対してユーザーを新規に登録する場合のテナント管理システム２０の動作について説明する。

【0063】

図１０は、テナントに対する特定のテナント別アプリケーションに対してユーザーを新規に登録する場合のテナント管理システム２０の動作のフローチャートである。

【0064】

管理者は、特定のテナント（以下、図１０に示す動作の説明において「対象テナント」という。）に対する特定のテナント別アプリケーション（以下、図１０に示す動作の説明において「対象テナント別アプリケーション」という。）に対するユーザーの新規の登録を希望する場合に、対象テナントに対する対象テナント別アプリケーションに対するユーザーの新規の登録の開始の指示を管理者コンピューターを介してテナント管理部２７に送信することができる。テナント管理部２７は、対象テナントに対する対象テナント別アプリケーションに対するユーザーの新規の登録の開始の指示を受信すると、図１０に示す動作を開始する。

【0065】

図１０に示すように、テナント管理部２７は、特定の動作を実行することによって、対象テナントに対する対象テナント別アプリケーションに対して、管理者によって指定されたユーザーを管理テーブル２９ａに新規に登録する（Ｓ１６１）。ここで、テナント管理部２７は、新規のユーザーの住所、姓、名、メールアドレス、ユーザーＩＤおよびパスワードと、対象テナントのサブドメインと、対象テナント別アプリケーションのＡＰＩＤとの組み合わせを管理テーブル２９ａに登録する。

【0066】

サーバーリソース管理部２８は、Ｓ１６１の処理の後、対象テナントに対する対象テナント別アプリケーションに対して管理テーブル２９ａに登録されているユーザーの人数を取得する（Ｓ１６２）。

【0067】

次いで、サーバーリソース管理部２８は、対象テナント別アプリケーションのＡＰＩＤにＡＰＬ管理マスターテーブル２９ｂにおいて対応付けられている消費リソース単位を取得する（Ｓ１６３）。

【0068】

次いで、サーバーリソース管理部２８は、Ｓ１６３において取得した消費リソース単位に、Ｓ１６２において取得した人数を掛けた値が、対象テナントに対する対象テナント別アプリケーションの現在のリソースの量を超えたか否かを判断する（Ｓ１６４）。

【0069】

サーバーリソース管理部２８は、Ｓ１６３において取得した消費リソース単位に、Ｓ１６２において取得した人数を掛けた値が、対象テナントに対する対象テナント別アプリケーションの現在のリソースの量を超えたとＳ１６４において判断すると、特定のリソースを特定の量だけ、対象テナントに対する対象テナント別アプリケーションのリソースとして、追加でプロビジョニングする（Ｓ１６５）。なお、プロビジョニングするリソースの量については、例えば、Ｓ１６３において取得した消費リソース単位に、Ｓ１６２において取得した人数を掛けた値から、対象テナントに対する対象テナント別アプリケーションの現在のリソースの量を減じた量でも良い。また、プロビジョニングするリソースの種類と、種類毎の量とについては、テナント別アプリケーション毎に事前に定められても良い。

【0070】

サーバーリソース管理部２８は、Ｓ１６３において取得した消費リソース単位に、Ｓ１６２において取得した人数を掛けた値が、対象テナントに対する対象テナント別アプリケーションの現在のリソースの量を超えていないとＳ１６４において判断するか、Ｓ１６５の処理が終了すると、図１０に示す動作を終了する。

【0071】

次に、ユーザーによってテナント別アプリケーションが利用される場合のテナント管理システム２０の動作について説明する。

【0072】

図１１は、ユーザーによってテナント別アプリケーションが利用される場合のテナント管理システム２０の動作のシーケンス図である。

【0073】

ユーザーは、テナント別アプリケーションの利用を希望する場合に、テナント別アプリケーションの利用を、図示していないコンピューター（以下「クライアント」という。）に指示することができる。クライアントは、例えば、ＰＣなどのコンピューターによって実現されることが可能である。

【0074】

以下、サービス名、すなわち、ソリューション１２の名前は、「ｓｅｒｖｉｃｅ．ｃｏｍ」であることとする。外部アクセスポイント２１のドメイン名は、「ｃｌｏｕｄ．ａｐｐ」であることとする。ユーザーが利用を希望するテナント別アプリケーション（以下、図１１に示す動作の説明において「対象テナント別アプリケーション」という。）を実現するテナント（以下、図１１に示す動作の説明において「対象テナント」という。）のサブドメインは、「ａａｐ１」であることとする。

【0075】

クライアントは、テナント別アプリケーションの利用が指示されると、図１１に示すように、ＤＮＳサービス３０に対して、対象テナントのサーバー名をＦＱＤＮ、すなわち、「ａａｐ１．ｓｅｒｖｉｃｅ．ｃｏｍ」で問い合わせる（Ｓ１８１）。ここで、ＤＮＳサービス３０は、サーバー名として、外部アクセスポイント２１を含むワイルドカード、すなわち、「＊．ｃｌｏｕｄ．ａｐｐ」が登録されている。そして、ＤＮＳサービス３０は、サブドメインが例えば「○○」であるとすると、「○○．ｓｅｒｖｉｃｅ．ｃｏｍ」を含むクエリーに対して、「○○．ｃｌｏｕｄ．ａｐｐ」を応答する。したがって、ＤＮＳサービス３０は、「ａａｐ１．ｓｅｒｖｉｃｅ．ｃｏｍ」を含むクエリーに対して、「ａａｐ１．ｃｌｏｕｄ．ａｐｐ」を応答する。

【0076】

クライアントは、Ｓ１８１の処理の後、ＤＮＳサービス３０から対象テナントのサーバー名が応答されると、ＤＮＳサービス３０から応答されたサーバー名、すなわち、「ａａｐ１．ｃｌｏｕｄ．ａｐｐ」によって外部アクセスポイント２１に対して接続する（Ｓ１８２）。

【0077】

クライアントは、Ｓ１８２の処理の後、外部アクセスポイント２１と接続されると、ＨＴＴＰ／ＨＴＴＰＳ接続要求を外部アクセスポイント２１に送信する（Ｓ１８３）。

【0078】

外部アクセスポイント２１は、Ｓ１８３においてクライアントから送信されたＨＴＴＰ／ＨＴＴＰＳ接続要求を受信すると、受信したＨＴＴＰ／ＨＴＴＰＳ接続要求を外部ロードバランサー２２に転送する（Ｓ１８４）。

【0079】

外部ロードバランサー２２は、Ｓ１８４において外部アクセスポイント２１から転送されたＨＴＴＰ／ＨＴＴＰＳ接続要求を受信すると、クライアントとの間で、ＨＴＴＰ／ＨＴＴＰＳ接続を確立し、外部アクセスポイント２１から受信した接続要求を接続要求受け付け部２３に転送する（Ｓ１８５）。なお、外部ロードバランサー２２は、ＨＴＴＰＳ接続の場合にはＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）を終端する。

【0080】

接続要求受け付け部２３は、Ｓ１８５において外部ロードバランサー２２から転送された接続要求を受信すると、外部アクセスポイント２１から受信した要求をリクエスト処理部２４に転送する（Ｓ１８６）。

【0081】

リクエスト処理部２４は、Ｓ１８６において接続要求受け付け部２３から転送された要求を受信すると、接続要求受け付け部２３から受信した要求に含まれるユーザーＩＤおよびパスワードの組み合わせに基づいてクライアントとの間で認証要求を処理するとともに、接続要求受け付け部２３から受信した要求に含まれるサブドメインを取得し、アプリケーション管理部２５を呼び出す（Ｓ１８７）。ここで、接続要求受け付け部２３から受信した要求には、例えば、ＨＴＴＰ ＲＥＱＵＥＳＴヘッダーのＨＯＳＴにサブドメインが示されている。

【0082】

アプリケーション管理部２５は、Ｓ１８７においてリクエスト処理部２４から呼び出されると、リクエスト処理部２４によって取得されたサブドメインと、リクエスト処理部２４において認証が成功したユーザーのユーザーＩＤとに管理テーブル２９ａにおいて対応付けられているテナント別アプリケーションのうち、クライアントからの要求において指定されているテナント別アプリケーションを呼び出す（Ｓ１８８）。したがって、クライアントからの要求において指定されているテナント別アプリケーションは、クライアントからの要求に応じた動作を実行する。

【0083】

以上に説明したように、テナント管理システム２０は、ユーザーからテナントのサーバー名がＦＱＤＮで問い合わせられた場合（Ｓ１８１）に、このＦＱＤＮにおけるサブドメインによって特定されるテナントに対するテナント別アプリケーションを呼び出す（Ｓ１８８）ので、ユーザーによるテナントの指定を容易化することができる。

【0084】

テナント管理システム２０は、テナントを登録する場合に指定されたサブドメインが既に登録されているとき（Ｓ１２６でＹＥＳ）、テナントの登録（Ｓ１２８）を中止するので、テナントと、サブドメインとを適切に対応付けることができる。

【符号の説明】

【0085】

１１ パブリッククラウド
１２ ソリューション
１３ テナント
１４ ユーザー
２０ テナント管理システム
２５ アプリケーション管理部
２６ テナント別アプリケーション
２７ テナント管理部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】