Developers Summit 2016 【18-B-2】石原様の資料です。

1. (株) インターネットイニシアティブ
石原 翔真
データ分析で始めるサービス改善初めの一歩
＃devsumiB【18-B-2】

2. ‐ 2 ‐
自己紹介
石原翔真
株式会社インターネットイニシアティブ
入社2年目
クラウドサービスの開発・運用を担当

3. ‐ 3 ‐
発表内容
サービスのログを分析し、様々な改善に活用
するための第一歩を踏み出した話
Elasticsearch, kibana, Flume, Hive,
R…
これから始める方向け

4. ‐ 4 ‐
これまでの運用

5. ‐ 5 ‐
運用しているサービス
IIJ GIO ストレージ＆アナリシスサービス
• S3互換のストレージとHiveによる解析機能を提供
ストレージ
ユーザからの大量のアクセス
(HTTP(s), PUT/GET/DELETE等)
解析機能
解析対象 = ストレージへのアクセス 解析ツール = 自社サービス + α

6. ‐ 7 ‐
これまでの運用
 単発の障害検知を目的にした監視システム
• 社内共通の監視基盤 (ping, snmp 等)
• munin
• エラーログ収集
ユニットテスト/結合テスト中心の自動化
• 定常的なパフォーマンス計測については手薄

7. ‐ 8 ‐
できていなかったこと
サービス利用の全体傾向をつかむこと
• 障害の全体像がわからない
• 需要予測がしづらい
• 予防的なパフォーマンス改善ができない
ログを収集・分析することで実現する！！

8. ‐ 9 ‐
ログ収集と可視化
【この取り組みで解決した課題】
 障害の全体像がわからない
 需要予測がしづらい

9. ‐ 10 ‐
利用傾向をつかむために
手始めにログ収集・可視化に取り組む
• Flume でのログ収集
• Elasticsearch への蓄積, kibana による可視化
リクエスト単位での利用傾向を確認する

10. ‐ 11 ‐
ツール その1 - Elasticsearch/kibana
Elasticsearch
kibana

11. ‐ 12 ‐
ツール その2 - Flume
ログ転送ツール
• 類似のツール: Fluentd、Logstash
Flume の構造
• Source, Channel, Sink の三段構成
• 連携するツールに合わせてプラグインを自作可能

12. ‐ 13 ‐
 各サーバから集めたログはElasticsearchへ格納され、
kibanaで可視化される
構成
IIJ GIO ストレージ&アナリシスサービス
Apache
ストレージAPI
Apache
解析API
Flume Flume
Log
Log
Log
Log
Log
Log
インターネット

13. ‐ 14 ‐
問題点
ログの量が多い
• 1日のログの容量がtotal 20GB
• 20GB × 365 = 7TB over…
• そのままでは長期間のログ保管ができない
• お客様が増えるとさらにつらい
「有用な」ログの選別がつらい
• モジュールごとにフォーマットや取得できる値は
ばらばら
• スタックトレースがそのまま吐かれている

14. ‐ 15 ‐
対策 : 収集するログを絞る
Apacheアクセスログのみ
• ユーザー利用傾向だけなら十分
• ログの大部分はアプリのトレースログだった
Flume に Esper を組み込んで集約
• (株)サイバーエージェント様の事例を参考に実装
• CyberAgent Tech Report: FlumeとEsperを用いたSQLライクな
クエリによるストリーム処理
https://www.cyberagent.co.jp/techinfo/techreport/report/id=7872
ログの収集

15. ‐ 16 ‐
Esper
CEP (複合イベント処理) エンジン
• SQL ライクにイベントデータの操作が可能
ログ集約に活用
• 一定時間ごとにログを集計し、アクセス総件数や
処理時間の最大値・平均値などを計算
• Elasticsearch には集計した値のみを投入
• Flume に組み込む
ログの収集

16. ‐ 17 ‐
Flumeのカスタマイズ
自作 Interceptor で Esper を走らせる
• Interceptor: Source内で受け取ったログデータ
の変形・フィルタを行う
ログの量を 1/10 に抑えられた
Log
LogEsper
ログの収集

17. ‐ 18 ‐
kibana で可視化
Elasticsearch/kibana 連携は容易
アクセス件数、HTTPメソッドの割合、処理
時間の分布などを可視化
可視化・解析

18. ‐ 19 ‐
Elasticsearch に投入
可視化する項目を選ぶ際に試行錯誤
• Kibanaで可視化するためにはMapping
Templateを設定する必要がある
• スキーマに相当
• 項目の選択、可視化を繰り返して有用な可視化対
象の項目を探した
注意点
• Indexの定期的な削除
• インデックスはGBオーダー
可視化・解析

19. ‐ 20 ‐
Kibana で可視化
 ログ集約の結果、分布図が書けなくなった..
• 左: データサイズ 右: レスポンスタイム
可視化・解析

20. ‐ 21 ‐
現在
アクセス傾向はつかめるようになった
ログの収集可視化は簡単！でも……収集する
ことを前提に設計するべき
• 収集の枠組みを後付けで作ったことで苦労した
• 集める前提でログを作り込む
• ログフォーマットの統一
• 収集する情報の選別

21. ‐ 22 ‐
解析
【この取り組みで解決した課題】
 予防的なパフォーマンス改善

22. ‐ 23 ‐
ログを可視化したが・・・
可視化だけでは不足していた点
• 人の目に頼った判断
• 情報が落ちている
より詳細に傾向の変化を把握して、能動的に
改善していきたい
• Hive による全アクセスログの集計
• R 機械学習ライブラリによる傾向の変化の検知

23. ‐ 24 ‐
解析の流れ
ログ収集対象
(今回はストレージ自身)
1. アクセス
ログの取得
2. データの整
形・フィルタ
IIJ GIO ストレージ&アナリシスサービス
4. データ・アルゴリズムへの
フィードバック
解析端末
3. 解析アルゴリズムの適用
フィードバック

24. ‐ 25 ‐
データの収集
Flume でアクセスログを収集
• オブジェクトストレージにPUTするSinkを自作
ストレージ&アナリシスサービス 解析API
で整形・クレンジング
• ストレージに蓄積したログを Hive で処理
ログ収集対象
1. アクセス
ログの取得
2. データの整
形・フィルタ
IIJ GIO ストレージ&アナリシスサービス

25. ‐ 26 ‐
解析してみて
 例: API アップデート前後の処理時間の変化
• 改修により性能向上し、遅いリクエストが無くなったことが判る
• 緑の点がアップデート前、桃色の点がアップデート後
小リクエスト処理時間大
小 レスポンスサイズ 大
アップデート前 〃後
小リクエスト処理時間大
全アクセスログ解析

26. ‐ 28 ‐
次の一歩
ログを全量手に入れて分析できた
しかしまだ属人性が高い
• 人の目で結果を判断をする
• 解析の観点も人が決定するため経験に依存する
判断まで自動化し属人性を低くする
• 全量ログを生かした機械学習！

27. ‐ 29 ‐
異常値に関連する指標を探す – まずは可視化
 データを眺めてみる
日別週別
同時刻間の変化は小さい
リクエスト数
全リクエスト GET/PUTのみ
機械学習

28. ‐ 30 ‐
異常値に関連する指標を探す
シンプルな指標の変化をみてみる
• 例: 速度(bps)・バイト数(in/out) 比の上位１％
を閾値に異常なアクセスであるか判定する
うまくいかない
• 顧客環境に影響を受ける
 方針転換
• 機械学習のアルゴリズムを使う
• 閾値による検出から、ユーザの利用傾向の変化に
よる検出へ
機械学習

29. ‐ 31 ‐
機械学習を実際に使う
適切なアルゴリズムを選ぶための試行錯誤
• LOF, SVM, PCA, k-NN, …
• パラメータ数を増やし、適切な特徴量を探す
• 処理速度・バイト数に加えてユーザー、APIの種別など
機械学習

30. ‐ 32 ‐
密度が周りに比べて薄い点を異常値とする
• 青い枠内に検出値(赤丸)が入ればGoodと判断(今回は)
不採用
LOF (Local Outlier Factor)
小 PUT されるデータのサイズ 大
小転送速度(bps)大
機械学習

31. ‐ 33 ‐
一定数あるはずの異常値と正常値の切り分け方を
探す
採用
SVM (One-class SVM)
小 PUT されるデータのサイズ 大
小転送速度(bps)大
機械学習

32. ‐ 34 ‐
解析してみて
サービスを包括していろいろ測れるように
なった
• メンテナンス時やアップデートの性能の変化
• 顧客の利用傾向の変化
大変なのはデータの用意と読み解き方
• どんなアルゴリズムが適切か試行錯誤が必要
簡単な機械学習の適用ならすぐできる
• R ライブラリが充実している
• 試行錯誤がとても楽になる

33. ‐ 35 ‐
まとめ

34. ‐ 36 ‐
まとめ
やったこと
• ユーザーアクセスログのリアルタイム可視化
• Flume、Esper、Elasticsearch、Kibana
• 機械学習でのアクセス傾向分析
• Hive (ストレージ＆アナリシスサービス)、R
できたこと
• 可視化
• 障害の全体像把握
• 需給予測
• 傾向分析
• 予防的なパフォーマンス改善

35. ‐ 37 ‐
まとめ
感想
• 簡単な解析でも思っているよりずっといろんなこ
とがやりやすくなる
• より客観的・継続的な改善のためにデータ分析を
軸にした方法は有用
これからやりたいこと
• バックエンドのアプリログの解析・可視化
• APIサーバーのリソース消費
• ストレージの利用傾向分析