Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
【IoT-Tech Meetup #6】サーバーレスで始める IoTデータパイプラインとファンアウトのアーキテクチャー
Search
SORACOM
PRO
October 24, 2023
Technology
0
1.1k
【IoT-Tech Meetup #6】サーバーレスで始める IoTデータパイプラインとファンアウトのアーキテクチャー
2023年10月24日開催『
IoT-Tech Meetup 第6回【IoT × サーバーレス入門】
』で、ソラコム小梁川(koya)が発表した資料です。
SORACOM
PRO
October 24, 2023
Tweet
Share
More Decks by SORACOM
See All by SORACOM
【基調講演】変える、今ここから ― IoTとAIで紡ぐ未来
soracom
PRO
0
320
【基調講演】IoTとAIテクノロジーが織りなす、データ中心の世界へ
soracom
PRO
0
94
SIM? LTE-M? SORACOM?セルラーLPWA通信 まるわかり!
soracom
PRO
3
1.4k
生成 AI で社内ナレッジ共有が変わる!Q&A ボットは質問に答える時間を削減するだけじゃない!
soracom
PRO
1
430
【SORACOM UG 四国】今だからこそ学ぶ!IoTの全体像と最新事例、生成AIの基礎
soracom
PRO
2
1.1k
【SORACOM UG 四国】IoTプラットフォーム「SORACOM」の位置づけと始め方
soracom
PRO
1
800
【SORACOM UG 東海】あらゆるモノがつながる社会へ、IoT と SORACOM
soracom
PRO
1
790
【SORACOM UG 広島】つながる社会へ!IoT プラットフォーム「SORACOM」
soracom
PRO
0
600
【SORACOM UG】SIM Deep Dive セキュアエレメント編
soracom
PRO
0
500
Other Decks in Technology
See All in Technology
Classmethod流のPlatform Engineering / classmethod-platform-engineering-devio2024
tomoki10
0
470
成長期に歩みを止めないための創業期の開発文化形成
mayah
6
420
楽しくGoを学び合う、LayerXの勉強会文化 / LayerX's study culture of having fun and learning Go together
ar_tama
2
350
Git 研修 Basic【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
310
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
280
Git 研修 Advanced【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
200
テスト・設計研修【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
エンジニアの生存戦略 〜クラウド潮流の経験から紐解く技術トレンドのメカニズムと乗りこなし方〜
shimy
9
1.9k
簡単に始めるSnowflakeの機械学習
nayuts
1
190
可視化プラットフォームGrafanaの基本と活用方法の全て
hamadakoji
0
230
データ分析基盤を作ってみよう~設計編~
nrinetcom
PRO
1
110
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
opelab
17
8.1k
Featured
See All Featured
Rebuilding a faster, lazier Slack
samanthasiow
78
8.5k
GraphQLとの向き合い方2022年版
quramy
36
13k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
24
1.8k
Designing on Purpose - Digital PM Summit 2013
jponch
113
6.6k
Art, The Web, and Tiny UX
lynnandtonic
291
20k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
Into the Great Unknown - MozCon
thekraken
20
1.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
149
45k
What's new in Ruby 2.0
geeforr
338
31k
What's in a price? How to price your products and services
michaelherold
239
11k
Designing the Hi-DPI Web
ddemaree
276
34k
We Have a Design System, Now What?
morganepeng
46
7k
Transcript
サーバーレスで始める IoTデータパイプラインと ファンアウトのアーキテクチャー Oct. 24, 2023 IoT-Tech Meetup【IoT × サーバーレス】
株式会社ソラコム ソリューションアーキテクト 小梁川 貴史 #6-2
自己紹介 株式会社ソラコム / ソリューションアーキテクト 小梁川 貴史(こやながわ たかし) 経歴: • SI会社で開発/インフラ設計、構築など幅広く経験
• 電機メーカーで自社サービス、社内共通プラットフォームの開発、運用 • 外資系クラウドのソリューションアーキテクトとして パートナー担当 => IoT スペシャリスト/プロトタイピング
はじめに Severlessという趣旨の回になっておりますが、ここでは広義 にマネージドサービスでサーバを意識しないサービスまでを含 めてお話します。
データパイプライン ソース 受付 処理 収集/蓄積 利用/連携 • IoTにおけるデ バイスやセン サーにあたる
データを生み出 すもの • IoTデータの通 信を受け付けつ 部分と認証や 振り分け • デバイス差分や データフォー マットの version差分な どを吸収し利用 しやすいデータ を作成したり、 データ間にまた がる意味付けを したりする • データの格納、 DBやオブジェ クトストレージ など、アプリ ケーションやシ ステム要件に合 わせた保管 • 可視化(ダッシュ ボード)環境の構 築やWebアプリ ケーション • その他全社データ 統合などのデータ レイク、データ ウェアハウス
データパイプライン 大きな話 • 1つの会社で複数のシステムがあり、全社データベース、データレイ クなどを構築するようなデータパイプライン IoTスコープでの話 • 1つのシステムで複数のデバイスやバージョンのフォーマットを単一 のデータウェアハウスとして構築するようなデータパイプライン 今回の対象
データパイプライン ETL • Extract(抽出) , Transform(変換), Load(書き出し)の頭文字、様々な データソースからデータと取り出し、扱いやすいフォーマットへ変 換するような前処理 データレイク
• 複数(もしくは未確定)用途として、Rawデータのまま保管されて いるようなデータ データウェアハウス • 特定用途へむけた処理済みデータとしてビジネス担当者にとって使 いやすい構造になっているデータ
IoTにおけるプロトコル選択 HTTP • クラウド側からニアリアルタイムで送信したい要件がない。結果整 合でデバイスにコンテキストが通知できれば良いようなユースケー ス。 • HTTPでの定期情報送信のレスポンスに乗せてデバイスへの通知コンテキ ストを返信するようなユースケースでニーズが満たせる MQTT
• クラウドなどからの通知をニアリアルタイムで反映されてほしい データがある。 • MQTTでclientがメッセージ受信用のSubscriberセッションを作成してメッ セージを待ち続ける必要がある
AWS IoT Core を使ったアーキテクチャ例 PoCフェーズ AWS IoT Core Amazon DynamoDB
Amazon OpenSearch Service デバイスの数も少ない、データ変換などの要件もないのでのデータストアと可視化ツールがあ ればよいフェーズ 作り込みや利用サービスも最小限でスタート
AWSを使ったアーキテクチャ例 本番環境 AWS IoT Core Amazon DynamoDB Amazon OpenSearch Service
デバイスの数が増えて、個別/都度の書き込みが非効率になるのストリームデータ処理基盤を追加、 DBに投入する前にデータの構造を変換する必要がでた、、、などをクラウドプラットフォーム側で極力影響 吸収することでデバイス運用を楽にすることができる AWS Lambda Amazon Kinesis Data Firehose Amazon S3 Amazon Kinesis Data Streams
AWSを使ったアーキテクチャ例 本番環境 AWS IoT Core Amazon DynamoDB Amazon OpenSearch Service
デバイスの数が増えて、個別/都度の書き込みが非効率になるのストリームデータ処理基盤を追加、 DBに投入する前にデータの構造を変換する必要がでた、、、などをクラウドプラットフォーム側で極力影響 吸収することでデバイス運用を楽にすることができる AWS Lambda Amazon Kinesis Data Firehose Amazon S3 Amazon Kinesis Data Streams デバイスごとのデータの 差分やフォーマットバー ジョンの差分を吸収する レイヤー 設定変更だけで後段のデ ータ転送先サービスを変 更可能 本構成上インスタンスが 唯一必要なサービス Lambdaの同時起動数な ども加味して マイクロバッチ化
サービスの例 プロトコル/ 認証 業務 ロジック データストア 可視化/分析 Amazon API Gateway
AWS IoT Core Azure Application Gateway Azure IoT Hub API Gateway AWS Lambda Amazon Kinesis AWS IoT Analytics Azure Event Hubs Azure Functions Azure Stream Analytics Cloud Functions Cloud Pub/Sub Cloud Storage BigQuery Firestore Azure Cosmos DB Storage Account Data Lake Storage Gen2 Amazon S3 Amazon DynamoDB Cloud Dataflow
Severless、マネージドサービスのメリット • スケーラビリティの確保 • 使った分(時間や回数)の従量課金 • 非機能要件の大半をクラウドベンダによりかかること が可能 必要なもの、欲しい機能を作れば開始できる!
ファンイン(Fan-in)/ファンアウト(Fan-out) ファンイン • 多数のデバイスからのデータ送信(publisher) から送られてくるデータ が単一のデータ受信者(subscriber)へ送られるようなケース • 先のような多数のデバイスからの単一のデータストアへのデータ収集の ユースケースがファンインにあたります ファンアウト
• 単一のメッセージ配信(publisher)を多数のデバイスが受信者 (subscriber)となるユースケース。 • 例えば、デバイスのアップデート通知など、単一のコンテキストを多数の デバイスに通知するもの
AWS IoT Core MQTT message Broker Chatアプリケーションで考えてみる MQTT message brokerがactiveなセッション(接続済みのsubscriber)を管理、
channel名をtopicで表現することなでそのチャンネルを受信している人へ 単一publish命令をsubscriberへ送信してくれる。 (ただしpub/subのみで実現すると過去ログなどは読めずに接続している感のやり取りのみの表示になります) channel/room1 送信者 受信者
Message BrokerもAWS IoTのごく一部の機能
たとえば同じことをサーバレス構成の WebSocketで実現すると Amazon API Gateway Amazon DynamoDB AWS Lambda AWS
Lambda セッション管理用 接続クライアント を取得してメッセ ージを送る用 セッション管理 = 接続デバイス情 報管理DB connect channel 参加 発言 アクティブな ユーザへPUSH 受信したいチャンネル情報をRESTのパスなどで表現し、 接続情報やchannel情報を管理するDBで管理、メッセージが着信したら そのDBから接続情報を引いて対象のチャンネルに接続しているPUSHする仕組みを 作る必要がある。 送信者 受信者
適材適所 上記例では異なるサービスでファンアウトのアーキテクチャの 例をみていただきましたが、AWS IoTはMQTT通信ということ も含めて大規模通信でスケールし易い、マネージドな領域が多 いことがわかります。 WebSocketでAPI Gatewayをベースに類似のシステムを作成 することができますがその場合には接続情報の管理までユーザ が作る必要があります。
AWSさんの事例を読んで見る 大規模台数のたまごっちへ AWS IoT Jobs で高速かつ高効率にファーム ウェアを配信する方法 https://aws.amazon.com/jp/blogs/news/aws -iot-jobs-for-bandai-tamagotchi/
ファンアウトのまとめ 一斉配信(ファンアウト)の使い所を考えましょう。 AWS IoT Core , Azure IoT Hub などにはDevice
shadow, Device twinなどを使い 1:1 での管理、通知の仕組みなどの検 討をしましょう。 一斉通知は配信側やネットワーク側にも負荷が重く、サーバレ スとはいえアカウントリミットなどにも当たりやすい構成にな るので回避できる、気がつける仕組みも重要です。
•AWS LambdaではRDSを使わない方が良い •RDS Proxyで対応可能に アンチパターンがなくなることもある • Kinesis Data Streamなどを挟む場合はshard数などの兼ね合いで 必要セッション数がもとから小さい場合もあります。
おすすめドキュメント AWS IoT CoreのMQTTトピックの設計 https://d1.awsstatic.com/whitepapers/ja_JP/Designing_MQTT_Topics_for_AWS_IoT_Core.pdf 古いですが、2017年のre:Invent AWS IoTで1つのメッセージを大量デバイスへ配信するためには の解説。 One
message to a Million Things https://www.slideshare.net/AmazonWebServices/iot308one-message-to-a-million-things-done-in-60- seconds-with-aws-iot
IoT の「つなぐ」を簡単に You Create. We Connect.