tsalakh ain sus noam Huyah ol guf

勉強会のメモ。その他備忘録。参考にさせて頂いたサイトや資料はリンクさせて頂いていますが不都合があればご連絡ください。

【勉強会】db tech showcase 2017 2日目

noindex

db tech showcase 2017 2日目

www.db-tech-showcase.com

InfluxDBで時系列データの異常検知

  • 笹谷泰輔さん

InfluxDB+αで時系列データの異常検知を可視化してみた

www.slideshare.net

TICKスタック

  • Telegraf：集める（SystemStats/MySQL/Docker/etc.）
  • InfluxDB：溜める
  • Chronograf：可視化する
  • Kapacitor：処理する

今日の話

  • 時系列データの「いつもと違う」をリアルタイムに検知したい
  • 一般的な統計量では警告が上がりすぎる Kapacitorならうまいことできる

時系列DBとは

  • タイムスタンプと値をセットで持つもの
  • InfluxDBはタイムスタンプの他に、タグとフィールドを持たせられる
    • タグはインデックスされるKey/Value
    • フィールドはインデックスされないKey/Value

Telegrafはデフォルトだと文字列が入らない confで事前定義すれば入る

まとめ

  • 導入は簡単、操作設定は特有
  • OSSなので全て無料でできる
  • python使わなければDockerですぐ使える

Retz と Apache Mesos で作る統合バッチ環境

  • 上西康太さん

speakerdeck.com

背景

  • 単体コンピュータの性能が上がってきた
  • データが全てメモリに乗る規模、マルチコアを使いこなせば性能向上は簡単
  • のはずが、マルチスレッド処理を早く安全に書くのは難しい
  • フレームワークが欲しい

→そこで、M3BP

リソースの利用率を上げるためにリソーススケジューラがほしい

  • Jenkins ：柔軟性が高くプラグインも豊富だが、ジョブキューとしては不十分
  • YARN：Hadoop系プロダクトじゃないと乗せにくい
  • Mesos：完成度も自由度も高いが、スケジューラを自作する必要がある

Mesosは「リソース管理」と「スケジューリング」をしてくれる

  • リソース管理：サーバ資源の数値化、死活監視
  • スケジューリング：アプリに資源を割り当ててタスク実行、タスクの状態監視と成否通知

Mesos Framewark API

  • 基本的に非同期的なプログラミングにならざるをえない
  • つかいにくい
  • 使いやすいものを作ろう

→Retz

Retz

  • いわゆる「ジョブキュー」
  • ジョブを渡すと、リソースが空いた順にジョブを実行する
  • MesosのAPIとUIを完全隠蔽することを目指す

RetzとMesosの関係は、アプリとカーネルの関係に似てる Computer資源を隠蔽するのがカーネル（Mesos）、アプリ（Retz）はカーネルやり取り

障害時の自動的な再実行 完璧ではない、アプリのバグだと防げなかったり

事例 さくらの石狩DC、DCの原価計算システム Asakusa on SparkからAsakusa on M3BPに移行 MapR FS/YARN/Asakusa on Spark/Jenkins MapR FS/Retz/Mesos/Asakusa on M3BP/Digdag

Jenkinsだとジョブが深くなった時の障害が追いにくい、リカバリ大変→Digdag

まとめ

１台で動くジョブ数：バッチサーバが、m:nの場合に高可用に実行可能

NewRelic

New Relicの特徴

  1. SaaS型の監視サービス
  2. アプリ監視のみでなく、サービス全体を広く監視できる

New Relicの機能概要

  • アプリ監視
  • インフラリソース状況
  • インベントリ管理
  • MW、プロセス死活監視
  • DB接続
  • ネットワーク監視
  • UX監視
  • 外形監視
  • ダッシュボード
  • アラート

APMのキモ

ボトルネックの詳細→深掘り→分析

サービスマップ モニタリング対象のサービスと、連携する外部サービスの相関

DB観点では、

INFRASTRUCTURE

  • 複数台のサーバで1つのサービスを提供している場合に有効
  • イベントの発生状況
  • リアルタイムのインベントリ管理
  • AWS各種サービス監視の統合も可能

INSIGHTS

  • 統合ダッシュボード、New Relicの各機能を１枚で
  • GoogleAnalyticsの内容も出せる

これまでの監視は定型的な分析 New Relicはアドホックな分析 全体の変調を大枠で捉えて、

「スペシャリストでなくても見える」というのがポイント

クエリのVALUES部分をマスクすることは、New Relicの設定で変更可能 メトリクスの収集はHTTPS Detailsを開くと、実行計画の内容を表示、簡単な分析とヒントも表示できる

「DBエンジニア」ではない人でもここまで辿り着ける

トップダウンアプローチで性能問題を追跡できる アプリエンジニアとインフラエンジニアの仲の悪さが問題ではなくなる

LITEプラン スロークエリのクエリ文が見られない（オーバービューは見れる） INFRASTRUCTUREが見られない

Kafka

www.slideshare.net

ElasticStackによる異常検知

大谷さん

Beatsは現在30を超えるコミュニティ、増加中 WINGLOGBEAT、Windowsのイベント収集 モジュールが増えてる、MWのログ拾えそう Beatsを使うと、ダッシュボードまで自動生成してくれる PacketBeat使ってMySQLやPostgresのポートを設定すると、クエリが拾える（SSLだとダメ）

Elasticsearch Wikipedia、はてブ、日経電子版でも利用されている 今後SQLに対応予定

多段Aggregationも可能になっている

LogStashで「grok」使うと、正規表現に名前をつけられる 正規表現を手書きしなくてよくなる

Hadoopにすでにデータが溜まってる場合、プラグイン入れるとkibanaで見れる

X-Pack サブスクリプション

Monitoring

  • Elasticsearchのクラスタのモニタリングができる
  • データはElasticsearch内にたまるのでkibanaで見れる

Alerting

  • 通知出せる
  • 閾値検知じゃなくてクエリベースでも出せる

  • 時系列の異常
    • いつもと違う傾向の検知
  • アタックの検知
    • 特定のIPで見たときにHTTPステータスの割合が他と違うとか
  • レアなログメッセージ
    • ログの文字列の構造で比較ができるので

可視化すれば異常が目で見えるか、というとそうでもない 「教師なし」の機械学習で異常を検知する（正常の定義は不要） ただし、最初のうちは学習できてないので検知不可

デモ：ニューヨークのタクシー利用データ

デモのデータなら、1-2週間のデータで学習結果が収束してくる ぱっと見周期性がありそうでも、分析するとハズレ値が出てくる

レシピも公開されてる、詳しくはブログ（日本語版の）