1
データ遅延に着目したエッジコンピューティングアーキテクチャの
提案と評価
2015SE029 伊藤 亮太 2015SE037 河合 直也 2015SE075 高橋 哲也 指導教員 青山 幹雄
1. 研究背景と目的
IoT が社会に浸透しつつある．しかし，常に最新のデータ を必要とするシステムでは，データ発生順で送信すると重 要なデータの処理に遅延が発生するケースがある．その ため，重要なイベントには優先的にクラウドへ配信する方法 が必要である．本研究ではエッジコンピューティングアーキ テクチャとNoSQL データベースを用いた方法を提案する．2. 研究課題
本研究課題を以下に示す． (1) センサ/デバイス層からエッジ層へ配信されたメッセー ジに優先度を付与し，それに従う順位付け方法の提案． (2) 優先順位に従って高優先イベントをクラウド層へ優先的 に配信するアーキテクチャの設計方法の提案． (3) 提案アーキテクチャが高負荷時においてもリアルタイム 配信が可能かプロトタイプを用いて検証．3. 関連研究
3.1. エッジコンピューティングアーキテクチャ エッジコンピューティングアーキテクチャは，センサ/デバイ ス層，エッジ層，クラウド層の3 層から構成される[4]． 3.2. Publish/Subscribe アーキテクチャ Publish/Subscribe アーキテクチャとは，パブリッシャ，サブ スクライバ，ブローカから構成される非同期メッセージ配信ア ーキテクチャである．空間と時間の点から分離が可能であり， システムの拡張が可能である[2]． 3.3. RedisRedis とは，オープンソフトウェアの Key Value 型データベ ースである[3]．KVS が持つ特徴以外の主な特徴として以下 の2 点があげられる． (1) Publish/Subscribe アーキテクチャ Publish/Subscribe アーキテクチャに基づいた非同期メ ッセージ配信が可能である． (2) リアルタイムランキングの実装 ラ ン キ ン グ を 識別す る Key に ， Value(Member) と Score(順位を判断するための値)を付与可能である．
4. アプローチ
多種多様のセンサから発生するイベントには優先的にクラ ウドへ配信するべきイベントが存在すると考え，イベントのデ ータを基に生成されるメッセージの優先度に着目した．生成 されるメッセージの優先度はRedis の Score 付与機能を用い ることでランキング表現が可能であると考えた．適切な優先度 の指標に基づき生成されるメッセージに優先度を付与し， Redis を用いて重要なメッセージを優先的に配信可能なエッ ジコンピューティングアーキテクチャの設計方法を提案する．5. 提案アーキテクチャ
5.1. アーキテクチャの設計方法 提案アーキテクチャの構成を図1 に示す． 図 1 提案アーキテクチャの構成 (1) センサ/デバイス層 1) センサ 対象の検知及び相互間の距離を測定し，測定した データを車載ゲートウェイへ送信する． 2) Redis(パブリッシャ) 送信されたデータを基にメッセージを生成し，Redis Broker へメッセージをパブリッシュする． (2) エッジ層 1) Redis(サブスクライバ) センサ/デバイス層からセンサ毎にメッセージを受 信する． 2) Redis(優先順位決め)2 パブリッシュされたメッセージをMember に格納し， Key を付与する．センサ ID を参照して対応する値 (1~n)を Score に格納し，付与する．優先度の高いメッ セージにはScore の値を低く設定し，それぞれのメッ セージをR1~Rn とする． 3) Redis(データベース) 優先度が付与されたメッセージを格納する． 4) Redis(キュー) 格納通知メッセージをエンキュー，デキューする． 5) Redis(パブリッシャ) データベースからソートされた先頭のメッセージを 取得し，クラウド層へ優先度毎に配信する． (3) クラウド層 1) Redis(サブスクライバ) 順位分けされたイベントをそれぞれ受信するサブ スクライバを用意する． 2) Redis(データベース) Redis Broker から配信されたメッセージを格納する． 3) アプリケーション 優先的に配信されたメッセージを利用するクラウド 上のアプリケーションである． 5.2. 振る舞い定義 Redis Broker でのメッセージ受信からメッセージ配信の流 れを図2 に示す． 図 2 Redis Broker のシーケンス図 (1) クラウドは，Redis Broker のメッセージ送信機能へサブ スクリプションを配信する． (2) メッセージ受信機能は，優先度付与機能へ車載ゲート ウェイから受信したメッセージを配信する． (3) 優先度付与機能は，メッセージ受信機能から配信され たメッセージに付与されているデータを解析し，センサ ID を取得する． (4) 優先度付与機能はセンサID 取得後，メッセージ受信 機能から配信されたメッセージへ，Key と Score を付与 する． (5) 優先度付与機能は，メッセージ保持機能とメッセージ格 納機能へKey と Score を付与したメッセージを配信す る． (6) 優先度付与機能はメッセージを格納後，格納通知メッセ ージをエンキューする． (7) メッセージ格納機能は，配信されたメッセージを受信し 格納，メッセージをScore の値の昇順ソートする． (8) メッセージ送信機能は，キューに格納通知メッセージを 要求する． (9) メッセージ送信機能は，格納通知メッセージをデキュー する． (10) メッセージ送信機能はキューから格納通知メッセージを 取得後，メッセージ格納機能にソートされた先頭のメッ セージを要求する． (11) メッセージ格納機能は，メッセージ送信機能が要求する メッセージを配信する． (12) メッセージ送信機能は，配信されたメッセージを受信 し，メッセージ格納機能へ取得したメッセージの削除要 求をする． (13) メッセージ送信機能は，削除要求されたメッセージを削 除する． (14) メッセージ送信機能は，(12)で受信したサブスクライブ 条件を参照する． (15) メッセージ送信機能は，優先度毎にメッセージをクラウ ドへ配信する． 5.3. 優先度定義 本研究では，イベントをRn(n は自然数)とする．n の値が大 きいほど優先度が高いイベントとする．扱うセンサは前方距 離測定センサ，ブレーキセンサ，ステアリングセンサ，アクセ ルセンサとし，発生するイベントの優先度を表1 に示す． 表 1 イベントへの優先度定義 センサ名 優先度 理由 前方距離 測定センサ R4 衝突の危険性を測定する必 要があるため ブレーキ センサ R3 衝突回避の最も有効な手段 は減速することであるため ステアリング センサ R2 衝突回避の有効な手段は進 路を変更することであるため アクセル センサ R1 むやみなスロットル制御は危 険に繋がる可能性があるため Redis では，同一 Key に Score を付与した Member を Score
の値でソートが可能である．Key にはランキング名を設定す る．付与するScore の値は整数を用い，下限を 1，上限を 100 とする．付与する値はセンサID を参照し付与する．Score の 値は，同一センサでのScoreの競合を防ぐために値は一定の 範囲を保持する．Memberにはそれぞれの発生時刻，測定値 を設定する． Key，Score，Member の関係を図 3 に示す． 図3 Key，Score，Member の関係 メッセージ 削除要求 優先度 付与機能 メッセージ 格納機能 メッセージ 送信機能 クラウド サブスク リプション センサID 参照 Key,Score 付与 メッセージ 格納 ランキング ソート 格納通知 メッセージ 先頭参照 要求/応答 優先度 参照 メッセージ 受信機能 メッセージ 配信 メッセージ 送信 車載GW メッセージ 配信 キュー 完了通知 要求/応答 メッセージ 削除 メッセージ 保持機能 メッセージ 格納 Key Score センサID 発生時刻 測定値 Member 1 1 1 1..＊ 1 1..＊ ranking : string センサIDを参照し付与 整数型を用い，値域1~100とする 値は一定の範囲を持つ データの競合を防ぐため格納
3
5.4. 優先度付与構造
Redis は Key に対して Member を Score の値でソートが可
能である．優先度付与構造を図4 に示す． 図4 優先度付与構造
6. プロトタイプの実装
6.1. 前提条件 提案アーキテクチャの設計においての前提条件を示す． (1) 自車のみ走行中で，直進のみをする． (2) 前方に障害物が存在し，衝突の危険性がある． (3) イベントを発生させるセンサは前方距離測定センサ，ブ レーキセンサ，ステアリングセンサ，アクセルセンサの4 つとする． (4) 測定値は整数とし，乱数を用いて決定する． (5) イベントへの優先度は決定済みである． (6) メッセージ配信には Redis の Publish/Subscribe アーキテ クチャを利用する． 6.2. 実装環境 プロトタイプの実装環境を表2 に示す． 表 2 実装環境 階層名 センサ/ デバイス層 エッジ層 クラウド層 ハード ウェア Raspberry Pi 3Model B Raspberry Pi 3 Model B ESPRIMO WD2/W
OS Raspbian 8.0 Raspbian 8.0 Ubuntu 16.04
プロセッサ ARMv7 Processor rev4 ARMv7 Processor rev4 Intel Core i7-6000 メモリ 1GB 1GB 16GB ストレージ 32GB micro SD カード 32GB micro SD カード 1TB HDD
実装言語 Python3.4.2 Python 3.5.3 Python3.6.5
データベース Redis 4.0.10 Redis 4.0.10 Redis 4.0.10
6.3. プロトタイプの構成 プロトタイプを提案アーキテクチャに基づいて実装する． プロトイプの構成を図5 に示す． 図5 プロトタイプの構成 6.4. プロトタイプの実装と実行 プロトタイプではPython を実装言語として用い，通信方法と してRedisのPublish/Subscribeアーキテクチャを利用し，Redis Broker 内では受信層と配信層を分けて負荷分散をする． プロトタイプを実行する上で，プロトタイプの構成に基づきメ ッセージ生成プログラムで生成されるメッセージの配信間隔 を，高負荷時を想定した1msec，2msec，通常負荷時を想定し た10msec，20msec の 4 パターンで配信する．生成されたメッ セージのRedis Broker 内での処理時間を計測し比較検証を する．
7. プロトタイプの適用と実行結果
7.1. プロトタイプの適用事例 プロトタイプを自動ブレーキシステムに適用し，以下の4 項 目の検証をする． (1) メッセージの送受信を確認 (2) メッセージへの優先度付与の確認 (3) メッセージをデータベースに格納し，昇順ソートされて いるかの確認 (4) 優先度の高いメッセージ取得から送信までのリアルタイ ム性の確認 7.2. プロトタイプのシナリオ 本研究におけるプロトタイプの実行シナリオを図6 に示す． 図 6 プロトタイプの振る舞い プロトタイプは車載システムからメッセージ配信間隔を4パターンでRedis Broker へ配信する．また，Redis Broker は
配信されたメッセージの受信と優先度付与をし，優先度が高 いメッセージを優先的にクラウドへ配信する． メッセージ メッセージ メッセージ メッセージ サブスクライバ :distance サブスクライバ :brake サブスクライバ :steering サブスクライバ :accelerator 測定値解析 測定値解析 測定値解析 測定値解析 Key Score 付与 Key Score 付与 Key Score 付与 Key Score 付与 格納 機能 保持 機能 キュー パブリッシャ クラウド → : 発生時刻，測定値 →: 格納通知メッセージ メッセージ生成 プログラム Redis
Publisher BrokerRedis
Redis Subscriber 優先度付与 プログラム Redis Publisher Redis Broker 車載ゲートウェイ Redis Broker クラウド 生成 データ メッセージ 配信 Publish メッセージ メッセージ 配信 メッセージ 優先度付与 メッセージ Publish メッセージ メッセージ格納 データベース (Key : ranking) メッセージ保持 データベース (Key : save) 優先度付与 メッセージ キュー 格納通知 メッセージ 優先度付与メッセージ Redis SubscriberRedis SubscriberRedis SubscriberRedis Subscriber 格納通知 メッセージ 取り 出し メッセージ 削除 優先度付与 プログラム メッセージ格納データ ベース(Key : ranking) Redis Publisher クラウド サブスクリプション Key,Score 付与 メッセージ格納 ランキング ソート 格納通知 メッセージ 取り出し 先頭参照要求 配信メッセージ 削除要求 メッセージ生成 プログラム 生成メッセージ 配信 キュー メッセージ保持データ ベース(Key : save) 格納通知 メッセージ挿入 メッセージ格納 サブスクリプション キュー監視 要求メッセージ 配信 優先度 参照 メッセージ配信
4 7.3. 実行結果 プロトタイプを実行し，4 パターンの間隔で各センサ 500 件 ずつメッセージを配信した時の優先度毎でのRedis Broker 内 の処理時間を計測し比較した．それぞれ3 回計測し，1 回目 をa，2 回目を b，3 回目を c とした．
1msec 時の Redis Broker 内の処理時間のグラフを図7 に示 す． 図7 1msec 間隔メッセージ配信 優先度の高いメッセージ(R4)を 4 パターンの間隔で配信 し，それぞれの1 回目，2 回目，3 回目の Redis Broker 内の 処理時間を比較したグラフを図8 に示す． 図8 高優先度メッセージ配信 Redis Broker 内での平均遅延時間を図 9 に示す． 図 9 平均遅延時間
8. 提案アーキテクチャの評価
(1) メッセージへの優先度付与 センサデータ毎に生成されたメッセージに優先度付 与をすることで，センサ ID が異なるセンサデータに優 先順位を示すことが可能になった．これにより，クラウド が要求するデータを優先的に配信することが可能とな った． (2) メッセージのリアルタイム配信及びメッセージの共有 センサ/デバイス層で発生するイベント間隔を発生デ ータ間隔高負荷時を想定した1msec，2msec，発生デー タ間隔通常負荷時を想定した 10msec，20msec の処理 時間の比較をした結果，優先度の高いメッセージは高 負荷時においても通常負荷時の遅延時間との差が小さ い上で配信でき，データの共有が可能となった．9. 提案アーキテクチャの考察
センサ/デバイス層，エッジ層，クラウド層の各層でメッセー ジ共有が可能となった．また，優先度の高いメッセージはイ ベント発生間隔が高負荷時においても通常負荷時の遅延時 間との差が小さい上で配信可能となった．以上より，重要なイ ベントを優先的にクラウドへ配信する方法として有用である．10. 今後の課題
(1) 異常値の制御 メッセージ処理時間の計測値から異常値が確認され たため，システム要求を満たさない場合がある． (2) サブスクライバの数の増減に対応 Redis Broker へメッセージ配信をする際，センサ ID と サブスクライバが1 対 1 であるため，多種類のセンサに 対応できるように1 つのサブスクライバで対応するセン サ数を改善する必要がある．11. まとめ
本稿では，オープンソースソフトウェアのNoSQL データベ ースであるRedis を用いてクラウド層へメッセージ配信をする アーキテクチャを提案した．提案アーキテクチャでは，優先 度付与をするRedis Broker を設置することで，優先度の高い メッセージを優先的に配信し共有が可能となった．また，優 先度の高いメッセージはリアルタイム配信が可能となった．以 上より，重要なイベントを優先的にクラウドへ配信する方法と して有用である．参考文献
[1] 濱野 真伍，他，IoT システムのためのエッジアーキテク チャ設計方法論の提案と評価，第198 回ソフトウェア工 学研究会，No. 12，Mar. 2018，pp. 1-8． [2] 井ノ口 仁也，他，MQTT を用いた車載エッジコンピュ ーティングアーキテクチャの提案と評価，情報処理学会 第79 回全国大会，Mar. 2017，pp. 229-230． [3] Josiah L. Carlson，Redis 入門 インメモリ KVS による高速 データ管理，株式会社KADOKAWA， 2013． [4] 緒方 研一，他，データベース徹底攻略，技術評論社， 2014[5] W. Shi and S. Dustdar，The Promise of Edge Computing，
IEEE Computer，Vol. 49，No. 5，May 2016，pp. 78-81．
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 1 10 19 28 37 4655 64 73 82 91 100109 118 127 136 145 415163 172 181 190 199 820217 226 235 244 253 262127 280 289 298 307 316532 334 343 352 361 370379 388 397 406 415 424433 244 451 460 469478 487 496 R1_0.001_a R2_0.001_a R3_0.001_a R4_0.001_a R1_0.001_b R2_0.001_b R3_0.001_b R4_0.001_b R1_0.001_c R2_0.001_c R3_0.001_c R4_0.001_c (sec) 0 0.005 0.01 0.015 0.02 1917 2533 414957 657381 8997 105113121 129137 145153161 169177185 193201 209217225 233241249 257265 327281289 297305313 321329 337345353 361369377 538393 401409417 425433144 449457 465473481 489497 R4_0.001_a R4_0.001_b R4_0.001_c R4_0.002_a R4_0.002_b R4_0.002_c R4_0.01_a R4_0.01_b R4_0.01_c R4_0.02_a R4_0.02_b R4_0.02_c R4の中では2msec間隔で配信した際に，遅延時間 が10msecに近づくことが他の配信間隔に比べ多 かった．2msec間隔の3回目の実行においては遅延 時間が20msecに近づくことがあった． (sec) 2,450 504 6.84 3.86 1,090 371 19.1 4.23 2.643.32 2.643.28 2.6 3.24 2.67 3.29 1 10 100 1,000 10,000 R1 R2 R3 R4
1msec間隔 2msec間隔 10msec間隔 20msec間隔 (msec)
