JP2022142456A - 異常対処プログラム、異常対処システム、及び異常対処方法 - Google Patents

Abstract

【課題】コンテナの異常への対処が遅れるのを抑制すること。【解決手段】複数のコンテナの各々に発生した異常の優先度を設定し、前記異常の種類ごとに、当該異常を解消させるロジックを生成し、前記優先度の順に、前記異常に対して前記ロジックを実行する処理をコンピュータに実行させるための異常対処プログラムによる。【選択図】図７

Description

本発明は、異常対処プログラム、異常対処システム、及び異常対処方法に関する。

コンピュータを仮想化する技術の一つにコンテナ仮想化技術がある。コンテナ仮想化技術は、OS(Operating System)のカーネルの一部を利用して仮想化を行うため、VM(Virtual Machine)仮想化技術と比較して仮想化のオーバヘッドが小さく軽量であるという利点がある。そのコンテナ仮想化技術においては、互いに独立した複数のユーザ空間が生成される。これらのユーザ空間はコンテナと呼ばれ、そのコンテナの各々においてアプリケーションプログラムが実行される。

コンテナを利用して業務システムを構築する場合、各々のコンテナで一つのアプリケーションプログラムを実行するMSA(Micro Service Architecture)と呼ばれるアーキテクチャを採用することがある。MSAは、業務システムを複数の機能に分割し、各機能を実現するアプリケーションプログラムをコンテナで実行するアーキテクチャである。前述のようにコンテナは軽量であるため、コンテナを利用したMSAでは業務システムを簡単にスケールアウトすることができるというメリットがある。

但し、MSAでは、例えば一つのコンテナの負荷が増大したときの負荷軽減を図る等の目的でコンテナの個数が急増したり、更にコンテナ同士の依存関係が複雑になったりする。そのため、コンテナに異常が発生した場合、業務システムの運用者がその異常に対処するのが極めて難しくなり、ひいては異常への対処が遅れてしまう。

特開２０１３－１６１３０５号公報 国際公開第２０１３／０３５２４３号

一側面によれば、コンテナの異常への対処が遅れるのを抑制することを目的とする。

一側面によれば、複数のコンテナの各々に発生した異常の優先度を設定し、前記異常の種類ごとに、当該異常を解消させるロジックを生成し、前記優先度の順に、前記異常に対して前記ロジックを実行する処理をコンピュータに実行させるための異常対処プログラムが提供される。

一側面によれば、コンテナの異常への対処が遅れるのを抑制できる。

図１は、業務システムの監視方法について示す模式図である。 図２は、問題を示す模式図（その１）である。 図３は、問題を示す模式図（その２）である。 図４は、業務システムの別の監視方法について示す模式図である。 図５は、問題について示す模式図（その３）である。 図６は、問題について示す模式図（その４）である。 図７は、本実施形態に係る異常対処システムの機能構成図である。 図８は、サービス情報の模式図である。 図９（ａ）、（ｂ）は、サービス情報の取得方法の例について示す模式図である。 図１０は、サービス情報に含まれる「Using_service」の項目を取得する方法の模式図である。 図１１は、異常情報リソースの模式図である。 図１２は、ロジックデータベースの模式図である。 図１３は、運用ポリシの模式図である。 図１４は、業務システムの運用を開始するときの処理の流れを示すフローチャートである。 図１５は、本実施形態に係る異常対処方法のフローチャートである。 図１６は、異常対処処理のフローチャートである。 図１７は、本実施形態の第１例に係る異常対処について説明するための模式図である。 図１８（ａ）は本実施形態の第１例に係るサービス情報の模式図であり、図１８（ｂ）は本実施形態の第１例において制御部が生成した異常情報リソースの模式図である。 図１９は、本実施形態の第１例においてロジック生成部が生成したロジックの模式図である。 図２０は、本実施形態の第２例に係る異常対処について説明するための模式図である。 図２１は、本実施形態の第２例に係るサービス情報を示す模式図である。 図２２は、図２１のサービス情報を利用して制御部が生成したサービストポロジの模式図である。 図２３は、本実施形態の第２例において制御部が生成した異常情報リソースの模式図である。 図２４は、本実施形態に係る異常対処装置のハードウェア構成図である。

本実施形態の説明に先立ち、本願発明者が検討した事項について説明する。

図１は、業務システムの監視方法について示す模式図である。

図１においては、複数のサービス４によって実現される業務システム１について例示している。業務システム１はMSAを採用したシステムであり、MSAの個々の機能がサービス４によって実現される。

各々のサービス４は、コンテナ基盤２の上で起動した複数のコンテナの各々のアプリケーションプログラムで実現される。コンテナ基盤２は、複数のコンテナを自動的に配備するプログラムであって、Kubernetes（登録商標）やOpenShift（登録商標）等がその一例である。

サービス４を実現するコンテナに異常が発生しているかを判断するために、この例では各々のコンテナをコンテナ監視ソフトウェア５で監視する。コンテナ監視ソフトウェア５は、コンテナの異常を検知した場合には、業務システム１の運用者の操作端末６にアラートを表示する。そして、業務システム１の運用者は、アラートが通知された順に異常に対処することになる。

しかし、コンテナ監視ソフトウェア５は軽微な異常や重篤な異常を問わずにアラートを表示するため、この方法では業務システム１の運用者が重篤な異常に対処するのが遅れる可能性がある。

図２は、この問題を示す模式図である。図２の例では、軽微な異常である「軽微A」～「軽微D」という異常と、重大な重篤な異常である「重大A」という異常が各コンテナに発生した場合を想定している。

この場合、運用者は、異常が発生した順に対処するため、「重大A」という重篤な異常に対処するのが遅れてしまい、業務システム１自体の運用に問題が生じてしまう。更に、業務システム１の運用者が異常の緊急性を考慮して異常への対応順を決めても、対応順を決める判断そのものに時間がかかり、異常への対処が遅れるおそれがある。

また、運用者が手動で異常に対処するのではなく、異常への対処をスクリプトで自動化することも考えられる。しかし、単純にスクリプトを組んだのでは、上記と同様にアラートが通知された異常から順にスクリプトが対処するため、やはり重篤な異常への対処が遅れる。

しかも、この方法では、異常への対処後に当該異常が解消されたかを運用者が確認する必要があり、解消されていない場合には再び同じ異常に対して対処する必要がある。

図３は、この問題を示す模式図である。図３では、運用者が同じ異常に対して何度も対処した場合を想定している。これでは運用者の負担が大きくなり煩わしさに堪えない。

図４は、業務システムの別の監視方法について示す模式図である。なお、図４において図１で説明したのと同じ要素には図１におけるのと同じ符号を付し、以下ではその説明を省略する。

図４の例では、コンテナ基盤２に備わっているヘルスチェック機構２ａがサービス４を実行しているコンテナの異常を検出し、異常が検出された場合にはヘルスチェック機構２ａが異常を解消させる。

しかし、ヘルスチェック機構２ａが監視可能な異常の種類は、コンテナ自身が停止した等の異常に限定されており、コンテナの内部の異常をヘルスチェック機構２ａが検出することはできない。

更に、ヘルスチェック機構２ａは、複数のコンテナに跨って発生した高度な異常を検出することもできない。

図５は、その問題について示す模式図である。図５に示すように、ヘルスチェック機構２ａは、コンテナの内部でのみ有効なコマンドを実行することで当該コンテナのログを取得し、ログに基づいて異常の有無の判断を行う。そのため、一つのコンテナでコマンドを実行しても、そのコンテナとは別のコンテナのログを取得することができず、複数のサービス４に跨る異常を検出することができない。

しかも、ヘルスチェック機構２ａは、ある異常を解消させることができない場合、その異常に対する対処を繰り返して行うため、重篤な異常への対処が遅れる可能性がある。

図６は、その問題について示す模式図である。図６に示すように、ヘルスチェック機構２ａがあるコンテナのサービス４の異常に対して繰り返し対処をしている間は、他のコンテナで実行しているサービス４の異常が放置されてその対処が遅れてしまう。以下、本実施形態について説明する。

（本実施形態）
図７は、本実施形態に係る異常対処システムの機能構成図である。

図７に示すように、異常対処システム２０は、業務システム２１と異常対処装置２２とを有する。このうち、業務システム２１は、複数のサービス２３で実現されるMSAを採用したシステムである。各々のサービス２３は、コンテナ２４とサイドカープロキシ２５とを有する。各々のコンテナ２４は、業務システム２１の複数の機能のうちの一つを実現するためのアプリケーションプログラムを一つ実行しており、これらのアプリケーションプログラムによって業務システム２１の機能が実現される。

各々のコンテナ２４とサイドカープロキシ２５はコンテナ基盤２６の上で実行される。コンテナ基盤２６は、コンテナ２４を起動するためのDocker（登録商標）等のコンテナエンジンと、各コンテナ２４を管理するKubernetes等のコンテナ管理プログラムとをコンピュータの上で実行することで実現されるコンテナ実行環境である。コンテナエンジンとコンテナ管理プログラムを実行するコンピュータは特に限定されず、物理マシンや仮想マシンの上でこれらのプログラムを実行し得る。

サイドカープロキシ２５は、自身と同一のサービス２３に配備されたコンテナ２４に係るサービス情報２７の各項目のパラメータを取得し、それを異常対処装置２２に通知するためのプログラムである。

図８は、サービス情報２７の模式図である。図８に示すように、サービス情報２７は、「Name」、「Id」、「Status」、「Priority」、「Stdout_path」、「Logfile_path」、「Internalcmd_path」、「Using_db」、「Using_service」、「Operation_type」、及び「SLA」の各項目を有する。

このうち、「Name」はサービス２３の名前であり、「Id」はサービス２３を一意に識別する識別子である。

「Status」は、サービス２３の状態を示す情報である。その情報には、サービス２３に含まれるコンテナ２４が稼働中であることを示す「Running」、当該コンテナ２４に異常が発生していることを示す「Error」、当該異常に対処中であることを示す「ResolvingError」がある。また、サービス２３に含まれるコンテナ２４が停止中であることを示す「Stopped」も「Status」に含まれる。

「Priority」は、コンテナ２４に異常が発生したときに異常の対処順序を決めるためのパラメータである。「Stdout_path」はサービス２３における標準出力先を示し、「Logfile_path」はログファイルの出力先を示す。

また、「Internalcmd_path」は、サービス２３に含まれるコンテナ２４の内部の情報を取得するためのコマンドパスを示す。

「Using_db」は、サービス２３に含まれるコンテナ２４が使用するデータベースの名前である。「Using_service」は、サービス２３に含まれるコンテナ２４と依存関係にある他のコンテナ２４を含むサービス２３の名前である。

「Operation_type」は、業務システム２１を実現するのに当該サービス２３が必須かどうかを示す情報である。

「SLA」は、業務システム２１のSLA(Service Level Agreement)である。一例として、業務システム２１の可用性をSLAとして採用し得る。

サービス情報２７の取得方法は特に限定されない。

図９（ａ）、（ｂ）は、サービス情報２７の取得方法の例について示す模式図である。

このうち、図９（ａ）は、サービス２３に割り当てられた記憶領域２３ａを利用した方法の模式図である。記憶領域２３ａは、同一のサービス２３に属するコンテナ２４とサイドカープロキシ２５の両方からアクセス可能な記憶領域である。例えば、コンテナ２４は、動作ログや異常ログを記憶領域２３ａに格納する。そして、サイドカープロキシ２５は、これらのログのうちでサービス情報２７に含まれる項目を記憶領域２３ａから取得し、当該項目をサービス情報取得部４１に通知する。

一方、図９（ｂ）は、記憶領域２３ａを介さずに、サイドカープロキシ２５がコンテナ２４からサービス情報２７に含まれる各項目を直接取得し、それをサービス情報取得部４１に通知する場合の模式図である。

この場合、サイドカープロキシ２５は、サービス情報２７に含まれる各項目を収集するための内部コマンド「/bin/internal_cmd」をコンテナ２４の内部で実行し、これらの項目を収集する。

図１０は、サービス情報２７に含まれる「Using_service」の項目を取得する方法の模式図である。

ここでは、「ServiceA」のサービス２３が、「ServiceB」と「ServiceC」のサービス２３の各々に依存しているとする。なお、「SeviceA」のコンテナ２４は第１のコンテナの一例であり、「ServiceB」のコンテナ２４は第２のコンテナの一例である。この場合、「ServiceA」のサービス２３におけるサイドカープロキシ２５は、自サービス２３のコンテナ２４から送信される通信パケット等のデータを監視する。そして、当該サイドカープロキシ２５は、通信パケットのヘッダを分析することにより送信元のコンテナ２４が属するサービス２３と、送信先のコンテナ２４が属するサービス２３とを特定する。その後、サイドカープロキシ２５は、送信元と送信先とを対応つけた通信テーブル２３ｂを生成し、それをサービス情報取得部４１に通知する。そして、サービス情報取得部４１が制御部４２に通信テーブル２３ｂを通知する。

制御部４２は、通信テーブル２３ｂに基づいて、送信元の「ServiceA」に含まれるコンテナ２４と、送信先の「ServiceB」に含まれるコンテナ２４とを特定する。そして、制御部４２は、「ServiceA」に含まれるコンテナ２４が「ServiceB」に含まれるコンテナ２４に依存していると判断し、サービス情報２７の「Using_service」の項目として「ServiceB」を設定する。

同様に、制御部４２は、は、この通信テーブル２３ｂから「ServiceA」に含まれるコンテナ２４が「ServiceC」に含まれるコンテナ２４に依存しているとも判断する。そのため、制御部４２は、サービス情報２７の「Using_service」の項目として更に「ServiceC」を設定する。

再び図７を参照する。異常対処装置２２は、業務システム２１の各コンテナ２４に異常が発生した場合に、その異常を解消させるための対処を行う装置である。一例として、異常対処装置２２は、解析部３１、異常対処部３２、記憶部３３、運用ポリシ生成部３４、運用ポリシ適用部３５、及び受付部３６を備える。

このうち、解析部３１は、前述のサービス情報２７を解析する処理部であって、サービス情報取得部４１と制御部４２とを有する。

サービス情報取得部４１は、各々のサイドカープロキシ２５からサービス情報２７を取得する処理部である。

制御部４２は、サービス情報取得部４１が収集したサービス情報２７を解析することによりコンテナ２４の異常の有無を判定する。

例えば、制御部４２は、サービス情報２７の「Status」が「Error」となっている場合に、そのサービス情報２７に係るサービス２３に含まれるコンテナ２４に異常が発生したと判定する。

また、制御部４２は、サービス情報２７の「Using_db」や「Using_service」を利用して、複数のサービス２３同士の依存関係を示すサービストポロジを生成する。更に、制御部４２は、サービス情報２７の「Using_db」や「Using_service」が前回取得時と異なっている場合に、複数のサービス２３同士の依存関係を示すサービストポロジが変更されたと判定する。

制御部４２は、前述のようにコンテナ２４に異常が発生したと判定した場合には、サービス情報２７に基づいて異常情報リソース４４を生成し、それを記憶部３３に格納する。異常情報リソース４４は、サービス２３に発生した異常についての情報を示すファイルであり、発生した異常ごとに制御部４２が生成する。

図１１は、異常情報リソース４４の模式図である。図１１に示すように、異常情報リソース４４は、「Kind」、「Id」、「Status」、「Priority」、「Service」、及び「Retry_count」の各項目を有する。

このうち、「Kind」は、異常の種類を示す情報である。「Kind」の設定方法は特に限定されない。例えば、制御部４２は、サービス情報２７の「Status」が「Error」となっている場合に、サービス情報２７の「Stdout_path」で示されるパスから標準エラー出力を取得し、サービス情報２７の「Logfile_path」からログファイルを取得する。そして、制御部４２は、取得した標準エラー出力とログファイルに基づいて異常の種類を示す「Kind」の値を設定する。

また、「Id」は異常情報リソース４４を一意に識別する識別子である。「Status」は、異常への対処結果を示す情報である。その情報には、対処により異常が解消されたことを示す「Sucess」、対処しても異常が解消されなかったことを示す「Failed」、及び異常への対処中であることを示す「ResolvingError」がある。

「Priority」は、複数の異常のうち、どの異常から先に対処すべきかを示す優先度を示す数値であり、その値が小さいほど優先度が高いことになる。「Priority」の値の設定方法は特に限定されず、異常の種類を示す「Kind」と、サービス情報２７に含まれる「Priority」等に基づいて、制御部４２が異常情報リソース４４の「Priority」の値を設定し得る。

「Service」は、異常が発生したサービス２３の名前である。「Retry_count」は、異常に対処した回数を示す。「Retry_count」の初期値は「０」であり、異常を解消させるためのロジックをロジック実行部４９が実行するたびに制御部４２が「Retry_count」を１だけインクリメントする。

再び図７を参照する。制御部４２は、異常情報リソース４４を生成した後に、異常対処部３２に対して異常の対処を依頼する。

異常対処部３２は、制御部４２からの依頼を受けたときに、サービス２３に発生した異常を解消させるための対処を行う処理部である。一例として、異常対処部３２は、異常特定部４６、スケジューリング部４７、ロジック生成部４８、及びロジック実行部４９を有する。

このうち、異常特定部４６は、制御部４２から依頼を受けたときに記憶部３３にある複数の異常情報リソース４４を読み込み、これらの異常情報リソース４４に対応した異常の種類を特定する処理部である。例えば、異常特定部４６は、異常情報リソース４４の「Kind」から異常の種類を特定する。また、異常特定部４６は、異常の種類を特定した後に、異常への対処のスケジューリングを行うようにスケジューリング部４７に依頼する。

スケジューリング部４７は、異常特定部４６からの依頼を受けたときに、異常への対処のスケジューリングを行う処理部である。一例として、スケジューリング部４７は、異常情報リソース４４の「Priority」から異常の優先度を特定し、優先度が高い異常から順に処理をするようにスケジューリングを行う。

ロジック生成部４８は、異常特定部４６が特定した異常の種類ごとに、当該異常を解消させるロジックを生成する処理部である。例えば、ロジック生成部４８は、記憶部３３に格納されているロジックデータベース５１を参照することによりロジックを生成する。

図１２は、ロジックデータベース５１の模式図である。図１２に示すように、ロジックデータベース５１は、「異常の種類」、「異常名」、及び「ロジック」の各々を対応付けた情報である。

「異常の種類」は、異常情報リソース４４の「Kind」と同一の情報であって、異常の種類を示す情報である。「異常名」は、異常の名前を示す情報である。そして、「ロジック」は、異常を解消させるための処理内容を示す情報である。

例えば、「異常の種類」が「サービス間のネットワークタイムアウト」である場合について考える。この場合の「異常の名前」は「NW_timeout」である。「ロジック」は、「[COMMAND: “<実行するコマンド>”]」であって、この“<実行するコマンド>”を実行することにより「サービス間のネットワークタイムアウト」という異常が解消される。

そして、ロジック生成部４８は、「[COMMAND: “<実行するコマンド>”]」というロジックを生成する。

なお、「DBへの接続エラー」のように、ロジックとして異常を解消させるためのスクリプトを用いてもよい。

再び図７を参照する。ロジック実行部４９は、ロジック生成部４８が生成したロジックを実行することにより、異常の解消を試みる処理部である。なお、ロジック生成部４８は、ある異常の異常情報リソース４４の「Retry_count」が予め定めておいた閾値を超えている場合には、当該異常に対するロジックの実行を停止する。この場合、ロジック生成部４８は、残りの異常のうちで優先度が最も高い異常に対してロジックを実行することになる。

運用ポリシ生成部３４は、制御部４２がサービス情報２７から取得したSLAに基づいて業務システム２１の運用ポリシを生成する処理部である。

図１３は、運用ポリシの模式図である。運用ポリシは、コンテナ２４のリソース使用率の制御のためのパラメータとサービス２３間の通信を制御するためのサイドカープロキシ２５の設定パラメータである。そのような設定パラメータとしては、サービス情報２７における「Name」、「Id」、「Priority」、「Stdout_path」、「Logfile_path」、「Internalcmd_path」、及び「Operation_type」の各パラメータがある。これらの値の初期値は運用者によって設定されるが、業務システム２１の運用の開始と共に運用ポリシ生成部３４が自動で調節する。例えば、運用ポリシ生成部３４は、業務システム２１がSLAを満たすようにこれらの設定パラメータを更新する。また、運用ポリシ生成部３４は、更新した運用ポリシを運用ポリシデータベース５２に格納する。

再び図７を参照する。運用ポリシ適用部３５は、運用ポリシデータベース５２を参照することにより、各コンテナ２４に運用ポリシを適用する処理部である。

受付部３６は、運用者からロジックデータベース５１に含まれる個々のパラメータの入力を受け付け、それを記憶部３３に格納する処理部である。また、受付部３６は、運用者から運用ポリシの初期値の入力を受け付け、それを記憶部３３の運用ポリシデータベース５２に格納する。

次に、業務システム１２の運用を開始するときの処理の流れについて説明する。

図１４は、業務システム１２の運用を開始するときの処理の流れを示すフローチャートである。

まず、受付部３６が、運用者から運用ポリシ（図１３参照）の個々のパラメータの初期値の入力を受け付け、それらを運用ポリシデータベース５２に格納する（ステップＳ１１）。

次に、運用ポリシ生成部３４が運用ポリシデータベース５２を参照して運用ポリシを生成する（ステップＳ１２）。

次いで、運用ポリシ適用部３５が、運用ポリシデータベース５２を参照して運用ポリシを取得する（ステップＳ１３）。

続いて、運用ポリシ適用部３５が、取得した運用ポリシを各コンテナ２４に適用する（ステップＳ１４）。

次に、受付部３６が、運用者からロジックデータベース５１の個々のパラメータの入力を受け付け、それを記憶部３３に格納する（ステップＳ１５）。

次いで、ロジック生成部４８がこれらのパラメータからロジックデータベース５１を作成し、それを記憶部３３に格納する（ステップＳ１６）。

以上により、業務システム１２の運用を開始するときの基本的な処理を終える。

次に、本実施形態に係る異常対処方法について説明する。

図１５は、本実施形態に係る異常対処方法のフローチャートである。まず、運用ポリシ適用部３５が運用ポリシデータベース５２を参照し、運用ポリシに変更がある場合には変更後の運用ポリシを各コンテナ２４に適用する（ステップＳ２１）。

次いで、サイドカープロキシ２５が、サービス情報２７に含まれる各項目の情報を、当該サイドカープロキシ２５と同じサービス２３内のコンテナ２４から収集し、それらをサービス情報取得部４１に通知する（ステップＳ２２）。

次に、サービス情報取得部４１が各サイドカープロキシ２５からサービス情報２７を取得する（ステップＳ２３）。

次いで、制御部４２がサービス情報２７を解析する（ステップＳ２４）。例えば、制御部４２は、通信テーブル２３ｂに基づいて、複数のサービス２３同士の依存関係を示すサービストポロジを生成する。また、制御部４２は、サービス情報２７に基づいて業務システム１２のSLAを特定する。

次に、制御部４２が、サービス情報２７を解析した結果、サービストポロジが変更されたかを判定する（ステップＳ２５）。

そして、サービストポロジが変更されたと判定された場合（ステップＳ２５：肯定）はステップＳ２６に移る。ステップＳ２６では、運用ポリシ生成部３４が、変更後のサービストポロジにとって望ましい運用ポリシを生成し、それを運用ポリシデータベース５２に格納する。

一方、サービストポロジが変更されていないと判定された場合（ステップＳ２５：否定）はステップＳ２７に移る。

ステップＳ２７においては、制御部４２が、サービス情報２７を解析した結果、業務システム１２のSLAが基準を超えたかを判定する。ここで、SLAが基準を超えたと判定された場合（ステップＳ２７：肯定）は前述のステップＳ２６に移る。ステップＳ２６では、運用ポリシ生成部３４が、業務システム１２のSLAが基準を満たすように運用ポリシを変更する。

一方、SLAが基準を超えていないと判定された場合（ステップＳ２７：否定）はステップＳ２８に移る。

ステップＳ２８においては、制御部４２が、コンテナ２４に異常が発生したかを判定する。例えば、制御部４２は、サービス情報２７の「Status」が「Error」となっている場合に、サービス情報２７の「Name」が示すサービス２３に含まれるコンテナ２４に異常が発生したと判定する。

ここで、異常は発生していないと判定された場合（ステップＳ２８：否定）はステップＳ２９に移る。

ステップＳ２９においては、制御部４２が、業務システム１２が業務を終了したかを判定する。ここで、業務を終了していないと判定された場合（ステップＳ２９：否定）にはステップＳ２２に戻る。一方、業務を終了したと判定した場合（ステップＳ２９：肯定）は処理を終える。

また、前述のステップＳ２８において異常が発生したと制御部４２が判定した場合にはステップＳ３０の異常対処処理を行い、その後ステップＳ２９に移る。以上により、図１５のフローチャートの基本的な処理を終える。

図１６は、前述のステップＳ３０の異常対処処理のフローチャートである。

まず、制御部４２が、サービス情報２７に基づいて異常情報リソース４４を生成し、それを記憶部３３に格納する（ステップＳ４１）。このとき、制御部４２は、サービス情報２７に基づいて異常の種類を特定し、その異常の種類に応じた「Kind」の値を異常情報リソース４４に設定する。また、制御部４２は、異常対処部３２に対して異常の対処を依頼する。

次に、異常対処部３２の異常特定部４６が、制御部４２からの依頼を受けて、異常の種類を特定する（ステップＳ４２）。例えば、異常特定部４６は、記憶部３３にある異常情報リソース４４を読み込み、その異常情報リソース４４の「Kind」から異常の種類を特定する。また、異常特定部４６は、異常への対処のスケジューリングを行うようにスケジューリング部４７に依頼する。

次に、スケジューリング部４７が、異常特定部４６からの依頼を受けて、異常への対処のスケジューリングを行う（ステップＳ４３）。例えば、スケジューリング部４７は、異常情報リソース４４の「Priority」から異常の優先度を特定し、優先度が高い異常から順に処理をするようにスケジューリングを行う。

次いで、ロジック生成部４８が、異常特定部４６が特定した異常の種類ごとに、当該異常を解消させるロジックを生成する（ステップＳ４４）。一例として、ロジック生成部４８は、記憶部３３に格納されているロジックデータベース５１を参照することにより、ステップＳ４２で特定した異常の種類に対応するロジックを特定し、当該ロジックを生成する。

次に、ロジック実行部４９が、ロジック生成部４８が生成したロジックを実行する（ステップＳ４５）。

次いで、制御部４２がサービス情報２７を新たに取得し、そのサービス情報２７に基づいて異常情報リソース４４を生成する（ステップＳ４６）。

次に、ロジック実行部４９が、ロジックを実行したことにより異常が解消されたかを判定する（ステップＳ４７）。例えば、ロジック実行部４９は、ステップＳ４６で生成した異常情報リソース４４の「Status」が「Running」の場合に異常が解消されたと判定し、「Status」が「Error」のままの場合に異常は解消されていないと判定する。

ここで、異常が解消されたと判定された場合（ステップＳ４７：肯定）はステップＳ５０に移る。

ステップＳ５０においては、制御部４２が、解消された異常に対応した異常情報リソース４４を記憶部３３から削除する。

一方、異常が解消されていないと判定された場合（ステップＳ４７：否定）はステップＳ４８に移る。

ステップＳ４８においては、ロジック実行部４９が、異常対処のリトライ回数を示す異常情報リソース４４の「Retry_count」が閾値を超えたかを判定する。その閾値は、ある異常への対処を繰り返すことで他の異常への対処が遅れるのを防止する観点から設定される。

ここで、閾値を超えたと判定した場合（ステップＳ４８：肯定）は、前述のステップＳ５０に移り、制御部４２が、ステップＳ４５で対処した異常に係る異常情報リソース４４を記憶部３３から削除する。これにより、特定の異常に対する異常を何度も繰り返すことで他の異常への対処が遅れるのを防止することができる。

なお、この場合は異常が解消されていないことになるが、制御部４２が表示装置等にアラートを表示することで、運用者に異常が解消されていないことを通知してもよい。

一方、閾値を超えていないと判定した場合（ステップＳ４８：否定）はステップＳ４９に移る。

ステップＳ４９においては、対処していない異常があるかを制御部４２が判定する。ここで、対処していない異常があると判定した場合（ステップＳ４９：肯定）はステップＳ４３に戻る。

一方、対処していない異常がないと判定した場合（ステップＳ４９：肯定）は処理を終えて呼び出し元に戻る。

以上により、本実施形態に係る異常対処方法の基本的な処理を終える。

上記した本実施形態によれば、異常に対処すべき優先度を示す異常情報リソース４４の「Priority」を制御部４２が設定し（ステップＳ４１）、その優先度の順に異常に対処する（ステップＳ４３、Ｓ４５）。そのため、重篤な異常の対処が後回しにされるのを抑制でき、異常への対処が遅れるのを抑制することができる。

更に、ロジック生成部４８が異常の種類ごとにロジックを生成するため（ステップＳ４４）、当該異常を解消するのに相応しいロジックを自動で実行でき、業務システム１２の運用者が対処内容を判断する必要がない。

しかも、ステップＳ４８においてある異常についてのリトライ回数が閾値を超えたと判定された場合には、ロジック実行部４９がその異常への対処を停止する。そのため、同一の異常への対処が何度も行われることで他の異常への対処が遅れるのを抑制することができる。

次に、異常対処の具体例について説明する。

・第１例
図１７は、第１例に係る異常対処について説明するための模式図である。

図１７に示すように、第１例では、「ServiceA」～「ServiceD」の４つのサービス２３で業務システム１２が実現される場合を想定する。また、これらのサービス２３のうちで、「ServiceA」と「ServiceD」の２つのコンテナ２４に異常が発生したものとする。

図１８（ａ）は、この場合のサービス情報２７の模式図である。図１８（ａ）に示すように、コンテナ２４に異常が発生していない「ServiceB」と「ServiceC」の「Status」は「Running」となる。一方、コンテナ２４に異常が発生した「ServiceA」と「ServiceD」の「Status」は「Error」となる。

図１８（ｂ）は、第１例において制御部４２が生成した異常情報リソース４４の模式図である。異常情報リソース４４は、コンテナ２４に異常が発生したサービス２３ごとに制御部４２が生成するため、この例では制御部４２が「ServiceA」と「ServiceD」の異常情報リソース４４を生成する。

ここでは、制御部４２が、「ServiceD」に係る異常情報リソース４４の「Priority」を「0」に設定し、「ServiceA」に係る異常情報リソース４４の「Priority」をそれよりも高い「1」に設定したものとする。

図１９は、この場合にロジック生成部４８が生成したロジックの模式図である。

そのロジックには、「ServiceA」のコンテナ２４の異常を解消させるスクリプトと、「ServiceD」のコンテナ２４の異常を解消させるスクリプトが記述される。前述のように「ServiceA」の異常の優先度は「ServiceD」のそれよりも高い。そのため、スケジューリング部４７は、「ServiceA」への対処が「ServiceD」への対処よりも先になるようにスケジューリングを行う。このスケジューリングの結果、ロジック生成部４８は、「ServiceA」のコンテナ２４の異常を解消させるためのスクリプトを、「ServiceD」のコンテナ２４の異常を解消させるためのスクリプトよりも先に記述する。

これにより、ロジック実行部４９は、優先度が高い「ServiceA」のコンテナ２４の異常から先に対処し、その対処を終えた後に「ServiceD」のコンテナ２４の異常に対処する。

その結果、優先度が高く重篤な異常への対処が遅れるのを抑制することができ、業務システム１２を安定的に稼働させることができる。しかも、制御部４２が自動的に異常の優先度を設定し、その優先度に従ってスケジューリング部４７が自動的にスケジューリングを行うため、業務システム１２の運用者が異常への対応順を決める必要もない。

・第２例
図２０は、第２例に係る異常対処について説明するための模式図である。図２０に示すように、第２例では、「ServiceA1」、「ServiceA2」、「ServiceA3」、及び「ServiceB」の４つのサービス２３と、「DatabaseA」というデータベース２９とによって業務システム２１が実現されている場合を想定する。また、図２０では、サービス２３同士の依存関係を矢印で示している。その矢印の根元のサービス２３は、通信パケットの送信元のコンテナ２４が起動しているサービスを示す。また、矢印の先端のサービス２３は、通信パケットの送信先のコンテナ２４を示す。

なお、データベース２９に向かう矢印は、矢印の根元のサービス２３内のコンテナ２４がデータベース２９にアクセスすることを示す。

以下では、「ServiceA1」と「ServiceA2」の各々のコンテナ２４に異常があった場合について説明する。

図２１は、この場合のサービス情報２７を示す模式図である。前述のように「ServiceA1」と「ServiceA2」の各々のコンテナ２４に異常があるため、これらのサービス２３における「Status」は「Error」となる。

また、「Using_db」と「Using_service」の各項目には、図２０の依存関係を反映した値が格納される。例えば、「ServiceA1」の「Using_service」には「ServiceA2」と「ServiceA3」が格納される。なお、「ServiceA1」は「DatabaseA」にアクセスしないため、アクセスしないことを示す「NULL」が「Using_db」に格納される。

一方、「ServiceA2」は「DatabaseA」にアクセスするため、「ServiceA2」の「Using_db」には「DatabaseA」が格納される。また、「ServiceA2」は他のサービス２３に依存しないため、「ServiceA2」の「Using_service」は「NULL」となる。

なお、「ServiceA3」の「Operation_type」における「CircuitBreakOK」は、「ServiceA3」のサービス２３を実行しているコンテナ２４に異常が発生した場合、業務システム２１から「ServiceA3」を削除してもよいことを示す。

図２２は、図２１のサービス情報２７を利用して制御部４２が生成したサービストポロジの模式図である。

ここでは、制御部４２は、サービストポロジを表現する隣接リストを生成する。この隣接リストの１行目の「ServiceA1-ServiceA2-ServiceA3」は、「ServiceA1」の通信先のサービス２３が「ServiceA2」と「ServiceA3」であることを示す。２行目の「ServiceA2-DatabaseA」は、「ServiceA2」が「DatabaseA」にアクセスすることを示す。また、最後の行の「DatabaseA」は、「DatabaseA」のアクセス先がないことを示す。

図２３は、本例において制御部４２が生成した異常情報リソース４４の模式図である。

図２３の例では、「ServiceA1」と「ServiceA2」の各異常に対してロジック実行部４９が既に１回ロジックを実行しており、それでも異常が解消されなかった場合を示す。この場合、「ServiceA1」と「ServiceA2」のそれぞれの「Status」は「Failed」となる。

また、「ServiceA1」と「ServiceA2」のそれぞれの「Priority」はいずれも「1」であるとする。

このように二つのサービス２３の「Priority」が同一の場合は、スケジューリング部４７は、通信パケットの送信先のサービス２３に含まれるコンテナ２４から先にロジックを実行するようにスケジューリングする。この例では通信パケットの送信先は「ServiceA2」であるため、スケジューリング部４７は、「ServiceA1」よりも先に「ServiceA2」のロジックが実行されるようにスケジューリングする。

そのスケジューリングを受けて、ロジック実行部４９は、「ServiceA1」よりも先に「ServiceA2」のロジックを実行し、「ServiceA2」のコンテナ２４の異常の解消を試みる。

これとは逆に「ServiceA1」から先に対処することも考えられるが、この場合は仮に「ServiceA1」の異常が解消しても、送信先の「ServiceA2」で異常が発生しているため、「ServiceA1」にすぐに異常が発生することがある。

これに対し、本例では送信先の「ServiceA2」から先に対処し、その次に「ServiceA1」の対処を行う。そのため、「ServiceA2」の異常が解消した後に「ServiceA1」の対処を行っているときに「ServiceA2」で再び異常が発生する可能性が少なく、異常への無駄な対処を抑制できる。

（ハードウェア構成）
次に、本実施形態に係る異常対処装置２２のハードウェア構成について説明する。

図２４は、本実施形態に係る異常対処装置２２のハードウェア構成図である。

図２４に示すように、異常対処装置２２は、記憶装置２２ａ、メモリ２２ｂ、プロセッサ２２ｃ、通信インターフェース２２ｄ、入力装置２２ｆ、表示装置２２ｇ、及び媒体読取装置２２ｈを有する。これらの各部は、バス２２ｊにより相互に接続される。

このうち、記憶装置２２ａは、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性のストレージであって、本実施形態に係る異常対処プログラム１００を記憶する。

なお、異常対処プログラム１００をコンピュータが読み取り可能な記録媒体２２ｉに記録し、媒体読取装置２２ｈを介してプロセッサ２２ｃにその異常対処プログラム１００を読み取らせるようにしてもよい。

そのような記録媒体２２ｉとしては、例えばCD-ROM (Compact Disc - Read Only Memory)、DVD (Digital Versatile Disc)、及びUSB (Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体２２ｉとして使用してもよい。これらの記録媒体２２ｉは、物理的な形態を持たない搬送波のような一時的な媒体ではない。

更に、公衆回線、インターネット、及びLAN等に接続された装置に異常対処プログラム１００を記憶させてもよい。その場合は、プロセッサ２２ｃがその異常対処プログラム１００を読み出して実行すればよい。

一方、メモリ２２ｂは、DRAM(Dynamic Random Access Memory)等のようにデータを一時的に記憶するハードウェアである。

プロセッサ２２ｃは、異常対処装置２２の各部を制御するCPUやGPU(Graphical Processing Unit)等のハードウェアである。また、プロセッサ２２ｃは、メモリ２２ｂと協働して異常対処プログラム１００を実行する。

これにより、図７に示した異常対処装置２２の解析部３１、異常対処部３２、運用ポリシ生成部３４、運用ポリシ適用部３５、及び受付部３６が実現される。

また、記憶部３３（図７参照）は、記憶装置２２ａとメモリ２２ｂによって実現される。

更に、通信インターフェース２２ｄは、異常対処装置２２をインターネットやLAN(Local Area Network)等のネットワークに接続するためのNIC(Network Interface Card)等のハードウェアである。この通信インターフェース２２ｄを介して、コンテナ２４やコンテナ基盤２６の各々と異常対処装置２２が通信することができる。

また、入力装置２２ｆは、ロジックデータベース５１に含まれる各パラメータや運用ポリシの初期値を運用者が入力するためのキーボードやマウス等のハードウェアである。

表示装置２２ｇは、入力装置２２ｆを介して運用者が異常対処装置２２に入力した各種のデータを表示するための液晶ディスプレイ等の表示デバイスである。

媒体読取装置２２ｈは、記録媒体２２ｉを読み取るためのCDドライブ、DVDドライブ、及びUSBインターフェース等のハードウェアである。

１…業務システム、２…コンテナ基盤、２ａ…ヘルスチェック機構、４…サービス、５…コンテナ監視ソフトウェア、６…操作端末、１２…業務システム、２０…異常対処システム、２１…業務システム、２２…異常対処装置、２３…サービス、２３ａ…記憶領域、２３ｂ…通信テーブル、２４…コンテナ、２５…サイドカープロキシ、２６…コンテナ基盤、２７…サービス情報、２９…データベース、３１…解析部、３２…異常対処部、３３…記憶部、３４…運用ポリシ生成部、３５…運用ポリシ適用部、３６…受付部、４１…サービス情報取得部、４２…制御部、４４…異常情報リソース、４６…異常特定部、４７…スケジューリング部、４８…ロジック生成部、４９…ロジック実行部、５１…ロジックデータベース、５２…運用ポリシデータベース、１００…異常対処プログラム。

Claims (5)

1. 複数のコンテナの各々に発生した異常の優先度を設定し、
   前記異常の種類ごとに、当該異常を解消させるロジックを生成し、
   前記優先度の順に、前記異常に対して前記ロジックを実行する、
   処理をコンピュータに実行させるための異常対処プログラム。
2. 複数の前記コンテナのうち、データの送信元の第１のコンテナと送信先の第２のコンテナとを特定し、
   前記第１のコンテナの前記異常と前記第２のコンテナの前記異常の各々の前記優先度が同じ場合は、前記第２のコンテナの前記異常から先に前記ロジックを実行する、
   処理を更に前記コンピュータに実行させるための請求項１に記載の異常対処プログラム。
3. 同一の前記異常に対する前記ロジックの実行回数が閾値を超えた場合に、当該異常に対する前記ロジックの実行を停止する、
   処理を更に前記コンピュータに実行させるための請求項１に記載の異常対処プログラム。
4. 複数のコンテナの各々に発生した異常の優先度を設定する制御を行う制御部と、
   前記異常の種類ごとに、当該異常を解消させるロジックを生成する生成部と、
   前記優先度の順に、前記異常に対して前記ロジックを実行する実行部と、
   を有することを特徴とする異常対処システム。
5. コンピュータが、
   複数のコンテナの各々に発生した異常の優先度を設定し、
   前記異常の種類ごとに、当該異常を解消させるロジックを生成し、
   前記優先度の順に、前記異常に対して前記ロジックを実行する、
   処理を実行することを特徴とする異常対処方法。
   

Images