知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024134730
(43)【公開日】2024-10-04
(54)【発明の名称】制御システム及びマイクロサービス処理方法
(51)【国際特許分類】
G06F 8/30 20180101AFI20240927BHJP
G06F 9/50 20060101ALI20240927BHJP
G06F 11/20 20060101ALI20240927BHJP
G06F 9/445 20180101ALI20240927BHJP
G06F 11/07 20060101ALI20240927BHJP
【ＦＩ】
G06F8/30
G06F9/50 150E
G06F11/20 620
G06F9/445 130
G06F11/07 190
G06F11/07 140A
【審査請求】未請求
【請求項の数】10
【出願形態】ＯＬ
(21)【出願番号】P 2023045074
(22)【出願日】2023-03-22
(71)【出願人】
【識別番号】000005108
【氏名又は名称】株式会社日立製作所
(74)【代理人】
【識別番号】110000925
【氏名又は名称】弁理士法人信友国際特許事務所
(72)【発明者】
【氏名】真矢 讓
(72)【発明者】
【氏名】山本 秀典
(72)【発明者】
【氏名】飯島 光一朗
(72)【発明者】
【氏名】森 駿介
(72)【発明者】
【氏名】伊藤 大輔
(72)【発明者】
【氏名】高橋 清隆
(72)【発明者】
【氏名】中島 康雄
(72)【発明者】
【氏名】高村 稔子
(72)【発明者】
【氏名】郡 伸吾
(72)【発明者】
【氏名】小川 雅昭
【テーマコード（参考）】
5B034
5B042
5B376
【Ｆターム（参考）】
5B034BB02
5B034CC01
5B042KK13
5B042MA08
5B042MA11
5B042MA14
5B042MC30
5B376AC00
5B376BC15
5B376BC16
5B376BC23
5B376BC36
5B376BC38
5B376BC80
(57)【要約】
【課題】複数のＭＳで構成された制御システムにクリティカルＭＳが存在すると、クリティカルＭＳに発生した障害が他のＭＳに影響を与えるため、対象システムからクリティカルＭＳを除く制御システムを提供する。
【解決手段】制御システム２００は、対象システムを構成するマイクロサービスごとに障害影響度を計算する障害影響度計算プログラム２３１と、障害影響度が基準値より大きいマイクロサービスをクリティカルマイクロサービスとし、予め設定されたシステム要件に従って、クリティカルマイクロサービスが無くなるまで、クリティカルマイクロサービスを分割し、又は複数のマイクロサービスを統合する分割統合処理を行うＭＳ分割／統合プログラム２３２と、を備える。
【選択図】図２
【解決手段】制御システム２００は、対象システムを構成するマイクロサービスごとに障害影響度を計算する障害影響度計算プログラム２３１と、障害影響度が基準値より大きいマイクロサービスをクリティカルマイクロサービスとし、予め設定されたシステム要件に従って、クリティカルマイクロサービスが無くなるまで、クリティカルマイクロサービスを分割し、又は複数のマイクロサービスを統合する分割統合処理を行うＭＳ分割／統合プログラム２３２と、を備える。
【選択図】図２
【特許請求の範囲】
【請求項1】
対象システムを構成するマイクロサービスごとに障害影響度を計算する計算部と、
前記障害影響度が基準値より大きい前記マイクロサービスをクリティカルマイクロサービスとし、予め設定されたシステム要件に従って、前記クリティカルマイクロサービスが無くなるまで、前記クリティカルマイクロサービスを分割し、又は複数の前記マイクロサービスを統合する分割統合処理を行う分割統合部と、を備える
制御システム。
前記障害影響度が基準値より大きい前記マイクロサービスをクリティカルマイクロサービスとし、予め設定されたシステム要件に従って、前記クリティカルマイクロサービスが無くなるまで、前記クリティカルマイクロサービスを分割し、又は複数の前記マイクロサービスを統合する分割統合処理を行う分割統合部と、を備える
制御システム。
【請求項2】
前記計算部は、障害が発生した前記マイクロサービスを他のマイクロサービスに切り替えるために要する切替時間から求めた指標、前記マイクロサービスにより提供されるサービスの重要度から求めた指標、及び前記マイクロサービスの通信に関わる通信指標から平均値、乗算値、最大値、又は最小値のいずれかにより求めた指標に基づいて、前記障害影響度を計算する
請求項１に記載の制御システム。
請求項１に記載の制御システム。
【請求項3】
前記システム要件として、リアルタイム性、可用性、及び保守性があり、
前記分割統合部は、前記リアルタイム性、前記可用性、前記保守性の順に前記システム要件を満たすように、前記分割統合処理を行う
請求項２に記載の制御システム。
前記分割統合部は、前記リアルタイム性、前記可用性、前記保守性の順に前記システム要件を満たすように、前記分割統合処理を行う
請求項２に記載の制御システム。
【請求項4】
前記リアルタイム性及び前記保守性は、前記リアルタイム性を高くすることで前記保守性が下がり、前記リアルタイム性を低くすることで前記保守性が下がるトレードオフの関係である
請求項３に記載の制御システム。
請求項３に記載の制御システム。
【請求項5】
前記分割統合部は、前記通信指標として、少なくとも通信範囲、通信頻度、及び通信形態に基づいて前記分割統合処理を行う
請求項３に記載の制御システム。
請求項３に記載の制御システム。
【請求項6】
前記分割統合部は、前記マイクロサービスが前記リアルタイム性を満たさない場合に、前記リアルタイム性を満たすように前記マイクロサービスのパラメータを最適化する
請求項３に記載の制御システム。
請求項３に記載の制御システム。
【請求項7】
前記クリティカルマイクロサービスを含む障害影響範囲を示す表示欄、及び前記システム要件の再設定が可能な入力欄を有する画面が出力され、
前記入力欄から前記システム要件の再設定が入力された後、前記分割統合処理の実行結果が出力される
請求項３に記載の制御システム。
前記入力欄から前記システム要件の再設定が入力された後、前記分割統合処理の実行結果が出力される
請求項３に記載の制御システム。
【請求項8】
前記マイクロサービスの動作を制御する制御部を備え、
前記制御部は、現用系と待機系で動作する前記クリティカルマイクロサービスのうち、現用系の前記クリティカルマイクロサービスで障害が発生したことを検出すると、前記クリティカルマイクロサービスを現用系から待機系に切り替えてサービスを継続し、現用系と待機系で動作していない前記マイクロサービスに障害の発生を検出すると、前記マイクロサービスの機能を補うマイクロサービスを新たに起動する
請求項３に記載の制御システム。
前記制御部は、現用系と待機系で動作する前記クリティカルマイクロサービスのうち、現用系の前記クリティカルマイクロサービスで障害が発生したことを検出すると、前記クリティカルマイクロサービスを現用系から待機系に切り替えてサービスを継続し、現用系と待機系で動作していない前記マイクロサービスに障害の発生を検出すると、前記マイクロサービスの機能を補うマイクロサービスを新たに起動する
請求項３に記載の制御システム。
【請求項9】
前記対象システムに前記クリティカルマイクロサービスが残る場合には、前記クリティカルマイクロサービスが多重化して構成され、現用系の前記クリティカルマイクロサービスの障害が検知されると、チェックポイントデータ転送方式、又は両系転送方式のいずれかにより、待機系の前記クリティカルマイクロサービスに切り替えてサービスが継続される
請求項４に記載の制御システム。
請求項４に記載の制御システム。
【請求項10】
対象システムを構成するマイクロサービスごとに障害影響度を計算するステップと、
前記障害影響度が基準値より大きい前記マイクロサービスをクリティカルマイクロサービスとし、予め設定されたシステム要件に従って、前記クリティカルマイクロサービスが無くなるまで、前記クリティカルマイクロサービスを分割し、又は複数の前記マイクロサービスを統合する分割統合処理を行うステップと、を含む
マイクロサービス処理方法。
前記障害影響度が基準値より大きい前記マイクロサービスをクリティカルマイクロサービスとし、予め設定されたシステム要件に従って、前記クリティカルマイクロサービスが無くなるまで、前記クリティカルマイクロサービスを分割し、又は複数の前記マイクロサービスを統合する分割統合処理を行うステップと、を含む
マイクロサービス処理方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、制御システム及びマイクロサービス処理方法に関する。
【背景技術】
【0002】
従来、制御対象の動作を制御するための制御システムは安全性が求められており、非常に大規模な構成となっていた。このような従来の制御システムをモノリスと呼ぶ。モノリスは、多数のプログラムとデータベースをリンクすることで、処理に不整合が生じないように構成されていた。ただし、モノリスとして構成された制御システムの一部で障害が発生すると、障害箇所だけを制御システムから切り離すことは困難であった。このため、制御システム全体を停止した後、障害箇所を修復し、動作確認を行った後に、制御システムの稼働が再開されていた。このような手順を経ると、制御システムの再開までに長時間を要する。
【0003】
そこで、安定性が求められる制御システムでは、プライマリとセカンダリの二重構成とされる。そして、プライマリの制御システムで障害が発生した時には、セカンダリの制御システムに一括切替される。しかし、プライマリからセカンダリの制御システムに切り替えるための切替時間が長くなっていた。また、従来の制御システムを更新する際には、制御システムの動作停止が必要となることが多く、業務に支障のない時間帯に更新するしかなかった。
【0004】
近年では、モノリス構成に変えて、制御システムが提供するサービス単位で機能を切り分け、複数のＭＳ（ＭＳ：Micro Service）を繋げて構成される制御システムが検討されつつある。ＭＳにより構成された制御システムで障害が発生した場合、その障害が発生したＭＳだけを別のＭＳに切り替えればよいので、切替時間を短縮し、システム障害の影響を抑えることができると考えられていた。また、更新が必要なＭＳだけを個別に更新することでモダナイゼーションが可能となると考えられていた。
【0005】
特許文献１には、「サービス構成情報管理部に記憶したサービス実行順序定義情報を検索して、前ログが示すサービスと入力ログが示すサービスとのサービス実行順序がサービス構成情報管理部に記憶したサービス実行順序定義情報のサービス実行順序と一致するか否かを判断してサービスの障害発生を検出する」と記載されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開２０１３－３６８１号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
ＭＳにより制御システムを構成することで、既存の制御システム（ＯＴ（Operational Technology）資産）の機能を置き換えることができる。また、汎用的な機能をＭＳで構築することで、日本だけでなく世界に制御システムを提供できると考えられる。このため、ＭＳで制御システムを構成するための支援ツールの開発が進められてきた。また、リアルタイム性が重視される制御システムを構築するために、複数のＭＳで制御システムを構築することが検討されていた。リアルタイム性とは、制御システムに入力された指示に対する応答の性能を表す指標である。
【0008】
しかし、複数のＭＳで構成された制御システムでは、あるＭＳに生じた障害が別の複数のＭＳに波及しやすくなることが判明した。このように、障害影響度が基準値より大きいＭＳを「クリティカルマイクロサービス（以下、「クリティカルＭＳ」と略称）」と呼ぶ。クリティカルＭＳに障害が発生すると、クリティカルＭＳの障害を起点として、他のＭＳに多大な影響を及ぼすことから、障害の範囲を拡大させることがあった。例えば、クリティカルＭＳに対してメッセージを送信する他のＭＳは、クリティカルＭＳがメッセージを受信できないことから、バッファオーバーフローが発生することがあった。また、クリティカルＭＳのメッセージの送信先であるＭＳは、クリティカルＭＳに対してメッセージを送っても応答メッセージを受信できないため、アイドル状態となってしまう。
【0009】
このため、マイクロサービス化された制御システムには、クリティカルＭＳが存在しないことが必要であることが分かってきたが、従来、クリティカルＭＳについて考慮されていなかった。また、特許文献１に開示された技術は、単にサービスの障害発生を検出するにすぎないため、障害が発生したＭＳがクリティカルＭＳであった場合に、他のＭＳに与える影響を排除できなかった。
【0010】
本発明はこのような状況に鑑みて成されたものであり、マイクロサービス化された対象システムからクリティカルＭＳを除くことを目的とする。
【課題を解決するための手段】
【0011】
本発明に係る制御システムは、対象システムを構成するマイクロサービスごとに障害影響度を計算する計算部と、障害影響度が基準値より大きいマイクロサービスをクリティカルマイクロサービスとし、予め設定されたシステム要件に従って、クリティカルマイクロサービスが無くなるまで、クリティカルマイクロサービスを分割し、又は複数のマイクロサービスを統合する分割統合処理を行う分割統合部と、を備える。
【発明の効果】
【0012】
本発明によれば、クリティカルマイクロサービスが無くなるまで、クリティカルマイクロサービスを分割し、又は複数のマイクロサービスを統合する分割統合処理を行うことで、マイクロサービス化された対象システムからクリティカルＭＳを除くことが可能となる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。
【図面の簡単な説明】
【0013】
【図1】本発明の一実施形態に係る対象システム及び制御システムの全体構成例を示すブロック図である。
【図2】本発明の一実施形態に係るマイクロサービス構成とした対象システムと、制御システムの詳細な内部構成例を示すブロック図である。
【図3】本発明の一実施形態に係る巨大プログラムをマイクロサービス化した後、マイクロサービスを最適化する処理の流れを示す概要図である。
【図4】本発明の一実施形態に係るＭＳ分割／統合処理の一例を示すフローチャートである。
【図5】本発明の一実施形態に係るシステム要件の構成例を示す図である。
【図6】本発明の一実施形態に係る可用性の内容を示す図である。
【図7】本発明の一実施形態に係る切替時間_度の変換テーブルの例を示す図である。
【図8】本発明の一実施形態に係る重要度_度の変換テーブルの例を示す図である。
【図9】本発明の一実施形態に係る通信_度の変換テーブルの例を示す図である。
【図10】本発明の一実施形態に係る障害影響度とクリティカルＭＳの検出判定方法の関係を示す変換テーブルの例である。
【図11】本発明の一実施形態に係るクリティカルＭＳを無くすための処理の例を示すフローチャートである。
【図12】本発明の一実施形態に係るケース１～３のクリティカルＭＳの要因の例を示す図である。
【図13】本発明の一実施形態に係るケース１の可用性の設定変更の例を示す図である。
【図14】本発明の一実施形態に係るケース２のサービス重要度の例を示す図である。
【図15】本発明の一実施形態に係るケース３の通信の例を示す図である。
【図16】本発明の一実施形態に係るトレードオフの判定処理の例を示すフローチャートである。
【図17】本発明の一実施形態に係るケース４のトレードオフの要因がリアルタイム性である場合の処理時間と障害影響度の例を示す図である。
【図18】本発明の一実施形態に係るケース５のトレードオフの要因が保守性（ＭＳサイズ）である場合の保守性と障害影響度の例を示す図である。
【図19】本発明の一実施形態に係る障害影響範囲が可視化された画面の表示例を示す図である。
【図20】本発明の一実施形態に係るチェックポイントデータ転送方式による障害検出方法の例を示す図である。
【図21】本発明の一実施形態に係る両系転送方式による障害検出方法の例を示す図である。
【発明を実施するための形態】
【0014】
以下、本発明を実施するための形態について、添付図面を参照して説明する。本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。以下に、制御対象となる対象システムを複数のＭＳで構成する場合に、ＭＳの構成を制御する制御システムに本発明を適用した例について説明する。
【0015】
［一実施形態］
図１は、本発明の一実施形態に係る対象システム１００及び制御システム２００の全体構成例を示すブロック図である。
図１は、本発明の一実施形態に係る対象システム１００及び制御システム２００の全体構成例を示すブロック図である。
【0016】
（事前処理の前）
対象システム１００は、従来のモノリス構成としたシステムであり、システム設計者１０によりマイクロサービス化される事前処理の対象となるシステムの一例である。対象システム１００として、例えば、鉄道制御システム、運行管理システム、電力制御システム、プラント制御システム、ＩＴプラットフォーム等の様々な分野における制御システムが想定される。
対象システム１００は、従来のモノリス構成としたシステムであり、システム設計者１０によりマイクロサービス化される事前処理の対象となるシステムの一例である。対象システム１００として、例えば、鉄道制御システム、運行管理システム、電力制御システム、プラント制御システム、ＩＴプラットフォーム等の様々な分野における制御システムが想定される。
【0017】
マイクロサービス化の事前処理の前には、対象システム１００の記憶管理部１１０に、従来の巨大プログラム１１１と、パラメータ１１２とが記憶される。巨大プログラム１１１は、各種のプログラムが複雑につなぎ合わされた構成である。また、巨大プログラム１１１が処理の途中で参照するパラメータ１１２が記憶管理部１１０に設けられている。このパラメータ１１２の構成も巨大かつ複雑なものである。
【0018】
（事前処理の後）
マイクロサービス化の事前処理により、巨大プログラム１１１とパラメータ１１２がマイクロサービス化される。マイクロサービス化された複数のマイクロサービス１２１（マイクロサービスMS_A～MS_F）は、それぞれパラメータ１２２を持つ。そして、マイクロサービス１２１（マイクロサービスMS_A～MS_F）は、対象システム１００の記憶管理部１２０に記憶される。
マイクロサービス化の事前処理により、巨大プログラム１１１とパラメータ１１２がマイクロサービス化される。マイクロサービス化された複数のマイクロサービス１２１（マイクロサービスMS_A～MS_F）は、それぞれパラメータ１２２を持つ。そして、マイクロサービス１２１（マイクロサービスMS_A～MS_F）は、対象システム１００の記憶管理部１２０に記憶される。
【0019】
事前処理により記憶管理部１２０に記憶されたマイクロサービス１２１（マイクロサービスMS_A～MS_F）は、最適化されておらず、クリティカルＭＳが存在する可能性がある。このため、クリティカルＭＳとなるマイクロサービス１２１に対して分割又は統合する以下の処理が行われる。なお、マイクロサービス１２１の分割又は統合の処理では、マイクロサービス１２１が持つパラメータ１２２についても適切に分割又は統合されるものとする。以下、複数のマイクロサービス１２１で構成される対象システム１００について説明する。
【0020】
制御システム２００は、従来のモノリス構成とした対象システム１００を、本実施の形態に係るマイクロサービス構成に置き換える処理を行う。このため、制御システム２００には、システム設計者１０が設定したマイクロサービス化ルール２２４が登録されている。マイクロサービス化ルール２２４には、例えば、後述する図４のフローチャートの判定処理に用いられるルールの他、システム要件３００等が含まれる。
【0021】
また、制御システム２００には、一つのＭＳを分割し、又は複数のＭＳを統合するＭＳ分割／統合プログラム２３２が登録されている。ＭＳ分割／統合プログラム２３２は、マイクロサービス化ルール２２４に従って、巨大プログラム１１１を複数のマイクロサービスに分割し、又は一つのマイクロサービスに統合することができる。
【0022】
＜対象システムと制御システムの内部構成例＞
図２は、マイクロサービス構成とした対象システム１００と、制御システム２００の詳細な内部構成例を示すブロック図である。
図２は、マイクロサービス構成とした対象システム１００と、制御システム２００の詳細な内部構成例を示すブロック図である。
【0023】
（対象システムの構成例）
対象システム１００は、記憶管理部１２０、演算部１３０、入力部１４０、出力部１５０及び通信処理部１６０を備える。図２では、記憶管理部１１０の記載は省略する。
対象システム１００は、記憶管理部１２０、演算部１３０、入力部１４０、出力部１５０及び通信処理部１６０を備える。図２では、記憶管理部１１０の記載は省略する。
【0024】
記憶管理部１２０は、図１に示した複数のマイクロサービス１２１（マイクロサービスMS_A～MS_F）を記憶し、管理する。
【0025】
演算部１３０は、制御プログラム１３１を実行可能である。制御プログラム１３１は、対象システム１００で必要とされる処理の演算を行うため、記憶管理部１２０から必要なマイクロサービス１２１を読み出して実行する制御を行ったり、入力部１４０、出力部１５０及び通信処理部１６０の動作を制御したりする。演算部１３０は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、及びＲＡＭ（Random Access Memory）により構成される。演算部１３０のＣＰＵは、本実施の形態に係る各機能を実現するソフトウェアのプログラムコードをＲＯＭから読み出してＲＡＭにロードし、実行する。演算部１３０のＲＡＭには、ＣＰＵの演算処理の途中で発生した変数やパラメータ等が一時的に書き込まれ、これらの変数やパラメータ等がＣＰＵによって適宜読み出される。
【0026】
入力部１４０には、例えば、キーボード、マウス等が用いられ、対象システム１００のユーザーが所定の操作入力、指示を行うことが可能である。
出力部１５０は、例えば、液晶ディスプレイモニターであり、演算部１３０で行われる処理の結果等を対象システム１００のユーザーに表示する。
通信処理部１６０には、例えば、ＮＩＣ（Network Interface Card）等が用いられ、ＮＩＣの端子に接続されたＬＡＮ（Local Area Network）、専用線等を介して各種のデータを制御システム２００との間で送受信することが可能である。
出力部１５０は、例えば、液晶ディスプレイモニターであり、演算部１３０で行われる処理の結果等を対象システム１００のユーザーに表示する。
通信処理部１６０には、例えば、ＮＩＣ（Network Interface Card）等が用いられ、ＮＩＣの端子に接続されたＬＡＮ（Local Area Network）、専用線等を介して各種のデータを制御システム２００との間で送受信することが可能である。
【0027】
（制御システムの構成例）
制御システム２００は、記憶管理部２２０、演算部２３０、入力部２４０、出力部２５０及び通信処理部２６０を備える。制御システム２００は、システム設計者１０が操作入力可能なＰＣ又はサーバでもよいし、クラウド上に構築されたクラウドサーバであってもよい。
制御システム２００は、記憶管理部２２０、演算部２３０、入力部２４０、出力部２５０及び通信処理部２６０を備える。制御システム２００は、システム設計者１０が操作入力可能なＰＣ又はサーバでもよいし、クラウド上に構築されたクラウドサーバであってもよい。
【0028】
演算部２３０は、障害影響度計算プログラム２３１、ＭＳ分割／統合プログラム２３２、及び制御プログラム２３３を実行可能である。演算部２３０は、例えば、ＣＰＵ、ＲＯＭ、及びＲＡＭにより構成される。演算部２３０のＣＰＵは、本実施の形態に係る各機能を実現するソフトウェアのプログラムコードをＲＯＭから読み出してＲＡＭにロードし、実行する。演算部２３０のＲＡＭには、ＣＰＵの演算処理の途中で発生した変数やパラメータ等が一時的に書き込まれ、これらの変数やパラメータ等がＣＰＵによって適宜読み出される。演算部２３０の各プログラムは、記憶管理部２２０からパラメータ２２１、要件データ２２２、障害影響度データ２２３、及びマイクロサービス化ルール２２４を読み出して、本実施の形態に係るマイクロサービスの最適化処理を行う。この最適化処理は、演算部２３０がシステム要件３００に従ってマイクロサービスの分割統合処理を行うこと、でクリティカルＭＳを除く処理である。
【0029】
障害影響度計算プログラム２３１（計算部の一例）は、対象システム１００を構成するマイクロサービスごとに障害影響度を計算する。障害影響度は、マイクロサービスに障害が発生した時に、他のマイクロサービスに影響を与える指標である。障害影響度が基準値より大きいマイクロサービスがクリティカルＭＳとして検出される。障害影響度計算プログラム２３１は、例えば、３要素（切替時間、サービス重要度、通信指標）を用いて、障害影響度を計算する。この３要素は、例えば、障害が発生したマイクロサービスを他のマイクロサービスに切り替えるために要する切替時間、マイクロサービスにより提供されるサービスの重要度、及びマイクロサービスの通信に関わる通信指標である。障害影響度計算プログラム２３１は、切替時間から求めた指標（切替時間_度）、サービスの重要度から求めた指標（サービス重要度_度）、及び通信指標から平均値、乗算値、最大値、又は最小値のいずれかにより求めた指標（通信_度）に基づいて、障害影響度を計算する。
【0030】
切替時間とは、マイクロサービスの障害時に、他のマイクロサービスに切り替えるために要する時間である。例えば、新たに立ち上げた別のサーバ又は情報処理装置に対して、新たにマイクロサービスを引き継ぐことを「切り替え」と呼ぶ。切替時間が長いほど、障害影響度に与える影響が大きくなる。
【0031】
サービス重要度とは、サービスの重要性を表す。例えば、サービス重要度が高程度であれば、そのサービスを提供するマイクロサービスに障害が検出されると、サービスに与える影響が大きくなる。また、サービス重要度が中程度であれば、サービスにおける実際の処理の内容に応じて、サービス重要度が変わる。例えば、サービスが周期起動する場合に、秒オーダのサービスは、分オーダのサービスよりもサービス重要度が高い。また、対象システム１００では、周期的に発生しない処理、すなわち不定期に発生する処理があり、この処理をイベントと呼ぶ。イベントの発生時に起動するサービスは、分オーダのサービスよりもサービス重要度が低い。なお、サービスの内容が診断処理であれば、手動で処理開始が指示されるか、又は他のサービスの停止中に処理が開始されるため、他のサービスへの影響が小さい。このため、サービスの内容が診断処理である場合に、このサービスのサービス重要度が最も低くなる。
【0032】
通信指標とは、あるマイクロサービスが他のマイクロサービスとの通信に際して用いられる要素であり、例えば、通信範囲、通信形態、及び通信頻度から決定される。通信範囲は、例えば、通信MS数/全MS数、イベント数により求められる値であり、あるマイクロサービスに接続される他のマイクロサービスの数等を表す。通信形態は、同期又は非同期により決定される。同期の方が非同期よりもサービスに与える影響が大きい。また、通信頻度は、例えば、１秒間当たりの通信回数として表され、通信頻度が高いほど、サービスに与える影響が大きい。以下の説明では、通信指標を「通信」と呼ぶことがある。
【0033】
マイクロサービスに発生する障害の影響は、障害影響度（Ｅ）として、(切替時間_度) * (サービス重要度_度) * (通信_度)の式を用いて計算される。以下の説明で「_度」を付加した要素の値は０から１の範囲で正規化した値とする。障害影響度計算プログラム２３１が計算した障害影響度は、記憶管理部２２０に障害影響度データ２２３として保存される。
【0034】
ＭＳ分割／統合プログラム２３２（分割統合部の一例）は、予め設定されたシステム要件３００（後述する図５を参照）に従って、クリティカルＭＳが無くなるまで、クリティカルＭＳを分割し、又は複数のマイクロサービスを統合する分割統合処理を行う。例えば、ＭＳ分割／統合プログラム２３２は、記憶管理部２２０から読み出したマイクロサービス化ルール２２４に基づいて、図１に示した対象システム１００のマイクロサービス１２１をさらに分割したり、複数のマイクロサービス１２１を統合して、一つのマイクロサービスを生成したりする分割統合処理を行う。ＭＳ分割／統合プログラム２３２が複数のマイクロサービス１２１を統合すると、マイクロサービスを削減することができ、マイクロサービスの保守性を向上させることが可能となる。このため、ＭＳ分割／統合プログラム２３２は、クリティカルＭＳを検出した場合に、以下の（１）クリティカルＭＳの分割又は統合（プログラム分割）の処理と、（２）パラメータ再設定（設定ファイル）の処理を行う。
【0035】
（１）クリティカルＭＳの分割又は統合の処理（「ＭＳ分割／統合」と称する。）
・分割：通信に対する影響が大きい場合に、ＭＳを分割する処理。
・統合：リアルタイム性に影響が大きいＭＳを分割したことでリアルタイム性が低下した場合、リアルタイム性を満たすようにＭＳを統合する処理
（２）パラメータの再設定の処理
・再設定されるパラメータの項目
バッファサイズ、タイムアウト時間、リトライ回数
外付けディスクの読み取り
・その他
・分割：通信に対する影響が大きい場合に、ＭＳを分割する処理。
・統合：リアルタイム性に影響が大きいＭＳを分割したことでリアルタイム性が低下した場合、リアルタイム性を満たすようにＭＳを統合する処理
（２）パラメータの再設定の処理
・再設定されるパラメータの項目
バッファサイズ、タイムアウト時間、リトライ回数
外付けディスクの読み取り
・その他
【0036】
なお、対象システム１００が提供可能なサービスは、複数のマイクロサービスを組み合わせて構築される。そして、マイクロサービスは、複数のプログラムから構成される。このため、ＭＳの分割／統合の処理は、サービス単位ではなく、プログラム単位で分割又は統合されるものとなる。
【0037】
制御プログラム２３３は、対象システム１００で必要とされる処理の演算を行うため、記憶管理部２２０から必要なデータを読み出して、マイクロサービスの動作を制御する。また、制御プログラム２３３は、入力部２４０、出力部２５０及び通信処理部２６０の動作を制御する。
【0038】
記憶管理部２２０は、パラメータ２２１、要件データ２２２、障害影響度データ２２３及びマイクロサービス化ルール２２４を記憶し、管理する。
【0039】
パラメータ２２１には、障害検出時間、リトライ時間、及びリトライ回数が含まれる。
【0040】
要件データ２２２には、可用性データ、ＲＴ（Real Time）性データ（以下、ＲＴ性データと略称する）、及び保守性データが含まれる。
【0041】
入力部２４０には、例えば、キーボード、マウス等が用いられ、システム設計者１０が所定の操作入力、指示を行うことが可能である。
出力部２５０は、例えば、液晶ディスプレイモニターであり、演算部２３０で行われる処理の結果等をシステム設計者１０に表示する。
通信処理部２６０には、例えば、ＮＩＣ等が用いられ、ＮＩＣの端子に接続されたＬＡＮ、専用線等を介して各種のデータを対象システム１００との間で送受信することが可能である。
出力部２５０は、例えば、液晶ディスプレイモニターであり、演算部２３０で行われる処理の結果等をシステム設計者１０に表示する。
通信処理部２６０には、例えば、ＮＩＣ等が用いられ、ＮＩＣの端子に接続されたＬＡＮ、専用線等を介して各種のデータを対象システム１００との間で送受信することが可能である。
【0042】
図３は、巨大プログラム１１１をマイクロサービス化した後、マイクロサービスを最適化する処理の流れを示す概要図である。図中に矢印と番号を付して、処理の流れを説明する。
【0043】
（１）事前のＭＳ分割処理
対象システム１００は、本実施の形態に係るＭＳ分割／統合処理の前に、事前のＭＳ分割処理が行われる。この際、記憶管理部１１０に記憶されたモノリス構成の巨大プログラム１１１が、記憶管理部１２０に複数のマイクロサービスとして分割され、保存される。このＭＳ分割処理は、システム設計者１０が巨大プログラム１１１を大まかに分割する処理であり、詳細な要件は不要である。
対象システム１００は、本実施の形態に係るＭＳ分割／統合処理の前に、事前のＭＳ分割処理が行われる。この際、記憶管理部１１０に記憶されたモノリス構成の巨大プログラム１１１が、記憶管理部１２０に複数のマイクロサービスとして分割され、保存される。このＭＳ分割処理は、システム設計者１０が巨大プログラム１１１を大まかに分割する処理であり、詳細な要件は不要である。
【0044】
（２）システム要件の設定
次に、システム設計者１０は、図１に示したマイクロサービス化ルール２２４として、システム要件３００を記憶管理部２２０に設定する。システム要件３００として、例えば、可用性３１０、ＭＳのリアルタイム性３２０、保守性３３０がある。可用性３１０、ＭＳのリアルタイム性３２０、保守性３３０は、いずれもマイクロサービスごとに設定される要件である。
次に、システム設計者１０は、図１に示したマイクロサービス化ルール２２４として、システム要件３００を記憶管理部２２０に設定する。システム要件３００として、例えば、可用性３１０、ＭＳのリアルタイム性３２０、保守性３３０がある。可用性３１０、ＭＳのリアルタイム性３２０、保守性３３０は、いずれもマイクロサービスごとに設定される要件である。
【0045】
（３）ＭＳの分割／統合
制御システム２００の障害影響度計算プログラム２３１は、マイクロサービスの障害影響度を計算する。ＭＳ分割／統合プログラム２３２は、マイクロサービス化ルール２２４に基づいて、記憶管理部１２０に記憶されているマイクロサービス１２１の分割又は統合を行う。制御システム２００は、マイクロサービス化の処理を自動的に行うことができるが、システム設計者１０と対話式で処理の実行を指示し、処理の実行結果を確認できる形態としてもよい。
制御システム２００の障害影響度計算プログラム２３１は、マイクロサービスの障害影響度を計算する。ＭＳ分割／統合プログラム２３２は、マイクロサービス化ルール２２４に基づいて、記憶管理部１２０に記憶されているマイクロサービス１２１の分割又は統合を行う。制御システム２００は、マイクロサービス化の処理を自動的に行うことができるが、システム設計者１０と対話式で処理の実行を指示し、処理の実行結果を確認できる形態としてもよい。
【0046】
（４）対象システム１００から制御システム２００への分割結果の受信
ＭＳ分割／統合プログラム２３２は、対象システム１００からマイクロサービス１２１の分割結果を受信する。分割結果には、マイクロサービス化の結果と、マイクロサービスの要件とが含まれる。
ＭＳ分割／統合プログラム２３２は、対象システム１００からマイクロサービス１２１の分割結果を受信する。分割結果には、マイクロサービス化の結果と、マイクロサービスの要件とが含まれる。
【0047】
（５）制御システム２００が受信した分割結果の確認
システム設計者１０は、制御システム２００が受信した分割結果を確認する。
システム設計者１０は、制御システム２００が受信した分割結果を確認する。
【0048】
（６）システム要件３００の再設定
分割結果が、最適解があることを示す場合、以降の処理は不要である。最適解があるとは、分割統合処理の結果、クリティカルＭＳが無くなり、全てのマイクロサービスがシステム要件３００を満たすことである。このため、システム設計者１０は、分割結果であるマイクロサービス１２１がシステム要件３００を満たしていれば、処理を終了する。一方、分割結果が、最適解がないことを示す場合、システム設計者１０は、システム要件３００を設定し直し、制御プログラム２３３にシステム要件３００を再設定したことを通知する。
分割結果が、最適解があることを示す場合、以降の処理は不要である。最適解があるとは、分割統合処理の結果、クリティカルＭＳが無くなり、全てのマイクロサービスがシステム要件３００を満たすことである。このため、システム設計者１０は、分割結果であるマイクロサービス１２１がシステム要件３００を満たしていれば、処理を終了する。一方、分割結果が、最適解がないことを示す場合、システム設計者１０は、システム要件３００を設定し直し、制御プログラム２３３にシステム要件３００を再設定したことを通知する。
【0049】
（７）ＭＳの分割／統合の再指示
システム設計者１０は、設定し直したシステム要件３００により、再びＭＳの分割／統合を制御システム２００に行わせる指示を入力する。その後、上述した処理（３）～（５）が再び実行される。
システム設計者１０は、設定し直したシステム要件３００により、再びＭＳの分割／統合を制御システム２００に行わせる指示を入力する。その後、上述した処理（３）～（５）が再び実行される。
【0050】
ここで、処理（３）で障害影響度計算プログラム２３１により計算される障害影響度（Ｅ）について説明する。障害影響度(Ｅ)は、マイクロサービスに発生する障害の影響が他のマイクロサービスにどのように影響するかを示す指標であり、以下に示す式（１）の切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、及び通信_度Ｅ(cm)により定義される。障害影響度が基準値（Ｃ）より大きければ、クリティカルＭＳと判定される。
【0051】
E = E(to) * E(pr) * E(cm) …（１）
【0052】
障害の影響は、掛け算、最大値のいずれかを用いて判断される。障害影響度(Ｅ)、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、又は通信_度Ｅ(cm)のうち、どれか一つでも重要であれば、障害影響度(Ｅ)は大きいものとする。
0 ≦ E ≦ 1
0 ≦ E(to), E(pr), E(cm) ≦ 1
0 ≦ E ≦ 1
0 ≦ E(to), E(pr), E(cm) ≦ 1
【0053】
切替時間_度Ｅ(to)
0 ≦ (切替時間_度) ≦ 1となるように、後述する変換テーブルを用いて変換される。切替時間_度Ｅ(to)は、例えば、障害検出時間、メッセージ再送時間、リトライ時間、リトライ回数、又はハードディスク読出し時間(共有データ読出し)により決定される。切替時間が長くなると、障害の影響範囲は拡大することになる。
0 ≦ (切替時間_度) ≦ 1となるように、後述する変換テーブルを用いて変換される。切替時間_度Ｅ(to)は、例えば、障害検出時間、メッセージ再送時間、リトライ時間、リトライ回数、又はハードディスク読出し時間(共有データ読出し)により決定される。切替時間が長くなると、障害の影響範囲は拡大することになる。
【0054】
・重要度_度Ｅ(pr)
0 ≦ (サービス重要度_度) ≦ 1となるように、変換テーブルを用いて変換される。サービス重要度は、業務の役割に基づいて決定される。重要なサービスが障害になると、障害の影響範囲は拡大する。
0 ≦ (サービス重要度_度) ≦ 1となるように、変換テーブルを用いて変換される。サービス重要度は、業務の役割に基づいて決定される。重要なサービスが障害になると、障害の影響範囲は拡大する。
【0055】
・通信_度Ｅ(cm)
0 ≦ (通信_度) ≦ 1となるように、変換テーブルを用いて変換される。通信_度は、例えば、受信MS数/全MS数、送信MS数/全MS数、通信対象のMS数/全MS数、通信頻度、通信範囲、通信形態（同期/非同期）、又はイベント種類等に基づいて変換される。
0 ≦ (通信_度) ≦ 1となるように、変換テーブルを用いて変換される。通信_度は、例えば、受信MS数/全MS数、送信MS数/全MS数、通信対象のMS数/全MS数、通信頻度、通信範囲、通信形態（同期/非同期）、又はイベント種類等に基づいて変換される。
【0056】
図４は、ＭＳ分割／統合処理の一例を示すフローチャートである。図４に示すＭＳ分割／統合処理は、対象システム１００をマイクロサービスに分割する時のシステム設計時に行われるマイクロサービス処理方法の一例を示す。
【0057】
始めに、システム設計者１０は、本処理を開始する前にモノリス構成の巨大プログラム１１１を、マイクロサービスに分割しておく（Ｓ１）。ここで、システム設計者１０は、机上計算、あるいは簡単にツールを動作させて、巨大プログラム１１１を、マイクロサービスに分割する（Ｓ１Ａ）。次に、制御システム２００の障害影響度計算プログラム２３１は、障害影響度を計算する（Ｓ２）。
【0058】
以下に説明する処理は、クリティカルＭＳを無くす処理４００と、リアルタイム性と保守性（ＭＳサイズ）のトレードオフの判定処理４１０に大別される。
処理４００において、ＭＳ分割／統合プログラム２３２は、ステップＳ１で分割されたマイクロサービスにクリティカルＭＳを検出したか否かを判定する（Ｓ３）。クリティカルＭＳを検出したと判定した場合（Ｓ３のＹＥＳ）、ＭＳ分割／統合プログラム２３２は、クリティカルＭＳを分割し、又は統合する（Ｓ４）。
処理４００において、ＭＳ分割／統合プログラム２３２は、ステップＳ１で分割されたマイクロサービスにクリティカルＭＳを検出したか否かを判定する（Ｓ３）。クリティカルＭＳを検出したと判定した場合（Ｓ３のＹＥＳ）、ＭＳ分割／統合プログラム２３２は、クリティカルＭＳを分割し、又は統合する（Ｓ４）。
【0059】
また、ＭＳ分割／統合プログラム２３２は、ステップＳ４にて分割し、又は統合したマイクロサービスに対して、アルゴリズムに従ってパラメータを設定する（Ｓ５）。その後、再びステップＳ２に移り、障害影響度計算プログラム２３１は、障害影響度を計算し（Ｓ２）、クリティカルＭＳを検出しなくなるまで処理を繰り返す。
【0060】
ステップＳ３の処理でクリティカルＭＳを検出しないと判定した場合（Ｓ３のＮＯ）、ＭＳ分割／統合プログラム２３２は、マイクロサービスのリアルタイム性とＭＳサイズを評価する（Ｓ６）。そして、ＭＳ分割／統合プログラム２３２は、マイクロサービスのリアルタイム性とＭＳサイズがいずれもＯＫであるか否かを判定する（Ｓ７）。ステップＳ７では、リアルタイム性とＭＳサイズのいずれか一つでもＯＫではない場合、マイクロサービスが最適ＭＳではないと評価される。なお、リアルタイム性及び保守性（ＭＳサイズ）は、リアルタイム性を高くすることで保守性が下がり、リアルタイム性を低くすることで保守性が下がるトレードオフの関係である。
【0061】
リアルタイム性とＭＳサイズがいずれもＯＫではないと判定した場合（Ｓ７のＮＧ）、ＭＳ分割／統合プログラム２３２は、マイクロサービスを分割し、又は統合する（Ｓ８）。また、ＭＳ分割／統合プログラム２３２は、分割し、又は統合したマイクロサービスにパラメータを設定する（Ｓ９）。その後、再びステップＳ２に移り、障害影響度計算プログラム２３１は、障害影響度を計算し（Ｓ２）、処理を繰り返す。
【0062】
ステップＳ７の処理を所定の回数行ったにも関わらず、リアルタイム性とＭＳサイズがいずれもＯＫではないと判定した場合、最適なＭＳが見つかっていない。このため、ＭＳ分割／統合プログラム２３２は、システム設計者１０に警告を通知する（Ｓ１０）。警告が通知されたシステム設計者１０は、システム要件３００（図３を参照）を手動で再設定し、本処理を再び実行させる（Ｓ１１）。例えば、システム設計者１０が、ＭＳサイズが大きくなってもリアルタイム性を優先させたい場合には、ＭＳサイズの要件を緩和する設定が想定される。
【0063】
ステップＳ７の処理でリアルタイム性とＭＳサイズがいずれもＯＫであると判定した場合（Ｓ７のＯＫ）、ＭＳ分割／統合プログラム２３２は、本処理を終了する。
【0064】
＜システム要件の説明＞
次に、システム要件３００の詳細な内容を説明する。
次に、システム要件３００の詳細な内容を説明する。
【0065】
図５は、システム要件３００の構成例を示す図である。
システム要件３００は、性能分類、性能項目、値、内容の各項目で構成される。
図３に示したように、システム要件３００の性能分類は、可用性３１０、リアルタイム性３２０、保守性３３０に分けられる。ＭＳ分割／統合プログラム２３２は、リアルタイム性、可用性、保守性の順にシステム要件３００を満たすように、分割統合処理を行う。
システム要件３００は、性能分類、性能項目、値、内容の各項目で構成される。
図３に示したように、システム要件３００の性能分類は、可用性３１０、リアルタイム性３２０、保守性３３０に分けられる。ＭＳ分割／統合プログラム２３２は、リアルタイム性、可用性、保守性の順にシステム要件３００を満たすように、分割統合処理を行う。
【0066】
可用性３１０では、性能項目は「切替時間」であり、切替時間の値は、例えば５秒であり、可用性３１０の内容は、「ＭＳの切替時間」である。つまり、障害が起きたＭＳが、正常なＭＳに切り替わるまでの切り替え時間が可用性３１０に定義されている。
【0067】
リアルタイム性３２０では、性能項目は「実行時間」であり、実行時間の値は、例えば１２ミリ秒であり、リアルタイム性３２０の内容は、「ミッションクリティカルなサービスの実行時間」である。つまり、リアルタイム性が要求されるＭＳは、実行時間の範囲内で処理が完了することが求められる。
【0068】
保守性３３０では、性能項目は「ＭＳサイズ」であり、ＭＳサイズの値は、例えば５kstepであり、保守性３３０の内容は、「ＭＳサイズ」である。つまり、ＭＳサイズが大きくなるほど保守性が低下するので、ＭＳサイズが５kstep未満となるまで分割し、又は統合することが求められる。
【0069】
上述したように、可用性３１０、リアルタイム性３２０、及び保守性３３０により計算される障害影響度（Ｅ）が基準値Ｃより大きいと、マイクロサービスがクリティカルＭＳであることを表す。このため、ＭＳ分割／統合プログラム２３２は、障害影響度の値を小さくするように分割統合処理を繰り返すことで、クリティカルＭＳを無くすことができる。
【0070】
図６は、可用性３１０の内容を示す図である。
可用性３１０は、性能分類、パラメータ、及び値の各項目で構成される。
可用性３１０は、性能分類、パラメータ、及び値の各項目で構成される。
【0071】
可用性３１０のパラメータとして、aliveメッセージ、リトライ時間、リトライ回数がある。aliveメッセージは、他のマイクロサービスが正常であるかを確認するために、一定周期で発行されるメッセージである。
【0072】
リトライは、マイクロサービスの処理が異常終了などした場合に、同じ処理の実行をもう一度試みることである。例えば、マイクロサービスがaliveメッセージを送信できない時に、一定時間後に再びaliveメッセージの送信を試みる処理が行われる。
リトライ時間は、例えば、マイクロサービスがaliveメッセージの送信可否を判断する時間である。他のマイクロサービスに送信したaliveメッセージの応答をリトライ時間内に受信できなければ、リトライが行われる。
リトライ回数は、マイクロサービスがリトライを行う回数である。例えば、aliveメッセージは３秒、リトライ時間は２秒、リトライ回数は２回とされる。
図６に示した値では、障害検出時間が、３秒＋２秒×２回＝７秒間と算出される。
リトライ時間は、例えば、マイクロサービスがaliveメッセージの送信可否を判断する時間である。他のマイクロサービスに送信したaliveメッセージの応答をリトライ時間内に受信できなければ、リトライが行われる。
リトライ回数は、マイクロサービスがリトライを行う回数である。例えば、aliveメッセージは３秒、リトライ時間は２秒、リトライ回数は２回とされる。
図６に示した値では、障害検出時間が、３秒＋２秒×２回＝７秒間と算出される。
【0073】
【0074】
図７は、切替時間_度の変換テーブルの例を示す図である。
切替時間_度の変換テーブルは、マイクロサービス（ＭＳ）、切替時間、及び切替時間_度の各項目で構成される。上述したように切替時間_度は、0 ≦ (切替時間_度) ≦ 1の範囲でマイクロサービスごとに設定される。
切替時間_度の変換テーブルは、マイクロサービス（ＭＳ）、切替時間、及び切替時間_度の各項目で構成される。上述したように切替時間_度は、0 ≦ (切替時間_度) ≦ 1の範囲でマイクロサービスごとに設定される。
【0075】
例えば、マイクロサービスMS_Aの切替時間が１秒以下である場合、切替時間_度は「0.9」である。また、マイクロサービスMS_Bの切替時間が１秒～３秒以下である場合、切替時間_度は「0.7」である。
【0076】
図８は、重要度_度の変換テーブルの例を示す図である。
重要度_度の変換テーブルは、サービス、サービス重要度、及びマイクロサービスの各項目で構成される。上述したように重要度_度は、0 ≦ (サービス重要度_度) ≦ 1の範囲でマイクロサービスごとに設定される。
重要度_度の変換テーブルは、サービス、サービス重要度、及びマイクロサービスの各項目で構成される。上述したように重要度_度は、0 ≦ (サービス重要度_度) ≦ 1の範囲でマイクロサービスごとに設定される。
【0077】
サービス項目には、サービス_A～サービス_Dが格納される。
サービス重要度項目には、サービス_A～サービス_Dごとのサービス重要度が格納される。
マイクロサービス項目には、サービス_A～サービス_Dを構成するマイクロサービスが丸印で表される。
サービス重要度項目には、サービス_A～サービス_Dごとのサービス重要度が格納される。
マイクロサービス項目には、サービス_A～サービス_Dを構成するマイクロサービスが丸印で表される。
【0078】
例えば、サービス_Aのサービス重要度は0.9であり、マイクロサービスMS_A、MS_B及びMS_Fで構成される。サービス_Bのサービス重要度は0.9で、マイクロサービスMS_B及びMS_Cで構成される。サービス_Cのサービス重要度は0.5で、マイクロサービスMS_A、MS_C、MS_D及びMS_Fで構成される。
【0079】
そして、重要度_度の変換テーブルを用いることで、サービス重要度からマイクロサービス重要度（平均値）を算出することができる。例えば、マイクロサービスMS_Aの重要度は(0.9+0.5)/2= 0.7、マイクロサービスMS_Bの重要度は(0.9+0.9)/2=0.9と算出される。同様に、マイクロサービスMS_C～MS_Fの重要度が算出される。
【0080】
図９は、通信_度の変換テーブルの例を示す図である。
通信_度の変換テーブルは、通信範囲（Com_R）、通信頻度（Com_F）、通信形態（Com_T）、通信_度平均値の各項目で構成される。上述したように通信_度は、0 ≦ (通信_度) ≦ 1の範囲で設定される。
通信_度の変換テーブルは、通信範囲（Com_R）、通信頻度（Com_F）、通信形態（Com_T）、通信_度平均値の各項目で構成される。上述したように通信_度は、0 ≦ (通信_度) ≦ 1の範囲で設定される。
【0081】
通信範囲（Com_R）は、通信MS数/全MS数で表される。例えば、通信範囲は、0～1%以下であれば「0.2」、1～20%以下であれば「0.4」のように算出される。
通信頻度（Com_F）は、１秒当たりの送受信回数で算出される。例えば、通信頻度は、0～1回以下であれば「0.2」、1～30回以下であれば「0.4」のように算出される。
通信形態（Com_T）は、同期又は非同期で表される。例えば、同期であれば、「0.3」、非同期であれば「0.7」のように算出される。
通信頻度（Com_F）は、１秒当たりの送受信回数で算出される。例えば、通信頻度は、0～1回以下であれば「0.2」、1～30回以下であれば「0.4」のように算出される。
通信形態（Com_T）は、同期又は非同期で表される。例えば、同期であれば、「0.3」、非同期であれば「0.7」のように算出される。
【0082】
通信_度平均値は、{(Com_R)+(Com_F)+(Com_T)}/3の式で算出される。例えば、通信範囲（Com_R）が0～1%以下であり、通信頻度（Com_F）が0～1回以下であり、通信形態（Com_T）が同期であれば、通信_度平均値は「0.23」と算出される。
【0083】
図１０は、障害影響度とクリティカルＭＳの検出判定方法の関係を示す変換テーブルの例である。
このテーブルは、ＭＳ、障害影響度、クリティカルＭＳの検出判定、可用性、重要度、及び通信項目の各項目で構成される。
このテーブルは、ＭＳ、障害影響度、クリティカルＭＳの検出判定、可用性、重要度、及び通信項目の各項目で構成される。
【0084】
ＭＳ項目には、マイクロサービスMS_A～MS_Fが格納される。このため、マイクロサービスごとに各項目の値が求められる。
障害影響度の項目には、マイクロサービスごとに算出された、障害影響度(Ｅ)、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、及び通信_度Ｅ(cm)の値が格納される。
障害影響度の項目には、マイクロサービスごとに算出された、障害影響度(Ｅ)、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、及び通信_度Ｅ(cm)の値が格納される。
【0085】
クリティカルＭＳの検出判定項目には、クリティカルＭＳの検出判定結果が格納される。マイクロサービスの障害影響度（Ｅ）が基準値（Ｃ）より大きい場合に、このマイクロサービスがクリティカルＭＳであると判定される。クリティカルＭＳであると判定されたマイクロサービスには丸印が格納され、クリティカルＭＳでないと判定されたマイクロサービスにはバツ印が格納される。例えば、マイクロサービスMS_AからMS_CはクリティカルＭＳと判定されている。
【0086】
可用性、重要度、及び通信項目には、クリティカルＭＳと判定されたマイクロサービスのうち、要件を満たしていない項目にバツ印が格納される。図１０では、MS_AからMS_CはクリティカルＭＳと判定されており、マイクロサービスMS_Aは可用性の要件を満たしていない。マイクロサービスMS_Bはサービス重要度の要件を満たしていない。また、マイクロサービスMS_Cは通信の要件を満たしていない。
【0087】
一方、マイクロサービスMS_D～MS_FはクリティカルＭＳではない。ただし、マイクロサービスMS_DとMS_Eは、後述する図１６にケース４として説明するようにリアルタイム性を満たしていないものとする。また、サービス４を考慮してMS_Fは後述する図１６にケース５として説明するようにＭＳサイズが大きいため、保守性を満たしていないものとする。なお、リアルタイム性は、マイクロサービスではなく、サービスの種類で判定される。このため、一つのマイクロサービスでリアルタイム性を満たしても、複数のマイクロサービスで構成されるサービスでリアルタイム性を満たさないことがある。
【0088】
図９に示した通信_度の変換テーブルの右側には、通信範囲（Com_R）、通信頻度（Com_F）及び通信形態（Com_T）の平均値が格納され、図１０に示した変換テーブルの障害影響度は、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、及び通信_度Ｅ(cm)の乗算値が格納された。しかし、これらの値は、平均をとる他、最大値をとる、又は最小値をとるなど様々な計算式により計算されてもよい。
【0089】
次に、図２に示した制御システム２００の演算部２３０で行われる処理について説明する。
図１１は、クリティカルＭＳを無くすための処理の例を示すフローチャートである。ここでは、障害影響度計算プログラム２３１がクリティカルＭＳの障害影響度（Ｅ）を計算した結果に基づいて、クリティカルＭＳを無くす処理が行われる。
図１１は、クリティカルＭＳを無くすための処理の例を示すフローチャートである。ここでは、障害影響度計算プログラム２３１がクリティカルＭＳの障害影響度（Ｅ）を計算した結果に基づいて、クリティカルＭＳを無くす処理が行われる。
【0090】
図１１に示す処理の前に予め、図４に示したステップＳ１により、巨大プログラム１１１が６つのマイクロサービス（MS_A, MS_B, MS_C, MS_D, MS_E, MS_F）に分割されたものとする。
【0091】
次に、図４に示したステップＳ２により、障害影響度計算プログラム２３１は、６つのマイクロサービス（MS_A, MS_B, MS_C, MS_D, MS_E, MS_F）の障害影響度を計算し、図４に示したステップＳ３により、マイクロサービスMS_A, MS_B, MS_CがクリティカルＭＳであると検出されたものとする。図１１に示す処理は、図４に示したステップＳ３により、複数のマイクロサービスにクリティカルＭＳが有ると検出された後に行われる処理である。
【0092】
この処理において、障害影響度計算プログラム２３１は、クリティカルＭＳの要因を判定する。例えば、障害影響度計算プログラム２３１は、クリティカルＭＳの要因が切替時間であるか否かを判定する（Ｓ２１）。クリティカルＭＳの要因が切替時間であるか否かは、例えば、パラメータであれば、タイムアウト、リトライ間隔、リトライ回数が判定基準となり、チェックポイントデータであれば、ＭＳサイズ、読み出し時間が判定基準となる。チェックポイントデータとは、マイクロサービスで障害が発生し、他のマイクロサービスに引き継ぐために必要なデータである。
【0093】
マイクロサービスの分割又は統合が行われても、パラメータ（タイムアウト、リトライ間隔、リトライ回数）は変わらない。一方、マイクロサービスが分割されると、チェックポイントデータのサイズが小さくなるので、チェックポイントデータの読み出し時間も減少する。逆に、複数のマイクロサービスが統合されると、チェックポイントデータのサイズが大きくなるので、チェックポイントデータの読み出し時間は増加する。
【0094】
クリティカルＭＳの要因が可用性の判定項目の一つである切替時間であれば（Ｓ２１のＹＥＳ：ケース１）、障害影響度計算プログラム２３１は、マイクロサービスMS_Aのパラメータを再設定する（Ｓ２２）。
【0095】
次に、障害影響度計算プログラム２３１は、障害影響度を計算し（Ｓ２３）、障害影響度が基準値を満たす、すなわち障害影響度（Ｅ）が基準値（Ｃ）より大きいか否かを判定する（Ｓ２４）。障害影響度が基準値を満たさなければ（Ｓ２４のＮＯ）、障害影響度計算プログラム２３１は、再びステップＳ２１に戻って処理を繰り返す。障害影響度が基準値を満たせば（Ｓ２４のＹＥＳ）、障害影響度計算プログラム２３１は、本処理を終了する。
【0096】
ステップＳ２１にて、クリティカルＭＳの要因が切替時間でなければ（Ｓ２１のＮＯ）、障害影響度計算プログラム２３１は、クリティカルＭＳの要因が通信であるか否かを判定する（Ｓ２５）。クリティカルＭＳの要因が通信であるか否かは、例えば、通信範囲（通信MS数/全MS数）、通信頻度（通信数/秒）、又は通信形態（同期、非同期）が判定基準となる。
【0097】
クリティカルＭＳの要因が通信であれば（Ｓ２５のＹＥＳ：ケース３）、ＭＳ分割／統合プログラム２３２がマイクロサービスを分割する。この時、ＭＳ分割／統合プログラム２３２は、通信指標として、少なくとも通信範囲、通信頻度、及び通信形態に基づいて分割統合処理を行う。
【0098】
次に、障害影響度計算プログラム２３１は、送信側のマイクロサービスと受信側のマイクロサービスの通信を考慮して（Ｓ２６）、障害影響度を算出する（Ｓ２３）。例えば、ＭＳ分割／統合プログラム２３２がクリティカルＭＳであるマイクロサービスMS_Cを、マイクロサービスMS_C1とMS_C2に分割する。次に、障害影響度計算プログラム２３１がマイクロサービスMS-C1とMS-C2の障害影響度を算出し、それぞれの障害影響度（Ｅ）が基準値（Ｃ）以下となって、基準値を満たすか否かを判定する（Ｓ２４）。
【0099】
ステップＳ２５にて、クリティカルＭＳの要因が通信でなければ（Ｓ２５のＮＯ：ケース２）、障害影響度計算プログラム２３１は、「クリティカルＭＳの要因がサービス重要度」であることをシステム設計者１０に通知し（Ｓ２７）、本処理を終了する。
【0100】
サービス重要度は固定値として変更できない項目である。サービス重要度が高いマイクロサービスは、一般的に切替時間が短く、かつ通信範囲が広い。そこで、マイクロサービスのサービス重要度が高い場合は、切替時間や通信範囲を考慮して分割統合処理が行われることが望ましい。なお、サービス重要度を変更できる場合、システム設計者１０は、マイクロサービスMS-Bの重要度を再設定してもよい。
【0101】
図１１に示す処理は、クリティカルＭＳが無くなるまで繰り返し実行される。クリティカルＭＳが無くなると、図４に示したトレードオフの判定処理４１０が行われる。ただし、後述するように、クリティカルＭＳを無くしきれず、クリティカルＭＳのコア部分が残る場合がある。この場合、制御プログラム２３３は、クリティカルＭＳのコア部分をクリティカルＭＳ相当として、多重化する等により、クリティカルＭＳの障害発生時でもサービスを継続できるようにする。
【0102】
＜ケースごとの障害影響度＞
図１２は、ケース１～３のクリティカルＭＳの要因の例を示す図である。この図は、ケース、障害影響度の計算式、処理内容、及び該当ＭＳの各項目で構成される。
図１２は、ケース１～３のクリティカルＭＳの要因の例を示す図である。この図は、ケース、障害影響度の計算式、処理内容、及び該当ＭＳの各項目で構成される。
【0103】
ケース項目には、図１１に示したケース１～３が格納される。ケース１からケース３は、クリティカルＭＳの例とする。障害影響度（Ｅ）が基準値（Ｃ）の「0.2」より大きいMSをクリティカルＭＳとする。クリティカルＭＳを無くすためには、切替時間_度、重要度_度、通信_度のうち、最大の指標を改善する必要がある。
【0104】
障害影響度の計算式の項目には、計算された障害影響度（Ｅ）、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、又は通信_度Ｅ(cm)が格納される。
【0105】
処理内容項目には、ケース１～３ごとの処理内容が格納される。
該当ＭＳ項目には、ケース１に該当するMS_A、ケース２に該当するMS_B、ケース３に該当するMS_Cが格納される。
該当ＭＳ項目には、ケース１に該当するMS_A、ケース２に該当するMS_B、ケース３に該当するMS_Cが格納される。
【0106】
ケース１では、マイクロサービスMS_Aを対象として、切替時間_度(0.9)をパラメータ１２２が再設定されることにより、障害影響度が改善する。このため、ケース１の処理内容項目には、図１１のステップＳ２２で示した「パラメータの再設定」が処理内容として格納される。
【0107】
ケース２では、マイクロサービスMS_Bを対象として重要度_度(0.9)をシステム設計者１０に通知し、パラメータ１２２が再設定されることにより、障害影響度が改善する。このため、ケース２の処理内容項目には、図１１のステップＳ２７で示した「システム設計者１０に通知すること」と「パラメータ１２２の再設定」が処理内容として格納される。
【0108】
ケース３では、ＭＳ分割／統合プログラム２３２がマイクロサービスMS_Cを対象として通信_度(0.8)が低くなるようにマイクロサービスを分割することにより、障害影響度を改善する。このため、ケース３の処理内容項目には、図１１のステップＳ２６で示した「マイクロサービスの分割」が処理内容として格納される。
【0109】
＜ケース１の設定内容＞
ケース１では、マイクロサービスMS_Aの障害影響度（Ｅ）が基準値（Ｃ）より大きいため、マイクロサービスMS_AがクリティカルＭＳと判定されている。マイクロサービスMS_Aに対するパラメータの再設定は、システム設計者１０との問合せにより行われる。そして、リトライ時間とリトライ回数を変更することにより、クパラメータが再設定される。その後、パラメータが再設定されたマイクロサービスMS_Aの障害影響度（Ｅ）が再計算される。
ケース１では、マイクロサービスMS_Aの障害影響度（Ｅ）が基準値（Ｃ）より大きいため、マイクロサービスMS_AがクリティカルＭＳと判定されている。マイクロサービスMS_Aに対するパラメータの再設定は、システム設計者１０との問合せにより行われる。そして、リトライ時間とリトライ回数を変更することにより、クパラメータが再設定される。その後、パラメータが再設定されたマイクロサービスMS_Aの障害影響度（Ｅ）が再計算される。
【0110】
【0111】
パラメータ項目には、設定可能な項目（障害検出時間、リトライ時間、リトライ回数）と、値が含まれる。
障害影響度の項目には、図１２に示した障害影響度の計算式の項目と同様に、計算された障害影響度（Ｅ）、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、又は通信_度Ｅ(cm)が格納される。
障害影響度の項目には、図１２に示した障害影響度の計算式の項目と同様に、計算された障害影響度（Ｅ）、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、又は通信_度Ｅ(cm)が格納される。
【0112】
事前設定されたパラメータ１２２の障害検出時間が１秒、リトライ時間が１秒、リトライ回数が０回である場合、計算された障害影響度（Ｅ）は、「0.315」である。ここで、クリティカルＭＳと判定される基準値（Ｃ）が「0.2」であれば、障害影響度（Ｅ）＞基準値（Ｃ）であるので、マイクロサービスの分割が行われる。
【0113】
一方、再設定されたパラメータの障害検出時間が１秒、リトライ時間が２秒、リトライ回数が２回である場合、計算された障害影響度（Ｅ）は、「0.175」である。障害影響度（Ｅ）＜基準値（Ｃ）であるので、これ以上のマイクロサービスの分割は行われない。
【0114】
＜ケース２の設定内容＞
ケース２では、マイクロサービスMS_Bの障害影響度（Ｅ）が基準値（Ｃ）より大きいため、マイクロサービスMS_BがクリティカルＭＳと判定されている。マイクロサービスMS_B対するパラメータの再設定は、システム設計者１０への問い合わせにより行われる。この時、システム設計者１０に重要度が下げられないか問い合わせる。システム設計者１０は、問合せを受けた重要度がサービス重要度であれば、サービス重要度の再検討を行う。例えば、システム設計者１０は、マイクロサービスMS_Bに関係している、サービスとして、サービス_Aとサービス_Bのサービス重要度を見直し、サービス重要度を再設定する。そして、システム設計者１０は、再設定したサービス重要度の値を基にマイクロサービスMS_Bの重要度を決める。
ケース２では、マイクロサービスMS_Bの障害影響度（Ｅ）が基準値（Ｃ）より大きいため、マイクロサービスMS_BがクリティカルＭＳと判定されている。マイクロサービスMS_B対するパラメータの再設定は、システム設計者１０への問い合わせにより行われる。この時、システム設計者１０に重要度が下げられないか問い合わせる。システム設計者１０は、問合せを受けた重要度がサービス重要度であれば、サービス重要度の再検討を行う。例えば、システム設計者１０は、マイクロサービスMS_Bに関係している、サービスとして、サービス_Aとサービス_Bのサービス重要度を見直し、サービス重要度を再設定する。そして、システム設計者１０は、再設定したサービス重要度の値を基にマイクロサービスMS_Bの重要度を決める。
【0115】
【0116】
パラメータ項目には、設定可能な項目（サービス、ＭＳ）と値が含まれる。
障害影響度の項目には、計算された障害影響度_度（Ｅ）、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、又は通信_度Ｅ(cm)が格納される。
障害影響度の項目には、計算された障害影響度_度（Ｅ）、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、又は通信_度Ｅ(cm)が格納される。
【0117】
事前設定されたパラメータ１２２では、サービス_Aの値が「0.9」であり、サービス_Bの値が「0.9」であり、サービス_A、サービス_Bのいずれにも用いられるマイクロサービスMS_Bの値が「0.9」である。この場合、計算された障害影響度（Ｅ）は、「0.225」である。クリティカルＭＳと判定される基準値（Ｃ）が「0.2」であれば、障害影響度（Ｅ）＞基準値（Ｃ）であるので、パラメータ１２２が再設定される。
【0118】
一方、再設定されたパラメータ１２２では、サービス_Aの値が「0.7」であり、サービス_Bの値が「0.7」であり、サービス_A、サービス_Bのいずれにも用いられるマイクロサービスMS_Bの値が「0.7」である。この場合、計算された障害影響度（Ｅ）は、「0.175」である。ここで、障害影響度（Ｅ）＜基準値（Ｃ）であるので、これ以上のマイクロサービスの分割は行われない。
【0119】
＜ケース３の設定内容＞
ケース３では、マイクロサービスMS_Cの障害影響度（Ｅ）が基準値（Ｃ）より大きいため、マイクロサービスMS_CがクリティカルＭＳと判定されている。そこで、ＭＳ分割／統合プログラム２３２は、ＭＳマイクロサービスMS_CをマイクロサービスMS_C1とMS_C2に分割する。
ケース３では、マイクロサービスMS_Cの障害影響度（Ｅ）が基準値（Ｃ）より大きいため、マイクロサービスMS_CがクリティカルＭＳと判定されている。そこで、ＭＳ分割／統合プログラム２３２は、ＭＳマイクロサービスMS_CをマイクロサービスMS_C1とMS_C2に分割する。
【0120】
【0121】
ＭＳ項目には、事前設定されたマイクロサービスMS_Cと、再設定されたマイクロサービスMS_C1,MS_C2とが格納される。
パラメータ項目には、設定可能な項目（通信MS/全MS、通信頻度、通信形態）と値が含まれる。
障害影響度の項目には、計算された障害影響度（Ｅ）、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、又は通信_度Ｅ(cm)が格納される。
パラメータ項目には、設定可能な項目（通信MS/全MS、通信頻度、通信形態）と値が含まれる。
障害影響度の項目には、計算された障害影響度（Ｅ）、切替時間_度Ｅ(to)、サービス重要度_度Ｅ(pr)、又は通信_度Ｅ(cm)が格納される。
【0122】
事前設定されたパラメータでは、マイクロサービスMS_Cの通信MS/全MSが４０%であり、通信頻度が６０回であり、通信形態が非同期である。この場合、計算された障害影響度（Ｅ）は、「0.266」である。クリティカルＭＳと判定される基準値（Ｃ）が「0.2」であれば、障害影響度（Ｅ）＞基準値（Ｃ）であるので、マイクロサービスの分割が行われる。
【0123】
＜トレードオフの判定処理＞
次に、トレードオフの判定処理について、図１６～図１９を参照して説明する。
図１６は、トレードオフの判定処理の例を示すフローチャートである。ここでは、６つのマイクロサービス（MA-A, MA-B, MS-C1, MS-C2, MS-D ,MS-E ,MS-F）のリアルタイム性と保守性が評価される。本処理における評価の優先順位はリアルタイム性、可用性、保守性の順とする。また、評価の各項目について、基準値を満たさない場合は、警告が通知される。
次に、トレードオフの判定処理について、図１６～図１９を参照して説明する。
図１６は、トレードオフの判定処理の例を示すフローチャートである。ここでは、６つのマイクロサービス（MA-A, MA-B, MS-C1, MS-C2, MS-D ,MS-E ,MS-F）のリアルタイム性と保守性が評価される。本処理における評価の優先順位はリアルタイム性、可用性、保守性の順とする。また、評価の各項目について、基準値を満たさない場合は、警告が通知される。
【0124】
始めに、ＭＳ分割／統合プログラム２３２は、トレードオフの要因がリアルタイム性であるか否かを判定する（Ｓ３１）。クリティカルＭＳを分割すると、ＭＳサイズが小さくなり、障害影響度は小さくなる。また、分割されたマイクロサービスごとの処理が軽くなるので、マイクロサービスに行われた要求に対するレスポンスは早くなり、リアルタイム性が向上する。そこで、分割されたマイクロサービスのリアルタイム性が最初に評価される。リアルタイム性の評価は、マイクロサービスの実行時間が所定時間内であるか否かで判定される。マイクロサービスの実行時間が所定時間内であれば、リアルタイム性で問題なしと判定される。一方、マイクロサービスの実行時間が所定時間以上であれば、リアルタイム性で問題ありと判定される。
【0125】
ステップＳ３１にて、トレードオフの要因がリアルタイム性であれば（Ｓ３１のＹＥＳ：ケース４）、障害影響度計算プログラム２３１は、マイクロサービスがリアルタイム性を満たせばＯＫと評価する。一方、ＭＳ分割／統合プログラム２３２は、マイクロサービスがリアルタイム性を満たさない場合にはＮＧと評価し、リアルタイム性を満たすようにマイクロサービスのパラメータ１２２を最適化する。例えば、リアルタイム性に影響を与えるクリティカルＭＳの該当箇所が分割されていれば、ＭＳ分割／統合プログラム２３２は、分割されたマイクロサービスを統合し、パラメータを変更してクリティカルＭＳに戻してリアルタイム時間を算出する（Ｓ３２）。
【0126】
ＭＳ分割／統合プログラム２３２が、分割されたマイクロサービスを統合し、クリティカルＭＳに戻す処理は、可用性よりリアルタイム性を重視したことになる。クリティカルＭＳに戻したことは、システム設計者１０に警告として通知される。また、クリティカルＭＳに統合した結果、このクリティカルＭＳのＭＳサイズが基準値より大きくなっている場合もシステム設計者１０に警告として通知される。なお、複数のマイクロサービスがクリティカルＭＳに統合されると、処理が重くなり、レスポンスが遅くなることから、リアルタイム性は低下しやすい。しかし、マイクロサービスのサイズが大きくなることで、プログラム数が減ると、プログラムの保守が容易になり、保守性が向上する。
【0127】
次に、障害影響度計算プログラム２３１は、統合されたマイクロサービスの障害影響度（Ｅ）を算出し（Ｓ３３）、障害影響度（Ｅ）が基準値（Ｃ）を満たすか、すなわち障害影響度（Ｅ）が基準値（Ｃ）以下であるか否かを判定する（Ｓ３４）。障害影響度（Ｅ）が基準値（Ｃ）を満たさなければ（Ｓ３４のＮＯ）、ステップＳ３１に戻ってトレードオフの判定処理が繰り返される。
一方、障害影響度（Ｅ）が基準値（Ｃ）を満たせば（Ｓ３４のＹＥＳ）、障害影響度計算プログラム２３１は、本処理を終了する。
一方、障害影響度（Ｅ）が基準値（Ｃ）を満たせば（Ｓ３４のＹＥＳ）、障害影響度計算プログラム２３１は、本処理を終了する。
【0128】
ケース４では、例えば、マイクロサービスMS_DとMS_Eのトレードオフの要因がリアルタイム性であったとする。リアルタイム性に影響を及ぼす該当箇所(トランザクション)が分割されてマイクロサービスMS_DとMS_Eが作成されたのであれば、ＭＳ分割／統合プログラム２３２は、マイクロサービスMS_DとMS_Eを統合し、統合されたマイクロサービスの実行時間を算出する。その後、障害影響度計算プログラム２３１は、統合されたマイクロサービスの実行時間が所定時間内か否かを判定する。また、障害影響度計算プログラム２３１は、統合されたマイクロサービスの障害影響度を算出し、障害影響度が基準値を満たすか否かを判定する。
【0129】
ステップＳ３１にて、トレードオフの要因がリアルタイム性でなければ（Ｓ３１のＮＯ）、マイクロサービスの保守性が評価される。マイクロサービスの保守性は、マイクロサービスのサイズを評価し、所定値以下かどうかで判定される。そして、ＭＳサイズが所定値以下であれば、保守性で問題なしと判定される。一方、ＭＳサイズが所定値より大きければ、保守性で問題ありと判定される。
【0130】
そこで、障害影響度計算プログラム２３１は、トレードオフの要因がＭＳサイズであるか否かを判定する（Ｓ３５）。トレードオフの要因がＭＳサイズであれば（Ｓ３５のＹＥＳ：ケース５）、障害影響度計算プログラム２３１は、ＭＳサイズが一定値未満であるか否かを判定する。
【0131】
障害影響度計算プログラム２３１は、マイクロサービスのＭＳサイズが一定値未満であると判定すればＯＫと評価し、そのまま処理を終了する。一方、障害影響度計算プログラム２３１は、マイクロサービスのＭＳサイズが一定値以上であると判定すれればＮＧと評価し、システム設計者１０に対して警告を通知する。この場合、障害影響度計算プログラム２３１は、ＭＳの保守性を犠牲にして、リアルタイム性及び可用性を重視することとなる（Ｓ３６）。その後、障害影響度計算プログラム２３１は、本処理を終了する。このことから、始めに、ステップＳ３１でリアルタイム性が重視され、その後、ステップＳ３５で保守性に関わるＭＳサイズがトレードオフの要因であった場合に、リアルタイム性及び可用性が重視される。そして、最後に保守性が重視されることとなる。
【0132】
ケース５では、例えば、マイクロサービスMS_Fのトレードオフの要因が保守性であったとする。この場合、ＭＳ分割／統合プログラム２３２は、トレードオフの要因であるマイクロサービスMS_Fを分割する。但し、ケース４のように、マイクロサービスMS_Fを分割することでリアルタイム性に影響が及ぶ場合は、分割しない。その後、障害影響度計算プログラム２３１は、分割されたマイクロサービスMS_Fの障害影響度を算出し、障害影響度が基準値を満たすか否かを判定する。その後、システム設計者１０に警告が通知される。
【0133】
ステップＳ３５にて、トレードオフの要因がＭＳサイズでなければ（Ｓ３５のＮＯ：ケース６）、トレードオフの要因は無かったので、障害影響度計算プログラム２３１は、何もせずに本処理を終了する。
【0134】
【0135】
この表の左側は、計算対象のＭＳ、リアルタイム性の各項目で構成され、表の右側は、障害影響度、及び計算対象のＭＳの各項目で構成される。
表の左側に示す目標値は、リアルタイム性を判定するための値であり、マイクロサービスの実行時間と待ち時間の合計時間として表される。この例では、目標値が合計時間を１２ｍ秒とされている。
表の左側に示す目標値は、リアルタイム性を判定するための値であり、マイクロサービスの実行時間と待ち時間の合計時間として表される。この例では、目標値が合計時間を１２ｍ秒とされている。
【0136】
リアルタイム性は、事前の処理時間と、再設定の処理時間ごとに計算される。
事前の処理時間とは、マイクロサービスMS_DとMS_Eがそれぞれ行う処理の実行時間と待ち時間、及び合計時間を表す。事前の処理時間に示される合計時間が１５ｍ秒であるため、目標値の１２ｍ秒を超えている。
事前の処理時間とは、マイクロサービスMS_DとMS_Eがそれぞれ行う処理の実行時間と待ち時間、及び合計時間を表す。事前の処理時間に示される合計時間が１５ｍ秒であるため、目標値の１２ｍ秒を超えている。
【0137】
また、表の右側に示す障害影響度は、マイクロサービスMS_DとMS_Eのそれぞれに対して計算された値を格納する。例えば、マイクロサービスMS_Dの障害影響度（Ｅ）は「0.084」であり、マイクロサービスMS_Eの障害影響度（Ｅ）は「0.075」であるため、上述した基準値（Ｃ）の「0.2」よりは小さく、基準値を満たしている。
【0138】
図８に示したように、サービス_Dは、２つの分割されたマイクロサービスMS_DとMS_Eにより構成されており、マイクロサービスMS_DとMS_EはクリティカルＭＳではない。しかし、マイクロサービスMS_DとMS_Eの間で待ち時間が発生するため、合計時間が目標値を超え、リアルタイム性を満たさない。このため、マイクロサービスMS_DとMS_Eを統合する処理が行われる。なお、マイクロサービスの統合に際して、切替時間_度、重要度_度、通信_度は、大きな方の値が採用される。
【0139】
再設定の処理時間には、マイクロサービスMS_DとMS_Eが統合されたマイクロサービスMS_DEに対して算出された処理時間が格納される。マイクロサービスMS_DとMS_Eが統合されたことにより、待ち時間が０秒となる。マイクロサービスMS_DEの実行時間と待ち時間の合計時間は１０ｍ秒であるため、目標値の１２ｍ秒以内となり、リアルタイム性を満たすようになる。また、マイクロサービスMS_DEの障害影響度（Ｅ）は「0.14」であるため、基準値（Ｃ）の「0.2」よりは小さいので、基準値を満たしている。
【0140】
図１８は、ケース５のトレードオフの要因が保守性（ＭＳサイズ）である場合の保守性と障害影響度の例を示す図である。ここでは、図１６のステップＳ３５でＹＥＳ判定が行われた場合（ケース５）を想定して説明する。
【0141】
図１８の上側に示す表は、ＭＳ、保守性、及び障害影響度の各項目で構成される。
保守性の目標値は、ＭＳサイズが１０Kstepである。
事前のＭＳサイズは、マイクロサービスMS_Fに関して１５Kstepであるので、目標値を超えている。なお、マイクロサービスMS_Fの障害影響度（Ｅ）は「0.175」であるため、上述した基準値（Ｃ）の「0.2」よりは小さく、基準値を満たしている。
保守性の目標値は、ＭＳサイズが１０Kstepである。
事前のＭＳサイズは、マイクロサービスMS_Fに関して１５Kstepであるので、目標値を超えている。なお、マイクロサービスMS_Fの障害影響度（Ｅ）は「0.175」であるため、上述した基準値（Ｃ）の「0.2」よりは小さく、基準値を満たしている。
【0142】
そこで、ＭＳサイズが目標値より大きいマイクロサービスMS_Fは、マイクロサービスMS_F1とMS_F2に分割され、再び保守性と障害影響度が判定される。
再設定されたＭＳサイズは、マイクロサービスMS_F1が８kstepであり、マイクロサービスMS_F2が８kstepであるので、いずれも保守性の目標値以下である。また、障害影響度（Ｅ）は、マイクロサービスMS_F1が「0.081」であり、マイクロサービスMS_F2が「0.081」であるので、いずれも基準値（Ｃ）以下であり、基準値を満たしている。
再設定されたＭＳサイズは、マイクロサービスMS_F1が８kstepであり、マイクロサービスMS_F2が８kstepであるので、いずれも保守性の目標値以下である。また、障害影響度（Ｅ）は、マイクロサービスMS_F1が「0.081」であり、マイクロサービスMS_F2が「0.081」であるので、いずれも基準値（Ｃ）以下であり、基準値を満たしている。
【0143】
図１８の下側に示す表は、分割前のマイクロサービスMS_Fの通信に関する各項目（通信範囲（Com_R）、通信頻度（Com_F）、通信形態（Com_T））と、通信_度平均値が格納される。通信に関する各項目（通信範囲（Com_R）、通信頻度（Com_F）、通信形態（Com_T））は、図９に示した通信_度の変換テーブルにより値が格納される。
【0144】
マイクロサービスMS_Fの通信範囲（Com_R）は「0.2」、通信頻度（Com_F）は「0.2」、通信形態（Com_T）は「0.3」であり、通信_度平均値は「0.23」である。
一方、マイクロサービスMS_F1とMS_F2は、互いに通信が行われるため、通信に関する各項目の値が大きくなる。例えば、マイクロサービスMS_F1とMS_F2の通信範囲（Com_R）は「0.6」、通信頻度（Com_F）は「0.6」、通信形態（Com_T）は「0.3」であり、通信_度平均値は「0.5」である。
一方、マイクロサービスMS_F1とMS_F2は、互いに通信が行われるため、通信に関する各項目の値が大きくなる。例えば、マイクロサービスMS_F1とMS_F2の通信範囲（Com_R）は「0.6」、通信頻度（Com_F）は「0.6」、通信形態（Com_T）は「0.3」であり、通信_度平均値は「0.5」である。
【0145】
なお、クリティカルＭＳを分割しても、厳しいシステム要件３００が設定されていれば、コア部分が残ることがある。コア部分が残れば、システム性能(可用性、リアルタイム性、保守性)を満たさない場合も存在しうる。この場合、システム性能を満たさないコア部分が存在することがシステム設計者１０に通知される。例えば、リアルタイム性と保守性を同時に満足できないことがある。この場合、リアルタイム性を優先して、保守性を満たさないことは許容するように促すメッセージが制御システム２００からシステム設計者１０に提案される。そこで、システム設計者１０は、提案に従って、システム要件３００（可用性、リアルタイム性、保守性）を再設定する。制御システム２００は、再設定されたシステム要件３００に従って、マイクロサービスの分割/統合、パラメータの再設定を行うこととなる。
【0146】
＜可視化された障害影響範囲＞
次に、障害影響範囲を可視化する例について説明する。
図１９は、障害影響範囲が可視化された画面５０の表示例を示す図である。この画面５０は、例えば、図４のステップＳ７の処理後に、図２に示した出力部２５０により出力され、システム設計者１０が確認することができる。
次に、障害影響範囲を可視化する例について説明する。
図１９は、障害影響範囲が可視化された画面５０の表示例を示す図である。この画面５０は、例えば、図４のステップＳ７の処理後に、図２に示した出力部２５０により出力され、システム設計者１０が確認することができる。
【0147】
画面５０は、システム要件３００の再設定が可能なコマンド入力欄５１、実行結果の表示欄５２、及びクリティカルＭＳを含む障害影響範囲を示す表示欄５３を有する。
【0148】
コマンド入力欄５１には、コマンドの一例として、可用性、リアルタイム性、ＭＳサイズの入力欄が含まれる。システム設計者１０が、コマンドとして、可用性、リアルタイム性、ＭＳサイズをコマンド入力欄５１に指定して、実行ボタン５１ａを押下すると、図２に示した演算部２３０によるマイクロサービス化の処理が自動実行される。
【0149】
コマンド入力欄５１からシステム要件３００の再設定が入力された後、分割統合処理の実行結果が出力される。例えば、再設定されたシステム要件３００に従ってマイクロサービス化の処理が自動実行された結果が、実行結果の表示欄５２に表示される。実行結果がＯＫではない場合、システム設計者１０に警告が通知される。警告の通知は、例えば、表示欄５２のける警告メッセージの表示、又は表示欄５３におけるクリティカルＭＳの表示によって行われる。
【0150】
また、マイクロサービス化の処理が自動実行されると、マイクロサービス化の実行結果の表示欄５３に、マイクロサービスが可視化して表示される。ここでは、マイクロサービスMS_A～MS_Fの障害影響度（Ｅ）と、各マイクロサービスの障害の関連性が可視化して示される。例えば、マイクロサービスMS_Aに発生する障害は、マイクロサービスMS_Dに影響を与える。また、マイクロサービスMS_Bに発生する障害は、マイクロサービスMS_DとMS_Fに影響を与える。
【0151】
ここで、マイクロサービスMS_Dの障害影響度（Ｅ）は「0.3」であり、基準値（Ｃ）の「0.2」より大きい。このため、マイクロサービスMS_DがクリティカルＭＳであることが強調して表示される。システム設計者１０は、クリティカルＭＳであるマイクロサービスMS_Dをさらに分割するかを指定することができる。
【0152】
＜リカバリ手順の説明＞
次に、マイクロサービスに障害が発生した時に行われるリカバリ手順について説明する。
（１）障害発生
マイクロサービスで障害が発生すると、以下のリカバリ手順が開始される。
（２）障害検出
次に、マイクロサービスで発生した障害が検出される。
次に、マイクロサービスに障害が発生した時に行われるリカバリ手順について説明する。
（１）障害発生
マイクロサービスで障害が発生すると、以下のリカバリ手順が開始される。
（２）障害検出
次に、マイクロサービスで発生した障害が検出される。
【0153】
（３）障害回復
次に、障害から回復する処理が行われる。ここで、マイクロサービスが重要であるか、重要でない（通常である）かによって、２つの方法が用いられる。
次に、障害から回復する処理が行われる。ここで、マイクロサービスが重要であるか、重要でない（通常である）かによって、２つの方法が用いられる。
【0154】
（３－１）重要なマイクロサービス
重要なＭＳであれば、制御プログラム２３３は、現用系のＭＳと、待機系のＭＳを動作させている。上述したようにクリティカルＭＳは、できるだけ無くなるように処理されるが、それでもクリティカルＭＳが残る場合がある。この場合、クリティカルＭＳを分割して残ったコア部分（クリティカルＭＳに相当する部分）が重要なＭＳとして現用系と待機系で多重化して運用される。そして、制御プログラム２３３は、クリティカルＭＳで障害が発生したことが検出されたタイミングで、現用系と待機系で動作するクリティカルＭＳを現用系から待機系に切り替えてサービスを継続させる。このサービス切り替えの例は後述する。
重要なＭＳであれば、制御プログラム２３３は、現用系のＭＳと、待機系のＭＳを動作させている。上述したようにクリティカルＭＳは、できるだけ無くなるように処理されるが、それでもクリティカルＭＳが残る場合がある。この場合、クリティカルＭＳを分割して残ったコア部分（クリティカルＭＳに相当する部分）が重要なＭＳとして現用系と待機系で多重化して運用される。そして、制御プログラム２３３は、クリティカルＭＳで障害が発生したことが検出されたタイミングで、現用系と待機系で動作するクリティカルＭＳを現用系から待機系に切り替えてサービスを継続させる。このサービス切り替えの例は後述する。
【0155】
（３－２）通常のマイクロサービス
通常のＭＳは、二重化されておらず、待機系のＭＳが動作していない。このため、制御プログラム２３３は、現用系と待機系で動作していない通常のマイクロサービスに障害が発生したことを検出すると、障害の発生を検出したマイクロサービスの機能を補うマイクロサービスを新たに起動する。
通常のＭＳは、二重化されておらず、待機系のＭＳが動作していない。このため、制御プログラム２３３は、現用系と待機系で動作していない通常のマイクロサービスに障害が発生したことを検出すると、障害の発生を検出したマイクロサービスの機能を補うマイクロサービスを新たに起動する。
【0156】
＜障害検出方法＞
次に、重要なマイクロサービスの障害検出方法について、図２０と図２１を参照して説明する。
上述したように、対象システム１００にクリティカルＭＳが残る場合には、クリティカルＭＳが多重化して構成される。多重化構成として、例えば、現用系と待機系による二重化構成がある。そして、現用系のクリティカルＭＳの障害が検知されると、チェックポイントデータ転送方式、又は両系転送方式のいずれかにより待機系のクリティカルＭＳに切り替えてサービスが継続される。
次に、重要なマイクロサービスの障害検出方法について、図２０と図２１を参照して説明する。
上述したように、対象システム１００にクリティカルＭＳが残る場合には、クリティカルＭＳが多重化して構成される。多重化構成として、例えば、現用系と待機系による二重化構成がある。そして、現用系のクリティカルＭＳの障害が検知されると、チェックポイントデータ転送方式、又は両系転送方式のいずれかにより待機系のクリティカルＭＳに切り替えてサービスが継続される。
【0157】
（チェックポイントデータ転送方式）
図２０は、チェックポイントデータ転送方式による障害検出方法の例を示す図である。例えば、マイクロサービスMS_Aは、現用系のクリティカルＭＳと通信を行っている。処理順を示す番号を図面に付してチェックポイントデータ転送方式による障害検出方法を説明する。
図２０は、チェックポイントデータ転送方式による障害検出方法の例を示す図である。例えば、マイクロサービスMS_Aは、現用系のクリティカルＭＳと通信を行っている。処理順を示す番号を図面に付してチェックポイントデータ転送方式による障害検出方法を説明する。
【0158】
（１）現用系のクリティカルＭＳは、待機系のクリティカルＭＳに対して、チェックポイントデータを周期的に転送する。上述したように、チェックポイントデータは、例えば、マイクロサービスMS_Aに障害が発生した場合に、待機系のクリティカルＭＳに処理を引き継ぐために必要なデータである。待機系のクリティカルＭＳは、チェックポイントデータを受信することで、現用系のクリティカルＭＳからマイクロサービスMS_Aとの通信処理を引き継ぐ。併せて、現用系のクリティカルＭＳと待機系のクリティカルＭＳは、互いにAliveメッセージを送り合うことで稼働確認している。
【0159】
（２）現用系のクリティカルＭＳに障害が発生する。
（３）障害が発生すると、現用系のクリティカルＭＳがマイクロサービスMS_Aと通信できなくなる。このため、待機系のクリティカルＭＳは、現用系のクリティカルＭＳからチェックポイントデータを受け取れない。また、待機系のクリティカルＭＳは、現用系のクリティカルＭＳからAliveメッセージを受け取れず、現用系のクリティカルＭＳにAliveメッセージを送ることもできない。このため、待機系のクリティカルＭＳは、現用系のクリティカルＭＳに障害が発生したことを検出し、リカバリ手順を実施することができる。
（３）障害が発生すると、現用系のクリティカルＭＳがマイクロサービスMS_Aと通信できなくなる。このため、待機系のクリティカルＭＳは、現用系のクリティカルＭＳからチェックポイントデータを受け取れない。また、待機系のクリティカルＭＳは、現用系のクリティカルＭＳからAliveメッセージを受け取れず、現用系のクリティカルＭＳにAliveメッセージを送ることもできない。このため、待機系のクリティカルＭＳは、現用系のクリティカルＭＳに障害が発生したことを検出し、リカバリ手順を実施することができる。
【0160】
（両系転送方式）
図２１は、両系転送方式による障害検出方法の例を示す図である。例えば、マイクロサービスMS_Aは、現用系のクリティカルＭＳと、待機系のクリティカルＭＳの両系と通信を行っている。処理順を示す番号を図面に付して両系転送方式による障害検出方法を説明する。
図２１は、両系転送方式による障害検出方法の例を示す図である。例えば、マイクロサービスMS_Aは、現用系のクリティカルＭＳと、待機系のクリティカルＭＳの両系と通信を行っている。処理順を示す番号を図面に付して両系転送方式による障害検出方法を説明する。
【0161】
（１）マイクロサービスMS_Aは、現用系のクリティカルＭＳと、待機系のクリティカルＭＳにメッセージを送信する。両系転送方式では、現用系のクリティカルＭＳが待機系のクリティカルＭＳにチェックポイントデータを送信する必要はない。なお、現用系のクリティカルＭＳと待機系のクリティカルＭＳは、互いにAliveメッセージを送り合うことで稼働確認している。
【0162】
（２）現用系のクリティカルＭＳに障害が発生する。
（３）障害が発生すると、現用系のクリティカルＭＳがマイクロサービスMS_Aと通信できなくなる。待機系のクリティカルＭＳは、現用系のクリティカルＭＳからAliveメッセージを受け取れず、現用系のクリティカルＭＳにAliveメッセージを送ることもできない。このため、待機系のクリティカルＭＳは、現用系のクリティカルＭＳに障害が発生したことを検出し、リカバリ手順を実施することができる。
（３）障害が発生すると、現用系のクリティカルＭＳがマイクロサービスMS_Aと通信できなくなる。待機系のクリティカルＭＳは、現用系のクリティカルＭＳからAliveメッセージを受け取れず、現用系のクリティカルＭＳにAliveメッセージを送ることもできない。このため、待機系のクリティカルＭＳは、現用系のクリティカルＭＳに障害が発生したことを検出し、リカバリ手順を実施することができる。
【0163】
以上説明した一実施の形態に係る制御システム２００では、システム設計者１０が事前処理により巨大プログラム１１１がマイクロサービス化される。その後、制御システム２００は、マイクロサービス化ルール２２４に従って、マイクロサービスごとに要件を判定することで、システム設計時にクリティカルＭＳを検出する。この時、制御システム２００は、対象システム１００のマイクロサービスからクリティカルＭＳが無くなるように、マイクロサービスの分割又は統合をアルゴリズムにより処理する。このため、対象システム１００を構成する多数のマイクロサービスが自動的に最適化される過程で、クリティカルＭＳが除かれ、マイクロサービスのシステム設計が容易化する。また、既存の対象システム１００がマイクロサービス化されることで、各マイクロサービスのモダナイゼーション（古いプログラムを更新する処理）が容易化される。また、既存の対象システム１００がマイクロサービス化されることで、マイクロサービスを他の環境に展開することも容易となる。
【0164】
制御システム２００では、障害影響度が計算され、障害影響度と基準値とを比較することで、マイクロサービスがクリティカルＭＳであるか否かが判定される。そして、クリティカルＭＳであると判定されたマイクロサービスは、分割又は統合が行われることで、クリティカルＭＳが無くなることが期待される。クリティカルＭＳが無くなると、仮にマイクロサービスに障害が発生しても、他のマイクロサービスに障害の影響が及びにくくなる。このため、障害が発生したマイクロサービスだけを置き換える処理が容易となり、マイクロサービスの全体に波及する障害を押さえることができる。また、障害が発生したマイクロサービスと、他のマイクロサービスとの繋がりを必要最小限とすることで、障害が発生したマイクロサービスのリカバリに要する時間を短縮することができる。
【0165】
また、マイクロサービスのシステム要件３００の優先順位を、リアルタイム性、可用性、保守性の順としている。この優先順位に従って、マイクロサービスが分割又は統合されるため、マイクロサービスの性能が保証される。
【0166】
また、リアルタイム時間が一定値以上となるマイクロサービスは、他のマイクロサービスと統合され、リアルタイム時間が一定時間未満になり、リアルタイム性の要件を満たすようになる。このため、制御システム２００によるマイクロサービスの分割又は統合処理は、特にリアルタイム性が要求される対象システム１００のマイクロサービス化に有用となる。
【0167】
また、リアルタイム性とＭＳサイズとのトレードオフを考慮して、マイクロサービスが分割又は統合される。このため、リアルタイム性が一定時間時間未満であり、かつ、ＭＳサイズが一定値未満となるようなマイクロサービスが生成される。この結果、システム設計者１０により予め設定された要件を満たすマイクロサービスによって対象システム１００が構成されることとなる。
【0168】
また、クリティカルＭＳが検出されると、クリティカルＭＳに関する情報が可視化して画面５０に表示される。システム設計者１０は、画面５０を確認しながら、可用性、リアルタイム性、又はＭＳサイズを含むシステム要件３００の設定変更が可能である。そして、設定変更されたシステム要件３００により、再びマイクロサービスの分割又は統合処理が行われた結果が画面５０に表示される。このため、システム設計者１０は、設定変更したシステム要件３００が妥当であったかを確認することが容易となる。
【0169】
なお、本発明は上述した各実施形態に限られるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
例えば、上述した各実施形態は本発明を分かりやすく説明するために制御システム２００の構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施形態の構成の一部を他の実施形態の構成に置き換えることは可能であり、さらにはある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
例えば、上述した各実施形態は本発明を分かりやすく説明するために制御システム２００の構成を詳細かつ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されない。また、ここで説明した実施形態の構成の一部を他の実施形態の構成に置き換えることは可能であり、さらにはある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【0170】
１０…システム設計者、５０…画面、１００…対象システム、１２０…記憶管理部、１２１…マイクロサービス、１２２…パラメータ、２００…制御システム、２２０…記憶管理部、２２１…パラメータ、２２２…要件データ、２２３…障害影響度データ、２２４…マイクロサービス化ルール、２３０…演算部、２３１…障害影響度計算プログラム、２３２…ＭＳ分割／統合プログラム、２３３…制御プログラム
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】