1
データ遅延に着目したエッジコンピューティングアーキテクチャの
提案と評価
2015SE029 伊藤 亮太 2015SE037 河合 直也 2015SE075 高橋 哲也 指導教員 青山 幹雄
1. 研究背景と目的
IoT が社会に浸透しつつある．しかし，常に最新のデータ を必要とするシステムでは，データ発生順で送信すると重要 なデータの処理に遅延が発生するケースがある．そのため， 重要なイベントには優先的にクラウドへ配信する方法が必要 である．本研究ではエッジコンピューティングアーキテクチャ と NoSQL データベースを用いた方法を提案する．2. 研究課題
本研究課題を以下に示す． (1) センサ/デバイス層からエッジ層へ配信されたメッセー ジに優先度を付与し，それに従う順位付け方法の提案． (2) 優先順位に従って高優先イベントをクラウド層へ優先的 に配信するアーキテクチャの設計方法の提案． (3) 提案アーキテクチャが高負荷時においてもリアルタイム 配信が可能かプロトタイプを用いて検証．3. 関連研究
3.1. エッジコンピューティングアーキテクチャ エッジコンピューティングアーキテクチャは，センサ/デバイ ス層，エッジ層，クラウド層の 3 層から構成される[4]． 3.2. Publish/Subscribe アーキテクチャ Publish/Subscribe アーキテクチャとは，パブリッシャ，サブ スクライバ，ブローカから構成される非同期メッセージ配信ア ーキテクチャである．空間と時間の点から分離が可能であり， システムの拡張が可能である[3]． 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 3 Model B Raspberry Pi 3 Model B ESPRIMO WD2/WOS 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 Redis Broker Redis Subscriber 優先度付与 プログラム Redis Publisher Redis Broker 車載ゲートウェイ Redis Broker クラウド 生成 データ メッセージ 配信 Publish メッセージ メッセージ 配信 メッセージ 優先度付与 メッセージ Publish メッセージ メッセージ格納 データベース (Key : ranking) メッセージ保持 データベース (Key : save) 優先度付与 メッセージ キュー 格納通知 メッセージ 優先度付与メッセージ Redis Subscriber Redis Subscriber Redis 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 に示す． 高優先度メッセージ(以降 R4)は低遅延で配信された． 図 7 1msec 間隔メッセージ配信 R4 を 4 パターンの間隔で配信し，それぞれの 1 回目，2 回目，3 回目の Redis Broker 内の処理時間を比較したグラフ を図 8 に示す． 図 8 高優先度メッセージ配信 Redis Broker 内での平均遅延時間を図 9 に示す． R4 の遅延時間は高負荷時でも通常負荷時から増大しな いことがわかった． 図 9 平均遅延時間
8. 提案アーキテクチャの評価
(1) メッセージへの優先度付与 センサ毎生成されたメッセージに優先度付与をする ことで，センサ ID が異なるデータに優先順位を示すこ とが可能になった．これにより，クラウドが要求するデー タを優先的に配信することが可能となった． (2) メッセージのリアルタイム配信及びメッセージの共有 センサ/デバイス層で発生するイベント間隔は発生デ ータ間隔高負荷時を想定した 1msec と 2msec，発生デ ータ間隔通常負荷時を想定した 10msec と 20msec とし， 処理時間の比較をした結果，図 9 で示すように優先度 の高いメッセージは高負荷時でも通常負荷時から遅延 時間が増大せず，リアルタイム性の保証が確認できた．9. 提案アーキテクチャの考察
センサ/デバイス層，エッジ層，クラウド層の各層でメッセー ジ共有が可能となった．また，優先度の高いメッセージはイ ベント発生間隔が高負荷時でも通常負荷時から遅延時間が 増大しなかった． 以上より，重要なイベントを優先的にクラウドへ配信する方 法として有用である．10. 今後の課題
(1) 異常値の制御 メッセージ処理時間の計測値から異常値が確認され たため，システム要求を満たさない場合がある． (2) サブスクライバの数の増減に対応 Redis Broker へメッセージ配信をする際，センサ ID と サブスクライバが 1 対 1 であるため，多種類のセンサに 対応できるように 1 つのサブスクライバで対応するセン サ数を改善する必要がある．11. まとめ
本稿では，オープンソースソフトウェアの NoSQL データベ ースである Redis を用いてクラウド層へメッセージ配信をする アーキテクチャを提案した．提案アーキテクチャでは，優先 度付与をする Redis Broker を設置することで，優先度の高い メッセージを優先的に配信し共有が可能となった．さらに，優 先度の高いメッセージはリアルタイム配信が可能となった． 以上より，重要なイベントを優先的にクラウドへ配信する方 法として有用である．参考文献
[1] J. L. Carlson，Redis 入門 インメモリ KVS による高速デ ータ管理，KADOKAWA， 2013． [2] 濱野 真伍，他，IoT システムのためのエッジアーキテク チャ設計方法論の提案と評価，第198 回ソフトウェア工 学研究会，No. 12，Mar. 2018，pp. 1-8． [3] 井ノ口 仁也，他，MQTT を用いた車載エッジコンピュ ーティングアーキテクチャの提案と評価，情報処理学会 第79 回全国大会，Mar. 2017，pp. 229-230． [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 1928 37 4655 64 7382 91 10 0 10 9 11 8 12 7 13 6 14 5 15 4 16 3 17 2 18 1 19 0 19 9 20 8 21 7 22 6 23 5 24 4 25 3 26 2 27 1 28 0 28 9 29 8 30 7 31 6 32 5 33 4 34 3 35 2 36 1 37 0 37 9 38 8 39 7 40 6 41 5 42 4 43 3 44 2 45 1 46 0 46 9 47 8 48 7 49 6
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 2533414957 6573818997105 113121129137145153 161169177185193 201209217225233241 249257265327281 289297305313321329 337345353361369 377538393401409417 425433144449457465 473481489497 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間隔
