FaaSで小さくはじめるIoTリアルタイムデータ処理 #serverlesstokyo
•
1 j'aime•17,320 vues
2020-02-27 Serverless Meetup Tokyo #16 https://serverless.connpass.com/event/165352/ #serverlesstokyo FaaSで小さくはじめるIoTリアルタイムデータ処理
Recommandé
Recommandé
Contenu connexe
Plus de Masahiro NAKAYAMA
Plus de Masahiro NAKAYAMA (20)
FaaSで小さくはじめるIoTリアルタイムデータ処理 #serverlesstokyo
- 2. 仲山 昌宏 / @nekoruri • サーバーレス極振り屋さん • 株式会社WHERE （2016-） • SecHack365 トレーナー （2017-） • セキュリティ・キャンプ 全国大会 講師 （2015-） • 技術系同人誌サークル 「めもおきば」「ssmjp同人部」 • #ssmjp / #qpstudy /#serverlesstokyo • Microsoft MVP (Azure) • Minecrafter (筋肉整地担当) 2
- 7. IoTのデータ処理 即時性が必要なもの • ひと・ものがどこにいる？ • いまいる場所を知りたい • 場所に紐付けた危険判断 （危険エリアへの滞在など） • 故障の検知 • 現場にいる人への指示 • 動いているデバイスの制御 正確性や大量のデータが必要なもの • 稼働データ • 生産管理や課金請求 • 故障予測 • MLに突っ込む大量の生データ
- 8. IoTのデータ処理 即時性が必要なもの • ひと・ものがどこにいる？ • いまいる場所を知りたい • 場所に紐付けた危険判断 （危険エリアへの滞在など） • 故障の検知 • 現場にいる人への指示 • 動いているデバイスの制御 正確性や大量のデータが必要なもの • 稼働データ • 生産管理や課金請求 • 故障予測 • MLに突っ込む大量の生データ
- 9. リアルタイムデータ処理 • DBでがんばる • とにかく生データをDBに入れてクエリ等で頑張る • ストリームデータ処理エンジン • Spark Streaming、Apache Flink • Apache Beam (プログラミングモデル) • Google Cloud Dataflow (↑のフルマネージドサービス) • PubSub + FaaS + データストア • Azure: EventHubs + Functions • AWS: Kinesis + Lambda • とにかく手軽かつ軽率安易にはじめられる
- 11. IoTあるあるユースケース • センサーから上がってくる温度データをリアルタイムで見たい • 温度センサーの前処理 • 電圧⇒温度 • 誤差の吸収 • 計測誤差：センサーの配線にノイズが乗って電圧が変動する • 環境誤差：人が通ると温度がふらつく
- 12. IoTあるあるユースケース • 誤差の吸収 • まあやりかたはたくさんあります • 一番手軽なのは移動平均 • 移動平均……？ • 過去N件あるいはM秒以内の値の平均値
- 13. 基本的なアーキテクチャ PubSub • 生データを集める • バッチ用のアーカイブ 保存 • EventHubs(Azure) • Kinesis Data Streaming(AWS) 関数 • 逐次的にデータを分析 • 判断結果に基づいて行 動 • Azure Functions • AWS Lambda データストア • 処理結果を貯める • CosmosDB(Azure) • DynamoDB(AWS)
- 14. Azure: EventHubs + Functions • EventHubsにデータを集める • Azure IoTHubも基本的には一緒 • その話は今回はしません • EventHubsからFunctionsに連携 • Trigger • Output binding
- 15. EventHubs Trigger module.exports = async function (context, eventHubMessages) { eventHubMessages.forEach((message, index) => { context.log(`Processed message ${message}`); }); };
- 16. EventHubs output binding module.exports = async function(context) { const timeStamp = new Date().toISOString(); const message = 'Message created at: ' + timeStamp; const message = []; messages.push("1 " + message); messages.push("2 " + message); return messages; };
- 17. FaaS is STATELESS! • 移動平均は直近の過去のデータが必要 • 戦略1：CosmosDBやRDBに過去のデータを入れる • デバイスごとに、タイムスタンプで履歴を入れていく • パーティションキー：デバイスのID • レンジキー：タイムスタンプ • デバイスを指定して、直近のデータを取得 • 移動平均を取得してDBに戻す • WRITEが高い • CosmosDBもDynamoDBも書き込み課金が比較的高い
- 18. FaaS is STATELESS! • 戦略2：Redisに過去のデータを入れる • 移動平均の直近データ、昔のは要らないのでは？ ⇒ いわゆる「状態」データをメモリキャッシュストアに入れる • 結果データやマスタデータはCosmosDB等できちんと永続化
- 19. Redis • ちょうはやいメモリキャッシュストア • 参考 • redis、それは危険なほどのスピード https://ameblo.jp/principia-ca/entry-11197286812.html • 時系列データベースという概念をクラウドの技で再構築する https://speakerdeck.com/yuukit/the-rebuild-of-time-series- database-on-aws
- 20. Redisのデータ型 • 基本はKVS (Key-Value-Store) • いくつかのデータ型が存在 • 文字列 • リスト • セット（重複しないリスト） • ソート済みリスト • ハッシュ • 今回はハッシュを利用
- 21. データ構造 • Valueに履歴を含むJSONをまとめて突っ込む • Redisから取得 ⇒追加データを使って移動平均を計算 ⇒移動平均の期間外のデータを削除 ⇒新しい履歴データをRedisに更新 { "history": [ { "timestamp": 1582798224, "value": 24, "movavg": 24 }, { "timestamp": 1582798224, "value": 25, "movavg": 24.5}, { "timestamp": 1582798224, "value": 26, "movavg": 25 } ] }
- 22. 気になる性能 • おさらい： 「ちょうはやい」メモリキャッシュストア • ただし：全データがメモリ上に載っかること • メモリにさえ載っていれば、 1コアで秒数万クエリ以上さばける
- 23. 横道：タイムスタンプ • デバイスで計測したときの時刻 • デバイスの時計、信頼できますか？ • NTPへの通信路は安定していますか？ • クラウドに上がってきたときの時刻 • できる限り入口で付ける （SORACOM Funnelだと受信時点で付けてくれる） • PubSubに積まれた時刻は取得可能 • データを処理するときの現在時刻 • クラウド内で「処理」するまでの遅延が入る：数100ミリ秒～数十秒 • 処理が詰まるとPubSubに積まれていく（MAX1～7日）
- 24. 状態を扱うアーキテクチャ PubSub • 生データを集める • バッチ用のアーカイブ 保存 • EventHubs(Azure) • Kinesis Data Streaming(AWS) 関数 • 逐次的にデータを分析 • 判断結果に基づいて行 動 • Azure Functions • AWS Lambda データストア • 処理結果を貯める • CosmosDB(Azure) • DynamoDB(AWS) メモリキャッシュ • 中間データ（状態）を 保持する • Redis (各社にマネージドサー ビスもあり）
- 25. ところでそれもっと楽にできるよね？ • ストリーミング処理エンジンのSQL (Stream Anaytics) • DSL (Spark Streaming on Scala) SELECT AVG(Value) AS AverageValue, DeviceId INTO Output FROM Input GROUP BY DeviceId, TumblingWindow(minute, 5) sc.parallelize(1 to 100, 10) .sliding(3) .map(curSlice => (curSlice.sum / curSlice.size)) .collect()
- 26. ところでそれもっと楽に実装できるよね？ • ストリーミング処理エンジンのSQL (Stream Anaytics) • DSL (Spark Streaming on Scala) SELECT AVG(Value) AS AverageValue, DeviceId INTO Output FROM Input GROUP BY DeviceId, TumblingWindow(minute, 5) sc.parallelize(1 to 100, 10) .sliding(3) .map(curSlice => (curSlice.sum / curSlice.size)) .collect()
- 27. まとめ • PubSubとFaaSで手軽にリアルタイムデータ処理が書ける • 直近の状態データを持ちたくなったら、 Redisなどメモリキャッシュを併用すると吉 • 失いたくないデータはお金を払ってきちんと永続化 • 選択肢はFaaS意外にもあるので常に手札は複数もとう • フルマネージドサービス極振りはいいぞ