(57)【要約】【課題】小容量のローカルメモリによって、マイクロサービスをモニタリングする。【解決手段】コンピュータ１に、受信パケットの送信元及び送信先アドレスを含む重複情報に付加されて受信パケットに対する処理を示すフラグが特定のフラグである場合に、重複情報から生成したキーと特定のフラグとを第１のローカルメモリ１２における第１の領域１１２に記憶させ、受信パケットに応じて、処理毎に第１のローカルメモリ１２における第２の領域１２２に含まれる重複情報に対するアクセス頻度を示すカウンタを更新し、第１のタイミングで蓄積された第１の領域における各フラグに対応する処理を、第２の領域１２２において実施し、第２のタイミングで処理毎の第２の領域１２２を参照し、カウンタが閾値以上である第２の領域におけるエントリを第１のローカルメモリ１２から当該第１のローカルメモリの後段の第２のローカルメモリ１７に移動させる、処理を実行させる。【選択図】図１６
2020113924.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
受信したパケットの送信元アドレス及び送信先アドレスを含む重複情報に付加されて前記受信したパケットに対する処理を示すフラグが特定のフラグである場合に、前記重複情報から生成したキーと前記特定のフラグとを第１のローカルメモリにおける第１の領域に記憶させ、
前記受信したパケットに応じて、処理毎に前記第１のローカルメモリにおける第２の領域に含まれる重複情報に対するアクセス頻度を示すカウンタを更新し、
第１のタイミングで蓄積された前記第１の領域における各フラグに対応する処理を、前記第２の領域において実施し、
第２のタイミングで処理毎の前記第２の領域を参照し、前記カウンタが閾値以上である前記第２の領域におけるエントリを前記第１のローカルメモリから当該第１のローカルメモリの後段に備えられる第２のローカルメモリに移動させる、
処理を実行させる、モニタリングプログラム。
【請求項２】
前記第１の領域におけるエントリの数が一定数以上になった際に、前記第１のタイミングの処理を完了させ、前記第２のタイミングにおける処理を開始する、
処理を前記コンピュータに実行させる、請求項１に記載のモニタリングプログラム。
【請求項３】
前記第１の領域におけるエントリの数が一定数に達しない場合には、前記第１のタイミングの処理を継続する、
処理を前記コンピュータに実施させる、請求項１又は２に記載のモニタリングプログラム。
【請求項４】
前記特定のフラグは、Transmission Control Protocol/Internet Protocol（ＴＣＰ／ＩＰ）ヘッダの通信プロトコルで定義されたフラグを含む、
請求項１〜３のいずれか１項に記載のモニタリングプログラム。
【請求項５】
前記重複情報は、送信先ポート番号を更に含む、
請求項１〜４のいずれか１項に記載のモニタリングプログラム。
【請求項６】
前記重複情報は、送信元ポート番号を更に含む、
請求項１〜５のいずれか１項に記載のモニタリングプログラム。
【請求項７】
受信したパケットの送信元アドレス及び送信先アドレスを含む重複情報に付加されて前記受信したパケットに対する処理を示すフラグが特定のフラグである場合に、前記重複情報から生成したキーと前記特定のフラグとを第１の領域に記憶する第１のローカルメモリと、
前記受信したパケットに応じて、処理毎に前記第１のローカルメモリにおける第２の領域に含まれる重複情報に対するアクセス頻度を示すカウンタを更新する更新部と、
第１のタイミングで蓄積された前記第１の領域における各フラグに対応する処理を、前記第２の領域において実施する処理部と、
第２のタイミングで処理毎の前記第２の領域を参照し、前記カウンタが閾値以上である前記第２の領域におけるエントリを前記第１のローカルメモリから当該第１のローカルメモリの後段に備えられる第２のローカルメモリに移動させる移動部と、
を備える、プログラマブルデバイス。
【請求項８】
プログラマブルデバイスにおいて、
受信したパケットの送信元アドレス及び送信先アドレスを含む重複情報に付加されて前記受信したパケットに対する処理を示すフラグが特定のフラグである場合に、前記重複情報から生成したキーと前記特定のフラグとを第１のローカルメモリにおける第１の領域に記憶させ、
前記受信したパケットに応じて、処理毎に前記第１のローカルメモリにおける第２の領域に含まれる重複情報に対するアクセス頻度を示すカウンタを更新し、
第１のタイミングで蓄積された前記第１の領域における各フラグに対応する処理を、前記第２の領域において実施し、
第２のタイミングで処理毎の前記第２の領域を参照し、前記カウンタが閾値以上である前記第２の領域におけるエントリを前記第１のローカルメモリから当該第１のローカルメモリの後段に備えられる第２のローカルメモリに移動させる、
モニタリング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モニタリングプログラム，プログラマブルデバイス及びモニタリング方法に関する。
【背景技術】
【０００２】
マイクロサービスは、１つのアプリケーションが単独で配備されており、各アプリケーション間が接続されることで、容易に変化させることができ、スケールアウトも実施しやすくなる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１８−１２０４８９号公報
【特許文献２】特開２００３−２１８８７２号公報
【特許文献３】特開２０１８−８１４４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
マイクロサービスによって構成されたサービスをモニタリングする場合には、コンテナベースの分散システムで利用されるサイドカー（Sidecar）でフローをトラッキングすることが想定されるが、多くのメモリ空間やCentral Processing Unit（ＣＰＵ）が消費されてしまう。
【０００５】
そのため、Network Interface Card（ＮＩＣ）やスイッチ等のプログラマブルデバイスによってトラッキングすることが想定される。
【０００６】
しかしながら、プログラマブルデバイスで使用できるローカルメモリには限りがあるため、メモリの使用量を削減しなければならない。
【０００７】
そこで、各種共通項目である通信情報をハッシュにかけてＫｅｙが生成され、Ｋｅｙ毎に情報を蓄積することが想定される。
【０００８】
しかしながら、不要な情報が不明であるためメモリ内の情報を適切に削除することができず、メモリの使用量を削減できないという課題がある。
【０００９】
１つの側面では、小容量のローカルメモリによって、マイクロサービスをモニタリングすることを目的とする。
【課題を解決するための手段】
【００１０】
モニタリングプログラムは、コンピュータに、受信したパケットの送信元アドレス及び送信先アドレスを含む重複情報に付加されて前記受信したパケットに対する処理を示すフラグが特定のフラグである場合に、前記重複情報から生成したキーと前記特定のフラグとを第１のローカルメモリにおける第１の領域に記憶させ、前記受信したパケットに応じて、処理毎に前記第１のローカルメモリにおける第２の領域に含まれる重複情報に対するアクセス頻度を示すカウンタを更新し、第１のタイミングで蓄積された前記第１の領域における各フラグに対応する処理を、前記第２の領域において実施し、第２のタイミングで処理毎の前記第２の領域を参照し、前記カウンタが閾値以上である前記第２の領域におけるエントリを前記第１のローカルメモリから当該第１のローカルメモリの後段に備えられる第２のローカルメモリに移動させる、処理を実行させる。
【発明の効果】
【００１１】
１つの側面では、小容量のローカルメモリによって、マイクロサービスをモニタリングできる。
【図面の簡単な説明】
【００１２】
【図１】関連例におけるモノリスアーキテクチャのスケールアウトを示す図である。
【図２】関連例におけるマイクロサービスアーキテクチャのスケールアウトを示す図である。
【図３】関連例における分散トレーシングシステムにおける処理を説明する図である。
【図４】関連例における分散トレーシングシステムにおける処理時間を説明する図である。
【図５】関連例におけるHTTP cookieベースのstatefulの維持方法を説明する図である。
【図６】関連例におけるTokenベースのstatefulの維持方法を説明する図である。
【図７】関連例におけるマイクロサービス間での通信を説明する図である。
【図８】関連例におけるプログラマブルデバイスの構成例を示す図である。
【図９】関連例におけるプログラマブルデバイスのメモリアーキテクチャを示す図である。
【図１０】関連例におけるコンテナベースのサイドカーでのフロートラッキングを説明する図である。
【図１１】関連例における通信トレーシングテーブルを例示する図である。
【図１２】関連例におけるローカルメモリの資源節約方法を説明するテーブルである。
【図１３】関連例におけるSpanIDの推定方法を説明するシーケンス図である。
【図１４】関連例におけるSpanIDの推定方法を説明するテーブルである。
【図１５】実施形態の一例におけるプログラマブルデバイスの構成例を示すブロック図である。
【図１６】実施形態の一例におけるメモリレイテンシの削減処理の概要を説明する図である。
【図１７】図１６に示したメモリレイテンシの削減処理の概要を説明するシーケンス図である。
【図１８】図１６に示したメモリレイテンシの削減処理の概要を説明するシーケンス図である。
【図１９】実施形態の一例における重複情報プールを示すテーブルである。
【図２０】実施形態の一例におけるMatch flagの定義を示すテーブルである。
【図２１】実施形態の一例における重複情報の第１の例を示すテーブルである。
【図２２】実施形態の一例における重複情報の第２の例を示すテーブルである。
【図２３】実施形態の一例における重複情報プールの詳細を示すテーブルである。
【図２４】実施形態の一例における重複管理テーブルの詳細を示す図である。
【図２５】実施形態の一例におけるスパンテーブルを示す図である。
【図２６】実施形態の一例におけるプログラマブルデバイスの機能構成例を示すブロック図である。
【図２７】実施形態の一例におけるプログラマブルデバイスにおけるEntry挿入処理を説明する図である。
【図２８】実施形態の一例におけるプログラマブルデバイスにおけるEntry挿入処理を説明するシーケンス図である。
【図２９】実施形態の一例におけるプログラマブルデバイスにおけるEntry挿入処理を説明するシーケンス図である。
【図３０】実施形態の一例におけるプログラマブルデバイスにおけるEntry削除処理を説明する図である。
【図３１】実施形態の一例におけるプログラマブルデバイスにおけるEntry削除処理を説明するシーケンス図である。
【図３２】実施形態の一例におけるプログラマブルデバイスのアクセス測定タイムスロットにおける処理を説明するフローチャートである。
【図３３】実施形態の一例におけるプログラマブルデバイスのペナルティ管理タイムスロットにおける処理を説明するフローチャートである。
【図３４】実施形態の一例におけるプログラマブルデバイスのペナルティ管理タイムスロットにおける処理を説明するフローチャートである。
【図３５】実施形態の一例におけるプログラマブルデバイスにおけるタイムスロット管理処理を説明するフローチャートである。
【発明を実施するための形態】
【００１３】
以下、図面を参照して一実施の形態を説明する。ただし、以下に示す実施形態はあくまでも例示に過ぎず、実施形態で明示しない種々の変形例や技術の適用を排除する意図はない。すなわち、本実施形態を、その趣旨を逸脱しない範囲で種々変形して実施することができる。
【００１４】
また、各図は、図中に示す構成要素のみを備えるという趣旨ではなく、他の機能等を含むことができる。
【００１５】
以下、図中において、同一の各符号は同様の部分を示しているので、その説明は省略する。
【００１６】
〔Ａ〕関連例
図１は、関連例におけるモノリスアーキテクチャのスケールアウトを示す図である。
【００１７】
モノリスアーキテクチャは、一枚岩のアーキテクチャであり、複数の機能が１つの実行体として構築される（符号Ａ１参照）。図示する例では、モノリスアーキテクチャにおいて、サービス＃１〜＃５が機能している。
【００１８】
モノリスアーキテクチャをスケールアウトさせる際には、アプリケーション全体が複数のサーバに複製される（符号Ａ２参照）。
【００１９】
モノリスアーキテクチャでは、多くのアプリケーションが１つのサーバ及び仮想マシンの中で動作しているため、変化やスケールアウトが容易でない場合がある。
【００２０】
図２は、関連例におけるマイクロサービスアーキテクチャのスケールアウトを示す図である。
【００２１】
マイクロサービスアーキテクチャは、各サービスを独立性の高い単一のビジネス機構として構築する（符号Ｂ１参照）。図示する例では、モノリスアーキテクチャにおいて、サービス＃１〜＃５が機能している。
【００２２】
マイクロサービスアーキテクチャをスケールアウトさせる際には、複数のサーバに各サービスが必要に応じて配置される（符号Ｂ２参照）。
【００２３】
マイクロサービスアーキテクチャでは、各アプリケーションが単独で配備されているため、変化やスケールアウトが容易である。
【００２４】
ただし、マイクロサービスアーキテクチャは、分散システムの一種であるため、モニタリングの実施は容易でない場合がある。
【００２５】
図３は、関連例における分散トレーシングシステムにおける処理を説明する図である。
【００２６】
分散トレーシングシステムは、アプリケーション内で発生したエラーや遅いクエリを検出して、アプリケーション内の状態を提示する。また、分散トレーシングシステムは、アプリケーション内のトランザクションをトレーシングして記録する。更に、分散トレーシングシステムは、システムのモニタリングや性能分析を実施する。トレーシング乃実施のため、Sidecar(Proxy)というコンテナが追加で配備される。
【００２７】
図３に示す例では、記録トランザクションとしてのトレースコンテクストがサービスプロセッサに与えられる（符号Ｃ１参照）。
【００２８】
サービスプロセッサは、記述トランザクションとして、符号Ｃ２１〜Ｃ２３でそれぞれ示すサービス計測，オープンソースライブラリ計測及びブラックボックス計測を実施する（符号Ｃ２参照）。
【００２９】
そして、サービスプロセッサは、トレーサ走行時間を算出し（符号Ｃ２４参照）、トレースデータとしてトレーシングバックエンドシステムに送信する（符号Ｃ３参照）。
【００３０】
トレーシングバックエンドシステムでは、符号Ｃ４１〜Ｃ４３でそれぞれ示されるプロセス，ストレージ及びアナリシスが機能する（符号Ｃ４参照）。
【００３１】
トレーシングバックエンドは、分析トランザクションとして、インタラクティブＵＩ及びアナリティカルＡＰＩを提供する（符号Ｃ５及びＣ６参照）。なお、ＵＩはUser Interfaceの略称であり、ＡＰＩはApplication Programming Interfaceの略称である。
【００３２】
図４は、関連例における分散トレーシングシステムにおける処理時間を説明する図である。
【００３３】
分散トレーシングにおける最初から最後までのスパンの集合は、トレースと称される。図４に示す例において、符号Ｄ１で示すＷｅｂフレームワークは、トレースである。また、符号Ｄ２で示すＷｅｂフレームワークとRemote Procedure Call（ＲＰＣ）と外部サービスＡＰＩとの集合は、スパンである。また、符号Ｄ３〜Ｄ８で示すＲＰＣ，外部サービス及びＡＰＩも、スパンである。
【００３４】
スパンは、分散システムの中で論理的なユニットであり、名前や作業開始時刻，作業時間等を定義する。また、各スパンは、呼び出し元である親と、呼び出し先である子との関係を有する場合がある。
【００３５】
分散トレーシングシステムは、スパンの最初及び最後の呼び出し時間に基づき、性能劣化をモニタリングする。スパンが伸びている場合には、マイクロサービスの処理時間が増加する。図示する例では、符号Ｄ４で示すＲＰＣよりも符号Ｄ５で示す外部サービスのＡＰＩの方が処理時間を要する。
【００３６】
図５は、関連例におけるHTTP cookieベースのstatefulの維持方法を説明する図である。
【００３７】
１回目の処理において、クライアント＃１は、「sample.co.jp」のサーバにアクセスする（符号Ｅ１参照）。
【００３８】
これにより、サーバは、セッション識別子（ＳＩＤ）としてabcd1234を生成し、セッションＩＤとクライアント＃１の情報を紐づけて保存する。
【００３９】
そして、サーバは、クライアント＃１に対して、Hypertext Transfer Protocol（ＨＴＴＰ）レスポンスにおいて、CookieとしてSID=abcd1234を送信する（符号Ｅ２参照）。
【００４０】
これにより、クライアント＃１のブラウザは、CookieのSID=abcd1234を保存する。
【００４１】
２回目の処理において、クライアント＃１は、「sample.co.jp」のサーバにアクセスする際に、ブラウザに保存されたSID=abcd1234をサーバに送信する（符号Ｅ３参照）。
【００４２】
これにより、サーバは、SID=abcd1234によって保存したクライアント＃１の情報を取得し、接続元をクライアント＃１と認識する（符号Ｅ４参照）。
【００４３】
以上より、１回目と２回目との別々の通信において、同じクライアント＃１の情報を扱うことができる。
【００４４】
図６は、関連例におけるTokenベースのstatefulの維持方法を説明する図である。
【００４５】
マイクロサービス間では、互いにリクエスト／レスポンスを送信する際に、トークンを埋め込むことにより、互いのリソースを認識できる。TokenベースのＨＴＴＰ認証は、Request For Comments（ＲＦＣ）７６１７で定義されており、標準トラックとなっている。オープンスタックで仮想インフラ（「リソース」と称してもよい。）を参照する際も、キーストーンでTokenが発行され、各リソースがＡＰＩで参照される。
【００４６】
図６に示す例では、モバイルやウェブ等のクライアントアプリケーション６１は、認証サービス６２に対してSign-inする。認証サービス６２内のマイクロサービス６２１は、Token Database (DB)６２２を参照する事により、クライアントアプリケーション６１に対して、Security Tokenを発行する。
【００４７】
また、クライアントアプリケーション６１は、サービス６３に対して、Tokenとともにリクエストを発行する。サービス６３内のマイクロサービス６３１は、マイクロサービス６３２を介して、トークンＤＢ６３３にアクセスする。
【００４８】
図７は、関連例におけるマイクロサービス７１，７２間での通信を説明する図である。
【００４９】
送信側がクライアントのマイクロサービス７１として機能し、受信側がサーバのマイクロサービス７２として機能する。マイクロサービス７１，７２間では、ＨＴＴＰ／ｇＲＰＣのメッセージが伝送される。
【００５０】
図７に示すように、送信側のマイクロサービス７１におけるInternet Protocol（ＩＰ）アドレスと、受信側のマイクロサービス７２におけるＩＰアドレス／ポート番号とは、固定される。一方、送信側のマイクロサービス７１におけるポート番号は、変化する。
【００５１】
図８は、関連例におけるプログラマブルデバイス８の構成例を示す図である。
【００５２】
プログラマブルデバイス８は、ソフトウェアによりハードウェアデバイスを自由に操作可能であり、ハードウェアデバイスの機能を動的に変化できる。プログラマブルデバイス８は、プログラマブルスイッチやＮＩＣであってよい。
【００５３】
図８に示すように、プログラマブルデバイス８は、２つのパイプライン８１及び１つのスイッチ８２を備える。
【００５４】
パイプライン８１は、スイッチ８２の前段及び後段にそれぞれ備えられ、複数のマッチアクションテーブル８１１（「ステージ」と称してもよい。）を有する。パイプライン８１は、マッチアクションテーブル８１１の中で、スイッチ８２の内部情報（例えば、queue lengthやin/out port，特定のヘッダ情報）をメタデータとして扱うことができる。パイプライン８１は、マッチアクションテーブル８１１を利用することにより、特定のパケットを数える等の処理ができる。
【００５５】
図９は、関連例におけるプログラマブルデバイス８のメモリアーキテクチャを示す図である。
【００５６】
プログラマブルデバイス８において、各マッチアクションテーブル８１１の中には、ローカルメモリ８１２が存在する。また、各ローカルメモリ８１２には、シェアメモリ８３（「グローバルメモリ」と称してもよい。）が接続される。
【００５７】
ローカルメモリ８１２は、各マッチアクションテーブル８１１の中で、多段のテーブル（「マルチステージ」と称してもよい。）として構成される。ローカルメモリ８１２は、Ternary Content Addressable Memory（ＴＣＡＭ）やStatic Random Access Memory（ＳＲＡＭ）等であり、小さい容量（例えば、数〜数十メガバイト）であるが、高速で動作する。
【００５８】
シェアメモリ８３は、マッチアクションテーブル８１１の外に存在する。シェアメモリ８３は、Dynamic Random Access Memory（ＤＲＡＭ）等であり、大きな容量（例えば、数〜数十ギガバイト）であるが、低速で動作する。マッチアクションテーブル８１１からシェアメモリ８３を参照するためには、ＣＰＵ（図１０を用いて後述）を経由する等により、レイテンシが発生する。
【００５９】
複数のマイクロサービスによって構成されるサービスは、例えば、以下の（１）〜（６）で示す前提により構成されてよい。
【００６０】
（１）ユーザからのフロー（例えば、ＨＴＴＰトラフィック）は、Statefulを維持するためにCookieやTokenを利用する。
【００６１】
（２）マイクロサービス間の通信は、Transmission Control Protocol（ＴＣＰ）上で動作し、ＨＴＴＰやｇＲＰＣが主に利用される。
【００６２】
（３）サービスの規模によっては、ゲートウェイやイングレスロードバランサが備えられる場合もある。
【００６３】
（４）ＴＣＰ／ＩＰパケットのヘッダで、メタデータを埋め込むことが可能である。メタデータは、オプションフィールドを利用することによって埋め込まれてよい。また、メタデータは、ＴＣＰ／ＨＴＴＰ等のヘッダに埋め込まれてよい。
【００６４】
（５）各マイクロサービスには、Sidecar(Proxy)が存在する。ＨＴＴＰヘッダのParsingやＨＴＴＰレベルによって統計値が収集可能である。
【００６５】
（６）サーバ側では、プログラマブルデバイス８（例えば、ＮＩＣ）存在する。
【００６６】
マイクロサービスにおいて、Annotationのような追加コードを用いずに、ハードウェアの機能を利用することにより、フロー（例えば、Connection）をTrackingしてSpanを生成し、マイクロサービスをモニタリングしたい。
【００６７】
そのために、既存のAnnotationベースと同じ形式でSpanが生成され、互換性が保持されるようにする。例えば、TraceIDやParentID，SpanID等がハードウェアの機能を利用して管理され、TraceのデータがCollectorに保存される。
【００６８】
また、ハードウェアタイムスタンプを利用して、ナノ秒レベルでタイムスタンプを生成する。
【００６９】
これらにより、Spanだけでは観測できなかったネットワークの遅延が観測できる。
【００７０】
図１０は、関連例におけるコンテナベースのサイドカー９２でのフロートラッキングを説明する図である。
【００７１】
図１０に示すように、マイクロサービス９１に対応するコンテナベースのサイドカー９２でフロートラッキングを生成することも可能である。
【００７２】
しかしながら、複数のフローをトラッキングするためには、多くのメモリ空間が消費される。また、フローのトラッキングテーブルを維持するためには、多くのＣＰＵ９３が使用される。さらに、コンテナがＣＰＵ９３を全部占有した場合には、コンテナがリスタートされた際に、コンテナが保持していたフロー情報９２１が全て消失してしまう。
【００７３】
図１１は、関連例における通信トレーシングテーブルを例示する図である。
【００７４】
図示する通信トレーシングテーブルは、フローの通信情報（例えば、送受信ＩＰ，ポート，プロトコル）やトレーシングするための情報（例えば、スパンID, ペアレントID, トレースID, 時刻, ステイトフルな情報）を含む。
【００７５】
このような情報は、プログラマブルデバイス８の小さな容量のローカルメモリ８１２には保存できない。また、共有メモリに保存する場合には、アクセスのためにＣＰＵ９３によりメモリコピーが発生し、余分なレイテンシが増加する。
【００７６】
図１２は、関連例におけるローカルメモリ８１２の資源節約方法を説明するテーブルである。
【００７７】
ローカルメモリ８１２の資源を節約するために、各フローの通信情報をハッシュにかけてハッシュキーが生成され、ハッシュキーに基づいて各フローの通信情報やSpan情報にアクセスすることが想定される。
【００７８】
図１２に示す例では、ハッシュキーが各フローの値（例えば、ＳＩＰ，ＤＩＰ，プロトコル等）に対応付けられている。
【００７９】
図１２に示すテーブルは、Entryが少なければローカルメモリ８１２に収容可能であるが、Entryが多いと収容が困難となる。
【００８０】
図１３は、関連例におけるSpanIDの推定方法を説明するシーケンス図である。図１４は、関連例におけるSpanIDの推定方法を説明するテーブルである。
【００８１】
ホスト側において、複数のポイントでパケットキャプチャが行なわれ、キャプチャ結果とリクエストが到達するタイミング（ＴＨ）に基づき、送信元候補の出現頻度に応じてParent SpanIDが推定される。
【００８２】
図１３に示す例では、符号Ｆ１〜Ｆ３に示すように、サービスａからサービスｂへの通信が３回行なわれている。
【００８３】
符号Ｆ１に示すように、時間ＴＨにおいて、サービスａで受信される通信は、サービスｑ→ａ及びサービスｒ→ａである。また、符号Ｆ２に示すように、時間ＴＨにおいて、サービスａで受信される通信は、サービスｒ→ａである。更に、符号Ｆ３に示すように、時間ＴＨにおいて、サービスａで受信される通信は、サービスｒ→ａ，サービスｐ→ａ及びサービスｑ→ａである。
【００８４】
符号Ｆ１〜Ｆ３でそれぞれ示した時間ＴＨにおける通信を集計すると、図１４に示すように、親通信候補としてサービスｒ→ａが、出現回数３回で割合１．００となり、最大となる。これにより、最も割合が高い通信を親通信として推定できる。
【００８５】
しかしながら、適切な時間ＴＨ（「閾値」と称してもよい。）を決めることは容易でない。
【００８６】
また、事前にどのマイクロサービス（別言すれば、「コンテナ」）がどの仮想ポートに紐づけられているかを認識していなければならない。１個のサーバにおいて数百個のコンテナが配備されていることもあり、対象の仮想ポートを探すことは容易でない。コンテナがリスタートした場合には、ＩＰアドレスやキャプチャ対象の仮想ポートが変更されるため、新しく情報を収集し直すことになる。
【００８７】
更に、フローをトラッキングするためのＣＰＵ９３は必要でないものの、ホスト側において複数のポイントでキャプチャするため処理負荷が生じる。処理負荷は、同時に生成されたフローの数が多いほど、大きくなる。
【００８８】
〔Ｂ〕実施形態の一例
〔Ｂ−１〕システム構成例
図１５は、実施形態の一例におけるプログラマブルデバイス１の構成例を示すブロック図である。
【００８９】
プログラマブルデバイス１は、コンピュータの一例であり、多段のマッチアクションテーブル１１，スイッチ１３，入力ポート１４，パケットパーサ１５及び出力ポート１６を備える。多段のマッチアクションテーブル１１は、スイッチ１３の前段及び後段に備える。また、プログラマブルデバイス１は、図１６を用いて後述するように、シェアメモリ１７を備える。
【００９０】
入力ポート１４は、外部からのパケットの入力を受け付ける。
【００９１】
パケットパーサ１５は、プラグやソースポートの情報を抽出する。
【００９２】
マッチアクションテーブル１１は、スイッチ１３の前段及び後段において、それぞれ複数備えられ、分散して処理を行なう。マッチアクションテーブル１１は、それぞれローカルメモリ１２を備える。
【００９３】
スイッチ１３は、パケットに対する種々の処理を行なう。
【００９４】
出力ポート１６は、プログラマブルデバイス１からパケットを出力する。
【００９５】
図１６は、実施形態の一例におけるメモリレイテンシの削減処理の概要を説明する図である。
【００９６】
プログラマブルデバイス１では、マイクロサービスの送信ＩＰ，受信ＩＰとポートとが同じネットワーク２からのパケットについて、重複情報として扱われる。図１６に示すように、多段のマッチアクションテーブル１１（「Stage」と称してもよい。）を重複情報プール１１２と重複管理テーブル１２２とに分けて、２つのタイムスロットで重複情報プール１１２と重複管理テーブル１２２とを制御することで、メモリレイテンシを低下させる。２つのタイムスロットは、アクセス測定とペナルティ管理である。
【００９７】
先頭のStage(0)における重複情報プール１１２では、届いたＴＣＰパケットの重複情報からキーが生成され、Flag（フラグ；例えば、SYN/FIN/RST）が保存される。Flagについては、図２０等を用いて後述される。すなわち、アクセス測定において、重複情報プール１１２で新しい重複情報が保存され、Penaltyを与えるために所定時間待機される。
【００９８】
Stage(1)以降における重複管理テーブル１２２では、重複情報（別言すれば、「Key」）とAging Counterの数値（別言すれば、「Penalty」）とが保存される。すなわち、ペナルティ管理において、TCP Flag (SYN/FIN/RST)をベースに、新しい重複情報について各重複管理テーブル１２２のEntry及びSpan情報を挿入／削除される。また、アクセスがないEntryにPenaltyが与えられて、Aging Counterが閾値以上であるEntryが後段のStageに移動される。
【００９９】
アクセス測定及びペナルティ管理が完了すると、その後も、アクセス測定及びペナルティ管理が繰り返し実施される。
【０１００】
図１７及び図１８は、図１６に示したメモリレイテンシの削減処理の概要を説明するシーケンス図である。
【０１０１】
Stage(0)は、パケット管理部１１１，重複情報プール１１２及び通信部１１３を含む。
【０１０２】
Stage(1)以降は、スパン制御部１２１，重複管理テーブル１２２，スパンテーブル１２３及び通信部１２４を含む。
【０１０３】
図１７に示すように、アクセス測定のタイムスロットにおいて、Stage(0)のパケット管理部１１１は、ネットワーク２から、(Key, Flag)=(XXX, SYN)及び(DDX, FIN)のパケットを受信する（符号Ｇ１及びＧ２参照）。なお、ＳＹＮはStageへのEntry挿入を示し、ＦＩＮはStageからのEntry削除を示す。
【０１０４】
Stage(0)のパケット管理部１１１は、重複情報からKeyを生成して重複情報プール１１２に保存する（符号Ｇ３参照）。
【０１０５】
ペナルティ管理のタイムスロットにおいて、Stage(m)及びStage(n)等の各Stageのスパン制御部１２１は、Stage(0)の通信部１１３を通じて、Key及びFlagを取得する（図２８の符号Ｇ４及びＧ５参照）。
【０１０６】
Stage(m)及びStage(n)のスパン制御部１２１は、重複情報プール１１２からの重複情報を重複管理テーブル１２２においてマッチングする（符号Ｇ６及びＧ７参照）。
【０１０７】
Stage(m)のスパン制御部１２１は、重複管理テーブル１２２において、SYNのEntryを作成し（符号Ｇ８参照）、FINのEntryを削除する（符号Ｇ９参照）。
【０１０８】
Stage(m)のスパン制御部１２１は、スパンテーブル１２３において、SYNのSpanを作成し（符号Ｇ１０参照）、FINのSpanを削除する（符号Ｇ１１参照）。
【０１０９】
図１８に示すように、Stage(n)のスパン制御部１２１は、重複管理テーブル１２２において、SYNのEntryを作成し（符号Ｇ１２参照）、FINのEntryを削除する（符号Ｇ１３参照）。
【０１１０】
Stage(n)のスパン制御部１２１は、スパンテーブル１２３において、SYNのSpanを作成し（符号Ｇ１４参照）、FINのSpanを削除する（符号Ｇ１５参照）。
【０１１１】
Stage(m)のスパン制御部１２１は、アクセスがない全てのEntryにPenaltyを付加する（符号Ｇ１６参照）。
【０１１２】
Stage(m)のスパン制御部１２１は、Penaltyの値が閾値以上の場合に、通信部１１３を通じて、別のStageに重複情報を移動させる（符号Ｇ１７参照）。
【０１１３】
所定時間が経過すると（符号Ｇ１８参照）、再びアクセス測定のタイムスロットが開始する。
【０１１４】
Stage(0)のパケット管理部１１１は、ネットワーク２から、(Key, Flag)=(UNY, SYN)及び(SAC, FIN)のパケットを受信する（符号Ｇ１９及びＧ２０参照）。
【０１１５】
Stage(0)のパケット管理部１１１は、重複情報からKeyを生成して重複情報プール１１２に保存する（符号Ｇ２１参照）。以下、ペナルティ管理のタイムスロットが再び開始する。
【０１１６】
図１９は、実施形態の一例における重複情報プール１１２を示すテーブルである。
【０１１７】
アクセス測定のタイムスロットの時間は、例えば、以下のように調整されてよい。
【０１１８】
所定時間内に、重複情報プール１１２のEntry数が一定割合（例えば、８０％）以上になった場合に、ペナルティ管理のタイムスロットに切り替えられてよい。
【０１１９】
また、所定時間を超えても、重複情報プール１１２のEntry数が一定数割合（例えば、１０％）以下であれば、ペナルティ管理のタイムスロットに切り替えられなくてもよい。
【０１２０】
すなわち、Entryがどのくらい埋められたかに応じて、タイムスロットの切り替えタイミングが決定されてよい。
【０１２１】
図２０は、実施形態の一例におけるMatch flagの定義を示すテーブルである。
【０１２２】
Match flagは、フラグの一例であり、送信元アドレス及び送信先アドレスを含む重複情報に付加されて、受信したパケットに対する処理を示す。図２０に示すように、TCP SYNはActionとしてStageにEntryを挿入させることを示し、TCP RST及びTCP FINはActionとしてStageにEntryを削除させることを示す。
【０１２３】
また、TCP Flagに限らず、IP HeaderのECN等も使用されてよい。IP ECNは、Actionとして、輻輳により、スループットが低下し、レイテンシが伸びるため、Trapを利用して管理者に通知させることを示す。当該通知は、Stage(0)の通信部１１３によって実行されてよい。
【０１２４】
図２１は、実施形態の一例における重複情報の第１の例を示すテーブルである。図２２は、実施形態の一例における重複情報の第２の例を示すテーブルである。
【０１２５】
図２１に示すように、重複情報には、マイクロサービスにおいて共通の送信側ＩＰ（ＳＩＰ），受信側ＩＰ（ＤＩＰ）及び受信側ポート（ＤＰｏｒｔ）を含んでよい。
【０１２６】
ただし、マイクロサービスの受信側のポート番号が常に固定である場合には、図２２に示すように、重複情報には、受信側ポート（ＤＰｏｒｔ）を含まなくてよい。
【０１２７】
また、重複情報には、送信側ポート（ＳＰｏｒｔ）が含まれてもよいし、受信側ポート（ＤＰｏｒｔ）及び送信側ポート（ＤＰｏｒｔ）が共に含まれてもよい。
【０１２８】
図２３は、実施形態の一例における重複情報プール１１２の詳細を示すテーブルである。
【０１２９】
重複情報プール１１２は、重複情報やTCP Flagを保存し、Hash keyを生成するテーブルである。重複情報プール１１２は、Dup. Hash key, SIP, DIP, DPort, TCP Flag及びPacket Timeを含んでよい。
【０１３０】
Dup. Hash keyは、重複情報（例えば、SIP, DIP, DPort）によって生成されたHash keyである。SIPは、送信側のＩＰアドレスである。DIPは、受信側のＩＰアドレスである。DPortは、受信側のポート番号である。Packet Timeは、パケットを受信した時刻である。TCP Flagは、TCP HeaderにあるFlagであり、Entryを管理する手段の１つとして利用される。
【０１３１】
SYNは、TCPフロー（別言すれば、Connection）が生成されることを示し、SPANが生成される。
【０１３２】
FINは、TCPフロー（別言すれば、Connection）が終了されることを示し、ペナルティ管理のタイムスロットでEntryをすぐに削除可能である。
【０１３３】
RSTは、TCPフロー（別言すれば、Connection）が終了されることを示し、ペナルティ管理のタイムスロットでEntryをすぐに削除可能である。
【０１３４】
図２４は、実施形態の一例における重複管理テーブル１２２の詳細を示す図である。
【０１３５】
重複管理テーブル１２２は、重複情報を保存し、Hash keyを生成するテーブルである。重複情報プール１１２は、Dup. Hash key, SIP, DIP, DPort及びAging Counterを含んでよい。
【０１３６】
Dup. Hash keyは、重複情報（例えば、SIP, DIP, DPort）によって生成されたHash keyである。SIPは、送信側のＩＰアドレスである。DIPは、受信側のＩＰアドレスである。DPortは、受信側のポート番号である。Aging Counterは、アクセス頻度と経過時間とによって設定される値であり、閾値を超えて高い数値になるとシェアメモリ１７に移動される。
【０１３７】
重複情報にアクセスがない場合には、Aging Counterに一定の値がPenaltyとして加算され、値が大きくなるほど、シェアメモリ１７側へシフトされる。重複情報にヒットが発生した場合には、Aging Counterが０に初期化され、ローカルメモリ１２側の先頭のハッシュテーブルにEntryが移動される。
【０１３８】
図２５は、実施形態の一例におけるスパンテーブル１２３を示す図である。
【０１３９】
スパンテーブル１２３では、Span情報が存在し、重複情報に基づいてEntryが管理される。
【０１４０】
Hash Keyは、SPort, Dup. hash key, Stateful info.によって生成されたハッシュキーである。Dup. Hash keyは、重複管理テーブル１２２のハッシュキーである。Stateful info.は、Cookie又はTokenを示す。TraceIDは、Span全体が共有するIDである。ParentIDは、親のSpanのIDを示す。SpanIDは、自身のSpanのIDを示す。Start Timeは、重複情報プール１１２の情報に基づき、HTTPのTCPフローのSYNが届いた時刻を示す。End Timeは、重複情報プール１１２の情報に基づき、HTTPのTCPフローのFINが届いた時刻を示す。Durationは、End TimeからStart Timeを減じた時間を示す。
【０１４１】
図２６は、実施形態の一例におけるプログラマブルデバイス１の機能構成例を示すブロック図である。
【０１４２】
図２６に示すように、各Stageはパイプライン１１０に展開され、パイプライン１１０にはシェアメモリ１７が接続される。
【０１４３】
Stage(0)は、通信部１１３，パケット解析部１１４及びハッシュ生成部１１５として機能し、ローカルメモリ１２において重複情報プール１１２を保持する。パケット解析部１１４及びハッシュ生成部１１５は、図１７及び図１８に示したパケット管理部１１１に対応する。
【０１４４】
パケット解析部１１４は、パケットからTCP/IPヘッダを抜き出して、TCP SYN/FINを検出する（符号Ｈ１参照）。また、パケット解析部１１４は、パケット情報をハッシュ生成部１１５に伝送する。更に、パケット解析部１１４は、TCPのSYN/FIN/RSTを重複情報プール１１２に保存する。
【０１４５】
ハッシュ生成部１１５は、現在のパケットから重複情報（例えば、SIP, DIP, DPort）のDup. Hash keyを生成し、重複情報プール１１２に保存する（符号Ｈ２参照）。
【０１４６】
重複情報プール１１２は、受信したパケットのフラグが特定のフラグである場合に、受信したパケットの送信元アドレス及び送信先アドレスを含む重複情報から生成したキーと特定のフラグとを記憶する第１の領域の一例である。
【０１４７】
Stage(0)の通信部１１３は、Stage(1)以降からの依頼に基づき、重複情報プール１１２からKeyとFlagとを取得する（符号Ｈ３参照）。
【０１４８】
Stage(1)以降は、通信部１２４，重複情報確認部１２５，ペナルティ付加部１２６，エントリ移動部１２７，スパン生成部１２８，時刻管理部１２９，スパン管理部１３０，ハッシュ生成部１３１，重複情報依頼部１３２及びタイマ１３３として機能する。また、Stage(1)以降のローカルメモリ１２には、重複管理テーブル１２２及びスパンテーブル１２３が保持される。重複情報確認部１２５，ペナルティ付加部１２６，エントリ移動部１２７，スパン生成部１２８，時刻管理部１２９，スパン管理部１３０，ハッシュ生成部１３１及び重複情報依頼部１３２は、図１７及び図１８に示したスパン制御部１２１に対応する。
【０１４９】
重複情報確認部１２５は、重複管理テーブル１２２にあるDup. Hash Keyと現在のパケットのHash Keyとが一致するかを確認する（符号Ｈ４参照）。
【０１５０】
ペナルティ付加部１２６は、タイマ１３３を参照して、重複管理テーブル１２２の全てのEntryについて、Aging Counterの値を加算する（符号Ｈ５参照）。
【０１５１】
ペナルティ付加部１２６は、受信したパケットに応じて、処理毎にローカルメモリ１２における重複管理テーブル１２２（別言すれば、「第２の領域」）に含まれる重複情報に対するアクセス頻度を示すカウンタを更新する更新部の一例である。
【０１５２】
エントリ移動部１２７は、Aging Counterが閾値以上になったEntryについて、通信部１１３を介して、別のStage又はシェアメモリ１７に移動させる（符号Ｈ６参照）。
【０１５３】
エントリ移動部１２７は、アクセス測定タイムスロット（別言すれば、「第２のタイミング」）で処理毎の重複管理テーブル１２２（別言すれば、「第２の領域」）を参照する。そして、エントリ移動部１２７は、Aging Counterが閾値以上である重複管理テーブル１２２におけるエントリをローカルメモリ１２から次段（別言すれば、「後段」）のローカルメモリ１２又はシェアメモリ１７に移動させる移動部の一例である。
【０１５４】
スパン生成部１２８は、Stateful情報に基づき、TraceID, ParentID及びSpanIDを生成し、時刻管理部１２９からのTimeStampをスパンテーブル１２３に記録する（符号Ｈ７参照）。
【０１５５】
時刻管理部１１９は、TCPのSYN/FINが完了した旨の通知を受け取ったタイミングでTimeStampを生成して、スパン生成部１１８に送る（符号Ｈ８参照）。
【０１５６】
スパン管理部１３０は、TCP/IPヘッダとペイロードとの間で存在するスパン情報を称入したり抜き出したりする（符号Ｈ９参照）。
【０１５７】
ハッシュ生成部１３１は、現在のパケットから重複情報（例えば、SIP, DIP, DPort）のDup. Hash keyを生成する。また、ハッシュ生成部１３１は、現在のフローのSPort, Dup. hash Key及びStateful info.からHash Keyを生成してスパンテーブル１２３に格納する（符号Ｈ１０参照）。
【０１５８】
ハッシュ生成部１３１は、第１のタイミングで蓄積された重複情報プール１１２（別言すれば、「第１の領域」）における各フラグに対応する処理を、重複管理テーブル１２２（別言すれば、「第２の領域」）において実施する処理部の一例である。
【０１５９】
〔Ｂ−２〕動作例
以下、図２７を参照しながら、実施形態の一例におけるプログラマブルデバイス１におけるEntry挿入処理を、図２８及び図２９に示すシーケンス図（符号Ｊ１〜Ｊ１０）を用いて説明する。
【０１６０】
図２７及び図２８に示すように、Stage(0)のパケット管理部１１１は、アクセス測定のタイムスロットで、新しいコネクションのSYNのパケットをネットワーク２から受信する（図２７の符号Ｉ１及び図２８の符号Ｊ１参照）。
【０１６１】
Stage(0)のパケット管理部１１１は、重複情報からKeyを生成して重複情報プール１１２に保存する（図２８の符号Ｊ２参照）。
【０１６２】
ペナルティ管理のタイムスロットにおいて、Stage(m)，Stage(m+1)及びStage(n)等の各Stageのスパン制御部１２１は、Stage(0)の通信部１１３を通じて、Key及びFlagを取得する（図２８の符号Ｊ３参照）。
【０１６３】
Stage(m)のスパン制御部１２１は、重複情報Key(XXX)を重複管理テーブル１２２においてマッチングしたがEntryにないことを確認する（図２８の符号Ｊ４参照）。
【０１６４】
Stage(m+1)及びStage(n)等の各Stageにおいても、EntryとしてKey(XXX)がないことが確認される（図２８の符号Ｊ５参照）。
【０１６５】
Stage(m)のスパン制御部１２１は、重複情報がSYNであるため、重複管理テーブル１２２にEntry(XXX)を挿入する（図２８の符号Ｊ６参照）。
【０１６６】
Stage(m)のスパン制御部１２１は、重複情報がSYNであるため、スパンテーブル１２３にSpan(XXX)を生成する（図２８の符号Ｊ７参照）。
【０１６７】
図２９において、Stage(m)のスパン制御部１２１は、重複管理テーブル１２２において、アクセスがない全てのEntryにPenaltyとしてAging Counterの値を上げる（図２９の符号Ｊ８参照）。
【０１６８】
Stage(m)のスパン制御部１２１は、重複管理テーブル１２２のEntry(YYY)の値が190であり閾値（例えば、180）以上であるため、次のStage(m+1)に移動させる（図２７の符号Ｉ２及び図２９の符号Ｊ９参照）。
【０１６９】
Stage(m+1)において、重複情報のEntry(YYY)が保存される（図２９の符号Ｊ１０参照）。そして、Entry挿入処理は終了する。
【０１７０】
次に、図３０を参照しながら、実施形態の一例におけるプログラマブルデバイス１におけるEntry削除処理を、図３１に示すシーケンス図（符号Ｌ１〜Ｌ９）を用いて説明する。
【０１７１】
図３０及び図３１に示すように、Stage(0)のパケット管理部１１１は、アクセス測定のタイムスロットで、コネクションのFINのパケットをネットワーク２から受信する（図３０の符号Ｋ１及び図３１の符号Ｌ１参照）。
【０１７２】
Stage(0)のパケット管理部１１１は、重複情報からKey(SAC)を生成して重複情報プール１１２に保存する（図３１の符号Ｌ２参照）。
【０１７３】
ペナルティ管理のタイムスロットにおいて、Stage(m)，Stage(m+3)及びStage(n)等の各Stageのスパン制御部１２１は、Stage(0)の通信部１１３を通じて、Key及びFlagを取得する（図３１の符号Ｌ３参照）。
【０１７４】
Stage(m)及びStage(n)等の各Stageにおいて、EntryとしてKey(SAC)がないことが確認される（図３１の符号Ｌ４及びＬ５参照）。
【０１７５】
Stage(m+3)のスパン制御部１２１は、重複情報Key(XXX)を重複管理テーブル１２２においてマッチングしてEntryにおいて発見する（図３１の符号Ｌ６参照）。
【０１７６】
Stage(m+3)のスパン制御部１２１は、重複情報がFINであるため、重複管理テーブル１２２にEntry(SAC)を削除する（図３０の符号Ｋ２及び図３１の符号Ｌ７参照）。
【０１７７】
Stage(m)のスパン制御部１２１は、重複情報がSYNであるため、スパンテーブル１２３にSpan(SAC)を削除する（図３０の符号Ｋ３及び図３１の符号Ｌ８参照）。
【０１７８】
Stage(m)のスパン制御部１２１は、重複管理テーブル１２２において、アクセスがない全てのEntryにPenaltyとしてAging Counterの値を上げる（図３１の符号Ｌ９参照）。そして、Entry削除処理は終了する。
【０１７９】
次に、実施形態の一例におけるプログラマブルデバイス１におけるアクセス測定タイムスロットにおける処理を、図３２に示すフローチャート（ステップＳ１〜Ｓ５）を用いて説明する。
【０１８０】
Stage(0)のパケット管理部１１１は、現在のタイムスロットがアクセス測定（図示する例では、「Access Time Slot」）であるかを判定する（ステップＳ１）。
【０１８１】
現在のタイムスロットがアクセス測定でない場合は（ステップＳ１のＮｏルート参照）、アクセス測定タイムスロットにおける処理は終了する。
【０１８２】
一方、現在のタイムスロットがアクセス測定である場合には（ステップＳ１のＹｅｓルート参照）、パケット管理部１１１は、受信された新しいパケットがあるかを判定する（ステップＳ２）。
【０１８３】
新しいパケットがない場合には（ステップＳ２のＮｏルート参照）、処理はステップＳ１へ戻る。
【０１８４】
一方、新しいパケットがある場合には（ステップＳ２のＹｅｓルート参照）、パケット管理部１１１は、重複情報プール１１２において、パケットが届いた時間を記録する（ステップＳ３）。
【０１８５】
パケット管理部１１１は、重複情報のHash Keyを生成する（ステップＳ４）。
【０１８６】
パケット管理部１１１は、重複情報とFlagとを重複情報プール１１２に記録し（ステップＳ５）、処理はステップＳ１へ戻る。
【０１８７】
次に、実施形態の一例におけるプログラマブルデバイス１におけるペナルティ管理タイムスロットにおける処理を、図３３及び図３４に示すフローチャート（ステップＳ１１〜Ｓ２９）を用いて説明する。
【０１８８】
Stage(0)のパケット管理部１１１は、現在のタイムスロットがペナルティ管理（図示する例では、「Penalty Time Slot」）であるかを判定する（ステップＳ１１）。
【０１８９】
現在のタイムスロットがペナルティ管理でない場合は（ステップＳ１１のＮｏルート参照）、ペナルティ管理タイムスロットにおける処理は終了する。
【０１９０】
一方、現在のタイムスロットがペナルティ管理である場合には（ステップＳ１１のＹｅｓルート参照）、パケット管理部１１１は、重複情報プール１１２からHash KeyとFlagとを読み込む（ステップＳ１２）。
【０１９１】
パケット管理部１１１は、Flagにおいて、TCPのRST又はFINが存在するかを判定する（ステップＳ１３）。
【０１９２】
Flagにおいて、TCPのRST及びFINが存在しない場合には（ステップＳ１３のＮｏルート参照）、処理はステップＳ１７へ進む。
【０１９３】
一方、Flagにおいて、TCPのRST又はFINが存在する場合には（ステップＳ１３のＹｅｓルート参照）、パケット管理部１１１は、FlagがRST又はFINであるHash Keyを先に取り出す（ステップＳ１４）。
【０１９４】
Stage(1)以降のスパン制御部１２１は、重複管理テーブル１２２からFlagがRST又はFINであるEntryを削除する（ステップＳ１５）。
【０１９５】
スパン制御部１２１は、関連するスパン情報を削除する（ステップＳ１６）。
【０１９６】
スパン制御部１２１は、Flagにおいて、TCPのSYNが存在するかを判定する（ステップＳ１７）。
【０１９７】
Flagにおいて、TCPのSYNが存在しない場合には（ステップＳ１７のＮｏルート参照）、処理は図３４のステップＳ２４へ進む。
【０１９８】
一方、Flagにおいて、TCPのSYNが存在する場合には（ステップＳ１７のＹｅｓルート参照）、スパン制御部１２１は、重複管理テーブル１２２から重複情報のHash Keyに基づき一致するEntryを検索する（ステップＳ１８）。
【０１９９】
図３４において、スパン制御部１２１は、重複管理テーブル１２２において、重複情報が一致するEntryが存在するかを判定する（ステップＳ１９）。
【０２００】
重複情報が一致するEntryが存在する場合には（ステップＳ１９のＹｅｓルート参照）、当該Entryを重複管理テーブル１２２の先頭に入れてAging Counterを初期化する（ステップＳ２０）。
【０２０１】
スパン制御部１２１は、関連するスパン情報を移動し（ステップＳ２１）、処理はステップＳ２４へ進む。
【０２０２】
ステップＳ１９において、重複情報が一致するEntryが存在しない場合には（ステップＳ１９のＮｏルート参照）、スパン制御部１２１は、重複管理テーブル１２２の先頭に新しいEntryを追加する（ステップＳ２２）。
【０２０３】
スパン制御部１２１は、関連するスパン情報を生成する（ステップＳ２３）。
【０２０４】
スパン制御部１２１は、重複管理テーブル１２２において、アクセスがなかったEntryにPenaltyを与える（ステップＳ２４）。
【０２０５】
スパン制御部１２１は、重複管理テーブル１２２において、EntryのAging Counterを検索する（ステップＳ２５）。
【０２０６】
スパン制御部１２１は、Aging Counterの数値が閾値以上であるEntryが存在するかを判定する（ステップＳ２６）。
【０２０７】
Aging Counterの数値が閾値以上であるEntryが存在しない場合には（ステップＳ２６のＮｏルート参照）、処理はステップＳ２９へ進む。
【０２０８】
Aging Counterの数値が閾値以上であるEntryが存在する場合には（ステップＳ２６のＹｅｓルート参照）、スパン制御部１２１は、次のStageに該当Entryを移動する（ステップＳ２７）。
【０２０９】
スパン制御部１２１は、次のStageに関連するスパン情報を移動する（ステップＳ２８）。
【０２１０】
スパン制御部１２１は、ペナルティ管理タイムスロットのフラグを“Ｎ”に設定し（ステップＳ２９）、ペナルティ管理タイムスロットにおける処理は終了する。
【０２１１】
次に、実施形態の一例におけるプログラマブルデバイス１におけるタイムスロット管理処理を、図３５に示すフローチャート（ステップＳ３１〜Ｓ３６）を用いて説明する。
【０２１２】
Stage(0)のパケット管理部１１１は、タイマ１３３の値が“０”であるかを判定する（ステップＳ３１）。
【０２１３】
タイマ１３３の値が“０”である場合には（ステップＳ３１のＹｅｓルート参照）、処理はステップＳ３５へ進む。
【０２１４】
一方、タイマ１３３の値が“０”でない場合には（ステップＳ３１のＮｏルート参照）、パケット管理部１１１は、重複情報プール１１２のEntryの数を計測する（ステップＳ３２）。
【０２１５】
パケット管理部１１１は、新しく重複情報プール１１２に登録されたEntryが存在するかを判定する（ステップＳ３３）。
【０２１６】
新しいEntryが存在しない場合には（ステップＳ３３のＮｏルート参照）、処理はステップＳ３１へ戻る。
【０２１７】
新しいEntryが存在する場合には（ステップＳ３３のＹｅｓルート参照）、パケット管理部１１１は、重複情報プール１１２におけるEntryの数が閾値以上であるかを判定する（ステップＳ３４）。
【０２１８】
Entryの数が閾値以上でない場合には（ステップＳ３４のＮｏルート参照）、処理はステップＳ３１へ戻る。
【０２１９】
一方、Entryの数が閾値以上である場合には（ステップＳ３４のＹｅｓルート参照）、パケット管理部１１１は、タイマ１３３を初期化する（ステップＳ３５）。
【０２２０】
パケット管理部１１１は、アクセス測定タイムスロットであることを示すAccess time slot Flagを“Y”に変更する（ステップＳ３６）。そして、タイムスロット管理処理は終了する。
【０２２１】
〔Ｂ−３〕効果
上述した実施形態の一例におけるモニタリングプログラムによれば、例えば、以下の作用効果を奏することができる。
【０２２２】
重複情報プール１１２は、受信したパケットのフラグが特定のフラグである場合に、受信したパケットの送信元アドレス及び送信先アドレスを含む重複情報から生成したキーと特定のフラグとを記憶する。ペナルティ付加部１２６は、受信したパケットに応じて、処理毎にローカルメモリ１２における重複管理テーブル１２２（別言すれば、「第２の領域」）に含まれる重複情報に対するアクセス頻度を示すカウンタを更新する。ハッシュ生成部１３１は、第１のタイミングで蓄積された重複情報プール１１２（別言すれば、「第１の領域」）における各フラグに対応する処理を、重複管理テーブル１２２（別言すれば、「第２の領域」）において実施する。エントリ移動部１２７は、アクセス測定タイムスロット（別言すれば、「第２のタイミング」）で処理毎の重複管理テーブル１２２（別言すれば、「第２の領域」）を参照する。そして、エントリ移動部１２７は、Aging Counterが閾値以上である重複管理テーブル１２２におけるエントリをローカルメモリ１２から次段のローカルメモリ１２又はシェアメモリ１７に移動させる。
【０２２３】
これにより、小容量のローカルメモリ１２によって、マイクロサービスをモニタリングできる。具体的には、マイクロサービスの重複情報をKeyとして利用することにより、アクセス頻度と経過時間とに基づいて、ローカルメモリ１２とシェアメモリ１７とを効率的に制御し、コピーによる余分な負荷（別言すれば、「レイテンシの増加」）を減少できる。
【０２２４】
例えば、ローカルメモリ１２に保存可能なEntryの数が５万であり、シェアメモリ１７に保存可能なEntryの数が１００万であり、メモリ間のアクセス（別言すれば、「コピー」）によるレイテンシが５０ナノ秒であると仮定する。
【０２２５】
そして、ローカルメモリ１２に３個保存され、シェアメモリ１７に７個保存されているEntryが所定時間内に１０回アクセスされた際のレイテンシを想定する。
【０２２６】
各メモリに順次アクセスするためには、シェアメモリ１７にある７個のEntryにアクセスするための余分な負荷として7*50=350nsかかる。当該負荷を１０回繰り返されると、350*10=3500nsがかかってしまう。
【０２２７】
一方、上述した実施形態の一例では、初回のアクセスでは同様に350nsがかかるが、２回目のアクセスからはEntryがローカルメモリ１２に配置されるため、負荷を１０分の１に低減できる。
【０２２８】
重複情報プール１１２におけるエントリの数が一定数以上になった際に、アクセス測定の処理を完了させ、ペナルティ管理における処理が開始される。また、重複情報プール１１２におけるエントリの数が一定数に達しない場合には、アクセス測定が継続される。
【０２２９】
これにより、アクセス測定タイムスロットとペナルティ管理タイムスロットとを効率的に切り替えられる。
【０２３０】
特定のフラグは、ＴＣＰによって定義されるフラグと、ＩＰによって定義されるフラグとを含む。また、特定のフラグがＩＰによって定義されるフラグである場合には、ネットワーク２のスループットが低下していることが通知される。
【０２３１】
これにより、管理者は早期にスループットの低下を認識できる。
【０２３２】
重複情報は、送信先ポート番号を含む。また、重複情報は、送信元ポート番号を含む。更に、重複情報は、送信先ポート番号及び送信元ポート番号を共に含んでもよい。
【０２３３】
これにより、送信先ポート番号と送信元ポート番号との一方又は両方が固定でない場合においても、マイクロサービスをモニタリングできる。
【０２３４】
〔Ｃ〕その他
開示の技術は上述した実施形態に限定されるものではなく、本実施形態の趣旨を逸脱しない範囲で種々変形して実施することができる。本実施形態の各構成及び各処理は、必要に応じて取捨選択することができ、あるいは適宜組み合わせてもよい。
【０２３５】
〔Ｄ〕付記
以上の実施形態に関し、さらに以下の付記を開示する。
【０２３６】
（付記１）
コンピュータに、
受信したパケットの送信元アドレス及び送信先アドレスを含む重複情報に付加されて前記受信したパケットに対する処理を示すフラグが特定のフラグである場合に、前記重複情報から生成したキーと前記特定のフラグとを第１のローカルメモリにおける第１の領域に記憶させ、
前記受信したパケットに応じて、処理毎に前記第１のローカルメモリにおける第２の領域に含まれる重複情報に対するアクセス頻度を示すカウンタを更新し、
第１のタイミングで蓄積された前記第１の領域における各フラグに対応する処理を、前記第２の領域において実施し、
第２のタイミングで処理毎の前記第２の領域を参照し、前記カウンタが閾値以上である前記第２の領域におけるエントリを前記第１のローカルメモリから当該第１のローカルメモリの後段に備えられる第２のローカルメモリに移動させる、
処理を実行させる、モニタリングプログラム。
【０２３７】
（付記２）
前記第１の領域におけるエントリの数が一定数以上になった際に、前記第１のタイミングの処理を完了させ、前記第２のタイミングにおける処理を開始する、
処理を前記コンピュータに実行させる、付記１に記載のモニタリングプログラム。
【０２３８】
（付記３）
前記第１の領域におけるエントリの数が一定数に達しない場合には、前記第１のタイミングの処理を継続する、
処理を前記コンピュータに実施させる、付記１又は２に記載のモニタリングプログラム。
【０２３９】
（付記４）
前記特定のフラグは、Transmission Control Protocol/Internet Protocol（ＴＣＰ／ＩＰ）ヘッダの通信プロトコルで定義されたフラグを含む、
付記１〜３のいずれか１項に記載のモニタリングプログラム。
【０２４０】
（付記５）
前記重複情報は、送信先ポート番号を更に含む、
付記１〜４のいずれか１項に記載のモニタリングプログラム。
【０２４１】
（付記６）
前記重複情報は、送信元ポート番号を更に含む、
付記１〜５のいずれか１項に記載のモニタリングプログラム。
【０２４２】
（付記７）
受信したパケットの送信元アドレス及び送信先アドレスを含む重複情報に付加されて前記受信したパケットに対する処理を示すフラグが特定のフラグである場合に、前記重複情報から生成したキーと前記特定のフラグとを第１の領域に記憶する第１のローカルメモリと、
前記受信したパケットに応じて、処理毎に前記第１のローカルメモリにおける第２の領域に含まれる重複情報に対するアクセス頻度を示すカウンタを更新する更新部と、
第１のタイミングで蓄積された前記第１の領域における各フラグに対応する処理を、前記第２の領域において実施する処理部と、
第２のタイミングで処理毎の前記第２の領域を参照し、前記カウンタが閾値以上である前記第２の領域におけるエントリを前記第１のローカルメモリから当該第１のローカルメモリの後段に備えられる第２のローカルメモリに移動させる移動部と、
を備える、プログラマブルデバイス。
【０２４３】
（付記８）
前記更新部と前記処理部と前記移動部とは、前記第１の領域におけるエントリの数が一定数以上になった際に、前記第１のタイミングの処理を完了させ、前記第２のタイミングにおける処理を開始する、
付記７に記載のプログラマブルデバイス。
【０２４４】
（付記９）
前記更新部と前記処理部と前記移動部とは、前記第１の領域におけるエントリの数が一定数に達しない場合には、前記第１のタイミングの処理を継続する、
付記７又は８に記載のプログラマブルデバイス。
【０２４５】
（付記１０）
前記特定のフラグは、Transmission Control Protocol/Internet Protocol（ＴＣＰ／ＩＰ）ヘッダの通信プロトコルで定義されたフラグを含む、
付記７〜９のいずれか１項に記載のプログラマブルデバイス。
【０２４６】
（付記１１）
前記重複情報は、送信先ポート番号を更に含む、
付記７〜１０いずれか１項に記載のプログラマブルデバイス。
【０２４７】
（付記１２）
前記重複情報は、送信元ポート番号を更に含む、
付記７〜１１のいずれか１項に記載のプログラマブルデバイス。
【０２４８】
（付記１３）
プログラマブルデバイスにおいて、
受信したパケットの送信元アドレス及び送信先アドレスを含む重複情報に付加されて前記受信したパケットに対する処理を示すフラグが特定のフラグである場合に、前記重複情報から生成したキーと前記特定のフラグとを第１のローカルメモリにおける第１の領域に記憶させ、
前記受信したパケットに応じて、処理毎に前記第１のローカルメモリにおける第２の領域に含まれる重複情報に対するアクセス頻度を示すカウンタを更新し、
第１のタイミングで蓄積された前記第１の領域における各フラグに対応する処理を、前記第２の領域において実施し、
第２のタイミングで処理毎の前記第２の領域を参照し、前記カウンタが閾値以上である前記第２の領域におけるエントリを前記第１のローカルメモリから当該第１のローカルメモリの後段に備えられる第２のローカルメモリに移動させる、
モニタリング方法。
【０２４９】
（付記１４）
前記第１の領域におけるエントリの数が一定数以上になった際に、前記第１のタイミングの処理を完了させ、前記第２のタイミングにおける処理を開始する、
付記１３に記載のモニタリング方法。
【０２５０】
（付記１５）
前記第１の領域におけるエントリの数が一定数に達しない場合には、前記第１のタイミングの処理を継続する、
付記１３又は１４に記載のモニタリング方法。
【０２５１】
（付記１６）
前記特定のフラグは、Transmission Control Protocol/Internet Protocol（ＴＣＰ／ＩＰ）ヘッダの通信プロトコルで定義されたフラグを含む、
付記１３〜１５のいずれか１項に記載のモニタリング方法。
【０２５２】
（付記１７）
前記重複情報は、送信先ポート番号を更に含む、
付記１３〜１６のいずれか１項に記載のモニタリング方法。
【０２５３】
（付記１８）
前記重複情報は、送信元ポート番号を更に含む、
付記１３〜１７のいずれか１項に記載のモニタリング方法。
【符号の説明】
【０２５４】
１，８  ：プログラマブルデバイス
１１０，８１：パイプライン
１１，８１１：マッチアクションテーブル
１１１  ：パケット管理部
１１２  ：重複情報プール
１１３  ：通信部
１１４  ：パケット解析部
１１５  ：ハッシュ生成部
１１８  ：スパン生成部
１１９  ：時刻管理部
１２１  ：スパン制御部
１２２  ：重複管理テーブル
１２３  ：スパンテーブル
１２４  ：通信部
１２５  ：重複情報確認部
１２６  ：ペナルティ付加部
１２７  ：エントリ移動部
１２８  ：スパン生成部
１２９  ：時刻管理部
１３０  ：スパン管理部
１３１  ：ハッシュ生成部
１３２  ：重複情報依頼部
１３３  ：ハッシュ生成部
１３３  ：タイマ
１２，８３，８１２：ローカルメモリ
１３    ：スイッチ
１４，８２：入力ポート
１５    ：パケットパーサ
１６    ：出力ポート
１７    ：シェアメモリ
２      ：ネットワーク
６１    ：クライアントアプリケーション
６２    ：認証サービス
６３    ：サービス
６２１，６３１，６３２，７１，７２，９１：マイクロサービス
９２    ：サイドカー
９２１  ：フロー情報
９３    ：ＣＰＵ
【図１】
2020113924.tif 000003
【図２】
2020113924.tif 000004
【図３】
2020113924.tif 000005
【図４】
2020113924.tif 000006
【図５】
2020113924.tif 000007
【図６】
2020113924.tif 000008
【図７】
2020113924.tif 000009
【図８】
2020113924.tif 000010
【図９】
2020113924.tif 000011
【図１０】
2020113924.tif 000012
【図１１】
2020113924.tif 000013
【図１２】
2020113924.tif 000014
【図１３】
2020113924.tif 000015
【図１４】
2020113924.tif 000016
【図１５】
2020113924.tif 000017
【図１６】
2020113924.tif 000018
【図１７】
2020113924.tif 000019
【図１８】
2020113924.tif 000020
【図１９】
2020113924.tif 000021
【図２０】
2020113924.tif 000022
【図２１】
2020113924.tif 000023
【図２２】
2020113924.tif 000024
【図２３】
2020113924.tif 000025
【図２４】
2020113924.tif 000026
【図２５】
2020113924.tif 000027
【図２６】
2020113924.tif 000028
【図２７】
2020113924.tif 000029
【図２８】
2020113924.tif 000030
【図２９】
2020113924.tif 000031
【図３０】
2020113924.tif 000032
【図３１】
2020113924.tif 000033
【図３２】
2020113924.tif 000034
【図３３】
2020113924.tif 000035
【図３４】
2020113924.tif 000036
【図３５】
2020113924.tif 000037