Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
DEIM Forum 2016 F5-1
プル型のセンサー情報収集によるリソースの利用効率最大化
宮澤 慎一† 松永 昌浩†
†セコム株式会社 IS研究所 〒 181–8528東京都三鷹市下連雀 8-10-16セコム SCセンターE-mail: †{s-miyazawa,m-matsunaga}@secom.co.jp
あらまし 企業や家庭に取り付けたセンサーの情報を元にサービスを提供する場合,センサーの情報を収集するサー
バーのデータ受信量や負荷は,社会の活動と連動して大きく変化する.そのような変化に対し,最適なコストで ITリ
ソースを利用する手段としてクラウドが着目されている.一方,パフォーマンスやセキュリティの懸念から,クラウ
ドではなくオンプレミスな環境でサーバーを運用したいという要望もある.そこで本稿では,ITリソースを最適化す
る手法として,クラウドのように ITリソースを伸縮させるのではなく,収集するデータ量を伸縮させる手法を提案す
る.本手法では,サーバーが即座に受信すべきサービスの根幹に関わる情報はセンサーからプッシュする手法を用い,
サービスの質を向上させるために必要な平時の情報は,サーバーがセンサーへデータを問い合わせる手法(プル)を
用いる.このハイブリッドな手法は,ITリソースを最適なコストで利用できるだけでなく,サーバー側とセンサー側
の機器の性能の進化のずれの緩和や,サービスの目的や状況に応じたダイナミックな QoSの変更も可能となる.これ
らの有用性についてサービス事業者の視点から考察する.
キーワード IoT, DMBS, QoS
1. は じ め に
IoT [1] という言葉の登場以来,インターネットを介してセ
ンサーのデータを収集するビジネスが話題になっている.セン
サーからサーバーへデータを送信する手法(プッシュ型)が前
提とされていることが多く,その大量のデータを受信するため
にクラウドを用いることが提案されている [2].一方,パフォー
マンスやセキュリティの懸念 [3]から,クラウドではなくオン
プレミスな環境のサーバーで運用したいという要望も存在する.
たとえば,機械警備業など,企業や家庭の状態の変化に応じ
てサービスを提供するような事業形態では,企業や家庭に設置
されたセンサーが発生させたイベント情報を元にサービスを提
供している(図 1).これらの情報は,オンプレミスな環境の
サーバーで受信し管理されている.
センサーなどの情報
サービス 提供者
お客様
図 1 センサー情報を収集するサービスの例
企業や家庭からのイベント情報は,人間の生活や社会の活動
のリズムと密接に関係しており,サーバーが受信するデータ量
は時間帯によってピークとオフピークが発生することとなる.
イベント発生に対して迅速な対応が求められるので,サーバー
の処理能力はあらかじめピークに合わせて準備する必要がある.
オンプレミスのサーバーでピーク時とオフピーク時のデータ
量に極端に差がある場合,ITリソースの余剰が発生する.余剰
資産を保有することは企業にとって無駄なコストであるため,
余剰資産を有効活用することが課題となる.
そこで本稿では,センサーがサーバー側へデータを送信する
手法(プッシュ型)だけではなくサーバーがセンサーへデータ
を問い合わせる手法(プル型)も用いる,プッシュ型とプル型
を組合せた手法(ハイブリッド型)を提案する.
また,ハイブリッド型データ収集手法がどのようなものなの
か理解しやすくするためのシミュレーターも今回構築したので,
合わせて紹介する.
以降,第 2節では,IoTを利用したサービスでサーバが受信
するデータ量にピークとオフピークが存在する例を説明する.
そして第 3節では,ピークとオフピークが存在しても ITリソー
スを無駄なく使う手段として知られている,クラウドの考え方
を紹介する.第 4節で本稿の提案する,プッシュ型-プル型を組
み合わせたハイブリッド型の手法を提案する.第 5節では,ハ
イブリッド手法を用いると ITリソースを使い切れること以外
の利点があることを説明する.第 6節ではデータ収集の様子を
可視化するシミュレーターを紹介し,最後に第 7節で今後の課
題を述べ,第 8節でまとめる.
2. 受信するデータ量にピークがあるシステム
本節では,受信するデータ量にピークがあるシステムの例と
して,建物に様々なセンサーをとりつけて,建物の状態の変化
や人の出入りを監視するサービスを例としてあげる.
建物の状態の変化や人の出入りは,社会の活動や人々の生活
と密接に結びついており,サービス提供者がセンサーから受信
するデータ量も社会の活動や人々の生活と連動している.
00 24 06 12 18 時刻
データ量
図 2 データ受信量の例
図 2は,上述したようなサービスにおいて,センサーから一
括してデータを受信するサーバーの受信データ量の変化を模擬
的に示したものである.横軸と縦軸はそれぞれ,時刻と単位時
間あたりに受信したデータ量をあらわしている.このグラフか
ら,早朝に受信データ量のピークが生じ,また夕方から夜にか
けてにゆるやかなデータ量増大が見てとれる.また,深夜から
明け方まではデータ量が少ない.
朝と夕方に受信データが増加する理由は,たとえば,建物が
会社や店舗であれば出勤/退社と連動しており,建物が自宅であ
れば出社/帰宅と連動しているといえる.日中が深夜よりもデー
タ量が多い理由は,日中のほうが社会の活動が活発になるため
である.このような傾向は,24時間単位,一週間単位,月単位,
などでパターンになる.
センサーからのイベント情報は,サービスを提供するために
迅速に把握して対応する必要があるため,ITリソースの能力は
ピーク時に必要な能力を事前に見積もり,準備することとなる.
このようなシステムでは,ピーク時とオフピーク時のデータ量
に極端に差がある場合,ITリソースの余剰が発生する.余剰資
産を保有することは企業にとって無駄なコストであるため,余
剰資産を有効活用することが課題となる.
3. ITリソースを無駄なく手段としてのクラウド
ITリソースを無駄なく使う手段として,クラウドが騒がれは
じめて以来,二つの選択肢が議論されることが多い [4].それは
クラウド事業者になるかクラウド消費者になるかである.
3. 1 クラウド事業者になる選択肢
クラウド事業者になる選択肢とは,オフピーク時の ITリソー
スを第三者に提供するというものである(図 3).
このようなビジネスの先駆けは,Amazon Web Service であ
る.よく話題になるのは,感謝祭直後のクリスマス商戦(サイ
バーマンデー)時のアクセス数とオフピーク時の差である.11
月にはひと月に 76パーセントの空リソースが発生していると
いう [5].
2014年の時点で,AWSではデータセンター 1つあたり最低
でも 5万台存在するという [6].つまり,単純計算で 11月には
データセンター 1つあたり 3.8万台分のリソースが無駄になる
ということである.このような事情から,ITリソースの余剰分
を外販する必要が出てくるのも無理はない.しかし,アマゾン
00 24 06 12 18 時刻
データ量
販売 販売
図 3 クラウド事業者の発想
のような,売るほど余剰サーバーがあるという大規模なサービ
スは非常に稀であり,クラウド事業者になるということは稀で
ある.
3. 2 クラウド消費者になる選択肢
クラウド消費者になる選択肢とは,先に述べたクラウド事業
者の提供する ITリソースを購入するというものである.この
選択肢では,必要な時間帯に必要な分だけ ITリソースをクラ
ウド事業者から購入する(図 4).
00 24 06 12 18 時刻
データ量
図 4 クラウド消費者の発想
これにより,サービスに必要な IT リソースを最適化するこ
とができる.その一方で,サービス提供者がサービスに利用す
る場合は,顧客に対してサービス提供者自身の信用だけでなく
クラウド事業者の信用も担保する必要が生じる.
3. 3 プライベートクラウド
オンプレミスな環境に複数台のサーバーを準備して,その上
で ITリソースを管理するプライベートクラウドがある.また,
Xen, KVM, VMWareなどにより仮想 PCを管理するもの [7]も
あれば,Mesos [8]や Kubernetes [9]などを利用することによっ
て,複数台のサーバーで構築された分散環境をあたかも一つの
マシンのようにコントロールする手段も登場している.
一台のサーバーの処理能力を越えるデータ量をさばく必要の
あるサービス提供者にとっては,これらの技術は必要な技術で
ある.本稿では,このような環境を活用する方法について述べ
ている.
4. ハイブリッド型データ収集
本節では,サービス提供者の観点から発想した,センサー側
常時取得データ (傾向分析の元ネタ。サービス向上に利用)
例: 温度、振動、日照、脈
常時取得データ (傾向分析の元ネタとなる) (サービス向上に利用) 例: 温度、振動、日照、脈
データ量
時刻
0時 24時 12時
データ量
時刻
0時 24時 12時
データ量
時刻
0時 24時 12時
(a) (b) (c)
図 5 データの収集タイミングを変化させる
からサーバー側へデータをプッシュする方式と,サーバー側か
らクライアント側のデータをプルする手法を組み合わせたハイ
ブリッド型のデータ収集手法を提案する.
4. 1 イベント発生時の情報を扱ってきた過去
従来,機械警備業など,企業や家庭にセンサーを取り付けそ
のセンサーの情報を元にサービスを提供するような事業形態で
は,顧客とサービス提供者との間を取り持つ通信網としてイン
ターネットよりも制約のある,電話や FAXに利用する一般公
衆回線を使用してきた.
一般公衆回線における制約(例:通信のたびに発生する通信
料,通信帯域/レイテンシー/通信データ量などの制約など)の
もとで,リアルタイムな最適のサービスを提供するために,顧
客の建物に設置したセンサーやアクチュエーター(電子錠など)
とそのコントローラーでできる限りの処理を実行し,サービス
提供者に伝えなければならない必要なデータのみを,サーバー
へプッシュしてきた(図 5(a))(注1).
4. 2 平時の情報を扱う未来
インターネットが普及して以来,通信インフラの通信遅延,
通信帯域,通信データ量が一般公衆回線よりも飛躍的に向上
し,通信料も定額となっていった.このため,前述したような
形態のサービス提供者も,一般公衆回線からインターネットへ
切り替えてきている.通信インフラが一般公衆回線だった時は,
サービスに必要なイベント情報を受信していたが,今後はイン
ターネット回線の優位性を利用して,イベント発生時ではなく
平時のデータを常に取得し,サービスを向上させることが鍵と
なっている.
たとえば,温度,振動,日照,脈などを常時取得して,お客
様の状態などの傾向を分析し,サービス向上やリスクの未然防
止に利用することができると考えられる.このようなデータも
サーバーへプッシュする方法で収集する場合,図 5(b)のように
受信するデータがかさ上げされることになる.
4. 3 ハイブリッド型データ収集
ところで,このような傾向分析に必要なデータは緊急性は高
くなく,即時にサーバーが受信できなくとも 1日単位でデータ
を取得できれば良いことが多い.また,近年では,組み込み機
器やモバイル端末にもデータベースを実装することが可能に
なっており,即座に必要ないデータを貯めておくことが可能に
(注1):近年,このようなアーキテクチャはエッジ・ヘビー・データ [10] という
言葉により再注目されている.
なっている [11].
そこで,サーバーのリソースに余剰が出たときに,サーバー
側のタイミングでデータを取得する手法を本稿では提案する.
これまで通り,緊急性の高い情報はサーバー側で遅滞なく受信
して処理する一方で,IT リソースに余剰がある際は,平時の
データを収集するというものである(図 6).
緊急性の高い情報は、 今まで通り、 即時に受け付ける。
平時のデータは、 ITリソースが暇なとき サーバーが収集する
全体としてコンピュータの リソースを使い切り続ける
サービス 提供者
サービス 提供者
図 6 緊急時と平時のデータを別々に受信
刻々と変化するサーバーの ITリソースの余剰分に合わせて,
データ収集スケジュールを生成し,決められた単位時間以内
(deadline) で全クライアントからデータを収集できるようにダ
イナミックにデータの QoSを変更するというものである.
この手法により,図 5(c)のようにピーク時性能に合わせたコ
ンピューターリソースを,有効に活用できることができるので
はないかと考えた.
4. 4 プル型が適用できるシステムの特徴
サーバー側からクライアント側の情報をプルしてデータを収
集するシステムの特徴は,そのシステムで実施するサービスの
観点から,以下に説明する 2つの特徴が上げられる.
一つ目は,センサーの情報を使って 365日 24時間サービス
をするという特徴である.これらのクライアント側も 365日 24
時間通電された状態である.このため,サーバー側からクライ
アント側へアクセスすることを前提条件として考えることがで
きる.
二つ目は,センサーの情報を使ってサービスを提供する場合,
サーバーだけでなくクライアント側の機器やアプリケーション
もサービス提供者のものであることが多いことである.このと
き,一般的なWebアプリケーションの場合と異なり,サーバー
とクライアントが協調したシステムとなることができ,通信を
セキュアにしたり通信内容をサーバー側クライアント側双方の
都合で変更することができる.(図 7).
Webのサーバーは、不特定多数の コンピュータ(クライアント)から一方的に アクセスされることが多い。
IoTのシステムにおいてサーバーと クライアントは既知の関係であり、サーバーは クライアントを制御可能であることが多い。
図 7 サービス提供者のサーバーにとってクライアントは既知
5. ITリソースの有効活用以外の利点
本稿で提案するハイブリッド手法によるメリットは,IT リ
ソースの余剰を有効に使い切ることだけがメリットではない.
本節では,サーバー側がクライアント側のデータを収集すると
きにサーバー側の都合で QoS を変更できるメリットと,アド
ホックな情報収集ができるメリットを説明する.
5. 1 サーバーとクライアントの進化のずれを緩和する
近年,低価格帯の組み込み機器においても,その性能は格段
に向上してきている.これらをセンサーの情報を収集するクラ
イアント側として使い,その能力を使い切ってデータを取得す
ると,ミリ秒オーダーの非常に細かい粒度のデータを取得する
ことができる.そのデータをクライアントからサーバーへ送信
すると,クライアント数が膨大な場合はサーバー側に求められ
る能力が甚大となってしまう.このため,クライアント側で統
計処理など事前に処理して送信するデータ量を調節する必要が
ある(図 8の 2015年の例).
2015年 2025年 100ms 100ms 100ms 100ms 100ms 100ms
1Gbps 100Gbps
10s間隔 100ms間隔
サービス 提供者
サービス 提供者
図 8 サーバー側の都合でデータの QoS を変更する
ところで,企業や家庭に設置するような設備は,何年も交換
せずに使用することが多い.その理由は,クライアントの機器
の性能が十分であること,クライアントの機器が方々に点在す
ること,一度設置すると変更工事が難しいことなどである.一
方,サーバー側は,ネットワーク帯域や処理能力などを徐々に
向上させることができ,クライアント側の全体の能力に,後か
ら徐々に追い付くことが可能である(図 8の 2025年の例).
このとき,クライアント側とサーバー側との通信の頻度や
データの精度(データ量)を変更する方法として,2つ考えら
れる.もし,クライアント側からデータをプッシュするアーキ
テクチャであれば,クライアント側のアプリケーションやパラ
メータを遠隔から更新する方法が考えられる.もう一つは,本
稿で提案しているサーバー側からクライアント側のデータを問
い合わせるプル型のアーキテクチャも準備しておき,サーバー
側で問い合わせのタイミングや内容を随時変更する方法が考え
られる.
以降で説明するが,本稿では,データ収集のタイミングや
データの精度など,データ収集戦略の変更をよりダイナミック
により柔軟にできる方法は,クライアント側のアプリケーショ
ンやパラメータを遠隔から更新する方法よりも,サーバー側で
問い合わせのタイミングや内容を随時変更する方法だと考えた.
5. 2 アドホックな情報収集
災害発生時などでは,あるエリアの最新の状態を頻繁に取得
したいということが発生する.このようなとき,イベント発生
時にデータを上げるだけの仕組みだと,任意のタイミングで任
意の精度のデータを収集することは難しい.しかし,サーバー
から情報を収集する仕組みになっていれば,任意の場所の情報
を任意のタイミングで取得することができる(図 9).
【災害時など】 ○○県××村の 物件の現状を今すぐ収集したい!
○○県××村
サービス 提供者
図 9 場所を指定して取得することができる
5. 3 状況や目的に応じた QoS前述したようなアドホックな情報収集をしたとしても,その
負荷によってサーバーがクライアントからデータを取得できな
くなるということがあってはならない.このため,状況に応じ
て QoSをダイナミックに変化させる機構は重要である.
また,この手法によって,用途ごとに必要な QoS の基準で
データを収集することができる.常時取得データを統計分析の
ためだけに使うなら,サーバーがクライアント側のデータを全
て取得する必要はなく,クライアント側で統計処理を実施した
状態でサーバーが収集しても問題ない.一方,証跡として平時
のデータを残す必要がある場合,できるだけ粒度の細かい状態
で平時のデータを保管しておくことが望ましくなる.
6. シミュレーター
6. 1 概 観
本稿で提案した「データを受信しつつオフピーク時にデータ
を回収する手法」を理解しやすくするために,シミュレーター
を構築して可視化した(図 10).
可視化に際して,サーバーを空中に浮かぶ球として表現し,
クライアントを日本地図上に配置された透明の点として表現し
た.クライアントからサーバーに対してデータを送信すると,
データを表す点がクライアントの座標からサーバーに向けて移
図 10 シミュレーション可視化の概観
動する.その点の色は,データがイベントデータの場合には赤
く,平時のデータの場合には黄色い.
また,平時のデータをサーバーからクライアントに対して問
い合わせることもできる.サーバーからクライアントへの問い
合わせを,サーバーからクライアントの座標に対して伸縮する
緑の直線によって表現した.
なお,右上にはシミュレーション上での時刻を表示した.
6. 2 シミュレータのアーキテクチャ
シミュレーターは,可視化ツール部とシミュレーター部の 2
つに分けて構築した(図 11).
WebServer
WebSocket
クライアント (物件シミュレータ)
・・・ ・・・ 4万
UDP
受信プロセス
スケジューラー
収集プロセス
サーバー
シミュレーター 可視化ツール
Webブラウザ (WebGL)
図 11 シミュレーターのアーキテクチャ概要
可視化ツール部は,Go [12]で書かれたWebサーバとWebブ
ラウザで構成される.WebブラウザはWebGL [13]に対応して
いれば,どの Web ブラウザでも問題ない.Web サーバーは,
シミュレーターから UDPで描画メッセージを受信し,それを
Websocket [14]経由でWebブラウザに表示している.
シミュレーター部では,各クライアントとサーバーを Er-
lang [15]のプロセスで実装しており並行に動作している.図中
の青い四角形はクライアントをあらわしており,各クライアン
トは 24秒間に一度サーバーに対してイベントデータを送信し
ている.送信するタイミングは,各クライアントにあらかじめ
割り当てられた確率分布を元に,24秒おきに各クライアント内
部で決定される.
シミュレーターのサーバーは 3 つの Erlang プロセスで実装
されいる.一つは受信プロセスである.受信プロセスは,クラ
イアントから随時信号を受信しつづける.スケジューラープロ
セスは受信プロセスのデータ受信状況を定期的に観測し,スケ
ジュールを決定し,24 秒ごとに収集プロセスにスケジュール
を転送する.スケジューラープロセスは,転送されてきたスケ
ジュールを元にクライアントから情報を収集する.
クライアントもサーバーも,描画が必要な処理の内部で,描
画メッセージを UDPで可視化ツールのWebサーバに送信して
いる.
6. 3 スケジューリング方法
今回構築したシミュレーターのサーバーは,24秒間に受信し
たイベントデータの受信パターンから,翌日の平時のデータ収
集スケジュールを決定している.ここでは,サーバー側がどの
ように収集スケジュールを決定しているかを説明する.
サーバーは 24秒ごとに過去 24秒間でどの程度イベントデー
タを取得したのかをヒストグラムとして算出する(図 12-a).
そのヒストグラムから,ピーク時の負荷を求めて,平時のデー
タに使える IT リソースを算出する(図 12-b).そのデータを
元に,翌日の収集する際のヒストグラムを求めて,収集スケ
ジュールとしている(図 12-c,d).
今回は deadline を守るために QoS を変化させる手法は検討
しなかったが,たとえば,統計的な手法を用いて deadlineまで
に情報を収集する方法 [16], [17]や,ウェブクローリングのスケ
ジューリングアルゴリズム [18]の研究が役に立つ可能性がある.
データ量
時刻
0時 24時 12時
データ量
時刻
0時 24時 12時
データ量
時刻
0時 24時 12時
データ量
時刻
0時 24時 12時
(a) (b)
(c) (d)
図 12 スケジューリングの手法
6. 4 評 価
サーバーのデータ受信状況がデータ収集手法によってどのよ
うに変化するのか,シミュレーターを用いて 3とおりのシナリ
オで評価した.共通の条件とシナリオは以下のとおりである.
シナリオ共通条件
• 1日を 24時間ではなく 24秒とする
• クライアント数:40000
• サーバー数:1
• クライアントは,24 秒に 1 回,イベントデータをサー
バーへ送信
• クライアントのイベントデータの発生時刻は,ラプラス
分布とガウス分布に従う.
– ラプラス分布:µ = 8, σ = 0.5
– ガウス分布:µ = 18, σ = 2.0
– 分布生成にノイズは入れない
シナリオ (a):イベントデータが即時に送信される場合
0
1000
2000
3000
40000
:11
2:0
7
4:0
3
5:5
9
7:5
5
9:5
1
11
:47
13
:43
15
:39
17
:36
19
:32
21
:28
23
:23
0
1000
2000
3000
4000
0:1
4
2:0
9
4:0
5
6:0
1
7:5
6
9:5
2
11
:48
13
:43
15
:39
17
:35
19
:31
21
:28
23
:23
0
1000
2000
3000
4000
0:1
0
2:0
6
4:0
2
5:5
8
7:5
4
9:5
0
11
:46
13
:42
15
:38
17
:33
19
:30
21
:25
23
:21
(a) (b) (c)
サーバーの受信信号数
時刻
イベントデータ
平時データ
図 13 スケジューリングの有無の比較
• クライアントは,イベントデータのみ送信する.平時の
データは発生しない.
シナリオ (b):イベントデータと平時のデータが即時に送信される場合
• クライアントは,24秒に 12回,平時のデータをサーバー
へ送信
• クライアントの平時のデータの送信時刻は,一様分布に
従う.
シナリオ (c):イベントデータは即時に送信される一方で,平時のデータはクライアントに蓄積され,サーバーからの問い合
わせに応答する場合
• サーバーは,平時のデータを 24秒以内に全クライアン
トから 12回ずつ収集
• 翌日の収集スケジュールは 24秒経過時点で再作成
図 13のグラフはそれぞれ,上記シナリオでのサーバーのデー
タ受信回数を示している.イベントデータも平時のデータも即
時に送信する場合は,サーバーの信号受信量のピークが 4000弱
になっている.その一方で,サーバーからクライアントへ問い
合わせをする場合は,ピークが約半分の 2000強で済んでいる.
7. 今後の課題
本稿では,クライアントの情報を収集するスケジューリング
の戦略として 24秒(時間)単位のものをシミュレーションで利
用した.実際には時間のパターン,曜日によるパターン,年間
を通じたパターンにあわせたスケジューリングや,パターンで
はなく分単位などより細かい粒度でダイナミックにスケジュー
リングを実施する機構が必要である.このようなスケジューリ
ングは,スマートグリッドの電力需要予測の研究 [19]などが参
考になると考えている.
また,サービスを向上させるために必要な平時の情報を実際
に取得するには,本稿で上げた課題以外にも,プライバシーに
ついての課題がある.どの情報を顧客からプルしても問題ない
のか,プルしてきたデータをサーバーでどのように扱うかとい
う課題である.
8. ま と め
本稿では,時間帯によって負荷が大きく変動するような,セ
ンサー情報を収集するサーバーの ITリソースの余剰分を有効
活用する手法を提案した.
企業や家庭にセンサーなどを設置して,そのデータによって
サービスを提供する事業者には,即時に受信し処理することが
必要な情報(サービスの根幹に関わる情報)と,統計情報など
で必要な情報(サービスを向上させるために必要な平時の情報)
とがある.本稿で紹介した手法は,これらの情報の特性を踏ま
えて,サービスの根幹に関わる情報に合わせて,ITリソースの
ピーク時性能を見積り,余剰分はサービスを向上させるために
必要な平時の情報の処理に利用するというものである.
この手法は,IT リソースの余剰分を有効利用できるだけな
く,サーバーとクライアントの性能の進化のずれを緩和したり,
アドホックにサーバー側の都合でクライアント側の情報を取得
できるようになったり,状況や目的に応じて QoSをダイナミッ
クに変更させることができる.
また,このような手法を理解しやすくするために,シミュー
レションし可視化するアプリケーションを構築した.
文 献[1] Kevin Ashton. That ‘internet of things’ thing. RFiD Journal, Vol. 22,
No. 7, pp. 97–114, 2009.[2] Jayavardhana Gubbi, Rajkumar Buyya, Slaven Marusic, and
Marimuthu Palaniswami. Internet of things (iot): A vision, architec-tural elements, and future directions. Future Generation ComputerSystems, Vol. 29, No. 7, pp. 1645–1660, 2013.
[3] Subashini Subashini and V Kavitha. A survey on security issues inservice delivery models of cloud computing. Journal of network andcomputer applications, Vol. 34, No. 1, pp. 1–11, 2011.
[4] Michael Armbrust, Armando Fox, Rean Griffith, Anthony D Joseph,Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, ArielRabkin, Ion Stoica, et al. A view of cloud computing. Communica-tions of the ACM, Vol. 53, No. 4, pp. 50–58, 2010.
[5] Simon Elisha. Scaling on aws for the first 10 million users, Nov.2013. http://www.slideshare.net/AmazonWebServices/
scaling-on-aws-for-the-first-10-million-users-arc206-
aws-reinvent-2013.[6] James Hamillton. Aws innovation at scale, Nov. 2014. http://www.
slideshare.net/AmazonWebServices/spot301-aws-innovation-
at-scale-aws-reinvent-2014.[7] Borja Sotomayor, Ruben S Montero, Ignacio M Llorente, and Ian
Foster. Virtual infrastructure management in private and hybridclouds. Internet computing, IEEE, Vol. 13, No. 5, pp. 14–22, 2009.
[8] Benjamin Hindman, Andy Konwinski, Matei Zaharia, Ali Ghodsi,Anthony D Joseph, Randy H Katz, Scott Shenker, and Ion Stoica.Mesos: A platform for fine-grained resource sharing in the data cen-ter. In NSDI, Vol. 11, pp. 22–22, 2011.
[9] Kubernetes, Aug. 2014. http://kubernetes.io.[10] 丸山宏. エッジ・ヘビー・データとそのアーキテクチャ. 情報管
理, Vol. 56, No. 5, pp. 269–275, 2013.
[11] Anil Nori. Mobile and embedded databases. In Proceedings of the2007 ACM SIGMOD international conference on Management ofdata, pp. 1175–1177. ACM, 2007.
[12] The go programming language. https://golang.org/.[13] Chris Marrin. Webgl specification. Khronos WebGL Working Group,
2011.[14] Ian Fette and Alexey Melnikov. The websocket protocol. 2011.[15] Joe Armstrong, Robert Virding, Claes Wikstrom, and Mike Williams.
Concurrent programming in erlang. 1993.[16] Susan V Vrbsky and Jane WS Liu. Approximate — a query pro-
cessor that produces monotonically improving approximate answers.Knowledge and Data Engineering, IEEE Transactions on, Vol. 5,No. 6, pp. 1056–1068, 1993.
[17] Sameer Agarwal, Barzan Mozafari, Aurojit Panda, Henry Milner,Samuel Madden, and Ion Stoica. Blinkdb: queries with boundederrors and bounded response times on very large data. In Proceed-ings of the 8th ACM European Conference on Computer Systems, pp.29–42. ACM, 2013.
[18] Carlos Castillo. Effective web crawling. In ACM SIGIR Forum,Vol. 39, pp. 55–56. ACM, 2005.
[19] Piotr Mirowski, Sining Chen, Tin Kam Ho, and Chun-Nam Yu. De-mand Forecasting In Smart Grids. Bell Labs Technical Journal,Vol. 18, No. 4, pp. 135–158, 2014.