クラウドではじめるリアルタイムデータ分析 #seccamp

セキュリティ・ミニキャンプ in 四国 2018（徳島） クラウドではじめる リアルタイムデータ分析 2018-03-03 @ひなまつり 株式会社WHERE IoT基盤センター 仲山 昌宏 / @nekoruri

自己紹介 • 株式会社WHERE IoT基盤センター サービスプロデューサー（2016-） • セキュリティ・キャンプ（2015-） 講師・プロデューサー • SecHack365 実施協議会（2017-） • 技術系同人誌サークル「めもおきば」 • ProjectDIVA Arcade LV.624

株式会社WHERE • Bluetoothメッシュネットワークによる ソリューションを提供 • BLEデバイスの開発、生産、施工 • ソリューションシステム およりアプリ等の開発

午前「サーバのログ収集と解析入門」 のおさらい • ログ管理の重要性 • OWASP Top 10 – 2017: A10 Insufficient Logging & Monitoring • システム障害（の予兆）の検知、不正アクセスの痕跡調査 などなど…… • OSS “Graylog” で実際にログを追ってみた • Elasticsearch • アラート機能（Slack webhook） • Elastic Beats

※注意：明確に区別されるものばかりではありません 「ログ」の二種類の目的 いま必要な行動を知るためのログ サービス改善などのためのログ • システムエラー • 404エラーのアクセスログ • リソース利用状況 • ユーザ別の行動ログ • 長時間でのリソース利用傾向

※注意：明確に区別されるものばかりではありません 「ログ」の二種類の目的 いま必要な行動を知るためのログ サービス改善などのためのログ • システムエラー • 404エラーのアクセスログ • リソース利用状況 • ユーザ別の行動ログ • 長時間でのリソース利用傾向 • 閾値などによるアラート • データ分析結果に基づく評価

※注意：明確に区別されるものばかりではありません 「ログ」の二種類の目的 いま必要な行動を知るためのログ • システムエラー • 500エラーのアクセスログ • リソース利用状況 • 閾値などによるアラート • リアルタイム性 • 常時走り続ける • アラート通知 • ダッシュボード表示 • エスカレーション

※注意：明確に区別されるものばかりではありません 「ログ」の二種類の目的 サービス改善などのためのログ • 大量のデータ • 複雑な集計条件 • 必要に応じて都度分析も • それでもできる限り リアルタイムで知りたい • ユーザ別の行動ログ • 長時間でのリソース利用傾向 • データ分析結果に基づく評価

必要なときに必要なだけ • プログラマエンジニアの三大美徳 • 怠惰：大量のログを処理する基盤を自分で管理するのは面倒 • 短期：分析を行うときは速い速度が欲しい • 傲慢：必要と言われたら必要なだけの分析を行いたい

必要なときに必要なだけ • プログラマエンジニアの三大美徳 • 怠惰：大量のログを処理する基盤を自分で管理するのは面倒 • 短期：分析を行うときは速い速度が欲しい • 傲慢：必要と言われたら必要なだけの分析を行いたい • コンピュータサイエンスによる技術進歩 ⇒クラウドコンピューティング

クラウドコンピューティング https://www.ipa.go.jp/files/000025366.pdf 11

• https://www.ipa.go.jp/files/000025366.pdf

クラウドコンピューティング https://www.ipa.go.jp/files/000025366.pdf 12

• https://www.ipa.go.jp/files/000025366.pdf

クラウドコンピューティング • 要点 • 共用されたリソースプールから • いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 13

「所有」から「利用」へ • サーバを所有しない • サービス部門は物理的なサーバを直接持たない • サーバやデータセンター、ネットワークの管理をしない • サーバを利用する • 必要な時間だけ、サーバの利用権を買う（借りる） • その道の匠が設計した素敵なサーバ環境を利用できる 14

「所有」から「利用」へ • サーバを所有しない • サービス部門は物理的なサーバを直接持たない • サーバやデータセンター、ネットワークの管理をしない • サーバを利用する • 必要な時間だけ、サーバの利用権を買う（借りる） • その道の匠が設計した素敵なサーバ環境を利用できる • 彼らの考えた「ベストプラクティス」に自分を合わせる 15

「所有」から「利用」へ • そもそも所有するべき技術を絞り込む • クラウド基盤の運用は、自分たちのビジネス領域では無い • 自ら技術者を確保するコストは決して安くない • 「利用」することで、自らのコア事業に集中できる ↔「技術」を知っていることは悪では無い • 内部を知っているほど最適な設定が導き出せる • トラブルシュート（とにかく全方位の能力が問われる） 16

コンピューティングの抽象化の進歩 • これまで：サーバ＝ペット🐕🐈 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • いま：サーバ＝家畜🐖🐓 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す。慈悲は無い。 • これから：サーバ？知らない子ですね…… • 大規模畜産業から出てきた肉や牛乳を買う • 「彼ら」の方がずっと上手く動物を育てられる 17

過渡期だから面白い • 「サーバ」前提の仕組みから「サーバ」を意識しない仕組みへ ⇒ 「サーバーレス」 • まだまだ過渡期 • サーバ：柔軟あるシステムを自由に開発できる • サーバーレス：様々な「制約」のもとに巨大なシステムを実現できる • 過渡期が故の面白さ • 「ベストプラクティス」は俺達が作る！！

というわけで • 今日は、クラウドを使ったデータ分析を体験してもらいます • ポイント • サーバーレスに実現している部分、サーバの上で実現している部分 • データが増えたときにどこが大変になるだろうか • リアルタイムって？

＜補足資料＞ 今回のハンズオンに必要なもの • GCPアカウント • 自分のメールアドレス、クレジットカード等で登録してください。 • Twitterのアプリケーション登録 • https://apps.twitter.com から登録して、 コンシューマキー・コンシューマシークレットを取得してください。 • Redashディスクイメージ • 以下に従ってRedashのイメージをプロジェクトに登録してください。 • https://redash.io/help-onpremise/setup/setting-up-redash-instance.html

• https://apps.twitter.com/
• https://redash.io/help-onpremise/setup/setting-up-redash-instance.html

今回使うクラウド • Google Cloud Platform • おなじみGoogleが提供するパブリッククラウド • 選んだ理由 • BigQueryがよくできている • SSHログインなどがブラウザで完結するのでハンズオンしやすい

全体像 Twitter BigQuery コントロールパネル output filter input Fluentd VMインスタンス BigQuery Redash VMインスタンス Google Cloud Platform

手順 1. 2. 3. 4. 5. 6. Fluentd用のVMをGoogle Cloud Platform上で作成 Twitterからデータを取ってくる設定を入れる BigQueryにデータを送る設定を入れる BigQueryのコントロールパネルでデータを見てみる Redash用のVMを作成 RedashでBigQueryにあるデータを見てみる

全体像 Twitter ④ BigQuery コントロールパネル filter input output ③ ② Fluentd VMインスタンス ① BigQuery Redash ⑥ VMインスタンス ⑤ Google Cloud Platform

最初に • データセットの名前などに自分の名前を使います • 名前が被らなければ、名字アルファベットを使ってください • 例：仲山 ⇒ nakayama • 注意事項：今回はTwitterのユーザを使います • 本日の講義が終わったらアプリを削除しますが、それまでの間、 アプリの管理者（仲山）が利用したTwitterユーザの情報を取得 できてしまう権限を持っています。 • 必要に応じて、新規Twitterアカウントを作成して下さい。

Google Cloud Platformにログイン • 以下のURLを開く • https://cloud.google.com • 右上のログインをクリック • 自分に割り当てられたメールアドレス・パスワードでログイン • 初回ログインで色々表示されますがそのまま進んで下さい。 • プロジェクトの一覧が出るので、デモ用のプロジェクトを選択 • seccamp2017-tokushima • 権限のエラーが出たら、左上の (三) からホームを選択

• https://cloud.google.com/

自分の作業用VMインスタンスを構築 • GCPでは仮想サーバを「VMインスタンス」と呼びます • 左上 (三) から、「Compute Engine」をクリック • 「インスタンスを作成」をクリック

インスタンスの作成 自分の名前 • 右のように入力します。 asia-northeast1-a Ubuntu 16.04 LTS すべて(省略)を許可

インスタンスの作成 自分の名前 • こんなかんじ asia-northeast1-a • 入力できたら 「作成」をクリック Ubuntu 16.04 LTS すべて(省略)を許可

自分のVMにログイン • 作成したVMを確認して、右の「SSH」をクリック • 別ウインドウが開いて、SSHで接続します。

Twitterの接続情報を取得 • OAuthという仕組みを利用（いわゆるアプリ連携） • twurlコマンドをインストール sudo apt-get update sudo apt-get -y install ruby build-essential jq sudo gem install twurl • twurlコマンドでOAuth認証 twurl authorize ¥ --consumer-key ＜コンシューマキー＞ ¥ --consumer-secret ＜コンシューマシークレット＞ コンシューマキーと コンシューマシークレットは 別紙にて共有

Twitterの接続情報を取得 • URLが表示されるので、ブラウザで開く • アプリ連携の確認画面が出るので利用許可 $ cat .twurlrc --profiles: nekoruri: ＜コンシューマキー＞: username: nekoruri consumer_key: ＜コンシューマキー＞ consumer_secret: ＜コンシューマシークレット＞ token: ＜アクセストークン＞ secret: ＜アクセストークンシークレット＞ （省略） この情報を利用

FluentdでTwitterの情報を取得 • Fluentdをインストール • 簡単にインストールできるtd-agentパッケージを利用 curl -L https://toolbelt.treasuredata.com/sh/install-ubuntu-xenial-td-agent2.sh | sudo sh sudo td-agent-gem install fluent-plugin-twitter fluent-plugin-bigquery --no-ri --no-rdoc

FluentdでTwitterの情報を取得 • 写経タイム $ sudoedit /etc/td-agent/td-agent.conf （元々はいっている内容は全て削除） <source> @type twitter consumer_key ＜コンシューマキー＞ consumer_secret ＜コンシューマシークレット＞ access_token ＜アクセストークン＞ access_token_secret ＜アクセストークンシークレット＞ tag input.twitter timeline sampling lang ja output_format nest </source> <match input.twitter> @type stdout </match>

FluentdでTwitterの情報を取得 • 実行してみよう $ sudo service td-agent restart 30秒くらい待って $ sudo service td-agent stop $ less /var/log/td-agent/td-agent.log • ログになんかよく分からないデータがでている？ 日本語っぽい文字列は見えてる？

FluentdからBigQueryに送信 • 自分用のデータセット（データを入れる枠）を作る $ bq mk seccamp2017-tokushima:＜自分の名前＞

FluentdからBigQueryに送信
• 写経タイム2（前編）
$ sudoedit /etc/td-agent/td-agent.conf

<match input.twitter>
type stdout
</match>

この3行を削除、下を追加

<filter input.twitter>
@type record_transformer
renew_record true
enable_ruby true
keep_keys text,created_at,user,timestamp_ms
<record>
timestamp ${record["timestamp_ms"].to_i / 1000}
</record>
</filter>

FluentdからBigQueryに送信
• 写経タイム2（後編）
<match input.twitter>
@type bigquery
auth_method compute_engine
project seccamp2017-tokushima
dataset ＜自分の名前＞
table tweets
auto_create_table true
ignore_unknown_values true
schema [
{"name": "created_at", "type": "STRING"},
{"name": "timestamp", "type": "INTEGER"},
{"name": "text", "type": "STRING"},
{"name": "user", "type": "RECORD", "fields": [
{"name": "screen_name", "type": "STRING"}
]}
]
<inject>
time_key timestamp
time_format %s
</inject>
</match>

（前スライドの続き）

FluentdからBigQueryに送信 • 実行してみよう $ sudo service td-agent restart

BigQueryコントロールパネルから確認 • BigQueryのコントロールパネルを表示 • https://bigquery.cloud.google.com/welcome/seccamp2017-tokushima • 左上 (三) からBigQueryを開いていっても良いです • 左の一覧から自分の名前のデータセットをクリック • さらに「Tables」にある「tweets」をクリック • 上手くいっていれば、Detailsをクリックすると、 Streaming Buffer StatisticsのEstimated Rowsが増えて行きます

• https://bigquery.cloud.google.com/welcome/seccamp2017-tokushima

BigQueryコントロールパネルから確認 • 右上「Query Table」をクリック • 自分のテーブルから10件表示してみる SELECT * FROM [seccamp2017-tokushima:＜自分の名前＞.tweets] LIMIT 10; • 「セキュリティ」を含むツイートを見てみる SELECT * FROM [seccamp2017-tokushima:＜自分の名前＞.tweets] WHERE text CONTAINS 'セキュリティ' LIMIT 10

ここまででできたこと Twitter BigQuery コントロールパネル output filter input Fluentd BigQuery SQLを書いていけば、 様々な分析が可能 VMインスタンス Google Cloud Platform

BIツールで可視化してみよう • 今回はRedashを使います • OSSでも配布しているし、サービスとしても提供している • 今回はOSS版を利用して自分で動かします • Graylogとの違い • ログに限定しない分、自分で色々決めて設定しないといけない • Elasticsearchに限らず、様々なデータベースに接続ができる

Redash環境の構築 • Redash用のVMインスタンスを作成 • 左上 (三) からCompute Engineを開く • 「インスタンスを作成」 • 以下のように入力 • • • • • 名前：「名前-redash」 ゾーン：asia-northeast1-a ブートディスク：次スライドで解説 アクセス範囲：すべての～～～を許可 ファイアウォール：HTTPトラフィックを許可

Redash環境の構築 • ブートディスクの選択 • 「カスタムイメージ」タブを選択 • 「redash-2-0-0」を選択

Redashを開く • 一覧画面で今作ったVMインスタンスを見つける • 外部IP欄に表示されるIPアドレスをブラウザで開く • すぐ右の矢印をクリックすれば別タブで開きます 自分の名前 メールアドレス パスワード 「seccamp」とか 適当に

Redashひらいた

RedashからBigQueryに接続 • 左上の「New Query」をクリック • 「Create Data Source」をクリック • 以下のように入力 • • • • Type： BigQueryGCE Name: bq ☑ Load Scheme Saveをクリック

BigQueryからデータを取ってみる • 上部メニュー「Queries」から「New Query」でSQL実行画面 • 自分のテーブルから10件表示してみる SELECT * FROM [seccamp2017-tokushima:＜自分の名前＞.tweets] LIMIT 10; • 「セキュリティ」を含むツイートを見てみる SELECT * FROM [seccamp2017-tokushima:＜自分の名前＞.tweets] WHERE text CONTAINS 'セキュリティ' LIMIT 10

複雑なクエリ例 • 「ネット」という文字を含むツイートの1分ごとの個数 SELECT SEC_TO_TIMESTAMP(timestamp / 60) * 60 AS time, AVG(count(text)) AS len_1mins_avg, FROM [seccamp2017-tokushima:nakayama.tweets] WHERE text CONTAINS 'ネット' GROUP BY time ORDER BY time DESC • 移動平均とかも出せます。

グラフ化してみよう • 検索結果の「+ NEW VISUALIZATION」をクリック • GENERALタブ • Chart Type: Line • X Column: time • Y Column: len_1mins_avg • X AXISタブ • Scale: Linear • Save • Refresh ScheduleのNeverをクリックして Every minuteに変更 • 右上のPublishをクリック

ここまででできたこと Twitter BigQuery コントロールパネル output filter input Fluentd VMインスタンス BigQuery Redash VMインスタンス Google Cloud Platform

発展： 様々なツイートの情報を見てみる • 仕様をチェック • https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/intro-to-tweet-json • 例：一定数以上RTやFavされたツイートを探してみる • 方針：FluentdでBigQueryに送るデータを追加 • <filter input.twitter>のkeep_keys に記録したいフィールドを追加 • <match input.twitter>のschemaにそれっぽく追加

• https://developer.twitter.com/en/docs/tweets/data-dictionary/overview/intro-to-tweet-json

発展： システムのログを送ってみる • ElasticもいいけどFluentdでもできる • 様々な中間処理や送り先のプラグインの豊富さが特徴 • 午前のおさらい：構造化ログの重要性 • 今出力されているログが構造化されていないなら Fluentdでパースして構造化する

発展： 様々な分析をしてみる • 自分のタイムラインで、直近5分間にツイートした人数 • 方針： • Fluentdで自分のタイムラインを取得してみるには？ • 直近5分でツイートした人数を数えるには？ ヒント：screen_nameのユニークな個数

ところでリアルタイムって？ • データの発生から、一定時間以内にそれが処理されること • 現実には、様々な「リアルタイム」の敵が…… • • • • データ送る側の処理遅延 クラウドまで転送するときの遅延（特にモバイル通信） 分析処理じたいに掛かる時間 途中で順番すら入れ替わる

ところでリアルタイムって？ • 厳密には2つの「時間」を分けて考える必要がある • データの発生時刻（EventTime） • データの処理時刻（ProcessingTime） • 「リアルタイム」≒「何かをあきらめること」 • 要件(仮)：データの分析結果は5分以内に欲しい！ • 実装方針：5分以上遅れたデータは無視せざるを得ない • 3つのトレードオフ • 完全性、低遅延、低コスト

ラムダアーキテクチャ • データの分析を2種類に分ける • ざっくり今を知るためのリアルタイム分析 • 最終的に正確な結果を知るためのバッチ分析 例：リアルタイムで売上傾向も 知りたいが、最終的な集計数字 がズレるのもまずい

ラムダアーキテクチャ • データの分析を2種類に分ける λ • ざっくり今を知るためのリアルタイム分析 • 最終的に正確な結果を知るためのバッチ分析 入力 リアルタイム分析 バッチ分析 ※トレードオフの説明のため、 ものすごく簡略に雑にまとめています。

高度なリアルタイム分析 • 今回のBigQuery集計 • リアルタイムでデータを集計できる、にすぎない • より高度なリアルタイム分析 • 入ってきたデータを逐次処理して積み重ねる • 機械学習なども交えたデータ処理の積み重ね ⇒ 「ストリーム処理」という技術領域

様々なデータ分析の枠組み • クラウド • 今日使ったBigQuery（Google） • ストリーム処理のサービスも増えてきている • Google Cloud Dataflow、 AWS Kinesis Stream Analytics、Azure Stream Analytics • ミドルウェア • Apache Spark（Spark Streaming)などなど

まとめ • クラウドを利用したリアルタイムデータ分析 • サーバを使ったFluentdによるデータ収集、蓄積 • BigQueryによる様々な分析 • Redashによる可視化 • より高度な「ストリーム処理」 • 自分で手を動かしてみよう！

最後に • 特にこの10年のインフラ業界は動きが早いです • クラウドが登場して（まだ）12年間 • 前提が変わり、ベストプラクティスが入れ替わる • 個人的には、 ・この10年で物理サーバからクラウド上の仮想サーバに ・今後10年でサーバという枠組みから解放 と予想しています • ツールレベルの盛衰は、一々取り上げるのも切りが無い • 動きが早い＝面白い！ 63

最後に • すぐに手を動かそう！ • 無料クーポン、無料枠を活用しよう（学生はより有利！） • 大きな機能もちょっとだけなら安くお試しできる！ • とにかくネタと機会を作って情報を発信しよう！ • • • • 情報は活動する人の近くに集まる ブログ等での情報発信 勉強会等での発表 同人誌等の制作、頒布 64