JP7754331B2 - コンフィグレーション投入装置、コンフィグレーション投入方法及びコンフィグレーション投入プログラム - Google Patents

Description

本開示は、コンフィグレーション投入装置、コンフィグレーション投入方法及びコンフィグレーション投入プログラムに関する。

通信事業者は、様々な種類の通信サービスを提供している。例えば、通信サービスとしては、インターネット接続サービスや、映像配信サービスが挙げられる。これらの通信サービスは、エッジルータなどの通信装置に設定された「ユーザコンフィグレーション（User Configuration）」にしたがって提供される。

便宜上、コンフィグレーション（configuration）は、コンフィグ（config）と略される。例えば、ユーザコンフィグは、ユーザコンフィグレーションを意味する。

ユーザコンフィグは、ユーザＩＤ（identifier）、ユーザが利用するサービス等のデータを含む。ユーザコンフィグは、集中管理サーバによって設定される。

集中管理サーバは、ネットワークを構成する通信装置のリソースを管理する。例えば、通信装置のリソースは、帯域、通信装置に設定可能なフィルタの数、確立可能なセッションの数を含む。リソースに関するデータは、集中管理サーバに集められる。集中管理サーバは、ユーザを収容する通信装置を、各通信装置の空きリソースに応じて選択する。その後に、集中管理サーバは、選択された通信装置に、ユーザコンフィグを設定する。

集中管理サーバは、複数の機能部で構成されている。大量の装置に対する制御を高速に処理するために、複数の機能部は、複数の装置制御部を含む。各装置制御部は、オーダ（orders）の内容に応じて、通信装置にアクセスし、それから、制御コマンドを実行する。以下では、「オーダ（orders）」を「要求」と表記することがある。

国際公開第２０２１／０４４６０４号 国際公開第２０２２／００３９２６号 国際公開第２０２２／０４４３４１号

岩橋宏樹、他３名、"Ansibleによる改造容易なエッジルータへのユーザコンフィグ投入"、電子情報通信学会２０２１年総合大会、Ｂ－６－６７、２０２１年３月１１日． 岩橋宏樹、他４名、"ユーザ収容柔軟化システムにおける収容替え先制限方法の検討"、電子情報通信学会２０２１年ソサエティ大会、Ｂ－６－１１、２０２１年９月１４日． 岩橋宏樹、他３名、"エッジルータコンフィグ投入サーバの改造容易な要求受付機能"、電子情報通信学会２０２２年総合大会、Ｂ－６－３３、２０２２年３月１５日．

しかしながら、上記の先行技術は、コンフィグレーション投入要求の処理における性能を向上させることが難しい場合がある。

そこで、本開示は、コンフィグレーション投入要求の処理における性能を向上させることができるコンフィグレーション投入装置、コンフィグレーション投入方法及びコンフィグレーション投入プログラムを提供する。

本開示の一態様では、コンフィグレーション投入装置は、特定の通信装置に対応する複数のコンフィグレーション投入要求を取得する取得部と、前記複数のコンフィグレーション投入要求が、前記特定の通信装置に対応する他のコンフィグレーション投入要求と競合するか、を判定する競合判定部と、前記複数のコンフィグレーション投入要求が前記他のコンフィグレーション投入要求と競合しない、と判定された場合に、前記複数のコンフィグレーション投入要求に対応する複数のコンフィグレーションを、前記特定の通信装置に、まとめて投入する投入部とを備える。

コンフィグレーション投入装置は、コンフィグレーション投入要求の処理における性能を向上させることができる。

図１Ａは、通信装置にコンフィグを投入するための処理の例を示す。 図１Ｂは、通信装置にコンフィグを投入するための処理の例を示す。 図２は、通信装置のための排他制御の例を示す。 図３は、通信装置のためのリソースコントロールの例を示す。 図４は、排他制御に関連する課題の例を示す。 図５は、リソースコントロールに関連する課題の例を示す。 図６は、コンフィグ投入のための環境の例のブロック図である。 図７は、本開示に係る集中管理サーバの構成の例のブロック図である。 図８は、本開示に係るコンフィグ投入処理の例を示す。 図９は、通信装置にコンフィグを投入するための処理の例を示すフローチャートである。 図１０は、通信装置のためのリソースコントロールを確立するための処理の例を示すフローチャートである。 図１１は、コンピュータのハードウェア構成の例を示す。

本開示の複数の実施形態が、添付の図面と、以下の説明に記載されている。なお、本発明は、これらの実施形態に限定されるものではない。これらの実施形態の様々な特徴は、これらの特徴が互いに矛盾しないという条件で、様々なやり方で組み合わされ得る。同種の符号は、同種の要素を示す。

以下の説明は、概要と９個の節で構成されている：
概要
１．はじめに
１－１．コンフィグ投入処理
１－２．排他制御―コンフィグ投入要求の競合の回避
１－３．リソースコンロール―集中管理サーバのリソースの配置
１－４．課題の例
２．コンフィグ投入のための環境
３．集中管理サーバの構成
４．本開示に係るコンフィグ投入処理
４－１．コンフィグの一括投入
４－２．予想される遅延を回避するためのリソースコンロール
５．コンフィグ投入処理のフローチャート
６．効果
７．ハードウェア構成
８．実施形態のまとめ
９．補遺

〔概要〕
本開示に係る技術の概要を、概要の項目で説明する。なお、この概要は、本発明や、以下の節で説明する複数の実施形態を限定することを意図するものではない。

様々な技術が、通信装置に、ユーザのコンフィグレーション（コンフィグ）を効率的に投入するために、提案されている。ユーザのコンフィグは、集中管理サーバから、通信装置へと投入される。集中管理サーバは、コンフィグ投入要求管理データベース（管理ＤＢ）、リソースコントローラ、複数の装置制御部等の、複数の要素で構成されている。

例えば、１つのコンフィグ投入技術では、装置制御部は、以下の動作を行う：（１）コンフィグレーション投入要求（configuration input order）を、管理ＤＢから取得する（２）通信装置にコンフィグレーション（コンフィグ）を投入する。その一方、リソースコントローラは、以下の動作を行う：（１）リソースを、装置制御部に、コンフィグ投入要求の数に応じて、割り当てる（２）スケールアップ(装置制御部の臨時増設)を行う（３）装置制御部が管理ＤＢにオーダ（コンフィグ投入要求）を確認する頻度を変更する。

しかし、大量のコンフィグ投入のオーダが、同一の通信装置に集中する場合がある。この場合、オーダの処理時間が、排他制御によって長くなる場合がある。また、大量のオーダが、全通信装置に均等に分散する場合がある。この場合、コンフィグ投入が、一部の通信装置において、遅くなる場合がある。なぜなら、１つの制御装置が、複数の通信装置にコンフィグを投入しているためである。例えば、制御装置が制御している通信装置の数が、この制御装置が同時に制御可能な通信装置の数を超えると、コンフィグ投入が遅くなる。

そこで、本開示に係る技術では、装置制御部が、同一の通信装置への複数のオーダを、この装置制御部が管理ＤＢからオーダを取得する際に、まとめて取得する。さらに、この装置制御部は、複数のオーダの競合判定を行い、それから、互いに競合しない複数のオーダを、同一の通信装置に、まとめて投入する。

一方、リソースコントローラは、オーダの種別や、対象の通信装置を監視する。もし、オーダの遅延が予想された場合には、リソースコントローラは、オーダが全通信装置に分散しているか、を判定する。オーダが全通信装置に分散している場合には、リソースコントローラは、装置制御部の増設を行う。

さらに、リソースコントローラは、オーダが特定の通信装置に集中しているか、を判定する。オーダが特定の通信装置に集中している場合には、リソースコントローラは、装置制御部の設定を、この装置制御部がこの特定の通信装置のみを制御するように、変更する。

これにより、本開示に係る技術は、装置制御部が管理ＤＢを確認する頻度を低減することができる。上で説明したように、大量のコンフィグ投入のオーダが、同一の通信装置に集中する場合がある。また、大量のオーダが、全通信装置に均等に分散する場合もある。このような状況でも、本開示に係る技術は、コンフィグ投入の遅延を低減することができる。

〔１．はじめに〕
様々な種類の通信サービスが、ＩＰ（Internet Protocol）ネットワークをとおして、提供されている。ＩＰネットワークは、エッジルータなどの複数の通信装置によって構成されている。

複数の通信装置は、ユーザのコンフィグを記憶する。各通信装置は、様々な通信制御を、ユーザごとに設定されたコンフィグ情報に基づいて、行う。例えば、コンフィグ情報は、インターネット接続サービス、映像配信サービス等の、通信サービスに関連する情報を含む。

ユーザのコンフィグは、ＩＰネットワークに接続された集中管理サーバによって管理される。集中管理サーバは、コンフィグ投入要求を、上位システムから受信する。上位システムは、例えば、通信事業者によって管理される通信制御システムである。上位システムは、オペレータであってもよい。

集中管理サーバは、コンフィグを、通信装置に、コンフィグ投入要求に基づいて、投入する。通信装置にコンフィグを投入するための処理の例を、図１Ａおよび図１Ｂを参照して、次の小節で説明する。

〔１－１．コンフィグ投入処理〕
図１Ａおよび図１Ｂは、通信装置にコンフィグを投入するための処理の例である処理１０を、ひとまとめにして示す。

処理１０は、集中管理サーバ１１によって行われる。図１Ａに示されるように、集中管理サーバ１１は、上位システム対応部１２、コンフィグ投入要求管理ＤＢ（Data Base）１３、リソース管理／収容位置決定部１４、複数の装置制御部１５、およびリソースコントローラ１６を含む。リソース管理／収容位置決定部１４は、リソース管理／収容位置管理ＤＢを含む。

図１Ｂに示されるように、処理１０は、ステップＳ１１からステップＳ１６までの６つのステップを含む。

ステップＳ１１では、集中管理サーバ１１が、コンフィグ投入要求を、上位システム１７から受信する。コンフィグ投入要求は、例えば、新規ユーザのコンフィグを投入せよとの要求である。

ステップＳ１２では、上位システム対応部１２が、コンフィグ投入要求を、コンフィグ投入要求管理ＤＢ１３に登録する。

ステップＳ１３では、リソース管理／収容位置決定部１４が、ユーザの収容位置を決定する。

例えば、リソース管理／収容位置決定部１４は、コンフィグ投入要求管理ＤＢ１３を、定期的に監視する。また、リソース管理／収容位置決定部１４は、各通信装置１８の空きリソースの量を管理している。新たなコンフィグ投入要求が、コンフィグ投入要求管理ＤＢ１３に登録された場合に、リソース管理／収容位置決定部１４は、リソース管理／収容位置管理ＤＢを参照する。リソース管理／収容位置決定部１４は、空き収容位置を確認する。

空き収容位置の確認後、リソース管理／収容位置決定部１４は、ユーザを収容する通信装置１８やＬＡＧ（Link Aggregation）（または物理ポート）を、各通信装置１８の空きリソースの量に応じて、適切に決定する。例えば、ユーザを収容する通信装置１８は、ユーザが通信可能なエッジルータ群（エッジグループ）の中から、決定される。図１Ｂの例では、通信装置１８ａが、ユーザＡを収容する通信装置として、決定される。

ステップＳ１４では、装置制御部１５ａが、コンフィグ投入要求管理ＤＢ１３から、コンフィグ投入要求を取得する。新たなコンフィグ投入要求を取得するために、装置制御部１５ａは、コンフィグ投入要求管理ＤＢ１３を、定期的に監視する。

ステップＳ１５では、装置制御部１５ａが、リソース管理／収容位置決定部１４によって決定された収容先の通信装置に、コンフィグを投入する。図１Ｂの例では、決定された収容先の通信装置は、通信装置１８ａである。装置制御部１５ａは、通信装置１８ａに、ユーザＡのコンフィグを投入する。

ステップＳ１６では、装置制御部１５ａが、通信を確立する。図１Ｂの例では、ユーザＡの通信が、コンフィグが投入された通信装置１８ａ上で、確立される。

〔１－２．排他制御―コンフィグ投入要求の競合の回避〕
複数の装置制御部１６が、同時に同じ通信装置１８にアクセスし、それから、制御コマンドを実行したり、コンフィグを投入したりすると、競合が発生する可能性がある。このため、集中管理サーバ１１は、排他制御を、競合を回避するために、必要とする。

図２は、通信装置のための排他制御の例である排他制御２０を示す。

図２の例では、装置制御部１５ａ（装置制御部＃１）および装置制御部１５ｂ（装置制御部＃２）が、通信装置１８ａ（通信装置Ａ）に、同時にアクセスしている。これらの装置制御部が、制御コマンド実行したり、コンフィグを投入したりする。このような動作は、競合２１を発生させる可能性がある。競合を回避するために、排他制御が、装置制御部１５において行われる。

図２に示されるように、排他制御の管理用のテーブル２２が、コンフィグ投入要求管理ＤＢ１３に用意されている。テーブル２２は、排他制御のフラグを管理する。フラグは、特定の通信装置１８を同時に制御可能な複数の装置制御部１５を、１台の装置制御部１５に制限する。

図２の例では、通信装置Ａは、制御フラグ＃１に関連付けられている。この場合、装置制御部１５ａ（装置制御部＃１）は、通信装置Ａを制御することができるが、他の装置制御部１５は、通信装置Ａを制御することができない。

〔１－３．リソースコンロール―集中管理サーバのリソースの配置〕
リソースコントローラ１６は、各機能部の動作状況を監視する。リソースコントローラ１６は、各機能部の動作を、各機能部のリソース状況に応じて、制御する。

図３は、通信装置のためのリソースコントロールの例であるリソースコントロール３０を示す。

図３に示されるように、リソースコントロール３０は、ステップＳ３１およびステップＳ３２を含む。

ステップＳ３１では、リソースコントローラ１６は、処理待ちのコンフィグ投入要求の数を確認する。リソースコントローラ１６は、受信されたコンフィグ投入要求の数を、一定時間ごとに、監視する。

ステップＳ３２では、装置制御部１５のリソースを制御する。リソースコントローラ１６は、リソースを、装置制御部１５に、確認された要求の数に応じて、割り当てる。投入要求の滞留を防ぐために、リソースコントローラ１６は、例えば、装置制御部１５ａ１を、装置制御部１５ａに臨時に増設する。あるいは、リソースコントローラ１６は、コンピュートリソースを、装置制御部１５ａに割り当ててもよい。また、リソースコントローラ１６は、装置制御部１５がコンフィグ投入要求管理ＤＢ１３を確認する頻度を、変更することができる。

なお、全ての装置制御部１５のＤＢアクセス頻度が高すぎて、ＤＢアクセスリソースが、枯渇する場合がある。このような状況を防ぐために、ステップＳ３２のリソースコントロールは、リソース拡張や確認頻度の加速を必要とする装置制御部１５にのみに、適用されてもよい。したがって、集中管理サーバ１１全体のリソース量は、ピーク時でも抑えられる。

〔１－４．課題の例〕
集中管理サーバ１１のオーダ処理性能は、以下で説明する理由によって、低くなる場合がある。さらに、大量のオーダがバースト的に流れると、オーダは処理しきれない場合がある。もし、オーダが、オーダのタイムアウト時間を超過すると、オーダは、エラーとして扱われる。

図４は、排他制御に関連する課題の例である課題４０を示す。

図２を参照して上で説明したように、もし、複数の装置制御部１５が、同一の通信装置１８に、同時にアクセスし、それから、コマンドを実行すると、コマンド競合が発生する場合がある。コマンド競合は、想定外の動作を引き起こす可能性がある。このため、集中管理サーバ１１は、制御対象の通信装置１８に関して、排他制御を必要とする。しかし、排他制御の仕組みのために、待ち時間が、同一の通信装置１８へのコマンド投入において、発声する。その結果、オーダの処理時間が長くなる。

排他制御のため、オーダは、原則、１つずつ処理される。したがって、同一の通信装置１８へのオーダは、処理の待ち時間が長い。オーダは、個々の装置制御部１５や通信装置１８で処理される。図５を参照して以下で説明するように、処理の待ち時間は、個々のオーダの処理時間が長い場合に、問題となる。

リソースコントローラ１６が、装置制御部１５のスケールアウトを行ったり、リソースを、装置制御部１５に追加的に割り当てたりしても、オーダ処理の性能が、改善されない場合がある。

リソースコントローラ１６は、装置制御部１５のスケールアウトを、上位システム１７からのオーダ入力数に基づいて、行う。このスケールアウトは、オーダ処理の性能を向上させるために行われる。しかし、オーダ処理の性能は、同一の通信装置１８へのオーダ投入に関しては、スケールアウトによって改善されない。なぜなら、排他制御のため、特定の装置制御部１５のみが、装置制御部１５に、オーダを投入するからである。リソースコントロールに効果があるかの判定は、１つの装置制御部１５によって同時に制御され得る通信装置１８の数、同一の通信装置１８へのオーダの集中具合、等の考慮を必要とする。

図４の例では、大量のオーダが、通信装置Ａに集中している（４１）。大量のオーダが、特定の通信装置１８に集中しても、特定の装置制御部１５のみが、装置制御部１５に、オーダを投入する。その結果、他の余力のある装置制御部１５が余る。この場合、単純に装置制御部１５ａ１を増設しても、意味がない。

図５は、リソースコントロールに関連する課題の例である課題５０を示す。

図５の例では、大量のオーダが、全通信装置１８に、均等に分散している（５１）。リソースコントローラ１６は、装置制御部１５ａおよび装置制御部１５ｂにリソースを、追加的に割り当てる（５２）。追加のリソースは、装置制御部１５ａおよび装置制御部１５ｂの処理速度を向上させる。

１台の装置制御部は、複数の通信装置１８を制御することができる。しかし、大量のオーダが、１台の装置制御部が多くの通信装置１８を制御する状況で、全通信装置１８に、均等に分散した場合に、一部の通信装置１８へのオーダ投入が遅れる（５３ａ、５３ｂ）。リソースコントローラ１６が、装置制御部１５にリソースを割り当て、装置制御部１５の処理速度を向上させたとしても、処理速度の向上は、オーダ投入の遅れを防ぐ上で効果が薄い。

その他の課題の例としては、装置制御部１５の処理速度が挙げられる。装置制御部１５の処理が、そもそも遅い場合がある。

装置制御部１５は、オーダに応じたコマンド生成／投入を実行する。コマンド生成／投入は、コマンド生成機能の起動、コマンド生成処理、通信装置１８（エッジルータ）との接続の確立、コマンド投入、応答待ち、応答チェック（投入結果のチェック）、等のステップを含む。

コマンド生成機能の起動およびコマンド生成処理は、実装方式または利用ソフトウェアによっては、時間がかかる場合がある。例えば、外部システムが、集中管理サーバ１１に組み込まれている場合がある。接続の確立、コマンド投入および応答チェックは、装置制御部１５のコマンド変換部の実装方式、利用ソフトウェアまたは通信装置１８によっては、時間がかかる場合がある。

上記の課題を解決するために、本開示に係る集中管理サーバは、以下で説明する１つまたは複数のコンフィグ投入処理を行う。

〔２．コンフィグ投入のための環境〕
まず、コンフィグ投入のための環境を、図６を参照して説明する。

図６は、コンフィグ投入のための環境の例である環境１のブロック図である。図６に示されるように、環境１は、集中管理サーバ１００、ネットワーク２００、上位システム１７および複数の通信装置１８を含む。集中管理サーバ１００は、コンフィグレーション投入装置の一例である。

環境１は、複数の集中管理サーバ１００を含み得る。複数の集中管理サーバ１００は、コンフィグ投入のためのシステムを構成し得る。

集中管理サーバ１００は、コンフィグを投入するための処理を行う装置である。この明細書では、このような処理は、コンフィグ投入処理と呼ばれる。様々なコンフィグ投入処理を、４節で詳細に説明する。

集中管理サーバ１００は、サーバ等のコンピュータである。集中管理サーバ１００の構成の例を、４節で説明する。

ネットワーク２００は、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット等のネットワークである。ネットワーク２００は、集中管理サーバ１００、上位システム１７および複数の通信装置１８を接続する。

〔３．集中管理サーバの構成〕
次に、集中管理サーバ１００の構成の例を、図７を参照して説明する。

図７は、本開示に係る集中管理サーバ１００の構成の例のブロック図である。図７に示されるように、集中管理サーバ１００は、通信部１１０、制御部１２０および記憶部１３０を含む。集中管理サーバ１００は、集中管理サーバ１００の管理者から入力を受け付ける入力部（例えば、キーボード、マウス）を含んでもよい。また、集中管理サーバ１００は、管理者に情報を表示する出力部（例えば、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ）を含んでもよい。

（通信部１１０）
通信部１１０は、ＮＩＣ（Network Interface Card）等のネットワーク機器によって実装される。通信部１１０は、有線または無線によりネットワーク２００と接続される。通信部１１０は、ネットワーク２００を介して、上位システム１７および複数の通信装置１８との間で、データの送受信を行うことができる。

（制御部１２０）
制御部１２０は、データ処理装置と、記憶装置に記憶された各種プログラムによって実装される。データ処理装置は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＧＰＵ（General Purpose Graphic Processing Unit）等のプロセッサである。制御部１２０は、集中管理サーバ１００の複数の動作を制御するためのコントローラ（controller）として実装され得る。例えば、１つまたは複数のプロセッサが、ＲＡＭ（Random Access Memory）を作業領域として使用することで、プログラム（複数の命令）を実行した場合に、この１つまたは複数のプロセッサは、複数の動作を行う。

制御部１２０は、コンフィグ投入処理のための入力データを、外部装置から受信することができる。制御部１２０は、入力データ、コンフィグ投入処理において使用されるデータ、コンフィグ投入処理の出力データ等のデータを、記憶部１３０に格納することができる。制御部１２０は、このようなデータを、記憶部１３０から、必要に応じて取得することができる。

（記憶部１３０）
記憶部１３０は、ＲＡＭ、フラッシュメモリ（Flash Memory）等の半導体メモリ、ハードディスク等の磁気ディスク、または光ディスクによって実装される。記憶部１３０は、各種プログラムおよび各種データを記憶することができる。

図７に示されるように、制御部１２０は、上位システム対応部１２１、リソース管理／収容位置決定部１２２、リソースコントローラ１２３および装置制御部１２４を含む。記憶部１３０は、コンフィグ投入要求管理ＤＢを含む。便宜上、以下では、「上位システム対応部」、「リソース管理／収容位置決定部」および「コンフィグ投入要求管理ＤＢ」を、略して、「対応部」、「決定部」および「管理ＤＢ」とそれぞれ呼ぶ。

リソースコントローラ１２３は、分散判定部、スケールアウト部、集中判定部およびスケールアップ部の一例である。装置制御部１２４は、取得部、競合判定部、投入部、格納部および追加部の一例である。

個々の部によって行われるデータ処理を、以下で説明する。また、個々の部によってアクセスされるＤＢを、以下で説明する。

（対応部１２１）
対応部１２１は、ユーザのコンフィグを通信装置に投入せよとの要求（order）を受信する。この要求は、コンフィグ投入要求と呼ばれる。

（決定部１２２）
決定部１２２は、ユーザを収容する通信装置１８を、上位システム１７のオーダに関する情報や、ユーザに関する情報に基づいて決定する。

（リソースコントローラ１２３）
リソースコントローラ１２３は、図１Ａ、図１Ｂ、図２、図３、図４および図５を参照して上述したリソースコントローラ１６と同様の機能を有し得る。リソースコントローラ１６の機能についての同じ説明は、ここでは、省略される。

（装置制御部１２４）
装置制御部１２４は、図１Ａ、図１Ｂ、図２、図３、図４および図５を参照して上述した装置制御部１５と同様の機能を有し得る。装置制御部１５の機能についての同じ説明は、ここでは、省略される。

（管理ＤＢ１３１）
管理ＤＢ１３１は、図１Ａ、図１Ｂ、図２、図３、図４および図５を参照して上述したコンフィグ投入要求管理ＤＢ１３と同様の機能を有し得る。コンフィグ投入要求管理ＤＢ１３の機能についての同じ説明は、ここでは、省略される。

〔４．本開示に係るコンフィグ投入処理〕
様々なコンフィグ投入処理を、この節で詳細に説明する。以下で説明する仕組みが、集中管理サーバ１００の要求処理の性能を向上させる。

図８は、本開示に係るコンフィグ投入処理の例であるコンフィグ投入処理６０を示す。図８に示されるように、装置制御部１２４は、オーダ群ＤＢ６１および一括投入機能６２を含む。リソースコントローラ１２３は、より高度な動作ロジック６３を含む。

オーダ群ＤＢ６１および一括投入機能６２は、図４を参照して上で説明した、排他制御に関連する課題を解決するために、使用される。より高度な動作ロジック６３は、図５を参照して上で説明した、リソースコントロールに関連する課題を解決するために、使用される。

〔４－１．コンフィグの一括投入〕
装置制御部１２４は、コンフィグ投入要求を、管理ＤＢ１３１から取得する。装置制御部１２４がコンフィグ投入要求を取得する際、装置制御部１２４は、同一の通信装置１８への複数のコンフィグ投入要求を、まとめて取得する（６４）。装置制御部１２４は、取得された複数のコンフィグ投入要求を、オーダ群ＤＢ６１に、同一の通信装置へのオーダ群（要求群）として、格納する。

オーダ群ＤＢ６１は、サブＤＢとして実装される。オーダ群ＤＢ６１は、管理ＤＢ１３１とは異なる、装置制御部１２４内のＤＢである。

オーダ群ＤＢ６１は、同一の通信装置へのオーダ群を記憶する。オーダ群は、複数のオーダ（要求）であり、複数のオーダ（要求）は、複数のコンフィグに対応する。

装置制御部１２４は、一括投入機能６２を含む。一括投入機能６２は、複数のコンフィグレーション投入要求が、他のコンフィグレーション投入要求と競合するかの判定に関連する。オーダ群に関して、装置制御部１２４は、複数のコンフィグが、特定の通信装置１８に、同時に投入され得るか、を判定する。この投入判定は、互いに競合しない複数のコンフィグ投入要求を決定すること、を意味する。

例えば、装置制御部１２４は、この投入判定を、（１）複数のコンフィグが同一のユーザのコンフィグであるか、（２）あるユーザが、他のユーザと共通するコンフィグ（すなわち、設定）を有するか、等の情報に基づいて、行う。

装置制御部１２４は、特定の通信装置１８に同時に投入され得る複数のコンフィグを特定する。装置制御部１２４は、特定された複数のコンフィグを、特定の通信装置１８にまとめて投入する（６５）。

上で説明したように、装置制御部１２４は、互いに競合しない複数のコンフィグ投入要求を決定し、それから、これらのコンフィグ投入要求に対応する複数のコンフィグを、特定の通信装置１８に、まとめて投入する。この投入処理は、コンフィグ投入要求をコマンドに変換するための起動処理の処理負荷を削減することができる。

また、装置制御部１２４は、通信装置１８への接続を確立するための処理を行う。投入処理は、この確立処理が遅い場合のオーバヘッドを削減することもできる。

上で説明したように、装置制御部１２４は、同一の通信装置１８への複数のコンフィグ投入要求を、管理ＤＢ１３１から、まとめて取得する。複数のコンフィグが、コンフィグ投入要求から特定され、それから、特定された複数のコンフィグが、特定の通信装置１８に投入される。その後に、装置制御部１２４は、コンフィグ投入の結果を、管理ＤＢ１３１に、まとめて反映させる。

すなわち、装置制御部１２４は、管理ＤＢ１３１へのアクセス頻度を、ＤＢ自体（オーダ群ＤＢ６１）を流通させることによって、低減している。このことは、オーダ（要求）取得のオーバヘッドを削減することができる。

〔４－２．予想される遅延を回避するためのリソースコンロール〕
リソースコントローラ１２３は、より高度な動作ロジック６３を含む。リソースコントローラ１２３は、コンフィグ投入要求の受信状況および処理速度だけではなく、コンフィグ投入要求の種別や対象の通信装置１８も監視する。

リソースコントローラ１２３は、通信装置１８ごとに、コンフィグ投入要求を抽出する。リソースコントローラ１２３は、通信装置１８に投入されるコマンドの量を、コンフィグ投入要求の種別に基づいて、推定することができる。したがって、リソースコントローラ１２３は、各通信装置１８に投入されるコマンドの量と、各コンフィグ投入要求の完了時刻を推定することができる。特定のコンフィグ投入要求の完了時刻は、そのコンフィグ投入要求以前に同一の通信装置１８に投入されたコマンドの量と、各コマンドの推定実行時間に基づいて、計算され得る。

コンフィグ投入要求の遅延が予想された場合に、リソースコントローラ１２３は、以下のリソースコントロールによって、コンフィグ投入処理を加速する。例えば、リソースコントローラ１２３が、「完了予定時刻が処理期限を超えるコンフィグ投入要求」を検出した場合に、リソースコントローラ１２３は、以下のリソースコントロールを実行する。リソースコントロールは、２つのケースを含む。

第１のケースは、（１）装置制御部１２４の数×１第の装置制御部１２４で同時に制御可能な通信装置１８の数≦全装置制御部１２４の数、かつ、（２）コンフィグ投入要求が全装置制御部１２４に分散しているケースである。この第１のケースでは、リソースコントローラ１２３は、装置制御部１２４を増設する。

第２のケースは、コンフィグ投入要求が、特定の通信装置１８に集中しているケースである。この第２のケースでは、リソースコントローラ１２３は、特定の通信装置１８を制御する装置制御部１２４を、１台の装置制御部１２４に固定する。リソースコントローラ１２３は、装置制御部１２４の設定を、この１台の装置制御部１２４のみが特定の通信装置１８を制御するように、変更する。

リソースコントローラ１２３は、余分な装置制御部１２４を、装置制御部１２４の設定を変更することによって、スケールインする。リソースコントローラ１２３は、浮いたリソースを、１台の装置制御部１２４に割り当てる。オーダ遅延の予想が解消された段階で、リソースコントローラ１２３は、装置制御部１２４の設定を、元の状態に戻す。

〔５．コンフィグ投入処理のフローチャート〕
次に、コンフィグ投入処理の例のフローチャートを、図９および図１０を参照して説明する。コンフィグ投入処理の例は、次の２つの処理を含む：（１）通信装置にコンフィグを投入するための処理および（２）通信装置のためのリソースコントロールを確立するための処理。この２つの処理は、例えば、図６の集中管理サーバ１００によって行われる。

図９は、通信装置にコンフィグを投入するための処理の例である処理Ｐ１００を示すフローチャートである。

集中管理サーバ１００の装置制御部１２４は、同一の通信装置１８への複数の要求をまとめて取得する（ステップＳ１０１）。

装置制御部１２４は、取得された複数の要求の中から、競合しない複数の要求を特定する（ステップＳ１０２）。

装置制御部１２４は、特定された複数のコンフィグを、同一の通信装置１８に、競合しない複数の要求に基づいて、まとめて投入する（ステップＳ１０３）。

図１０は、通信装置のためのリソースコントロールを確立するための処理の例である処理Ｐ２００を示すフローチャートである。

集中管理サーバ１００のリソースコントローラ１２３は、要求の種別と、対象の通信装置１８を監視する（ステップＳ２０１）。

リソースコントローラ１２３は、要求が遅延することが予想されるか、を判定する（ステップＳ２０２）。

要求が遅延することが予想されない場合に（ステップＳ２０２：Ｎｏ）、処理Ｐ２００は終了する。

要求が遅延することが予想される場合に（ステップＳ２０２：Ｙｅｓ）、リソースコントローラ１２３は、要求が複数の通信装置１８に分散しているか、を判定する（ステップＳ２０３）。

要求が複数の通信装置１８に分散している場合に（ステップＳ２０３：Ｙｅｓ）、リソースコントローラ１２３は、装置制御部１２４を増設する（ステップＳ２０４）。

要求が複数の通信装置１８に分散していない場合に（ステップＳ２０３：Ｎｏ）、リソースコントローラ１２３は、要求が特定の通信装置１８に集中しているか、を判定する（ステップＳ２０５）。

要求が特定の通信装置１８に集中していない場合に（ステップＳ２０５：Ｎｏ）、処理Ｐ２００は終了する。

要求が特定の通信装置１８に集中している場合に（ステップＳ２０５：Ｙｅｓ）、リソースコントローラ１２３は、装置制御部１２４の設定を変更する（ステップＳ２０６）。具体的には、リソースコントローラ１２３は、この特定の通信装置に割り当てられるリソースのスケールアップを行う。

〔６．効果〕
集中管理サーバ１００は、排他制御による制御対象の通信装置１８の正常性を担保しつつ、集中管理サーバ１００によるコンフィグ投入要求の処理における性能を向上させることができる。また、集中管理サーバ１００は、排他制御やコンフィグ投入要求の特性に応じて、柔軟にマシンリソースを制御することができる。これにより、集中管理サーバ１００は、効率的にリソースを使用することができ、コンフィグ投入要求の処理を、無駄なく行うことができる。

上で説明したように、集中管理サーバ１００の装置制御部１２４は、ＤＢの内容自体を流通させ、ＤＢ内容をマスタＤＢ（管理ＤＢ１３１）に刈り取りに行くのを不要にする。このことは、刈り取りのオーバヘッドを削減することができる。

装置制御部１２４は、複数のコンフィグを、まとめて通信装置１８に投入する。集中管理サーバ１００の機能部は、例えば、Ansible（登録商標）を使って実装され得る。Ansible起動のオーバヘッドが大きく、エッジアクセスのオーバヘッドが大きくなる場合でも、このようなコンフィグ投入は、オーダ処理の性能を改善することができる。

また、装置制御部１２４は、複数のコンフィグ投入要求が互いに競合しないかを判定する。例えば、この競合判定を、（１）コンフィグ投入要求が同一ユーザに対応するか、（２）ユーザのコンフィグ投入要求が他のユーザと共通する設定を含むか、等の情報に基づいて、行う。

上で説明したように、集中管理サーバ１００のリソースコントローラ１２３は、以下の２つの状況を満たすケースでは、装置制御部１２４をスケールアウトする：（１）装置制御部１２４が、「装置制御部１２４の数」×「１台の装置制御部１２４で同時に制御可能な通信装置１８の数」≦全装置制御部１２４の数という状況で、フル稼働している。（２）コンフィグ投入要求が、制御中の通信装置１８以外の通信装置１８に来ている。

特定の通信装置１８へのコンフィグ投入要求が集中している場合に、リソースコントローラ１２３は、スケールアップおよびＣＰＵ/メモリ等のリソース割り当てを、オーダの種別ごとの処理時間に応じて、増加させる。不足分のリソースに関しては、リソースコントローラ１２３は、余分な装置制御部１２４をスケールインし、不足分のリソースを確保する。確保されたリソースは、オーダ処理の速度を向上させることができる。

〔７．ハードウェア構成〕
図１１は、コンピュータのハードウェア構成の例であるコンピュータ１０００を示す図である。この明細書で説明されたシステムや方法は、例えば、コンピュータ１０００によって実装される。

コンピュータ１０００は、プログラムを実行することで集中管理サーバ１００を実装するコンピュータの一例を示している。コンピュータ１０００は、メモリ１０１０、ＣＰＵ１０２０を有する。また、コンピュータ１０００は、ハードディスクドライブインタフェース１０３０、ディスクドライブインタフェース１０４０、シリアルポートインタフェース１０５０、ビデオアダプタ１０６０およびネットワークインタフェース１０７０を有する。これらの構成要素は、バス１０８０によって接続される。

メモリ１０１０は、ＲＯＭ（Read Only Memory）１０１１およびＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic Input Output System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、ハードディスクドライブ１０９０に接続される。ディスクドライブインタフェース１０４０は、ディスクドライブ１１００に接続される。着脱可能な記憶媒体（例えば、磁気ディスクや光ディスク）が、ディスクドライブ１１００に挿入され得る。シリアルポートインタフェース１０５０は、例えば、マウス１１１０、キーボード１１２０に接続される。ビデオアダプタ１０６０は、例えば、ディスプレイ１１３０に接続される。

ハードディスクドライブ１０９０は、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３およびプログラムデータ１０９４を記憶する。コンピュータ１０００によって実行されるプログラムは、集中管理サーバ１００の複数の動作を規定する。このプログラムは、コンピュータ１０００により実行可能なコードで記述されたプログラムモジュール１０９３として実装され得る。プログラムモジュール１０９３は、例えば、ハードディスクドライブ１０９０に記憶される。例えば、ハードディスクドライブ１０９０は、集中管理サーバ１００の構成要素の機能と同様の処理を実行するためのプログラムモジュール１０９３を記憶する。なお、ハードディスクドライブ１０９０は、ＳＳＤ（Solid State Drive）に置き換えられてもよい。

ハードディスクドライブ１０９０は、コンフィグ投入処理のためのコンフィグレーション投入プログラムを記憶することができる。ハードディスクドライブ１０９０は、コンフィグレーション投入プログラム（複数の命令）を含むコンピュータプログラムプロダクトを記憶してもよい。コンフィグレーション投入プログラムは、実行された場合に、上で説明したような、１つまたは複数の方法を行う。

上で説明した様々な処理に用いられる設定データは、プログラムデータ１０９４として実装され得る。設定データは、例えば、メモリ１０１０やハードディスクドライブ１０９０に記憶される。ＣＰＵ１０２０は、メモリ１０１０やハードディスクドライブ１０９０に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を、必要に応じて、ＲＡＭ１０１２にロードする。そして、ＣＰＵ１０２０は、上で説明した様々な処理を行う。

なお、プログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０９０ではなく、着脱可能な記憶媒体に記憶されてもよい。ＣＰＵ１０２０は、プログラムモジュール１０９３やプログラムデータ１０９４を、ディスクドライブ１１００等を介してロードしてもよい。あるいは、プログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ、ＷＡＮ等）を介してコンピュータ１０００に接続された他のコンピュータに記憶されてもよい。この場合、ＣＰＵ１０２０は、プログラムモジュール１０９３やプログラムデータ１０９４を、ネットワークインタフェース１０７０を介してロードしてもよい。

〔８．実施形態のまとめ〕
上で説明したように、集中管理サーバ１００は、装置制御部１２４を含む。少なくとも１つの実施形態では、装置制御部１２４は、特定の通信装置に対応する複数のコンフィグレーション投入要求を取得する。その後に、装置制御部１２４は、複数のコンフィグレーション投入要求が、特定の通信装置に対応する他のコンフィグレーション投入要求と競合するか、を判定する。複数のコンフィグレーション投入要求が他のコンフィグレーション投入要求と競合しない、と判定された場合に、装置制御部１２４は、複数のコンフィグレーション投入要求に対応する複数のコンフィグレーションを、特定の通信装置に、まとめて投入する。

いくつかの実施形態では、装置制御部１２４は、特定の通信装置に対応する複数のコンフィグレーション投入要求を、複数の通信装置のうちのいずれかに対応する複数のコンフィグレーション投入要求を記憶するデータベースから、まとめて取得する。

いくつかの実施形態では、装置制御部１２４は、装置制御部１２４によって取得された複数のコンフィグレーション投入要求を、他のデータベースに格納する。その後に、装置制御部１２４は、他のデータベースから、特定の通信装置に対応する複数のコンフィグレーション投入要求を取得する。

いくつかの実施形態では、装置制御部１２４は、複数のコンフィグレーションの投入の複数の結果を、データベースに、まとめて追加する。

上で説明したように、集中管理サーバ１００は、リソースコントローラ１２３を含む。少なくとも１つの実施形態では、リソースコントローラ１２３は、複数の通信装置のうちのいずれかに対応する複数のコンフィグレーション投入要求が、複数の通信装置に分散しているかを判定する。複数の通信装置のうちのいずれかに対応する複数のコンフィグレーション投入要求が複数の通信装置に分散している、と判定された場合に、リソースコントローラ１２３は、複数の通信装置に割り当てられる複数のリソースのスケールアウトを行う。

いくつかの実施形態では、リソースコントローラ１２３は、複数の通信装置のうちのいずれかに対応する複数のコンフィグレーション投入要求が、複数の通信装置のうちの１つの通信装置に集中しているかを判定する。複数の通信装置のうちのいずれかに対応する複数のコンフィグレーション投入要求が１つの通信装置に集中している、と判定された場合に、リソースコントローラ１２３は、１つの通信装置に割り当てられるリソースのスケールアップを行う。

〔９．補遺〕
最後に、上記の説明を、その他の実施形態で補う。様々な実施形態を、図面を参照して上で説明してきた。これらの実施形態は、例示的であり、上記の説明は、本開示を、これらの実施形態に限定することを意図するものではない。この明細書で説明された特徴は、当業者の知識に基づく変形や改良を含む、様々な方法（ways）で実現され得る。

（各種変形）
この明細書では、いくつかの処理は、自動的に行われる処理として説明された。これらの処理の一部は、手動的に行われ得る。また、いくつかの他の処理は、手動的に行われる処理として説明された。これらの他の処理の全部または一部は、公知の方法を使って、自動的に行われ得る。

集中管理サーバ１００の様々な実装が、本明細書で説明されるか、または図面に示されている。いくつかの実装は、各種のデータ、データ処理手順、具体的名称、またはパラメータを含む情報に関する。このような実装は、特に明記しない限り、任意に変更され得る。例えば、各種のデータは、図面に示されたデータに限られない。

装置の構成要素が、図面に示されている。図示された構成要素は、装置の機能を、概念的に示すものである。構成要素は、必ずしも、図面に示されたように物理的に構成されているとは限らない。構成要素は、統合または分散されてもよく、装置の具体的形態は、図示された形態に限られない。装置の全部または一部は、各種の負荷や使用状況に応じて、機能的または物理的に統合または分散され得る。

（構成要素を表す用語）
部（module、section、-er接尾辞または-or接尾辞）という用語は、ユニット、手段、回路などに読み替えることができる。例えば、通信部（communication module）、制御部（control module）および記憶部（storage module）は、それぞれ、通信ユニット、制御ユニットおよび記憶ユニットに読み替えることができる。

（制御部の構成）
図７に示された制御部１２０の構成は、例示的であり、特定の部に関して説明されたデータ処理は、必ずしも、その特定の部によって行われなくてもよい。例えば、リソースコントローラ１２３は、装置制御部１２４に関して説明されたデータ処理を行ってもよい。また、制御部１２０は、図７に示されていないその他の部を含んでもよい。その他の部は、制御部１２０に関して説明されたデータ処理を行ってもよい。

（データ処理装置）
制御部１２０に関して説明されたデータ処理装置は、上で説明した特定のハードウェアに限定されるものはない。データ処理装置は、例えば、各種のコンピュータ、またはＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、ＧＰＧＰＵ（General Purpose Graphic Processing Unit）等の集積回路であってもよい。

１ 環境
１７ 上位システム
１８ 通信装置
１００ 集中管理サーバ
１１０ 通信部
１２０ 制御部
１２１ 対応部
１２２ 決定部
１２３ リソースコントローラ
１２４ 装置制御部
１３０ 記憶部
１３１ 管理ＤＢ
２００ ネットワーク

Claims (8)

1. 特定の通信装置に対応する複数のコンフィグレーション投入要求を取得する取得部と、
   前記複数のコンフィグレーション投入要求が、前記特定の通信装置に対応する他のコンフィグレーション投入要求と競合するか、を判定する競合判定部と、
   前記複数のコンフィグレーション投入要求が前記他のコンフィグレーション投入要求と競合しない、と判定された場合に、前記複数のコンフィグレーション投入要求に対応する複数のコンフィグレーションを、前記特定の通信装置に、まとめて投入する投入部と
   を備えるコンフィグレーション投入装置。
2. 前記取得部は、前記特定の通信装置に対応する前記複数のコンフィグレーション投入要求を、複数の通信装置のうちのいずれかに対応する複数のコンフィグレーション投入要求を記憶するデータベースから、まとめて取得する
   請求項１に記載のコンフィグレーション投入装置。
3. 前記取得部によって取得された複数のコンフィグレーション投入要求を、他のデータベースに格納する格納部
   をさらに備え、
   前記競合判定部は、前記他のデータベースから、前記特定の通信装置に対応する前記複数のコンフィグレーション投入要求を取得する
   請求項２に記載のコンフィグレーション投入装置。
4. 前記複数のコンフィグレーションの投入の複数の結果を、前記データベースに、まとめて追加する追加部
   をさらに備える請求項２に記載のコンフィグレーション投入装置。
5. 前記複数の通信装置のうちのいずれかに対応する前記複数のコンフィグレーション投入要求が、前記複数の通信装置に分散しているかを判定する分散判定部と、
   前記複数の通信装置のうちのいずれかに対応する前記複数のコンフィグレーション投入要求が前記複数の通信装置に分散している、と判定された場合に、前記複数の通信装置に割り当てられる複数のリソースのスケールアウトを行うスケールアウト部と
   をさらに備える請求項２に記載のコンフィグレーション投入装置。
6. 前記複数の通信装置のうちのいずれかに対応する前記複数のコンフィグレーション投入要求が、前記複数の通信装置のうちの１つの通信装置に集中しているかを判定する集中判定部と、
   前記複数の通信装置のうちのいずれかに対応する前記複数のコンフィグレーション投入要求が前記１つの通信装置に集中している、と判定された場合に、前記１つの通信装置に割り当てられるリソースのスケールアップを行うスケールアップ部と
   をさらに備える請求項２に記載のコンフィグレーション投入装置。
7. コンピュータが実行するコンフィグレーション投入方法であって、
   特定の通信装置に対応する複数のコンフィグレーション投入要求を取得する取得工程と、
   前記複数のコンフィグレーション投入要求が、前記特定の通信装置に対応する他のコンフィグレーション投入要求と競合するか、を判定する競合判定工程と、
   前記複数のコンフィグレーション投入要求が前記他のコンフィグレーション投入要求と競合しない、と判定された場合に、前記複数のコンフィグレーション投入要求に対応する複数のコンフィグレーションを、前記特定の通信装置に、まとめて投入する投入工程と
   を含むコンフィグレーション投入方法。
8. コンピュータを、請求項１～６のうちいずれか１つに記載のコンフィグレーション投入装置として機能させるためのコンフィグレーション投入プログラム。