2023/11/08 Findyさま主催の"スケーラビリティ×高可用性を追求するIoTアーキテクチャ Lunch LT "の発表資料

1. ビットキーのIoT基盤における
AWS IoT Rule Action 活用
佐々木 了
株式会社ビットキー 2023/11/08

2. 2
Outline
1. ビットキーについて
2. ビットキーのIoTアーキテクチャ
3. IoTトラフィック傾向
4. 課題
5. Rule Actionによる解決アプローチ
6. 注意

3. 佐々木 了
Ryo Sasaki
2012/04
2017/07
某 通信系SIer 入社
・元々はNWエンジニアだったので BGP使った他拠点 NW作ったりとか
・自治体とか官公庁系システムに携わったりすることが多かったかな
・橋梁点検ロボット開発やったりとか
フリーランスに転向
・ペネトレーションテストやったりとか
・OpenStatkとOpenShift結構やってたりとか
・ハイブリッドクラウド作ったりとか
・工事現場DXのサービス作って運営したりとか
・HWスタートアップのプロトタイピングやったりとか
2021/11 ビットキーにジョイン
UWBで遊んでます。
村田製作所さんの
Type2BP評価キットおすすめ！
https://www.murata.com/ja-jp/products/connectivitymodul
e/ultra-wide-band/nxp/type2bp

4. 4
はじめに
● お伝えしたいこと
○ ビットキーの現在のざっくりとしたIoTアーキテクチャについて
○ IoT Rule Actionの活用シーンと注意点について
● ごめんなさい
○ 今回は時間が短いので技術的に突っ込んだ内容はやらないです 󰢛

5. 5
1. ビットキーについて

11. 11

12. SaaS
IoT
HW/FW

13. SaaS
IoT
HW/FW
ざっくりこのへんの
中間レイヤーやってます

14. 1
4
2. ビットキーのIoTアーキテクチャ

15. ビットキーは
マルチクラウド環境

16. 16
2. ビットキーのIoTアーキテクチャ

17. 17
2. ビットキーのIoTアーキテクチャ
IoTレイヤーおよび
そこから各種HWを
制御する処理はこっち

18. なぜ？

19. 19
2. ビットキーのIoTアーキテクチャ
● それぞれのクラウドプラットフォームには得手不得手がある
○ この領域はこっちのほうが扱いやすいよね、とか、先進的だよね、とか
● 下手に1つのクラウドにこだわって苦手分野をその中で頑張るよりは、
うまい具合にそれぞれを組み合わせるほうが最善に近づけるはず
○ 事業を爆速で成長させないといけない時期において、
オールインワンなGCPのFirebaseは開発速度の点で大変魅力的だった
○ 一方でGCPはどうしてもIoT領域が弱かった
○ この部分では明らかにAWSのほうが一日の長があった

20. 20
2. ビットキーのIoTアーキテクチャ
● それぞれのクラウドプラットフォームには得手不得手がある
○ この領域はこっちのほうが扱いやすいよね、とか、先進的だよね、とか
● 下手に1つのクラウドにこだわって苦手分野をその中で頑張るよりは、
うまい具合にそれぞれを組み合わせるほうが最善に近づけるはず
○ 事業を爆速で成長させないといけない時期において、
オールインワンなGCPのFirebaseは開発速度の点で大変魅力的だった
○ 一方でGCPはどうしてもIoT領域が弱かった
○ この部分では明らかにAWSのほうが一日の長があった
このあたりは今回は割愛

21. 実は・・・

23. IoTプロダクトは
ここだけ

24. 24
API
2. ビットキーのIoTアーキテクチャ
Cloud Load
Balancing
Cloud Run
Cloud
Functions
Database
AlloyDB
Firestore
Contents
Cloud
Storage
frontend（SPA）
Firebase
hosting
RUM Logs
dd-agent
Cloud Run
APM
Logging
Error Tracking Monitor
BLE
BLE
BLE

25. 25
API
2. ビットキーのIoTアーキテクチャ
Cloud Load
Balancing
Cloud Run
Cloud
Functions
Database
AlloyDB
Firestore
Contents
Cloud
Storage
frontend（SPA）
Firebase
hosting
RUM Logs
dd-agent
Cloud Run
APM
Logging
Error Tracking Monitor
BLE
BLE
BLE
純粋なIoTレイヤーは
ここだけ

26. 26
2. ビットキーのIoTアーキテクチャ
● 各種コマンドのやりとりを代行
● ログやバッテリー変化のリアルタイムな通知
IoT Core
BLE
BLE
MQTT
ここだけIoT
これらは
インターネットに直
結はしてない

27. 27
● 各種コマンドのやりとりを代行
● ログやバッテリー変化のリアルタイムな通知
IoT Core
BLE
MQTT
Lambda
Lambda
API Gateway
コマンド実行
リアルタイム通知
2. ビットキーのIoTアーキテクチャ

28. 2
8
3. IoTトラフィック傾向

29. 平日か休日か
昼か夜か
かなりトラフィック傾向が変わる

30. 30
3. IoTトラフィック傾向
● IoTデバイス: 13000台
● Publish流量
○ ピーク: 75000 msg/min
○ 夜間平均: 14000 msg/min
○ 日中平均: 45000 msg/min

31. 3
1
4. 課題

32. 1. 万が一のスパイク対策
2. コスト

33. 33
4. 課題
万が一のスパイク対策
● 王道はIoT Core + Lambdaなサーバーレスな手法
● Lambdaの場合トラフィックがスパイクしたときに
スロットリングする可能性がある
○ 初期値: 1000 (ビットキーの場合ちょっとでも負荷かかれば簡単に超える)
○ 申請により比較的楽ちんに緩和可能

34. 34
4. 課題
コスト
● IoT関連処理の場合、1つ1つの処理は大変軽い
● よってLambdaとしてはMem256MBで十分足りるような
小さな関数で構わないケースが多いだろう
● それでもチリが積もればなんとやら・・・である
ChatGPTのDALL-E3に描かせた”ちりつも”の図

35. 3
5
5. Rule Actionによる
解決アプローチ

36. IoT Rule Action
めちゃんこええで

37. 37
5. Rule Actionによる解決アプローチ
AWS IoT ルールアクションは、ルールが呼び出されたときに行う動作を指定します。 Amazon DynamoDB
データベースへのデータの送信、 Amazon Kinesis Data Streams へのデータの送信、AWS Lambda 関数
の呼び出しなどのアクションを定義できます。 AWS IoT は、アクションのサービスを使用できる AWS リー
ジョン で次のアクションをサポートします。
https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/iot-rule-actions.html
ざっくり言うと、SQLライクにクエリを書いて
任意のメッセージに対してごにょごにょできる機能
IoT Core
これ
IoT Rule Action とは

38. 38
● IoTデータ処理パイプラインの起点として大変優秀
● IoT Coreの中を流れるMQTTメッセージに対して
○ クエリを書いてひっかけて
○ 何かのアクション
をさせられる
● この機能自体は割と有名
○ 特定のトピックにメッセージが流れたら
Lambdaが発火してそのメッセージを加工してどうのこうの
5. Rule Actionによる解決アプローチ
IoT Rule Action とは
王道パターン

39. 39
● IoTデータ処理パイプラインの起点として大変優秀
● IoT Coreの中を流れるMQTTメッセージに対して
○ クエリを書いてひっかけて
○ 何かのアクション
をさせられる
● この機能自体は割と有名
○ 特定のトピックにメッセージが流れたら
Lambdaが発火してそのメッセージを加工してどうのこうの
5. Rule Actionによる解決アプローチ
IoT Rule Action とは
王道パターン
それだけじゃもったいない！！

40. 40
● メッセージを自動的にパースしてDynamoDBにPUTする
● S3に保存する
● 外部のHTTP APIを叩く
● データをちょこっと加工してRe-Publishさせる
● Kinesisにつなげる
● どこかにSNS通知を投げる
全部 Rule Actionによって
Lambdaなしで出来るよ！
5. Rule Actionによる解決アプローチ
IoT Rule Action とは

41. 41
5. Rule Actionによる解決アプローチ

42. 42
参考: https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/iot-sql-reference.html
5. Rule Actionによる解決アプローチ
この内容を自動的に
DynamoDBやS3に保存とか。
文字列加工をこの中で事前に
やっておくことも可能。

43. 43
5. Rule Actionによる解決アプローチ
SQLで抽出したデータを
どうするか(アクション)
※まだ他にもたくさんあるよ！

44. 44
● メリット
○ 高度なプログラミングが不要
○ LambdaなどのFaaSをも上回るスケーリング性能
○ 爆安(参考: https://aws.amazon.com/jp/iot-core/pricing/)
● デメリット
○ ローカルで試しづらい
○ ログがめちゃくちゃわかりづらい
■ よって何か問題があったとしても、それに気づくのが至難の業
5. Rule Actionによる解決アプローチ
IoT Rule Action のメリデメ
Rule Action + Lambda
-> Rule Action単独になるん
だからそりゃ安い

45. 45
5. Rule Actionによる解決アプローチ
開始されたルール: 0.15USD (トリガーされたルール 100 万件あたり/適用されたアクション 100 万件あたり)
適用されたアクション: 0.15USD (トリガーされたルール 100 万件あたり/適用されたアクション 100 万件あたり)
ルールとアクションは、メッセージサイズ 5 KB 単位で計算されます。例えば、5KB のメッセージを処理し、何もアクションを適用しないルールは、1
つのルールと 1 つのアクションとして測定されます。また、8KB のメッセージを処理し、2 つのアクションを適用するルールは、2 つのルールと 4
つのアクションとして測定されます。リージョン外からの特定のルールから「出し」「入れ」するデータの転送は、こちらの「データ転送」にリストされ
ている Amazon Elastic Compute Cloud (Amazon EC2) データ転送料金が課金されます。
ルールエンジンで decode() 関数を使用して、エンコードされた Protocol Buffer (Protobuf) メッセージを JavaScript Object Notation (JSON) 形式
にデコードすると、1 つのアクションとして計測されます。ただし、Protobuf-to-JSON デコードは、5KB 単位での課金ではありません。Protobuf
メッセージのデコードは、最大ペイロードサイズ 128KB まで、1 デコード (アクション) 分の料金がかかりますが、ルールトリガーとアクション実行に
ついては、通常のメータリングと同様に追加料金を支払います。
https://aws.amazon.com/jp/iot-core/pricing/
IoT Rule Action コスト体系

46. 46
● IoT関連の処理なんて大体がめちゃくちゃ軽い
● Lambdaで書くにしても、
大した実装コストもメンテナンスコストもかからないだろう
5. Rule Actionによる解決アプローチ

47. 47
● とはいえ”作らず実現”できるならそのほうがよくない？
○ 自分たちでは”一切のコンピューティングリソースを持たない”ということ
● 極限まで実装コストと運用コストを下げられる
● どれだけトラフィックに変化があっても、いくらでもついていける
○ Lambdaのようにスロットリングに悩まされることもない
5. Rule Actionによる解決アプローチ

48. ビットキーの場合、
今までLambdaにやらせていたことを
可能な限りRule Action単独に移行
これでIoT関連の月額コストの約30%を削減

49. 49
IoT Core Lambda DynamoDB
DynamoDB
IoT Core
今まで
Rule Action
だけでOK
5. Rule Actionによる解決アプローチ

50. 50
IoT Core Lambda DynamoDB
DynamoDB
IoT Core
今まで
Rule Action
だけでOK
5. Rule Actionによる解決アプローチ
Lambdaがなくなるので、
そこのクオータを気にする必
要がない

51. 51
IoT Core Lambda DynamoDB
DynamoDB
IoT Core
今まで
Rule Action
だけでOK
5. Rule Actionによる解決アプローチ
Rule Action単独での処理に
なるため安い。速い。
絶対的なスケーリング性能。

52. 52
IoT Core
Lambda
IoT Core
今まで
Rule Action
だけでOK
API
API
5. Rule Actionによる解決アプローチ

53. 53
API
Cloud Load
Balancing
Cloud Run
Cloud
Functions
Database
AlloyDB
Firestore
Contents
Cloud
Storage
frontend（SPA）
Firebase
hosting
RUM Logs
dd-agent
Cloud Run
APM
Logging
Error Tracking Monitor
BLE
BLE
BLE
5. Rule Actionによる解決アプローチ
これもLambdaを使わずに
Rule Action単独でいける
RESTful API

54. 5
4
6. 注意

55. 55
6. 注意
● デメリットというより、そもそもの仕様の話になるけれど・・・
Rule Actionではやれることに限界がある
● 大したデータ加工はできない
○ 参考: AWS IoT 関数
(https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/iot-sql-functions.html)
● そもそも流れるペイロードやETLが複雑なら、
RuleAction単独ではまず太刀打ちできない
期待しすぎはダメゼッタイ

56. 56
● 当然、Lambdaとかの何らかのまともなコンピューティングに
頼らないといけないケースだってある
○ ビットキーとしてもそういうワークロードは当然あるので、
Lambdaに頼っているシーンは依然として存在する
6. 注意

57. 57
● 実際には”めっちゃ頑張ればRule Action単独でいけそう”というのもある
● しかし、それをRule Actionで頑張りすぎると異常に認知負荷が上がる
○ 保守性を著しく下げかねない
○ ならLambdaのほうがわかりやすくない？
6. 注意
これぐらいならまぁ。
加工が入ってないだけまだマシ。
もうちょいいくと厳しくなってきそう。

58. 58
● ただし大事なのは何でもかんでもLambdaに頼るのではなく、
こういうようにIoT内部機能を使い倒したほうが
より良いアーキテクチャにできる可能性がある、ということ
● Lambdaに頼るにしても、起動してから中でValidationするのではなく、
Rule ActionのSQLのwhere句を頑張れば、
そもそもLambdaの起動回数を減らせる -> コスト削減
6. 注意
ビットキーの場合、この手法でコストを
かなり下げられた側面もある

59. 59
● そういう純正マネージド機能を最大限に享受するためにも
事前にIoTプロダクトとしての設計に関わっていくのが大事
○ そうじゃないとLambdaで頑張らないと絶対無理！みたいな
ペイロードになってしまっても、
後になってからでは取り返しがつかない
6. 注意
マジ大事

60. 60
● ワークロードを如何にシンプルにして、そしてそれらをどこで捌くか？
○ シンプルにすればRule Actionで爆安で捌けるようになるし、
そこから先のデータパイプラインとしても楽になる
○ 何か複雑に処理したいことがあったとしても、それはRule Actionを起点として
始まるデータパイプラインを経た上でのコンピューティングであれば、コストと
しては安くできる (無駄撃ちしなくて良い)
6. 注意
IoT Core Lambda
・絞り込み
・一次加工
二次加工
・実行回数の削減
・実行時間の削減
につながる

61. 61
まとめ
● Lambdaで実現していた処理の一部はRule Actionに移行できる可能性がある
● 実現できれば更なるスケーラビリティの向上とコスト削減を両立できる
● ただし自由度の低さや使いづらさはあるので用法用量は考えよう

62. 62
ビットキーにご興味を持ってくださった方！
もしよければ気軽に技術雑談でもしましょ〜〜！
https://jobs.qiita.com/employers/240/dev_talks/566

63. End of File
6
3