Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4

6.963 Aufrufe

Veröffentlicht am

IoT と時系列データと Elasticsearch
Data Pipeline Casual Talk Vol.4

株式会社ソラコム
ソリューションアーキテクト
今井 雄太

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

IoT と時系列データと Elasticsearch | Data Pipeline Casual Talk Vol.4

  1. 1. IoTと時系列データとElasticsearch at Data Pipeline Casual Talk Vol.4 Yuta Imai Solutions Architect, SORACOM, INC.
  2. 2. Who am I 今井 雄太 経歴: • Sierで7年くらい • SNSの会社でアドサーバーとレポートシステムの開発 2.5年 • クラウドベンダでソリューションアーキテクト 3.5年 • Hadoopベンダでセールスエンジニア 1年 • ソラコムでソリューションアーキテクト 3年
  3. 3. IoT?
  4. 4. お客様事例: 西鉄グループ様 乗車当日の時刻表と現時 刻の時間帯を大文字で画 面に掲載。多言語対応で、 運行状況や緊急時のお知 らせ等も一斉配信 スマートバス停実証実 験、リアルタイム情報 提供 協力パートナー:安川情報システム株式会社 お客様事例: 西鉄グループ様 Ⓒ2014 ZENRIN CO.LTD.(Z14KF No.213)
  5. 5. お客様事例: ダイドードリンコ様 • 数万台以上の回線管理 • SORACOM Funnelを活用 し安全かつ容易にデータを 送信 毎日、明日が楽しみにな る。未来型自販機!
  6. 6. お客様事例: 大阪ガス様 ガス•電気メーターに外部 デバイスを取付、10分毎 にSORACOMでデータ送 信、お客さまに使いすぎ 等を通知 ガス•電気の見える化 簡易データ計測サービス 「ekul(イークル)」 協力パートナー:株式会社オージス総研
  7. 7. IoTの技術面での難しさ
  8. 8. インターネット クラウドモノ IoTは、テクノロジーの総合格闘技 センサー ゲート ウェイ デバイス 通信 データ 収集 可視化 デバイス 管理 省 電力化 セキュ リティ クラウド 連携 遠隔 管理
  9. 9. IoTでも変わらないもの
  10. 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. 11. ソラコムが解決すること
  12. 12. 接続方法 インターネットモノ ・有線LAN 場所の制約 ・無線LAN 事前設定が難あり ・3G/LTEの通信は便利 人向けプランのみ 初期費用、通信費高い 長期固定契約
  13. 13. 2015年9月30日発表 1日10円〜、モノ向けデータ通信サービス SORACOM Air
  14. 14. SORACOM Air - モバイル通信サービス •だれでも •一枚から •使った分だけ
  15. 15. SORACOMの仕組み モノ 暗号化された 携帯無線 世界中の 携帯基地局 データセンター AWS、Azure インターネット 閉じた ネットワーク SORACOM
  16. 16. SORACOMの特徴
  17. 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
  18. 18. SORACOM Beam モノ SORACOM SORACOM Beam IMSI Signature HTTP TCP UDP MQTT HTTPS MQTTS TCPS クラウド 回線情報でリクエストを認証する セキュアなリバースプロキシ beam.soracom.io
  19. 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 認証したリクエストを 各種クラウドサービスへ直接送信
  20. 20. SORACOM Funk FaaSをあたかもデバイスの ファームウェアのように利用可能
  21. 21. SORACOM Lagoon モノ SORACOM HTTP TCP UDP ストレージ SORACOM内部で 可視化まで実施することも可能
  22. 22. SORACOMはIoTアプリケーションのデバイス- >クラウドのいろいろな仕事をオフロードし ます!
  23. 23. じゃあ、IoTのクラウド側のワークロードは? • どんなユースケースにおいても、デバイスや環境の情報などのメトリ クスやイベントを収集、時間ベースのアグリゲーションをするという使 い方はとてもCommon。 • 時系列DB(ログDBとも言える)のようなものが欲しくなるが、選択肢が 多くて迷う。 クラウド このパートはSORACOMにオフロード! ここはどうすれ ば?
  24. 24. 時系列DBの選択肢(の一部)
  25. 25. ひとつの選択として: Elasticsearch ソラコムのお客様はITの専門家でないひとたちも多いので、情報の得やすさ や使い勝手、運用の容易さがあるとよい。 • 時間ベースのAggregation(ゼロフィル含め)が簡単にできる • 情報が得やすく、KibanaがあるのでGetting startedしやすい • GCPやAWS上で利用可能なマネージドサービスがある • とりあえずデータを投げ込めばなんとかしてくれる(少なくとも最初は) • スケーラビリティがビルトインなので成長に対する安心感
  26. 26. ひとつの選択として: Elasticsearch という背景から、Elasticsearchをおすすめする ケースが多いのです。 おすすめする側の立場として、改めて Elasticsearchの中身をおさらいしておこう、という のが今日の主題で、ここからの話です。
  27. 27. 一般的な時系列DBのウリ • Writeヘビーなワークロードに強い • イベントやログの書き込みに対する高いスループットや信頼性 • LSMツリーベースのデータ構造 • データの圧縮率が非常に高い • カラムナーストレージによる高圧縮率の実現 このあたり、Elasticsearchではどうなっているので しょうか
  28. 28. Elasticsearch Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index
  29. 29. 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。(用語が混乱しがちw)
  30. 30. Elasticsearch – Lucene Index Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index まずはこの中身を覗いてみましょう
  31. 31. Elasticsearch – Lucene Index Shard (Lucene Index) Lucene IndexはSegmentと呼ばれるファイルの集合。 Segment Segment Segment Inverted Index Inverted Index Inverted Index
  32. 32. Lucene Index - Write Shard (Lucene Index) SegmentはImmutable。書き込み(addDocument)はインメモリバッファで受 け取る。 Segment Segment Segment Inverted Index Inverted Index Inverted Index In-memory buffer write 更に、データロストを防ぐために Translogというファイルにも同様 の情報が追記される。
  33. 33. 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
  34. 34. Lucene Index - Search Shard (Lucene Index) Lucene Indexに対するSearchはすべてのSegmentに対してScanが実施さ れ、マージされた結果が返る。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index IndexSearcher
  35. 35. Lucene Index - Search Shard (Lucene Index) SegmentはImmutableなのでFile System Cacheをうまく活用しやすいように なっている。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index IndexSearcher
  36. 36. Lucene Index - Delete Shard (Lucene Index) DeleteはレコードにDeleteフラグを立てるだけ。Search時にフィルタされる。 なのでSearchのコストが高くなる。 Segment Segment Segment Inverted Index Inverted Index Inverted Index Segment Inverted Index Deleted : true
  37. 37. 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
  38. 38. 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
  39. 39. Lucene Index – Compaction/Rollup Shard (Lucene Index) 古いSegmentになるほどCompaction対象になる頻度も減り、キャッシュを 活かして高速な検索が可能になる。(LSMっぽい) Segment Segment Segment Segment Segment NewOld In-memory buffer Write
  40. 40. Elasticsearch – Lucene Index Shard0 Primary Shard0 Replica Shard0 Replica Shard1 Replica Shard1 Replica Shard1 Primary Node 0 Node 1 Node 2 Index Lucene Index
  41. 41. 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)
  42. 42. Elasticsearch – Write Path • shardIdはhash関数を使ってDocumentのField情報(_id?)をもとに決定 される。 • つまり、例えば特定のFieldをキーにして時系列にソートされた Document群がひとつのShardに格納されるわけではない。
  43. 43. 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を利 用することができる。
  44. 44. Elasticsearch – Search Path • 前述のように、ほしいDocument群はすべてのShardに等しく存在する 可能性をもっている。 • よって、SearchはすべてのShardをScanし、それらのレスポンスが マージされたものが最終的な結果となる。 • つまり、Fieldの内容によってデータが偏ったりはしない(はず)で、 Shardの数を増やすことによるリニアなスケールが期待できる。 • さらに、Readヘビーなワークロードの場合、それらを処理するために Replicaを増やすという戦略も取れる。
  45. 45. 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
  46. 46. 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 …
  47. 47. Elasticsearch – Doc Values • 「Indexを(例えば)日毎に分ける」「Shardあたりの受け持ちデータ量/クエリ量を 適切に」という2点を守っていればOKそうに思えてきましたよね。 • 内部的な話としてはLucene Indexは更に内部的にはImmutableなSegmentという ものを追記していくことでDenseなWriteオペレーションを効率的にさばけるように していることも分かってきました。 圧縮率とかカラムナーストレージの話は?
  48. 48. こういうクエリをなげると・・・ Elasticsearch – Doc Values
  49. 49. Elasticsearch – Doc Values こんなクエリがLuceneに対して発行されます
  50. 50. 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はカラムナーストレージなので圧縮率も高い。(圧縮方式は)
  51. 51. Elasticsearch – Doc Values • Doc Valuesはカラムナーストレージなので圧縮率も高い。もちろん型もある。(圧 縮方式まではしらべきれていない) • Doc ValuesはSegmentの作成時に一緒に作成されるので、カラムナーストレージ の連続的書き込みの相性の悪さをうまく解決してくれている。 • いいですね! • 一方、ドキュメントをいろいろあたって見る限り、SegmentごとにBoundary(例えば、 当該Segmentが担当するFieldのValueの最小値、最大値)や、Bloom Filterを持っ ているわけではなさそう。(おそらく)
  52. 52. Elasticsearch – Conclusion • 「Indexを(例えば)日毎に分ける」「Shardあたりの受け持ち データ量/クエリ量を適切に」という2点を守っていれば、時系 列DBっぽいユースケースにはしっかりおすすめできる。 • という感じに・・・結果として広く世に伝わっているプラクティ スをなぞる形にはなりましたが、「あ、これでよかったんや」 的にわりと安心できましたよね?(にっこり)
  53. 53. Executive conclusion • SORACOMは通信を中心に、様々なヘビーリフティングを肩 代わりします! • デバイスも最近はいろんなボードやゲートウェイが簡単に手 に入るようになってきています! • もちろん、クラウドもどんどん便利になってきていますよね。 • IoTも価値のあるところ「だけ」に集中できる世の中になって きています。 • IoTアプリケーションを作る際にはSORACOMを使ってぜひ楽 をしてください!
  54. 54. You create, we connect.

×