JP7371784B2 - 通信中継装置、通信中継システム、通信中継方法、および、プログラム - Google Patents

Description

本発明は、通信中継装置、通信中継システム、通信中継方法、および、プログラムに関する。

近年、アプリケーションの新たなアーキテクチャの一つであるマイクロサービス型のアプリケーションや、通信システムの仮想化ＮＦＶ（Network Function Virtualization）に関するアプリケーションが普及している。

マイクロサービス型のアプリケーションは、非特許文献１に記載のkubernetes（登録商標）と呼ばれるソフトウェアが代表的である。以下、単にkubernetesと記載し、「登録商標」の記載を省略する。

マイクロサービス基盤は、マイクロサービスを収容するサーバ群と、リクエストを各サーバに振り分ける振り分け装置（ロードバランサ）により構成される。マイクロサービス基盤は、コンテナ等の仮想ノードをサーバクラスタ上で稼働させてアプリケーションを実現する。これらコンテナ等の仮想ノードは、アプリケーションの対向ノードからロードバランサを経由してパケットを受信する。

"Kubernetes",インターネット<URL:https://kubernetes.io/>

Radiusクライアントは対向ノードである。マイクロサービスのRadiusサーバは、サーバ上にデプロイされている。Radiusサーバには、ロードバランサを介して対向ノードからのリスエストが振り分けられる。

ＮＦＶのアプリケーションには、Radiusプロトコルのように、ＩＰアドレスをパラメータとして持ち、このＩＰアドレスの情報を認証プロセスで利用するプロトコルが存在する。しかし、このような構成のシステムにおいて、マイクロサービスから対向ノードへの通信は、ロードバランサを経由せず、サーバクラスタから直接対向ノードに送られてしまう。

RadiusサーバからRadiusクライアントの通信は、ロードバランサを通過しない。その結果、対向ノードであるRadiusクライアントは、Radiusサーバのアドレスを送信元アドレスとするリクエストを受信する。しかし、対向ノードが期待するＩＰアドレスは、ロードバランサのＩＰアドレスである。よって、ＩＰ認証が必要なRadius認証のようなアプリケーションの場合、この通信経路では要件を満たせず、認証に失敗する。

Radius認証においては、ＣｏＡ（Change of Authorization）という認可変更機能が提供されており、認証、認可、およびアカウンティングセッションの属性をセッション認証後に変更するためのメカニズムを提供する。Radius認可変更機能は、RadiusサーバからRadiusクライアント（端末）に対するリクエスト送信であり、Radiusサーバから端末のセッションを切断するDisconnect Request等がある。

また、Radius認証に限らず、何らかの通信制御要求において、他の通信装置にパケットを送信する必要のあるケースが存在する。例えば、セッション処理にはＭＭＥ（Mobility Management Entity）、ＳＧＷ（Serving Gateway）、ＰＧＷ（Packet data network Gateway）、ＰＣＲＦ（Policy and Charging Rules Function）といった機能が必要であり、それらが互いに通信を行うことで一連のセッション処理を実施する。これらの機能のいずれかがマイクロサービス基盤上にいる場合、マイクロサービス基盤から外のノードに対する通信が発生することとなる。

そこで、本発明は、ＩＰ認証が必要なＮＦＶアプリケーションを搭載するマイクロサービス基盤において、マイクロサービスから対向ノードに対して送信されるリクエストのアプリケーションの要件を満たすことを課題とする。

前記した課題を解決するため、本発明の通信中継装置は、マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを、前記マイクロサービスを収容するサーバ群のうち何れかに振り分ける順方向中継部と、前記マイクロサービスから対向ノードのアドレス帯へのリクエストをＮＡＰＴし、前記リクエストに対する対向ノードからの応答を前記リクエストが通った経路の逆順で前記マイクロサービスへ返却する逆方向中継部と、
を備えることを特徴とする。
その他の手段については、発明を実施するための形態のなかで説明する。

本発明によれば、ＩＰ認証が必要なＮＦＶアプリケーションを搭載するマイクロサービス基盤において、マイクロサービスから対向ノードに対して送信されるリクエストのアプリケーションの要件を満たすことが可能となる。

マイクロサービス基盤の構成図である。 マイクロサービス基盤の動作のうち、サーバクラスタから対向ノードにリクエストを送信する動作を示す図である。 マイクロサービス基盤の動作のうち、サーバクラスタからロードバランサを介して対向ノードにリクエストを送信する動作を示す図である。 マイクロサービス基盤とロードバランサを示すシステム図である。 対向ノードからコンテナへのリクエストの流れを示す図である。 コンテナから対向ノードへのリクエストの流れを示す図である。 現用系のロードバランサがダウンした場合の動作を示す図である。 Nginx（登録商標）の状態遷移図である。 Nginx（登録商標）の状態遷移テーブルを示す図である。 障害パターンに応じたルーティングテーブルのモード間の動作を示すモード遷移図である。 障害パターンに応じたルーティングテーブルのルートの向きの変更を示すモード遷移図である。 仮想ＩＰアドレスを用いたロードバランサを示す図である。

以降、本発明を実施するための形態を、各図を参照して詳細に説明する。
図１は、マイクロサービス基盤２の構成図である。
マイクロサービス基盤２は、対向ノードからのパケットを振り分けるロードバランサ３と、振り分けたパケットを処理して応答を返すサーバクラスタ４とを含んで構成されている。図１に示すマイクロサービス基盤２は、Radiusクライアント１に対してRadius認証のサービスを提供する。

ロードバランサ３のＩＰアドレスは、10.x.y.6である。Radiusクライアント１のＩＰアドレスは、10.x.y.5である。このサーバクラスタ４は、ＩＰアドレス10.x.x.100のサーバ５ａと、ＩＰアドレス10.x.x.102のサーバ５ｂを含んでいる。

サーバ５ａには、Radiusサーバ５１ａがコンテナとしてデプロイされている。このRadiusサーバ５１ａには、ＩＰアドレス10.x.x.101が付与されている。
サーバ５ｂには、Radiusサーバ５１ｂ，５１ｃがコンテナとしてデプロイされている。Radiusサーバ５１ｂには、ＩＰアドレス10.x.x.103が付与されている。Radiusサーバ５１ｃには、ＩＰアドレス10.x.x.104が付与されている。

図２は、対向ノードからマイクロサービス基盤２に送信するリクエストパケットと、サーバクラスタ４から対向ノードに送信するリクエストパケットを示す図である。

《対向ノードからマイクロサービス基盤２へのリクエスト》
ロードバランサ３は、順方向中継部３１を有し、対向ノードからマイクロサービス基盤２へのリクエストパケットと、このリクエストに対する応答パケットを中継する。

Radiusクライアント１は、対向ノードであり、例えばユーザの端末である。Radiusクライアント１は、ロードバランサ３のＩＰアドレス10.x.y.6をリクエストパケットの宛先アドレスとすることで、Radiusサーバ５１ａ～５１ｃに対するリクエストパケットを送信する。このリクエストパケットは、ロードバランサ３により、サーバ５ａ，５ｂの何れかに振り分けられる。具体的には、順方向中継部３１は、ＮＡＰＴ（Network Address Port Translation）部３２により、リクエストパケット宛先をサーバ５ａ，５ｂの何れかに書き換える。図２においてリクエストパケットは、サーバ５ａに振り分けられている。

サーバ５ａは、このリクエストパケットを受信すると、ＮＡＰＴ部５２により、その宛先をRadiusサーバの何れかに書き換える。ここでは単一のRadiusサーバ５１ａしか配置されていないので、リクエストパケットの宛先は、Radiusサーバ５１ａのＩＰアドレス10.x.x.101に書き換えられる。

Radiusサーバ５１ａは、このリクエストパケットを受信して対応する処理を行うと、処理結果を示す応答パケットを生成し、この応答パケットを対向ノードに送信する。サーバ５ａは、この応答パケットを受信すると、ＮＡＰＴ部５３により、宛先をロードバランサ３に書き換えて転送する。
ロードバランサ３の順方向中継部３１は、ＮＡＰＴ部３３により、サーバ５ａが転送した応答パケットの宛先をRadiusクライアント１に書き換えて転送する。

《マイクロサービス基盤２から対向ノードへのリクエスト》
Radiusサーバ５１ａは、対向ノードのRadiusクライアント１へのリクエストパケットをサーバ５ｂに送信する。サーバ５ｂは、このリクエストパケットを受信すると、ＮＡＰＴ部５４により、宛先をRadiusクライアント１のＩＰアドレスに書き換えて転送する。このリクエストパケットはロードバランサ３を経由せず、このリクエストパケットの送信元アドレスは、サーバ５ｂのＩＰアドレス10.x.x.102である。

前述した対向ノードからマイクロサービス基盤２へのリクエストパケットの宛先は、ロードバランサ３の10.x.y.6であり、このリクエストパケットの送信元の10.x.x.102とは相違する。ＩＰ認証が必要なRadius認証のようなアプリケーションの場合、この通信経路では要件を満たせず、認証に失敗する。

《第１の実施形態》
第１の実施形態では、ＩＰ認証が必要なＮＦＶアプリケーションを搭載するマイクロサービス基盤において、マイクロサービスから対向ノードに対して送信されるリクエストパケットを、ロードバランサが中継することによって、アプリケーションの要件を満たすことができる。

図３は、コンテナからロードバランサ３を介して対向ノードにリクエストパケットを送信する動作を示す図である。
図３のマイクロサービス基盤２は、図１のマイクロサービス基盤２と同様に構成されており、更にロードバランサ３は、順方向中継部３１と逆方向中継部３４とを含んで構成されており、振分装置または通信中継装置として機能する。

順方向中継部３１は、ＮＡＰＴ部３２，３３を含んで構成され、マイクロサービス基盤２の対向ノードからこのマイクロサービス基盤２へのリクエストを、このマイクロサービス基盤２を収容するサーバ５ａ，５ｂのうち何れかに振り分ける。順方向中継部３１は、ＮＡＰＴ部３２により、リクエストの送信元アドレスを自身のアドレスに書き換えてＮＡＰＴする。

逆方向中継部３４は、ＮＡＰＴ部３５，３６を含んで構成され、マイクロサービス基盤２から対向ノードのアドレス帯へのリクエストをＮＡＰＴし、このリクエストに対する対向ノードからの応答を、このリクエストが通った経路の逆順でマイクロサービス基盤２へ返却する。

コンテナ（Radiusサーバ５１ａ～５１ｃ）のうち何れかは、対向ノード（Radiusクライアント１）へのリクエストパケットを送信する。図３では、Radiusサーバ５１ｃがRadiusクライアント１へのリクエストパケットを送信している。不図示のルータは、このリクエストパケットをロードバランサ３にルーティングする。これにより、リクエストパケットはロードバランサ３に中継される。

ロードバランサ３の逆方向中継部３４は、ＮＡＰＴ部３５により、このリクエストパケットの宛先を対向ノードのＩＰアドレスに書き換える。これによりリクエストパケットは、Radiusクライアント１に中継される。

Radiusクライアント１は、リクエストパケットを受信して対応する処理を行うと、応答パケットをロードバランサ３に送信する。ロードバランサ３の逆方向中継部３４は、ＮＡＰＴ部３６により、この応答パケットの宛先をサーバ５ｂのＩＰアドレス10.x.x.102に書き換える。これにより応答パケットは、サーバ５ｂに送信される。

サーバ５ｂのＮＡＰＴ部５５は、この応答パケットの宛先を元のコンテナ（例えば、Radiusサーバ５１ｃ）のＩＰアドレスに書き換える。ここではRadiusサーバ５１ｃが元のコンテナなので、応答パケットの宛先は、10.x.x.104に書き換えられる。

マイクロサービス基盤２の外にいる対向ノード（Radiusクライアント１）から、マイクロサービス基盤２上のコンテナ（Radiusサーバ５１ａ～５１ｃ）に対するリクエストパケットについては、対向ノードからロードバランサ３のＩＰアドレス10.x.y.6を宛先として送信する一般的な仕組みである。

一方、マイクロサービス基盤２上のRadiusサーバ５１ａ～５１ｃからマイクロサービス基盤２の外にいる対向ノードへのリクエストパケットについては、宛先アドレスがマイクロサービス基盤２の外にいるノードとなり、通常の方法ではロードバランサ３を通過しない。これを解決するため、このリクエストパケットがロードバランサ３を通過するための機能を設ける構成をとる。この機能については、後記する第２の実施形態で詳細に説明する。

《第１の実施形態の効果》
ＩＰ認証が必要なＮＦＶアプリケーションを、マイクロサービス化することができる。

《第２の実施形態》
第２の実施形態では、ロードバランサが冗長化している場合において、状態遷移図に記載の条件にて経路を切り替えている。これにより、冗長化したロードバランサのうち何れかに障害が発生してもサービスを継続させることが可能になる。

図４は、マイクロサービス基盤２とロードバランサ３ｃ，３ｄを示すシステム図である。
このシステムでは、オンプレミス１２と、クラウドに配置されたマイクロサービス基盤２とが示されている。オンプレミス１２は、100.X.0.0/16のアドレス帯であり、端末１１を含んでいる。この端末１１のＩＰアドレスは、100.X.0.10である。

マイクロサービス基盤２は、冗長化されたロードバランサ３ｃ，３ｄが制御プレーンに配置され、ワーカーノード５ｃ，５ｄとルータ６がマネジメントプレーンに配置されている。ロードバランサ３ｃが配置された制御プレーンは、100.Y.32.0/23のアドレス帯である。ロードバランサ３ｄが配置された制御プレーンは、100.Y.34.0/23のアドレス帯である。ワーカーノード５ｃが配置されたマネジメントプレーンは、100.Y.44.0/23のアドレス帯である。ワーカーノード５ｄが配置されたマネジメントプレーンは、100.Y.46.0/23のアドレス帯である。

ロードバランサ３ｃは、第１の振分装置として機能する。ロードバランサ３ｄは、第２の振分装置として機能する。ロードバランサ３ｃ，３ｄは、図３に示した順方向中継部３１と逆方向中継部３４とを含んで構成されており、通信中継システムとしても機能する。

図４において、端末１１は、マイクロサービス基盤２の対向ノードである。ロードバランサ３ｃ，３ｄは、２台に冗長化された振分装置である。ワーカーノード５ｃ，５ｄはサーバクラスタ４であり、内部にコンテナをデプロイしている。

図５は、対向ノードからコンテナへのリクエストパケットとその応答パケットの流れを示す図である。
対向ノードからマイクロサービス基盤２へのリクエストパケットの流れを下図に示す。ここでノード間の実線矢印はリクエストパケットを示し、破線矢印は応答パケットを示している。

対向ノードである端末１１は、２台のロードバランサ３ｃ，３ｄのうち何れかにリクエストパケットを送信してアクセスする。ここでは、ロードバランサ３ｄに、リクエストパケットを送信している。端末１１からロードバランサ３ｄへ送信されるリクエストパケットは、送信元が100.X.0.10であり、宛先が100.Y.34.4である。

ロードバランサ３ｄは、図３に示した順方向中継部３１により、ワーカーノード５ｃ，５ｄのうち何れかに対して、このリクエストパケットを振り分ける。この振り分けにあたり、ロードバランサ３ｄの順方向中継部３１は、ＮＡＰＴ部３２により、送信元を自身のＩＰアドレスに書き換え、宛先をワーカーノード５ｄに書き換えている。ロードバランサ３ｄからワーカーノード５ｄに送信されるリクエストパケットは、送信元が100.Y.34.4であり、宛先が100.Y.46.10である。

ワーカーノード５ｄは、その内部に配置されているコンテナにより、このリクエストパケットを処理して応答バケットを生成する。リクエストパケットに対する応答パケットは、リクエストパケットが通った経路を通って返却される。

ワーカーノード５ｄは、応答パケットをロードバランサ３ｄに送信する。ワーカーノード５ｄからロードバランサ３ｄに送信される応答パケットは、送信元が100.Y.46.10であり、宛先が100.Y.34.4である。つまり、応答パケットの宛先は、リクエストパケットの送信元である。これにより、ワーカーノード５ｄは、リクエストパケットの経路の逆順で応答パケットを送信することができる。

ロードバランサ３ｄは、順方向中継部３１により、送信元を自身のＩＰアドレスに書き換え、宛先をリクエストパケットの送信元である端末１１に書き換えている。ロードバランサ３ｄから端末１１に送信される応答パケットは、送信元が100.Y.34.4であり、宛先が100.X.0.10である。端末１１が受信した応答パケットの送信元は、端末１１が送信したリクエストパケットの宛先と同一である。これにより端末１１は、リクエストパケットと送信パケットとを対応づけることができる。

図６は、コンテナから対向ノードへのリクエストの流れを示す図である。
ここでは、コンテナから対向ノードへのリクエストの流れを示しており、例としてRadius Disconnect Requestについて記載している。

ワーカーノード５ｃ，５ｄの収容されるサブネットのルータ６のルーティングテーブル６１には、対向ノードのアドレス帯へのリクエストパケットは、ロードバランサ３ｃにルーティングされるように経路が設定されている。

ワーカーノード５ｃのコンテナから対向ノードへのリクエストバケットが送信される。このリクエストパケットはロードバランサ３ｃにルーティングされる。ワーカーノード５ｃからロードバランサ３ｃにルーティングされたリクエストパケットは、送信元が100.Y.44.10であり、宛先が100.X.0.10である。

ロードバランサ３ｃは、逆方向中継部３４により、このリクエストパケットの送信元を自身のＩＰアドレスに書き換えている。ロードバランサ３ｃから端末１１に中継されるリクエストパケットは、送信元が100.Y.32.4であり、宛先が100.X.0.10である。これにより端末１１は、リクエストパケットに対する応答パケットの宛先を決定できる。具体的にいうと、リクエストパケットの送信元を応答パケットの宛先とすることで、このリクエストパケットが通った経路を通して応答パケットを返却することができる。

端末１１は、このリクエストパケットを処理して、応答バケットを生成する。リクエストパケットに対する応答パケットは、リクエストパケットが通った経路を通って返却される。そのため、応答パケットの宛先には、リクエストパケットの送信元が設定される。

つまり、端末１１は、応答パケットをロードバランサ３ｃに送信する。端末１１からロードバランサ３ｃに送信される応答パケットは、送信元が100.X.0.10であり、宛先が100.Y.32.4である。

応答パケットを受信すると、ロードバランサ３ｃは、送信元を自身のＩＰアドレスに書き換え、宛先をワーカーノード５ｃに書き換えている。ロードバランサ３ｄからワーカーノード５ｃに送信される応答パケットは、送信元が100.Y.32.4であり、宛先が100.Y.44.10である。

図７は、現用系のロードバランサ３ｃに障害が発生した場合の動作を示す図である。
ここで、現用系（Active）のロードバランサ３ｃに障害が発生した場合、ロードバランサ３ｃは、Fault状態に遷移する。ロードバランサ３ｃと対向するロードバランサ３ｄは、予備系（Backup）から現用系（Active）に昇格する。

これと共にサーバの収容されるサブネットのルーティングテーブル６１が変更され、Route（経路）がロードバランサ３ｄに切り替わる。これによって、片方のロードバランサに障害が発生しても、他方のロードバランサで継続してリクエストの送受信が可能となる。

図８は、Nginx（登録商標）の状態遷移図である。
Nginx（登録商標）は、オープンソースとして開発されたフリーのＷｅｂサーバプログラムである。以下、Nginxは、「（登録商標）」を省略して記載する。Nginxは、リバースプロキシ機能に加え、ロードバランサやＨＴＴＰキャッシュの機能を実現している。ここで図４から図７のロードバランサ３ｃ，３ｄは、Nginxによって実現されている。

モードＭ２０の“Active”とは、Nginxのロードバランサが現用系として動作しているモードである。モードＭ２０においてNginxが故障すると、モードＭ２２の“Fault”に遷移する。モードＭ２０において、対向ロードバランサの復帰によるPriorityの再計算が行われると、モードＭ２１の“Backup”に遷移する。

モードＭ２１の“Backup”とは、Nginxのロードバランサが予備系として動作しているモードである。モードＭ２１において、対向ロードバランサの故障によるPriorityの再計算が行われると、モードＭ２０の“Active”に遷移する。モードＭ２１においてNginxが故障すると、モードＭ２２の“Fault”に遷移する。

モードＭ２２の“Fault”とは、Nginxのロードバランサが故障により動作を停止しているモードである。モードＭ２２において、自身のNginxが復帰すると、モードＭ２１の“Backup”に遷移する。

図９は、Nginx（登録商標）で動作する２台のロードバランサ夫々の状態遷移テーブルを示す図である。
各行の項目は、変更前のNginxの状態を示している。各列の項目は、変更後のNginxの状態を示している。

変更前のNginxの状態が“Active”であり、変更後のNginxの状態は“Backup”であるとき、対向ノードからマイクロサービス基盤２へのルートの向き先は、対向のＮＩＣ（Network Interface Card）のアドレスとなる。

変更前のNginxの状態が“Active”であり、変更後のNginxの状態は“Fault”であるとき、対向ノードからマイクロサービス基盤２へのルートの向き先は変更されない。
変更前のNginxの状態が“Backup”であり、変更後のNginxの状態は“Active”であるとき、対向ノードからマイクロサービス基盤２へのルートの向き先は、自身のＮＩＣのアドレスとなる。

変更前のNginxの状態が“Backup”であり、変更後のNginxの状態は“Fault”であるとき、対向ノードからマイクロサービス基盤２へのルートの向き先は変更されない。
変更前のNginxの状態が“Fault”であり、変更後のNginxの状態は“Active”または“Backup”であるとき、対向ノードからマイクロサービス基盤２へのルートの向き先は変更されない。

図１０は、障害パターンに応じたルーティングテーブル６１のモード間の動作を示すモード遷移図である。
障害パターンに応じた、ルーティングテーブル６１（図７参照）の変更パターンを以下の状態遷移図に示す。図１０と図１１において、LB1はロードバランサ３ｃを示し、LB2はロードバランサ３ｄを示す。また、LB1はLB2よりも優先順位が高い。

モードＭ１０は、LB1とLB2が共に“Fault”であり、ルーティングテーブル６１の対向ノードからマイクロサービス基盤２へのルートの向き先がLB1またはLB2の場合である。なお、図面において、ルートの向き先がLB1またはLB2の場合を“LB1orLB2”と記載する。モードＭ１０において、LB1のNginxが復旧したならば、マイクロサービス基盤２は、モードＭ１１に遷移する。モードＭ１０において、LB2のNginxが復旧したならば、マイクロサービス基盤２は、モードＭ１４に遷移する。以降、ルーティングテーブル６１の対向ノードからマイクロサービス基盤２へのルートの向き先のことを、単に「ルートの向き先」と記載する。

モードＭ１１は、LB1が“Active”であり、LB2が“Fault”であり、ルートの向き先がLB1またはLB2の場合である。モードＭ１１において、priorityが計算されたならば、マイクロサービス基盤２はモードＭ１２に遷移する。

モードＭ１２は、LB1が“Active”であり、LB2が“Fault”であり、ルートの向き先がLB1の場合である。モードＭ１２において、LB2のNginxが復旧したならば、マイクロサービス基盤２はモードＭ１３に遷移する。モードＭ１２において、LB1のNginxの異常を検知したならば、マイクロサービス基盤２はモードＭ１０に遷移する。

モードＭ１３は、LB1が“Active”であり、LB2が“Backup”であり、ルートの向き先がLB1の場合である。モードＭ１３において、LB2のNginxの異常を検知したならば、マイクロサービス基盤２はモードＭ１２に遷移する。モードＭ１３において、Keepalive異常を検知したならば、マイクロサービス基盤２はモードＭ１７に遷移する。モードＭ１３において、LB1のNginxの異常を検知したならば、マイクロサービス基盤２はモードＭ１５に遷移する。

モードＭ１４は、LB1が“Fault”であり、LB2が“Backup”であり、ルートの向き先がLB1またはLB2の場合である。モードＭ１４において、priorityが計算されたならば、マイクロサービス基盤２はモードＭ１５に遷移する。

モードＭ１５は、LB1が“Fault”であり、LB2が“Active”であり、ルートの向き先がLB2の場合である。モードＭ１５において、LB1のNginxが復旧したならば、マイクロサービス基盤２はモードＭ１６に遷移する。モードＭ１５において、LB2のNginxの異常を検知したならば、マイクロサービス基盤２はモードＭ１０に遷移する。

モードＭ１６は、LB1が“Backup”であり、LB2が“Active”であり、ルートの向き先がLB2の場合である。モードＭ１６において、Priorityが計算されたならば、マイクロサービス基盤２はモードＭ１３に遷移する。モードＭ１６において、Keepalive異常を検知したならば、マイクロサービス基盤２はモードＭ１７に遷移する。

モードＭ１７は、LB1が“Active”であり、LB2が“Active”であり、ルートの向き先がLB1またはLB2の場合である。モードＭ１７において、Priorityが計算されたならば、マイクロサービス基盤２はモードＭ１３に遷移する。

このように、LB1とLB2の両方が稼働可能な状態であったならば、LB1が現用系に昇格し、LB2が予備系に降格する。これにより、複数の振分装置が同時に稼働することを防ぎ、何れかの振分装置が故障したときの回復を容易とすることができる。

図１１は、障害パターンに応じたルーティングテーブル６１のルートの向きの変更を示すモード遷移図である。図１１の各モードは、図１０に示した各モードと同一であり、同一の符号を付与している。

モードＭ１０は、LB1とLB2が共に“Fault”であり、ルートの向き先がLB1またはLB2の場合である。モードＭ１０において、LB1のNginxが復旧したならば、マイクロサービス基盤２はモードＭ１１に遷移するが、このときルートの向き先は変更されない。モードＭ１０において、LB2のNginxが復旧したならば、マイクロサービス基盤２はモードＭ１４に遷移するが、このときもルートの向き先は変更されない。

モードＭ１１は、LB1が“Active”であり、LB2が“Fault”であり、ルートの向き先がLB1またはLB2の場合である。モードＭ１１において、priorityが計算されたならば、LB1がルートの向き先をLB1に変更し、マイクロサービス基盤２はモードＭ１２に遷移する。

モードＭ１２は、LB1が“Active”であり、LB2が“Fault”であり、ルートの向き先がLB1の場合である。モードＭ１２において、LB2のNginxが復旧したならば、マイクロサービス基盤２はモードＭ１３に遷移するが、ルートの向き先は変更されない。モードＭ１２において、LB1のNginxの異常を検知したならば、マイクロサービス基盤２はモードＭ１０に遷移するが、ルートの向き先は変更されない。

モードＭ１３は、LB1が“Active”であり、LB2が“Backup”であり、ルートの向き先がLB1の場合である。モードＭ１３において、LB2のNginxの異常を検知したならば、マイクロサービス基盤２はモードＭ１２に遷移するが、ルートの向き先は変更されない。モードＭ１３において、Keepalive異常を検知したならば、LB2がルートの向き先をLB2に変更し、マイクロサービス基盤２はモードＭ１７に遷移する。
モードＭ１３において、LB1のNginxの異常を検知したならば、LB2がルートの向き先をLB2に変更し、マイクロサービス基盤２はモードＭ１５に遷移する。

モードＭ１４は、LB1が“Fault”であり、LB2が“Backup”であり、ルートの向き先がLB1またはLB2の場合である。モードＭ１４において、priorityが計算されたならば、LB2がルートの向き先をLB2に変更し、マイクロサービス基盤２はモードＭ１５に遷移する。

モードＭ１５は、LB1が“Fault”であり、LB2が“Active”であり、ルートの向き先がLB2の場合である。モードＭ１５において、LB1のNginxが復旧したならば、マイクロサービス基盤２はモードＭ１６に遷移するが、ルートの向き先は変更されない。モードＭ１５において、LB2のNginxの異常を検知したならば、マイクロサービス基盤２はモードＭ１０に遷移するが、ルートの向き先は変更されない。

モードＭ１６は、LB1が“Backup”であり、LB2が“Active”であり、ルートの向き先がLB2の場合である。モードＭ１６において、Priorityが計算されたならば、LB1またはLB2は、ルートの向き先をLB1に変更し、マイクロサービス基盤２はモードＭ１３に遷移する。モードＭ１６において、Keepalive異常を検知したならば、LB1がルートの向き先をLB1に変更し、マイクロサービス基盤２はモードＭ１７に遷移する。

モードＭ１７は、LB1が“Active”であり、LB2が“Active”であり、ルートの向き先がLB1またはLB2の場合である。モードＭ１７において、Priorityが計算されたならば、LB2がルートの向き先をLB1に変更し、マイクロサービス基盤２はモードＭ１３に遷移する。

《第２の実施形態の効果》
マイクロサービス基盤２に、複数のロードバランサ３ｃ，３ｄを設置して冗長化した際に、図１０と図１１で示したモード遷移で動作させることで、ロードバランサ３ｃ，３ｄの一方に障害が発生しても、他方のロードバランサでサービスを継続させることができる。

《第３の実施形態》
図１２は、仮想ＩＰアドレス７１を用いたロードバランサ７を示す図である。
ロードバランサ７は、仮想ＩＰアドレス７１を備え、内部にNginxロードバランサ７２ａ，７２ｂが配置されている。

この場合、サーバクラスタ４から対向ノード向けのパケットが送られてきたときに、Nginxロードバランサ７２ａ，７２ｂのうちActive側（現用系）にルーティングさせる方式は同じである。

第３の実施形態では、第２の実施形態と同様に、ロードバランサの障害時にルーティングテーブルを切り替え、それに加えて仮想ＩＰアドレス７１の付け替えも実施する。これにより、図１１に示した対向ノードからマイクロサービス基盤２へのルートの向き先の変更を容易に実施可能である。

《第３の実施形態の効果》
マイクロサービス基盤に設置されるロードバランサを冗長化し、ロードバランサに障害が発生してもサービスを継続させることができる。

《変形例》
本発明は、上記実施形態に限定されることなく、本発明の趣旨を逸脱しない範囲で、変更実施が可能であり、例えば、次の（ａ）～（ｃ）のようなものがある。

（ａ） 本発明が適用されるアプリケーションは、Radius認証に限定されない。
（ｂ） 本発明のマイクロサービス基盤は、kubernetesに限定されない。
（ｃ） 本発明のロードバランサを具現化するＷｅｂサーバプログラムは、Nginxに限定されない。

《本発明の概要とその効果》
（１）に記載の発明では、マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを、前記マイクロサービスを収容するサーバ群のうち何れかに振り分ける順方向中継部と、前記マイクロサービスから対向ノードのアドレス帯へのリクエストをＮＡＰＴし、前記リクエストに対する対向ノードからの応答を前記リクエストが通った経路の逆順で前記マイクロサービスへ返却する逆方向中継部と、を備えることを特徴とする通信中継装置とした。

このようにすることで、ＩＰ認証が必要なＮＦＶアプリケーションを搭載するマイクロサービス基盤において、マイクロサービスから対向ノードに対して送信されるリクエストのアプリケーションの要件を満たすことができる。

（２）に記載の発明では、前記順方向中継部は、前記リクエストの送信元アドレスを自身のアドレスに書き換えてＮＡＰＴする、ことを特徴とする請求項１に記載の通信中継装置とした。

このようにすることで、マイクロサービスは、応答パケットの宛先を、この通信中継装置とすることができる。更に通信中継装置は、この応答パケットをＮＡＰＴすることにより、リクエストパケットを送信した対向ノードに中継可能である。

（３）に記載の発明では、マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを前記マイクロサービスを収容するサーバ群のうち何れかに振り分ける順方向中継部と、前記マイクロサービスから対向ノードのアドレス帯へのリクエストをＮＡＰＴし、リクエストされた対向ノードからの応答を前記リクエストが通った経路の逆順で前記マイクロサービスへ返却する逆方向中継部と、をそれぞれ備える第１，第２の振分装置を有する通信中継システムであって、前記第１の振分装置および前記第２の振分装置の何れか一方が現用系の振分装置、他方が待機系の振分装置として機能する、ことを特徴とする通信中継システムとした。

このようにすることで、ＩＰ認証が必要なＮＦＶアプリケーションを、マイクロサービス化することができ、かつ振分装置を冗長化することができる。

（４）に記載の発明では、前記マイクロサービスから対向ノードのアドレス帯へのリクエストを前記現用系の振分装置へルーティングするように経路を設定するルータ、を備え、前記第１の振分装置および前記第２の振分装置の何れか一方である現用系の振分装置が故障して、他方である待機系の振分装置が現用系に昇格した際、前記待機系の振分装置が前記マイクロサービスから対向ノードのアドレス帯へのリクエストを自身へルーティングするように前記ルータに経路を設定する、ことを特徴とする請求項３に記載の通信中継システムとした。

このようにすることで、ＩＰ認証が必要なＮＦＶアプリケーションを、マイクロサービス化することができ、かつ振分装置の一方に障害が発生しても、他方の振分装置でサービスを継続可能である。

（５）に記載の発明では、前記第１の振分装置および前記第２の振分装置の両方が稼働可能な状態であったならば、前記第１の振分装置が現用系に昇格する、ことを特徴とする請求項３に記載の通信中継システムとした。

このようにすることで、例えば第１の振分装置よりも第２の振分装置を性能が低く廉価なものとすることで、廉価に冗長化を実現できる。

（６）に記載の発明では、振分装置が、マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを前記マイクロサービスを収容するサーバ群のうち何れかに振り分けるステップと、前記マイクロサービスから対向ノードのアドレス帯へのリクエストを前記振分装置がＮＡＰＴし、リクエストされた対向ノードからの応答を前記リクエストが通った経路の逆順で前記マイクロサービスへ返却するステップと、を実行することを特徴とする通信中継方法とした。

このようにすることで、ＩＰ認証が必要なＮＦＶアプリケーションを搭載するマイクロサービス基盤において、マイクロサービスから対向ノードに対して送信されるリクエストのアプリケーションの要件を満たすことができる。

（７）に記載の発明では、第１，第２の振分装置が、マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを前記マイクロサービスを収容するサーバ群のうち何れかに振り分けるステップと、前記マイクロサービスから対向ノードのアドレス帯へのリクエストを前記第１，第２の振分装置がＮＡＰＴし、リクエストされた対向ノードからの応答を前記リクエストが通った経路の逆順で前記マイクロサービスへ返却するステップと、を実行し、前記第１の振分装置および前記第２の振分装置の何れか一方が現用系の振分装置、他方が待機系の振分装置として機能する、ことを特徴とする通信中継方法とした。

このようにすることで、ＩＰ認証が必要なＮＦＶアプリケーションを搭載するマイクロサービス基盤において、マイクロサービスから対向ノードに対して送信されるリクエストのアプリケーションの要件を満たすことができる。

（８）に記載の発明では、マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを前記マイクロサービスを収容するサーバ群のうち何れかに振り分ける手順、前記マイクロサービスから対向ノードのアドレス帯へのリクエストをＮＡＰＴさせて、リクエストされた対向ノードからの応答をリクエストが通った経路で前記マイクロサービスへ返却する手順、をコンピュータに実行させるためのプログラムとした。

このようにすることで、ＩＰ認証が必要なＮＦＶアプリケーションを搭載するマイクロサービス基盤において、マイクロサービスから対向ノードに対して送信されるリクエストのアプリケーションの要件を満たすことができる。

１ Radiusクライアント
１１ 端末
１２ オンプレミス
２ マイクロサービス基盤
３，３ｃ，３ｄ ロードバランサ （振分装置、通信中継装置）
３１ 順方向中継部
３２，３３ ＮＡＰＴ部
３４ 逆方向中継部
３５，３６ ＮＡＰＴ部
４ サーバクラスタ
５ａ サーバ
５ｂ サーバ
５１ａ～５１ｃ Radiusサーバ
５２，５３，５４，５５ ＮＡＰＴ部
５ｃ，５ｄ ワーカーノード
６ ルータ
７ ロードバランサ
７１ 仮想ＩＰアドレス
７２ａ，７２ｂ Nginxロードバランサ

Claims (8)

1. マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを、前記マイクロサービスを収容するサーバ群のうち何れかに振り分ける順方向中継部と、
   前記マイクロサービスから対向ノードのアドレス帯へのリクエストをＮＡＰＴし、前記リクエストに対する対向ノードからの応答を前記リクエストが通った経路の逆順で前記マイクロサービスへ返却する逆方向中継部と、
   を備えることを特徴とする通信中継装置。
2. 前記順方向中継部は、前記リクエストの送信元アドレスを自身のアドレスに書き換えてＮＡＰＴする、
   ことを特徴とする請求項１に記載の通信中継装置。
3. マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを前記マイクロサービスを収容するサーバ群のうち何れかに振り分ける順方向中継部と、
   前記マイクロサービスから対向ノードのアドレス帯へのリクエストをＮＡＰＴし、リクエストされた対向ノードからの応答を前記リクエストが通った経路の逆順で前記マイクロサービスへ返却する逆方向中継部と、をそれぞれ備える第１，第２の振分装置を有する通信中継システムであって、
   前記第１の振分装置および前記第２の振分装置の何れか一方が現用系の振分装置、他方が待機系の振分装置として機能する、
   ことを特徴とする通信中継システム。
4. 前記マイクロサービスから対向ノードのアドレス帯へのリクエストを前記現用系の振分装置へルーティングするように経路を設定するルータ、
   を備え、
   前記第１の振分装置および前記第２の振分装置の何れか一方である現用系の振分装置が故障して、他方である待機系の振分装置が現用系に昇格した際、前記待機系の振分装置が前記マイクロサービスから対向ノードのアドレス帯へのリクエストを自身へルーティングするように前記ルータに経路を設定する、
   ことを特徴とする請求項３に記載の通信中継システム。
5. 前記第１の振分装置および前記第２の振分装置の両方が稼働可能な状態であったならば、前記第１の振分装置が現用系に昇格する、
   ことを特徴とする請求項３に記載の通信中継システム。
6. 振分装置が、マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを前記マイクロサービスを収容するサーバ群のうち何れかに振り分けるステップと、
   前記マイクロサービスから対向ノードのアドレス帯へのリクエストを前記振分装置がＮＡＰＴし、リクエストされた対向ノードからの応答を前記リクエストが通った経路の逆順で前記マイクロサービスへ返却するステップと、
   を実行することを特徴とする通信中継方法。
7. 第１，第２の振分装置が、マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを前記マイクロサービスを収容するサーバ群のうち何れかに振り分けるステップと、
   前記マイクロサービスから対向ノードのアドレス帯へのリクエストを前記第１，第２の振分装置がＮＡＰＴし、リクエストされた対向ノードからの応答を前記リクエストが通った経路の逆順で前記マイクロサービスへ返却するステップと、を実行し、
   前記第１の振分装置および前記第２の振分装置の何れか一方が現用系の振分装置、他方が待機系の振分装置として機能する、
   ことを特徴とする通信中継方法。
8. マイクロサービスの対向ノードから前記マイクロサービスへのリクエストを前記マイクロサービスを収容するサーバ群のうち何れかに振り分ける手順、
   前記マイクロサービスから対向ノードのアドレス帯へのリクエストをＮＡＰＴさせて、リクエストされた対向ノードからの応答をリクエストが通った経路で前記マイクロサービスへ返却する手順、
   をコンピュータに実行させるためのプログラム。

Images