Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

【18-B-2】データ分析で始めるサービス改善最初の一歩

1,261 views

Published on

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

Published in: Technology
  • Be the first to comment

【18-B-2】データ分析で始めるサービス改善最初の一歩

  1. 1. (株) インターネットイニシアティブ 石原 翔真 データ分析で始めるサービス改善初めの一歩 #devsumiB【18-B-2】
  2. 2. ‐ 2 ‐ 自己紹介 石原翔真 株式会社インターネットイニシアティブ 入社2年目 クラウドサービスの開発・運用を担当
  3. 3. ‐ 3 ‐ 発表内容 サービスのログを分析し、様々な改善に活用 するための第一歩を踏み出した話 Elasticsearch, kibana, Flume, Hive, R… これから始める方向け
  4. 4. ‐ 4 ‐ これまでの運用
  5. 5. ‐ 5 ‐ 運用しているサービス IIJ GIO ストレージ&アナリシスサービス • S3互換のストレージとHiveによる解析機能を提供 ストレージ ユーザからの大量のアクセス (HTTP(s), PUT/GET/DELETE等) 解析機能 解析対象 = ストレージへのアクセス 解析ツール = 自社サービス + α
  6. 6. ‐ 7 ‐ これまでの運用  単発の障害検知を目的にした監視システム • 社内共通の監視基盤 (ping, snmp 等) • munin • エラーログ収集 ユニットテスト/結合テスト中心の自動化 • 定常的なパフォーマンス計測については手薄
  7. 7. ‐ 8 ‐ できていなかったこと サービス利用の全体傾向をつかむこと • 障害の全体像がわからない • 需要予測がしづらい • 予防的なパフォーマンス改善ができない ログを収集・分析することで実現する!!
  8. 8. ‐ 9 ‐ ログ収集と可視化 【この取り組みで解決した課題】  障害の全体像がわからない  需要予測がしづらい
  9. 9. ‐ 10 ‐ 利用傾向をつかむために 手始めにログ収集・可視化に取り組む • Flume でのログ収集 • Elasticsearch への蓄積, kibana による可視化 リクエスト単位での利用傾向を確認する
  10. 10. ‐ 11 ‐ ツール その1 - Elasticsearch/kibana Elasticsearch kibana
  11. 11. ‐ 12 ‐ ツール その2 - Flume ログ転送ツール • 類似のツール: Fluentd、Logstash Flume の構造 • Source, Channel, Sink の三段構成 • 連携するツールに合わせてプラグインを自作可能
  12. 12. ‐ 13 ‐  各サーバから集めたログはElasticsearchへ格納され、 kibanaで可視化される 構成 IIJ GIO ストレージ&アナリシスサービス Apache ストレージAPI Apache 解析API Flume Flume Log Log Log Log Log Log インターネット
  13. 13. ‐ 14 ‐ 問題点 ログの量が多い • 1日のログの容量がtotal 20GB • 20GB × 365 = 7TB over… • そのままでは長期間のログ保管ができない • お客様が増えるとさらにつらい 「有用な」ログの選別がつらい • モジュールごとにフォーマットや取得できる値は ばらばら • スタックトレースがそのまま吐かれている
  14. 14. ‐ 15 ‐ 対策 : 収集するログを絞る Apacheアクセスログのみ • ユーザー利用傾向だけなら十分 • ログの大部分はアプリのトレースログだった Flume に Esper を組み込んで集約 • (株)サイバーエージェント様の事例を参考に実装 • CyberAgent Tech Report: FlumeとEsperを用いたSQLライクな クエリによるストリーム処理 https://www.cyberagent.co.jp/techinfo/techreport/report/id=7872 ログの収集
  15. 15. ‐ 16 ‐ Esper CEP (複合イベント処理) エンジン • SQL ライクにイベントデータの操作が可能 ログ集約に活用 • 一定時間ごとにログを集計し、アクセス総件数や 処理時間の最大値・平均値などを計算 • Elasticsearch には集計した値のみを投入 • Flume に組み込む ログの収集
  16. 16. ‐ 17 ‐ Flumeのカスタマイズ 自作 Interceptor で Esper を走らせる • Interceptor: Source内で受け取ったログデータ の変形・フィルタを行う ログの量を 1/10 に抑えられた Log LogEsper ログの収集
  17. 17. ‐ 18 ‐ kibana で可視化 Elasticsearch/kibana 連携は容易 アクセス件数、HTTPメソッドの割合、処理 時間の分布などを可視化 可視化・解析
  18. 18. ‐ 19 ‐ Elasticsearch に投入 可視化する項目を選ぶ際に試行錯誤 • Kibanaで可視化するためにはMapping Templateを設定する必要がある • スキーマに相当 • 項目の選択、可視化を繰り返して有用な可視化対 象の項目を探した 注意点 • Indexの定期的な削除 • インデックスはGBオーダー 可視化・解析
  19. 19. ‐ 20 ‐ Kibana で可視化  ログ集約の結果、分布図が書けなくなった.. • 左: データサイズ 右: レスポンスタイム 可視化・解析
  20. 20. ‐ 21 ‐ 現在 アクセス傾向はつかめるようになった ログの収集可視化は簡単!でも……収集する ことを前提に設計するべき • 収集の枠組みを後付けで作ったことで苦労した • 集める前提でログを作り込む • ログフォーマットの統一 • 収集する情報の選別
  21. 21. ‐ 22 ‐ 解析 【この取り組みで解決した課題】  予防的なパフォーマンス改善
  22. 22. ‐ 23 ‐ ログを可視化したが・・・ 可視化だけでは不足していた点 • 人の目に頼った判断 • 情報が落ちている より詳細に傾向の変化を把握して、能動的に 改善していきたい • Hive による全アクセスログの集計 • R 機械学習ライブラリによる傾向の変化の検知
  23. 23. ‐ 24 ‐ 解析の流れ ログ収集対象 (今回はストレージ自身) 1. アクセス ログの取得 2. データの整 形・フィルタ IIJ GIO ストレージ&アナリシスサービス 4. データ・アルゴリズムへの フィードバック 解析端末 3. 解析アルゴリズムの適用 フィードバック
  24. 24. ‐ 25 ‐ データの収集 Flume でアクセスログを収集 • オブジェクトストレージにPUTするSinkを自作 ストレージ&アナリシスサービス 解析API で整形・クレンジング • ストレージに蓄積したログを Hive で処理 ログ収集対象 1. アクセス ログの取得 2. データの整 形・フィルタ IIJ GIO ストレージ&アナリシスサービス
  25. 25. ‐ 26 ‐ 解析してみて  例: API アップデート前後の処理時間の変化 • 改修により性能向上し、遅いリクエストが無くなったことが判る • 緑の点がアップデート前、桃色の点がアップデート後 小リクエスト処理時間大 小 レスポンスサイズ 大 アップデート前 〃後 小リクエスト処理時間大 全アクセスログ解析
  26. 26. ‐ 28 ‐ 次の一歩 ログを全量手に入れて分析できた しかしまだ属人性が高い • 人の目で結果を判断をする • 解析の観点も人が決定するため経験に依存する 判断まで自動化し属人性を低くする • 全量ログを生かした機械学習!
  27. 27. ‐ 29 ‐ 異常値に関連する指標を探す – まずは可視化  データを眺めてみる 日別週別 同時刻間の変化は小さい リクエスト数 全リクエスト GET/PUTのみ 機械学習
  28. 28. ‐ 30 ‐ 異常値に関連する指標を探す シンプルな指標の変化をみてみる • 例: 速度(bps)・バイト数(in/out) 比の上位1% を閾値に異常なアクセスであるか判定する うまくいかない • 顧客環境に影響を受ける  方針転換 • 機械学習のアルゴリズムを使う • 閾値による検出から、ユーザの利用傾向の変化に よる検出へ 機械学習
  29. 29. ‐ 31 ‐ 機械学習を実際に使う 適切なアルゴリズムを選ぶための試行錯誤 • LOF, SVM, PCA, k-NN, … • パラメータ数を増やし、適切な特徴量を探す • 処理速度・バイト数に加えてユーザー、APIの種別など 機械学習
  30. 30. ‐ 32 ‐ 密度が周りに比べて薄い点を異常値とする • 青い枠内に検出値(赤丸)が入ればGoodと判断(今回は) 不採用 LOF (Local Outlier Factor) 小 PUT されるデータのサイズ 大 小転送速度(bps)大 機械学習
  31. 31. ‐ 33 ‐ 一定数あるはずの異常値と正常値の切り分け方を 探す 採用 SVM (One-class SVM) 小 PUT されるデータのサイズ 大 小転送速度(bps)大 機械学習
  32. 32. ‐ 34 ‐ 解析してみて サービスを包括していろいろ測れるように なった • メンテナンス時やアップデートの性能の変化 • 顧客の利用傾向の変化 大変なのはデータの用意と読み解き方 • どんなアルゴリズムが適切か試行錯誤が必要 簡単な機械学習の適用ならすぐできる • R ライブラリが充実している • 試行錯誤がとても楽になる
  33. 33. ‐ 35 ‐ まとめ
  34. 34. ‐ 36 ‐ まとめ やったこと • ユーザーアクセスログのリアルタイム可視化 • Flume、Esper、Elasticsearch、Kibana • 機械学習でのアクセス傾向分析 • Hive (ストレージ&アナリシスサービス)、R できたこと • 可視化 • 障害の全体像把握 • 需給予測 • 傾向分析 • 予防的なパフォーマンス改善
  35. 35. ‐ 37 ‐ まとめ 感想 • 簡単な解析でも思っているよりずっといろんなこ とがやりやすくなる • より客観的・継続的な改善のためにデータ分析を 軸にした方法は有用 これからやりたいこと • バックエンドのアプリログの解析・可視化 • APIサーバーのリソース消費 • ストレージの利用傾向分析

×