ピコもんのログ収集基板について

WACODE @airtoxin

自己紹介

Ryoji Ishii@airtoxin

ピコもん株式会社

アプリケーションエンジニア

曲を作っていたりイカになったりしている。

フロントでJavascript、バックエンドでNode.js、レコメンダーの実装にJava、サーバーの構成管理にRuby、死活監視の為にPythonなどなど…

ピコもん株式会社

ピコもん株式会社

Webサイトの案内人として、ピコもん導入サイト上でキャラクターを動かし、訪問ユーザーとコミュニケーションを取りながらユーザーが求めている情報へと誘導する。

ピコもん

デモ

• https://www.picomon.jp/company/recruit

ピコもんのログ事情

全体図

アクセスログ

アプリケーションログ

アクセスログ

アプリケーションログ

アプリケーション サーバー

ログ サーバー

アクセスログ全てのAPIエンドポイントについて、リクエストとレスポンスを合わせたログデータをテーブルなどに分けて保存

サーバーアプリケーションからのログも必要ならば保存

基本的にフロントからの要求で動作するので、調査が必要になった時にユーザーの行動履歴を復元できる

アプリケーションログ

現在はエラー情報のみを流している

将来的にはボトルネックを調査できるようにアクセススループットのデータやデータベースのログなども流したい

アクセスログ

アプリケーションログ

アプリケーション サーバー

ログ サーバー

Fluentd

Fluentdアプリケーションサーバーとログサーバー間、ログサーバーと各種サービス間を繋ぐログデータのパイプ

データは一時的にバッファリングされるためロストが無く安心

各データに対してタグを付け、そのタグのマッチングで送信先を振り分ける事が出来る

プラグインで送受信先やデータの振り分け方などを拡張できる

fluent-plugin-forest

タグを分解し、変数として送信先の指定などに使用できる

APIエンドポイント毎に送信先を動的に決定するなどの処理をするのに必須

アクセスログ

アプリケーションログ

アプリケーション サーバー

ログ サーバー

Slack

Slack

最近流行りのチャットツール

色々なツールと連携が取れる

Incoming WebHooksを使うと自由にメッセージが流せる

Slack

Slack

Slack

Slack活用事例• botで社内の雰囲気を明るく

• アプリケーションのエラーログをリアルタイムでチャンネルに表示し、エンジニアのスムーズなバグ調査を支援

😊

アクセスログ

アプリケーションログ

アプリケーション サーバー

ログ サーバー

elasticsearch + kibana

elasticsearch

全文検索エンジン

ログのテキスト入れれば色々検索できてハッピーみたいなやつ

kibana

elasticsearchをバックエンドとした、可視化用ダッシュボード

リアルタイムに集計とか出来て便利だよね系

elasticsearch + kibana活用事例

• エラーログの表示

• シナリオ実行数のカウント

見た目がキレイ

何か仕事やってる感出る

アクセスログ

アプリケーションログ

アプリケーション サーバー

ログ サーバー

Norikra

NorikraSQLライクなクエリ(Esper EPL)でjson形式のデータストリームを集計(Continuous Query)

集計したデータは新たなストリームとして再び流れてゆく

機能としては集計のみなので、集計結果をelasticsearch

に流してkibanaで可視化などする必要がある

rubygemで簡単にインストール・アップデートできる

Norikra活用事例• リアルタイムのユーザー数のカウント

• 気密性の高いサーバーからのエラーをメール通知

• 異常アクセス検知とアラートの送信

お手軽CQ

アクセスログ

アプリケーションログ

アプリケーション サーバー

ログ サーバー

Google BigQuery

BigQuery• Googleが提供するフルマネージド

DWH

• 数千台のサーバーでデータを処理

• データ量が増えても極端に遅くなることが無い

BigQuery活用事例1現在弊社で動いてる最大のクエリ→ユーザーの行動履歴を元に、どの程度想定した行動が取られているか？

3つの行動履歴から時間指定して特殊データを除外してユーザーのIDやセッションでグループ分けして全てを結合(約3000文字)

実行完了まで5秒程度

BigQuery活用事例2重すぎてアプリケーションのパフォーマンスを落としていた処理→ユーザーのアクション実行履歴をグラフに整形して出力する

アクションやシナリオの実行履歴をセッション毎にグループ分けし、それぞれをtimestampで並び替え、順番で番号付けし、それぞれのグループ毎に1番目と2番目,2番目と3番目…とデータを取り出し、同じデータについてカウントを取る(約1500文字)

こちらも実行完了まで5秒程度

やんちゃんなクエリも受け入れる包容力

BigQueryは暴力

BigQueryは暴力👊

サイコー！

アクセスログ

アプリケーションログ

アプリケーション サーバー

ログ サーバー

データ保持のスパンNorikra - 短期的

Elasticsearch - 中長期的

BigQuery - ∞

即時的な解析・調査からバッチによる集計まで、ミドルウェア毎に得意とするデータ保持期間で同じデータを分散して保持する

データの保証データ欠損→Fluentdの再送機能によって保証。Fluentdを介さずアプリケーションから直接送っている所も再送機能を実装し対応。

重複送信→DBの制約によって保証。

ログ基板の構築Chef + Serverspecでテストを行いながら各ミドルウェアを導入。冪等性があるので安心して実行できる。

Fluentd同士の連携テスト中、データが10分ほど届かないことがあった(原因不明)ので気長に待つのが良い。

serverspecのテスト中に破壊的バージョンアップがあってうまく動かなくなったりした。

まとめ

まとめ• 解析に合わせてDBを選択

• リアルタイムな集計が必要ないデータはとりあえずBigQueryに入れておけば安心

• Fluentdがだいたい面倒見てくれる

FIN

素敵なデータ処理ライフを！