BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
•
4 likes•4,329 views
2017-11-03 ServerlessConf Tokyo 2017 リンクが白色になってしまっていました。以下です。 https://exbeacon.where123.jp/faret/ https://exbeacon.where123.jp/docomocschiba/
![自己紹介＆会社紹介
国土交通省の「ジャパンスマートナビ」
（東京駅付近の地下道ナビ実験）の
測位エンジンなんかもやってます
• WHERE, Inc. [ https://where123.jp/ ]
• Bluetoothメッシュネットワークを活用したソリューションを提供
• もともとは地域観光アプリの開発会社
⇒ 屋内測位でBLEビーコンよくね？
⇒ BLEビーコンの管理大変だからメッシュ技術で遠隔一括管理
⇒ やってみたら色々なことに使えそう ←イマココ
• 仲山昌宏 ＠IoT基盤センター サービスプロデューサー
• ビーコンを制御するクラウド基盤の設計・開発・運用
• Bluetoothメッシュネットワーク上の上位プロトコル設計](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
Similar to BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo (20)
More from Masahiro NAKAYAMA
More from Masahiro NAKAYAMA (20)
Recently uploaded
Recently uploaded (8)
BluetoothメッシュによるIoTシステムを支えるサーバーレス技術 #serverlesstokyo
- 2. 自己紹介＆会社紹介 国土交通省の「ジャパンスマートナビ」 （東京駅付近の地下道ナビ実験）の 測位エンジンなんかもやってます • WHERE, Inc. [ https://where123.jp/ ] • Bluetoothメッシュネットワークを活用したソリューションを提供 • もともとは地域観光アプリの開発会社 ⇒ 屋内測位でBLEビーコンよくね？ ⇒ BLEビーコンの管理大変だからメッシュ技術で遠隔一括管理 ⇒ やってみたら色々なことに使えそう ←イマココ • 仲山昌宏 ＠IoT基盤センター サービスプロデューサー • ビーコンを制御するクラウド基盤の設計・開発・運用 • Bluetoothメッシュネットワーク上の上位プロトコル設計
- 3. 個人の活動 • 通称Aki (@nekoruri) • 『秋葉原生まれ大手町育ちの歌って踊れる 江戸っ子フルスタックインフラエンジニア』 • 同人物書き • 「Serverlessを支える技術」 今日も受付横にて頒布中！ • 副業：セキュリティ人材育成 • セキュリティ・キャンプ / SecHack365 • Microsoft MVP (Azure, 2017/01-) • ProjectDIVA Arcade LV.624
- 4. WHERE, Inc. • 「Bluetoothメッシュネットワークを活用したソリューション」 • ちょっと技術について紹介
- 5. Bluetooth LEの基本 • Bluetooth LE（Bluetooth Low Energy; BLE） • 地獄の2.4GHz（ISMバンド：電子レンジなど通信以外の電波にも許可 された周波数帯）を使う通信方式 • 他にも、Wi-Fi、RFID、コードレス電話、ラジコンなどが通信にも利用 • Bluetooth 4.0以降のBLEと、それ以前の「Classic Bluetooth」は別物
- 6. Bluetooth LEの通信形態 • ブロードキャスト • 最近はiBeaconなどにも使われる1:Nの通信 • （独自に作らない限り）到達確認・再送制御などはない • 「だいたい届いているはず」ぐらいの期待値で繰り返し送信 • 見通し100m以上届く ※確実に届くとは言っていない • コネクション • 相手を決めて行われる1:1の通信 • きちんとした再送制御など安定した通信路を提供 • ある程度電波が確実に届くことが必要、10mあたりから不安定
- 12. Bluetooth mesh • Bluetoothを使ったメッシュネットワークの「標準規格」 • 2017年7月にBluetooth SIGより正式発表 • Bluetooth 4.0以降の上に乗っかるプロトコル （5.0以降であれば新しい無線方式などの恩恵も得られる） • フラッド型メッシュのQualcomm社「CSRmesh」をベースに規格化 • あくまでプロトコルが決まっただけ • 発表を受けて、各ベンダーからのSDKが出揃ってきた • WHEREでは、既にCSRmeshベースでフラッド型メッシュを実用化済 • できることはだいたい同じ
- 13. Bluetoothメッシュ × サーバーレス • Bluetoothのメッシュ通信でデータ収集 ⇒たくさんのデータがぽんぽんあがってくる ⇒少量のデータがたまにあがってくる • たくさんのデータからリアルタイムで集計して見たい ⇒ストリーム処理 • それを少ないリソース（コスト・人員）で回したい ⇒サーバーレス！ Gateway 分析 API
- 15. Bluetoothメッシュの活用事例： 測位用ビーコンの遠隔一括管理 • 観光アプリ用の測位インフラ • 「GPSより細かい測位をして、街に拡がる美術品を紹介をしたい」 • ビルの谷間でGPSの精度が低い • EXBeacon（メッシュ対応BLEビーコン）を街中に80個設置 • 課題 • 従来のビーコンでは、現地に行かないと設定変更ができないし 電池残量も判らない ⇒ メッシュネットワーク経由の通信で管理 • 電池駆動 ⇒ BLEの名前の通り
- 17. 測位用ビーコンの遠隔一括管理システム • サーバーレスでやってみた初プロジェクト • ＝IoT事業の初プロジェクト • 踏み出した理由 • データ量・アクセス頻度少ないので、FaaSの価格モデルに向いてそう • クラウド側担当が自分一人で、運用後に障害で割り込まれたくない • そもそも機能自体は多くない（集めた情報の取得と設定送信） • 最悪でもゲートウェイの直接操作で当面のリスクは受容可能 • 当時（2016年8月）ちょうど「サーバレスの薄い本」を出した時期 • サーバーレスやっていこうという気持ち！！！！！！！
- 22. Lambdaの開発 • Node.js • トランスパイラ無しで素のNode.js（初期は4.3、今は6.10） • ビルドの簡潔さ維持を優先。ただ、はやくawait使いたい…… • Kinesis経由で流れてくるデータとの結合テスト難しい • IoTのE2Eテスト…… • ほとんどロジックは無いので初期はテスト無し😇😇 • 処理の冪等性に気をつける • 同じデータが繰り返し来たら同じDB結果になるようにする • LambdaはApexで操作 • マネジメントコンソール？御冗談を…… • Serverless Frameworkは主語大きくてちょっと気に入らなかった時期（若かった） • とにかくlightweightなツールという印象で採用決定 • 当時はLambda一個ずつApex projectもGit repoも個別⇒つらかった
- 23. 運用と管理 • みんなだいすき？Terraformで全体を管理 • 今後機能が増えれば増えるほど利用サービスが増える • 最初からInfrastructure as Codeしていかないと死ぬ😇😇 • 過去の死屍累々は知っていたけどそろそろ枯れてると予想 • ApexのTerraform統合は使わず • システムの中のLambdaであってLambdaに他のコンポーネントが付随 するのではないのでは • Terraformでダミー関数をデプロイ、以後はApexでデプロイ • memory_size等もApex側で制御
- 26. ビーコンTX • BLEのアドバタイズ（ブロードキャスト）を定期的に送信 • TX：Transmitter（送信機） • 薄型ボタン電池等で１年～数ヶ月動く • 人やモノに付けることが容易
- 27. メッシュ経由で受信してTXの位置を推定 • 天井や机、壁などでビーコンTXからの電波を受信 • 受信したEXBeaconは、受信強度などをメッシュ経由でクラウドに送信 • クラウド側で分析することで、各ビーコンTXとEXBeaconの位置関係を 推定する
- 28. 測位アルゴリズムとの闘いの始まり • 展示会向けに、DynamoDB上の直近データを基にした簡易測位 を実装したのが運の尽きビジネスの始まり • EXBeacon ⇒ ゲートウェイ ⇒ SORACOM Funnel ⇒ Kinesis Streams ⇒ AWS Lambda ⇒ DynamoDB • ここまで詰まらなければ数秒で反映される • ひとまず移動平均で強い奴を探す（子供のおもちゃレベル） • リアルタイムで色々できるんじゃね？という雰囲気の醸成（つらい）
- 29. リアルタイムでなんでもはできない • Kinesis Streams ＋ AWS Lambda ＋ DynamoDB • シンプルなことはシンプルに実現可能 • できることとできないことがある • 実現しやすいことと実現しづらいことがある • 素直な逐次処理以外は基本的に難しいor面倒or高価 • 一定の範囲の直近データを扱うのはDynamoDBに聞かないといけない • Kinesis Streamsから呼ばれる度に直近データを取りに行くと必要性能 増えまくってつらい • Redis等の併用も考えた方が良い（が結局まだ採用していない）
- 31. 働き方改革と居場所の見える化 • フリーアドレスになったので居場所を楽に計測したい • EXBeaconを使ったビーコンTX測位ソリューションを提供 • 従業員みなさんに薄型のビーコンTXを持っていただく （首下げネームカードと一緒） • 天井にカスタム型EXBeaconをばらまいて人やモノを測位 • リアルタイムで居場所を画面に表示
- 33. システムの分割 • フロントエンド苦手です！死んでしまいます！ • 隣のアプリチームに、フロント側ウェブアプリを依頼 • 自分の方で測位結果をAPIとして提供 • 最終的に、測位結果の細かい表示調整までフロント側で実装 • 実質的には、組織ごとのマイクロサービス化 • バックエンド側はサーバーレス構成でAPIをフロント側に提供、 共通したコア技術である測位アルゴリズムを安定して運用 • フロント側は一般的なウェブアプリをHerokuで実行、 CMS的な機能などお客様の要望に柔軟に対応
- 36. 測位用ビーコンの遠隔一括管理システム • 集計部分がだんだんと複雑に…… • Lambdaを介して多段Kinesis Streamsのような形に • 常に、極力シンプルを保つことを念頭にし続けることが重要 • このあたりから管理の仕組みが現在の形に • 全体で一体のサービスとみなしてレポジトリは全て1つに共有 • Terraform • 機能ごとにmodule化 • プロジェクト別に必要なmoduleを呼び出し • Lambda • moduleごとにまとめてデプロイできるようにスクリプト整備 • このあたりをどうCI回すか悩んでレガシーに手戻り中
- 37. 大規模化に伴う茨の道 • ボトルネックの制御 • Lambdaの実行時間と割り当てメモリ量のバランス • Kinesis StreamsのPartition Key（ソラコムさんありがとう！） • DynamoDBのキャパシティ • 様々なコンポーネントのソムリエ力が試される……！
- 38. Lambdaの実行時間と割り当てメモリ量 • AWS Lambdaへの「割り当てメモリ量」 • 実際には「メモリ量＋CPU速度」を確保するパラメータ • 右から左に投げる簡単な処理にメモリは要らないね！ ⇒ 128MBとかに下げるとCPU速度も落とされて実行時間が延びる • ログにしか出ない実際のメモリ消費量＋単体の実行時間を元に、調整 していく必要がある • 基本的に暗黙の再処理が許される制約なのだから、クラウド側 で過去実績を元に推測したりうまくやってほしい……
- 39. Kinesis StreamsのPartition Key • Kinesis StreamsからLambdaへのデータ送信 • 決まった量ごとにLambdaに渡される ⇒ Lambdaの処理能力が足りなくなると詰まる • Lambdaの同時実行数を増やしたい ⇒ Kinesis StreamsのShard数（パイプの本数）を増やす必要がある • Kinesis StreamsのShard数を増やせば良い （2倍/半分にするのはコンパネからぽちぽちできる）
- 40. Kinesis StreamsのPartition Key Kinesis Streams Lambda Function Function Function Function SORACOM Funnel Shard Shard Shard Shard SIMのID(IMSI)毎に分けられるので、 同じSIMからのデータは同じShard に偏る⇒スケールしない
- 41. Kinesis StreamsのPartition Key Kinesis Streams Lambda Function Function Function Function SORACOM Funnel Shard Shard Shard Shard ソラコムさんに対応してもらい SIM関係無く ランダムにShardに割り振られる 設定ができました！
- 42. DynamoDBのキャパシティ • サービス上の負荷特性 • 人が居ない時間＝TXからのデータは上がってこない＝DB更新無し！ • 人が居るときは、毎秒数百の書き込み性能が必要 • DynamoDB Auto Scalingが神のようなタイミングで降臨 • 使ってみた ⇒ 「だいたい」うまくいく • あまりギリギリを攻めすぎるとダメ • 例：二つのテーブルに書き込むLambdaが詰まる ⇒ どちらもテーブルも少しずつスロットリング ⇒ 消費量が上がらないので、Auto Scalingが発火しない
- 43. コストとの闘い • コスト管理 • DynamoDB Auto Scalingは銀の弾丸では無い（金の弾丸にはなる💸💸） • 小さな案件でもKinesis Streamsの月1500円が地味にかさむ…… • 重要： サーバーレスだからと言ってクラウド費用が安いとは限らない
- 44. 気になっていること • ストリーミング分析サービス • AWS Kinesis Analytics • Azure Stream Analytics • 基本的な設計の再見直し • DynamoDB以外のデータストア（RDBやRedis等） • Azure Durable Functionsのようなステートを持つFaaS
- 45. まだまだサーバーレスやっていこう • IoTビジネスは実証実験の数/種類が重要 • とにかく素早く開発することと、 余計な割り込み（障害対応）が起きないことが必要 • 今のところサービス固有の障害対応などはほとんど無し♥ （今後も間違いなく、自前でやるよりは低い発生確率） • メッセージ処理のノウハウはベンダー間で共通 • 基本的にはイベント駆動＋KVSがベース • Azureへの横展開・その他クラウドのサービスつまみ食いを検討中 • Azureに移植作業中 • CosmosDBとDurable FunctionsとStream Analyticsを使いたい • 移植終わったらmeetupあたりでまた共有します
- 46. 【PR】Internet Week 2017 • Internet Weekとは？ • 「インターネットに関する技術の研究・開発、 構築・運用・サービス に関わる人々が一堂に会し、 主にインターネットの基盤技術の基礎知 識や最新動向を学び、 議論し、理解と交流を深めるためのイベント」 • 11月28日～12月1日 • 11月29日 「S7 IoTもおまかせ！ サーバーレスで変わるインフラとの関わり方」 • Microsoft吉田パクえ氏、オルターブース松村氏、JPNE石田氏、仲山 • ServerlessConfとはまた違った視点からのイベント • https://www.nic.ad.jp/iw2017/program/s07/
- 47. 【PR】We’re hiring!!!! • WHEREではエンジニアを募集中です！ • サーバーレスなIoTプラットフォーム基盤の開発メンバー • サーバーフルなオンプレ向けシステムの開発メンバー • お仕事楽しいめう • BLEメッシュネットワークとサーバーレスという先端技術の活用最先端 • 社内の超優秀なハードウェアエンジニアが作り出す様々なデバイスと の連携 • 様々なセンサー等とクラウドの組み合わせによるソリューションの 開発・実現 • 興味ある方は @nekoruri までご連絡ください！