クラウドではじめるリアルタイムデータ分析 #seccamp
•
6 gefällt mir•2,132 views
2018-03-03 セキュリティ・ミニキャンプ in 四国 2018（徳島） 専門講義「クラウドではじめるリアルタイムデータ分析」
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (9)
Ähnlich wie クラウドではじめるリアルタイムデータ分析 #seccamp
Ähnlich wie クラウドではじめるリアルタイムデータ分析 #seccamp (20)
Mehr von Masahiro NAKAYAMA
Mehr von Masahiro NAKAYAMA (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
クラウドではじめるリアルタイムデータ分析 #seccamp
- 1. クラウドではじめる リアルタイムデータ分析 2018-03-03 @ひなまつり 株式会社WHERE IoT基盤センター 仲山 昌宏 / @nekoruri セキュリティ・ミニキャンプ in 四国 2018（徳島）
- 2. 自己紹介 • 株式会社WHERE IoT基盤センター サービスプロデューサー（2016-） • セキュリティ・キャンプ（2015-） 講師・プロデューサー • SecHack365 実施協議会（2017-） • 技術系同人誌サークル「めもおきば」 • ProjectDIVA Arcade LV.624
- 3. 株式会社WHERE • Bluetoothメッシュネットワークによる ソリューションを提供 • BLEデバイスの開発、生産、施工 • ソリューションシステム およりアプリ等の開発
- 4. 午前「サーバのログ収集と解析入門」 のおさらい • ログ管理の重要性 • OWASP Top 10 – 2017: A10 Insufficient Logging & Monitoring • システム障害（の予兆）の検知、不正アクセスの痕跡調査 などなど…… • OSS “Graylog” で実際にログを追ってみた • Elasticsearch • アラート機能（Slack webhook） • Elastic Beats
- 5. 「ログ」の二種類の目的 いま必要な行動を知るためのログ • システムエラー • 404エラーのアクセスログ • リソース利用状況 サービス改善などのためのログ • ユーザ別の行動ログ • 長時間でのリソース利用傾向 ※注意：明確に区別されるものばかりではありません
- 6. 「ログ」の二種類の目的 いま必要な行動を知るためのログ • システムエラー • 404エラーのアクセスログ • リソース利用状況 • 閾値などによるアラート サービス改善などのためのログ • ユーザ別の行動ログ • 長時間でのリソース利用傾向 • データ分析結果に基づく評価 ※注意：明確に区別されるものばかりではありません
- 7. 「ログ」の二種類の目的 いま必要な行動を知るためのログ • システムエラー • 500エラーのアクセスログ • リソース利用状況 • 閾値などによるアラート ※注意：明確に区別されるものばかりではありません • リアルタイム性 • 常時走り続ける • アラート通知 • ダッシュボード表示 • エスカレーション
- 8. 「ログ」の二種類の目的 サービス改善などのためのログ • ユーザ別の行動ログ • 長時間でのリソース利用傾向 • データ分析結果に基づく評価 ※注意：明確に区別されるものばかりではありません • 大量のデータ • 複雑な集計条件 • 必要に応じて都度分析も • それでもできる限り リアルタイムで知りたい
- 9. 必要なときに必要なだけ • プログラマエンジニアの三大美徳 • 怠惰：大量のログを処理する基盤を自分で管理するのは面倒 • 短期：分析を行うときは速い速度が欲しい • 傲慢：必要と言われたら必要なだけの分析を行いたい
- 10. 必要なときに必要なだけ • プログラマエンジニアの三大美徳 • 怠惰：大量のログを処理する基盤を自分で管理するのは面倒 • 短期：分析を行うときは速い速度が欲しい • 傲慢：必要と言われたら必要なだけの分析を行いたい • コンピュータサイエンスによる技術進歩 ⇒クラウドコンピューティング
- 13. クラウドコンピューティング • 要点 • 共用されたリソースプールから • いつでもどこからでもネットワーク経由で • 必要な分だけをすぐに利用できる 13
- 14. 「所有」から「利用」へ • サーバを所有しない • サービス部門は物理的なサーバを直接持たない • サーバやデータセンター、ネットワークの管理をしない • サーバを利用する • 必要な時間だけ、サーバの利用権を買う（借りる） • その道の匠が設計した素敵なサーバ環境を利用できる 14
- 15. 「所有」から「利用」へ • サーバを所有しない • サービス部門は物理的なサーバを直接持たない • サーバやデータセンター、ネットワークの管理をしない • サーバを利用する • 必要な時間だけ、サーバの利用権を買う（借りる） • その道の匠が設計した素敵なサーバ環境を利用できる • 彼らの考えた「ベストプラクティス」に自分を合わせる 15
- 16. 「所有」から「利用」へ • そもそも所有するべき技術を絞り込む • クラウド基盤の運用は、自分たちのビジネス領域では無い • 自ら技術者を確保するコストは決して安くない • 「利用」することで、自らのコア事業に集中できる ↔「技術」を知っていることは悪では無い • 内部を知っているほど最適な設定が導き出せる • トラブルシュート（とにかく全方位の能力が問われる） 16
- 17. コンピューティングの抽象化の進歩 • これまで：サーバ＝ペット🐕🐈 • 1台1台名前を付けて、手間を掛けて育てていく • 少しおかしくなっても直して死ぬまで面倒を見る • いま：サーバ＝家畜🐖🐓 • 集団の役割だけを見て、1台ずつの個別の面倒は見ない • おかしくなったら殺す。慈悲は無い。 • これから：サーバ？知らない子ですね…… • 大規模畜産業から出てきた肉や牛乳を買う • 「彼ら」の方がずっと上手く動物を育てられる 17
- 18. 過渡期だから面白い • 「サーバ」前提の仕組みから「サーバ」を意識しない仕組みへ ⇒ 「サーバーレス」 • まだまだ過渡期 • サーバ：柔軟あるシステムを自由に開発できる • サーバーレス：様々な「制約」のもとに巨大なシステムを実現できる • 過渡期が故の面白さ • 「ベストプラクティス」は俺達が作る！！
- 19. というわけで • 今日は、クラウドを使ったデータ分析を体験してもらいます • ポイント • サーバーレスに実現している部分、サーバの上で実現している部分 • データが増えたときにどこが大変になるだろうか • リアルタイムって？
- 20. ＜補足資料＞ 今回のハンズオンに必要なもの • GCPアカウント • 自分のメールアドレス、クレジットカード等で登録してください。 • Twitterのアプリケーション登録 • https://apps.twitter.com から登録して、 コンシューマキー・コンシューマシークレットを取得してください。 • Redashディスクイメージ • 以下に従ってRedashのイメージをプロジェクトに登録してください。 • https://redash.io/help-onpremise/setup/setting-up-redash-instance.html
- 21. 今回使うクラウド • Google Cloud Platform • おなじみGoogleが提供するパブリッククラウド • 選んだ理由 • BigQueryがよくできている • SSHログインなどがブラウザで完結するのでハンズオンしやすい
- 23. 手順 1. Fluentd用のVMをGoogle Cloud Platform上で作成 2. Twitterからデータを取ってくる設定を入れる 3. BigQueryにデータを送る設定を入れる 4. BigQueryのコントロールパネルでデータを見てみる 5. Redash用のVMを作成 6. RedashでBigQueryにあるデータを見てみる
- 25. 最初に • データセットの名前などに自分の名前を使います • 名前が被らなければ、名字アルファベットを使ってください • 例：仲山 ⇒ nakayama • 注意事項：今回はTwitterのユーザを使います • 本日の講義が終わったらアプリを削除しますが、それまでの間、 アプリの管理者（仲山）が利用したTwitterユーザの情報を取得 できてしまう権限を持っています。 • 必要に応じて、新規Twitterアカウントを作成して下さい。
- 26. Google Cloud Platformにログイン • 以下のURLを開く • https://cloud.google.com • 右上のログインをクリック • 自分に割り当てられたメールアドレス・パスワードでログイン • 初回ログインで色々表示されますがそのまま進んで下さい。 • プロジェクトの一覧が出るので、デモ用のプロジェクトを選択 • seccamp2017-tokushima • 権限のエラーが出たら、左上の (三) からホームを選択
- 27. 自分の作業用VMインスタンスを構築 • GCPでは仮想サーバを「VMインスタンス」と呼びます • 左上 (三) から、「Compute Engine」をクリック • 「インスタンスを作成」をクリック
- 28. インスタンスの作成 • 右のように入力します。 自分の名前 asia-northeast1-a Ubuntu 16.04 LTS すべて(省略)を許可
- 29. インスタンスの作成 • こんなかんじ • 入力できたら 「作成」をクリック 自分の名前 asia-northeast1-a Ubuntu 16.04 LTS すべて(省略)を許可
- 31. Twitterの接続情報を取得 • OAuthという仕組みを利用（いわゆるアプリ連携） • twurlコマンドをインストール • twurlコマンドでOAuth認証 sudo apt-get update sudo apt-get -y install ruby build-essential jq sudo gem install twurl twurl authorize ¥ --consumer-key ＜コンシューマキー＞ ¥ --consumer-secret ＜コンシューマシークレット＞ コンシューマキーと コンシューマシークレットは 別紙にて共有
- 32. Twitterの接続情報を取得 • URLが表示されるので、ブラウザで開く • アプリ連携の確認画面が出るので利用許可 $ cat .twurlrc --- profiles: nekoruri: ＜コンシューマキー＞: username: nekoruri consumer_key: ＜コンシューマキー＞ consumer_secret: ＜コンシューマシークレット＞ token: ＜アクセストークン＞ secret: ＜アクセストークンシークレット＞ （省略） この情報を利用
- 33. 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
- 34. 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>
- 35. FluentdでTwitterの情報を取得 • 実行してみよう • ログになんかよく分からないデータがでている？ 日本語っぽい文字列は見えてる？ $ sudo service td-agent restart 30秒くらい待って $ sudo service td-agent stop $ less /var/log/td-agent/td-agent.log
- 36. FluentdからBigQueryに送信 • 自分用のデータセット（データを入れる枠）を作る $ bq mk seccamp2017-tokushima:＜自分の名前＞
- 37. FluentdからBigQueryに送信 • 写経タイム2（前編） $ sudoedit /etc/td-agent/td-agent.conf <match input.twitter> type stdout </match> <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> この3行を削除、下を追加
- 38. 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> （前スライドの続き）
- 39. FluentdからBigQueryに送信 • 実行してみよう $ sudo service td-agent restart
- 40. BigQueryコントロールパネルから確認 • BigQueryのコントロールパネルを表示 • https://bigquery.cloud.google.com/welcome/seccamp2017-tokushima • 左上 (三) からBigQueryを開いていっても良いです • 左の一覧から自分の名前のデータセットをクリック • さらに「Tables」にある「tweets」をクリック • 上手くいっていれば、Detailsをクリックすると、 Streaming Buffer StatisticsのEstimated Rowsが増えて行きます
- 41. BigQueryコントロールパネルから確認 • 右上「Query Table」をクリック • 自分のテーブルから10件表示してみる • 「セキュリティ」を含むツイートを見てみる SELECT * FROM [seccamp2017-tokushima:＜自分の名前＞.tweets] LIMIT 10; SELECT * FROM [seccamp2017-tokushima:＜自分の名前＞.tweets] WHERE text CONTAINS 'セキュリティ' LIMIT 10
- 43. BIツールで可視化してみよう • 今回はRedashを使います • OSSでも配布しているし、サービスとしても提供している • 今回はOSS版を利用して自分で動かします • Graylogとの違い • ログに限定しない分、自分で色々決めて設定しないといけない • Elasticsearchに限らず、様々なデータベースに接続ができる
- 44. Redash環境の構築 • Redash用のVMインスタンスを作成 • 左上 (三) からCompute Engineを開く • 「インスタンスを作成」 • 以下のように入力 • 名前：「名前-redash」 • ゾーン：asia-northeast1-a • ブートディスク：次スライドで解説 • アクセス範囲：すべての～～～を許可 • ファイアウォール：HTTPトラフィックを許可
- 45. Redash環境の構築 • ブートディスクの選択 • 「カスタムイメージ」タブを選択 • 「redash-2-0-0」を選択
- 46. Redashを開く • 一覧画面で今作ったVMインスタンスを見つける • 外部IP欄に表示されるIPアドレスをブラウザで開く • すぐ右の矢印をクリックすれば別タブで開きます 自分の名前 メールアドレス パスワード 「seccamp」とか 適当に
- 47. Redashひらいた
- 48. RedashからBigQueryに接続 • 左上の「New Query」をクリック • 「Create Data Source」をクリック • 以下のように入力 • Type： BigQueryGCE • Name: bq • ☑ Load Scheme • Saveをクリック
- 49. BigQueryからデータを取ってみる • 上部メニュー「Queries」から「New Query」でSQL実行画面 • 自分のテーブルから10件表示してみる • 「セキュリティ」を含むツイートを見てみる SELECT * FROM [seccamp2017-tokushima:＜自分の名前＞.tweets] LIMIT 10; SELECT * FROM [seccamp2017-tokushima:＜自分の名前＞.tweets] WHERE text CONTAINS 'セキュリティ' LIMIT 10
- 50. 複雑なクエリ例 • 「ネット」という文字を含むツイートの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
- 51. グラフ化してみよう • 検索結果の「+ 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をクリック
- 53. 発展： 様々なツイートの情報を見てみる • 仕様をチェック • 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にそれっぽく追加
- 54. 発展： システムのログを送ってみる • ElasticもいいけどFluentdでもできる • 様々な中間処理や送り先のプラグインの豊富さが特徴 • 午前のおさらい：構造化ログの重要性 • 今出力されているログが構造化されていないなら Fluentdでパースして構造化する
- 55. 発展： 様々な分析をしてみる • 自分のタイムラインで、直近5分間にツイートした人数 • 方針： • Fluentdで自分のタイムラインを取得してみるには？ • 直近5分でツイートした人数を数えるには？ ヒント：screen_nameのユニークな個数
- 56. ところでリアルタイムって？ • データの発生から、一定時間以内にそれが処理されること • 現実には、様々な「リアルタイム」の敵が…… • データ送る側の処理遅延 • クラウドまで転送するときの遅延（特にモバイル通信） • 分析処理じたいに掛かる時間 • 途中で順番すら入れ替わる
- 57. ところでリアルタイムって？ • 厳密には2つの「時間」を分けて考える必要がある • データの発生時刻（EventTime） • データの処理時刻（ProcessingTime） • 「リアルタイム」≒「何かをあきらめること」 • 要件(仮)：データの分析結果は5分以内に欲しい！ • 実装方針：5分以上遅れたデータは無視せざるを得ない • 3つのトレードオフ • 完全性、低遅延、低コスト
- 58. ラムダアーキテクチャ • データの分析を2種類に分ける • ざっくり今を知るためのリアルタイム分析 • 最終的に正確な結果を知るためのバッチ分析 例：リアルタイムで売上傾向も 知りたいが、最終的な集計数字 がズレるのもまずい
- 59. ラムダアーキテクチャ • データの分析を2種類に分ける • ざっくり今を知るためのリアルタイム分析 • 最終的に正確な結果を知るためのバッチ分析 λ入力 リアルタイム分析 バッチ分析 ※トレードオフの説明のため、 ものすごく簡略に雑にまとめています。
- 60. 高度なリアルタイム分析 • 今回のBigQuery集計 • リアルタイムでデータを集計できる、にすぎない • より高度なリアルタイム分析 • 入ってきたデータを逐次処理して積み重ねる • 機械学習なども交えたデータ処理の積み重ね ⇒ 「ストリーム処理」という技術領域
- 61. 様々なデータ分析の枠組み • クラウド • 今日使ったBigQuery（Google） • ストリーム処理のサービスも増えてきている • Google Cloud Dataflow、 AWS Kinesis Stream Analytics、Azure Stream Analytics • ミドルウェア • Apache Spark（Spark Streaming)などなど
- 62. まとめ • クラウドを利用したリアルタイムデータ分析 • サーバを使ったFluentdによるデータ収集、蓄積 • BigQueryによる様々な分析 • Redashによる可視化 • より高度な「ストリーム処理」 • 自分で手を動かしてみよう！
- 63. 最後に • 特にこの10年のインフラ業界は動きが早いです • クラウドが登場して（まだ）12年間 • 前提が変わり、ベストプラクティスが入れ替わる • 個人的には、 ・この10年で物理サーバからクラウド上の仮想サーバに ・今後10年でサーバという枠組みから解放 と予想しています • ツールレベルの盛衰は、一々取り上げるのも切りが無い • 動きが早い＝面白い！ 63
- 64. 最後に • すぐに手を動かそう！ • 無料クーポン、無料枠を活用しよう（学生はより有利！） • 大きな機能もちょっとだけなら安くお試しできる！ • とにかくネタと機会を作って情報を発信しよう！ • 情報は活動する人の近くに集まる • ブログ等での情報発信 • 勉強会等での発表 • 同人誌等の制作、頒布 64