1.　はじめに

IoT機器の普及や新たなWebサービスの発展に伴いインターネットの利便性が向上している一方で，サイバー攻撃の脅威は年々増大している．国立研究開発法人情報通信研究機構（NICT）のNICTER観測レポート2024では大規模サイバー攻撃観測網（NICTER）のダークネット観測で確認された2024年の総観測パケット数は2015年と比べて10倍以上に増加し，総観測パケット数が年々増加傾向にあることが報告されている[12]．このような状況下においてシステムを保護するネットワークセキュリティ技術の重要性が高まっている．

ネットワークセキュリティ技術の1つとして侵入検知システム（Intrusion Detection System, IDS）がある．IDSはネットワーク上の通信をリアルタイムで監視し，異常な通信を検知した場合に管理者に通知するシステムである．IDSは，事前に登録した攻撃パターンとの一致を検知するシグネチャ型と，機械学習などを用いて異常な挙動を検知する異常挙動検知型に大別される．なかでも異常挙動検知型IDSは未知の攻撃を検知できる可能性があることから近年活発に研究が行われている．

また，IDSの中でも通信データの統計情報（本稿では特徴量と呼ぶ）を使用して通信の判定を行うIDSはフローベースIDSと呼ばれる．フローベースIDSは一部のDoS攻撃など正当なパケットを用いて行う攻撃の検知が可能という特徴を持つ．フローベースIDSではパケットごとではなくフローごとに特徴量が計算され，その特徴量をもとに検知を行う．フローとは送信元・宛先IPアドレス，送信元・宛先ポート番号，プロトコルの5タプルが一致する通信として定義され，通信の双方向性から送信元と宛先が逆転した組み合わせも同一のフローとして扱われる．この特徴量計算には専用のツール（本稿では特徴量抽出機と呼ぶ）が必要となるが，既存の特徴量抽出機には大規模データに対して適用した際に処理が非常に低速になることや動作がクラッシュしてプログラムが停止してしまうというような課題が存在する[3]．

そこで本研究ではそれらの課題を解決するため，2025年に公開された最新の特徴量抽出機であるNTLFlowLyzer [9]を基盤とし，高速化と堅牢性を実現した新たなフレームワークであるATLFlowLyzerを提案する．ATLFlowLyzerは特徴量計算のGPU上での実行やパケットに対するフロー検索処理のマルチプロセス化により高速性と堅牢性の両立を図る．また，ATLFlowLyzerの有効性を検証するため，パケット数の異なる複数のpcapファイルを用いた評価実験を行う．さらに，本ツールは研究コミュニティでの利用を目的としてオープンソースで公開する[4]．

以下に本研究の主要な貢献を示す．

• ・既存の特徴量抽出機が抱える処理速度と安定性の課題を解決する新たなフレームワークであるATLFlowLyzerの提案と実装．
• ・複数種類のpcapファイルを用いた評価実験によるATLFlowLyzerの高速性と堅牢性の定量的評価．
• ・研究コミュニティでの利用を目的としたATLFlowLyzerの公開．

2.　既存研究

通信トラフィックからフロー情報を収集するための代表的なプロトコルとしてNetFlowが挙げられる．NetFlowは1996年にCisco社によって開発され，nProbe [2]など多くのツールによって使用されている．しかし，NetFlowはトラフィックを監視するために使用されることを前提としたものであり，取得された情報が異常検知に役立つかどうかは定かではない．実際，データセットの特徴量をNetFlowを用いた新たな特徴量に変換した研究は存在しているものの，元の特徴量に比べるとIDSの性能が低下することが報告されている[8]．NetFlowの他にArgusやZeek（旧Bro）などのツールも広く使用されているが，これらもネットワーク監視用に設計されたものであり，元々は機械学習に用いるデータを生成するためのツールではない．

それらに対しCICFlowMeter [10]はCanadian Institute of Cybersecurityによって作成された，異常検知に使用するためのデータを収集するオープンソースツールである．84種類もの特徴量を抽出可能であり，IDSの研究に広く用いられるCIC-IDS2017やCIC-IDS2018など多くのデータセットがCICFlowMeterによって作成された．その結果，CICFlowMeterが生成する特徴量形式は機械学習ベースのIDSの研究におけるデファクトスタンダードとなっており，この形式に準拠したデータを生成することは研究の比較可能性や再現性の観点から価値が高い．しかし，CICFlowMeterにはTCP通信におけるフロー終了の論理エラーや大規模データの処理時にクラッシュしてしまうなどの課題が存在している[3]．

CICFlowMeterの抱える問題点を解決しつつ，その有用な特徴量設計の思想を継承・発展させ，より効率的に抽出するために2025年にNTLFlowLyzer [9]が開発された．このツールは可読性の観点からPythonによって作成され，特徴量計算部分を複数プロセスで分散実行するなど効率的な設計となっている．抽出される特徴量数は公開当初は114個だったが，バージョン0.2.0では340個以上の特徴量を抽出可能になっており，これはCICFlowMeterの4倍以上になっている．

しかし，NTLFlowLyzerのアーキテクチャは特徴量計算こそ複数プロセスで実行されるものの，各パケットを対応するフローに割り当てるフロー処理部分は単一プロセスで実行される．この設計は，DDoS攻撃など特にフロー数が爆発的に増加するような大規模データにおいて，フロー処理部分が深刻なボトルネックとなり，システム全体の性能を著しく低下させる可能性が懸念される．既存研究ではNTLFlowLyzerの大規模データに対する詳細な性能評価は十分に行われていない．

そこで本研究では，まず予備実験として，NTLFlowLyzerを代表的な大規模データセットに適用し，その性能限界とボトルネック部分を明らかにする．その結果を踏まえ，ボトルネックを解消するための新たなアーキテクチャを持つATLFlowLyzerを提案する．

3.　予備実験

本章では，NTLFlowLyzerを大規模データに適用した際の性能限界を明らかにし，そのボトルネック箇所を特定するための予備実験について述べる．評価にはCICIoT2023データセット[6]のDDoS RSTFINFloodデータを使用する．CICIoT2023データセットには複数のDDoS RSTFINFloodファイルが存在するが，そのうちDDoS-RSTFINFlood.pcapを選択した．このファイルには16時間程度の攻撃パケットが記録されているが，多くのパケットが集中した前半部分と少量のパケットが存在する後半部分に分かれており，その間に15時間程度の空白部分が存在する．実験では28分1秒分，24,658,301パケットが含まれている前半部分のデータのみを使用する．

NTLFlowLyzerを始めとする特徴量抽出機の使用用途は主に（1）研究者がIDSの性能検証を行うためにメモリ容量などのスペックに制限のある自身のPC等を用いてフロー抽出を行う，あるいは（2）実環境において運用されているサーバなどをIDSを用いて保護するためにスペックの高い計算機を用いてフロー抽出を行う，という2種類に分類される．そのため，特徴量抽出機はスペックの異なる両方の環境において正常かつ高速に動作することが求められる．本稿では両環境での動作検証を行うための実験環境として，個人の研究者が研究用に使用する状況を想定した環境Aと組織が実際のトラフィックに適用するような状況を想定したサーバレベルの環境Bを用意した．各環境の主要なスペックを表1に示す．

NTLFlowLyzerを両環境においてそれぞれ168時間実行したが，いずれもpcapファイル全体の処理は完了せず，特に処理後半において動作が著しく低速になる現象が観測された．内部処理時間を計測した結果，パケットに対するフロー検索やフロー状態管理を行うフロー処理部分の負荷が実行時間の大半を占めており，この箇所がボトルネックであることが特定された．図1に横軸を処理済みパケット数，縦軸を1パケットあたりのフロー処理時間（対数スケール）として，その推移を紫色の線で示す．両環境とも約30万パケットまでは1パケットあたり10 μs程度で推移しているが，その後急激に増加し，最終的に1パケットあたり0.5秒近くに達した．168時間の実行で処理できたパケット数は環境Aで約240万（全パケットの約9.7%），環境Bで約150万（同約6.1%）に留まった．

この性能低下の原因はNTLFlowLyzerのフロー処理ロジックにおいて，進行中のフロー数が閾値を超えると新たなパケットを読み込むごとにすべての進行中フローに対して終了条件の確認を行う，計算コストの高い処理が存在するためである．この処理がボトルネックであることを検証するため，終了条件の確認を1,000パケットごとに行うように修正を加え，再度同様の実験を行った．実験結果を図1に緑色の線で示す．図の示すとおり，修正後のNTLFlowLyzerは1パケットあたりの処理時間が1 ms程度と修正前に比べ大幅に改善された．その結果，環境Bでは13時間程度で全パケットの処理を完了できた．しかし，CPUメモリ容量の小さい環境Aでは約2,100万パケット（全体の約85%）まで処理した後Out of Memory（OOM）エラーが発生しプログラムがクラッシュした．

以上の予備実験から，NTLFlowLyzerの主要なボトルネックはフロー処理部分にあることが確認された．また，単純なロジック修正により処理速度は大幅に改善するものの，処理時間は約13時間と，ファイルに含まれる時間内（28分1秒）での処理には程遠いことが示された．さらに修正後であってもCPUメモリが限られた環境下ではOOMエラーによりクラッシュする可能性があり，堅牢性にも課題が残ることが明らかとなった．次章ではフロー処理のボトルネック解消と堅牢性の向上を目的として設計したATLFlowLyzerについて述べる．

4.　提案手法

予備実験の結果を参考に，NTLFlowLyzerを改良した特徴量抽出機であるATLFlowLyzerの設計を行う．図2にATLFlowLyzerの処理フローを示す．ATLFlowLyzerは（1）パケット解析ブロック（2）フロー処理ブロック（3）特徴量計算ブロック（4）出力ブロックの4つのメインブロックから構成される．それぞれについて詳しく説明を行う．

4.1　パケット解析ブロック

このブロックの主な役割は入力pcapファイルからパケット情報を効率的に抽出し，後段のフロー処理ブロックでの負荷を均等に分散するための準備を行うことである．情報抽出ではIPアドレスやプロトコル，タイムスタンプ，TCPフラグなどのヘッダ情報とパケット長やペイロードサイズなど特徴量計算で必要になる情報を抽出する．次に，抽出した送信元・宛先IPアドレス，送信元・宛先ポート番号，プロトコルを結合し，その値のハッシュ値を計算する．このハッシュ値計算の目的はパケットのフロー検索等を行う各フロー処理プロセスに均等にパケットを割り振ることである．フロー処理ブロックにn個のプロセスが存在する場合，パケットから計算されたハッシュ値をhashとすると\[k = hash \ \% \ n\](1)

に従って決定されるk番目のプロセス（フロー処理プロセスk）にこのパケットを割り振る．ここで同じフローに属するパケットは同じ処理プロセスにて処理される必要がある．そのため，IPアドレス等を結合する際にそれらの値の大小によって結合する順番を定め，同一フローに属するパケットから計算されるハッシュ値が等しくなるように設計している．また，ハッシュ値の計算においては高速な計算が可能であるxxHashを使用する．

プロセス間のデータ共有にはPython標準のキューを用いる．この共有処理を含むパケット解析ブロック全体の性能向上のため，ATLFlowLyzerではCython [1]を用いてパケット解析ブロックの主要部分をC言語コードにコンパイルしている．更にキューで送受信されるデータにはC言語の構造体を用いることでシリアライズ・デシリアライズのオーバーヘッドを削減する設計とした．

4.2　フロー処理ブロック

このブロックの主な役割はパケット解析ブロックから送られてきたパケット情報に対し，そのパケットの属するフローの特定，フローが存在しない場合のフロー作成，そして後段の特徴量計算ブロックにおいて必要となるフロー情報の用意を行うことである．各プロセスはパケット解析ブロックから送られてきたパケット情報の構造体に記録されているIPアドレスやプロトコル等からそのパケットの属するフローを特定する．もしフローが存在する場合にはそのフローが終了しているかどうかを判断する．フローの終了判定は（1）フローの継続時間が閾値以上（2）1つ前のパケットが送られてから一定時間経過（3）クライアントとサーバ両方からFINパケットが送信されている（4）RSTパケットが存在，の4条件で行われる．フローが継続中の場合，フロー内におけるパケットの向き，すなわちクライアントとサーバ間のどちらの方に送られた通信であるかを判断した後にフローにパケット情報を追加し，フロー情報を更新する．フローの更新の際にはパケット情報を単純に追加するだけでなく，フロー内の他のパケットのタイムスタンプの値を使用して新しいパケットがバルク通信であるか，通信頻度が活発な状態であるかなどのフロー全体としての特徴も更新・保存する．フローが終了していた場合やパケットが属するフローが存在しない場合は新たにフローを作成する．

このようにフローに関する情報を管理し，終了したフロー数が一定数に達すると，終了したフローの情報を後段の特徴量計算ブロックにキューを用いて送信する．これらのフロー処理は複数のプロセスによって並列に実行される．そのため一度に大量のフローが終了するような場面では大量のフロー情報が特徴量計算ブロックに送られ，その結果としてCPUメモリ使用量が増加しプログラムがクラッシュしてしまう可能性がある．それを防ぐためにパケット解析ブロックとフロー処理ブロックの間のキューとフロー処理ブロックと特徴量計算ブロックの間のキューにはそれぞれ変更可能な最大サイズを設定可能にしている．キュー内に存在するデータが最大サイズに達した場合に新たな入力をブロックし，一定時間待機させることで動作の安定性を保つことができる設計となっている．

4.3　特徴量計算ブロックと出力ブロック

これらのブロックの主な役割はフロー処理ブロックから送られてきたフロー情報からGPUを用いて特徴量を抽出し，CSVファイル形式で記録することである．ATLFlowLyzerではGPU上での表形式計算に優れるcudfライブラリ[7]を使用する．cudfは表形式計算で広く用いられるpandas [5]のAPIをサポートしつつ，計算の実行をGPU上で行うことで計算を高速化できるライブラリである．特徴量計算ブロックではGPUのメモリエラーを防ぐために一度に処理される最大処理フロー数を自由に設定可能にしており，もし最大処理フロー数を超えるフロー数を処理する場合には分割して実行することでGPUメモリエラーを防ぐ．ここで計算される特徴量はNTLFlowLyzerのものと同等であり，計算された特徴量はキューを用いて出力ブロックに送信される．

また，GPUが使用できない環境を考慮して，polars [11]を用いたCPU上での特徴量計算もオプションとして選択可能となっている．polarsはRustで実装されたライブラリであり，pandas等と比べて高速に実行可能であるという特徴を持つ．CPU上での実行とGPU上での実行は設定ファイルによって切り替えることが可能である．

最後に特徴量計算ブロックで計算された特徴量はキューで出力ブロックに送られた後CSVファイルとして保存される．ATLFlowLyzerでは高速な書き込みを行うためにpolarsを使用する．

4.4　NTLFlowLyzerとの主な違い

NTLFlowLyzerとATLFlowLyzerの主な違いを表2に示す．

大きな違いとしてNTLFlowLyzerにおいては特徴量計算ブロックを複数プロセスで分散実行する代わりにフロー処理ブロックを単一プロセスで行っている一方でATLFlowLyzerにおいては特徴量計算ブロックを単一プロセスで実行する代わりにフロー処理ブロックを複数プロセスで分散実行している点が挙げられる．これは予備実験においてフロー処理がボトルネックとなっていたことからこの処理を複数プロセスで実行することで動作の安定化および高速化を目指すとともに，特徴量計算をCPUではなくGPU上で行うことで計算の高速化だけでなくCPU上のメモリ使用量やCPU使用率を下げることを目的としている．また，NTLFlowLyzerはプロセス間のデータ共有を共有メモリを用いて行うのに対してATLFlowLyzerではキューを用いて行う．これはATLFlowLyzerの開発初期段階において共有メモリでのデータ共有時に発生する競合状態による性能低下が確認されたこと，そしてキューのほうが最大サイズの制御などが行いやすくプログラムの安定性向上に寄与すると判断したためである．また，tcpdump等のパケットキャプチャプロセスを別途実行する必要はあるが，ATLFlowLyzerは特徴量抽出をオンライン上でリアルタイムに実行可能であることもNTLFlowLyzerにはなかった特徴となっている．

5.　本実験

5.1　実験設定

実験に使用するデータとしてはCICIoT2023データセットから4種類のpcapファイルを選択した．CICIoT2023データセットには33種類の異なる攻撃データが含まれている．その中には10,000程度のパケットしか含まれない小規模なデータからDDoS攻撃などの大規模なデータまで揃っており，様々な規模のデータに対して実験が行えるという点で最適であると判断したため今回の実験に採用した．使用したデータの概要を表3に示す．パケット時間の列はpcapファイルに含まれる最後のパケットと最初のパケットのタイムスタンプの差を表している．DDoS RSTFINFloodに関しては予備実験と同様のデータを使用した．

リアルタイムで動作する特徴量抽出機は表3で表されるパケット時間よりも短い時間でpcapファイルを処理する必要がある．パケット時間内に処理することができない場合，入力pcapファイルに対する結果が即座に得られず，結果として攻撃検知が遅れてしまう可能性がある．そのためパケット時間内にpcapファイルを処理できることが特徴量抽出機に求められる要件であると言える．

また，実験において使用したパラメータのうち，ATLFlowLyzerの実行速度やGPUあるいはCPUメモリ使用量に関連するパラメータを表4に示す．なお，パケットキューとはパケット解析ブロックからフロー処理ブロックへパケットの情報を送るためのキューである．一方，フローキューとはフロー処理ブロックから特徴量計算ブロックへフロー情報を送るためのキューである．パケットキューはパケット単位で格納されるため設定値はパケット数と等価であるが，フローキューは複数のフロー情報をまとめたバッチ単位で格納されるため，設定値はフロー数ではなくバッチ数を表すことに注意する必要がある．

実験ではNTLFlowLyzerとATLFlowLyzerの2つのツールを比較する．NTLFlowLyzerに関しては小規模データ等に対しても悪影響が確認されなかったことから，予備実験で示したフロー処理部分を改善したものを使用する．また，ATLFlowLyzerはGPUを用いて特徴量計算を行った場合の結果だけでなく，参考としてCPUを用いた場合の結果も同時に示す．各ツールの性能比較として（1）フロー処理時間，（2）特徴量計算にかかる時間，（3）全体の実行時間，（4）CPUメモリ使用量，の4点を計測する．フロー処理時間はフロー処理ブロックでの処理にかかる時間を1パケットごとに計測する．フロー処理時間とCPUメモリ使用量に関しては特に実行が困難であるDDoS RSTFINFloodデータに対する結果を示す．NTLFlowLyzerとATLFlowLyzerはそれぞれ並列実行されるプロセス数が合計15となるように実行した．プロセス数を15に設定した理由は両ツールにおいて，それ以上プロセス数を追加しても実行時間に大きな変化がみられなかったためである．

5.2　フロー処理時間の比較

はじめに，本実験でのDDoS RSTFINFloodデータを用いたフロー処理時間の推移を図3に示す．横軸は処理したパケット数，縦軸は1パケットあたりの処理時間を表しており，NTLFlowLyzerの結果は予備実験と同じものを使用している．まず，環境BにおいてはNTLFlowLyzerが1パケットあたり1,000 μs程度で推移しているのに対し，ATLFlowLyzerはGPU版とCPU版の両方で20 μs程度で推移している．それに対し，環境Aでは予備実験でも示したとおりNTLFlowLyzerがOOMエラーを起こしプログラムがクラッシュした一方で，ATLFlowLyzerはCPU版とGPU版の両方で処理時間が振動しながらではあるが処理を完了した．環境Aにおいて処理時間の振動がみられた原因としてはOOMエラーを防ぐために最大処理フロー数やキューの最大サイズを小さく設定していることが挙げられる．これにより，キューの最大サイズに達した際に新たな入力を一時的にブロックする流量制御が働き，フロー処理動作が制限されることで処理時間が不安定化したと考えられる．また，特徴量計算が高速に実行されるGPU版と比べ，特徴量計算が低速であるCPU版では振動の振幅が大きく，さらにCPUメモリ容量が十分でキューの最大サイズなどに大きな値を設定可能な環境Bでは処理時間は比較的一定の値で推移していることからも，処理時間の不安定化が流量制御の介入に起因することが確認できる．ただし，処理時間の不安定性が観測された一方で，ATLFlowLyzerはCPUへの負荷が大きいCPU版であっても処理を完了した．これは最大処理フロー数などの値を適切に設定することにより，処理速度の安定性と引き換えにプログラムのクラッシュを回避できるという実用的なプラクティスを示している．

また，両環境において1,250万パケット周辺でNTLFlowLyzerの処理時間が一度10 μs程度になった後に再度1,000 μs程度に戻るという現象が観測された．これは使用データであるDDoS RSTFINFloodにおいて，1,250万パケット前後に6分間程度の通信の空白期間が存在しており，この箇所において大量のフローが終了判定を受けて特徴量計算に回された結果，残存するフロー数が少なくなり，フロー処理時間が短くなったためと考えられる．

最後に，フロー処理にかかった時間の合計としてはNTLFlowLyzerが環境Aで約4時間35分（エラー発生まで），環境Bで約9時間31分であったのに対し，GPU版のATLFlowLyzerは環境Aで約1時間17分，環境Bで約8分47秒，CPU版では環境Aで約12時間1分，環境Bで約10分36秒となった．環境AでのATLFlowLyzerのフロー処理時間の合計はパケット時間である28分1秒を超過しているが，実際には複数のプロセスを用いて分散処理を行っているため，各プロセスの処理時間の単純な合計と基準となるパケット時間やNTLFlowLyzerとの単純な比較はできない点に留意する必要がある．

5.3　特徴量計算時間の比較

次に図4に各pcapファイルに対する特徴量計算にかかる時間を示す．ただし，環境AにおけるDDoS RSTFINFloodデータに対するNTLFlowLyzerによる処理がOOMエラーによって完了しなかったため，値を示していない．図の示すとおり，両環境およびすべてのデータセットにおいてATLFlowLyzerはCPU版とGPU版の両方でNTLFlowLyzerと比べて特徴量計算にかかる時間が短いことが分かる．この傾向は特に大規模データになるほど顕著であり，環境BでのDDoS RSTFINFloodデータにおける特徴量計算時間はNTLFlowLyzerが約62時間12分であったのに対し，GPU版ATLFlowLyzerは約15分50秒であり，約235倍の差が存在する．ただし，NTLFlowLyzerは複数プロセスで特徴量計算を分散実行しているのに対し，ATLFlowLyzerは単一プロセスで実行しているため，こちらもパケット処理時間と同様に単純な比較はできない点に留意する必要がある．

また，フロー数が少ないUploading AttackやSQL InjectionではCPU版ATLFlowLyzerがGPU版ATLFlowLyzerより高速に動作した．これは処理するフロー数が少ない場合，CPUでも十分高速に特徴量計算が可能であり，さらにGPU版ではGPUへの転送コストがボトルネックとなっている可能性が挙げられる．しかし，フロー数が多くなるとGPU上での計算がCPU上での計算に比べ圧倒的に高速となり，特に環境BではGPU版はCPU版と比較して約28倍高速となった．

また，フロー処理時間とは異なり，特徴量計算では常に環境Aが環境Bと比べて高速に処理を完了した．これはCPUの1コアあたりの処理速度が環境Aのほうが優れていることが要因であると考えられる．表1に示すとおり，環境AのCPUのクロック周波数は5.1 GHzであるのに対し，環境BのCPUのクロック周波数は2.4 GHzと低い値となっている．特徴量計算では加算等の単純な演算だけでなく，表の結合などのCPUのシングルスレッド性能に依存する制御処理が多く存在する．そのため，並列演算能力自体は環境Bのほうが高速であるものの，制御部分がボトルネックとなることで全体の実行時間としては環境Aのほうが高速になった可能性が挙げられる．ただし，特に環境BにおいてGPU版がCPU版に対して圧倒的に処理時間を短縮したことから，GPUを用いた特徴量計算の高速化という本アプローチの有効性が確認できる．

5.4　全体実行時間の比較

次に図5に各pcapファイルに対する全体の実行時間の比較を示す．ただし，環境AにおけるDDoS RSTFINFloodデータに対するNTLFlowLyzerによる処理がOOMエラーによって完了しなかったため，値を示していない．全体の傾向としては特徴量計算時間と同様にNTLFlowLyzerに比べATLFlowLyzerが一貫して短くなり，また，フロー数が少ない場合はCPU版のほうが高速であるが，フロー数が増えるにつれGPU版のほうが高速となった．特に大規模データに対してはツール間の差が顕著であり，環境BでのDDoS RSTFINFloodデータにおける全体の実行時間はNTLFlowLyzerが約13時間24分であったのに対し，GPU版ATLFlowLyzerは約24分となり，約33倍の高速化を達成している．また，環境Aのほうが環境Bよりも一貫して高速である傾向がみられた．この傾向について，フロー処理時間の観点ではCPUメモリ容量の限られる環境Aが低速であったのに対し，特徴量計算の観点ではCPUのシングルスレッド性能に優れる環境Aが高速となった結果を踏まえると，ATLFlowLyzerにおいて全体の実行時間は特徴量計算による影響が支配的である可能性が示唆されている．5.3節で述べたとおり，特徴量計算におけるデータ制御はGPUの演算能力以上にCPUの性能に依存している．すなわち，ATLFlowLyzerをより高速化させるためには，より高性能なGPUを使用することよりも，ボトルネックとなるCPUのシングルスレッド性能を向上させることが有効であると考えられる．また，同時にフロー処理時間を安定させるために十分なCPUメモリ容量を確保することも，システム全体の性能向上に重要であると考えられる．

また，実験設定で述べたとおり，特徴量抽出機はリアルタイムで動作する場合パケット時間内にpcapファイルを処理する必要がある．NTLFlowLyzerとATLFlowLyzerの両方において小規模～中規模程度のデータであるUploading AttackやSQL Injection，Vulnerability Scanデータに対してはパケット時間内に処理を完了しているが，DDoS RSTFINFloodデータに対してNTLFlowLyzerはパケット時間内に処理を完了できなかった．それに対し，GPU版ATLFlowLyzerは両方の環境においてOOMエラーを起こすことなくパケット時間内に処理を完了した．これにより，GPU版ATLFlowLyzerはリアルタイムでの特徴量抽出が可能であることが実証された．

5.5　CPUメモリ使用量の比較

次に図6にDDoS RSTFINFloodデータにおけるCPUメモリ使用量の推移を示す．横軸は進捗率を表し，縦軸がCPUメモリ使用量を示している．なお，両環境で縦軸のスケールが異なることに留意する必要がある．環境AではCPU版ATLFlowLyzerが25 GiB～30 GiBの間で安定して推移し，GPU版ATLFlowLyzerも25 GiB程度で安定して動作した一方，NTLFlowLyzerは進捗率60%まではATLFlowLyzerより少ないCPUメモリ使用量であったが，それ以降は不安定となり，最終的にはNTLFlowLyzerのほうがCPUメモリ使用量が多くなった．NTLFlowLyzerは最大で30.76 GiBのCPUメモリを使用してOOMエラーを起こしたのに対し，ATLFlowLyzerはCPU版とGPU版の両方でそれぞれ最大28.69 GiBと27.62 GiBとなり，30 GiB以下で安定して動作した．

環境BではCPU版ATLFlowLyzerのCPUメモリ使用量が圧倒的に多くなり，次にNTLFlowLyzer，最も少なかったのがGPU版ATLFlowLyzerという結果になった．CPU版ATLFlowLyzerのCPUメモリ使用量が圧倒的に多くなった理由はほぼ常にCPU上で大量のフローに対する特徴量計算を行っているためだと考えられる．複数のプロセスに分散することで一度に生成される特徴量が少量であるNTLFlowLyzerに対し，CPU版ATLFlowLyzerは1つのプロセスで一度に大量の特徴量を生成するため．CPUメモリ使用量が多くなったと考えられる．しかし，これは環境BのCPUメモリ容量が十分に大きいことから最大処理フロー数などの値を大きく設定したことによる影響であり，環境Aと同様の値に設定するとCPUメモリ使用量を低く抑えることは可能である．また，GPU版ATLFlowLyzerは最もCPUメモリを使用する特徴量計算部分をGPU上で実行するためCPUメモリ使用量が他に比べて低くなったと考えられる．

これらの結果から，実行速度だけでなく堅牢性の観点でもATLFlowLyzerはNTLFlowLyzerを上回ることが示された．また，実運用環境を想定した十分なCPUメモリ容量が使用できる環境だけでなく，個人の研究者が使用するような環境下でも基準となるパケット時間を下回りながら大規模データに対して動作を完了したことは本手法の実用性の高さを裏付けるものである．特に，ATLFlowLyzerが示した高い堅牢性は，キューの最大サイズ制御や，一度に処理する最大処理フロー数の制限といった，CPUメモリ使用量を能動的に制御する設計に起因している．実際，開発初期段階においてこれらの流量制御機構を実装していなかった際は，各処理ブロック間のスループットの差によってキュー内にデータが滞留し，大規模データ処理時にメモリ枯渇によるクラッシュが頻発していたが，これらの機構を導入したことで動作が劇的に安定した．このプラクティスからリソースが制限された環境で大規模データを扱うシステムにおいて，各処理ブロック間のデータ流量を適切に制御する機構の実装がシステム全体の堅牢性を担保するうえで極めて重要であるという知見が得られた．

5.6　GPUに関する感度分析

最後にGPU版ATLFlowLyzerの処理速度および堅牢性に大きな影響を及ぼすパラメータである最大処理フロー数に関する感度分析を行う．具体的には広い範囲のパラメータで検証を行うことのできる環境Bにおいて，DDoS RSTFINFloodデータを使用し，最大処理フロー数を5万から300万の範囲で5万ずつ変化させながらGPU使用率の最大値・平均値およびGPUメモリ使用量の最大値・平均値，そして実行時間の推移を計測した．ただし，実験条件を揃えるため，本実験と同じ最大処理フロー数（150万）を使用する場合も新たに実験を行った．そのため，本実験とは全体の実行時間の結果が異なることに留意する必要がある．それらの結果を図7に示す．

まずGPU使用率に関して，最大値は最大処理フロー数を増やすほどに大きくなる傾向にあったのに対し，平均値は30万で最大値に達した後減少する傾向にあった．これは，最大処理フロー数を大きくするほどGPUでのバッチ処理効率が向上し，特徴量計算が短時間で完了するようになるため，結果として全実行時間に対するGPUの稼働時間割合が低下したためであると考えられる．GPU使用率の最大値が初めて100%となったのは最大処理フロー数が135万のときであった．しかし，この値はGPUやCPUなどの性能に大きく依存しており，他環境で同様の値が得られるわけではない．たとえば，環境Aでは本実験と同様最大処理フロー数を40万に設定した場合のGPU使用率の最大値は98%で平均値が22.33%となり，環境Bの値を大きく上回った．そのため，GPUのメモリ容量が許容する範囲で最大処理フロー数にある程度大きな値を設定すればGPU使用率の値は向上させられると考えられる．

次にGPUメモリ使用量に関して，最大GPUメモリ使用量および平均GPUメモリ使用量と，最大処理フロー数との間にはそれぞれ線形関係がみられた．なお，最大処理フロー数を40万とした環境Aでの実測値は最大使用量が6,323 MiB，平均が1,807 MiBと環境Bにおける値と同程度となった．実運用においてOOMエラーを未然に防ぐためには，設定した最大処理フロー数から最大GPUメモリ使用量を事前に予測することが極めて重要となる．そこで，最大使用量に対して線形回帰分析を行った結果，最大使用量をy（MiB），最大処理フロー数をxとするとy≈0.0098x＋3017（R²≈0.96）という関係式が得られた．この式は最大処理フロー数を1万増やすごとに最大GPUメモリ使用量が約98 MiB増加することを示している．以上の回帰分析の結果に基づくと，実行環境におけるGPUメモリ容量M（MiB）に対し，OOMエラーが発生する境界値となる最大処理フロー数x_limitは，x_limit≈$\frac{M - 3017}{0.0098}$≈100（M－3000）と推定できる．なお，本式はDDoS攻撃のように「フローあたりのパケット数は少ないがフロー数が爆発的に増加する」という，OOMエラーを誘発しやすい実運用上で最も高負荷となるケースの観測に基づいている．そのため，ここから導出された境界値は，システムを保護するための安全側のリソース設計指標として十分に妥当であると考えられる．

最後に実行時間に関しては，最大処理フロー数を増加させると短縮される傾向にあった．特に5万フローの設定では，GPUの演算能力を十分に活用できないうえ，頻繁なデータ転送によるオーバーヘッドが大きく，1時間以上の処理時間を要した．また，100万フロー前後からは性能の上昇が緩やかとなり，それ以降は大きな変化がみられなかった．すなわち，必ずしも限界値付近まで最大処理フロー数を高めなくとも十分な性能が発揮可能であることが示された．そのため，実際にGPU版ATLFlowLyzerを運用する場合には，実運用上最も回避するべき事象であるOOMエラーによる動作停止を防ぐため，回帰式から求められた境界値x_limitの50%程度の値を設定することが推奨される．

5.7　得られたプラクティス

本実験および開発プロセスを通じて得られた1つ目の重要なプラクティスは，大規模データを扱うシステムにおいては，非同期パイプラインにおけるブロック間のスループット差に起因するデータ滞留を防ぐため，各処理ブロック間のデータ流量を制御する機構の実装が，システム全体の堅牢性を担保するうえで不可欠であるという点である．開発初期では環境Aでクラッシュが頻発していたが，キューサイズや最大処理フロー数の制限といった流量制御の導入により，リソース制約の厳しい環境AでもOOMエラーを回避し実行可能となった．このことから，実用的なシステム構築においては，処理速度の安定性を多少犠牲にしてでも，流量制御によってリソース消費の上限を担保する設計が優先されるべきという知見が得られた．

さらに，本実験を通じて得られた最も重要な知見は，性能ボトルネックは特徴量計算だけではなくパケット検索やフロー管理などのデータハンドリング部分に存在しうるということである．予備実験と本実験の結果で示したとおり，NTLFlowLyzerのフロー処理部分におけるわずか数行のロジック変更がシステム全体の性能を劇的に改善した．この知見に基づき，ATLFlowLyzerではフロー処理のマルチプロセス化を最優先するアーキテクチャ設計を行った．Cython等の活用といった実装上の工夫も行っているが，本手法の高速性と堅牢性はこれら根本的なアーキテクチャ設計や流量制御の寄与が大きいと考えられる．これが本研究における中心的な知見であり，今後の特徴量抽出機の設計においても重要な指針となると考えられる．

6.　おわりに

本研究では既存の特徴量抽出機を基盤とし，GPUによる高速な特徴量計算とフロー処理の分散実行を組み合わせた新たな特徴量抽出機であるATLFlowLyzerを提案した．提案手法の有効性を示すために複数のサイズの異なるpcapファイルに対して実験を行い，NTLFlowLyzerと比較した．実験の結果，提案手法の高速性と堅牢性が示された．さらに，その設計と評価を通じて，ネットワークトラフィック処理システムの性能向上においては，計算処理の最適化だけでなく，データハンドリングのアーキテクチャ設計が極めて重要であるという実践的な知見が得られた．今後の課題としてはRust等のより高速な言語での実装によりさらなる高速化を図ることや，オンライン環境における実運用を想定した評価を行うことが挙げられる．

謝辞　本研究はJSPS科研費JP23K28051の助成を受けたものです．