“ASKS” と データソースの接続

こんにちは、CHAGE 開発メンバーの くまさか です。

CHAGE 紹介記事、第四弾です。
今回は、CHAGE にどんどんデータを追加できる仕組みである ASKS Seller を紹介します。

ASKS Seller は、 ASKS の世界に検索のデータソースを接続する仕組みです。
つまりは、CHAGE に出力される結果は全て、ASKS Seller を経由して取得しています。
今までの記事では、ASKS Agent が データソース(ISONなど) と接続しているような図を表していましたが、実は間にASKS Seller が存在しています。

全てのデータは、 ASKS Seller で違いを吸収し、ASKS Packet となります。
そのため、ASKS Seller を開発するだけで、どんどんデータソースを接続することができてしまいます。(どんどん接続されたデータソースは 現在、266個(8種類) も稼働しています。)

ASKS Seller の構成

ASKS Seller は、「ASKS Agent に接続する機能」と「検索を変換する機能」から構成されます。

ASKS Agent に接続する機能

ASKS Seller は、データソースを接続することに特化しているので、今までの記事で紹介した「どんどん検索」を支える仕組みがありません。
「どんどん検索」を行う一部とする為に、ASKS Buyer に接続できる ASKS Router を持つ ASKS Agent と接続する必要があります。
ASKS Seller と ASKS Agent の接続は、前回の記事で紹介した MPPP を活用することで、トータルスループットの向上にも努めています。

検索を変換する機能

様々なデータソースは、データソース毎に「異なるアクセス方法」と「異なるデータ形式」を持ちます。
それらの違いを吸収し、「共通のアクセス方法 」と「共通のデータ形式 (ASKS Packet)」を提供する機能です。
この機能により、ASKS では、ASKS Seller 以外がデータソース毎の違いを意識することなく検索が行えます。

検索の流れとしては、以下のようになります。

1. 検索リクエストのASKS Packet が、共通のアクセス方法 MPPI を経由し、ASKS Seller に到達します
2. ASKS Seller は、データソースが扱える 形式にデータの変換を行います
3. ASKS Seller は、データソースの扱い方に合わせた検索(データの取得) を行います
4. ASKS Seller は、データソースの形式の応答結果をASKS Packet に変換します。
5. ASKS Seller は、MPPI 経由で、検索結果のASKS Packet を応答します

データの取得

データソース毎の扱い方に合わせたデータの取得方法の例を挙げます。

• プロセスとして動作している検索システム ISON の場合
  • プロセスに対して、標準入出力でデータの取得を行う
• CSVファイル の場合
  • ファイルを開き、データの取得を行う
• データベースファイル の場合
  • 専用の接続クライアントや、接続ライブラリを用いてファイルを開き、データの取得を行う

このような違い毎に ASKS Seller を開発し、MPPI 経由の共通化されたアクセス方法を実現しています。
( 具体的な方法については、本記事下部の “増えまくった ASKS Seller 達を紹介” で紹介しています。)

データの変換

データ形式についても簡単な例を挙げます。
ASKS Packet に変換する前のデータは以下のように様々な形式があります。

• 1つのvalueだけが返るもの value
• 複数のvalueが返るもの value, value, value
• 検索したkeyと一緒に返るもの key, value

ASKS Packet は、前回の記事で紹介したように key value(1つのkeyに対して 1つのvalue) を格納する形式です。
例えば、2つ目の場合、複数のvalueを1つずつに切り分けるような変換を行い、ASKS Packet を生成するような変換を行っています。

検索のデータソースをどんどん増やせる

データソース毎の違いは ASKS Seller で吸収されるので、ASKS Seller だけ開発を行えば、新しいデータソースを追加する準備が整います。
CHAGE の 検索データソースとして ASKS Seller を登録するには、検索先の経路情報に追加する必要があります。
( 前回の記事で紹介した ASKS Buyerの「検索可能先一覧」に追加するだけです。)

しかし、ASKS Seller は、ASKS Router を持たないので、「検索可能先一覧」の宛先になれません。
そのため、ASKS Router を保有する、ASKS Agent と ASKS Seller をセットで起動することで、検索先として活用できます。

ASKS Agent が間にいる理由

スーパー等で買い物するときに、商品の仲卸業者が多いほど値段が高くなるかと思います。
マイクロサービスの世界でもそれは同じであり、 ASKS Agent が間に存在することで連携コストが発生します。
そのため、ASKS Seller に ASKS Router を入れてしまえば、ASKS Agent が不要になり、1つの検索に対するレイテンシを下げられます。

しかし、あえて連携するコストを払い、ASKS Agent を分離しています。
その目的は、データ毎の処理(ASKS Seller) と、経路配送の仕組み(ASKS Router) を分離させることにあります。
経路配送の仕組みである ASKS Router は、複雑な組み合わせから、効率的な経路配送を支えています。(前回の記事で詳細に紹介しています。)
このような複雑な仕組みをASKS Seller に持たせないことで、構造を単純にし、開発や動作改善を容易にしています。

とはいえ、連携するコストに対して向上するメリットが少なければ ASKS Agent を分離する意味はありません。
紹介している ASKS がここで払う連携コストは、微々たるものなので、ASKS Agent が分離されていても、大きな問題になりません。
1つの検索で払うASKS Agent 通過のコストに比べて、検索をおこなう記憶装置のI/O や インターネット上のAPIのコストが比較にならないほど大きいので、微々たるものです。

増えまくった ASKS Seller 達を紹介

どんどん増やせるので、データソースの特性や、特定の役割に合わせて ASKS Sellerはいくつも作りました。
現在稼働中の仕組みは、以下の8種類です。
データソース自体が複数存在する場合や、別な機構が共通データソースに変換している( ISON等 ) 場合は、複数プロセス起動させています。

これらのASKS Seller は、大きく2種類に分類できます。

• 自立型
  • データソースへ自らアクセスする
• 依頼型
  • 他プロセスへ検索を依頼し、自らはデータソースにアクセスしない

その中でも代表的な3つのみを詳しく紹介します。

CmdCSV Seller

コマンドの呼び出しで他のプロセスへ依頼する依頼型のASKS Seller です。
最も汎用的な ASKS Sellerです。

名前からイメージできるように、コマンドの結果をCSVフォーマットで受け取る事に対応しています。
入力されたCSVフォーマットは、内包するCSVパーサによって、ASKS Packet へ変換されていきます。
「最も汎用的」である理由は、CSVを出力できる何か開発すれば、簡単にASKS へ接続できる為です。
例えば、echo "MyKind,my.value" のシェルスクリプトだとしても、ASKS Seller にできます。

コマンドの結果をCSVで受け取るのは、ASKS Seller の標準入力です。
標準入力で処理する理由は、受け取るたびに逐次変換していくためです。
仮にファイルで受け渡した場合、逐次変換が難しい事に加え、ファイルI/Oまで発生してしまうので、ASKS の世界では耐えられない待ち時間が発生してしまいます。

ISON で活用する ASKS Seller は、この CmdCsv Seller です。
ISON は、CmdCSV Seller の標準入力に検索結果をCSV形式で渡します。

さて、なぜ、ISON が 自立型ISON ASKS Seller のようなものを用意せず、依頼型のCmdCSV Sellerを活用するのでしょうか。

それは、ASKSの世界の速度に比べ、外部APIのレイテンシは極端に大きいことがポイントです。
その規模は、 ASKS Seller の段階でいくら速度を稼げたとしても、トータルスループットが変化しないほどです。
そのため、独自の ASKS Seller を開発しても速度が稼げないという判断から、ISON は、依頼型で汎用的なCmdCSV Seller を活用しています。
仮に ISON や その先の外部APIが、超高速応答できるような仕組みとなれば、改めてその時に見直します。

CDB Seller

KVSファイルシステムに対して自ら検索を行う自立型 ASKS Seller です。事前にDBファイルにデータを蓄積し、検索させます。
CDB とは、key に対してvalueが格納できるデータ構造の1つです。

CDBを採用している理由は 主に以下の3つです。

• 検索コストが低い 点
• 単一ファイルである 点
• 同一キーを格納できる 点

それぞれ順番に解説します。

検索コストが低い 点

ASKS の世界で大切なのは、高速に応答できることです。そのため、DBファイルは、高速に検索できる必要があります。
CDB は、ファイル作成時にデータをソートしてから書き出す為、検索のレイテンシが小さい特性があります。
書き出す際も、ブロックサイズを意識したデータマッピングを行う等の検索の小さいレイテンシ化を支える技術が多く、検索コストがとても低いです。

しかしその反面、ファイルを作成するコストが高いことや、データの追加ができない といったいくつかの制約が存在します。
CHAGE では、全く新しいCDBファイルを作成し直し、差し替えることで、データの追加に対応しています。

単一ファイルである 点

CHAGE では、データの追加を行う際、検索を止めない為に、検索とは別な機構でCDBファイルを作成しています。
具体的には、CDBファイル作成機構でファイルを作成し、検索対象path にあるファイルと入れ替えるという動作をします。

入れ替える際の課題は2つです。

1. 既に検索中のプロセスは引き続き古いファイルにアクセスできること
2. 入れ替えが中途半端な時に検索が開始されないこと

Linux上でファイルを扱う場合、単一ファイルであれば、これらの課題はOS側が解決してくれます。
(1つ目の課題は、ファイルの中身へのアクセスはpathではなくinodeである為、ファイルpathを入れ替えても古いファイルへのアクセスは疎外されません。)
(2つ目の課題は、pathの入れ替え(rename) は、不可分操作です。中途半端な時に他のプロセスがアクセスすることはありません。)

同一キーを格納できる 点

CHAGE では、1つのkeyに対して複数のValueが存在します。例えば以下です。

• key
  • domain iij.ad.jp
• value
  • ns dns0.iij.ad.jp
  • host omgi.iij.ad.jp
  • domain iij.com

このような Key-Multi Valueなデータ構造の場合、ファイルに格納する構造は2つ考えられます。

1. 1つのkeyに対して1つの領域を割当て、中に複数のValueを格納する
2. 複数のValue個分の領域を割当て、同じKeyを登録する(同じkey を複数登録できる)

単一のValueを取得する為には、1の構造の場合、Keyに対するValueを全て取得してから1つのValueを抽出します。
対して2の構造の場合、単一のValueを特に加工せず取得することができます。

複数のValueを取得する為には、1の構造のように一度に全て取得できるような構造の方が都合がいいかもしれません。
ASKSのような、ASKS Agent に1つのkey, valueをどんどん連携する構造においては、単一の取得が早いことが大切になってきます。

さて、ASKS Seller には、CDB Seller と同じように key, valueの格納はできる LDB Seller というものが存在します。
この LDB Seller は、同一キーを格納できない という特徴を持っています。
そのため、安直に考えた場合、複数のValueを取得する為には、1の構造のようにせざるを得なくなります。
そのような状況における問題点や、問題点を回避した構造 について、CHAGEの裏側: LevelDBでの並列化用の最適化 で紹介しています。

Regexp Seller

検索依頼されたkeyの文字列を決められた正規表現で抽出しValueとして返す自立型の ASKS Seller です。
例えば、https://www.iij.ad.jp/ というurlから www.iij.ad.jp というホスト名を抽出できるような正規表現を用意しています。
先ほど紹介した CDB Seller や、 CmdCsv Seller に比べるととても単純な役割を持つ ASKS Seller です。

このような 単純な役割をもつ ASKS Seller も、 CHAGE にとっては立派な情報の1つです。
CHAGE には、ASKS が存在するので、文字列からの抽出であっても再帰的検索され、より多くの検索結果を出力することを支えます。
より多くの関連情報を出力できれば、OSINTを支援できる情報量が増えます。
その為、単純な役割がただの正規表現や文字列置換だったとしても、CHAGE 本来の目的を大きく支えることにつながっています。

---

今回は、ASKS にデータソースがどのように接続されているのかを紹介し、具体的な ASKS Seller を3つ紹介しました。
役割毎の ASKS Seller さえ開発できれば、ASKS の機能を容易に増やせる構造によって、データソースがどんどん増えることを知ってもらえたかと思います。

ちなみに、ASKS Seller という名前ですが、売り子からきています。
前回の記事で、 ASKS Buyer がデータを集めることを買い物と表現しました。それに対して、データを渡す様子が売り子に見えるので、Seller と名前がついています。

さて、次回は第五弾です。実は、この CHAGE シリーズの最終章です。
最終章では、CHAGE の最も大切な要素を紹介します。

関連記事

1. IIJ内製調査システム CHAGE のご紹介
2. CHAGE の動き
3. “ASKS” の働き
4. “ASKS” と データソースの接続（本記事です）
5. “CHAGE” の大切な要素