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 06 12 18 24 時刻 データ量 図 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 06 12 18 24 時刻 データ量
販売
販売
図 3 クラウド事業者の発想 のような，売るほど余剰サーバーがあるという大規模なサービ スは非常に稀であり，クラウド事業者になるということは稀で ある． 3. 2 クラウド消費者になる選択肢 クラウド消費者になる選択肢とは，先に述べたクラウド事業 者の提供するITリソースを購入するというものである．この 選択肢では，必要な時間帯に必要な分だけITリソースをクラ ウド事業者から購入する（図4）． 00 06 12 18 24 時刻 データ量 図 4 クラウド消費者の発想 これにより，サービスに必要なITリソースを最適化するこ とができる．その一方で，サービス提供者がサービスに利用す る場合は，顧客に対してサービス提供者自身の信用だけでなく クラウド事業者の信用も担保する必要が生じる． 3. 3 プライベートクラウド オンプレミスな環境に複数台のサーバーを準備して，その上 でITリソースを管理するプライベートクラウドがある．また， Xen, KVM, VMWareなどにより仮想PCを管理するもの[7]も あれば，Mesos [8]やKubernetes [9]などを利用することによっ て，複数台のサーバーで構築された分散環境をあたかも一つの マシンのようにコントロールする手段も登場している． 一台のサーバーの処理能力を越えるデータ量をさばく必要の あるサービス提供者にとっては，これらの技術は必要な技術で ある．本稿では，このような環境を活用する方法について述べ ている．4.
ハイブリッド型データ収集
本節では，サービス提供者の観点から発想した，センサー側常時取得データ （傾向分析の元ネタ。サービス向上に利用） 例： 温度、振動、日照、脈 常時取得データ （傾向分析の元ネタとなる） （サービス向上に利用） 例： 温度、振動、日照、脈 データ量 時刻 0時 12時 24時 データ量 時刻 0時 12時 24時 データ量 時刻 0時 12時 24時 (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時 12時 24時 データ量 時刻 0時 12時 24時 データ量 時刻 0時 12時 24時 データ量 時刻 0時 12時 24時 (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 4000 0: 11 2: 07 4: 03 5: 59 7: 55 9: 51 11 :4 7 13 :4 3 15 :3 9 17 :3 6 19 :3 2 21 :2 8 23 :2 3 0 1000 2000 3000 4000 0: 14 2: 09 4: 05 6: 01 7: 56 9: 52 11 :4 8 13 :4 3 15 :3 9 17 :3 5 19 :3 1 21 :2 8 23 :2 3 0 1000 2000 3000 4000 0: 10 2: 06 4: 02 5: 58 7: 54 9: 50 11 :4 6 13 :4 2 15 :3 8 17 :3 3 19 :3 0 21 :2 5 23 :2 1 (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 Computer
Systems, Vol. 29, No. 7, pp. 1645–1660, 2013.
[3] Subashini Subashini and V Kavitha. A survey on security issues in service delivery models of cloud computing. Journal of network and
computer 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, Ariel Rabkin, 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, Rub´en S Montero, Ignacio M Llorente, and Ian Foster. Virtual infrastructure management in private and hybrid clouds. 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] 丸山宏. エッジ・ヘビー・データとそのアーキテクチャ. 情報管
[11] Anil Nori. Mobile and embedded databases. In Proceedings of the
2007 ACM SIGMOD international conference on Management of data, 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 Wikstr¨om, 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 bounded errors 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,
