JP2023035466A - 情報処理プログラム、情報処理方法、および情報処理装置 - Google Patents

Abstract

【課題】マイクロサービス化に適した部分を容易に把握できるようにする。【解決手段】情報処理装置１０は、複数のソフトウェア部品３ａ，３ｂ，・・・を含むソフトウェア２実行時にソフトウェア部品３ａ，３ｂ，・・・それぞれにより実現される機能４ａ～４ｌの呼び出し頻度を示す呼び出し頻度情報に基づいて、呼び出される頻度が第１の基準より高い第１の機能４ｇ，４ｈに対応する第１のソフトウェア部品を特定する。情報処理装置１０は、ソフトウェア２実行時の複数の機能４ａ～４ｌ間での呼び出し関係に基づいて、第２の基準より多くの呼び出し元が存在する第２の機能４ｈに対応する第２のソフトウェア部品を特定する。そして情報処理装置１０は、第１のソフトウェア部品に該当し、かつ第２のソフトウェア部品に該当しない第３のソフトウェア部品を、マイクロサービス化の対象として提示する。【選択図】図１

Description

本発明は、情報処理プログラム、情報処理方法、および情報処理装置に関する。

コンピュータシステムのソフトウェア構築に関するアーキテクチャとして、モノリシックなアーキテクチャがある。モノリシックなアーキテクチャは、ソフトウェアで実現される複数の機能が１つのソフトウェアモジュールで実現されたものである。モノリシックなアーキテクチャは、一枚岩のアーキテクチャとも呼ばれる。

それに対してマイクロサービスアーキテクチャという概念が広がってきている。マイクロサービスアーキテクチャは、従来のような一枚岩のアーキテクチャではなく、独立性の高い機能単位のサービスの組み合わせによりソフトウェアを開発・提供する考え方である。マイクロサービスアーキテクチャで設計されたソフトウェアは機能間が疎結合になっている。そのため、ソフトウェア改修時の影響調査やソースファイルの修正が容易となる。またソフトウェア改修時のテストの範囲を限定でき、短期間での新規機能の提供または柔軟なスケールアウトが可能となる。

モノリシックなアーキテクチャで作成された既存のシステム（モノリシックシステム）についても、マイクロサービスアーキテクチャのシステムに変更することで、システムのソースの修正やスケールアウトの柔軟性を向上させることができる。このようなマイクロサービス化に関する技術としては、例えばコンテナ化、スケーラブル、かつフレキシブルな動作環境において実行されるマイクロサービスとしての展開のためにモノリシックレガシーアプリケーションを区分するためのシステムが提案されている。

特表２０２０－５１８０７３号公報

既存のモノリシックシステムのマイクロサービス化は、システムの作り替えが発生するため移行コストが高く、作り直し後の機能不全や入替え時の一時業務停止などのリスクを伴う。そこで例えば、最小限のコスト・リスクで顧客ニーズに素早く対応できるシステムに作り替えるために、アクセス頻度が高く修正が頻繁する部分のみをマイクロサービス化することが求められる。

しかし、従来の技術では、既存のシステムのなかからマイクロサービス化するのに適した部分を正しく特定することは困難である。そのため既存のモノリシックシステムの部分的なマイクロサービス化によるシステム改修時の柔軟性などの性能向上が困難となっている。

１つの側面では、本件は、マイクロサービス化に適した部分を容易に把握できるようにすることを目的とする。

１つの案では、以下の処理をコンピュータに実行させる情報処理プログラムが提供される。
コンピュータは、複数のソフトウェア部品を含むソフトウェア実行時に複数のソフトウェア部品それぞれにより実現される機能の呼び出し頻度を示す呼び出し頻度情報に基づいて、呼び出される頻度が第１の基準より高い第１の機能に対応する第１のソフトウェア部品を特定する。コンピュータは、ソフトウェア実行時の機能間での呼び出し関係に基づいて、第２の基準より多くの呼び出し元が存在する第２の機能に対応する第２のソフトウェア部品を特定する。そしてコンピュータは、第１のソフトウェア部品に該当し、かつ第２のソフトウェア部品に該当しない第３のソフトウェア部品を、マイクロサービス化の対象として提示する。

１態様によれば、マイクロサービス化に適した部分の特定が可能となる。

第１の実施の形態に係る情報処理方法の一例を示す図である。 システム構成の一例を示す図である。 サーバのハードウェアの一例を示す図である。 モノリシックアーキテクチャとマイクロサービスアーキテクチャとのスケールアウトの例を示す図である。 部分的なマイクロサービス化の一例を示す図である。 修正頻度の多い機能抽出の一例を示す図である。 処理頻度の多い機能抽出の一例を示す図である。 コア部分または共通処理部分の除外の一例を示す図である。 呼び出しシーケンス内の機能抽出の一例を示す図である。 マイクロサービス化を支援するためのサーバの機能の一例を示す図である。 マイクロサービス化対象機能の特定のために取得する情報の一例を示す図である。 修正頻度情報の一例を示す図である。 アクセス先情報の一例を示す図である。 ＪＯＩＮ情報の一例を示す図である。 マイクロサービス化候補機能からのマスタテーブルへアクセスする機能の除外処理の一例を示す図である。 ＡＰＩ呼び出し頻度情報の一例を示す図である。 画面別ＡＰＩ呼び出し情報の一例を示す図である。 呼び出しシーケンス情報の一例を示す図である。 特定されたマイクロサービス化対象機能の一例を示す図である。 マイクロサービス化機能提案処理の手順の一例を示すフローチャートである。 マイクロサービス化対象特定処理の手順の一例を示すフローチャートである。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
まず第１の実施の形態について説明する。第１の実施の形態は、既存のシステムにおけるマイクロサービス化に適した部分を検出し、提示する情報処理方法である。

図１は、第１の実施の形態に係る情報処理方法の一例を示す図である。図１には、第１の実施の形態に係る情報処理方法を実現する情報処理装置１０が示されている。情報処理装置１０は、例えば所定の情報処理プログラムを実行することにより、第１の実施の形態に係る情報処理方法を実施することができる。

情報処理装置１０は、記憶部１１と処理部１２とを有する。記憶部１１は、例えば情報処理装置１０が有するメモリまたはストレージ装置である。処理部１２は、例えば情報処理装置１０が有するプロセッサまたは演算回路である。

記憶部１１は、複数のソースファイル１ａ，１ｂ，・・・と、複数のソースファイル１ａ，１ｂ，・・・に基づいて生成されたソフトウェア２とを記憶する。ソフトウェア２は、例えば３階層の各階層に対応する実行形式のプログラム２ａ，２ｂ，２ｃが含まれる。例えばソースファイル１ａ，１ｂ，・・・に対してコンパイルおよびリンクなどの処理を行った結果、プログラム２ａ，２ｂ，２ｃが生成される。

プログラム２ａ，２ｂ，２ｃには、複数のソフトウェア部品３ａ，３ｂ，・・・が含まれる。ソフトウェア部品３ａ，３ｂ，・・・それぞれは、いずれかのソースファイル１ａ，１ｂ，・・・に基づいて生成される。そのためソフトウェア部品３ａ，３ｂ，・・・は、例えば生成元となったソースファイルのファイル名によって識別できる。

処理部１２は、ソフトウェア２を実行することで既存システム４を動作させる。既存システム４は、プレゼンテーション層、アプリケーション層、およびデータ層を有する３階層のシステムである。プレゼンテーション層の機能４ａ～４ｃは、例えば処理部１２がプログラム２ａを実行することにより実現される。アプリケーション層の機能４ｄ～４ｊは、例えば処理部１２がプログラム２ｂを実行することにより実現される。データ層の機能４ｋ～４ｌは、例えば処理部１２がプログラム２ｃを実行することにより実現される。

既存システム４が有する各機能４ａ～４ｌは、ソフトウェア２内のソフトウェア部品３ａ，３ｂ，・・・によって実現されている機能である。各機能４ａ～４ｌが実行する処理の手順は、対応するソフトウェア部品の生成元となるソースファイルに定義されている。したがって、既存システム４の一部の機能を修正する場合、その機能を実現するためのソフトウェア部品に対応するソースファイルを修正することとなる。

情報処理装置１０は、既存システム４によりユーザにサービスを提供する。既存システム４を利用するユーザから提供されるサービスに対するニーズは随時変化する。そのため情報処理装置１０の管理者は、ユーザのニーズに応じて、既存システム４により提供するサービスの機能を適宜修正する。

なお図１に示す既存システム４は例えばモノリシックシステムである。この場合、既存システム４の一部の機能を修正する場合、その機能を含むプログラム全体の作り直しが行われる。また修正後の機能を実装するには、既存システム４全体が一時的に停止される。

既存システム４の機能の修正を容易にする方法の１つとして、既存システム４をマイクロサービス化しておくことが考えられる。なお既存システム４全体をマイクロサービス化すると膨大な移行コストが発生する上に、安定稼働しているシステムの品質低下リスクもある。他方、ユーザのニーズに応じた修正が発生しやすい機能は、既存システム４内の機能４ａ～４ｌのうちの一部である。そこで情報処理装置１０の処理部１２は、ユーザのニーズに応じた修正が発生しやすい機能に対応するプログラム部品を特定し、マイクロサービス化が有効なプログラム部品として情報処理装置１０の管理者に提示する。

例えば処理部１２は、ソフトウェア２実行時に複数のソフトウェア部品３ａ，３ｂ，・・・それぞれにより実現される機能４ａ～４ｌの呼び出し頻度を示す呼び出し頻度情報を取得する。そして処理部１２は、呼び出し頻度情報に基づいて、呼び出される頻度が第１の基準より高い機能４ｇ，４ｈ（第１の機能）に対応する第１のソフトウェア部品を特定する。第１の基準は、例えば機能４ａ～４ｌを呼び出し頻度の高い順にソートした場合における、上位から所定の順番の機能の呼び出し頻度で表される。この場合、例えば呼び出し頻度でソートしたときの機能の順番が上位から所定の割合以内であれば、その機能に対応するソフトウェア部品は第１のソフトウェア部品として特定される。図１の例では、機能４ｇと機能４ｈとに対応するソフトウェア部品が、第１のソフトウェア部品として特定されたものとする。

また処理部１２は、ソフトウェア２実行時の機能４ａ～４ｌ間での呼び出し関係に基づいて、第２の基準より多くの呼び出し元が存在する機能４ｈ（第２の機能）に対応する第２のソフトウェア部品を特定する。第２の基準は、例えば機能を呼び出すことのある上位の層の機能の数の、上位の層の機能の総数に占める割合で表される。この場合、機能を呼び出すことのある上位の層の機能の数が、上位の層の機能の総数の所定の割合以上であれば、その機能に対応するプログラム部品は第２のソフトウェア部品として特定される。

図１の例では、アプリケーション層の機能４ｈは、１つ上の層であるプレゼンテーション層の３つの機能４ａ～４ｃのいずれからも呼び出される。第２の基準が、上位の層の機能のうちの半数と定められている場合、機能４ｈに対応するソフトウェア部品は第２のソフトウェア部品として特定される。

処理部１２は、第１のソフトウェア部品に該当し、かつ第２のソフトウェア部品に該当しない第３のソフトウェア部品を、マイクロサービス化の対象として提示する。図１の例では、機能４ｇ，４ｈに対応するソフトウェア部品が第１のソフトウェア部品であり、機能４ｈに対応するソフトウェア部品が第２のソフトウェア部品である。そのため機能４ｇに対応するソフトウェア部品が第３のソフトウェア部品である。この場合、機能４ｇに対応するソフトウェア部品を示す情報（例えばそのソフトウェア部品に対応するソースファイルのファイル名）が、マイクロサービス化が有効なソフトウェア部品として提示される。

このようにして、上位の所定数以上の機能から呼び出させるコアな機能ではないものの、呼び出される頻度が所定以上に高い機能のソフトウェア部品が、マイクロサービス化が有効なソフトウェア部品として提示される。これにより、マイクロサービス化に有効な最小限のソフトウェア部品が提示され、管理者は、提示内容に基づいて、効率的にマイクロサービス化を実施することができる。

また処理部１２は、複数のソフトウェア部品３ａ，３ｂ，・・・それぞれの修正頻度を示す修正頻度情報に基づいて、修正頻度が第３の基準より高い第４のソフトウェア部品を特定してもよい。この場合、処理部１２は、第３のソフトウェア部品の提示では、第１のソフトウェア部品と第４のソフトウェア部品とに該当し、第２のソフトウェア部品に該当しないソフトウェア部品を、第３のソフトウェア部品とする。なお第３の基準は、例えば修正頻度によって機能を降順にソートした場合の上位から所定の順番の機能の修正頻度である。これにより第３のソフトウェア部品を、修正頻度が上位の所定の割合に含まれるソフトウェア部品に限定することができる。その結果、過去にほとんど修正されていないソフトウェア部品について、マイクロサービス化が有効なソフトウェア部品であると提示されることが抑止され、マイクロサービス化が有効なソフトウェア部品の判定精度が向上する。

また処理部１２は、データベースへのデータアクセスログに基づいて、データベース内のマスタデータにアクセスする第５の機能に対応する第５のソフトウェア部品を特定することもできる。この場合、処理部１２は、第５のソフトウェア部品を第３のソフトウェア部品から除外する。マスタデータにアクセスする機能は、既存システム４におけるコア機能または多数の処理で利用される共通機能である可能性がある。コア機能または共通機能は、ユーザのニーズに応じて修正する部分ではない。そのため、マスタデータにアクセスする機能に対応する第５のソフトウェア部品を第３のソフトウェア部品から除外することで、コア機能または共通機能に対応するソフトウェア部品は、マイクロサービス化が有効なソフトウェア部品であると提示されずに済む。その結果、マイクロサービス化が有効なソフトウェア部品の判定精度が向上する。

処理部１２は、データベースに含まれる複数のデータテーブル間での結合関係に基づいて、第４の基準より多くのデータテーブルに結合されたデータテーブルをマスタデータとして特定することができる。第４の基準は、例えばデータベース内のデータテーブル全体に対する結合されたデータテーブルが占める割合で示される。これによりマスタデータを自動で判別することが可能となる。

また処理部１２は、第３のソフトウェア部品に対応する機能（第３の機能）を含む呼び出しシーケンスに含まれる他の機能（第６の機能）に対応する第６のソフトウェア部品を特定することもできる。例えば処理部１２は、第３のソフトウェア部品に対応する機能を起点として、同一の層内での呼び出し関係を辿って到達可能な他の機能に対応するソフトウェア部品を第６のソフトウェア部品とする。また処理部１２は、第３のソフトウェア部品に対応する機能の呼び出し元となる上位の層の機能に対応するソフトウェア部品を第６のソフトウェア部品に加えてもよい。さらに処理部１２は、第３のソフトウェア部品に対応する機能を含む呼び出しシーケンスによって呼び出される下位の層の機能を第６のソフトウェア部品に加えてもよい。第６のソフトウェア部品を特定した場合、処理部１２は、第３のソフトウェア部品と共に第６のソフトウェア部品を、マイクロサービス化が有効なソフトウェア部品として提示する。

第６のソフトウェア部品は、第３のソフトウェア部品の修正に伴って修正することとなる可能性が高い。そのため第３のソフトウェア部品をマイクロサービス化する場合、第６のソフトウェア部品もマイクロサービス化が有効なソフトウェア部品として提示することで、マイクロサービス化が有効なソフトウェア部品を漏らさず提示することができる。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、３階層のモノリシックシステム内の一部の機能をマイクロサービス化する際に、マイクロサービス化が有効なソフトウェア部品を提示するものである。３階層のシステムとは、画面制御を行うフロント部分のプレゼンテーション層、および画面から要求を受け付けて処理するアプリケーション層、および処理したデータを管理するデータ層で構成されるシステムである。なお第２の実施の形態におけるメソッドは、第１の実施の形態に示した機能４ａ～４ｌの一例である。

図２は、システム構成の一例を示す図である。例えば３階層のモノリシックシステムが構築されたサーバ１００がネットワーク２０に接続されている。サーバ１００は、３階層となるように構築されたソフトウェアを実行することでサービスを提供する、１台または複数台のコンピュータである。ネットワーク２０には、さらに端末３１，３２，・・・が接続されている。端末３１，３２，・・・は、サーバ１００で提供されるサービスを利用するユーザが操作するコンピュータである。例えばユーザは端末３１，３２，・・・を操作することで、端末３１，３２，・・・に対して、サーバ１００へサービス提供の要求を送信させることができる。サーバ１００は、端末３１，３２，・・・のいずれかからの要求に応じて処理を実行し、処理の結果を要求の送信元の端末に送信する。

図３は、サーバのハードウェアの一例を示す図である。サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、ＧＰＵ（Graphics Processing Unit）１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、サーバ１００の補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）を使用することができる。

ＧＰＵ１０４は画像処理を行う演算装置であり、グラフィックコントローラとも呼ばれる。ＧＰＵ１０４には、モニタ２１が接続されている。ＧＰＵ１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取り、または光ディスク２４へのデータの書き込みを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ－ＲＡＭ、ＣＤ－ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ－Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。ネットワークインタフェース１０８は、例えばスイッチやルータなどの有線通信装置にケーブルで接続される有線通信インタフェースである。またネットワークインタフェース１０８は、基地局やアクセスポイントなどの無線通信装置に電波によって通信接続される無線通信インタフェースであってもよい。

サーバ１００は、以上のようなハードウェアによって、第２の実施の形態の処理機能を実現することができる。なお、第１の実施の形態に示した情報処理装置１０も、図３に示したサーバ１００と同様のハードウェアにより実現することができる。

サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、サーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。またサーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

以上のようなハードウェア構成のサーバ１００に構築された３階層のモノリシックシステムは、機能の修正のしやすさ、スケールアップのしやすさなどの点でマイクロサービスアーキテクチャのシステムに劣る。

図４は、モノリシックアーキテクチャとマイクロサービスアーキテクチャとのスケールアウトの例を示す図である。例えばモノリシックアーキテクチャ２００では、複数の機能４１～４４を含むプログラム２１１が、サーバ２１０に実装されている。プログラム２１１は、複数の機能４１～４４が１つの実行体として開発されており、機能４１～４４間の境界もあいまいである。

ここでサーバ２１０の性能が不十分となると、サーバ２１０のスケールアウトが行われる。モノリシックアーキテクチャ２００におけるスケールアウトでは、複数機能の分離が困難である。そのためプログラム２１１と同じ機能４１～４４を有する複数のプログラム２２１，２３１，２４１が複数のサーバ２２０，２３０，２４０に実装される。

マイクロサービスアーキテクチャ３００では、独立性の高いサービスとして、複数の機能４１～４４それぞれが開発される。サーバ３１０には、複数の機能４１～４４を実現するために複数のプログラム３１１～３１４が実装される。複数のプログラム３１１～３１４それぞれは、複数の機能４１～４４のうちの異なる機能を含んでいる。

サーバ３１０をスケールアウトする場合、機能単位に、要求される性能に応じた数の機能を複数のサーバ３２０，３３０，３４０のいずれかに実装することができる。図４の例では、機能４１は不要になったため、サーバ３２０，３３０，３４０のいずれにも実装されていない。サーバ３２０には、それぞれが機能４２を含む３つのプログラム３２１～３２３が実装されている。サーバ３３０には、それぞれが機能４３を含む３つのプログラム３３１～３３３が実装されている。サーバ３４０には、それぞれが機能４４を含む２つのプログラム３４１～３４２が実装されている。

このようにマイクロサービスアーキテクチャ３００のシステムでは機能間が疎結合になっているため、モノリシックアーキテクチャ２００のシステムに比べて柔軟かつ効率的なスケールアウトが可能となる。

またマイクロサービスアーキテクチャ３００では、機能間が疎結合であることにより、機能の改修時の影響調査、ソースプログラムの修正が容易となる。さらにテストの範囲を限定することもでき、短期間での機能改修が可能である。

なおマイクロサービスアーキテクチャ３００における各プログラムで提供されるマイクロサービスの呼び出しは、例えばＲｅｓｔｆｕｌｌ ＡＰＩ（Application Programming Interface）により実施可能である。

以下、モノリシックアーキテクチャ２００で構築された既存の業務システムの一部をマイクロサービスアーキテクチャ３００に置き換えることの重要性についてさらに具体的に説明する。

既存の業務システムはＳｏＲ（System of Record）と呼ばれ、データを正確に記録することを重視したシステムである。一方、最近はＳｏＥ（System of Engagement）と呼ばれるシステムが注目されている。ＳｏＥは、ユーザとのつながりを重視して設計されるシステムである。

例えばクラウドサービス登場やスマートデバイスの浸透でＩＣＴ（Information and Communication Technology）が身近になり、ＩＣＴシステムに対する顧客ニーズが多様化している。顧客ニーズに応えるために顧客とのつながりを重視したＳｏＥシステム開発が適切となる。しかも、通信性能の向上や、アジャイル開発・DevOpsなどの新たな開発手法や考え方、それを支えるＲＥＳＴｆｕｌ ＡＰＩやコンテナ技術など、ＳｏＥに利用可能な様々な技術が発展している。これらの技術の発展と浸透がＳｏＥシステム開発を促進させている。

既存のＳｏＲと言われる業務システムは、正確性、信頼性、安定性を重視し、開発段階において、機能が大きく変化することを想定していないシステムである。しかしＳｏＲで開発された業務システムの中にも、本来は顧客ニーズに素早く応えることで、サービスの質を向上させることができるシステムが存在する。このようなＳｏＲシステムをＳｏＥシステムに容易に移行できることが望まれる。

既存のＳｏＲシステムの多くは、システム内が密に連携したモノリシックシステムである。他方、ＳｏＥシステムにはマイクロサービスアーキテクチャが適している。すなわち、システム内が密に連携したモノリシックシステムでは、システムの一部修正もしくは機能を追加する場合はシステム全体の起動・停止を伴う。そのためモノリシックシステムの機能を修正する場合、最小限の修正にとどめて安定運用を重視することも少なくない。それに対してＳｏＥシステムでは顧客ニーズに素早く応えるため、機能の修正が高頻度で行われるため、マイクロサービスアーキテクチャによりマイクロサービス化しておけば、修正対象の機能に対応するプログラムと、その関連部分を修正するだけですむ。

なお、システムを機能単位に分割して連結するサービス指向アーキテクチャ（ＳＯＡ：Service Oriented Architecture）という考え方も存在する。ただし、ＳＯＡを支える技術（ＣＯＲＢＡ（Common Object Request Broker Architecture）やＳＯＡＰ（Simple Object Access Protocol）など）は使いこなすことが難しく、分割したシステム間の通信で性能上の問題もあり、浸透していない。そこでＳＯＡと考え方はほぼ同等であるがＲＥＳＴｆｕｌ ＡＰＩというシンプルな技術を活用するマイクロサービスアーキテクチャが注目されている。クラウドサービスの発達や通信性能の向上により遠隔のシステム間を連携が容易になったこともあり、遠隔のシステム間でもマイクロサービスを適用する事例も増え始めている。

既存のシステムをマイクロサービス化することにより修正スピードおよび可用性が向上するが、システム全体を作り替えたのでは移行コストが高く、作り直し後の機能不全や入替え時の一時業務停止などのリスクを伴う。そこで最小限のコスト・リスクで、顧客ニーズに素早く対応できるシステムに作り替えるには、アクセス頻度が高く・修正が頻繁する部分に限定してマイクロサービス化するのが適切である。そこでサーバ１００は、ＳｏＲである既存業務システムからマイクロサービス化が有効な部分を特定する。

図５は、部分的なマイクロサービス化の一例を示す図である。既存のシステム用のソフトウェア（既存システムソフトウェア４００）は、プレゼンテーション層、アプリケーション層、およびデータ層の３階層のＳｏＲである。既存業務システムはＳｏＲの下、層ごとのプログラム４１０，４２０，４４０が実装されている。複数のプログラム４１０，４２０，４４０それぞれには、複数の機能が含まれる。

このような３階層システムで構築された既存システムソフトウェア４００内の機能の一部を、マイクロサービス化することができる。例えばシステムの管理者は、プログラム４１０，４２０，４４０それぞれ内の一部の機能に対応する独立のプログラム５１０，５２０，５３０を生成する。生成したプログラム５１０，５２０，５３０は、ＳｏＥによる作り替え後のシステム用のソフトウェア（作り替えシステムソフトウェア５００）としてサーバ１００に実装される。このようにして生成されたプログラム５１０，５２０，５３０が、マイクロサービスとなる。

この際、ＳｏＥシステムとして抽出することで修正スピード向上・可用性向上が見込まれる機能をマイクロサービス化することが重要となる。そこでサーバ１００は、既存システムソフトウェア４００の運用状況を解析し、マイクロサービス化が有用な機能を特定する。サーバ１００の管理者は、特定した機能をマイクロサービス化するためのプログラム５１０，５２０，５３０の作成、サーバ１００へのデプロイなどの作業を行う。

次に、マイクロサービス化が有用な機能の特定の困難性について説明する。
マイクロサービス化の対象となる既存システムソフトウェア４００は１０年以上前に作られたシステムであることが多い。そのため、既存システムソフトウェア４００の設計・開発した担当者がすでに不在であったり、既存システムソフトウェア４００の設計書が残っていなかったりする。従って、開発時の資料だけからマイクロサービス化が適切な部分を特定するのは困難である。

なおマイクロサービス化の対象の決定手法としては、ドメイン駆動設計（ＤＤＤ：Domain-Driven Design）の適用などが良いとされている。ＤＤＤは、システム開発する対象業務を、業務内容を詳細に把握する専門家とソフトウェア開発技術者との間で、意味のある単位（ドメイン）で分割した上でモデル化し、それをマイクロサービスに反映するという考え方である。このＤＤＤは、新規にシステムを設計・開発する際に有効なアプローチである。しかしながらＤＤＤでは、既存システムソフトウェア４００からマイクロサービス化するのに適した機能を抽出するのは困難である。

ここで、既存システムソフトウェア４００において機能を修正する場合、安定稼働を維持しながら修正することが求められる。そのため、修正頻度が多い機能をマイクロサービス化することで、その後の修正の容易性が増す。しかし、修正が多いというだけでは顧客ニーズに応えて頻繁に改修される機能であるとは言い切れない。

顧客ニーズに応えて頻繁に改修される機能（マイクロサービス化対象機能）の特定に利用可能な情報取得技術として、以下の５つの技術が考えられる。
［第１の情報取得技術］
ソースファイルに対する修正内容を蓄積する技術がある。この技術の一例として、後述の継続的インテグレーション（ＣＩ：Continuous Integration）／継続的デリバリー（ＣＤ：Continuous Delivery）技術がある。この技術を利用すれば、修正頻度が多い機能をマイクロサービス化対象機能として特定することができる。修正頻度が多い機能は、マイクロサービス化の効果が高い部分の可能性がある。

ただし既存のＳｏＲシステムは修正による影響が大きい。そのため、頻繁に修正は行われず、以下のように必ずしも修正が多い機能であっても、顧客ニーズに応えて改修を行うことが求められる機能とは限らない。

修正頻度のみでの判断が不適切な第１の理由は、修正頻度が多い機能の修正が、顧客ニーズに応えるための修正ではなく、品質問題で障害修正が頻繁に発生している可能性がある点である。障害発生の抑止のためには、修正頻度が高い機能であっても、安定運用を重視した一枚岩のモノリシックなアーキテクチャのシステム内に留めて置く方がよい。

修正頻度のみでの判断が不適切な第２の理由は、修正頻度が多い機能の修正が、セキュリティ脆弱性対応のために行われている可能性がある点である。セキュリティの脆弱性に応じた修正例としては、顧客の要求を受け付けるプレゼンテーション層でセキュリティ脆弱性が見つかった場合、オープンソースの重大障害や脆弱性の問題が公知となった場合などがある。セキュリティ脆弱性対応のためには、修正頻度が高い機能であっても、一枚岩のモノリシックなアーキテクチャのシステム内に留めておく方がよい。

このように修正頻度のみでは、顧客ニーズに応えて修正される機能を正しく判断できない。そのため、修正頻度のみでマイクロサービス化対象機能を判断するのは適切ではない。

［第２の情報取得技術］
プレゼンテーション層がＷｅｂサイトの場合、Ｗｅｂサイトの動線分析により、どの画面のどの操作が利用者によく利用されているかを分析する技術がある。この技術を利用すると、動線分析によりよく利用された機能を抽出し、その機能をマイクロサービス化対象機能とすることも可能である。

しかし第２の情報取得技術は、Ｗｅｂサイトにしか利用できない。さらに第２の情報取得技術は、Ｗｅｂサイトの動線分析で利用頻度が高い画面・操作をマイクロサービス化対象機能として特定しても、その修正箇所から呼び出されるアプリケーション層・データ層内のマイクロサービス化対象機能が分からない。そのため第２の情報取得技術によるマイクロサービス化対象機能の特定は、操作性の向上という限定的な顧客ニーズへの対応にしかならない。

［第３の情報取得技術］
プレゼンテーション層からアプリケーション層へのＡＰＩ呼び出しを監視して、何の処理（ＡＰＩ）がどれくらいの頻度で実行されているかを観測し、可視化する技術がある。このようなＡＰＩ呼び出しの監視は、例えばＡＰＩ管理ツールと呼ばれるソフトウェアで実現されている。この技術を利用すると、ＡＰＩ管理ツールで見える化された結果から、呼び出しが多い機能をマイクロサービス化が有効な機能と特定することが可能である。

しかし、第３の情報取得技術では、通信頻度を減らしてネットワークへの負荷を軽減させるため、１回の要求でなるべく多くの情報を共通ＡＰＩで送信する。そしてアプリケーション層のプログラム内において、実行する処理をいずれかの機能に振り分けている場合が多い。そのため第３の情報取得技術だけでマイクロサービス化対象機能を特定すると、共通ＡＰＩに応じた処理を実行する可能性があるすべての機能がマイクロサービス化対象機能となり、マイクロサービス化の対象範囲が広くなりすぎてしまう。

［第４の情報取得技術］
１つのプログラム内でのクラスの呼び出し回数を集計する技術がある。例えばＪＡＶＡ（登録商標）であればスタックトレースと呼ばれる機能を用いてクラスの呼び出し頻度を集計できる。この技術を利用することにより、アクセス回数が多いクラスをマイクロサービス化対象機能として特定することが可能である。

しかし保守対象を減らすため、再利用可能な処理は共通クラスとすることが多い。そのため、アクセス回数が多いクラスが必ずしも修正頻度が高いとは判断できない。
［第５の情報取得技術］
データ層のアクセスログから、どのデータに対するアクセス回数が多いかを分析する技術がある。この技術を利用することにより、アクセス回数が多いデータの呼び出し元の機能をマイクロサービス化対象機能と特定することが可能である。

しかし、データ層には、業務運用上で重要なコア情報（例えば従業員名簿・商品管理情報など）を格納するマスタデータと、それに付随して顧客要件に合わせて構成の更新が行われる一般データとが存在する。マスタデータはコア情報となるためアクセス回数が多いものの、基本情報であるためほぼ修正することはない。逆にコア情報を扱う部分に修正を加えてしまうとシステムの基本品質低下のリスクを伴う。このため、アクセス回数が多いデータの呼び出し元の機能をマイクロサービス化対象機能としてしまうと、マイクロサービス化のリスクを回避すべき機能もマイクロサービス化の対象となってしまう。

以上が利用可能な５つの技術である。これらの情報取得技術を個別に適用しても、マイクロサービス化対象機能を適切に特定することは困難である。そこでサーバ１００は、情報取得技術の２つ以上を組み合わせてマイクロサービス化対象機能を特定する。

例えば処理の実行回数が多い機能は、ユーザによる利用頻度が高いと言える。そのため、顧客ニーズの変化によって改修を加えるマイクロサービス化の効果が高い機能である可能性がある。しかし実行頻度の高い機能のなかには、システムの根幹を支えるコア部分、またはどの業務処理でも共通に利用する共通処理部分が含まれる。これらの制御部分は業務の不変的な部分である可能性があり、実行回数が多くても頻繁に改修は発生しないものと推定できる。逆にこれらの制御部分を改修してしまうと、システムの安定稼働についての品質低下リスクを招く。

そこでサーバ１００は、既存システムソフトウェア４００で実装されたプログラム４１０，４２０，４４０で実現される機能のなかから以下の３つの要件を満たす機能を特定する。
［第１の要件］修正頻度が高い（可用性向上・修正スピード向上の必要性が高い）こと。
［第２の要件］処理頻度が高いこと。
［第３の要件］コア部分または共通処理部分に該当しないこと。

サーバ１００は、これらの要件を満たした機能と、その機能を含むメソッド呼び出しシーケンスに含まれる機能とを顧客ニーズの変化に応じて修正する可能性の高い機能として特定する。そしてサーバ１００は、特定した機能を、マイクロサービス化に有効な機能であるとして、管理者に提示する。

図６は、修正頻度の多い機能抽出の一例を示す図である。図６の例では、プレゼンテーション層のプログラム４１０には、６個の機能４１１～４１６が含まれている。アプリケーション層のプログラム４２０には、１８個の機能４２１～４３８が含まれている。データ層のプログラム４４０には、３個の機能４４１～４４３が含まれている。データ層の各機能４４１～４４３は、例えばデータテーブルに対応しており、対応するデータテーブルへのデータの入出力を行う機能である。図６において、矩形の内部にばつ印が示されている機能４１３，４２６，４２８，４３２，４３６は、修正頻度が所定の閾値より多い機能である。

顧客ニーズに素早く対応するためには、例えばアジャイル開発やＤｅｖＯｐｓという短サイクルで製品やサービスに取り込んで顧客ニーズにアジャストしていく開発手法が採られる。このような開発のために、ビルド・検証・リリース作業をバックグラウンドで自動的に実行するＣＩ／ＣＤ技術が発展している。

このＣＩ／ＣＤ技術を利用することで、ソースファイルの修正頻度を把握することができる。例えばサーバ１００は、ＣＩ／ＣＤ技術を用いたソース管理ツールで、プログラム４１０，４２０，４４０のソースファイルを管理する。サーバ１００は、ソース管理ツールによりソースファイルが修正されたことを検知する。そしてサーバ１００は、ソースファイルが修正されたタイミングで、ＣＩ／ＣＤツールに対して、修正が発生したことと合わせて修正箇所を通知する。この際、サーバ１００は、この修正タイミング・修正箇所を蓄積しておく。これにより、修正頻度の多い修正箇所（機能４１３，４２６，４２８，４３２，４３６）を特定することができる。

次にサーバ１００は、修正頻度が多い機能４１３，４２６，４２８，４３２，４３６のうち、処理頻度が多い機能を、マイクロサービス化対象機能の候補（マイクロサービス化候補機能）として抽出する。

図７は、処理頻度の多い機能抽出の一例を示す図である。図７の例では、修正頻度が多い機能４１３，４２６，４２８，４３２，４３６のうちの２つの機能４２８，４３２が、修正頻度が多い機能として抽出されている。

例えばサーバ１００は、ＡＰＩ呼び出しを検知することで、処理頻度が多い機能を抽出することができる。すなわち、サーバ１００は、プレゼンテーション層のプログラム４１０を実行するプロセスから出力されたＡＰＩ呼び出しを検出する。このＡＰＩ呼び出しは、例えばアプリケーション層のプログラム４２０で提供されるＡＰＩを呼び出すＡＰＩ呼び出しである。サーバ１００は、検出したＡＰＩ呼び出しの内容を解読し、プログラム４１０内のどの機能からプログラム４２０内のどの機能への呼び出しなのかを把握する。そしてサーバ１００は、どの画面処理で、どの処理が多く実行されているかを把握する。

なお共通ＡＰＩでＡＰＩ呼び出しが行われる場合がある。その場合、アプリケーション層内の最上位の機能が共通ＡＰＩを取得し、処理を実行するべきＡＰＩを有する機能に処理を依頼する。このときのＡＰＩ呼び出しの実質的な呼び出し先は、アプリケーション層内の下位の層となる。例えばプレゼンテーション層内の機能４１１からのＡＰＩ呼び出しが、アプリケーション層内の２段目の機能４２８によって提供されているＡＰＩの呼び出しであることがあり得る。

またサーバ１００は、スタックトレースの機能を用いて、１つのプログラム内での機能間の呼び出しの発生を検知できる。サーバ１００は、機能間の呼び出し回数を計数することで、同一プログラム内での呼び出しも含めて、処理頻度が多い機能を識別することができる。そしてサーバ１００は、前述のＣＩ／ＣＤ技術により修正頻度が高いと判定された機能のうち処理頻度が多い機能を特定する。

次にサーバ１００は、コア部分または共通処理部分を、マイクロサービス化候補機能から除外する。
図８は、コア部分または共通処理部分の除外の一例を示す図である。図８の例では、機能４３２が共通処理部分として抽出されている。プレゼンテーション層もプログラム４１０またはアプリケーション層のプログラム４２０内におけるコア部分または共通処理部分は、例えばトラックトレース機能を用いて抽出できる。またデータ層のプログラム４４０におけるコア部分または共通処理部分は、データのアクセスログを用いて抽出できる。そこでサーバ１００は、どんな処理でも共通で処理されているコア部分または共通処理部分を、マイクロサービス化候補機能から除外する。

例えばサーバ１００は、ＡＰＩ管理ツールおよびプログラム４１０，４２０に対するトラックトレースの情報を利用して、プレゼンテーション層のプログラム４１０内の各機能４１１～４１６に対応する画面内の操作に基づいて処理を実行した機能を判定する。そして、所定数以上の画面の操作に基づいて処理を実行している機能をコア部分または共通処理部として抽出する。

またサーバ１００は、データベースを解析して、ＪＯＩＮ処理によるデータテーブル間の関連付けを示す情報を取得する。サーバ１００は、所定数以上のデータテーブルにＪＯＩＮ処理で関連付けられているデータテーブルをマスタデータと判断する。そしてサーバ１００は、データ層内のマスタデータの管理機能とマスタデータにアクセスするアプリケーション層内の機能とをコア部分または共通部分として抽出する。

サーバ１００は、コア部分または共通処理部として抽出した機能をマイクロサービス化候補機能から除外する。
さらにサーバ１００は、マイクロサービス化候補機能への処理の依頼元となっている画面を起点とする呼び出しシーケンスを辿り、その呼び出しシーケンスで呼び出される機能を、すべてのマイクロサービス化対象機能に含める。

図９は、呼び出しシーケンス内の機能抽出の一例を示す図である。図９の例では、アプリケーション層のプログラム４２０内の機能４２８が、マイクロサービス化候補機能のための上記３つの要件を満たしているものとして抽出されている。またサーバ１００は、すべての機能間の呼び出し関係に基づいて、呼び出しシーケンスを把握する。例えばＪａｖａランタイムではメソッドの呼び出しシーケンス（メソッドトレース）が把握できる。

機能間の呼び出し関係を辿ると、機能４２８は、プレゼンテーション層のプログラム４１０内の機能４１１からアプリケーション層のプログラム４２０内の機能４２１へのＡＰＩ呼び出しに基づいて処理を実行していることが分かる。すなわち機能４１１で提供される画面に対するユーザからの操作に応じた機能４２１の呼び出しの結果、機能４２８が処理を実行している。

このときサーバ１００は、機能４１１から機能４２１の呼び出しに起因する呼び出しシーケンスを判別する。図９の例では、機能４２１から機能４２８，４２９が呼び出され、機能４２８，４２９から機能４３５が呼び出され、機能４３５からデータ層のプログラム４４０内の機能４４２が呼び出されている。

サーバ１００は、このような呼び出しシーケンスに含まれるすべての機能を抽出する。図９の例では、機能４１１，４２１，４２８，４２９，４３５，４４２が抽出される。そしてサーバ１００は、抽出したすべての機能をマイクロサービス化対象機能に特定する。

このようにしてマイクロサービス化対象機能を特定することができる。サーバ１００は、マイクロサービス化対象機能をサーバ１００の管理者に提示し、マイクロサービス化を提案する。

図１０は、マイクロサービス化を支援するためのサーバの機能の一例を示す図である。サーバ１００は、既存システム１１０、ソースファイル記憶部１２０、ソースファイル管理部１３０、およびマイクロサービス化支援部１４０を有する。

既存システム１１０は、ＳｏＲの設計思想で開発され、運用されているシステムである。既存システム１１０は、プレゼンテーション部１１１、アプリケーション部１１２、データ管理部１１３、およびＤＢ１１４を有する。

プレゼンテーション部１１１は、プレゼンテーション層のプログラム４１０をプロセッサ１０１が実行することで実現される機能である。プログラム４１０内の機能４１１～４１６は、プレゼンテーション部１１１に含まれる。プレゼンテーション部１１１は、例えば端末３１，３２，・・・からの要求に応じて、機能４１１～４１６のうちのいずれかの機能を実行し、画面データを生成し、要求元の端末に画面データを送信する。プレゼンテーション部１１１は、送信した画面データに基づいて表示された画面への操作に基づく処理要求を受信すると、その処理要求に応じたＡＰＩ呼び出しを行うことで、アプリケーション部１１２に処理の実行を要求する。

アプリケーション部１１２は、アプリケーション層のプログラム４２０をプロセッサ１０１が実行することで実現される機能である。プログラム４２０内の機能４２１～４３８は、アプリケーション部１１２に含まれる。アプリケーション部１１２は、プレゼンテーション層からのＡＰＩ呼び出しに応じて処理を実行する。アプリケーション部１１２は、処理の過程でＤＢ１１４へのデータアクセスが発生すると、データ管理部１１３にデータアクセス要求を送信する。

データ管理部１１３は、データ層のプログラム４４０をプロセッサ１０１が実行することで実現される機能である。プログラム４４０内の機能４４１～４４３は、データ管理部１１３に含まれる。データ管理部１１３は、アプリケーション部１１２からのデータアクセス要求に応じてＤＢ１１４へのデータ書き込みまたはＤＢ１１４からのデータ読取りを行う。

ＤＢ１１４は、複数のデータテーブルにより構成されるデータベースである。ＤＢ１１４に格納されるデータテーブルの一部はコア部分を構成する。ＤＢ１１４内のデータテーブルは、他のデータテーブルとＪＯＩＮにより結合することができる。データ管理部１１３からのＤＢ１１４へのアクセスがあるとそのアクセスを示すデータアクセスログがメモリ１０２またはストレージ装置１０３に格納される。データアクセスにおいて複数のデータテーブルのＪＯＩＮが指示されている場合には、例えばＪＯＩＮによりデータテーブルが結合されたことがデータアクセスログとして記録される。

ソースファイル記憶部１２０は、３階層の各プログラム４１０，４２０，４４０の作成に用いられたソースファイルを記憶する。ソースファイルは、プログラム４１０，４２０，４４０内の機能ごとに作成されている。３階層の各プログラム４１０，４２０，４４０を修正する場合、修正対象の機能に対応するソースファイルが更新される。

ソースファイル管理部１３０は、ソースファイル記憶部１２０に格納されているソースファイルを管理する。例えばソースファイル記憶部１２０は、ＣＩ／ＣＤを利用して、ソースファイルごとに、そのソースファイルの修正頻度などを管理する。

マイクロサービス化支援部１４０は、既存システム１１０内の各機能の処理状況に基づいて、マイクロサービス化をすることで適切な機能（マイクロサービス化対象機能）を特定する。なお、マイクロサービス化支援部１４０は、マイクロサービス化対象機能の特定の際には、ソースファイル管理部１３０から、各機能に対応するソースファイルの修正頻度の情報を取得する。マイクロサービス化支援部１４０は、マイクロサービス化対象機能を特定すると、マイクロサービス化対象機能を示してマイクロサービス化を提案する情報を出力する。

なお、図１０に示した各要素間を接続する線は通信経路の一部を示すものであり、図示した通信経路以外の通信経路も設定可能である。また、図１０に示した各要素の機能は、例えば、その要素に対応するプログラムをコンピュータに実行させることで実現することができる。

マイクロサービス化支援部１４０は、マイクロサービス化対象機能を特定するために、既存システム１１０から各機能処理状況に関する情報を取得すると共に、ソースファイル管理部１３０からソースファイルの更新頻度に関する情報を取得する。

図１１は、マイクロサービス化対象機能の特定のために取得する情報の一例を示す図である。マイクロサービス化支援部１４０は、ソースファイル管理部１３０からは修正頻度情報１４１を取得する。

例えばソースファイル管理部１３０は、ソースファイル記憶部１２０に格納されたソースファイル１２１，１２２，・・・のいずれかが修正された場合に、その修正履歴を管理する。そしてソースファイル管理部１３０は、マイクロサービス化支援部１４０からの要求に応じて、ソースファイル１２１，１２２，・・・それぞれについての修正頻度を示す修正頻度情報１４１を出力する。

マイクロサービス化支援部１４０は、既存システム１１０による処理を監視することでアクセス先情報１４２、ＪＯＩＮ情報１４３、ＡＰＩ呼び出し頻度情報１４４、画面別ＡＰＩ呼び出し情報１４５、および呼び出しシーケンス情報１４６を取得する。アクセス先情報１４２には、機能ごとに、該当機能を実行することでアクセスされるデータテーブルが示されている。ＪＯＩＮ情報１４３には、データテーブル間のＪＯＩＮによる結合関係に関する情報が示されている。ＡＰＩ呼び出し頻度情報１４４には、機能ごとのＡＰＩ呼び出しの頻度に関する情報が示されている。画面別ＡＰＩ呼び出し情報１４５には、プレゼンテーション部１１１によって表示される画面ごとに、その画面に対する入力に応じて実行されるＡＰＩ呼び出しに関する情報が示されている。呼び出しシーケンス情報１４６には、プレゼンテーション部１１１からのＡＰＩ呼び出しによってアプリケーション部１１２内で実行される一連の機能に関する情報が示されている。

以下、図１２～図１９を参照し、マイクロサービス化支援部１４０がマイクロサービス化対象機能を特定するために取得する情報と取得した情報の用途について具体的に説明する。

図１２は、修正頻度情報の一例を示す図である。例えば修正頻度情報１４１には、ソースファイルのファイル名に対応付けて、その修正頻度が設定されている。ソースファイルのファイル名には、そのソースファイルで実装されるＡＰＩのリストが示されている。例えばファイル名「ａａａ．ｊａｖａ」のソースファイルにより、ＡＰＩ「Ａ１，Ａ２」がサーバ１００に実装される。修正頻度は、所定の期間内にソースファイルが修正された回数である。

マイクロサービス化支援部１４０は、例えばＣＩ／ＣＤ技術を利用して、ＡＰＩの実装に用いられるソースファイルの修正頻度を蓄積して、修正頻度情報１４１を生成することができる。マイクロサービス化支援部１４０は、修正頻度情報１４１に基づいて、修正頻度が高いソースファイルを抽出することができる。例えばマイクロサービス化支援部１４０は、すべてのソースファイルのうち修正頻度が多い方から上位１割のソースファイルを抽出する。

図１３は、アクセス先情報の一例を示す図である。例えばアクセス先情報１４２には、ソースファイルのファイル名に対応付けて、そのソースファイルを実行することで実現される機能がアクセスするＤＢ１１４内のデータテーブルのテーブル名が設定されている。例えばファイル名「ａａａ．ｊａｖａ」のソースファイルを実行することで実現される機能は、データテーブル「Ｔ１」と「Ｔ２」にアクセスする。

図１４は、ＪＯＩＮ情報の一例を示す図である。例えばＪＯＩＮ情報１４３には、データテーブルのテーブル名それぞれに対応付けて、そのデータテーブルにＪＯＩＮされているデータテーブルのテーブル名が設定されている。図１４の例では、テーブル名「Ｔ３」のデータテーブルには、テーブル名「Ｔ４」のデータテーブルがＪＯＩＮされている。またテーブル名「Ｔ８」のデータテーブルには、テーブル名「Ｔ１」、「Ｔ２」、「Ｔ５」、「Ｔ６」、「Ｔ９」などの多くのデータテーブルがＪＯＩＮされている。

ＪＯＩＮ情報１４３に基づいて、ＤＢ１１４のコア部分（マスタデータを格納する部分）であるマスタテーブルを判別することができる。すなわちマスタテーブルは様々な用途で利用されるため、用途に応じてのデータテーブルがＪＯＩＮされる。そのため、全体のデータテーブルに対するＪＯＩＮされるデータテーブルの割合が所定値以上（例えば５０％以上）となるデータテーブルは，マスタテーブルであると判断できる。マイクロサービス化支援部１４０は、マスタテーブルにアクセスする機能については、マイクロサービス化候補機能から除外する。

図１５は、マイクロサービス化候補機能からのマスタテーブルへアクセスする機能の除外処理の一例を示す図である。図１５の例では、テーブル名「Ｔ８」のデータテーブルは、５０％以上のデータテーブルがＪＯＩＮされているものとする。この場合、マイクロサービス化支援部１４０は、テーブル名「Ｔ８」のデータテーブルをマスタテーブルであると判断する。そしてマイクロサービス化支援部１４０は、アクセス先情報１４２に示される各ソースファイルのうち、テーブル名「Ｔ８」のマスタテーブルにアクセスするソースファイルを抽出する。マイクロサービス化支援部１４０は、抽出したソースファイルを実行することで実現する機能については、マイクロサービス化候補機能から除外する。

図１６は、ＡＰＩ呼び出し頻度情報の一例を示す図である。例えばＡＰＩ呼び出し頻度情報１４４には、ソースファイルのファイル名に対応付けて、そのソースファイルによって実装されるＡＰＩに対するＡＰＩ呼び出し頻度（所定期間内のＡＰＩ呼び出し回数）が設定されている。図１６の例では、ファイル名「ａａａ．ｊａｖａ」のソースファイルにより実装されるＡＰＩ「Ａ１」、「Ａ２」に対するＡＰＩ呼び出しが、合計で「１１２，０００」回行われていることが示されている。

このようなＡＰＩ呼び出し頻度は、例えばＡＰＩ管理ツールを利用して取得することができる。マイクロサービス化支援部１４０は、ソースファイルにより実装されるＡＰＩの呼び出し頻度が多い方から所定数のソースファイルで実現される機能を、マイクロサービス化候補機能とする。例えばマイクロサービス化支援部１４０は、修正頻度が上位１割に入り、マスタテーブルへのアクセスを行わない機能のうち、ＡＰＩ呼び出し頻度が上位から２分の１以内のソースファイルで実現される機能を、マイクロサービス化候補機能とする。

図１６の例では、修正頻度が上位１割に入り、マスタテーブルへのアクセスを行う機能を含まないソースファイルは、「ａａａ．ｊａｖａ」、「ｂｂｂ．ｊａｖａ」、「ｃｃｃ．ｊａｖａ」、「ｄｄｄ．ｊａｖａ」、「ｆｆｆ．ｊａｖａ」の５個である。このうちＡＰＩ呼び出し頻度が上位の２分の１以下に入るのは、「ａａａ．ｊａｖａ」（ＡＰＩ呼び出し頻度「１１２，０００」）と「ｃｃｃ．ｊａｖａ」（ＡＰＩ呼び出し頻度「６５０，０００」）である。

図１７は、画面別ＡＰＩ呼び出し情報の一例を示す図である。画面別ＡＰＩ呼び出し情報１４５には、マイクロサービス化候補機能に対応するソースファイルのファイル名に対応付けて、そのソースファイルにより実装されるＡＰＩを、プレゼンテーション部１１１における各画面からの呼び出しの有無が示されている。例えば画面ＡＰＩ呼び出し情報１４５の各行には、ソースファイルのファイル名が対応付けられ、各列にはプレゼンテーション部１１１における画面の画面番号が対応付けられている。具体的には、画面別ＡＰＩ呼び出し情報１４５には、各行と各列との交差する位置に、列に示される画面に対するユーザ操作に応じた処理により、行に示されるソースファイルにより実装されるＡＰＩの呼び出しが行われるか否かが示されている。図１７の例では、ＡＰＩ呼び出しが行われている場合には丸印が示されている。

図１７の例では、ファイル名「ａａａ．ｊａｖａ」は２個の画面に基づいてＡＰＩ呼び出しが行われる。またファイル名「ｃｃｃ．ｊａｖａ」は１０個の画面に基づいてＡＰＩ呼び出しが行われる。

マイクロサービス化支援部１４０は、プレゼンテーション層（ＧＵＩ）のソースファイルを検索し、各ソースファイルを実行することで表示される画面に画面番号を付与する。そして、マイクロサービス化支援部１４０は、ＡＰＩ管理ツールなどにより抽出したＡＰＩの呼び出し元を確認することで、その画面からどのＡＰＩ呼び出しが行われているのかを判断する。

マイクロサービス化支援部１４０は、例えば５０％以上の画面からＡＰＩ呼び出しが行われている機能は、どこからも実行される共通処理（コア部分）だと判断して、そのＡＰＩを有する機能は、マイクロサービス化候補機能から除外する。図１７の例では、１０個の画面からＡＰＩ呼び出しが行われているファイル名「ｃｃｃ．ｊａｖａ」のソースファイルに対応する機能は、マイクロサービス化候補機能から除外される。

画面別ＡＰＩ呼び出し情報１４５に基づいて多くの画面からＡＰＩ呼び出しが行われる機能を除外した後にマイクロサービス化候補機能として残っている機能は、マイクロサービス化対象機能として特定される。またマイクロサービス化支援部１４０は、特定されたマイクロサービス化候補機能のＡＰＩ呼び出し元となる画面に対応するプレゼンテーション部１１１内の機能も、マイクロサービス化対象機能として特定する。さらにマイクロサービス化支援部１４０は、データ管理部１１３内のマイクロサービス化対象機能が有するＡＰＩの処理においてアクセスするデータテーブルを管理する機能についても、マイクロサービス化対象機能として特定する。

図１８は、呼び出しシーケンス情報の一例を示す図である。呼び出しシーケンス情報１４６には、マイクロサービス化候補機能が有するＡＰＩ「Ａ１」、「Ａ２」それぞれにおいて、そのＡＰＩ内で呼び出すメソッドのメソッド名が、呼び出し順に設定されている。例えばＡＰＩ「Ａ１」からは、「ｘｘｘｘクラスのｍｅｔｈｏｄ００１」、「ｙｙｙｙクラスのｍｅｔｈｏｄ００２」、「ｙｙｙｙクラスのｍｅｔｈｏｄ００３」、「ｚｚｚｚクラスのｍｅｔｈｏｄ００４」の４個のメソッドが順に呼び出される。このようなメソッドの呼び出しシーケンスは、Ｊａｖａランタイムを用いて把握することができる。

ＡＰＩ内で呼び出されるメソッドは、アプリケーション部１１２内の１つの機能である。マイクロサービス化支援部１４０は、マイクロサービス化対象機能として特定した機能を含む呼び出しシーケンス内のメソッドに対応する機能を、マイクロサービス化対象機能として特定する。

マイクロサービス化支援部１４０は、マイクロサービス化対象機能として特定した機能を示すマイクロサービス化対象機能情報を生成する。そしてマイクロサービス化支援部１４０は、マイクロサービス化対象機能情報に基づいて、マイクロサービス化が有効な機能をユーザに提案する。

図１９は、特定されたマイクロサービス化対象機能の一例を示す図である。マイクロサービス化対象機能情報１４７には、階層ごとに、その階層のプログラム４１０，４２０，４４０内のマイクロサービス化対象のリストが設定されている。アプリケーション層の機能は、プレゼンテーション層からのＡＰＩ呼び出し対象となる機能（階層「アプリケーション」）と、呼び出されたＡＰＩの呼び出しシーケンスに含まれている機能（階層「アプリケーション内」）とに分けられている。

マイクロサービス化対象機能の特定では、まずアプリケーション層におけるプレゼンテーション層からのＡＰＩ呼び出し対象となる機能が、マイクロサービス化対象機能として特定される。図１９の例では「ａａａ．ｊａｖａ（Ａ１、Ａ２）」がマイクロサービス化対象機能として特定されている。

そしてアプリケーション層内のマイクロサービス化対象機能に対してＡＰＩ呼び出しを行うプレゼンテーション層の画面に対応する機能がマイクロサービス化対象機能として特定される。図１９の例では「Ｇ３」、「Ｇ９」がマイクロサービス化対象機能として特定されている。

またＡＰＩ呼び出し対象のマイクロサービス化対象機能のＡＰＩの実行時にアクセスされるデータテーブルの管理機能がマイクロサービス化対象機能として特定される。図１９の例では「Ｔ１」、「Ｔ２」がマイクロサービス化対象機能として特定されている。

さらにＡＰＩ呼び出し対象のマイクロサービス化対象機能のＡＰＩにおけるＡＰＩ呼び出しシーケンスにおいて実行されるメソッドに対応する機能が、マイクロサービス化対象機能として特定される。図１９の例では「ｘｘｘｘクラスのｍｅｔｈｏｄ００１」、「ｙｙｙｙクラスのｍｅｔｈｏｄ００２」などがマイクロサービス化対象機能として特定されている。

次にマイクロサービス化する機能の提案処理の手順についてフローチャートを参照して説明する。
図２０は、マイクロサービス化機能提案処理の手順の一例を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。

［ステップＳ１０１］マイクロサービス化支援部１４０は、修正頻度情報１４１を取得する。例えばマイクロサービス化支援部１４０は、ソースファイル管理部１３０がＣＩ／ＣＤ技術を利用して蓄積したソースファイルの修正履歴に基づいて、修正頻度情報１４１を生成する。

［ステップＳ１０２］マイクロサービス化支援部１４０は、アクセス先情報１４２を取得する。例えばマイクロサービス化支援部１４０は、ＤＢ１１４へのデータアクセスログに基づいて各ＡＰＩのアクセス先のデータテーブルを取得し、アクセス先情報１４２を生成する。

［ステップＳ１０３］マイクロサービス化支援部１４０は、ＪＯＩＮ情報１４３を取得する。例えばマイクロサービス化支援部１４０は、ＤＢ１１４におるデータテーブル間のＪＯＩＮ関係を解析し、ＪＯＩＮ情報１４３を生成する。

［ステップＳ１０４］マイクロサービス化支援部１４０は、ＡＰＩ呼び出し頻度情報１４４を取得する。例えばマイクロサービス化支援部１４０は、ＡＰＩ管理ツールを利用して、既存システム１１０の運用中におけるＡＰＩ呼び出し頻度を蓄積する。そしてマイクロサービス化支援部１４０は、呼び出し先の機能の実装に用いられたソースファイルごとに所定期間内のＡＰＩ呼び出し回数を計数することで、ＡＰＩ呼び出し頻度情報１４４を生成する。

［ステップＳ１０５］マイクロサービス化支援部１４０は、画面別ＡＰＩ呼び出し情報１４５を取得する。例えばマイクロサービス化支援部１４０は、プレゼンテーション層の機能によって表示される画面と、その画面操作に応じて出力されるＡＰＩ呼び出しにより呼び出されるＡＰＩを解析し、画面別ＡＰＩ呼び出し情報１４５を生成する。

［ステップＳ１０６］マイクロサービス化支援部１４０は、呼び出しシーケンス情報１４６を取得する。例えばマイクロサービス化支援部１４０は、ＡＰＩごとにメソッドトレースを行い、各ＡＰＩから呼び出されるメソッドをリストアップし、メソッドのリストに基づいて呼び出しシーケンス情報１４６を生成する。

［ステップＳ１０７］マイクロサービス化支援部１４０は、マイクロサービス化対象機能特定処理を実行する。この処理の詳細は後述する（図２１参照）。
［ステップＳ１０８］マイクロサービス化支援部１４０は、マイクロサービス化対象機能特定処理の結果を出力する。例えばマイクロサービス化支援部１４０は、マイクロサービス化対象機能に特定された機能を示すマイクロサービス化対象機能情報１４７をモニタ２１に表示する。

このようにして、マイクロサービス化機能提案処理が行われ、サーバ１００の管理者は、顧客ニーズに応じた改修が求められる機能を容易に認識することができる。管理者は、マイクロサービス化対象機能として示された機能のマイクロサービス化を行うことで、以後、顧客ニーズに応じた機能の改修が容易となる。

次にマイクロサービス化対象特定処理の手順について詳細に説明する。
図２１は、マイクロサービス化対象特定処理の手順の一例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。

［ステップＳ２０１］マイクロサービス化支援部１４０は、ソースファイル記憶部１２０に格納されているソースファイルのうちの、未選択のソースファイルを１つ選択する。
［ステップＳ２０２］マイクロサービス化支援部１４０は、修正頻度情報１４１を参照し、選択したソースファイルの修正頻度が上位１０％以内に入っているか否かを判断する。例えばマイクロサービス化支援部１４０は、ステップＳ２０２の処理を最初に実行する際に、ソースファイルを修正頻度によって降順にソートし、上位１０％のソースファイルによって実現される機能をマイクロサービス化候補機能とする。マイクロサービス化支援部１４０は、選択したソースファイルが上位１０％以内に入っていれば処理をステップＳ２０３に進める。またマイクロサービス化支援部１４０は、上位１０％以内に入っていなければ処理をステップＳ２０６に進める。

［ステップＳ２０３］マイクロサービス化支援部１４０は、選択したソースファイルにより実装されるＡＰＩがマスタデータにアクセスするか否かを判断する。例えばマイクロサービス化支援部１４０は、ＪＯＩＮ情報１４３を参照し、５０％以上のデータテーブルからＪＯＩＮされているデータテーブルをマスタデータと判断する。そしてマイクロサービス化支援部１４０は、ＤＢ１１４へのアクセスログに基づいてマスタデータにアクセスしているＡＰＩを特定する。そしてマイクロサービス化支援部１４０は、特定したＡＰＩに選択したソースファイルにより実装されるＡＰＩが含まれていれば、マスタデータにアクセスすると判断する。

マイクロサービス化支援部１４０は、マスタデータにアクセスすると判断した場合、処理をＳ２０６に進める。またマイクロサービス化支援部１４０は、マスタデータにアクセスしないと判断した場合、処理をステップＳ２０４に進める。

［ステップＳ２０４］マイクロサービス化支援部１４０は、ＡＰＩ呼び出し頻度情報１４４を参照し、選択したソースファイルにより実装されるＡＰＩの呼び出し頻度が上位５０％以内に入っているか否かを判断する。マイクロサービス化支援部１４０は、上位５０％以内に入っていれば処理をステップＳ２０５に進める。またマイクロサービス化支援部１４０は、上位５０％以内に入っていなければ処理をステップＳ２０６に進める。

［ステップＳ２０５］マイクロサービス化支援部１４０は、画面別ＡＰＩ呼び出し情報を参照し、選択したソースファイルによって実装されるＡＰＩが５０％以上の画面から呼び出されるか否かを判断する。マイクロサービス化支援部１４０は、５０％以上の画面から呼び出される場合、処理をステップＳ２０６に進める。またマイクロサービス化支援部１４０は、５０％未満の画面からしか呼び出されない場合、処理をステップＳ２０７に進める。

［ステップＳ２０６］マイクロサービス化支援部１４０は、選択したソースファイルによって実現する機能をマイクロサービス化候補機能から除外する。その後、マイクロサービス化支援部１４０は処理をステップＳ２０９に進める。

［ステップＳ２０７］マイクロサービス化支援部１４０は、選択したソースファイルで実装されるＡＰＩのメソッド呼び出しシーケンスによる処理の流れを把握する。
［ステップＳ２０８］マイクロサービス化支援部１４０は、把握した処理の流れにおいて処理を実行する機能をマイクロサービス化対象機能に決定する。マイクロサービス化対象機能には、選択したソースファイルで実装されるＡＰＩを呼び出す画面を表示するためのプレゼンテーション層における機能も含まれる。またマイクロサービス化対象機能には、選択したソースファイルで実装されるＡＰＩを実行することによりアクセスされるデータテーブルについてのアクセス環境を提供するデータ層内の機能も含まれる。

［ステップＳ２０９］マイクロサービス化支援部１４０は、未選択のソースファイルがあるか否かを判断する。マイクロサービス化支援部１４０は、未選択のソースファイルがある場合、処理をステップＳ２０１に進める。またマイクロサービス化支援部１４０は、未選択のソースファイルがなければマイクロサービス化対象特定処理を終了する。

このようにして特定されたマイクロサービス化対象機能は、修正頻度が高く、処理頻度が高く、コア部分または共通部分ではない機能、およびその機能を含む処理のシーケンス上の他の機能である。このような機能は、顧客ニーズに応じた改修が求められる機能である。すなわち、顧客ニーズに応じた改修が求められる機能が正しく特定されている。

〔その他の実施の形態〕
第２の実施の形態では３階層のシステムからマイクロサービス化対象機能を特定しているが、３階層以外のシステムにも適用可能である。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ａ，１ｂ，・・・ ソースファイル
２ ソフトウェア
２ａ，２ｂ，２ｃ プログラム
３ａ，３ｂ，・・・ ソフトウェア部品
４ 既存システム
４ａ～４ｌ 機能
１０ 情報処理装置
１１ 記憶部
１２ 処理部

Claims (7)

1. 複数のソフトウェア部品を含むソフトウェア実行時に前記複数のソフトウェア部品それぞれにより実現される機能の呼び出し頻度を示す呼び出し頻度情報に基づいて、呼び出される頻度が第１の基準より高い第１の機能に対応する第１のソフトウェア部品を特定し、
   前記ソフトウェア実行時の前記機能間での呼び出し関係に基づいて、第２の基準より多くの呼び出し元が存在する第２の機能に対応する第２のソフトウェア部品を特定し、
   前記第１のソフトウェア部品に該当し、かつ前記第２のソフトウェア部品に該当しない第３のソフトウェア部品を、マイクロサービス化の対象として提示する、
   処理をコンピュータに実行させる情報処理プログラム。
2. 前記複数のソフトウェア部品それぞれの修正頻度を示す修正頻度情報に基づいて、修正頻度が第３の基準より高い第４のソフトウェア部品を特定する、
   処理をさらに前記コンピュータに実行させ、
   前記第３のソフトウェア部品の提示では、前記第１のソフトウェア部品と前記第４のソフトウェア部品とに該当し、かつ前記第２のソフトウェア部品に該当しないソフトウェア部品を、前記第３のソフトウェア部品とする、
   請求項１記載の情報処理プログラム。
3. データベースへのデータアクセスログに基づいて、前記データベース内のマスタデータにアクセスする第５の機能に対応する第５のソフトウェア部品を特定する、
   処理をさらに前記コンピュータに実行させ、
   前記第３のソフトウェア部品の提示では、前記第５のソフトウェア部品を前記第３のソフトウェア部品から除外する、
   請求項１または２記載の情報処理プログラム。
4. 前記データベースに含まれる複数のデータテーブル間での結合関係に基づいて、第４の基準より多くのデータテーブルに結合されたデータテーブルを前記マスタデータとして特定する、
   処理をさらに前記コンピュータに実行させる請求項３記載の情報処理プログラム。
5. 前記第３のソフトウェア部品に対応する第３の機能を含む呼び出しシーケンスに含まれる、前記第３の機能以外の第６の機能に対応する第６のソフトウェア部品を特定する、
   処理をさらに前記コンピュータに実行させ、
   前記第３のソフトウェア部品の提示では、前記第３のソフトウェア部品と共に前記第６のソフトウェア部品を提示する、
   請求項１から４までのいずれかに記載の情報処理プログラム。
6. 複数のソフトウェア部品を含むソフトウェア実行時に前記複数のソフトウェア部品それぞれにより実現される機能の呼び出し頻度を示す呼び出し頻度情報に基づいて、呼び出される頻度が第１の基準より高い第１の機能に対応する第１のソフトウェア部品を特定し、
   前記ソフトウェア実行時の前記機能間での呼び出し関係に基づいて、第２の基準より多くの呼び出し元が存在する第２の機能に対応する第２のソフトウェア部品を特定し、
   前記第１のソフトウェア部品に該当し、かつ前記第２のソフトウェア部品に該当しない第３のソフトウェア部品を、マイクロサービス化の対象として提示する、
   処理をコンピュータが実行する情報処理方法。
7. 複数のソフトウェア部品を含むソフトウェア実行時に前記複数のソフトウェア部品それぞれにより実現される機能の呼び出し頻度を示す呼び出し頻度情報に基づいて、呼び出される頻度が第１の基準より高い第１の機能に対応する第１のソフトウェア部品を特定し、前記ソフトウェア実行時の前記機能間での呼び出し関係に基づいて、第２の基準より多くの呼び出し元が存在する第２の機能に対応する第２のソフトウェア部品を特定し、前記第１のソフトウェア部品に該当し、かつ前記第２のソフトウェア部品に該当しない第３のソフトウェア部品を、マイクロサービス化の対象として提示する処理部、
   を有する情報処理装置。

Images