JP2020123101A - クラスタリングシステムおよびクラスタリング方法 - Google Patents

Abstract

【課題】リソースを効率的に利用・運用可能であり、端末に提供する機能／サービスの要件を満たしたクラスタをＭＥＣサーバで構成可能なシステム及び方法を提供する。【解決手段】クラスタリングシステム１００は、ＭＥＣサーバ及びネットワークの利用状況を監視してテレメトリ情報として記憶部１２０に格納する監視部１１０と、機能／サービスの提供地域情報及び要件情報とＭＥＣサーバの配置情報等の非テレメトリ情報を取得して記憶部１２０に格納するクラスタ計画要請部１３０と、記憶部１２０の各情報に基づき提供地域及び要件を満たす１つ以上の拠点からなる仮想リージョンを設定し、当該仮想リージョンに属する拠点に配備された複数のＭＥＣサーバの中から機能／サービスを提供するためのクラスタ計画を算出するクラスタ計画部１４０と、クラスタ計画に基づきクラスタリング処理を行うクラスタ構築部１５０とを備えた。【選択図】図２

Description

本発明は、ＭＥＣサーバが配備されたネットワークにおいて、複数のＭＥＣサーバによる端末への機能／サービスの提供のためのクラスタを構成するクラスタリングシステム及び方法に関する。

ＭＥＣ（Multi-access Edge Computing）とは、従来は、端末を収容する移動通信網などのネットワーク（ＮＷ：Network）において端末に近い基地局などの「エッジ」にサーバを配置する仕組みを意味していた。しかし、端末の近くにサーバを配置するという技術的思想は移動通信網に限定されず固定通信網などのＮＷにおいても適用可能であり、また端末を収容するアクセス手段を複数種備えているＮＷにおいても適用可能である。また、「エッジ」という考え方も、クラウドサーバが配備されるインターネットを基準とすれば、ＮＷ内に配備されたサーバであれば端末に近いサーバと言える。そこで近年は、ＭＥＣは、移動通信網や固定通信網などアクセス手段の種類や数などを問わず、クラウドサーバと端末間のＮＷ、換言すればインターネットと端末間のＮＷにおいて配備されたサーバにより、各種サービスや機能を端末に提供する仕組みを意味する。非特許文献１には、５Ｇ（5th Generation）におけるＭＥＣについて記載されている。

このように、クラウドサーバと端末間のＮＷの端末近傍に情報を処理するサーバを配備するＭＥＣでは、物理的・地理的に分散配置されたＭＥＣサーバにより、従来クラウドサーバ側や端末側で実現していた種々の機能や処理の分散が可能である。これにより、低遅延性を要求するサービスや大容量の情報の集約と高速処理を要求するサービスなどの新たな領域のサービスへの対応が検討されている。

ＭＥＣサーバを含めたＮＷ構成は様々考えられるが、本願では、図１に示すように、インターネット２０上のクラウドサーバ２１と端末１との間に配備されたＭＥＣサーバが地域区分に応じた階層構造をとる環境を想定する。ここで、ＭＥＣサーバは、移動通信網や固定通信網など端末１を収容する事業者のＮＷ１０において、例えばデータセンタや基地局などの拠点に配備された物理サーバを意味する。各拠点には１つ又は複数のＭＥＣサーバが配備されている。なお、１つの拠点に複数のＭＥＣサーバが配備されることが多いので、図１では、各拠点に配備された複数のＭＥＣサーバをＭＥＣサーバ群１１と称するものとする。ＭＥＣサーバ群１１は地理的に異なる拠点に配備されており、各拠点間のネットワークトポロジーが地理的に階層構造を内包している。図１では、階層構造の例としてＭＥＣサーバ群１１が配備された拠点がツリー構造となっている例を示す。

一方、突発的な異常発生時にも機能／サービスの提供を中断させないための対応策としてはシステムの冗長化が挙げられる。サーバ等の障害対策である冗長化の方法の１つに、複数のサーバでのクラスタ構成が挙げられる（非特許文献２参照）。クラスタリングされたサーバにより機能／サービスを提供していれば、クラスタ内の現用系サーバに異常が発生した場合でも、予備系に切り替えて処理を引き継ぐことで機能／サービスの提供を継続できる。

そこで、端末１に提供する機能／サービスを提供するクラスタをＭＥＣサーバで構成（クラスタリング）することが検討されている。

"MEC in 5G networks", First edition, ETSI White Paper No. 28, ISBN No. 979-10-92620-22-1, European Telecommunications Standards Institute, June 2018, [online], [平成30年12月28日検索], インターネット<URL:https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf> "HAクラスターの教科書", 日本ヒューレット・パッカード, [online], [平成30年12月28日検索], インターネット<URL:httpth50146.www5.hpe.com/products/software/oe/hpux/developer/column/sg_text.pdf >

しかし、ＭＥＣサーバは物理的・地理的に分散配置されているため、全ての配置位置に豊富なリソースがあるわけではなく、ＭＥＣサーバ群やそれらに接続するＮＷの運用者側は、機能／サービスの要件を満足させつつ制限のあるリソースを効率的に利用する必要がある。機能／サービスは要件を満足するＭＥＣサーバにより提供できれば良い一方で、ＭＥＣサーバ群やＮＷのリソース配置／利用状況、保守運用も含めたコストを考慮すると、運用者側から見た機能／サービスのクラスタを組むべきＭＥＣサーバは状況により変動する。

一方、例えば、ＡＷＳ（Amazon Web Service）などの既存のエッジ／クラウドサービスでは、機能／サービス利用時にクラスタリングされるサーバの地域区分、リージョンを指定する方法を取っているが、同様の方法をＭＥＣに適用することは困難である。すなわち、ＭＥＣサーバにより提供されるそれぞれの機能／サービスが独立にリージョンを指定する方法では、物理的・地理的に分散配置されたＭＥＣサーバ群１１それぞれに潤沢なリソースがない限り、需要と供給の関係性によってはリソース不足により機能／サービスの利用ができなくなる可能性が高まる。つまり、階層構造をとるＭＥＣサーバ群１１のようなＭＥＣサーバ群１１毎に性質が異なり、かつ物理的に制限のあるリソースを効率的に利用、また運用することができない。

本発明は上記事情に鑑みてなされたものであり、その目的とするところは、リソースを効率的に利用・運用可能であり、端末に提供する機能／サービスの要件を満たしたクラスタをＭＥＣサーバで構成可能なシステム及び方法を提供することにある。

上記目的を達成するために、本願発明は、地理的に異なる複数の拠点のそれぞれにＭＥＣサーバが配備されるとともに拠点間のネットワークトポロジーが階層構造を内包し且つ端末が収容されたネットワークにおいて、複数のＭＥＣサーバによる端末への機能／サービスの提供のためのクラスタを構成するクラスタリングシステムであって、ＭＥＣサーバ及びネットワークの利用状況を監視するとともに当該監視により取得した状況情報を少なくとも含むテレメトリ情報を記憶部に格納する監視部と、機能／サービスの提供地域情報及び要件情報とＭＥＣサーバの配置情報とを少なくとも含む非テレメトリ情報を取得して前記記憶部に格納するとともに、前記非テレメトリ情報に基づきクラスタ計画要請を生成するクラスタ計画要請部と、前記クラスタ計画要請に応じて、前記記憶部のテレメトリ情報及び非テレメトリ情報に基づき機能／サービスを提供地域及び要件を満たす１つ以上の拠点からなる仮想リージョンを設定し、設定した仮想リージョンに属する拠点に配備された複数のＭＥＣサーバの中から機能／サービスを提供するためのクラスタ計画を算出するクラスタ計画部と、前記クラスタ計画に基づきクラスタリング処理を行うクラスタ構築部とを備えたことを特徴とする.

本発明によれば、端末に提供する機能／サービスの要件を満たしつつ、階層構造をとるＭＥＣサーバ群のようなＭＥＣサーバ群毎に性質が異なり、かつ物理的に制限のあるリソースを効率的に利用、また運用することができる。また、運用者側を考慮した仮想リージョンの設定により、機能／サービスは利用時にクラスタリングされるＭＥＣサーバの地域区分、リージョン等を具体的に指定することなく、提供地域と要件を提示するのみで、要件を満足した状態で利用・提供できる環境が実現可能となる。さらに、地域特性に関する情報やＭＥＣサーバ群・ＮＷの利用状況、クラスタ計画結果の蓄積は、その時点でのリソース活用（クラスタ構成）だけではなく、将来的なリソース計画（ＭＥＣサーバ群のスケールアップ／スケールアウト、新たな場所に配置）にも反映できる。

本発明の前提となる環境例の概略構成図 本発明に係るクラスタリングシステムの機能ブロック図 本発明に係るクラスタリングのシーケンスチャート、 本発明に係るクラスタ計画部のフローチャート 実施例１に係るクラスタリングシステムの機能ブロック図 実施例１に係るクラスタリングのシーケンスチャート 実施例１に係るクラスタ計画部のフローチャート 実施例２に係るクラスタ計画部のフローチャート

まず、本願発明の概念について説明する。なお、本願発明では、前述したように図１に示すようなＮＷ１０内のＭＥＣサーバ群１１が地域区分に応じたツリー構造をとる環境を想定する。なお、図１のインターネットやクラウドサーバは本願発明の構成要素に含まれない点に留意されたい。

また、本願発明では、ＮＷ１０の運用及びＭＥＣサーバ群１１によるクラスタ環境を提供する者と、当該クラスタ環境を利用して機能／サービスを提供する者と、前記機能／サービスの提供を受ける者（端末１のユーザ）とが登場する、いわゆるＢｔｏＢｔｏＸというビジネスモデルを想定している。本願では、説明の便宜上、ＮＷ１０の運用及びＭＥＣサーバ群１１によるクラスタ環境を提供する者を「運用者」、当該クラスタ環境を利用して機能／サービスを提供する者を「機能／サービス提供者」と呼ぶものとする。なお、運用者と機能／サービス提供者とは必ずしも異なる者である必要はない点に留意されたい。

本願発明に係るシステムは、端末１に対して提供する機能／サービスの要件に加えて、ＭＥＣサーバ群１１やＮＷ１０のリソース配置／利用状況、保守運用も含めたコストを考慮し、端末１に対して提供する機能／サービスのクラスタをＭＥＣサーバで構成（クラスタリング）、必要に応じて更新するシステムである。

ここで、ＭＥＣサーバ群１１やＮＷ１０のリソース配置／利用状況、保守運用も含めたコストに応じて、特定の機能／サービスのクラスタ構成に組み込むべきＭＥＣサーバ群１１、リージョンは変動するため、本願発明では、満足させられる機能／サービス要件とＭＥＣサーバ群１１やＮＷのリソース配置／利用状況、保守運用も含めたコストから設定される「仮想リージョン（ｖＲ：virtual Region）」を定義する。

ＭＥＣサーバを利用する機能／サービスは提供範囲（提供地域）と満足すべき要件を提示し、その提示を受けた運用者側が仮想リージョンｖＲに属するＭＥＣサーバ群１１から機能／サービスを提供するクラスタを構成（クラスタリング）する。要件には確保すべきリソース（ＧＰＵ（Graphics Processing Unit）の要否や確保すべきＣＰＵ（Central Processing Unit）、ＮＷ帯域など）や担保すべき条件（冗長化の程度や遅延時間）が想定される。

また、仮想リージョンｖＲを定義、運用するためにはＭＥＣサーバ群１１間を接続するＮＷ１０のトポロジーをＵプレーン／Ｃプレーン／Ｍプレーンそれぞれで考慮する必要があるが、ここでは前述した図１に示すような階層構造（ツリー構造）の環境を想定する。なお、当然、ＭＥＣ特有の機能／サービス特性やコストを含む運用者側の要件にしたがって、階層構造を内包するのであれば、メッシュ構造などの異なるＮＷトポロジーを想定してもよいし、ネットワークの機能も仮想化した上で必要に応じてＮＷトポロジーを変化させる環境を想定しても構わない。

次に、本発明に係るクラスタリングシステムについて図２〜図４を参照して説明する。図２は本発明に係るクラスタリングシステムの機能ブロック図、図３はクラスタリングのシーケンスチャート、図４はクラスタ計画部（後述する）のフローチャートである。

図２に示すように、クラスタリングシステム１００は、監視部１１０と、記憶部１２０と、クラスタ計画要請部１３０と、クラスタ計画部１４０と、クラスタ構築部１５０とを備えている。クラスタリングシステム１００の実装形態は不問である。例えば、クラスタリングシステム１００の各部を専用装置として実装してもよいし、汎用装置や仮想化環境にプログラムをインストールして実装してもよいし、ＮＷ１０を構成する各種装置にプログラムをインストールして実装してもよい。また、クラスタリングシステム１００を１つの装置・仮想化環境に集中して実装してもよいし、複数の装置・仮想化環境に分散して実装してもよい。

以下、本発明に係るクラスタリングシステム１００の各部の機能・動作の詳細について図２〜図４を参照して説明する。

記憶部１２０は、後述するように監視部１１０及びクラスタ計画要請部１３０からの各種情報を記憶する。記憶部１２０に記憶される情報としては、監視部１１０によって取得されたテレメトリ情報と、クラスタ計画要請部１３０で取得した非テレメトリ情報に大別される。テレメトリ情報及び非テレメトリ情報の詳細について後述する。

監視部１１０は、各拠点に配置されたＭＥＣサーバ群１１を構成するＭＥＣサーバおよびＮＷ１０の利用状況を監視し、取得した利用状況情報をテレメトリ情報として記憶部１２０に格納する（図３のステップＳ１１〜Ｓ１３）。各ＭＥＣサーバからの情報取得方法や、ＮＷ１０からの情報取得方法については、従来周知の種々の方法を用いることができる。

クラスタリング済みの機能／サービスや今後クラスタリングする必要のある機能／サービスの提供地域及び要件、ＭＥＣサーバの配置位置／量に関する非テレメトリ情報は、ＧＵＩ（Graphical User Interface）やＣＵＩ（Character User Interface）等の情報取得用インタフェースである非テレメトリ情報取得ＩＦ２００を介してクラスタ計画要請部１３０に送信される（図３のステップＳ１４）。送信される非テレメトリ情報としては、地域特性に関する情報、例えば時期／時間ごとの機能／サービス提供状況、地域別人口変動統計や在圏ｏｒ接続端末数変動統計などを含んでも構わない。また、送信される非テレメトリ情報は、非テレメトリ情報取得ＩＦ２００を介して、運用者により入力されてもよいし、機能／サービス提供者により入力されてもよいし、両者により入力されてもよい。

クラスタ計画要請部１３０は、取得した情報を記憶部１２０に格納する（図３のステップＳ１５）と同時に、クラスタリングする必要のある機能／サービスの新規発生やクラスタリング済みの機能／サービスの要件変更、ＭＥＣサーバの配置位置／量の変化を契機に、クラスタ計画部１４０にクラスタ計画要請を送信する（図３のステップＳ１６）。

次に、図４のフローチャートに従って、クラスタ計画要請に対してクラスタ計画部１４０がクラスタ計画の立案処理を行う。当該立案処理の主要な流れは、（ａ）仮想リージョンｖＲを設定し、（ｂ）仮想リージョンｖＲに含まれる拠点のＭＥＣサーバ群１１を用いた１つ以上のクラスタ計画案を立案し、（ｃ）各クラスタ計画案に対して後述するクラスタ構成適切度Ｆを算出し、（ｄ）算出したクラスタ構成適切度Ｆに基づき適切なクラスタ計画を選択する、というものである。以下、クラスと計画部１４０の処理について詳述する。

クラスタ計画部１４０は、クラスタ計画要請部１３０からクラスタ計画要請を受信すると（図４のステップＳ１０１）、記憶部１２０に格納されている情報を参照し（図４のステップＳ１０２，図３のステップＳ１７）、機能／サービスに追加ｏｒ変更があったかを確認する（図４のステップＳ１０３）。追加ｏｒ変更があった場合は、記憶部１２０の情報を参照して仮想リージョンｖＲを設定し、仮想リージョンｖＲに属するＭＥＣサーバを用いて追加ｏｒ変更のあった機能／サービスのみのクラスタ構成を新たに計画し、その計画をＭＥＣサーバ群に適用した時のクラスタ構成適切度Ｆ_１を算出する（図４のステップＳ１０４）。

クラスタ構成適切度Ｆ_１が所定の既定値Ｆ_th１以上の場合は、クラスタ計画結果をクラスタ構築部１５０とクラスタ計画要請部１３０に送信し（図４のステップＳ１０５〜Ｓ１０６，図３のステップＳ１８，Ｓ１９）、クラスタ構築部１５０がクラスタ計画結果に基づいてクラスタリングする（図３のステップＳ２０）。クラスタ計画要請部１３０は、受信したクラスタ計画を記憶部１２０に格納する（図３のステップＳ２１）。

ここで、クラスタ構成適切度Ｆは保守運用コストも考慮したＭＥＣサーバ群１１とＮＷ１０の利用状況から算出される運用者側にとってのクラスタ構成の適切度合いであり、クラスタ構成適切度Ｆが高い程、運用者側にとってリソースを効率的に利用できている状態を表す。算出には単なるＭＥＣサーバ群１１とＮＷ１０の利用状況だけではなく、ＭＥＣサーバの配置位置や耐用年数、定期保守までの時間間隔などにより算出される保守運用に関するコストも考慮することができる。クラスタ構成適切度Ｆの算出式や計算に含める要素、係数などについては、運用者側の要件に応じて任意に設定可能である。既定値Ｆ_th１は運用者側が理想とするリソースの効率的な利用を実現できるクラスタ構成適切度Ｆの下限値であり、これも各種外部要件に応じて任意に設定することができる。

一方、クラスタ構成適切度Ｆ_１が既定値Ｆ_th１より小さい場合は、運用者側が許容できるリソースの効率的な利用の所定の下限値Ｆ_th２とクラスタ構成適切度Ｆ_１とを比較する（図４のステップＳ１０５，Ｓ１０７）。クラスタ構成適切度Ｆ_１が下限値Ｆ_th２以上の場合は、クラスタ計画結果をクラスタ構築部１５０とクラスタ計画要請部１３０に送信する（図４のステップＳ１０７〜Ｓ１０８，図３のステップＳ１８，Ｓ１９）。次に、再度、記憶部１２０の情報を参照して、追加ｏｒ変更がなかった機能／サービスも含めて、すなわち今回のクラスタ計画要請以外の既存のクラスタに係る機能／サービスも含めて、仮想リージョンｖＲをそれぞれ設定し、クラスタ構成適切度Ｆ_２が最大となるクラスタ構成を計画する（図４のステップＳ１０９）。一方、クラスタ構成適切度Ｆ_１が下限値Ｆ_th２より小さい場合はクラスタリング不可のため、前述の図４のステップＳ１０９に処理を移す（図４のステップＳ１０７）。

クラスタ構成適切度Ｆ_２が下限値Ｆ_th２以上の場合は、クラスタ計画結果をクラスタ構築部１５０とクラスタ計画要請部１３０に送信し（図４のステップＳ１１０，Ｓ１０６，図３のステップＳ１８，Ｓ１９）、クラスタ構築部１５０が計画に基づいて（改めて）クラスタリングする（図３のステップＳ２０）。クラスタ計画要請部１３０は、受信したクラスタ計画を記憶部１２０に格納する（図３のステップＳ２１）。一方、クラスタ構成適切度Ｆ_２が下限値Ｆ_th２より小さい場合はクラスタリング不可のため、クラスタ計画結果をクラスタ計画要請部１３０に送信し、クラスタリングは実行しない（図４のステップＳ１１０，Ｓ１１１）。

クラスタリング不可の場合は機能／サービス提供が不可のため、運用者側がリソースの増強などの保守運用により対処する。対処後のリソース状況は非テレメトリ情報取得ＩＦ２００を通じて記憶部１２０に格納されるため、再度クラスタ計画要請部１３０がクラスタ計画部１４０にクラスタ計画要請を送信することになり、結果的に提供したい機能／サービスのクラスタリングが可能となる。

前述した図４のステップＳ１０３において、機能／サービスに追加ｏｒ変更がなかった場合は、再度、記憶部１２０の情報を参照して、追加ｏｒ変更がなかった機能／サービスも含めて、すなわち今回のクラスタ計画要請以外の既存のクラスタに係る機能／サービスも含めて、仮想リージョンｖＲを設定し、クラスタ構成適切度Ｆ_２が最大となるクラスタ構成を計画する（図４のステップＳ１０９）。クラスタ構成適切度Ｆ_２が下限値Ｆ_th２以上の場合は、クラスタ計画結果をクラスタ構築部１５０とクラスタ計画要請部１３０に送信し（図４のステップＳ１１０，Ｓ１０６，図３のステップＳ１８，Ｓ１９）、クラスタ構築部１５０が計画に基づいて（改めて）クラスタリングする（図３のステップＳ２０）。クラスタ計画要請部１３０は、受信したクラスタ計画を記憶部１２０に格納する（図３のステップＳ２１）。一方、クラスタ構成適切度Ｆ_２が下限値Ｆ_th２より小さい場合はクラスタリング不可のため、クラスタ計画結果をクラスタ計画要請部１３０に送信し、クラスタリングは実行しない（図４のステップＳ１１０，Ｓ１１１）。

なお、クラスタ構築処理は、クラスタ計画に基づき、クラスタ構築部１５０が従来周知の各種方法に基づき自動的に実施してもよいし、その処理の一部を運用者の人手によって実施してもよい。

クラスタ計画要請の発出条件や頻度、クラスタ構成適切度Ｆの算出式や形式、既定値Ｆ_th１や下限値Ｆ_th２として設定する閾値の種類や程度、クラスタ構成適切度Ｆの最大値を計算するために考慮するクラスタ構成計画の数的規模や範囲などは、必要に応じて別途規定することができる。

このようなクラスタリングシステム１００によれば、端末１に提供する機能／サービスの要件を満たしつつ、階層構造をとるＭＥＣサーバ群１１のようなＭＥＣサーバ群１１毎に性質が異なり、かつ物理的に制限のあるリソースを効率的に利用、また運用することができる。

また、運用者側を考慮した仮想リージョンｖＲの設定により、機能／サービス提供者はクラスタリングされるＭＥＣサーバの地域区分、リージョンを具体的に指定することなく、提供範囲と要件を提示するのみで、要件を満足した状態で利用・提供できる環境が実現可能となる。

さらに、地域特性に関する情報やＭＥＣサーバ群１１・ＮＷ１０の利用状況、クラスタ計画結果の蓄積は、その時点でのリソース活用（クラスタ構成）だけではなく、将来的なリソース計画（ＭＥＣサーバ群１１のスケールアップ／スケールアウト、新たな場所に配置）にも反映できる。

次に、本発明の実施例１について図５〜図７を参照して説明する。本実施例１では図１に示す環境において、サービスＡ（提供範囲：地域Ａ−１−α、確保すべきＣＰＵ使用率：２００％、冗長度：２重、遅延時間：１５ｍｓ）のクラスタを構成する例を示す。

ここで、地域Ａ−１−０に配置されているＣＰＵは合計で１６００％、地域Ａ−１−αに配置されているＣＰＵは合計で８００％とする。地域Ａ−１−αでサービスＡを提供する際に利用するＮＷ帯域は１０Ｇｂｐｓ、地域Ａ−１−０でサービスＡを提供する際に利用するＮＷ帯域は、地域Ａ−１−０と地域Ａ−１−α間のＮＷ帯域を含めて２０Ｇｂｐｓとし、保守運用コストは各地域のＭＥＣサーバ群で一律とする。また既定値Ｆ_th１は１８０に設定する。

本実施例１のクラスタ構成適切度Ｆは、下記数１に示す計算式により算出されるとする。なお、下記計算式は一例であり、前述したように、クラスタ構成適切度Ｆの算出式や計算に含める要素、係数などについては任意に設定できる点に留意されたい。

Ｆ：クラスタ構成の適切度（ａｒｂ．ｕｎｉｔ）
ｘ_ｉ：クラスタ構成時の地域ｉにおけるＣＰＵ使用率の百分率（％）（１００％を最大値として正規化）
ｙ：クラスタ構成時のＮＷ帯域利用量の期待値（Ｇｂｐｓ）
ｎ_ｈ，ｉ：地域ｉでサービスｈ提供に必要なＮＷ帯域量（Ｇｂｐｓ）
Ｃ_ｈ：サービスｈ提供に必要なＣＰＵ使用率（％）
Ｃ_ｈ，ｉ：地域ｉにおけるサービスｈでのＣＰＵ使用率（％）

本実施例１に係るクラスタリングシステムの機能ブロック図を図５、クラスタリングのシーケンスチャートを図６に示す。また、クラスタ計画部のフローチャートを図７に示す。図５〜図７において前述の図２〜図４と同様の要素については同一の符号を付して説明を省略する。

サービスＡを提供する必要性の発生を契機として、クラスタ計画要請部１３０はクラスタ計画部１４０にクラスタ計画要請を送信する（図６のステップＳ１７）。クラスタ計画部１４０は、クラスタ計画要請部１３０からクラスタ計画要請を受信すると（図７のステップＳ２０１）、記憶部１２０に格納されているサービスＡの提供範囲、確保すべきＣＰＵ使用率、冗長度、遅延時間、ＭＥＣサーバ配置位置／量を参照し、仮想リージョンｖＲ（本実施例では地域Ａ−１−０及びＡ−１−αからなるリージョン）を設定、サービスＡのクラスタ構成を計画し、計画適用時のクラスタ構成適切度Ｆの最大値Ｆ_１を算出する（図７のステップＳ２０２）。ここでは例として、クラスタ構成案として考えられる以下の３案についてクラスタ構成適切度Ｆを計算する。

・案１：地域Ａ−１−０にてＣＰＵを４００％確保する。Ｆ＝１８５。
・案２：地域Ａ−１−０にてＣＰＵを２００％、地域Ａ−１−αにてＣＰＵを２００ ％確保する。Ｆ＝１８９。
・案３：地域Ａ−１−αにてＣＰＵを４００ ％確保する。Ｆ＝２１０。

クラスタ構成適切度Ｆの最大値Ｆ_１＝２１０＞既定値Ｆ_th１となるため、クラスタ計画部１４０は案３をクラスタ構築部１５０とクラスタ計画要請部１３０に送信し（図７のステップＳ２０３〜Ｓ２０４）、クラスタ構築部１５０が案３に基づいてクラスタリングする（図６のステップＳ２０）。クラスタ計画要請部１３０は案３を記憶部に格納する（図６のステップＳ２１）。

以上により、サービスＡの要件を満たしつつ、階層構造をとるＭＥＣサーバ群１１のようなＭＥＣサーバ群１１毎に性質が異なり、かつ物理的に制限のあるリソースを効率的に利用、運用することができる。

また、運用者側を考慮した仮想リージョンｖＲの設定により、サービスＡ利用時にクラスタリングされるサーバの地域区分、リージョンを具体的に指定することなく、要件を満足した状態でのサービスＡ提供が可能となる。

さらに、案３に従ったサービスＡの提供は、地域Ａ−１−αのリソース需要が今後も存在することを意味するため、地域Ａ−１−αのリソース増強計画に反映できる。

次に、本発明の実施例２について図８を参照して説明する。本実施例２は、前記実施例１において、サービスＡが提供されている環境にサービスＢ（提供範囲：地域Ａ−１−α、確保すべきＣＰＵ使用率：２００％、冗長度：２重、遅延時間：８ｍｓ）のクラスタを構成、必要に応じてＭＥＣサーバ群に適用されているクラスタ構成を更新する例を示す。

ここで、地域Ａ−１−αでサービスＢを提供する際に利用するＮＷ帯域は３０Ｇｂｐｓとする。また、既定値Ｆ_th１は１８０、下限値Ｆ_th２は８０に設定する。

本実施例２に係るクラスタ計画部のフローチャートを図８に示す。

サービスＢを提供する必要性の発生を契機として、クラスタ計画要請部１３０はクラスタ計画部１４０にクラスタ計画要請を送信する。クラスタ計画部１４０は、クラスタ計画部１４０は、クラスタ計画要請部１３０からクラスタ計画要請を受信すると（図８のステップＳ３０１）、記憶部１２０に格納されているサービスＢの提供範囲、確保すべきＣＰＵ使用率、冗長度、遅延時間、ＭＥＣサーバ配置位置／量を参照し、仮想リージョンｖＲ（本実施例では地域Ａ−１−α）を設定、サービスＢのクラスタ構成を計画し、計画適用時のクラスタ構成適切度Ｆの最大値Ｆ_１を算出する（図８のステップＳ３０２〜Ｓ３０４）。

ここで、算出したクラスタ構成適切度Ｆの最大値Ｆ_１＜下限値Ｆ_th２である、すなわち「解なし」であったとする（図８のステップＳ３０５，Ｓ３０７）。これは、地域Ａ−１−αのＣＰＵ使用率が上限を超えるためであり、サービスＢのみの考慮ではクラスタリング不可であることを意味する。そこで、クラスタ計画部１４０は記憶部１２０に格納されている情報を参照し、サービスＡについてもクラスタ構成を再考する。すなわち、サービスＡとサービスＢについてそれぞれ仮想リージョンｖＲを設定し（本実施例では地域Ａ−１−０及びＡ−１−αからなるリージョン）、仮想リージョンｖＲに属するＭＥＣサーバ群１１のクラスタ構成を計画、計画適用時のクラスタ構成適切度Ｆの最大値Ｆ_２を算出する（図８のステップＳ３０９）。ここでは例として、クラスタ構成案として考えられる以下の３案についてクラスタ構成適切度Ｆを計算する。

クラスタ構成適切度Ｆの最大値Ｆ_２＝１０５＞下限値Ｆ_th２となるため、クラスタ計画部１４０は案３をクラスタ構築部１５０とクラスタ計画要請部１３０に送信し（図８のステップＳ３１０，Ｓ０３〜Ｓ３０６）、クラスタ構築部１５０が案３に基づいてクラスタリングする。クラスタ計画要請部１３０は案３を記憶部に格納する。

以上により、サービスＡとＢの両方との要件を満たしつつ、階層構造をとるＭＥＣサーバ群１１のようなＭＥＣサーバ群１１毎に性質が異なり、かつ物理的に制限のあるリソースを効率的に利用、運用することができる。

さらに、運用者側を考慮した仮想リージョンｖＲの設定により、サービスＡとＢの利用時にクラスタリングされるサーバの地域区分、リージョンを具体的に指定することなく、要件を満足した状態でのサービスＡとＢの提供が可能となる。

さらに、案３に従ったサービスＡとＢの提供は、地域Ａ−１−０と地域Ａ−１−α、特に地域Ａ−１−αのリソース需要が今後も存在することを意味するため、地域Ａ−１−０と地域Ａ−１−α、特に地域Ａ−１−αのリソース増強計画に反映できる。

次に、本発明の実施例３について説明する。本実施例３は、前記実施例１のようにクラスタ構成適切度Ｆの算出時にクラスタ構成時のＭＥＣサーバのＣＰＵ使用率やＮＷ利用帯域を考慮するだけではなく、さらに、ＭＥＣサーバ群１１の保守運用コストも考慮する例を示す。

本実施例３におけるクラスタ構成適切度Ｆの算出式を下記数２に示す。

Ｆ：クラスタ構成の適切度（ａｒｂ．ｕｎｉｔ）
ｘ_ｉ：クラスタ構成時の地域ｉにおけるＣＰＵ使用率の百分率（％）（１００％を最大値として正規化）
ｙ：クラスタ構成時のＮＷ帯域利用量の期待値（Ｇｂｐｓ）
ｎ_ｈ，ｉ：地域ｉでサービスｈ提供に必要なＮＷ帯域量（Ｇｂｐｓ）
Ｃ_ｈ：サービスｈ提供に必要なＣＰＵ使用率（％）
Ｃ_ｈ，ｉ：地域ｉにおけるサービスｈでのＣＰＵ使用率（％）
ｚ：保守運用コスト（ａｒｂ．ｕｎｉｔ）
ａ：利用しているＭＥＣサーバ群の中で保守拠点から最も遠いＭＥＣサーバ群と保守拠点間の物理的な距離（ｋｍ）
ｂ：利用しているＭＥＣサーバ群の中で次回の定期保守が最も先の日程となるＭＥＣサーバ群の次回の定期保守までの日数（日）

本実施例３では、保守運用コストとして、利用しているＭＥＣサーバ群１１の中で保守拠点から最も遠いＭＥＣサーバ群１１と保守拠点間の物理的な距離ａ（ｋｍ）、利用しているＭＥＣサーバ群１１の中で次回の定期保守が最も先の日程となるＭＥＣサーバ群１１の次回の定期保守までの日数ｂ（日）を考慮している。これらの他に、ＭＥＣサーバの耐用年数やリソース逼迫度、保守拠点ごとの従業員数、道路の整備状況や気象条件など、リソースの増強を含めた保守運用に関わるコストを算出式に反映することもできる。保守運用に関わるコストとして含める要素や係数なども任意に設定できる。

前記距離ａは定期的な保守やリソース増強作業以外に、臨時的に発生する緊急的な保守あるいはリソース増強作業発生時のコスト増大分、前記日数ｂは次回定期保守までの間に臨時的な保守が発生する可能性を保守運用コストに反映するために考慮している。

ここで、図１のＮＷ構成において、保守拠点からＭＥＣサーバ群地域Ａ−１−０および地域Ａ−１−αまでの物理的な距離をそれぞれ５ｋｍと５０ｋｍ、次回の定期保守までの日数をＭＥＣサーバ群地域Ａ−１−０および地域Ａ−１−αそれぞれ１０日と２０日と仮定し、実施例１の案１、２、３について、上記数２に示す算出式でクラスタ構成適切度Ｆを計算すると、クラスタ構成適切度Ｆはそれぞれ２５２、２０３、２２４となり、サービスＡは案１に従ってクラスタリングされることになる。

以上により、サービスＡの要件を満たしつつ、階層構造をとるＭＥＣサーバ群１１のようなＭＥＣサーバ群１１毎に性質が異なり、かつ物理的に制限のあるリソースについて、保守運用コストを考慮した上で効率的に利用することができる。

次に、本発明の実施例４について説明する。前記第１〜３の実施例では、新たな機能／サービスの提供を契機として当該機能／サービスの提供範囲と遅延時間等の要件とに合わせて仮想リージョンｖＲを作成していた。一方、本実施例４では、充足できる要件としての遅延時間要件とＭＥＣサーバ群１１やＮＷ１０といったリソースの状況から、予め複数の仮想リージョンｖＲを設定しておく例を示す。

クラスタリングシステム１００の記憶部１２０にはリソースの情報として、ＭＥＣサーバの配置位置と配置量、ＮＷ１０のトポロジーと帯域、ＭＥＣサーバとそのＭＥＣサーバによって機能／サービスが提供される範囲に存在する端末１との間の遅延時間が格納されている。一方、端末１に提供する機能／サービスの情報として、提供する範囲と要件、クラスタ計画部１４０によって作成、クラスタ構築部１５０によって構築されたクラスタ構築状況が格納されている。これらの情報は非テレメトリ情報取得ＩＦを介して格納時と変化が生じた際に更新する形でも、定期的に更新する形でもよい。また、現在のＭＥＣサーバとＮＷ１０の利用状況および提供する機能／サービスの提供状況についても随時格納される。

クラスタ計画部１４０は記憶部１２０に格納されている情報を参照し、提供範囲と遅延時間要件毎にその時々の状況で随時変化する仮想リージョンｖＲを作成、定期的に更新する。前記実施例１では、サービスＡの提供を契機としてサービスＡの提供範囲と遅延時間の要件に合わせて仮想リージョンｖＲを作成する例を示しているが、本実施例４のようにあらかじめ機能／サービスの提供範囲と遅延時間要件毎に仮想リージョンｖＲを作成しておき、機能／サービス利用時に既定の仮想リージョンｖＲからなるリージョンのオプションを選択する形で、クラスタ計画要請部１３０にクラスタ計画要請を発出させても構わない。

さらに、非テレメトリ情報取得ＩＦを介して他のエッジ／クラウド事業者のリソース情報を記憶部１２０に格納し、当該システムを利用する事業者が把握できる範囲の情報を利用して、他のエッジ／クラウドサーバを含めた仮想リージョンｖＲを作成、定期的に更新する形でも構わない。

仮想リージョンｖＲを設定するために必要な情報は、一般的なネットワークの管理機能や機能／サービスの管理機能を介して収集し、機能／サービスを提供するための一般的なオーケストレーション機能に対して仮想リージョンｖＲの設定機構を含む本発明のシステムを組み込むことで実装する。また、機能／サービスを利用するための一般的なウェブなどのインタフェースに対して、機能／サービスの提供範囲と要件を入力、あるいは既定の仮想リージョンｖＲからなるリージョンのオプションを選択できるインタフェースを追加し、仮想リージョンｖＲの設定機構を含む本発明のシステムを組み込んだ上記オーケストレーション機能と連携させることで、仮想リージョンｖＲに基づいたクラスタ計画および構築機能を実装する。

以上本発明の実施の形態について詳述したが本発明はこれに限定されるものではない。例えば、上記実施の形態では示したテレメトリ情報や非テレメトリ情報の具体的な情報は一例であり、他の情報を用いることもできる。

１…端末
１０…ネットワーク
１１…ＭＥＣサーバ群
１００…クラスタリングシステム
１１０…監視部
１２０…記憶部
１３０…クラスタ計画要請部
１４０…クラスタ計画部
１５０…クラスタ構築部

Claims (7)

1. 地理的に異なる複数の拠点のそれぞれにＭＥＣサーバが配備されるとともに拠点間のネットワークトポロジーが階層構造を内包し且つ端末が収容されたネットワークにおいて、複数のＭＥＣサーバによる端末への機能／サービスの提供のためのクラスタを構成するクラスタリングシステムであって、
   ＭＥＣサーバ及びネットワークの利用状況を監視するとともに当該監視により取得した状況情報を少なくとも含むテレメトリ情報を記憶部に格納する監視部と、
   機能／サービスの提供地域情報及び要件情報とＭＥＣサーバの配置情報とを少なくとも含む非テレメトリ情報を取得して前記記憶部に格納するとともに、前記非テレメトリ情報に基づきクラスタ計画要請を生成するクラスタ計画要請部と、
   前記クラスタ計画要請に応じて、前記記憶部のテレメトリ情報及び非テレメトリ情報に基づき機能／サービスの提供地域及び要件を満たす１つ以上の拠点からなる仮想リージョンを設定し、設定した仮想リージョンに属する拠点に配備された複数のＭＥＣサーバの中から機能／サービスを提供するためのクラスタ計画を算出するクラスタ計画部と、
   前記クラスタ計画に基づきクラスタリング処理を行うクラスタ構築部とを備えた
   ことを特徴とするクラスタリングシステム。
2. 前記クラスタ計画部は、機能／サービスの提供地域及び要件を満たすクラスタのクラスタ計画を算出できない場合、当該機能／サービスの他に提供中の他の機能／サービスを含めてクラスタ計画を算出する
   ことを特徴とする請求項１記載のクラスタリングシステム。
3. 前記非テレメトリ情報は保守運用コスト情報を含む
   ことを特徴とする請求項１又は２記載のクラスタリングシステム。
4. 前記クラスタ計画部は、予め複数の仮想リージョンを予め設定しておき、前記複数の仮想リージョンの何れかを選択するためのインタフェースにより選択された仮想リージョンを用いてクラスタ計画を算出する
   ことを特徴とする請求項１乃至３何れか１項記載のクラスタリングシステム。
5. 機能／サービスの提供するためのオーケストレーション機能に対して、前記監視部、前記クラスタ計画要請部、前記クラスタ計画部、前記クラスタ構築部を実装した
   ことを特徴とする請求項１乃至４何れか１項記載のクラスタリングシステム。
6. 前記クラスタ計画部は、設定した仮想リージョンに属する拠点に配備された複数のＭＥＣサーバの中から機能／サービスを提供するための複数のクラスタ計画案を算出するとともに、各クラスタ計画案に対してクラスタ構成適切度を算出し、算出したクラスタ構成適切度に基づきクラスタ計画案の１つを選択し、選択したクラスタ計画案をクタスタ計画として採用する
   ことを特徴とする請求項１乃至５何れか１項記載のクラスタリングシステム。
7. 地理的に異なる複数の拠点のそれぞれにＭＥＣサーバが配備されるとともに拠点間のネットワークトポロジーが階層構造を内包し且つ端末が収容されたネットワークにおいて、複数のＭＥＣサーバによる端末への機能／サービスの提供のためのクラスタを、クラスタリングシステムにより構成するクラスタリング方法であって、
   クラスタリングシステムの監視部が、ＭＥＣサーバ及びネットワークの利用状況を監視するとともに当該監視により取得した状況情報を少なくとも含むテレメトリ情報を記憶部に格納する第１のステップと、
   クラスタリングシステムのクラスタ計画要請部が、機能／サービスの提供地域情報及び要件情報とＭＥＣサーバの配置情報とを少なくとも含む非テレメトリ情報を取得して前記記憶部に格納するとともに、前記非テレメトリ情報に基づきクラスタ計画要請を生成する第２のステップと、
   クラスタリングシステムのクラスタ計画部が、前記クラスタ計画要請に応じて、前記記憶部のテレメトリ情報及び非テレメトリ情報に基づき機能／サービスの提供地域及び要件を満たす１つ以上の拠点からなる仮想リージョンを設定し、設定した仮想リージョンに属する拠点に配備された複数のＭＥＣサーバの中から機能／サービスを提供するためのクラスタ計画を算出する第３のステップと、
   クラスタリングシステムのクラスタ構築部が、前記クラスタ計画に基づきクラスタリング処理を行う第４のステップとを備えた
   ことを特徴とするクラスタリング方法。

Images