1.　はじめに

スマートフォンやタブレットなどのモバイル端末や5Gなどの無線通信技術の急速な普及により，移動しながら通信を行う機会が増加している[1]．しかし，端末の移動により接続先ネットワークが変化した場合や，Wi-Fiから5Gのように通信インタフェースを切り替えた場合，端末に割り当てられるIPアドレスもともに変化してしまう．そのため，移動前のIPアドレスで確立した通信フローを移動後では識別することができなくなるため，通信が断絶してしまう課題が存在する．この課題を解決する技術として移動透過性プロトコルが提案されている[2], [3]．

一方，現在のモバイルインターネット環境はIPv4とIPv6が混在しており，端末の移動先ネットワークによっては，移動透過性プロトコルを実装していても通信が断絶する場合がある．たとえば，IPv4ネットワークでは，IPv4グローバルアドレスの枯渇問題に対応するためにNAT（Network Address Translation）を導入し，プライベートネットワークを構築することが一般的である．しかし，NATの外側から内側のネットワークに対して通信を開始できないNAT越え問題が発生する．さらに，IPv4とIPv6の間では互換性が無いため，直接通信を行うこともできない．そのため，端末の接続先ネットワークの種類や通信相手端末のネットワーク環境に影響されることなく，通信接続性を確保しつつ，移動透過性を実現することが要求されている．特に，働き方改革の一環として遠隔地から組織内のネットワークへ安全に接続する需要が高まっており，この問題の解決は重要である[4]．

このような背景から，筆者らはIPv4/IPv6混在環境において通信接続性と移動透過性を同時に実現するNTMobile（Network Traversal with Mobility）を提案してきた[5]-[7]．NTMobileはエンド端末のIP層で動作するシステムであり，NTMobileを導入したエンド端末同士は暗号化されたトンネルを動的に構築し通信を行う．そのため，既存のアプリケーションを変更すること無く，ネットワークの制約を除去して安全なエンドツーエンド通信が可能となる．

NTMobileに基づく通信では，エンド端末間で暗号化トンネルを動的に形成するために，DC（Direction Coordinator）やRS（Relay Server）と呼ぶNTMobile独自のサーバ群が定義され，トンネル形成に必要なエンド端末の情報やRS中継の有無，暗号鍵などの情報を取り交わす．さらに，NTMobile特有の処理時に出力されるログは，DCやRSが連携しているため複数台のサーバへ分散することや，サーバが処理時に生成する情報をメモリ上のみにキャッシュすることもある．したがって，サーバ管理者がNTMobileの処理に関して監視や調査を行うには，複数台のサーバからログを取得して突き合わせて調査したり，メモリ上の情報を参照するためにメモリダンプを行って解析する必要があった．このような状況下において，NTMobile特有の処理において障害が発生した場合，管理者はトンネル形成にかかわったDCやRSを特定し，各種ログなどの情報を収集して解析する必要があり，エラーの原因究明に時間を要する懸念がある．そのため，NTMobileを安定的に運用するために，NTMobileサーバ群を低負担かつ高効率なサーバ管理手法は非常に重要である．

これまでに，上記の課題を解決すべく，NTMobileサーバ群を統合監視する手法が提案されている[8]．NTMobile独自の拡張MIB（Management Information Base）を定義し，各サーバの死活監視やCPU使用率等の負荷情報をSNMP（Simple Network Management Protocol）を用いて取得する．しかし，この手法では拡張MIBに基づいた規定的な状態情報しか取得できなかったため，NTMobileの一連の処理が正常に動作していない場合の状況分析や原因の特定に必要な任意の情報を網羅的に収集することができなかった．また，NTMobile機能を有するエンド端末はホームネットワークや社内LAN，セルラーネットワークに接続している状況がほとんどであり，エンド端末とDCおよびRS間にはNATやファイアウォールが存在するため，環境によってSNMPによる情報取得が不可能な場合も考えられる．

本稿では，ネットワーク機器等の統合監視システムであるZabbixを活用してNTMobileサーバ群を低負担かつ高効率に監視するシステムを提案する．NTMobileサーバ群のハードウェアリソース情報の監視以外にも，Zabbix上でNTMobileプロセスがメモリ上でキャッシュしている内部情報の監視を通じたNTMobile特有の処理に基づく障害の原因調査が行えるようにする．Linux環境上に実現したプロトタイプを用いて動作検証を行い，提案システムを導入することにより，管理者が監視作業に費やす負担がどの程度削減できるか示す．

2.　NTMobile

2.1　概要

NTMobileでは，ネットワークに依存せず端末の識別子としての役割を持つ仮想IPアドレスと，接続先ネットワークから割り当てられる位置情報としての役割を担う実IPアドレスの両方を利用して通信を行う．エンド端末のアプリケーション間で交換されるメッセージには仮想IPアドレスに基づくIPパケットを利用しており，実際のネットワークでルーティングさせるために実IPアドレスに基づくUDP/IPヘッダでカプセル化を行う．

NTMobileを実装したエンド端末は，起動時にDCより仮想IPアドレスが割り当てられる．通信開始時において，NTMobileを実装した通信相手端末との間で暗号鍵の交換やUDPトンネルの動的な構築を行い，仮想IPアドレスに基づくIPパケットをUDPトンネルを通じて通信相手端末へ伝送する．これにより，ネットワークの切り替えや通信経路上にあるNATの影響を受けない通信が可能である．さらに，移動や通信インタフェースの切り替えよりエンド端末の接続先ネットワークが変化した場合でも，仮想IPアドレスは変化しないため通信が断絶しない．

2.2　構成

図1にNTMobileの概要を示す．NTMobileは下記に示す装置より構成されている．

• ・NTM端末
  NTMobileが実装されたエンド端末である．便宜上，通信開始側NTM端末をMN（Mobile Node），その通信相手NTM端末をCN（Correspondent Node）と表記する．NTMobileを利用するために，任意のDCへログイン処理を行い仮想IPアドレスを取得する．この仮想IPアドレスを用いて通信を行う．
• ・DC（Direction Coordinator）
  管理下にあるNTM端末に仮想IPアドレスの割り当てや，NTM端末の実IPアドレス情報などの管理を行う．さらに，NTM端末の通信開始時に両端末間で最適なトンネル経路を構築するため，関連する端末へトンネル構築に関わる指示を送る．
• ・RS（Relay Server）
  NTMobileは経路最適化[9]により可能な限りNTM端末間で直接相互通信を行うが，IPv4/IPv6間の互換性がないネットワーク間で通信する場合や，NATの種類によっては経路最適化が行えない．このようなNTM端末同士で直接相互通信が行えない場合に通信を中継する．

DCやRSはデュアルスタックネットワークに接続しており，ネットワークの規模に応じて分散設置することが可能である．

2.3　通信シーケンス

図2にIPv4ネットワークに接続されているNTM端末とIPv6ネットワークに接続されているNTM端末間でUDPトンネルを構築して通信を開始するまでの通信シーケンスを示す．NTM端末は端末起動時に，現在の実IPアドレスや公開鍵情報をDCに登録するログイン処理を行う．DCはログインしたNTM端末に仮想IPアドレスを割り当て，NTM端末のアドレス情報やNTM端末の公開鍵情報を内部のデータベースに追加する．NTM端末は通信開始時に通信相手と通信を開始する要求を登録先DCへ送信する．その後，DCは受信した要求の内容を基に通信相手NTM端末の管理先DCを特定し，NTM端末間のトンネル構築を行うシグナリング処理を実施する．ただし，NTM端末同士が直接相互通信できないとDCが判断した場合はRSを経由する経路でトンネル構築を行う．

このように，NTMobileに基づいた通信は，DCおよびRSがメッセージの交換を通じてNTM端末間でトンネルを構築し端末間で通信を行う．

2.4　運用時における課題

NTMobileを実環境での運用を想定した場合や開発時において，以下に示す課題が懸念される．

• (1) NTMobile特有の処理にてエラーが発生した場合，サーバへリモートアクセスを行い，状況の調査を行う必要がある．特に，NTMobileに基づく通信はDCやRSが連携してNTM端末間の通信経路を構築するため，処理時に出力されるログが複数のサーバへ分散してしまう．そのため，サーバ管理者は複数のサーバからログを取得し，突き合わせて調査する必要がある．さらに，文字列による情報のため，視認性が悪く情報の見落としなどヒューマンエラー発生の懸念もある．
• (2) 障害発生時の原因特定に有用な情報が内部情報としてメモリ上のみに存在し，サーバ管理者が参照するためにメモリダンプ処理を行う必要がある．障害発生原因の調査時において，RSが持つリレーテーブルは通信経路の追跡を行う際に有用な情報であるが，メモリ上のみに存在するため，調査に時間を要する．
• (3) RSは通信の中継を行うために両NTM端末とUDPトンネルを構築するが，構築時にエフェメラルポートの範囲内[10]にあるUDPポート番号をUDPトンネルに割り当てる．つまり，使用可能なUDPポート番号が枯渇状態にある場合，UDPトンネルを新規構築することができない．しかし，トンネル構築指示を出すDCはすべてのRSが持つ割り当て可能なUDPポート番号の残数を把握しておらず，固定的に選択したRSに対してトンネル構築指示を送るため，RSの状態によっては処理エラーになる可能性がある．また，DCではログインしているNTM端末に対して仮想IPアドレスの割り当てやトンネル構築指示の送信などの処理を行うため，管理下にあるNTM端末台数の増加による通信負荷により処理遅延の発生が予測される．そのため，各RSで使用可能なUDPポート番号の残数やDCにログインしているNTM端末を管理する必要がある．

3.　提案システム

3.1　監視システムの要求事項

2.4節で示した運用時に懸念される課題を踏まえて，NTMobileサーバ群の統合監視システム構築にあたり，システム構築後の運用の手間やNTMobile自体のサービス品質低下を防止する仕組みとして，本稿では下記の要件を満たす必要があると考えた．

多数の機器の監視が可能

NTMobileはDCやRSがネットワーク規模に応じて分散配置されるため，複数機器を同時にかつ高効率な監視ができることは必須である．

多様な監視データの収集手段があること

監視情報の収集による通信帯域の逼迫を最小限にするため，監視情報取得の頻度や取得方法を柔軟に選択できることが重要である．

IPv4/IPv6混在環境下でも監視データの収集が可能

DCやRSはIPv4/IPv6が混在したネットワーク環境下において分散的に配置されるため，監視対象となる機器が出力する監視情報を接続先ネットワークによらず収集できることが必須である．

NTMobile独自項目の監視が可能

システムリソース使用量やシステム死活監視など標準的な監視項目以外にも，NTMobileで使用されるパラメータやメモリ上にキャッシュされる内部情報も監視できることは必須である．

再実装なく新規監視項目に対応可能

NTMobileは現在開発段階であり，今後も新機能が実装されることが予想される．これに伴い，監視内容を拡張する場合でも監視プラットフォーム自体に変更を加えない実現方法が望ましい．

3.2　提案システム概要

3.1節で示した要求事項を基に，NTMobileサーバ群の統合監視システムを構築するために，Zabbixを利用する．Zabbix [11]とは，ネットワーク上に分散する監視対象機器を統合監視するオープンソースで提供されている管理ソフトウェアである．Zabbixを利用する理由として，標準的なサービスやサービスに依存しないログ等の監視に加え，拡張次第で任意の値を取得および監視できる汎用性の高さ，監視項目等の設定等を複数の監視対象機器に共有できるためZabbix自体の管理負担が増大しないこと，GUIを用いた監視が可能であり，監視情報の閲覧や監視項目の設定をマウス操作で完結することが挙げられる．実際に，Zabbixはネットワーク機器の監視以外にもセンサー情報の分析基盤システムなど幅広い場面で利用されている[12], [13]．

Zabbixを利用しNTMobileサーバ群を統合的にかつ詳細に監視できるよう，以下に示すNTMobileおよびZabbixの機能拡張を提案する．

3.3　構成

図3に提案システムの概要を示す．監視対象となるDCおよびRSから監視情報を取得するために，デーモンプロセスであるZabbix Agentを各監視対象サーバへ導入する．また，Zabbix Agentが取得した監視情報を回収し総括するZabbixサーバをNTMobileシステム内に導入する．なお，IPv4およびIPv6上に存在する監視対象機器から監視情報を取得できるよう，Zabbixサーバはデュアルスタックネットワーク上に設置する．これにより，各監視対象サーバから回収した情報をZabbix上で集中的に監視することが可能である．

3.4　監視項目

Zabbixでは，サーバ死活監視やログファイル回収など一般的に利用される監視項目は標準で搭載されている．これらに加え，NTMobileの動作状況をより詳細に監視するために，NTMobileに関する監視項目を追加する．

3.4.1　障害検知

NTMobile特有の処理に関する障害の検知には，各サーバが出力するログの内容監視およびプロセス死活監視により行う．図4にNTMobileが出力するログを用いた障害検知手法の概要を示す．ログファイルの内容検知にはZabbixトリガー[14]機能を利用する．Zabbixトリガーは，事前に定義した条件式に基づき回収した監視情報を評価し，条件を満たす場合に指定した動作アクションを実行する機能である．提案システムでは，NTMobile特有の処理に関する障害を管理者が迅速に検知できるように，NTMobileが出力するログ内にキーワードを埋め込む．埋め込んだキーワードが含まれるログをZabbixサーバが回収した際に，その内容に基づいた障害情報をZabbix上に表示するようZabbixトリガーの条件式を定義する．

加えて，監視対象上で稼働するプロセスを監視し，NTMobileに関連するプロセスが動作しているか確認することで，NTMobileのシステムダウンをプロセス死活監視からも検知する．

以上により，DCやRS上で発生したNTMobile特有の処理に関する障害や関連するプロセスの稼働状況をZabbix上で検知することが可能になる．

3.4.2　内部情報可視化

RSが持つ内部情報としてリレーテーブルが定義されている[5]．リレーテーブルとは，RSが通信の中継を行うためにNTM端末とRS間で構築されるUDPトンネルとNTM端末の仮想IPアドレスを対応付けた情報である．この情報は通信障害発生時の原因究明において通信経路を追跡する際に有用な情報であるが，RSのメモリ上のみに存在する．提案システムでは，Zabbixが提供する機能であるスクリーン[15]を利用し，メモリダンプ操作を必要としないリレーテーブルの可視化を実装する．

スクリーンとは，Zabbixが取得した監視情報を1つの画面内に一覧表示し，管理者が監視対象のシステム状況について直感的に概要を把握することを目的とした機能である．スクリーンで表示ができる内容として，各種監視情報のほかにHTTPを用いて取得したHTMLページの表示がある．HTMLページの表示が可能であることに注目し，RS上でリレーテーブルの情報をHTMLにレンダリングする機能をNTMobileに追加実装を行い，Zabbixのスクリーンを通じてリレーテーブルを可視化できるようにする．

図5にリレーテーブルをZabbix上に可視化する手法の概要を示す．リレーテーブルをZabbix上で可視化するため，RSに可視化プロセスを追加実装する．そして，RSプロセス内で用いられているリレーテーブルに関する変数を取得できるようRSプロセスの機能拡張を行い，UNIXドメインソケットを用いたプロセス間通信により可視化プロセスにリレーテーブルに関する情報を送信する．可視化プロセスでは受け取った情報はWebフレームワークを用いてHTMLページにレンダリングする．

これにより，内部情報を取得するプロセスとZabbixで用意されているスクリーン機能を組み合わせる方法を用いることで，NTMobileプロセスが内部情報としてメモリ上にキャッシュしているリレーテーブルの情報を直接監視することが可能となる．

3.4.3　負荷検知

RSはトンネル作成時にUDPポート番号をエフェメラルポートの範囲内から割り当てる．しかし，トンネル構築指示を出すDCではそれぞれのRSにおけるエフェメラルポート範囲内のUDPポート番号残数を把握しておらず，使用可能なポート番号が枯渇しているRSにトンネル構築指示を出した場合トンネル構築処理に失敗してしまう．また，DCではログインしているNTM端末に対して仮想IPアドレスの割り当てやトンネル構築指示の送信などの処理を行うため，管理下にあるNTM端末台数の増加による通信負荷により処理遅延の発生が予測される．そこで提案システムでは，RSの割り当て可能なUDPポート番号の残数やDCが管理しているNTM端末の台数をZabbix上で監視できるようNTMobileおよびZabbixを拡張する．

図6にエフェメラルポート範囲内にある，RSが割り当て可能なUDPポート番号の残数を監視する手法の概要を示す．RSで利用可能なUDPポート番号残数はRSのサーバ内で持つリソース情報から取得する．一般的なLinuxシステムの場合，使用中のUDPポート情報およびエフェメラルポート範囲の設定情報が「proc」ディレクトリ内に格納されている[16]．これらの情報から，割り当て可能なUDPポート番号の残数を取得する監視プロセスをRSのプロセスと並列に処理されるように追加する．また，図7にDCの管理下にあるNTM端末台数を監視する手法の概要を示す．DCは，管理下にあるNTM端末について管理するデータベースをDC内部で持つ．このデータベースにクエリを送信しNTM端末台数を取得する機能をDCプロセス内に追加する．

上記より取得した各情報をZabbix上で監視するために，UserParameters [17]を用いる．UserParametersは，Zabbixで事前に定義されていない監視を行うために独自に定義した監視項目と監視情報を対応付けるキーの役割を持つ値である．これらの情報を監視する監視項目をUserParametersを用いて定義し，実装した追加機能が出力した情報をZabbix Agentを通じてZabbixサーバが回収し監視できるようにする．

以上により，Zabbix上で各RSで割り当て可能なUDPポート番号の残数および各DCで管理しているNTM端末台数を統合的に監視することが可能になる．

また，将来のNTMobileの新機能実装により，監視項目を新設する必要がある場合でも，UserParametersを利用することで，Zabbix上で監視を行うことも可能である．

4.　実装・評価

4.1　実装

提案システム動作確認および提案システムを用いた監視作業における所要時間を確認するために，NTMobileの監視に用いる追加機能をDCおよびRSに実装し，提案システムを構築した．なお，今回の実装にあたり，以下の点に配慮した．

• ・監視プロセスはNTMobileと並列して動作させるため，システムリソースの消費を最小限にするために軽量な並列処理が実装できるGo言語を用いて実装した．
• ・通信帯域に与える影響を抑えるために，障害に関わる重要度の高い項目であるエラーログ，エフェメラルポート使用率やNTM端末台数は取得間隔，それ以外の重要度の低い項目は取得するインターバルを長く設定した．
• ・各サーバから収集した情報から重要な情報の見落としを防止するために，Zabbixのカラー表示機能に対応するようにNTMobileのログに含まれるメッセージの重要度を見直した．

4.2　動作検証

ZabbixサーバはVirtualBoxを用いて仮想マシン^*1で構築した．また，監視対象となるDCおよびRSは，それぞれVirtualBoxを用いて起動した仮想マシン上で実行し，それぞれにZabbix Agentを導入した．なお，動作検証に使用した環境については表1に示すとおりである．

図8にZabbix上におけるNTMobileサーバ群の監視画面を示す．今回実装した監視項目について，Zabbixにより情報の取得および統合監視が行えることを確認した．ログの重要度に応じてカラー表示を適切に設定することにより，大量な監視情報の中から必要とする情報を順次に見つけることが可能になり，重要な監視情報の見落としによるヒューマンエラーの防止にもつながる．

4.3　監視作業時間

4.3.1　実験概要

本稿では提案手法の導入により，管理者の負担がどの程度軽減できるかを明らかにするために，NTMobileプロトコルの処理過程で異常が発生して端末間の通信が開始できない状況が発生したことを想定し，その原因を究明するまでに要する時間を計測した．管理者が手動で各種情報を収集・分析する手法（以後，従来手法）と提案手法の両方を使用して，それぞれの監視作業全体に要した時間を計測した．従来手法では，複数のNTMobileサーバに存在するログファイルを収集し，RSにおいてはメモリ上にキャッシュされているリレーテーブルの情報をダンプして解析する作業が必要になる．一方，提案手法ではZabbixサーバにアクセスし，統合管理されている情報を解析する作業を行った．

なお，これらの監視作業は，Linuxサーバの初歩的な運用スキルがあり，かつNTMobileに基づく通信の仕組みやプロトコル仕様を正しく理解していないと実施できないため，筆者が所属する研究室においてNTMobileの開発に従事している3名に被験者となってもらった．また，今回はNTMobile環境の最小構成であるDCおよびRSを1台ずつ稼働している状況で実験を行った．

4.3.2　実験結果

表2に両手法における作業概要とそれらの平均所要時間を示す．監視準備に関する作業は提案手法のほうが若干遅いが，それ以外の各作業時間は従来手法より提案手法のほうが短時間で完了していることが確認できる．リレーテーブルの調査については，従来手法ではメモリダンプ処理とダンプファイルの解析を行う必要があり，作業スキルが求められる．被験者はこれらの作業方法を熟知しているが，平均160秒程度を要していた．これに対して提案手法では，Webページに表示された情報を閲覧するだけで解析できるようになったため，約17秒まで短縮化することに成功した．

4.3.3　考察

メモリダンプは当該サーバに搭載されているメモリ全体の内容をファイルに出力する．従って，サーバのメモリ容量に準じて出力に要する時間が増減する．今回，RSのメモリ容量は2 GBであるため，実運用時はさらに大容量のメモリを搭載していることを想定すると，さらに作業時間が増加する．一方，提案手法はRSプロセスからリレーテーブルの情報を直接取得するように拡張したため，メモリダンプは必要なく，サーバの搭載メモリ容量に関係なく短時間で情報の収集・可視化が可能である．

また，今回の評価実験では最小構成の環境で実施したため，被験者はどのNTMobileサーバにログインすればよいのかを特定する必要がなかった．大規模環境で運用する場合，従来手法では障害に関与しているNTM端末の情報を管理しているDCを特定する必要がある．また，NTM端末が通信の中継に利用するRSはDCが動的に決定するため，特定したDCに保存されているログを解析しなければならない．これらの作業時間が表2の所要時間に加わることになる．一方，提案手法はすべてのDCのログ情報を一元管理できているため，これらの作業時間は大幅に削減できる．そのため，規模が大きくなるほど，従来手法と提案手法の差が大きくなることが分かる．

4.4　大規模運用時における必要スペック

NTMobileサーバ群をZabbixで統合管理する場合，3.4節に示した障害検知および負荷検知に関する情報収集は一般的なサーバの監視と同等と挙動であり，NTMobileの使用に伴って負荷が増加することはない．メモリ上にキャッシュされている内部情報の可視化については，独自の監視プロセスを稼働させる必要はあるが，これはZabbix Agentが稼働するNTMobileサーバ側で動作する．そのため，ZabbixサーバはZabbix Agentから送信されたHTTP GETメッセージを受信して表示するだけであり，この処理もNTMobile利用時に発生する固有の処理ではなく，一般的なZabbixサーバと同じ挙動になる．

以上を踏まえると，NTMobileを大規模で運用する場合も，同じ規模の一般的なサーバを監視する場合と同等の負荷がZabbixサーバに発生することが推測される．文献[18]に表3のように監視対象の規模に応じたZabbixサーバのハードウェア要件が示されており，NTMobileサーバ群の規模に応じてZabbixサーバのハードウェア仕様を決定することができると考えられる．

5.　残された課題と今後の展望

NTMobileは現在開発中の技術であり，大規模環境下における実運用および評価を行う段階には至っていない．今後は，大規模環境を想定して大量の監視情報が発生した際のNTMobileサーバ群および統合監視システムに発生するハードウェアリソースの負荷や，管理者の負担軽減効果を評価する必要がある．また，監視作業時間に関する定量評価では被験者数を増員したり，サーバ管理技能やNTMobile運用の習熟度に応じて，提案手法の改善効果をさらに詳細に分析する必要がある．

本稿では各サーバに点在しているNTMobileの挙動にかかわる情報をZabbixを用いて一箇所で統合管理できる仕組みについて示した．次のステップとして，提案手法により集積された様々な情報から動的に異常を検出する仕組みを追加することを予定している．これにより，NTMobileのプロトコル仕様を熟知していない管理者であっても，どの処理過程において，何が原因で通信が失敗しているのかを即座に判断できるようになると考えられる．

6.　おわりに

本稿では，ネットワーク機器の統合監視システムであるZabbixを活用して，NTMobileサーバ群を高効率かつ低負担に統合管理するシステムについて提案した．また，Zabbixが標準的にサポートしていないNTMobileプロセスがメモリ上にキャッシュしている内部情報を可視化する仕組みを示し，動作検証により実現できることを示した．評価実験を行った結果，提案システムを導入することによりNTMobileサーバ群の監視に関わる作業工程や所要時間を短縮できることを確認した．今回提案した独自のサーバプロセスで管理する情報をZabbixで統合管理する手法は，NTMobileだけではなく，既存サービスや研究開発中の様々なプロジェクトにも応用可能であり，システム運用時の監視以外にも開発補助ツールとして活用することも可能である．