BluetoothメッシュによるIoTシステムを支えるサーバーレス技術

株式会社WHERE仲山昌宏

( a.k.a. @nekoruri )

自己紹介＆会社紹介 国土交通省の「ジャパンスマートナビ」（東京駅付近の地下道ナビ実験）の測位エンジンなんかもやってます

• WHERE, Inc. [ https://where123.jp/ ]• Bluetoothメッシュネットワークを活用したソリューションを提供• もともとは地域観光アプリの開発会社

⇒屋内測位でBLEビーコンよくね？⇒ BLEビーコンの管理大変だからメッシュ技術で遠隔一括管理⇒やってみたら色々なことに使えそう ←イマココ

• 仲山昌宏＠IoT基盤センターサービスプロデューサー• ビーコンを制御するクラウド基盤の設計・開発・運用• Bluetoothメッシュネットワーク上の上位プロトコル設計

個人の活動• 通称Aki (@nekoruri)

• 『秋葉原生まれ大手町育ちの歌って踊れる江戸っ子フルスタックインフラエンジニア』

• 同人物書き• 「Serverlessを支える技術」今日も受付横にて頒布中！

• 副業：セキュリティ人材育成• セキュリティ・キャンプ / SecHack365

• Microsoft MVP (Azure, 2017/01-)• ProjectDIVA Arcade LV.624

WHERE, Inc.• 「Bluetoothメッシュネットワークを活用したソリューション」

• ちょっと技術について紹介

Bluetooth LEの基本• Bluetooth LE（Bluetooth Low Energy; BLE）

• 地獄の2.4GHz（ISMバンド：電子レンジなど通信以外の電波にも許可された周波数帯）を使う通信方式

• 他にも、Wi-Fi、RFID、コードレス電話、ラジコンなどが通信にも利用• Bluetooth 4.0以降のBLEと、それ以前の「Classic Bluetooth」は別物

Bluetooth LEの通信形態• ブロードキャスト

• 最近はiBeaconなどにも使われる1:Nの通信• （独自に作らない限り）到達確認・再送制御などはない• 「だいたい届いているはず」ぐらいの期待値で繰り返し送信• 見通し100m以上届く ※確実に届くとは言っていない

• コネクション• 相手を決めて行われる1:1の通信• きちんとした再送制御など安定した通信路を提供• ある程度電波が確実に届くことが必要、10mあたりから不安定

Bluetoothメッシュネットワーク？• ブロードキャスト通信をリレーしていく

• フラッド型メッシュ

クラウドゲートウェイ

メッシュネットワーク

ブロードキャスト通信送信元の再送制御

センサー情報等

Bluetoothメッシュネットワーク？• ブロードキャスト通信をリレーしていく

• フラッド型メッシュ

クラウドゲートウェイ

ブロードキャスト通信

センサー情報等

Bluetoothメッシュネットワーク？• ブロードキャスト通信をリレーしていく

• フラッド型メッシュ

クラウドゲートウェイ

センサー情報等

送信元の再送制御

Bluetoothメッシュネットワーク？• ブロードキャスト通信をリレーしていく

• フラッド型メッシュ

クラウドゲートウェイ

センサー情報等

Bluetoothメッシュネットワーク？• ブロードキャスト通信をリレーしていく

• フラッド型メッシュ

クラウドゲートウェイ

メッシュネットワーク

ブロードキャスト通信送信元の再送制御

センサー情報等

Bluetooth mesh• Bluetoothを使ったメッシュネットワークの「標準規格」

• 2017年7月にBluetooth SIGより正式発表• Bluetooth 4.0以降の上に乗っかるプロトコル（5.0以降であれば新しい無線方式などの恩恵も得られる）

• フラッド型メッシュのQualcomm社「CSRmesh」をベースに規格化

• あくまでプロトコルが決まっただけ• 発表を受けて、各ベンダーからのSDKが出揃ってきた• WHEREでは、既にCSRmeshベースでフラッド型メッシュを実用化済

• できることはだいたい同じ

Bluetoothメッシュ ×サーバーレス• Bluetoothのメッシュ通信でデータ収集

⇒たくさんのデータがぽんぽんあがってくる⇒少量のデータがたまにあがってくる

• たくさんのデータからリアルタイムで集計して見たい⇒ストリーム処理

• それを少ないリソース（コスト・人員）で回したい⇒サーバーレス！

Gateway 分析 API

Bluetoothメッシュの活用事例１測位用ビーコンの遠隔一括管理

Bluetoothメッシュの活用事例：測位用ビーコンの遠隔一括管理• 観光アプリ用の測位インフラ

• 「GPSより細かい測位をして、街に拡がる美術品を紹介をしたい」• ビルの谷間でGPSの精度が低い• EXBeacon（メッシュ対応BLEビーコン）を街中に80個設置

• 課題• 従来のビーコンでは、現地に行かないと設定変更ができないし電池残量も判らない ⇒メッシュネットワーク経由の通信で管理

• 電池駆動 ⇒ BLEの名前の通り

【会場のみ】

同内容を以下のURLで公開中https://exbeacon.where123.jp/faret/

測位用ビーコンの遠隔一括管理システム• サーバーレスでやってみた初プロジェクト

• ＝IoT事業の初プロジェクト

• 踏み出した理由• データ量・アクセス頻度少ないので、FaaSの価格モデルに向いてそう• クラウド側担当が自分一人で、運用後に障害で割り込まれたくない• そもそも機能自体は多くない（集めた情報の取得と設定送信）• 最悪でもゲートウェイの直接操作で当面のリスクは受容可能

• 当時（2016年8月）ちょうど「サーバレスの薄い本」を出した時期• サーバーレスやっていこうという気持ち！！！！！！！

測位用ビーコンの遠隔一括管理システム

EXBeacon

AWSCredential

SORACOMFunnel

KinesisStreams

Lambda(APIGW経由) DynamoDB

BLE Mesh

BLEビーコン

SORACOMBeam

測位用ビーコンの遠隔一括管理システム

EXBeacon

AWSCredential

SORACOMFunnel

KinesisStreams

Lambda(APIGW経由) DynamoDB

BLE Mesh

BLEビーコン

SORACOMBeam

それぞれのビーコンの電池残量や、現在の設定内容をDBに保存

測位用ビーコンの遠隔一括管理システム

EXBeacon

AWSCredential

SORACOMFunnel

KinesisStreams

Lambda(APIGW経由) DynamoDB

BLE Mesh

BLEビーコン

SORACOMBeam

ビーコンに対する設定値を定期的に取得（いわゆるデバイスツイン／デバイスシャドウ）

測位用ビーコンの遠隔一括管理システム

EXBeacon

AWSCredential

SORACOMFunnel

KinesisStreams

Lambda(APIGW経由) DynamoDB

BLE Mesh

BLEビーコン

SORACOMBeam

ゲートウェイとクラウドの通信部分はSORACOMを使って簡略化

ゲートウェイ側のソフトウェア単一化

※SORACOM Gateでメンテ用裏口も確保（このVXLANルータ＋踏み台だけEC2）

Lambdaの開発• Node.js

• トランスパイラ無しで素のNode.js（初期は4.3、今は6.10）• ビルドの簡潔さ維持を優先。ただ、はやくawait使いたい……

• Kinesis経由で流れてくるデータとの結合テスト難しい• IoTのE2Eテスト……• ほとんどロジックは無いので初期はテスト無し😇😇

• 処理の冪等性に気をつける• 同じデータが繰り返し来たら同じDB結果になるようにする

• LambdaはApexで操作• マネジメントコンソール？御冗談を……• Serverless Frameworkは主語大きくてちょっと気に入らなかった時期（若かった）• とにかくlightweightなツールという印象で採用決定• 当時はLambda一個ずつApex projectもGit repoも個別⇒つらかった

運用と管理• みんなだいすき？Terraformで全体を管理

• 今後機能が増えれば増えるほど利用サービスが増える• 最初からInfrastructure as Codeしていかないと死ぬ😇😇• 過去の死屍累々は知っていたけどそろそろ枯れてると予想

• ApexのTerraform統合は使わず• システムの中のLambdaであってLambdaに他のコンポーネントが付随するのではないのでは

• Terraformでダミー関数をデプロイ、以後はApexでデプロイ• memory_size等もApex側で制御

成果• 割と大きな問題無く成功

• このまま全部サーバーレスで行けるんじゃねという感触を得た

Bluetoothメッシュの活用事例２ビーコンTXからの受信による測位

ビーコンTX

• BLEのアドバタイズ（ブロードキャスト）を定期的に送信• TX：Transmitter（送信機）• 薄型ボタン電池等で１年～数ヶ月動く• 人やモノに付けることが容易

メッシュ経由で受信してTXの位置を推定• 天井や机、壁などでビーコンTXからの電波を受信

• 受信したEXBeaconは、受信強度などをメッシュ経由でクラウドに送信• クラウド側で分析することで、各ビーコンTXとEXBeaconの位置関係を推定する

測位アルゴリズムとの闘いの始まり• 展示会向けに、DynamoDB上の直近データを基にした簡易測位を実装したのが運の尽きビジネスの始まり

• EXBeacon⇒ゲートウェイ⇒ SORACOM Funnel ⇒ Kinesis Streams⇒ AWS Lambda⇒ DynamoDB

• ここまで詰まらなければ数秒で反映される• ひとまず移動平均で強い奴を探す（子供のおもちゃレベル）• リアルタイムで色々できるんじゃね？という雰囲気の醸成（つらい）

リアルタイムでなんでもはできない• Kinesis Streams ＋ AWS Lambda ＋ DynamoDB

• シンプルなことはシンプルに実現可能• できることとできないことがある• 実現しやすいことと実現しづらいことがある

• 素直な逐次処理以外は基本的に難しいor面倒or高価• 一定の範囲の直近データを扱うのはDynamoDBに聞かないといけない• Kinesis Streamsから呼ばれる度に直近データを取りに行くと必要性能増えまくってつらい

• Redis等の併用も考えた方が良い（が結局まだ採用していない）

Bluetoothメッシュの活用事例３居場所見える化システム

働き方改革と居場所の見える化• フリーアドレスになったので居場所を楽に計測したい

• EXBeaconを使ったビーコンTX測位ソリューションを提供• 従業員みなさんに薄型のビーコンTXを持っていただく（首下げネームカードと一緒）

• 天井にカスタム型EXBeaconをばらまいて人やモノを測位• リアルタイムで居場所を画面に表示

【会場のみ】

同内容を以下のURLで公開中https://exbeacon.where123.jp/docomocschiba/

システムの分割• フロントエンド苦手です！死んでしまいます！

• 隣のアプリチームに、フロント側ウェブアプリを依頼• 自分の方で測位結果をAPIとして提供• 最終的に、測位結果の細かい表示調整までフロント側で実装

• 実質的には、組織ごとのマイクロサービス化• バックエンド側はサーバーレス構成でAPIをフロント側に提供、共通したコア技術である測位アルゴリズムを安定して運用

• フロント側は一般的なウェブアプリをHerokuで実行、CMS的な機能などお客様の要望に柔軟に対応

測位用ビーコンの遠隔一括管理システム

EXBeacon

SORACOMFunnel

KinesisStreams

Lambda(APIGW経由) DynamoDB

BLE Mesh

BLEビーコン

Front App

測位用ビーコンの遠隔一括管理システム

EXBeacon

SORACOMFunnel

KinesisStreams

Lambda(APIGW経由) DynamoDB

BLE Mesh

BLEビーコン

Front App

この辺はもっと複雑だけど企業秘密😇😇

測位用ビーコンの遠隔一括管理システム• 集計部分がだんだんと複雑に……

• Lambdaを介して多段Kinesis Streamsのような形に• 常に、極力シンプルを保つことを念頭にし続けることが重要

• このあたりから管理の仕組みが現在の形に• 全体で一体のサービスとみなしてレポジトリは全て1つに共有• Terraform

• 機能ごとにmodule化• プロジェクト別に必要なmoduleを呼び出し

• Lambda• moduleごとにまとめてデプロイできるようにスクリプト整備• このあたりをどうCI回すか悩んでレガシーに手戻り中

大規模化に伴う茨の道• ボトルネックの制御

• Lambdaの実行時間と割り当てメモリ量のバランス• Kinesis StreamsのPartition Key（ソラコムさんありがとう！）• DynamoDBのキャパシティ

• 様々なコンポーネントのソムリエ力が試される……！

Lambdaの実行時間と割り当てメモリ量

• AWS Lambdaへの「割り当てメモリ量」• 実際には「メモリ量＋CPU速度」を確保するパラメータ• 右から左に投げる簡単な処理にメモリは要らないね！

⇒ 128MBとかに下げるとCPU速度も落とされて実行時間が延びる

• ログにしか出ない実際のメモリ消費量＋単体の実行時間を元に、調整していく必要がある

• 基本的に暗黙の再処理が許される制約なのだから、クラウド側で過去実績を元に推測したりうまくやってほしい……

Kinesis StreamsのPartition Key

• Kinesis StreamsからLambdaへのデータ送信• 決まった量ごとにLambdaに渡される⇒ Lambdaの処理能力が足りなくなると詰まる

• Lambdaの同時実行数を増やしたい⇒ Kinesis StreamsのShard数（パイプの本数）を増やす必要がある

• Kinesis StreamsのShard数を増やせば良い（2倍/半分にするのはコンパネからぽちぽちできる）

Kinesis StreamsのPartition Key

KinesisStreams Lambda

Function

Function

Function

Function

SORACOMFunnel

Shard

Shard

Shard

Shard

SIMのID(IMSI)毎に分けられるので、同じSIMからのデータは同じShard

に偏る⇒スケールしない

Kinesis StreamsのPartition Key

KinesisStreams Lambda

Function

Function

Function

Function

SORACOMFunnel

Shard

Shard

Shard

Shard

ソラコムさんに対応してもらいSIM関係無く

ランダムにShardに割り振られる設定ができました！

DynamoDBのキャパシティ• サービス上の負荷特性

• 人が居ない時間＝TXからのデータは上がってこない＝DB更新無し！• 人が居るときは、毎秒数百の書き込み性能が必要

• DynamoDB Auto Scalingが神のようなタイミングで降臨• 使ってみた⇒「だいたい」うまくいく• あまりギリギリを攻めすぎるとダメ• 例：二つのテーブルに書き込むLambdaが詰まる

⇒どちらもテーブルも少しずつスロットリング⇒消費量が上がらないので、Auto Scalingが発火しない

コストとの闘い• コスト管理

• DynamoDB Auto Scalingは銀の弾丸では無い（金の弾丸にはなる💸💸）• 小さな案件でもKinesis Streamsの月1500円が地味にかさむ……

• 重要：サーバーレスだからと言ってクラウド費用が安いとは限らない

気になっていること• ストリーミング分析サービス

• AWS Kinesis Analytics• Azure Stream Analytics

• 基本的な設計の再見直し• DynamoDB以外のデータストア（RDBやRedis等）• Azure Durable Functionsのようなステートを持つFaaS

まだまだサーバーレスやっていこう• IoTビジネスは実証実験の数/種類が重要

• とにかく素早く開発することと、余計な割り込み（障害対応）が起きないことが必要

• 今のところサービス固有の障害対応などはほとんど無し♥（今後も間違いなく、自前でやるよりは低い発生確率）

• メッセージ処理のノウハウはベンダー間で共通• 基本的にはイベント駆動＋KVSがベース• Azureへの横展開・その他クラウドのサービスつまみ食いを検討中

• Azureに移植作業中• CosmosDBとDurable FunctionsとStream Analyticsを使いたい• 移植終わったらmeetupあたりでまた共有します

【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/

【PR】We’re hiring!!!!• WHEREではエンジニアを募集中です！

• サーバーレスなIoTプラットフォーム基盤の開発メンバー• サーバーフルなオンプレ向けシステムの開発メンバー

• お仕事楽しいめう• BLEメッシュネットワークとサーバーレスという先端技術の活用最先端• 社内の超優秀なハードウェアエンジニアが作り出す様々なデバイスとの連携

• 様々なセンサー等とクラウドの組み合わせによるソリューションの開発・実現

• 興味ある方は @nekoruriまでご連絡ください！