3. フォーカス・リサーチ（2）

Hayabusa：高速に全文検索可能なログ検索エンジン
3.1 背景と目的いることになり、本来はログの解析に時間を費やしたいところ

ネットワークやシステム運用の現場では安定したネットワーを、検索・蓄積システムの管理に時間が割かれることも少なくク運用やトラブルシュートを行うために、ネットワーク管理者ありません。

がネットワーク機器から出力されるログを収集して統計情報として表示したり、トラブルの原因となるログを検索する方法「ログの蓄積」と「ログの検索」がシンプルに動作する仕組みが多く用いられています。また、セキュリティインシデントにが、複雑なクラスタリングシステムを用いることなく実現で対応する際にも、トラブル対応の場合と同様、ログからどのよきれば、ネットワーク管理者は蓄積・検索システムの管理に時うなインシデントが発生したかを探ることがあります。

間を割かれずに済み、本来の業務であるネットワークのトラブル対応やセキュリティインシデントの解析に集中すること大規模なネットワークでは、多くのサーバ・ネットワーク・セができます。

キュリティ機器から通信を記録したログが日々大量に出力されるため、ネットワーク管理者はそれら大量のログをストレー

本稿では、多数のマルチベンダー機器が出力する大量のログジシステムに蓄積し、高速にログ検索するシステムを管理してを高速に蓄積でき、高速に検索可能なシステムとして実装しいます。大規模なログ検索システムと蓄積システムを扱うためたオープンソースソフトウェア「Hayabusa」について解説しには、クラスタリングシステムや専用の管理ソフトウェアを用ます。そしてシステムが扱うログの量が増加した場合には、シ

図-1 2017年のShowNetトポロジー図

18© Internet Initiative Japan Inc.

Mar.2018

Vol.

38

3. フォーカス・リサーチ（2）ステムの検索性能が容易にスケールアウトすることで検索速ラー、構成の成否を判断する運用が行われます。
ShowNetを構度が飛躍的に向上する同ソフトウェアの分散システムのコン成する機材は多岐にわたり、更に最新鋭のソフトウェアやハーセプトモデルも併せて紹介します。

ドウェアが大量に投入されるため、機材やソフトウェアを管理する運用メンバーは機材からどのようなログが出力される

Hayabusaが実現する検索の高速化に関する評価は、Interopかを事前に知ることは困難です。

Tokyo で収集されたShowNetのsyslog実データを元に実験＊1を行いました。この実データは、600以上のサーバ・ネットワー

ShowNetでは、監視システムの1つとしてsyslogを収集し分ク・セキュリティ機器から出力されたものです。

析するシステムが運用されます。ほぼすべての物理機器・仮想機器群からsyslogが送信され、そのsyslogを集約し検索する

3.2 ShowNetシステムが構築されます。過去には、秒間２万件以上のログがShowNetは、毎年幕張メッセで開催されるInterop Tokyo内飛び交ったり、1日に2億件以上のログが蓄積されたこともあで構築される相互接続検証とデモンストレーションを行う実りました。

験ネットワーク環境です。出展社へのインターネットアクセスをサービス提供する側面もあるため、実験とサービス提供の両特定のソフトウェアやハードウェアからのログであれば、ロ方の側面を併せ持ちます。

グフォーマットを推測することも可能ですが、ShowNetを構築する機材には同一のソフトウェアやハードウェアは少なく、

図-1に示すように、ShowNetを構成する機材は数百を超え、実かつ大量のメッセージが最新のファームウェアやソフトウェ験ネットワークという性格上世界で初めて実ネットワークへアのデバッグ情報として出力されるため、一般的なログ蓄積・と組み込まれる製品も多く、中には試作レベルの機材やソフト解析ソフトウェアでリアルタイムに統計を表示させたり検索ウェアもあります。

を行うことは非常に難しいです。

ShowNetを運用するメンバーは、これらの機材やソフトウェ

3.3 Hayabusa

アを組み合わせて、サービス提供するネットワークを設計・構

Hayabusa＊2は、ShowNetで収集された大量のsyslogを高速に検築して運用を行います。安定的にシステム構築を行うために、索するためのシステムとして設計されました。
図-2にHayabusa

機材から出力されるsyslogを収集分析し、システムのバグやエのアーキテクチャを示します。

Hayabusa/targetdir/yyyy/mm/dd/hh
00.db/var/log/
syslogrsyslogd

x.log
x.log
x.log
x.log

readStoreEngine

insert01.db
・・・.db59.db

selectselectselectSearchEngine

selectSQLite DB Files（every 1 minute）
Simple Query$ parallel sqlite3 ::: target ﬁles ::: "select count(*) from xxx wherelogs match 'keyword';" | awk '{m+=$1} END{print m;}'

図-2 Hayabusaのアーキテクチャ＊1＊2

Interop Tokyo（https://www.interop.jp/）。

Hayabusa（https://github.com/hirolovesbeer/hayabusa）。

© Internet Initiative Japan Inc.

19

Hayabusaは ス タ ン ド ア ロ ン サ ー バ で 動 作 し、CPUの マ ル

このように定義することで、ログ検索のための時間情報をチコアを有効に使って高速な並列検索処理を実現します。

データベース内部に保持することなくディレクトリとのマッ

Hayabusaは大きくStoreEngineとSearchEngineの2つのシチングで行うことができ、時間のクエリ条件を指定することステムに分割されます。StoreEngineはcronにより1分ごとになく時間指定のログ検索が可能になります。ログが保存され起動され、ターゲットとなるログファイルを開き、ログファイるSQLite3ファイルはFTS（Full Text Search）と呼ばれる全ルに記録されたログメッセージをSQLite3 ファイルへと変文検索に特化したテーブルとして作成され、高速なログ検索換します。ログデータは1分ごとのSQLite3ファイルへと分割を実現します。SearchEngineは、並列検索性能を向上させるされ、検索時に複数プロセスにより並列処理されます。ログがために分単位に細分化されるFTSフォーマットで定義された保存されるディレクトリは以下のように時間を意味する階層

SQLite3ファイルへアクセスを行います。各SQLite3ファイとして定義されます。

ルへはGNU Parallel＊4を用いて並列にSQL検索クエリが実＊3行され、結果はUNIXパイプラインを経由してawkコマンドや/targetdir/yyyy/mm/dd/hh/min.db

countコマンドを用いて集計されます。

上記のディレクトリ階層は、以下の意味を持ちます。

Hayabusaはスタンドアロン環境で動作しますが、小規模なApache Spark＊5のクラスタよりも全文検索性能が高く、図-3/ターゲットディレクトリ/年/月/日/時間/分ごとのSQLite3

で示すように、先行研究＊6では3台のApache Sparkクラスタ

ファイルより27倍速い検索性能を示しました。

60
50

Hayabusa and Spark to pick up keyword "noc"Hayabusa（standalone）
Spark（distributed）

Seconds

40
30
20
100

110
Number of ﬁles

1001000

図-3 HayabusaとApache Sparkとの性能比較＊3

SQLite3（https://www.sqlite.org/）。

＊5

Aapache Spark（https://spark.apache.org/）。

＊4＊6

GNU Parallel（https://www.gnu.org/software/parallel/）。
H. Abe, K. Shima, Y. Sekiya, D. Miyamoto, T. Ishihara, and K. Okada. Hayabusa: Simple and fast full-text search engine for massive systemlog data. In Proceedings of the 12th International Conference on Future Internet Technologies, CFI’17, pages 2:1?2:7, New York, NY, USA,2017. ACM.

20© Internet Initiative Japan Inc.

Mar.2018

Vol.

38

3. フォーカス・リサーチ（2）3.4 Hayabusaの分散処理

より、どの処理ホストへ処理リクエストが渡ろうとも同じ結しかしながら、スタンドアロン環境にはハードウェア性能の果が返ることが保証されます。

限界が存在し、いつかは規模が拡大した他の分散処理クラスタに性能を抜かれてしまうと推測されます。そこでHayabusa

分散している処理ホストへの検索リクエストの実現にはRPCは、スタンドアロン環境という制約を取り払い、複数ホストでを用いました。Hayabusaの分散処理では、クライアントからHayabusaの分散処理環境を構築し、検索性能がスケールアウのリクエストを受け取った処理ホストは、スタンドアロンのト可能なアーキテクチャの実現を目指しました。

Hayabusaと同等にローカルディスクに保存した複数のデータベースファイルに検索クエリを発行することを前提としスタンドアロンで動作するHayabusaを分散処理システムとます。SQLite3のコマンドを検索リクエストのパラメータとして再定義し、検索処理性能をスケールアウトさせる実験をして処理ホストに受け渡すことも可能ではありますが、本提行いました。
Hayabusaのスタンドアロン処理性能を活かすべ

案ではスタンドアロンのHayabusaの性能を活かしつつ、シン

く、処理リクエストを高速なRPC（Remote Procedure Call）

プルに分散処理を実現するために、スタンドアロン環境で処としてクライアントから処理対象ホストへと送り込みます。

理されるものと同等のGNU Parallelのコマンドをリクエス

GNU Parallelを用いた並列検索を処理ホスト内で実行し、結果トのパラメータとして受け渡します。分散検索では複数の処はRPCを用いてクライアントへと返し集計を行います。これに理ホストへと処理リクエストが発行されることから、クライよりHayabusaが本来実現していた高速なスタンドアロン環アントが処理リクエストをキューイングし、処理ホストで動境での検索と、RPCによる高速なリクエスト/レスポンスを実作するWorkerがキューイングされた処理リクエストを取得現することができます。分散ホスト環境においてスケールアウして結果を返すProducer/Consumerモデルを選択しましトする検索機能を実現するために、データの並列蓄積と分散検た。これにより、各処理ホストで動作するWorkerは処理リク索に分けて設計を行いました。

エストを取得した後に、検索処理の実行が可能となります。

3.4.1 並列蓄積と分散検索

本提案では、すべての処理ホストにデータが複製されているこ

検索処理をスケールアウトさせるために、どの処理ホストにとから、どの処理ホストへ処理リクエストが渡ったとしても処理リクエストが届いても検索可能な状態になるように、同様の処理結果が返されます。また、クライアントからの処理

今回の実験ではすべての処理ホストに同一のデータを保持リクエストが特定の処理ホストに集中しないようにロードバさせる方法を用いました。これはすべての処理ホストへとランシングを行い、各処理ホストへ均等にリクエストを配布可syslogデータを複製して配送することを意味します。これに能にしました。

© Internet Initiative Japan Inc.

21

3.4.2 実装

れにより転送先のホストは、あたかも自身が送信元から直接■ 並列蓄積

データを受信したかのようにUDPパケットを受信することがsyslogをすべての処理ノードへ複製するために、本研究ではできます。

オープンソースソフトウェアであるUDP Samplicator を利＊7用しました。syslogの複製イメージを図-4に示します。UDP

通常、UDP Samplicatorは1プロセスでUDPの転送処理を行

Samplicatorは送信元アドレスを変更せずに受信したUDPパいます。しかしながら大量のsyslogを受信した場合には、プケットを指定した対象ホストへ転送することができます。こロセスの負荷が上昇しCPUのコア利用率が100%になってしHayabusa/targetdir/yyyy/mm/dd/hh

syslogsyslog

x.log
x.log
x.log
x.log

rsyslogd

select00.db/var/log/
readStoreEngine

insertselect01.db

select・・・.db

SearchEngine

select59.db

SQLite DB Files（every 1 minute）
Simple Query$ parallel sqlite3 ::: target ﬁles ::: "select count(*) from xxx wherelogs match 'keyword';" | awk '{m+=$1} END{print m;}'Hayabusa/targetdir/yyyy/mm/dd/hh

syslogsyslogsamplicator

x.log
x.log
x.log
x.log

rsyslogd

select00.db/var/log/syslog

readStoreEngine

insertselect01.db

select・・・.dbSearchEngine

select59.db

SQLite DB Files（every 1 minute）
Simple Query$ parallel sqlite3 ::: target ﬁles ::: "select count(*) from xxx wherelogs match 'keyword';" | awk '{m+=$1} END{print m;}'Hayabusa/targetdir/yyyy/mm/dd/hh
00.db/var/log/

syslogsyslog

x.log
x.log
x.log
x.log

rsyslogd

readStoreEngine

insert01.db
・・・.db59.db

selectselectselectSearchEngineselectSQLite DB Files（every 1 minute）
Simple Query$ parallel sqlite3 ::: target ﬁles ::: "select count(*) from xxx wherelogs match 'keyword';" | awk '{m+=$1} END{print m;}'

図-4 UDP Samplicatorを用いたsyslogの複製
Hayabusa/targetdir/yyyy/mm/dd/hh
00.db/var/log/
syslogrsyslogd

x.log
x.log
x.log
x.log

readStoreEngine

insert01.db・・・.db
59.db

selectselectselectSearchEngineselect3. exec

SQLite DB Files（every 1 minute）
Simple Query$ parallel sqlite3 ::: target ﬁles ::: "select count(*) from xxx wherelogs match 'keyword';" | awk '{m+=$1} END{print m;}'zeromqworker

2. command pullzeromqworker

2. command pull

5. result push

4. result

Hayabusa

1. Request（push）/targetdir/yyyy/mm/dd/hh
00.db/var/log/
syslogrsyslogd

x.log
x.log
x.log
x.log

readStoreEngine

insert01.db
・・・.db59.db

selectselectselectSearchEngineselect3. exec

SQLite DB Files（every 1 minute）
Simple Query$ parallel sqlite3 ::: target ﬁles ::: "select count(*) from xxx wherelogs match 'keyword';" | awk '{m+=$1} END{print m;}'5. result push

4. result

6. Response（pull）

Hayabusa/targetdir/yyyy/mm/dd/hh
00.db/var/log/syslog

rsyslogd

x.log
x.log
x.log
x.log

readStoreEngine

insert01.db
・・・.db59.db

selectselectselectSearchEngineselect3. exec

SQLite DB Files（every 1 minute）
Simple Query$ parallel sqlite3 ::: target ﬁles ::: "select count(*) from xxx wherelogs match 'keyword';" | awk '{m+=$1} END{print m;}'zeromqworker

4. result

図-5 UDP Hayabusaで用いるZeroMQのPush/Pull実装＊722

UDP Samplicator（ https://github.com/sleinen/samplicator）。

© Internet Initiative Japan Inc.

zeromqclient

2. command pull
5. result push

Mar.2018

Vol.

38

3. フォーカス・リサーチ（2）

まう場合があります。その結果、パケット転送処理が追いつか

図-5で示すように本提案でのクライアントは、PushとPullの2なくなり、データが破棄される可能性が生じます。そこで本実つの役割を持つように実装しました。これによりリクエストの験ではUDP Samplicatorにパッチを当て、マルチプロセスと発行からキューイング、結果の取得と集計をクライアント1プして動作するようにソースコードの修正を行いました。具体ロセスで行うことができます。

的 に は、socketの オ プ シ ョ ン と し て「SO_REUSEPORT」を追加することにより、複数プロセスで同じ待ち受けポートが利用可能となります。本提案の場合には、syslog受信ポート

3.5 評価

分散システムとしてのHayabusaのスケールアウト性能を調である「UDP 514ポート」が複数プロセスで共有されることべるため、処理ホストが増加した場合に処理時間が短縮できるとなり、UDP 514ポートへと届いたパケットは、複数のUDPかどうかの試験を行いました。処理ホストは1台から10台の範Samplicatorプロセスに自動的にロードバランスされます。こ囲で増加し、クライアントは1日分のデータに対して繰り返しれにより大量にsyslogを受信した際でも、1CPUコアではボト100回リクエストを実行します。
100回分のリクエスト対象のルネックになりがちなsyslogパケットの複製と転送をCPUコ

レコードサイズは、144億レコード（1分間のsyslog流量は10アスケールすることが可能となります。

万件と仮定）となります。

■ 分散検索図-6に示すように、ホスト1台のときの検索処理時間は約468

Producer/Consumerモデルは多くのソフトウェアで実装可秒でしたが、ホストの台数を増やすに従いホストの数で割った能ですが、本研究ではRPC処理が高速に実行可能で、ライブラ時間に近づき、10台のホストでかかる処理時間は約10分の1

リを用いることでクライアントとWorkerプロセスを実装可である48秒になりました。

能なZeroMQ を用いました。ZeroMQは高速に動作する分＊8

散メッセージキューとして利用され、「Request/Response」

また、秒間に処理可能なレコードのスキャン数はホスト1台の「Publish/Subscribe」「Push/Pull」などたくさんのメッセー

場合には3000万件ですが、ホスト数が10台の場合には10倍ジングパターンを容易に実装することができます。本提案でである3億件まで増加します。これはホストを1台から10台まは、「Push/Pull」パターンを用いてProducer/Consumerモデで増加させた場合、検索の処理性能がホストの台数に応じて意ルを実装しました。

図したとおりリニアにスケールアウトしていると言えます。

468

400
processing time（sec）

350

processing time（sec）
Scan record / sec（mega）

300M
257M

250

232M
205M

300

200

1000153M
15861M

91M

23150122M
11830M

1200180M

236

49430010080706256

567
Number of host89481050

Scan record / sec（mega）

500

0

図-6 検索ホストのスケールアウト性能＊8ZeroMQ（http://zeromq.org/）。

© Internet Initiative Japan Inc.

23

次に10台のホストで処理を実行する場合にWorkerの数を1プました。これは、本質的には重複するデータを大量に複製するロセスから16プロセスの間で増加させました。16という数字行為であり、データの量が増加すればするほどネットワークの根拠は本実験に用いたサーバのCPUの物理コア数であり、帯域と保持するデータに無駄が発生することを意味します。

物理コアの数だけスケールアウト可能かどうかを確認する意

Hadoop＊9のHDFSのようにレプリケーション数を設定し、複図があります。
10台のホストで1Workerプロセスのみを動作数ホストでデータを分散させ保持することはもちろん可能でさせた場合にかかった処理時間は約48秒でしたが、10台のホはありますが、その場合にはメタデータ管理機構でデータの管ストで10Workerプロセスを動作させた場合の処理性能は最理を行い、データアクセスはメタデータ管理機構経由となり、高6.1秒となり、処理速度が約8倍高速化しました。10Worker

ストレージへのアクセス性能を低下させ、検索自体の処理性以上の処理速度は横ばいとなったため、16プロセスで最大値能も低下させる恐れがあります。Hayabusaと分散ストレージを出すためには何かしらの工夫が必要と思われます。の利点欠点を考慮し、Hayabusaに適した分散ストレージを実現することが1つの大きな課題となります。

ホスト数とWorker数の両方のスケールアウトを組み合わせた
結果、1台の処理ホストで1Workerプロセスを用いた場合で約またHayabusaは検索基盤システムとして動作するため、その468秒かかっていた検索時間が、10台で10Workerプロセス上で動作する具体的なアプリケーションソフトウェアを組みを動作させた場合では6.1秒まで短縮し約78倍の高速化が実合わせることでさらなる有益なシステムとなり得ます。

現しました。
syslogを高速に検索できることから、先行研究であるインベン

3.6 今後の課題

トネットワークにおけるsyslogを用いた異常検知＊10と組み合

本研究では検索性能を向上させる分散クエリに対応するため、わせることで、高速に動作する異常検知アプリケーションを作各処理ホストに同一のsyslogデータを複製する手法を用い成することが可能になると考えます。

＊9

Apache Hadoop（http://hadoop.apache.org/）。

＊10 阿部博 and 敷田幹文. イベントネットワークにおけるsyslogを用いた異常検知手法の提案と実でータを用いた評価. In インターネットと運用技術シンポジ
ウム2016論文集, volume 2016, pages 57-64, dec 2016.

24© Internet Initiative Japan Inc.

Mar.2018

Vol.

38

3. フォーカス・リサーチ（2）3.7 Hayabusaの応用

3.8 まとめ目標の1つとされます。

明と分散処理による評価について解説しました。評価の対象とセキュリティ分野の研究では、攻撃の予測や検知を行うことが本稿では、オープンソースソフトウェアであるHayabusaの説なるレコード数は144億レコードであり、144億レコードを約増加するサイバー攻撃に対抗するために、攻撃の兆候をリアル6秒でフルスキャンできたということは、GoogleのBigQueryタイムに分析し、発生し得る攻撃とその深刻度、影響範囲を予に匹敵するデータのフルスキャン速度が実現できたことを意測することが可能になれば、今まで担当者の能力で担われてい味します。
10台の処理ホストでこれほど高速なスキャンを実たセキュリティ事案に対する属人的な対応を、機械学習や深層現できるということは、コスト面でもリーズナブルで高性能な学習を用いてサポートすることが可能となります。

分散処理システムであると言えます。

IIJ技術研究所は、東京大学、東京工業大学、奈良先端科学技術

なお、本稿のより詳細な解説は論文＊12として公開されています。

大学院大学と連携し、「サイバー脅威ビッグデータの解析によ＊11
るリアルタイム攻撃検知と予測」
プロジェクトへ参加して本研究の一部は、国立研究開発法人科学技術振興機構（JST）います。本プロジェクトでは、攻撃の兆候をリアルタイムに分の 研 究 成 果 展 開 事 業「 戦 略 的 創 造 研 究 推 進 事 業（CREST）

析する基盤として、その一部にHayabusaが組み込まれます。

JPMJCR1783」の支援によって行われています。

更に、他のデータ解析ソフトウェアや機械学習ソフトウェア（R、Chainer、Pandasなど）と連携をして、攻撃の兆候を統計や機械学習で分析する基盤として動作します。

執筆者：

阿部 博（あべ ひろし）
IIJ 技術研究所 研究員。

執筆者：

島 慶一（しま けいいち）
IIJ 技術研究所 主幹研究員。

＊11 「サイバー脅威ビッグデータの解析によるリアルタイム攻撃検知と予測」（ https://www.jst.go.jp/kisoken/crest/project/1111094/1111094_13.html）。
＊12 阿 部 博 and 篠 田 陽 一. ス ケ ー ル ア ウ ト 可 能 な ロ グ 検 索 エ ン ジ ン の 実 現 と 評 価. In イ ン タ ー ネ ッ ト と 運 用 技 術 シ ン ポ ジ ウ ム2017論 文 集, volume 2017,
pages 73-80, nov 2017.

© Internet Initiative Japan Inc.

25