JP2022007690A - ネットワークサービスシステム、ネットワーク管理方法およびコンピュータプログラム - Google Patents

Abstract

【課題】分散トレーシングを用いたネットワーク管理を改善する技術を提供する。【解決手段】ネットワークサービスシステム１００は、所定の要求に応じて複数のサービス呼び出しを連鎖的に実行する。トレース記憶部３４は、上記複数のサービスから出力された複数の出力データであって、連鎖的に実行された複数のサービス呼び出しを追跡するための追跡識別子を含む複数の出力データを記憶する。ネットワークサービスシステム１００は、上記複数のサービスそれぞれの処理においてユーザのモバイル識別子を検出した場合、そのモバイル識別子を各サービスの出力データに設定する。解析部３８は、トレース記憶部３４に記憶された複数の出力データの中から、検索対象として指定されたモバイル識別子を含む出力データを抽出し、その出力データに含まれる追跡識別子を含む別の出力データをさらに抽出する。【選択図】図７

Description

本開示は、データ処理技術に関し、特にネットワークサービスシステム、ネットワーク管理方法およびコンピュータプログラムに関する。

第５世代移動通信システム（以下「５Ｇ」と呼ぶ。）のコアネットワークでは、ＥＴＳＩ（European Telecommunications Standards Institute） ＮＦＶ（Network Functions Virtualization）で策定された仮想化技術を用いることを前提として、ＳＢＡ（Service Based Architecture）が採用されている。ＳＢＡでは、ＡＭＦ（Access and Mobility Management Function）やＳＭＦ（Session Management Function）のようにネットワークに必要な個別機能群ＮＦ（Network Function）を定義し、これら複数のＮＦがＳＢＩ（Service Based Interface）と呼ばれる統一されたインタフェースを介して接続される。

５Ｇネットワークに必要な個別機能群ＮＦ（Network Function）を実現するソフトウェアの構成技術として、マイクロサービスアーキテクチャが採用されることがある。マイクロサービスアーキテクチャでは、個々のＮＦは、より細分化された複数の単機能ＮＦサービス、フロントエンド部、データベース部等、複数のマイクロサービスにより構成される。このような分散システムでは、１つのリクエストを契機に、複数のマイクロサービス間での通信が発生する。

５Ｇネットワーク内を伝送されるトラフィックのキャプチャと解析は、通信障害時のトラブルシューティングや機能試験確認に必要不可欠である。一連のサービス呼び出しのトラフィックを関連付けて記録することで、マイクロサービスアーキテクチャにおけるトレーシングを可能にする技術が分散トレーシングである。分散トレーシングの標準仕様を策定するプロジェクトとしてＯｐｅｎＴｒａｃｉｎｇがある（例えば特許文献１参照）。また、ＯｐｅｎＴｒａｃｉｎｇの標準に準拠した分散トレーシングの実装としては例えばＪａｅｇｅｒがある（例えば特許文献２参照）。

OpenTracing specification"，［online］，［令和2年5月29日検索］，インターネット＜URL：https://opentracing.io/specification/＞ Architecture Jaeger documentation"，［online］，［令和2年5月29日検索］，インターネット＜URL：https://www.jaegertracing.io/docs/1.18/architecture/＞

特定の加入者のモバイル端末の通信に関するトラブルシューティングや機能試験確認では、データベースに保存してあるトレースデータの中から、当該加入者に関するモバイル識別子を用いて、当該加入者に関するデータを抽出する必要がある。しかし、現在の分散トレーシングでは、そのための仕組みが提供されていない。

本開示は本発明者の上記課題認識に基づきなされたものであり、１つの目的は、分散トレーシングを用いたネットワーク管理を改善する技術を提供することにある。

上記課題を解決するために、本開示のある態様のネットワークサービスシステムは、所定の要求に応じて複数のサービス呼び出しが連鎖的に実行されるシステムであって、複数のサービスを提供する複数のサービス部と、複数のサービス部から出力された複数の出力データであって、連鎖的に実行された複数のサービス呼び出しを追跡するための追跡識別子を含む複数の出力データを記憶する記憶部と、連鎖的に実行された複数のサービス呼び出しに関する情報を生成する解析部と、を備える。複数のサービス部のそれぞれは、自身の処理においてユーザのモバイル識別子を検出した場合、そのモバイル識別子を出力データに設定し、解析部は、記憶部に記憶された複数の出力データの中から、検索対象として指定されたモバイル識別子を含む出力データを抽出し、その出力データに含まれる追跡識別子を含む別の出力データをさらに抽出する。

本開示の別の態様は、ネットワーク管理方法である。この方法は、所定の要求に応じて複数のサービス呼び出しが連鎖的に実行されるシステムを構成するコンピュータが、複数のサービスを実行するステップと、複数のサービスから出力された複数の出力データであって、連鎖的に実行された複数のサービス呼び出しを追跡するための追跡識別子を含む複数の出力データを所定の記憶部に格納するステップと、連鎖的に実行された複数のサービス呼び出しに関する情報を生成する解析ステップと、を実行し、実行するステップは、複数のサービスそれぞれの処理においてユーザのモバイル識別子を検出した場合、そのモバイル識別子を出力データに設定し、解析ステップは、記憶部に記憶された複数の出力データの中から、検索対象として指定されたモバイル識別子を含む出力データを抽出し、その出力データに含まれる追跡識別子を含む別の出力データをさらに抽出する。

なお、以上の構成要素の任意の組合せ、本開示の表現を、装置、コンピュータプログラム、コンピュータプログラムを読み取り可能に記録した記録媒体などの間で変換したものもまた、本開示の態様として有効である。

本開示によれば、分散トレーシングを用いたネットワーク管理を改善することができる。

５Ｇのシステムアーキテクチャを示す図である。 ＤＡＧを用いたトレースの表記例を示す図である。 時間軸を用いたトレースの表記例を示す図である。 スパンコンテキストの伝播の例を示す図である。 スパンコンテキストの伝播の例を示す図である。 第１実施例に係るネットワークサービスシステムの構成を示すブロック図である。 第１実施例に係るネットワークサービスシステムの詳細な構成を示すブロック図である。 ＨＴＴＰヘッダへのモバイル識別子の設定例を示す図である。 モバイル識別子をキーとしたトレース発見の例を示す図である。 モバイル識別子をキーとしたトレース発見の例を示す図である。 モバイル識別子をキーとしたトレース発見の例を示す図である。 第３実施例に係るネットワークサービスシステムの詳細な構成を示すブロック図である。 図１３（ａ）、図１３（ｂ）、図１３（ｃ）、図１３（ｄ）は、第１サンプリング決定部の動作例を示す図である。

実施例のネットワークサービスシステムの構成を説明する前に概要を説明する。
（１）前提技術
（１－１）５Ｇコア
３ＧＰＰでは５Ｇの実現に向けて、新しいコアネットワークである５Ｇコアをリリース１５仕様として策定した。５Ｇの提供アーキテクチャは、（１）従来のＥＰＣ（Evolved Packet Core）をコアネットワークとし、５Ｇ無線アクセスネットワーク（以下「ＲＡＮ」とも呼ぶ。）を４ＧのＲＡＮと協調動作させるＮＳＡ（Non Stand Alone）と、（２）従来のＥＰＣとは独立して５Ｇコアを導入し、５ＧのＲＡＮを直接制御するＳＡ（Stand Alone）の２つに大別される。３ＧＰＰ リリース１５では、ＮＳＡとＳＡの両方のアーキテクチャが策定された。３ＧＰＰ ＴＳ２３．５０１において５Ｇコアの基本アーキテクチャが規定され、ＴＳ２３．５０２において５Ｇコアの動作手順が規定され、ＴＳ２３．５０３において５ＧコアのＰＣＣ（Policy and Charging Control）が規定されている。

図１は、５Ｇのシステムアーキテクチャを示す。５Ｇコアでは、ＥＴＳＩ ＮＦＶで策定された仮想化技術（すなわちネットワーク機能を汎用サーバ上で動作させるための技術）を活用することを前提として、ＳＢＡが採用されている。ＳＢＡでは、ＡＭＦやＳＭＦのようにネットワークに必要な個別機能郡ＮＦを定義し、これら複数のＮＦがＳＢＩと呼ばれる統一的なインタフェースを介して接続される。図１のＮａｍｆ、Ｎｓｍｆ等がＳＢＩに相当し、図１のＮ１、Ｎ２、Ｎ３等は非ＳＢＩ（例えば非ＨＴＴＰインタフェース）である。

個々のＮＦは、より細分化された複数の単機能ＮＦサービスにより構成される。この単機能ＮＦサービスは後述のマイクロサービスに相当する。或るＮＦのＮＦサービスに対して、他のＮＦのＮＦサービスは、他のノードを介することなく直接アクセスできる。ＳＢＡでは、必要なＮＦサービスの発見機能（Service Discovery）を提供するＮＲＦ（Network Repository Function）が規定されている。ＳＢＩのプロトコルスタックは、ＴＳ２９．５００で規定され、また、ＨＴＴＰ／２が採用されている。アプリケーションデータはＪＳＯＮ（JavaScript Object Notation）（「JavaScript」は登録商標）を介して交換され、セキュリティ保護にはＴＬＳ（ＴＬＳ１．２またはＴＬＳ１．３）を利用する。

ＥＰＣなどコアネットワークが動作する仮想化基盤として、ＯｐｅｎＳｔａｃｋが広く利用されており、また、５Ｇコアが動作する仮想化基盤として、クラウドネイティブ技術の一つでありコンテナオーケストレータであるクバネテス（Kubernetes）が想定される。コンテナは、ＯＳ（Operating System）まで含めてカプセル化する仮想マシンより軽量であり、起動時間が短く、またリソース効率が良いなどのメリットがある。そのため、５Ｇコアを動作させる実装として、コンテナの利用が普及しつつある。

（１－２）トレーシング
コアネットワーク内のトラフィックのキャプチャとその解析は、通信障害発生時のトラブルシューティングや機能試験確認に必要不可欠である。従来のＥＰＣでは、ＮＦＶを適用する場合であっても、各ＮＦを１つの仮想マシンとし特定の物理サーバに配備することで、特定の物理サーバの特定のＮＩＣ（Network Interface Card）で行われる通信がどのＮＦのものかを容易に識別できた。そのため、ポートミラーリング等の技術により特定のＮＦ間の通信をパケットキャプチャすることができた。

一方、クバネテスにより制御されるクラウドネイティブな環境では、複数の物理サーバ（以下「ノード」とも呼ぶ。）でリソースプールを形成し、また、５ＧコアにおけるＮＦの配備箇所はクバネテスにより動的制御される。そのため、ＮＦ間の通信はノード内で行われることになりパケットキャプチャを行うことができない。さらに、ソフトウェア構成技術としてマイクロサービスアーキテクチャを採用する場合、１つのＮＦは、先に述べた複数の論理的な単機能ＮＦサービス、フロントエンド部、ＤＢ（Database）等、複数のマイクロサービスで構成される。

このような分散システムでは、１つのリクエストを契機に、サービス間（マイクロサービス間）の通信が発生する。分散システムが大規模化した際には、多数のサービス間通信が発生し、サービス同士の依存関係の把握が困難になる。また、多数のサービスが複雑に連携し合うと、障害発生時の解析も困難となる。次の章では、このようなマイクロサービスアーキテクチャでのトレーシングを可能にする分散トレーシングについて述べる。

（１－３）分散トレーシング
分散トレーシングは、連鎖的に生じた一連のサービス呼び出しのトラフィックを関連付けて記録することにより、マイクロサービスアーキテクチャにおけるトレーシングの課題を解決する技術である。分散トレーシングでは、１つの機能呼び出しに伴って発生するサービス間の通信を全て把握できるためサービス（マイクロサービス）同士の依存関係を特定可能になる。また、１つ１つのトラフィックの所要時間や通信内容を全て記録することで、障害発生時やパフォーマンス劣化時にピンポイントで原因箇所を特定することができる。

分散トレーシングはその性質上、アプリケーションのコードに、トレース情報の取得や送信に関するコードを記述する必要があるが、特定のベンダの分散トレーシング技術に依存したコードがアプリケーションに書かれるとその後の保守や移行が困難になる。そこで、ベンダニュートラルな分散トレーシングの標準仕様を策定するプロジェクトであるＯｐｅｎＴｒａｃｉｎｇが２０１５年に立ち上がった。

ＯｐｅｎＴｒａｃｉｎｇでは、トレース情報のデータフォーマットや、データ収集用バックエンドのＡＰＩ（Application Programming Interface）仕様等、分散トレーシングのための標準仕様を策定している。ＯｐｅｎＴｒａｃｉｎｇでは、トレース情報は、主に以下の３つの要素、「トレース」、「スパン」、「スパンコンテキスト」で構成される。

１）トレース：連鎖的に実行される一連のサービス呼び出しを追跡して記録した情報の集合体である。
２）スパン：個々のサービスがリクエストを受け、それに応答するまでの単位である。スパンは、個々のサービスの処理内容または処理結果とも言える。１つのスパンの中で別のサービスを呼び出すと、呼び出されたサービスが応答するまでの単位を表す子スパンを想定できる。トレースはこのような階層構造を持ったスパンの集合体と位置づけられる。
３）スパンコンテキスト：複数のスパンを連鎖的なサービス呼び出しとして関連付けるための識別子となる情報。或るサービスから別のサービスを呼び出す際にスパンコンテキストを伝播させることによって複数のスパンを関連付けることができる。

各スパンの間には関連性があり、トレースは、スパンの有向非巡回グラフ（Directed Acyclic Graph、ＤＡＧ）と位置づけられる。図２は、ＤＡＧを用いたトレースの表記例を示す。図２の例では、１つのトレースが６個のスパンで構成されている。また、時間軸上に複数のスパンの関係性を示すことによりトレースを表記する形態も用いられる。図３は、時間軸を用いたトレースの表記例を示す。

ＯｐｅｎＴｒａｃｉｎｇの標準に準拠した分散トレーシングの実装として、Ｊａｅｇｅｒ、Ｚｉｐｋｉｎ、Ｌｉｇｈｔｓｔｅｐが挙げられる。また、マイクロサービスアーキテクチャのように個々のサービスの分割と連携により生じる様々な課題（例えば、ネットワーク通信起因の障害対応、パフォーマンスの低下、運用オペレーションの負荷の増加、障害解析の高難易度化等）を緩和するために、サービスメッシュが広く用いられてきている。サービスメッシュにも多くの実装が存在し、Ｉｓｔｉｏをはじめとして、Ｌｉｎｋｅｒｄ、Ｃｏｎｓｕｌ等が用いられている。

図４は、スパンコンテキストの伝播の例を示す。同図は、Ｉｓｔｉｏを利用したサービスメッシュの環境において、Ｊａｅｇｅｒを用いて分散トレーシングを行う際に想定されるアーキテクチャを示している。ＩｓｔｉｏとＪａｅｇｅｒを組み合わせた分散トレーシングでは、サイドカーコンテナとしてサービス間通信を仲介するＥｎｖｏｙがＪａｅｇｅｒのデータコレクタにスパンを送信する。Ｅｎｖｏｙは、レイヤ７プロキシであり、個々のマイクロサービスに１つずつ配置される。また、Ｅｎｖｏｙは、自身が担当するマイクロサービスが送受信するトラフィック（リクエストデータ等）を必ず仲介し、事前にＩｓｔｉｏのＰｉｌｏｔから受信した制御規則を適用する。

図４に示すように、Ｊａｅｇｅｒを用いた分散トレーシングでは、サービス間でスパンコンテキストを伝播する必要がある。そのため、図４に示すように、サービスアプリケーション側に、他サービスを呼び出す際のリクエストヘッダに外部から受信したスパンコンテキストを付与する動作を実装する必要がある。図４の例では、Ｉｎｇｒｅｓｓ Ｇａｔｅｗａｙは、外部から流入したＨＴＴＰリクエストに自動でスパンコンテキストを付与し、サービスＡ（アプリケーション）は、受信したスパンコンテキストを、サービスＢを呼び出すＨＴＴＰリクエストに設定する。このようなスパンコンテキストの引継をコンテキスト伝播（Propagation）という。

各スパンのスパンコンテキストを伝播させる実装としてＺｉｐｋｉｎのＢ３伝播が利用される。図５も、スパンコンテキストの伝播の例を示す。図５では、サービスＡがスパンコンテキストＡをＢ３ヘッダの形式でサービスＢへ送信し、サービスＢがスパンコンテキストＢをＢ３ヘッダの形式でサービスＣへ送信する状況における、サービスＢでのトレーサーのスパンコンテキストの処理とＢ３ヘッダ伝播の例を示している。

サービスＢのサーバートレーサー（スパンコンテキスト伝播のための機能）は、サービスＡから受信したＨＴＴＰリクエストのＢ３ヘッダをデシリアライズしてスパンコンテキストＡを復元する。次に、サービスＢは、サービスＡからのリクエストに基づいてサービスＣを呼び出す。その際に、サービスＢのサーバートレーサーは、スパンコンテキストＡをもとにスパンコンテキストＢを生成する。

具体的には、サービスＢのサーバートレーサーは、スパンコンテキストＡに含まれるトレースＩＤとサンプリング決定値（Sampling decision）をスパンコンテキストＢにコピーする。サービスＢのサーバートレーサーは、スパンコンテキストＡのスパンＩＤを、スパンコンテキストＢの親スパンＩＤにコピーし、また、サービスＢのスパンＩＤを新規に生成し、そのスパンＩＤをスパンコンテキストＢのスパンＩＤに設定する。サービスＢのサーバートレーサーは、スパンコンテキストＢをＢ３ヘッダの形式にシリアライズし、シリアライズ化されたスパンコンテキストＢを、サービスＣを呼び出すＨＴＴＰリクエストへ設定する。

トレースＩＤは、連鎖的に実行された一連のサービス呼び出しを一意に識別可能なＩＤであり、言い換えれば、連鎖的に実行された複数のサービス呼び出しを追跡するための追跡識別子である。スパンＩＤは、サービスが受け付けた複数の要求のそれぞれに応じたサービスの処理を一意に識別可能なＩＤであり、同じサービスであっても要求ごとに異なる値が設定される。

なお、トレースＩＤは、６４ビットまたは１２８ビット長のＩＤであり、Ｂ３ヘッダでは、１６進数（HEXADECIMAL）エンコードの１６文字長または３２文字長となる。スパンＩＤと親スパンＩＤは、６４ビット長のＩＤであり、Ｂ３ヘッダでは１６進数エンコードの１６文字長となる。サンプリング決定値には、１（Acceptまたはtrue）と、０（Denyまたはfalse）が設定される。サンプリング決定値は、Ｅｎｖｏｙ等のプロキシにおいて、トレース情報のサンプリング要否の判断、言い換えれば、コレクタへのトレース情報の送信要否の判断に用いられる。

（２）課題
（２－１）課題１
モバイル識別子によりトレース結果をフィルタリングすることができない。実施例でのモバイル識別子は、ＳＵＰＩ（Subscription. Permanent Identifier）とＰＥＩ（Permanent Equipment Identifier）の少なくとも一方を含む。

特定の加入者やその加入者の端末の通信に関するトラブルシューティングまたは機能試験確認のためには、ＤＢに保存してあるトレースデータを、加入者識別子であるＳＵＰＩや端末識別子であるＰＥＩを用いてフィルタリングする必要がある。一方で、ＳＢＩのＨＴＴＰリクエストおよびＨＴＴＰレスポンスのヘッダ部には、仕様上、ユーザの識別子を設定することはない。

また、ユーザの識別子を設定できたとしても、個人を特定できる形式で、ＩＭＳＩ（International Mobile Subscriber Identity）／ＩＭＥＩ（International Mobile Equipment Identifier）等の識別子をＨＴＴＰリクエストで流通させることは、ゼロトラストの観点から避けるべきである。３ＧＰＰの仕様上、ＨＴＴＰリクエストおよびＨＴＴＰレスポンスのボディ部にはＪＳＯＮ形式で識別子が設定されることがあるがその利用は限定的である。

（２－２）課題２
５Ｇでは、ＳＵＰＩに加えＳＵＣＩ（Subscriber Concealed Identifier）という識別子が標準化された。従来の４Ｇでは、ＵＥ（User Equipment）のアタッチ時に認証認可の対象となるＩＭＳＩをアタッチリクエストに入れてＭＭＥ（Mobility Management Entity）へ送信していた。しかし、認証認可前はＵＥとｅＮＢ（evolved Node B）間でセキュリティコンテキストが確立されていないため、ＩＭＳＩを平文で送信していた。セキュリティリスクを低減するため、５ＧではＳＵＣＩというＳＵＰＩから生成される識別子を用いて認証認可を行う。仮に課題１が解決できたとしても、ＳＵＰＩやＰＥＩだけでは、ＳＵＣＩに基づき行われる初期登録（Initial Registration）手順をトレースすることができない。

（２－３）課題３
トレース情報のサンプリング要否は、予め定められたサンプリングレートに基づいてランダムに決定される。そのため、障害発生時等に抽出の必要が生じたトレース情報がＤＢに保存されていないことがある。ＩｓｔｉｏとＪａｅｇｅｒを組み合わせて利用する場合、デフォルトのサンプリングレートは１％であり、変更することもできる。仮に課題１が解決できたとしても、トレース情報がそもそも保存されていなければ、解析が必要なトレース情報を見ることはできない。一方、トレース情報を全てＤＢに保存することは、トレース情報を送受信するプロキシおよびコレクタに多大な負荷がかかってしまう。

（３）実施例
上記の課題１～課題３を鑑みて、本開示では、分散トレーシングにおけるネットワーク管理を改善する技術を提案する。具体的には、第１実施例では、上記の課題１を解決する技術を提案する。第２実施例では、上記の課題２を解決する技術を提案する。第３実施例では、上記の課題３を解決する技術を提案する。

（３－１）第１実施例
上記の課題１を解決するため、第１実施例に係るネットワークサービスシステムの各サービスは、外部へ出力するＨＴＴＰリクエスト（以下「出力用ＨＴＴＰリクエスト」と呼ぶ。）を生成する際、前段のサービスから受信したＨＴＴＰリクエストに含まれるＳＵＰＩやＰＥＩ等のモバイル識別子をコピーして出力用ＨＴＴＰリクエストのヘッダ部に設定する。それとともに、各サービスは、前段のサービスから受信したＨＴＴＰリクエストに含まれないモバイル識別子であって、かつ、自身の処理において知り得た新たなモバイル識別子がある場合は、そのモバイル識別子を出力用ＨＴＴＰリクエストのヘッダ部に追加する。

図６は、第１実施例に係るネットワークサービスシステム１００の構成を示すブロック図である。本明細書のブロック図で示す複数の機能ブロックは、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムをＣＰＵが実行すること等により実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

ネットワークサービスシステム１００は、ユーザのモバイル機器であるＵＥ１０が接続される基地局装置１０２と、基幹回線網であるコアネットワークシステム１０４を備える。ネットワークサービスシステム１００は、ＵＥ１０から送信された所定の要求に応じて、基地局装置１０２およびコアネットワークシステム１０４が提供する複数のサービスの呼び出しが連鎖的に実行される通信システムである。ネットワークサービスシステム１００にはＮＦＶが適用され、基地局装置１０２のネットワーク機能ＮＦと、コアネットワークシステム１０４のネットワーク機能ＮＦは仮想化され、不図示の汎用サーバの仮想基盤上にソフトウェアとして実装される。

図７は、第１実施例に係るネットワークサービスシステム１００の詳細な構成を示すブロック図である。ゲートウェイ装置１２は、イングレスゲートウェイとも言え、外部から入力された所定の要求パケット（実施例ではＨＴＴＰリクエスト）を受け付け、その要求パケットをサービスへ転送する中継装置である。

Ｐｏｄ１４、Ｐｏｄ１８、Ｐｏｄ２４、Ｐｏｄ３０は、クバネテスでドッカーコンテナを管理するための最小単位を指すものであり、コンピュータ上のプロセスである。Ｐｏｄ１４は、ゲートウェイ装置１２にデプロイされる。Ｐｏｄ１８、Ｐｏｄ２４、Ｐｏｄ３０は、１台の汎用サーバ上にデプロイされ、または、複数台の汎用サーバ上に分散してデプロイされる（汎用サーバは不図示）。

各Ｐｏｄ内の機能（コンテナ）は、コンピュータプログラムとして実装されてもよく、そのコンピュータプログラムが記録された記録媒体、または、ネットワークを介して、各サーバにデプロイされてもよい。各Ｐｏｄが配置されたサーバのプロセッサは、ストレージに記憶された上記コンピュータプログラムをメインメモリに読み出して実行することにより、各Ｐｏｄ内の機能を発揮してもよい。

Ｐｏｄ１４は、ＧＷプロキシ部１６を含む。Ｐｏｄ１８は、第１サービス部２０と第１プロキシ部２２を含む。Ｐｏｄ２４は、第２サービス部２６と第２プロキシ部２８を含む。ＧＷプロキシ部１６、第１プロキシ部２２、第２プロキシ部２８は、サイドカーコンテナとしてデプロイされたサービス間通信を仲介するＥｎｖｏｙプロキシである。

第１サービス部２０は、第１のサービスを提供し、言い換えれば、第１のサービスとして定められたデータ処理を実行する。第２サービス部２６は、第１のサービスとは異なる第２のサービスを提供し、言い換えれば、第２のサービスとして定められたデータ処理を実行する。第１実施例では、第１のサービスと第２のサービスはともにマイクロサービスである。第１のサービスと第２のサービスは、同じＮＦのマイクロサービスであってもよい。例えば、第１サービス部２０は、ＡＭＦの第１の機能を提供し、第２サービス部２６は、ＡＭＦの第２の機能を提供するものであってもよい。また、第１のサービスと第２のサービスは、異なるＮＦのマイクロサービスであってもよい。

Ｐｏｄ３０は、トレース収集部３２を含む。トレース収集部３２は、ゲートウェイ装置１２と、複数のサービス部（第１サービス部２０および第２サービス部２６）から出力された複数の出力データを取得する。この出力データは、トレース情報またはスパンとも言え、第１実施例での出力データは、ＨＴＴＰリクエストである。トレース収集部３２は、ゲートウェイ装置１２、第１サービス部２０、第２サービス部２６から出力された出力データをトレース情報としてトレース記憶部３４に格納する。

トレース記憶部３４は、複数のトレース情報、言い換えれば、複数のスパンのデータを記憶するデータベースである。第１実施例のトレース情報は、図５のＨＴＴＰリクエストに示すように、連鎖的に実行された複数のサービス呼び出しを追跡するための追跡識別子（以下「トレースＩＤ」と呼ぶ。）を含む。

運用者端末３６は、ネットワークサービスシステム１００の運用者（言い換えれば保守者）により操作される情報処理端末である。解析部３８は、運用者端末３６からの要求に応じて、トレース記憶部３４を検索して、連鎖的に実行された複数のサービス呼び出しに関する情報（以下「トレース結果」とも呼ぶ。）を生成する。解析部３８は、生成したトレース結果を運用者端末３６へ送信し、トレース結果を運用者端末３６に記憶させ、または、トレース結果を運用者端末３６の表示装置に表示させる。解析部３８は、マイクロサービスと同様に汎用サーバ上に設けられてもよく、マイクロサービスが構築されるサーバとは別の装置上に設けられてもよい。

複数のサービス部（第１サービス部２０および第２サービス部２６）のそれぞれは、自身の処理においてユーザのモバイル識別子を検出した場合、そのモバイル識別子を出力データに設定する。例えば、第１サービス部２０または第２サービス部２６は、自身の処理において加入者情報を管理するＵＤＭ（Unified Data Management）から、要求元のＵＥ１０のＳＵＰＩを取得した場合、そのＳＵＰＩを出力データに設定する。また、第１サービス部２０または第２サービス部２６は、モバイル識別子を示すキーワード（例えば文字列「ＳＵＰＩ」および「ＰＥＩ」）を予め記憶してもよく、処理中のデータから上記キーワードを用いてモバイル識別子の値を抽出してもよい。

図７では、第１サービス部２０は、自身の処理においてモバイル識別子「ＩＤ＿Ａ」を認識し、第２サービス部２６は、自身の処理においてモバイル識別子「ＩＤ＿Ｂ」と「ＩＤ＿Ｃ」を認識した例を示している。

図７の例では、第１サービス部２０は、自身の処理の中で、モバイル識別子「ＩＤ＿Ａ」を検出し、生成したＨＴＴＰリクエスト（出力用ＨＴＴＰリクエスト）がモバイル識別子「ＩＤ＿Ａ」に関するリクエストであることを認識する。第１サービス部２０は、モバイル識別子「ＩＤ＿Ａ」を出力用ＨＴＴＰリクエストのヘッダ部に設定し、出力用ＨＴＴＰリクエストを後続の処理へ渡す。例えば、第１サービス部２０は、自身の処理において加入者情報を管理するＵＤＭ（Unified Data Management）から、要求元のＵＥ１０のＳＵＰＩを取得した場合、そのＳＵＰＩを出力用ＨＴＴＰリクエストのヘッダ部に設定する。

また、図７の例では、第２サービス部２６は、自身の処理の中で、モバイル識別子「ＩＤ＿Ｂ」と「ＩＤ＿Ｃ」を検出し、生成した出力用ＨＴＴＰリクエストがモバイル識別子「ＩＤ＿Ｂ」と「ＩＤ＿Ｃ」に関するリクエストであることを認識する。第２サービス部２６は、入力されたＨＴＴＰリクエストに設定されたモバイル識別子「ＩＤ＿Ａ」と、自身の処理で検出したモバイル識別子「ＩＤ＿Ｂ」と「ＩＤ＿Ｃ」を出力用ＨＴＴＰリクエストのヘッダ部に設定し、出力用ＨＴＴＰリクエストを後続の処理へ渡す。

第１サービス部２０と第２サービス部２６のそれぞれは、ＳＨＡ－１等の公知の暗号学的ハッシュ関数を用いて、ユーザのモバイル識別子のハッシュ値を導出する。第１サービス部２０と第２サービス部２６のそれぞれは、ユーザのモバイル識別子のハッシュ値を出力用ＨＴＴＰリクエストに設定する。

図８は、ＨＴＴＰヘッダへのモバイル識別子の設定例を示す。モバイル識別子であるＳＵＣＩ、ＳＵＰＩ、ＰＥＩのハッシュ値は、それぞれ１６０ビット長であり、１６進数エンコード後、４０文字長となる。図８では、複数のモバイル識別子のハッシュ値（１６進数エンコード文字列）をハイフン「－」で連結し、Ｘ－Ｒｅｑｕｅｓｔ－Ｉｄヘッダに設定する例を示している。

図７を参照しつつ、第１実施例のネットワークサービスシステム１００の動作を説明する。ゲートウェイ装置１２のＧＷプロキシ部１６は、ＵＥ１０のハンドオーバーに関するＨＴＴＰリクエストを外部装置または外部のＮＦから受信する。ＧＷプロキシ部１６は、受信したＨＴＴＰリクエストにトレースＩＤが含まれる場合、そのトレースＩＤを設定したスパンコンテキストを含むＨＴＴＰリクエストを第１サービス部２０へ送信する。受信したＨＴＴＰリクエストにトレースＩＤが含まれない場合、ＧＷプロキシ部１６は、新たなトレースＩＤを発行し、そのトレースＩＤを設定したスパンコンテキストを含むＨＴＴＰリクエストを第１サービス部２０へ送信する。

また、ＧＷプロキシ部１６は、第１サービス部２０へ送信したＨＴＴＰリクエスト、言い換えれば、ＧＷプロキシ部１６から出力したＨＴＴＰリクエストをトレース情報としてトレース収集部３２へ送信する。トレース収集部３２は、ＧＷプロキシ部１６から送信されたＨＴＴＰリクエストをトレース記憶部３４に格納する。

第１プロキシ部２２は、ＧＷプロキシ部１６から送信されたＨＴＴＰリクエストを第１サービス部２０に入力する。第１サービス部２０は、入力されたＨＴＴＰリクエストをもとに所定のマイクロサービス（例えばＡＭＦにおける第１の処理）を実行する。第１サービス部２０は、図５に示したように、入力されたＨＴＴＰリクエストに含まれるスパンコンテキストに基づく新たなスパンコンテキストを設定し、その新たなスパンコンテキストを含む出力用のＨＴＴＰリクエスト（宛先は第２サービス部２６）を生成する。新たなスパンコンテキストは、入力されたＨＴＴＰリクエストのスパンコンテキストからトレースＩＤとサンプリング決定値を引き継ぐ。また、図７の例では、出力用のＨＴＴＰリクエストのヘッダ部は、モバイル識別子「ＩＤ＿Ａ」を含む。第１サービス部２０は、生成したＨＴＴＰリクエストを第１プロキシ部２２へ出力する。

第１プロキシ部２２は、第１サービス部２０から出力されたＨＴＴＰリクエストを第２サービス部２６へ送信する。それとともに、第１プロキシ部２２は、第１サービス部２０から出力されたＨＴＴＰリクエストをトレース収集部３２へ送信する。トレース収集部３２は、第１プロキシ部２２から送信されたＨＴＴＰリクエストをトレース情報としてトレース記憶部３４に格納する。

第２プロキシ部２８は、第１プロキシ部２２から送信されたＨＴＴＰリクエストを第２サービス部２６に入力する。第２サービス部２６は、入力されたＨＴＴＰリクエストをもとに所定のマイクロサービス（例えばＡＭＦにおける第２の処理）を実行する。第２サービス部２６は、図５に示したように、入力されたＨＴＴＰリクエストに含まれるスパンコンテキストに基づく新たなスパンコンテキストを設定し、その新たなスパンコンテキストを含む出力用のＨＴＴＰリクエストを生成する（宛先は不図示の他サービス）。新たなスパンコンテキストは、入力されたＨＴＴＰリクエストのスパンコンテキストからトレースＩＤとサンプリング決定値を引き継ぐ。また、図７の例では、出力用のＨＴＴＰリクエストのヘッダ部は、モバイル識別子「ＩＤ＿Ａ」「ＩＤ＿Ｂ」「ＩＤ＿Ｃ」を含む。第２サービス部２６は、生成したＨＴＴＰリクエストを第２プロキシ部２８へ出力する。

第２プロキシ部２８は、第２サービス部２６から出力されたＨＴＴＰリクエストを不図示の他サービスへ送信する。それとともに、第２プロキシ部２８は、第２サービス部２６から出力されたＨＴＴＰリクエストをトレース収集部３２へ送信する。トレース収集部３２は、第２プロキシ部２８から送信されたＨＴＴＰリクエストをトレース情報としてトレース記憶部３４に格納する。このように、複数のサービスが連鎖的に実行される過程で、各サービスの処理内容または処理結果に関するトレース情報がトレース記憶部３４に蓄積されていく。

解析部３８は、トレース記憶部３４に記憶された複数のトレース情報（実施例では各サービスから出力されたＨＴＴＰリクエストデータ）の中から、運用者端末３６により検索対象として指定されたモバイル識別子を含むトレース情報を抽出する。第１実施例では、解析部３８は、ＳＨＡ－１等の公知の暗号学的ハッシュ関数を用いて、検索対象として指定されたモバイル識別子のハッシュ値を生成し、そのハッシュ値を含むトレース情報を抽出する。続いて解析部３８は、抽出したトレース情報に含まれるトレースＩＤを含む別のトレース情報をさらに抽出する。

図９は、モバイル識別子をキーとしたトレース発見の例を示す。運用者端末３６は、ＳＵＰＩを入力するテキストフィールドと、ＰＥＩを入力するテキストフィールドを含むダッシュボード画面５０を表示部に表示させる。ネットワークサービスシステム１００の運用者は、検索対象とするＳＵＰＩまたはＰＥＩの値（図９ではＳＵＰＩの値）をダッシュボード画面５０に入力する。運用者端末３６は、ダッシュボード画面５０に入力された検索対象の情報を解析部３８へ送信する（ステップ１）。

解析部３８は、運用者端末３６から送信された検索対象のモバイル識別子の値（図９ではＳＵＰＩの値）のハッシュ値を導出する（ステップ２）。解析部３８は、そのハッシュ値をキーとしてトレース記憶部３４を検索し、検索対象のモバイル識別子の値（実施例ではＳＵＰＩのハッシュ値）を含むトレース情報を抽出する（ステップ３）。解析部３８は、ステップ３で抽出したトレース情報に含まれるトレースＩＤを特定し（ステップ４）、Ｂ３ヘッダ伝播で設定されている「Ｘ－Ｂ３－ＴｒａｃｅＩｄ」を辿って、関連する別のトレース情報を抽出する（ステップ５）。

解析部３８は、ステップ３およびステップ５で抽出した複数のトレース情報を含むトレース結果であり、言い換えれば、或る要求に応じて連鎖的に実行された一連のサービスに関する複数のトレース情報を含むトレース結果を運用者端末３６へ送信して表示させる。解析部３８は、図２、図３で示したように、同じトレースＩＤを含む複数のトレース情報を関連付けたトレース結果を生成してもよい。

第１実施例のネットワークサービスシステム１００によると、モバイル識別子（ＳＵＰＩやＰＥＩ）をキーとしてトレース情報をフィルタリングすることができる。これにより、ネットワークの運用者は、意図するトレース結果を容易に参照でき、言い換えれば、通信障害発生時のトラブルシューティングや機能試験確認に有用な情報を容易に取得することができる。また、第１実施例のネットワークサービスシステム１００では、モバイル識別子の値そのものではなく、モバイル識別子のハッシュ値をトレース情報として保存することで、セキュリティリスクを低減することができる、

（３－２）第２実施例
本実施例に関して、第１実施例と相違する点を中心に以下説明し、共通する点の説明を適宜省略する。本実施例の構成要素のうち第１実施例の構成要素と同一または対応する構成要素には同一の符号を付して説明する。

第２実施例に係るネットワークサービスシステム１００の第１サービス部２０は、認証前のユーザに対するサービスを提供し、例えばＵＥ１０に対する初期登録処理を実行する。第１サービス部２０は、認証前のユーザに関する第１のモバイル識別子であり、言い換えれば、認証前のＵＥ１０に関して取得可能な第１のモバイル識別子（例えばＳＵＣＩ）を含む出力データ（例えばＨＴＴＰリクエスト）を出力する。

第２実施例に係るネットワークサービスシステム１００の第２サービス部２６は、認証成功後のユーザに対するサービスを提供し、例えばＵＥ１０に関するハンドオーバー処理を実行する。第２サービス部２６は、上記の第１のモバイル識別子に加えて、認証後に取得可能となるユーザに関する第２のモバイル識別子（例えばＳＵＰＩやＰＥＩ）を含む出力データ（例えばＨＴＴＰリクエスト）を出力する。

上記の課題２で述べた理由から、ＵＥ１０の初期登録手順において、最初にＨＴＴＰリクエストを生成する５ＧコアのＡＭＦは、ＵＥ１０から送信されたＳＵＣＩ以外のモバイル識別子を知り得ない。例えば、ＵＥ１０のＳＵＰＩやＰＥＩを知り得ない。そのため、第１サービス部２０が、ＡＭＦのマイクロサービスとしてＵＥ１０の初期登録手順に関する処理を実行するものである場合、第１サービス部２０は、ユーザ認証に用いるＨＴＴＰリクエスト（例えばＮａｕｓｆ＿ＵＥＡｕｔｈｅｎｔｉｃａｔｉｏｎリクエスト）に、ＳＵＣＩの値（具体的にはＳＵＣＩのハッシュ値）のみを設定する。

ＡＭＦは、ユーザ認証成功後、ＵＤＭがＳＵＣＩを変換して得たＳＵＰＩをＡＵＳＦ（AUthentication Server Function）経由で取得する。また、ＡＭＦは、ユーザ認証成功後、ＵＥ１０にＰＥＩの提供を要求し、ＵＥ１０から送信されたＰＥＩを取得する。以降、ＡＭＦは、ＨＴＴＰリクエストのヘッダ部に、ＳＵＰＩのハッシュ値とＰＥＩのハッシュ値を設定可能となる。そのため、第２サービス部２６が、ＡＭＦのマイクロサービスとしてＵＥ１０のハンドオーバー処理を実行するものである場合、第２サービス部２６は、ハンドオーバー対象のＵＥ１０のＳＵＣＩ、ＳＵＰＩおよびＰＥＩを外部から取得し、ハンドオーバー関連処理に用いるＨＴＴＰリクエストに、ＳＵＣＩ、ＳＵＰＩ、ＰＥＩそれぞれのハッシュ値を設定する。

第２実施例に係るネットワークサービスシステム１００の解析部３８は、検索対象として指定された第２のモバイル識別子を含む出力データを抽出し、その出力データに含まれる第１のモバイル識別子を含む別の出力データをさらに抽出する。

図１０は、モバイル識別子をキーとしたトレース発見の例を示す。トレースＩＤ「４２ｄ１９・・・」が設定されたトレース情報群５４は、認証完了前のＵＥ１０に対する初期登録処理に関係する一連のサービスのトレース情報を含む。また、トレースＩＤ「ａ２３２９・・・」が設定されたトレース情報群５２は、認証完了後のＵＥ１０に対する処理（例えばハンドオーバー処理）に関係する一連のサービスのトレース情報を含む。

ステップ１とステップ２は、図９と同じであるため図１０では省略している。解析部３８は、運用者端末３６から送信された検索対象のＳＵＰＩの値からそのハッシュ値を導出し、ＳＵＰＩのハッシュ値をキーとしてトレース記憶部３４を検索する。解析部３８は、キーとしてのＳＵＰＩのハッシュ値を含むトレース情報を抽出する（ステップ３）。解析部３８は、ステップ３で抽出したトレース情報に含まれるトレースＩＤ「ａ２３２９・・・」を特定し（ステップ４）、そのトレースＩＤにより関連付けられた別のトレース情報を抽出する（ステップ５）。図１０のステップ５では、トレース情報群５２が抽出される。

解析部３８は、ステップ３で抽出したトレース情報に含まれるＳＵＣＩのハッシュ値を特定し、そのＳＵＣＩのハッシュ値を含む別のトレース情報を抽出する（ステップ６）。解析部３８は、ステップ６で抽出したトレース情報に含まれるトレースＩＤ「４２ｄ１９・・・」を特定し（ステップ７）、そのトレースＩＤにより関連付けられた別のトレース情報を抽出する（ステップ８）。図１０のステップ８では、トレース情報群５４が抽出される。解析部３８は、トレース情報群５２およびトレース情報群５４を含むトレース結果を運用者端末３６へ送信して表示させる。

図１１も、モバイル識別子をキーとしたトレース発見の例を示す。トレースＩＤ「４２ｄ１９・・・」が設定されたトレース情報群６０は、ＵＥ１０に対する初期登録処理の一部（認証の前半処理）を実行する一連のサービスに関する複数のトレース情報を含む。トレースＩＤ「９８７９８・・・」が設定されたトレース情報群５８は、ＵＥ１０に対する初期登録処理の一部（認証の後半処理）を実行する一連のサービスに関する複数のトレース情報を含む。

トレースＩＤ「９ｂａ６１・・・」が設定されたトレース情報群５６は、認証完了後のＵＥ１０に対する処理（例えばハンドオーバー処理）を実行する一連のサービスに関する複数のトレース情報を含む。トレース情報群６０は、モバイル識別子としてＳＵＣＩ（実施例ではＳＵＣＩのハッシュ値）のみを含む。トレース情報群５８は、モバイル識別子としてＳＵＣＩとＳＵＰＩ（実施例ではＳＵＣＩとＳＵＰＩそれぞれのハッシュ値）を含む。トレース情報群５６は、モバイル識別子としてＳＵＰＩとＰＥＩ（実施例ではＳＵＰＩとＰＥＩそれぞれのハッシュ値）を含む。

ステップ１とステップ２は、図９と同じであるため図１０では省略している。図１１の例では、運用者により指定された検索対象のモバイル識別子はＰＥＩである。解析部３８は、運用者端末３６から送信された検索対象のＰＥＩの値からそのハッシュ値を導出し、ＰＥＩのハッシュ値をキーとしてトレース記憶部３４を検索する。解析部３８は、キーとしてのＰＥＩのハッシュ値を含むトレース情報を抽出する（ステップ３）。解析部３８は、ステップ３で抽出したトレース情報に含まれるトレースＩＤを特定し（ステップ４）、そのトレースＩＤにより関連付けられた別のトレース情報を抽出する（ステップ５）。図１１のステップ５では、トレース情報群５６が抽出される。

解析部３８は、ステップ３で抽出したトレース情報に含まれるＳＵＰＩのハッシュ値を特定し、そのＳＵＰＩのハッシュ値を含む別のトレース情報を抽出する（ステップ６）。解析部３８は、ステップ６で抽出したトレース情報に含まれるトレースＩＤを特定し（ステップ７）、そのトレースＩＤにより関連付けられた別のトレース情報を抽出する（ステップ８）。図１１のステップ８では、トレース情報群５８が抽出される。

解析部３８は、ステップ６で抽出したトレース情報に含まれるＳＵＣＩのハッシュ値を特定し、そのＳＵＣＩのハッシュ値を含む別のトレース情報を抽出する（ステップ９）。解析部３８は、ステップ９で抽出したトレース情報に含まれるトレースＩＤを特定し（ステップ１０）、そのトレースＩＤにより関連付けられた別のトレース情報を抽出する（ステップ１１）。図１１のステップ１１では、トレース情報群６０が抽出される。解析部３８は、トレース情報群５６、トレース情報群５８およびトレース情報群６０を含むトレース結果を運用者端末３６へ送信して表示させる。

第２実施例のネットワークサービスシステム１００によると、トレース記憶部３４に蓄積されるトレース情報の中に、ネットワーク運用者が通常知り得ないモバイル識別子（例えばＳＵＣＩ）だけしか含まれないトレース情報（ここでは「特殊トレース情報」とも呼ぶ。）が存在する場合でも、ＳＵＰＩまたはＰＥＩを用いた抽出、フィルタリングにより、特殊トレース情報を含むトレース結果を得ることができる。これにより、例えば、運用者は、ＵＥ１０の初期登録手順に関するエンドツーエンドでのトレース結果を参照することができる。

（３－３）第３実施例
本実施例に関して、第１実施例、第２実施例と相違する点を中心に以下説明し、共通する点の説明を適宜省略する。本実施例の構成要素のうち第１実施例、第２実施例の構成要素と同一または対応する構成要素には同一の符号を付して説明する。

上記の課題３を解決するため、第３実施例に係るネットワークサービスシステム１００では、サービスの出力データをトレース情報として保存することの要否を示すパラメータであり、具体的には、ＨＴＴＰリクエストのヘッダ部にＸ－Ｂ３－Ｓａｍｐｌｅｄヘッダとして設定するサンプリング決定値（Sampling decision）を、ＨＴＴＰリクエストのタイプに基づいて動的に変更する。

ＩｓｔｉｏとＪａｅｇｅｒを用いた実装の場合、最初のスパンコンテキストはＥｎｖｏｙプロキシで設定されるが、その際に、事前に設定されたサンプリングレート（例えば１％）にしたがって、或るＨＴＴＰリクエストをトレース対象にするか否かを決定する。トレース対象とする場合、当該ＨＴＴＰリクエストのスパンコンテキストには「サンプリング決定値＝Ｔｒｕｅ」が設定され、トレース対象外の場合、当該ＨＴＴＰリクエストのスパンコンテキストには「サンプリング決定値＝Ｆａｌｓｅ」が設定される。

システム負荷を考慮すると、サンプリングレートを低く抑えることが好ましい。一方、５Ｇコアで特に重要な３ＧＰＰ標準インタフェースであるＳＢＩを介したトラフィックは、マイクロサービス全体のトラフィックに比して小さい。実装依存であるが、サービスを細かく分割しているほど、言い換えれば、マイクロサービスの粒度が小さいほど、ＳＢＩを介したトラフィックの比率は小さくなる。

そこで、第３実施例に係るネットワークサービスシステム１００では、ＳＢＩ以外のトラフィックについては任意のｎ％（例えば１％）でトレース情報を記録する。一方、ＳＢＩのトラフィックについては任意のｍ％（ｍ＞ｎ、ｍは例えば１００％）でトレース情報を記録する。すなわち、第３実施例に係るネットワークサービスシステム１００が備える複数のサービス部は、ＳＢＩを介して他のサービスへ送信される出力データを予め定められた第１の割合で記憶部に格納する。一方、複数のサービス部は、ＳＢＩとは異なるインタフェースを介して他のサービスへ送信される出力データを予め定められた第２の割合で記憶部に格納する。第１の割合は、第２の割合より高く定められる。

図１２は、第３実施例に係るネットワークサービスシステム１００の詳細な構成を示すブロック図である。第３実施例に係るネットワークサービスシステム１００は、第１実施例の機能ブロックに加えて、サンプリング率設定部４４をさらに備える。また、Ｐｏｄ１８は、第１サービス部２０と第１プロキシ部２２に加えて、第１サンプリング決定部４０をさらに含む。また、Ｐｏｄ２４は、第２サービス部２６と第２プロキシ部２８に加えて、第２サンプリング決定部４２をさらに含む。

第１サンプリング決定部４０は、予め定められたサンプリング率にしたがって、第１サービス部２０からの出力データ（例えばＨＴＴＰリクエスト）をトレース情報として保存することの要否を決定する。第２サンプリング決定部４２は、予め定められたサンプリング率にしたがって、第２サービス部２６からの出力データ（例えばＨＴＴＰリクエスト）をトレース情報として保存することの要否を決定する。以下では、第１サンプリング決定部４０の処理を詳細に説明するが、第２サンプリング決定部４２の処理も同様である。

サンプリング率設定部４４は、運用者端末３６から送信された運用者の指示に応じて、ＧＷプロキシ部１６、第１サンプリング決定部４０、第２サンプリング決定部４２のそれぞれに対して運用者により定められたサンプリング率を設定し、または変更する。第３実施例のサンプリング率設定部４４は、第１サンプリング決定部４０と第２サンプリング決定部４２に対して、ＳＢＩを介して送信されるデータに対するサンプリング率（以下「ＳＢＩサンプリング率」とも呼ぶ。）を設定する。また、サンプリング率設定部４４は、ＧＷプロキシ部１６に対して、ＳＢＩとは異なるインタフェースを介して送信されるデータに対するサンプリング率（以下「非ＳＢＩサンプリング率」とも呼ぶ。）を設定する。既述したように、運用者は、ＳＢＩサンプリング率として、非ＳＢＩサンプリング率より高い値を設定する。

図１２を参照しつつ、インタフェースに応じたサンプリング決定値の動的変更例を説明する。ゲートウェイ装置１２のＧＷプロキシ部１６には、非ＳＢＩサンプリング率１％が事前設定され、言い換えれば、「サンプリング決定値（ＳＤ）＝Ｔｒｕｅ」を１％の割合でＨＴＴＰヘッダに設置するよう事前設定される。図１２の例では、ＧＷプロキシ部１６は、「ＳＤ＝Ｆａｌｓｅ」を設定している。なお、ＳＤは、上述のＸ－Ｂ３－Ｓａｍｐｌｅｄヘッダに対応する。

第１サービス部２０と第１プロキシ部２２の間に設置される第１サンプリング決定部４０は、リクエストが第１サービス部２０から第１プロキシ部２２に向けて送信されており（すなわち第１サービス部２０から出力されたリクエストであり）、かつ、リクエストがオリジナルＳＢＩサンプリング決定値（以下「ＯＳＳＤ」とも呼ぶ。）の情報を含まない場合、ＳＢＩ向けのリクエストに対するサンプリング要否を事前設定されたＳＢＩサンプリング率にしたがって決定する。以下では、第１サービス部２０から出力され第１プロキシ部２２に入力されたリクエストを「オリジナルリクエスト」と呼び、第１プロキシ部２２から第１プロキシ部２２へ出力されるリクエストを「出力リクエスト」と呼ぶ。

第１サンプリング決定部４０は、ＳＢＩ向けのリクエストに対するサンプリング要否示す情報を出力リクエストのヘッダ部のＯＳＳＤに設定する。サンプリングが必要と決定した場合、「ＯＳＳＤ＝Ｔｒｕｅ」を設定し、サンプリングが不要と決定した場合、「ＯＳＳＤ＝Ｆａｌｓｅ」を設定する。図１２の例では、ＳＢＩサンプリング率を１００％とし、「ＯＳＳＤ＝Ｔｒｕｅ」を設定している。また、第１サンプリング決定部４０は、オリジナルリクエストのヘッダ部に設定されていたＳＤの値を、出力リクエストのヘッダ部のオリジナルサンプリング決定値（以下「ＯＳＤ」とも呼ぶ。）にコピーする。図１２の例では、ＯＳＤ＝Ｆａｌｓｅが設定されている。

次に、第１サンプリング決定部４０は、第１サービス部２０から出力されたオリジナルリクエストが、ＳＢＩ向けのリクエストであるか、またはＳＢＩとは異なるインタフェース向けのリクエスト（例えばｇＲＰＣ（Remote Procedure Call））であるかを判定する。以下では、前者をＳＢＩリクエストと呼び、後者を非ＳＢＩリクエストとも呼ぶ。

第３実施例におけるインタフェース種別の判定方法を説明する。クバネテスでは、Ｐｏｄは複数のワーカーノードに分散配置されるが、ワーカーノード上のＰｏｄ配置を意識せずに、単一のエンドポイントを提供する「サービス」というリソースがある。クバネテスでは、Ｐｏｄを含む多くのリソースがラベル（例えばＫｅｙ－Ｖａｌｕｅペアの文字列）を付けることによって複数のリソースをグループ化することができ、また、ラベルにより特定のＰｏｄを抽出することができる。また、「サービス」リソースでは、特定のラベルを持つＰｏｄに対してサービス名を付けることができる。各Ｐｏｄは、互いのＩＰアドレスやポート番号を知ることなしに、このサービス名を用いて通信することができる。

第１サンプリング決定部４０は、第１サービス部２０から出力されたオリジナルリクエスト、言い換えれば、自身が出力するＨＴＴＰリクエストが、ＳＢＩリクエストであるか、または非ＳＢＩリクエストであるかを判定するために、この「サービス」リソースにアクセスする。「サービス」リソースでは、サービス名に対するラベルが保持されており、或るＰｏｄが提供するエンドポイントがＳＢＩであればそのことを示すラベルを持つようにＰｏｄリソースにおいて予め記述しておく。例えば、「Ｉｎｔｅｒｆａｃｅ＝ｓｂｉ」のようなラベルを付与しておく。

第１サンプリング決定部４０は、第１サービス部２０から出力されたオリジナルリクエストに記述された接続先（言い換えれば呼び出し先）のサービス名をもとに、接続先のサービスに付与されたラベルを「サービス」リソースから取得する。第１サンプリング決定部４０は、取得したラベルの記載をもとに、接続先のサービスがＳＢＩのエンドポイントか否か、言い換えれば、第１サービス部２０から出力されたオリジナルリクエストが、ＳＢＩリクエストと非ＳＢＩリクエストのいずれであるかを判定する。

オリジナルリクエストが非ＳＢＩリクエストである場合、第１サンプリング決定部４０は、オリジナルリクエストのヘッダ部に設定されていたＳＤの値を、出力リクエストのヘッダ部のＳＤにコピーする。一方、オリジナルリクエストがＳＢＩリクエストである場合、第１サンプリング決定部４０は、ＯＳＳＤの値を、出力リクエストのヘッダ部のＳＤにコピー（上書き）する。

図１３（ａ）、図１３（ｂ）、図１３（ｃ）、図１３（ｄ）は、第１サンプリング決定部４０の動作例を示す。各図の第１サンプリング決定部４０に設定されたＳＢＩサンプリング率は１００％とする。

図１３（ａ）は、第１サービス部２０から出力されたオリジナルリクエストが非ＳＢＩリクエストであり、かつ、そのヘッダにＯＳＳＤ（およびＯＳＤ）が含まれない場合の動作を示している。この場合、第１サンプリング決定部４０は、オリジナルリクエストのＳＤ値（図ではＦａｌｓｅ）を、出力リクエストのＯＳＤ値とＳＤ値に設定する。また、第１サンプリング決定部４０は、出力リクエストのＯＳＳＤ値を、予め定められたＳＢＩサンプリング率にしたがって設定し、ここではＴｒｕｅに設定する。

図１３（ｂ）は、第１サービス部２０から出力されたオリジナルリクエストがＳＢＩリクエストであり、かつ、そのヘッダにＯＳＳＤ（およびＯＳＤ）が含まれない場合の動作を示している。この場合、第１サンプリング決定部４０は、オリジナルリクエストのＳＤ値（図ではＦａｌｓｅ）を、出力リクエストのＯＳＤ値に設定する。また、第１サンプリング決定部４０は、出力リクエストのＯＳＳＤ値を、予め定められたＳＢＩサンプリング率にしたがって設定し、ここではＴｒｕｅに設定する。また、第１サンプリング決定部４０は、出力リクエストのＳＤ値にＯＳＳＤ値を設定し、ここではＴｒｕｅを設定する。

図１３（ｃ）は、第１サービス部２０から出力されたオリジナルリクエストが非ＳＢＩリクエストであり、かつ、そのヘッダにＯＳＳＤ（およびＯＳＤ）が含まれる場合の動作を示している。この場合、第１サンプリング決定部４０は、オリジナルリクエストのＯＳＤ値、ＯＳＳＤ値、ＳＤ値を、出力リクエストのＯＳＤ値、ＯＳＳＤ値、ＳＤ値に設定（コピー）する。

図１３（ｄ）は、第１サービス部２０から出力されたオリジナルリクエストがＳＢＩリクエストであり、かつ、そのヘッダにＯＳＳＤ（およびＯＳＤ）が含まれる場合の動作を示している。この場合、第１サンプリング決定部４０は、オリジナルリクエストのＯＳＤ値を、出力リクエストのＯＳＤ値に設定（コピー）する。また、第１サンプリング決定部４０は、オリジナルリクエストのＯＳＳＤ値を、出力リクエストのＯＳＳＤ値およびＳＤ値に設定（コピー）する。

図１２の第１サンプリング決定部４０は、図１３（ａ）の第１サンプリング決定部４０に対応する。第１サンプリング決定部４０から出力されたリクエストのＳＤ値はＦａｌｓｅであるため、第１プロキシ部２２は、第１サンプリング決定部４０から出力されたリクエストを第２プロキシ部２８に送信する一方、そのリクエストをトレース収集部３２に送信する（トレース記憶部３４に保存する）ことを抑制する。

図１２の第２サンプリング決定部４２は、図１３（ｄ）の第１サンプリング決定部４０に対応する。第２サンプリング決定部４２から出力されたリクエストのＳＤ値はＴｒｕｅであるため、第２プロキシ部２８は、第２サンプリング決定部４２から出力されたリクエストを不図示の他サービスへ送信するとともに、そのリクエストをトレース収集部３２に渡してトレース記憶部３４に保存させる。

第３実施例のネットワークサービスシステム１００によると、トレース情報のサンプリング率を、３ＧＰＰの標準インタフェースであるＳＢＩと非ＳＢＩとで独立して設定することができる。ＳＢＩは、典型的には、異なるＮＦ間（例えばＡＭＦとＵＤＭ間）でのデータ送受信に用いられる。一方、非ＳＢＩ（例えばｇＲＰＣ）は、典型的には、１つのＮＦ内部のマイクロサービス間でのデータ送受信に用いられる。したがって、第３実施例のネットワークサービスシステム１００によると、トレース取得による処理負荷を低減しつつ、ネットワーク運用者にとって特に重要となるＳＢＩを介して送受信されたデータを確実にトレースすることが可能になる。

第３実施例の変形例を説明する。第３実施例では、第１サンプリング決定部４０（第２サンプリング決定部４２）は、「サービス」リソースにアクセスして、入力されたオリジナルリクエストがＳＢＩリクエストか否かを判定したが、判定方法はこれに限られない。例えば、入力されたオリジナルリクエストに、接続先のサービスがＳＢＩのエンドポイントか否かを示す識別情報が含まれる場合、または、当該リクエストがＳＢＩリクエストか否かを示す識別情報が含まれる場合、第１サンプリング決定部４０（第２サンプリング決定部４２）は、この識別情報を参照することによってオリジナルメッセージがＳＢＩリクエストか否かを判定してもよい。

第３実施例の別の変形例を説明する。サンプリング率設定部４４は、ＧＷプロキシ部１６に対して非ＳＢＩサンプリング率を設定し、第１サンプリング決定部４０と第２サンプリング決定部４２に対して、ＳＢＩサンプリング率と非ＳＢＩサンプリング率の両方を設定してもよい。この変形例に係る第１サンプリング決定部４０（第２サンプリング決定部４２）は、第１サービス部２０（第２サービス部２６）から出力されたオリジナルリクエストが非ＳＢＩリクエストである場合、出力リクエストのＳＤ値を非ＳＢＩサンプリング率にしたがって設定してもよい。例えば、非ＳＢＩサンプリング率が１％の場合、出力リクエストのＳＤ値を１％の確率でＴｒｕｅにし、９９％の確率でＦａｌｓｅにしてもよい。これにより、非ＳＢＩリクエストは１％の確率でトレース情報として保存される。

また、この変形例に係る第１サンプリング決定部４０（第２サンプリング決定部４２）は、第１サービス部２０（第２サービス部２６）から出力されたオリジナルリクエストがＳＢＩリクエストである場合、出力リクエストのＳＤ値をＳＢＩサンプリング率にしたがって設定してもよい。例えば、ＳＢＩサンプリング率が１００％の場合、出力リクエストのＳＤ値を必ずＴｒｕｅにしてもよい。これにより、ＳＢＩリクエストは必ずトレース情報として保存される。

以上、本発明を第１～第３実施例をもとに説明した。これらの実施例は例示であり、各構成要素あるいは各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

上述した実施例および変形例の任意の組み合わせもまた本開示の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施例および変形例それぞれの効果をあわせもつ。また、請求項に記載の各構成要件が果たすべき機能は、実施例および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。例えば、請求項に記載のサービス部の機能は、実施例に記載の第１サービス部２０、第１プロキシ部２２、第１サンプリング決定部４０（または第２サービス部２６、第２プロキシ部２８、第２サンプリング決定部４２）の任意の組み合わせにより実現されてもよい。

２０ 第１サービス部、 ２２ 第１プロキシ部、 ２６ 第２サービス部、 ２８ 第２プロキシ部、 ３２ トレース収集部、 ３４ トレース記憶部、 ３８ 解析部、 ４０ 第１サンプリング決定部、 ４２ 第２サンプリング決定部、 ４４ サンプリング率設定部、 １００ ネットワークサービスシステム。

Claims (7)

1. 所定の要求に応じて複数のサービス呼び出しが連鎖的に実行されるシステムであって、
   前記複数のサービスを提供する複数のサービス部と、
   前記複数のサービス部から出力された複数の出力データであって、連鎖的に実行された複数のサービス呼び出しを追跡するための追跡識別子を含む複数の出力データを記憶する記憶部と、
   連鎖的に実行された複数のサービス呼び出しに関する情報を生成する解析部と、
   を備え、
   前記複数のサービス部のそれぞれは、自身の処理においてユーザのモバイル識別子を検出した場合、そのモバイル識別子を前記出力データに設定し、
   前記解析部は、前記記憶部に記憶された複数の出力データの中から、検索対象として指定されたモバイル識別子を含む出力データを抽出し、その出力データに含まれる追跡識別子を含む別の出力データをさらに抽出することを特徴とするネットワークサービスシステム。
2. 前記複数のサービス部のそれぞれは、前記ユーザのモバイル識別子のハッシュ値を出力データに設定し、
   前記解析部は、前記検索対象として指定されたモバイル識別子のハッシュ値を生成し、そのハッシュ値を含む出力データを抽出することを特徴とする請求項１に記載のネットワークサービスシステム。
3. 前記複数のサービス部は、認証前のユーザに対するサービスを提供する第１サービス部と、認証後のユーザに対するサービスを提供する第２サービス部とを含み、
   前記第１サービス部は、認証前のユーザに関する第１のモバイル識別子を含む出力データを出力し、
   前記第２サービス部は、前記第１のモバイル識別子に加えて、認証後に取得可能となるユーザに関する第２のモバイル識別子を含む出力データを出力し、
   前記解析部は、検索対象として指定された第２のモバイル識別子を含む出力データを抽出し、その出力データに含まれる第１のモバイル識別子を含む別の出力データをさらに抽出することを特徴とする請求項１または２に記載のネットワークサービスシステム。
4. 前記複数のサービス部は、ＳＢＩ（Service Based Interface）を介して送信される出力データを予め定められた第１の割合で前記記憶部に格納する一方、前記ＳＢＩとは異なるインタフェースを介して送信される出力データを予め定められた第２の割合で前記記憶部に格納し、
   前記第１の割合は、前記第２の割合より高いことを特徴とする請求項１から３のいずれかに記載のネットワークサービスシステム。
5. 運用者の操作に応じて、前記複数のサービス部に対して前記第１の割合を設定する設定部をさらに備えることを特徴とする請求項４に記載のネットワークサービスシステム。
6. 所定の要求に応じて複数のサービス呼び出しが連鎖的に実行されるシステムを構成するコンピュータが、
   前記複数のサービスを実行するステップと、
   前記複数のサービスから出力された複数の出力データであって、連鎖的に実行された複数のサービス呼び出しを追跡するための追跡識別子を含む複数の出力データを所定の記憶部に格納するステップと、
   連鎖的に実行された複数のサービス呼び出しに関する情報を生成する解析ステップと、
   を実行し、
   前記実行するステップは、前記複数のサービスそれぞれの処理においてユーザのモバイル識別子を検出した場合、そのモバイル識別子を前記出力データに設定し、
   前記解析ステップは、前記記憶部に記憶された複数の出力データの中から、検索対象として指定されたモバイル識別子を含む出力データを抽出し、その出力データに含まれる追跡識別子を含む別の出力データをさらに抽出することを特徴とするネットワーク管理方法。
7. 所定の要求に応じて複数のサービス呼び出しが連鎖的に実行されるシステムを構成するコンピュータに、
   前記複数のサービスを実行する機能と、
   前記複数のサービスから出力された複数の出力データであって、連鎖的に実行された複数のサービス呼び出しを追跡するための追跡識別子を含む複数の出力データを所定の記憶部に格納する機能と、
   連鎖的に実行された複数のサービス呼び出しに関する情報を生成する解析機能と、
   を実現させ、
   前記実行する機能は、前記複数のサービスそれぞれの処理においてユーザのモバイル識別子を検出した場合、そのモバイル識別子を前記出力データに設定し、
   前記解析機能は、前記記憶部に記憶された複数の出力データの中から、検索対象として指定されたモバイル識別子を含む出力データを抽出し、その出力データに含まれる追跡識別子を含む別の出力データをさらに抽出することを特徴とするコンピュータプログラム。

Images