IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4
•
11 recomendaciones•10,677 vistas
IoT と時系列データと Elasticsearch Data Pipeline Casual Talk Vol.4 株式会社ソラコム ソリューションアーキテクト 今井 雄太
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4
Similar a IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4 (20)
Más de SORACOM,INC
Más de SORACOM,INC (20)
Último
Último (11)
IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4
- 1. IoTと時系列データとElasticsearch at Data Pipeline Casual Talk Vol.4 Yuta Imai Solutions Architect, SORACOM, INC.
- 2. Who am I 今井 雄太 経歴: • Sierで7年くらい • SNSの会社でアドサーバーとレポートシステムの開発 2.5年 • クラウドベンダでソリューションアーキテクト 3.5年 • Hadoopベンダでセールスエンジニア 1年 • ソラコムでソリューションアーキテクト 3年
- 3. IoT?
- 4. お客様事例: 西鉄グループ様 乗車当日の時刻表と現時 刻の時間帯を大文字で画 面に掲載。多言語対応で、 運行状況や緊急時のお知 らせ等も一斉配信 スマートバス停実証実 験、リアルタイム情報 提供 協力パートナー：安川情報システム株式会社 お客様事例: 西鉄グループ様 Ⓒ2014 ZENRIN CO.LTD.(Z14KF No.213)
- 5. お客様事例: ダイドードリンコ様 • 数万台以上の回線管理 • SORACOM Funnelを活用 し安全かつ容易にデータを 送信 毎日、明日が楽しみにな る。未来型自販機！
- 7. IoTの技術面での難しさ
- 8. インターネット クラウドモノ IoTは、テクノロジーの総合格闘技 センサー ゲート ウェイ デバイス 通信 データ 収集 可視化 デバイス 管理 省 電力化 セキュ リティ クラウド 連携 遠隔 管理
- 9. IoTでも変わらないもの
- 10. クラウド側の処理は変わらない モノ Funnel Beam Stream Batch Amazon Athena Amazon S3 AWS Lambda Amazon Redshift BigQuery Feedback model Pipeline Processing Time series DB Machine Learning Ad-hoc queries Metrics Feedback Event リアルタイムな イベント検出 ダッシュボード BI 機械学習 データレイク Feedback rule デバイス側での イベント検出 Google Cloud Storage
- 11. ソラコムが解決すること
- 14. SORACOM Air - モバイル通信サービス •だれでも •一枚から •使った分だけ
- 16. SORACOMの特徴
- 17. エッジプロセッシング SORACOM Mosaic IoTテクノロジー民主化のためのプラットフォーム SORACOMGlobalPlatform ライブラリ & SDKs CLI(Go), Ruby, Swift Web インターフェース User Console データ転送支援 SORACOM Beam クラウドアダプタ SORACOM Funnel データ収集・蓄積 SORACOM Harvest Data / Files プライベート接続 SORACOM Canal IoT向けデータ通信 SORACOM Air for Cellular (2G, 3G, LTE) / LPWA (LoRaWAN, Sigfox, , LTE-M) / アップロード専用SIM 専用線接続 SORACOM Direct 仮想専用線 SORACOM Door API Web API Sandbox コネクティビティ ネットワーク インタフェース SIM認証・証明 SORACOM Endorse デバイス管理 SORACOM Inventory 透過型トラフィック処理 SORACOM Junction ダッシュボード作成/共有 SORACOM Lagoon セキュアプロビジョニング SORACOM Krypton アクセス権限管理 SORACOM Access Management アプリケーション デバイスLAN SORACOM Gate 開発者サポート Developer Support USB ドングル / セルラーモジュール / マイコンモジュール / ボタン / カメラデバイス クラウドファンクション SORACOM Funk オンデマンドリモートアクセス SORACOM Napter
- 19. SORACOM Funnel モノ SORACOM Amazon Kinesis Data Firehose Microsoft Azure EventHubs AWS IoT Core Amazon Kinesis Data Streams Google Cloud Pub/Sub Amazon Kinesis Video Streams SORACOM Funnel Credential HTTP TCP UDP HTTPS等funnel.soracom.io 認証したリクエストを 各種クラウドサービスへ直接送信
- 25. 時系列DBの選択肢（の一部）
- 26. ひとつの選択として: Elasticsearch ソラコムのお客様はITの専門家でないひとたちも多いので、情報の得やすさ や使い勝手、運用の容易さがあるとよい。 • 時間ベースのAggregation（ゼロフィル含め）が簡単にできる • 情報が得やすく、KibanaがあるのでGetting startedしやすい • GCPやAWS上で利用可能なマネージドサービスがある • とりあえずデータを投げ込めばなんとかしてくれる（少なくとも最初は） • スケーラビリティがビルトインなので成長に対する安心感
- 28. 一般的な時系列DBのウリ • Writeヘビーなワークロードに強い • イベントやログの書き込みに対する高いスループットや信頼性 • LSMツリーベースのデータ構造 • データの圧縮率が非常に高い • カラムナーストレージによる高圧縮率の実現 このあたり、Elasticsearchではどうなっているので しょうか
- 29. Elasticsearch Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index
- 30. Elasticsearch - Shard Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Lucene Index Shard単体はそれぞれがLuceneのIndex。（用語が混乱しがちｗ)
- 31. Elasticsearch – Lucene Index Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index まずはこの中身を覗いてみましょう
- 32. Elasticsearch – Lucene Index Shard (Lucene Index) Lucene IndexはSegmentと呼ばれるファイルの集合。 Segment Segment Segment Inverted Index Inverted Index Inverted Index
- 33. Lucene Index - Write Shard (Lucene Index) SegmentはImmutable。書き込み(addDocument)はインメモリバッファで受 け取る。 Segment Segment Segment Inverted Index Inverted Index Inverted Index In-memory buffer write 更に、データロストを防ぐために Translogというファイルにも同様 の情報が追記される。
- 34. Lucene Index - Write Shard (Lucene Index) バッファは定期的に(デフォルトでは1秒おき)に新しいSegmentとしてFlush され、初めてSearchableになる。 Segment Segment Segment Inverted Index Inverted Index Inverted Index In-memory buffer Segment Inverted Index flush
- 35. Lucene Index - Search Shard (Lucene Index) Lucene Indexに対するSearchはすべてのSegmentに対してScanが実施さ れ、マージされた結果が返る。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index IndexSearcher
- 36. Lucene Index - Search Shard (Lucene Index) SegmentはImmutableなのでFile System Cacheをうまく活用しやすいように なっている。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index IndexSearcher
- 37. Lucene Index - Delete Shard (Lucene Index) DeleteはレコードにDeleteフラグを立てるだけ。Search時にフィルタされる。 なのでSearchのコストが高くなる。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index Deleted : true
- 38. Lucene Index - Update Shard (Lucene Index) UpdateはWriteとDeleteのあわせ技。さらにコストが高い。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index Deleted : true In-memory buffer addDocument
- 39. Lucene Index – Compaction/Rollup Shard (Lucene Index) 古いSegmentはより大きなSegmentとしてMergeされていく。この際に Deletedなレコードはパージされる。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index Deleted Segment Inverted Index Merge sort
- 40. Lucene Index – Compaction/Rollup Shard (Lucene Index) 古いSegmentになるほどCompaction対象になる頻度も減り、キャッシュを 活かして高速な検索が可能になる。(LSMっぽい) Segment Segment Segment Segment Segment NewOld In-memory buffer Write
- 41. Elasticsearch – Lucene Index Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Lucene Index
- 42. Elasticsearch – Write Path Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Client index request Routing クラスタ内のどのNodeでもリク エストは受付可。Coordinatorとし て動作して、shardIdを決定してそ のShardのPrimary Nodeへルー ティングする。 Decide routing 出典: Elasticsearch: The Definitive Guide: A Distributed Real-Time Search and Analytics Engine (English Edition)
- 43. Elasticsearch – Write Path • shardIdはhash関数を使ってDocumentのField情報(_id?)をもとに決定 される。 • つまり、例えば特定のFieldをキーにして時系列にソートされた Document群がひとつのShardに格納されるわけではない。
- 44. Elasticsearch – Search Path Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Client search request searchはすべてのShardに対してリ クエストを転送し、結果をマージ する。 参照系のOperationはReplicaを利 用することができる。
- 45. Elasticsearch – Search Path • 前述のように、ほしいDocument群はすべてのShardに等しく存在する 可能性をもっている。 • よって、SearchはすべてのShardをScanし、それらのレスポンスが マージされたものが最終的な結果となる。 • つまり、Fieldの内容によってデータが偏ったりはしない（はず）で、 Shardの数を増やすことによるリニアなスケールが期待できる。 • さらに、Readヘビーなワークロードの場合、それらを処理するために Replicaを増やすという戦略も取れる。
- 46. Elasticsearch – Performance • Write(Index)はShardの偏りが発生しないようになっているので、Shard数を増やすことに よってスケーラビリティを確保しやすくなっている • Read(Search)もすべてのShardをScanする前提になっているので、Shard数を増やすこと で（ShardあたりのDocument量が減ることにより）スケールしやすくなっている。 • ただし、Shard内のSegment群がファイルキャッシュに載る限りにおいて。 • また、精度の観点からはShardは1つで済むならそちらのほうがいいという話がある。 もちろん、リソース利用の観点からのShardが少ないほうがいい。 • https://www.youtube.com/watch?v=PpX7J-G2PEo&t=2110
- 47. Elasticsearch – Performance • Segmentがファイルキャッシュに乗らなくなるとパフォーマンスに問題が発生する ため、ElasticsearchのIndexは、例えば日毎に分ける。それによってひとつの Indexあたりのデータ量に制約をかけるとともに予測が容易になる。 • つまりこれってPartitioning • 古いDocumentをパージするにも、DeleteではなくてIndexごと削除していくことで 低コストなオペレーションができる。 log- 2019090 1 log- 2910909 02 Elasticsearch indices log- 2019090 3 log- 2910909 04 log- 2019090 5 log- 2910909 06 log- 2019090 7 …
- 48. Elasticsearch – Doc Values • 「Indexを（例えば）日毎に分ける」「Shardあたりの受け持ちデータ量/クエリ量を 適切に」という2点を守っていればOKそうに思えてきましたよね。 • 内部的な話としてはLucene Indexは更に内部的にはImmutableなSegmentという ものを追記していくことでDenseなWriteオペレーションを効率的にさばけるように していることも分かってきました。 圧縮率とかカラムナーストレージの話は？
- 49. こういうクエリをなげると・・・ Elasticsearch – Doc Values
- 50. Elasticsearch – Doc Values こんなクエリがLuceneに対して発行されます
- 51. Elasticsearch – Doc Values • Doc Valuesとは、Field(RDB的に言えばカラム)ごとに作成される、「ValueでSortさ れたSecondary Index的なカラムナーストレージ」のこと。Inverted Indexと同様に Segmentごとに作成される。 • Inverted Indexは全文検索を高速に解決するためには有効だが、例えば「date: 20190930」みたいなValueで検索することには最適ではない。また、ValueでSort されていない。（TermでSortされている） • 今回のテーマで扱っているようなクエリ(SortやAggregation)はほぼこちらのDoc Valuesをつかって実現されている。（はず） • Doc Valuesはカラムナーストレージなので圧縮率も高い。（圧縮方式は）
- 52. Elasticsearch – Doc Values • Doc Valuesはカラムナーストレージなので圧縮率も高い。もちろん型もある。（圧 縮方式まではしらべきれていない） • Doc ValuesはSegmentの作成時に一緒に作成されるので、カラムナーストレージ の連続的書き込みの相性の悪さをうまく解決してくれている。 • いいですね！ • 一方、ドキュメントをいろいろあたって見る限り、SegmentごとにBoundary(例えば、 当該Segmentが担当するFieldのValueの最小値、最大値)や、Bloom Filterを持っ ているわけではなさそう。（おそらく）
- 53. Elasticsearch – Conclusion • 「Indexを（例えば）日毎に分ける」「Shardあたりの受け持ち データ量/クエリ量を適切に」という2点を守っていれば、時系 列DBっぽいユースケースにはしっかりおすすめできる。 • という感じに・・・結果として広く世に伝わっているプラクティ スをなぞる形にはなりましたが、「あ、これでよかったんや」 的にわりと安心できましたよね？(にっこり）
- 54. Executive conclusion • SORACOMは通信を中心に、様々なヘビーリフティングを肩 代わりします！ • デバイスも最近はいろんなボードやゲートウェイが簡単に手 に入るようになってきています！ • もちろん、クラウドもどんどん便利になってきていますよね。 • IoTも価値のあるところ「だけ」に集中できる世の中になって きています。 • IoTアプリケーションを作る際にはSORACOMを使ってぜひ楽 をしてください！
- 55. You create, we connect.