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.8k
【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
投資家様向けビジネス概要<2025年8月版>
soracom
PRO
0
160
Business Overview for Investors[August 2025 Edition]
soracom
PRO
0
20
少人数・短期間で実現!“ゼロから作らない” 4つの事例から見る、新時代IoT【SORACOM Discovery 2025】
soracom
PRO
0
260
現場のリアルをカメラで変える!小売・商業施設の「現場改革」最前線【SORACOM Discovery 2025】
soracom
PRO
0
220
【特別講演】公開思考実験!もしも、この世界から「ヒトとモノのつながり」が消えたなら?【SORACOM Discovery 2025】
soracom
PRO
0
140
トヨタのIoT民主化を支援!「D-ROOM」の仕組みと現場浸透のくふう【SORACOM Discovery 2025】
soracom
PRO
0
270
クラウド全盛時代におけるIoTエッジ活用とグローバルサプライチェーン戦略【SORACOM Discovery 2025】
soracom
PRO
0
150
【特別講演】デジタル変革の羅針盤 ~CIO/CDOが描くIoTとAIの未来~【SORACOM Discovery 2025】
soracom
PRO
0
260
現場データを“武器”に変える!データ連携で加速する製造DX【SORACOM Discovery 2025】
soracom
PRO
0
140
Other Decks in Technology
See All in Technology
実践AIガバナンス
asei
3
300
「魔法少女まどか☆マギカ Magia Exedra」の必殺技演出を徹底解剖! -キャラクターの魅力を最大限にファンに届けるためのこだわり-
gree_tech
PRO
0
460
実践アプリケーション設計 ③ドメイン駆動設計
recruitengineers
PRO
13
4.1k
個人CLAUDE.md紹介と設定から学んだこと/introduce-my-claude-md
shibayu36
0
180
ここ一年のCCoEとしてのAWSコスト最適化を振り返る / CCoE AWS Cost Optimization devio2025
masahirokawahara
1
1.3k
生成AI時代に必要な価値ある意思決定を育てる「開発プロセス定義」を用いた中期戦略
kakehashi
PRO
1
250
生成AI時代のデータ基盤
shibuiwilliam
4
2.7k
役割は変わっても、変わらないもの 〜スクラムマスターからEMへの転身で学んだ信頼構築の本質〜 / How to build trust
shinop
0
160
実運用で考える PGO
kworkdev
PRO
0
130
まだ間に合う! StrandsとBedrock AgentCoreでAIエージェント構築に入門しよう
minorun365
PRO
11
770
絶対に失敗できないキャンペーンページの高速かつ安全な開発、WINTICKET × microCMS の開発事例
microcms
0
370
250905 大吉祥寺.pm 2025 前夜祭 「プログラミングに出会って20年、『今』が1番楽しい」
msykd
PRO
1
250
Featured
See All Featured
A better future with KSS
kneath
239
17k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
The Invisible Side of Design
smashingmag
301
51k
Raft: Consensus for Rubyists
vanstee
140
7.1k
The World Runs on Bad Software
bkeepers
PRO
70
11k
A Tale of Four Properties
chriscoyier
160
23k
Code Reviewing Like a Champion
maltzj
525
40k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
GraphQLとの向き合い方2022年版
quramy
49
14k
Done Done
chrislema
185
16k
Git: the NoSQL Database
bkeepers
PRO
431
66k
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.