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.9k
【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
10年の共創が示す、これからの開発者と企業の関係 ~ Crossroad
soracom
PRO
1
150
投資家様向けビジネス概要<2025年8月版>
soracom
PRO
0
290
Business Overview for Investors[August 2025 Edition]
soracom
PRO
0
48
少人数・短期間で実現!“ゼロから作らない” 4つの事例から見る、新時代IoT【SORACOM Discovery 2025】
soracom
PRO
0
300
現場のリアルをカメラで変える!小売・商業施設の「現場改革」最前線【SORACOM Discovery 2025】
soracom
PRO
0
280
【特別講演】公開思考実験!もしも、この世界から「ヒトとモノのつながり」が消えたなら?【SORACOM Discovery 2025】
soracom
PRO
0
160
トヨタのIoT民主化を支援!「D-ROOM」の仕組みと現場浸透のくふう【SORACOM Discovery 2025】
soracom
PRO
0
330
クラウド全盛時代におけるIoTエッジ活用とグローバルサプライチェーン戦略【SORACOM Discovery 2025】
soracom
PRO
0
180
【特別講演】デジタル変革の羅針盤 ~CIO/CDOが描くIoTとAIの未来~【SORACOM Discovery 2025】
soracom
PRO
0
300
Other Decks in Technology
See All in Technology
Access-what? why and how, A11Y for All - Nordic.js 2025
gdomiciano
1
100
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
3
1.7k
GC25 Recap+: Advancing Go Garbage Collection with Green Tea
logica0419
1
360
生成AIを活用したZennの取り組み事例
ryosukeigarashi
0
200
o11yで育てる、強い内製開発組織
_awache
3
110
Windows で省エネ
murachiakira
0
160
ユニットテストに対する考え方の変遷 / Everyone should watch his live coding
mdstoy
0
120
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
290
組織観点からIAM Identity CenterとIAMの設計を考える
nrinetcom
PRO
1
160
非エンジニアのあなたもできる&もうやってる!コンテキストエンジニアリング
findy_eventslides
3
890
DataOpsNight#8_Terragruntを用いたスケーラブルなSnowflakeインフラ管理
roki18d
1
320
Azure SynapseからAzure Databricksへ 移行してわかった新時代のコスト問題!?
databricksjapan
0
130
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
890
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Balancing Empowerment & Direction
lara
4
670
Making Projects Easy
brettharned
119
6.4k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
610
The Illustrated Children's Guide to Kubernetes
chrisshort
48
51k
A Tale of Four Properties
chriscoyier
160
23k
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.