- 阿部 博
- 肩書き・所属
- 北陸先端科学技術大学院大学 博士(情報科学)
- 株式会社レピダム 研究員
- ココン株式会社 社長補佐/技術研究室 研究員
- 情報通信研究機構 協力研究員
- Interop Tokyo ShowNet NOCメンバー(2015年〜)
-
ログ一元化の問題について
- ログ処理を行う場合には、ログを一箇所へと集め大規模なシステムで処理するトレンドがある
- 転送コストが莫大
- トラヒック圧迫
- 処理システムへ集めるのが大変
- Kafka等使って大規模キューイングシステムを用いる
- Fluentdなどを使って構造化して投げつける
- 集めた物を扱うのが大変
- Hadoopエコシステムみんな管理できない問題
- Elasticsearchもしかり
- 書ききれない問題
- スキャンごとに課金される問題(BigQuery)
- Hadoopエコシステムみんな管理できない問題
- セキュリティの問題
- 処理システムが突破されると一発で終わってしまう
-
そもそも現状のサーバ機のスペックであるならば、ログの処理はそこまでheavyではない
-
関連キーワード
- Edge Heavy Computing
- Heavyに扱う必要すらないのではないか?
- Edge Heavy Computing
- ログを一箇所へと集めない手法を考える
- それぞれのサーバへとログ処理をちらばす
- 結果だけ取得できれば、全てのログを都度送る必要はない
- もっというと統計データのみでもよい
+--------+
| client |
+--------+
|
+----------------------+
|Distributed Task Queue|
+----------------------+
| | |
+---------+ +---------+ +---------+
| worker1 | | worker2 | | worker3 |
+---------+ +---------+ +---------+
-
Clinet
- 検索キーワードを投げ入れる
- The Platinum Searcherの引数として
-
Distributed Task queue
- PythonのCeleryを想定
- バックエンドにRedis
- RedisはString型で512MBまで格納可能
- 戻り値のログが大きくても格納できる
- PythonのCeleryを想定
-
worker
- ログを検索するための仕組み
- ここでは生ログを想定
- The Platinum Searcher
- 高速に生ログを検索可能
- clientから渡ったキーワードを引数にとる
- ログを検索するための仕組み
- アーキテクチャ的には小規模だと動きそう
- ではEdgeを数万まで拡大した場合には?
- Distributed Task Queueが詰まりそう
- 解決方法は
- 階層化
--------------------------
1. Client
--------------------------
2. Service Mesh
--------------------------
3. Distributed Task queue
--------------------------
4. worker群
--------------------------
- Service Meshによるロードバランシング
- Hashi CorpのConsulなどを組み合わせられないか?
- 違うんですよ、これはクエリの実現なんですよ
- 全サーバからデータを集めたいなら : *.*
- Webサーバだけからデータを集めたいなら : web.*
- nginxだけのログを集めたいなら : nginx.*
- webとnginxだったら : [web|nginx].* or [web.*,nginx,*] みたいなイメージ
- 情報収拾のターゲッティングをService Meshで実現できそう(要Consul調査)
- Edgeの検索処理をマイクロサービスと捉えるイメージ?
- まずは小規模から
- 次に規模を拡大して