第一回IoT関連技術勉強会 分散処理編 田実 誠
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
第一回IoT関連技術勉強会分散処理編
田実 誠
• IoTの話の前提となる知識• ビッグデータ• スケールアップとスケールアウト• 並行配置／分散処理
• Hadoop／Hive／Pig• TreasureData• RedShift, BigQuery, EMR• まとめ
アジェンダ
IoT…の前にビッグデータの話昔はデータが少なかったので、普通のRDB（Oracle, MySQL, Postgres, SQL Server…）で問題なかった
Webが広く受け入れられ、データ量が増えた
データ量（特にログ）が億とか兆レベルになって、RDBでは扱いづらいレベルになった。集計クエリを発行すると返ってこない。
スケールアップには限界がある。コストもかかりがち。さらに、データが将来どれくらい増えるかわからない。だから、限界が無いスケールアウトをしたい。とはいえ、 RDBだけの仕組みで分散処理の仕組みを作るのは難しい。
スケールアウトできる分散処理基盤Hadoop(Map/Reduce), TreasureData, Redshift, BigQuery
スケールアップとスケールアウトスケールアップ• 処理能力を上げるために、サーバ１台１台のスペック（CPU/RAM/ディスクIO）を上げる• スペックの上限がある• コストも高くなりがち• 管理対象が少ないので、管理コストが低い
スケールアウト（→バッチの分散処理に利用される）• 処理能力を上げるために、サーバ自体を増やす• スペックの上限が無い• スケールアップよりは安くなることが多い• 管理対象のサーバが増えるため、管理コストが高い（死活監視、メンテナンス、セキュリティ）• ロードバランサやマスターサーバが必要になり難度が高い（とはいえサービスの提供により簡単になってきて
いる）• 副産物として可用性も上げれる
可用性を上げれるという利点もあるので、スケールアウトの方針がとられることが多い
分散処理…の前にプロジェクトの話？
お客さん
PM／開発・要件定義・設計・開発・テスト
小型／保守案件パターン
お客さん
PM・要件定義・基本設計・テスト
中規模案件パターン＞役割分担
開発者・詳細設計・開発・単体テスト
お客さん
PM・要件定義・管理業務
大規模案件パターン＞役割分担、増員
開発者／テスター・詳細設計・開発・単体テスト
Webサーバのスケールアウトの話Webサーバのスケールアウトも基本原理は全く同じ
ユーザ（ブラウザ）
Web／DBサーバ
小規模Webアプリ
ユーザ（ブラウザ）
Webサーバ
中規模Webアプリ＞機能分割
DBサーバ
ユーザ（ブラウザ）
プロキシ・F/W(WAF)・ロードバランサ
大規模Webアプリ＞機能分割＋並行配置
Webサーバ
RDBのスケールアウトの話そもそもRDBの仕組みでスケールアウトができないのか
レプリケーション（別のサーバにコピー）、水平分割（シャーディング）、垂直分割等で可能。レプリケーション以外はDBの設計の難度が高い。レプリケーションでスケールアウトできるのは検索（READ）のみ。※ここらへんの問題を解決したのがNoSQL（ただし、万能ではない）
Webサーバ
DB（マスター）
DB（スレーブ）
作成、更新、削除 同期処理
検索
ちなみに…疎結合（役割分割）にするとスケールアウトできる、という利点があります。逆に、スケールアウトするためには疎結合にする必要があります。
最近はマイクロサービスアーキテクチャ、という言葉が流行っていますがこれはサーバの役割を必要最小限にすることでスケーラビリティ、メンテナンサビリティの高いアーキテクチャにする目的があります。（UNIX哲学的な）
HerokuのDynoに関してもアプリケーションサーバという役割に分割しているからこそスケールアウトを容易に実現できています（DB、ストレージは他のアドオンが役割を担う）
アクセス数、処理数が多いシステムはスケールアウトするために、たくさんの機能分割をしているのでノードが多く、複雑になります。
逆に、アクセス数、処理数が将来的にも少ないシステムは無理に役割分担をする必要は無いと思います。
適材適所という感じ。
・分散処理フレームワーク（バッチ処理）
Hadoop
バッチ処理サーバ
DBサーバ
マスターサーバ・タスク振り分け
ノードサーバ・タスク処理・データ保持
簡単なバッチ処理 大量データのバッチ処理
• データをHDFSという仮想ファイルシステムに格納→各ノード（処理サーバ）自体にデータを格納。同じデータを３つコピーする。
• Hadoopが起動すると、Map（非構造データをKey/Valueに変換する処理）とReduce（Mapで処理されたデータを集計する）処理が行われる→Javaで書いたり、それ以外の言語で書いたり(Hadoop Streaming)
• どんな非構造データでも分析することが可能
Hadoop
192.168.33.1 - -[28/May/2016:08:20:07 +0000] "GET / HTTP/1.1" 200 444 1.0269192.168.33.1 - -[28/May/2016:08:20:29 +0000] "GET /login HTTP/1.1" 200 1262 0.0353192.168.33.1 - -[28/May/2016:08:20:29 +0000] "GET /css/signing.css HTTP/1.1" 200 736 0.0041
/login<tab>10/signup<tab>20
/login<tab>25/signup<tab>25
/login<tab>15/signup<tab>5
Map
Reduce
Hadoop - HDFS
発注画面の仕様書を持つAさん
見積画面の仕様書を持つBさん
Aさん、Bさんどちらかが風邪を引くと終わる
発注画面と見積画面の仕様書を持つAさん
発注画面と見積画面の仕様書を持つBさん
両方、風邪を引いても大丈夫
同じデータを３つコピーする？→一部のノードに障害が発生しても問題なく動作する
• 対象のデータは処理ノード自身に持たせる（ネットワークレイテンシと輻輳対策）• 各ノードにデータを持たせることで、ディスクI/Oのスループットを向上させる
Hadoop - HDFS
仕様書を持っていない開発者
全仕様書を持っている非開発者
データのやりとりが発生する
発注画面と見積画面の仕様書を持つAさん
発注画面と見積画面の仕様書を持つBさん
データのやりとりが発生しない※かといって全仕様書を持たせることはできないので処理する最低限の仕様書だけ持たせる
Hadoopの概念図
出典: http://www.glennklockwood.com/data-intensive/hadoop/overview.html#3-2-map-reduce-jobs
Hive
RDBMSのSQLでMap/Reduceを書けるソフトウェア→わざわざMap/Reduceを書く必要がなく、SQLの知識が活かせて手軽→要件の大半は集計系のSQLで記述できるため便利※レコメンデーション、機械学習系の難しい処理はSQLでは記述できないのでHiveを利用せず、Map/Reduceを使うことが多い…と思う
Pig
Map/Reduceのラッパー。Map/Reduceを簡単に記述できる言語
• 大量のデータを集計、抽出、分析できる分散処理SaaS→Hadoop As A Serviceと言いたいところだが色々と構造が異なる※一から分散処理基盤を構築するのは難しいしコストも高いので手軽で便利
• 内部はHadoop/Hive（一部独自の実装を載せている）
• スキーマフリーだけど高速な処理→MessagePack(バイナリ版JSON)+カラム指向DB
• 集計処理はHive/Pig/Prestoで記述可能
• スケジュール実行＋実行結果の外部出力→GUIによる設定で自由に変更可能
TreasureData
• DBのボトルネックはディスクI/Oなので、読み込むデータが少なければ少ないほど良い
• 行ではなく、カラムごとにデータをまとめて持たせる→取得するときは利用するカラムだけ取得すれば良いので効率的、ディスクシークも少ない
• 各カラムのデータは圧縮されていてディスクI/Oが少ない→カラムは同一データ型なので圧縮効率が良い
• ただし、カラムが作成される度に展開／圧縮をする必要が有るため、データ作成処理は苦手
カラム指向DB？
RDB vs 分散処理RDBMS 分散処理(Hadoop)
目的 トランザクション処理小さいデータを読み書き
集計処理
データ量 テラバイト~億レコード
ペタバイト~兆レコード
レスポンス 早い 遅い（データ量が多くなると相対値としては早くなる）
拡張方法 スケールアップがメイン※スケールアウトの構成も取れるがやや複雑
スケールアウト
業務系システム： RDB分析システム： RDB/分散処理基盤
どう使うか？→DB作ってデータ入れてクエリ（Hive/Pig/Presto）発行するだけ！→データの入れ方は色々ある（fluentd/embulk/API直叩き）
TreasureData
DEMO
• TreasureDataと同じ用途で利用されるが、こちらはRDB色が強い。• PostgreSQLなので、ODBC/JDBCで接続可能• RDB色が強いと言ってもIndexは無い• スキーマフリーではなく、テーブルを作成• 内部的な構造がTreasureDataやHadoopとは異なる• 適切にチューニングされていればHadoop/Hiveよりは検索速度は早い
→データ入れてクエリ発行するだけ。
Amazon RedShift
• Hadoop As A Service• Hadoopのインストール（マスターノード、スレーブノード、クラスタ関連）が
不要なので、手軽にMap/Reduceできる• Amazonなので従量課金• Amazonなので自由にスケール可能
Elastic Map Reduce (EMR)
BigQuery (Google)
• 同じような用途。スキーマフリー。カラム指向DB。RDBではない。なんとなく安い印象
• データやリクエストの増加によりスケールアウト（分散処理）する構成が多くなった
• ビッグデータの分析はスケールアウトする分散処理基盤を使う必要がある
• TreasureDataはHadoop/Hive/Prestoをサービス化したもの（内部構造や考え方は一部異なる）
• 類似の分析処理基盤としてRedShift、BigQuery等がある
• 用途によってRDBと分散処理基盤（とNoSQL）を使い分ける必要がある
まとめ
Related Documents
