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] という言葉の登場以来，インターネットを介してセ量に極端に差がある場合，IT リソースの余剰が発生する．余剰ンサーのデータを収集するビジネスが話題になっている．セン

資産を保有することは企業にとって無駄なコストであるため，サーからサーバーへデータを送信する手法（プッシュ型）が前

余剰資産を有効活用することが課題となる．

提とされていることが多く，その大量のデータを受信するため

そこで本稿では，センサーがサーバー側へデータを送信するにクラウドを用いることが提案されている [2]．一方，パフォー

手法（プッシュ型）だけではなくサーバーがセンサーへデータ

マンスやセキュリティの懸念 [3] から，クラウドではなくオンを問い合わせる手法（プル型）も用いる，プッシュ型とプル型プレミスな環境のサーバーで運用したいという要望も存在する．

を組合せた手法（ハイブリッド型）を提案する．

たとえば，機械警備業など，企業や家庭の状態の変化に応じまた，ハイブリッド型データ収集手法がどのようなものなのてサービスを提供するような事業形態では，企業や家庭に設置か理解しやすくするためのシミュレーターも今回構築したので，されたセンサーが発生させたイベント情報を元にサービスを提合わせて紹介する．

供している（図 1）．これらの情報は，オンプレミスな環境のサーバーで受信し管理されている．

以降，第 2 節では，IoT を利用したサービスでサーバが受信するデータ量にピークとオフピークが存在する例を説明する．
そして第 3 節では，ピークとオフピークが存在しても IT リソー

サービス提供者

スを無駄なく使う手段として知られている，クラウドの考え方を紹介する．第 4 節で本稿の提案する，プッシュ型-プル型を組み合わせたハイブリッド型の手法を提案する．第 5 節では，ハセンサーなどの情報イブリッド手法を用いると IT リソースを使い切れること以外の利点があることを説明する．第 6 節ではデータ収集の様子を可視化するシミュレーターを紹介し，最後に第 7 節で今後の課題を述べ，第 8 節でまとめる．
お客様図 1 センサー情報を収集するサービスの例

2. 受信するデータ量にピークがあるシステム
本節では，受信するデータ量にピークがあるシステムの例として，建物に様々なセンサーをとりつけて，建物の状態の変化

企業や家庭からのイベント情報は，人間の生活や社会の活動や人の出入りを監視するサービスを例としてあげる．のリズムと密接に関係しており，サーバーが受信するデータ量

建物の状態の変化や人の出入りは，社会の活動や人々の生活は時間帯によってピークとオフピークが発生することとなる．と密接に結びついており，サービス提供者がセンサーから受信イベント発生に対して迅速な対応が求められるので，サーバーするデータ量も社会の活動や人々の生活と連動している．

データ量

データ量

販売0006121824

時刻00

販売06121824

時刻図 2 データ受信量の例

図 3 クラウド事業者の発想

図 2 は，上述したようなサービスにおいて，センサーから一のような，売るほど余剰サーバーがあるという大規模なサービ括してデータを受信するサーバーの受信データ量の変化を模擬

スは非常に稀であり，クラウド事業者になるということは稀で的に示したものである．横軸と縦軸はそれぞれ，時刻と単位時ある．

間あたりに受信したデータ量をあらわしている．このグラフか

3. 2 クラウド消費者になる選択肢

ら，早朝に受信データ量のピークが生じ，また夕方から夜にかクラウド消費者になる選択肢とは，先に述べたクラウド事業けてにゆるやかなデータ量増大が見てとれる．また，深夜から者の提供する IT リソースを購入するというものである．この明け方まではデータ量が少ない．

選択肢では，必要な時間帯に必要な分だけ IT リソースをクラ

朝と夕方に受信データが増加する理由は，たとえば，建物が会社や店舗であれば出勤/退社と連動しており，建物が自宅であれば出社/帰宅と連動しているといえる．日中が深夜よりもデー

ウド事業者から購入する（図 4）．
データ量

タ量が多い理由は，日中のほうが社会の活動が活発になるためである．このような傾向は，24 時間単位，一週間単位，月単位，などでパターンになる．
センサーからのイベント情報は，サービスを提供するために迅速に把握して対応する必要があるため，IT リソースの能力はピーク時に必要な能力を事前に見積もり，準備することとなる．
このようなシステムでは，ピーク時とオフピーク時のデータ量に極端に差がある場合，IT リソースの余剰が発生する．余剰資00

産を保有することは企業にとって無駄なコストであるため，余06

1218

24時刻

図 4 クラウド消費者の発想

剰資産を有効活用することが課題となる．

3. IT リソースを無駄なく手段としてのクラウド
IT リソースを無駄なく使う手段として，クラウドが騒がれはじめて以来，二つの選択肢が議論されることが多い [4]．それはクラウド事業者になるかクラウド消費者になるかである．

3. 1 クラウド事業者になる選択肢
クラウド事業者になる選択肢とは，オフピーク時の IT リソースを第三者に提供するというものである（図 3）．

これにより，サービスに必要な IT リソースを最適化することができる．その一方で，サービス提供者がサービスに利用する場合は，顧客に対してサービス提供者自身の信用だけでなくクラウド事業者の信用も担保する必要が生じる．

3. 3 プライベートクラウド
オンプレミスな環境に複数台のサーバーを準備して，その上で IT リソースを管理するプライベートクラウドがある．また，

Xen, KVM, VMWare などにより仮想 PC を管理するもの [7] もこのようなビジネスの先駆けは，Amazon Web Service でああれば，Mesos [8] や Kubernetes [9] などを利用することによっる．よく話題になるのは，感謝祭直後のクリスマス商戦（サイて，複数台のサーバーで構築された分散環境をあたかも一つのバーマンデー）時のアクセス数とオフピーク時の差である．11

マシンのようにコントロールする手段も登場している．

月にはひと月に 76 パーセントの空リソースが発生しているという [5]．

2014 年の時点で，AWS ではデータセンター 1 つあたり最低でも 5 万台存在するという [6]．つまり，単純計算で 11 月にはデータセンター 1 つあたり 3.8 万台分のリソースが無駄になるということである．このような事情から，IT リソースの余剰分を外販する必要が出てくるのも無理はない．しかし，アマゾン一台のサーバーの処理能力を越えるデータ量をさばく必要のあるサービス提供者にとっては，これらの技術は必要な技術である．本稿では，このような環境を活用する方法について述べている．

4. ハイブリッド型データ収集
本節では，サービス提供者の観点から発想した，センサー側

データ量

データ量

12時

常時取得データ（傾向分析の元ネタとなる）（サービス向上に利用）
例： 温度、振動、日照、脈常時取得データ（傾向分析の元ネタ。サービス向上に利用）
例： 温度、振動、日照、脈

時刻
0時

データ量

24時

0時

(a)

時刻

12時

時刻

24時

0時

12時

(b)
図5

(c)

データの収集タイミングを変化させるからサーバー側へデータをプッシュする方式と，サーバー側からクライアント側のデータをプルする手法を組み合わせたハイブリッド型のデータ収集手法を提案する．

なっている [11]．
そこで，サーバーのリソースに余剰が出たときに，サーバー側のタイミングでデータを取得する手法を本稿では提案する．

4. 1 イベント発生時の情報を扱ってきた過去

これまで通り，緊急性の高い情報はサーバー側で遅滞なく受信

従来，機械警備業など，企業や家庭にセンサーを取り付けそして処理する一方で，IT リソースに余剰がある際は，平時ののセンサーの情報を元にサービスを提供するような事業形態でデータを収集するというものである（図 6）．

は，顧客とサービス提供者との間を取り持つ通信網としてインターネットよりも制約のある，電話や FAX に利用する一般公サービス提供者

サービス提供者

衆回線を使用してきた．
一般公衆回線における制約（例：通信のたびに発生する通信料，通信帯域/レイテンシー/通信データ量などの制約など）のもとで，リアルタイムな最適のサービスを提供するために，顧客の建物に設置したセンサーやアクチュエーター（電子錠など）

緊急性の高い情報は、今まで通り、即時に受け付ける。とそのコントローラーでできる限りの処理を実行し，サービス

図6

提供者に伝えなければならない必要なデータのみを，サーバーへプッシュしてきた（図 5(a)）（注 1）．

4. 2 平時の情報を扱う未来
インターネットが普及して以来，通信インフラの通信遅延，通信帯域，通信データ量が一般公衆回線よりも飛躍的に向上し，通信料も定額となっていった．このため，前述したような形態のサービス提供者も，一般公衆回線からインターネットへ切り替えてきている．通信インフラが一般公衆回線だった時は，サービスに必要なイベント情報を受信していたが，今後はインターネット回線の優位性を利用して，イベント発生時ではなく平時のデータを常に取得し，サービスを向上させることが鍵となっている．
たとえば，温度，振動，日照，脈などを常時取得して，お客様の状態などの傾向を分析し，サービス向上やリスクの未然防止に利用することができると考えられる．このようなデータもサーバーへプッシュする方法で収集する場合，図 5(b) のように受信するデータがかさ上げされることになる．

4. 3 ハイブリッド型データ収集
ところで，このような傾向分析に必要なデータは緊急性は高くなく，即時にサーバーが受信できなくとも 1 日単位でデータを取得できれば良いことが多い．また，近年では，組み込み機器やモバイル端末にもデータベースを実装することが可能になっており，即座に必要ないデータを貯めておくことが可能に（注 1）：近年，このようなアーキテクチャはエッジ・ヘビー・データ [10] という言葉により再注目されている．

平時のデータは、ITリソースが暇なときサーバーが収集する全体としてコンピュータのリソースを使い切り続ける

緊急時と平時のデータを別々に受信

刻々と変化するサーバーの IT リソースの余剰分に合わせて，データ収集スケジュールを生成し，決められた単位時間以内(deadline) で全クライアントからデータを収集できるようにダイナミックにデータの QoS を変更するというものである．
この手法により，図 5(c) のようにピーク時性能に合わせたコンピューターリソースを，有効に活用できることができるのではないかと考えた．

4. 4 プル型が適用できるシステムの特徴
サーバー側からクライアント側の情報をプルしてデータを収集するシステムの特徴は，そのシステムで実施するサービスの観点から，以下に説明する 2 つの特徴が上げられる．
一つ目は，センサーの情報を使って 365 日 24 時間サービスをするという特徴である．これらのクライアント側も 365 日 24時間通電された状態である．このため，サーバー側からクライアント側へアクセスすることを前提条件として考えることができる．
二つ目は，センサーの情報を使ってサービスを提供する場合，サーバーだけでなくクライアント側の機器やアプリケーションもサービス提供者のものであることが多いことである．このとき，一般的な Web アプリケーションの場合と異なり，サーバーとクライアントが協調したシステムとなることができ，通信をセキュアにしたり通信内容をサーバー側クライアント側双方の都合で変更することができる．
（図 7）．

24時

稿で提案しているサーバー側からクライアント側のデータを問い合わせるプル型のアーキテクチャも準備しておき，サーバー側で問い合わせのタイミングや内容を随時変更する方法が考えられる．
以降で説明するが，本稿では，データ収集のタイミングやデータの精度など，データ収集戦略の変更をよりダイナミック
Webのサーバーは、不特定多数のコンピュータ（クライアント）から一方的にアクセスされることが多い。

図7

IoTのシステムにおいてサーバーとクライアントは既知の関係であり、サーバーはクライアントを制御可能であることが多い。

サービス提供者のサーバーにとってクライアントは既知により柔軟にできる方法は，クライアント側のアプリケーションやパラメータを遠隔から更新する方法よりも，サーバー側で問い合わせのタイミングや内容を随時変更する方法だと考えた．

5. 2 アドホックな情報収集
災害発生時などでは，あるエリアの最新の状態を頻繁に取得

5. IT リソースの有効活用以外の利点したいということが発生する．このようなとき，イベント発生

本稿で提案するハイブリッド手法によるメリットは，IT リソースの余剰を有効に使い切ることだけがメリットではない．
本節では，サーバー側がクライアント側のデータを収集するときにサーバー側の都合で QoS を変更できるメリットと，アド時にデータを上げるだけの仕組みだと，任意のタイミングで任意の精度のデータを収集することは難しい．しかし，サーバーから情報を収集する仕組みになっていれば，任意の場所の情報を任意のタイミングで取得することができる（図 9）．

ホックな情報収集ができるメリットを説明する．
サービス提供者

5. 1 サーバーとクライアントの進化のずれを緩和する
近年，低価格帯の組み込み機器においても，その性能は格段【災害時など】○○県××村の物件の現状を今すぐ収集したい！に向上してきている．これらをセンサーの情報を収集するクライアント側として使い，その能力を使い切ってデータを取得す
ると，ミリ秒オーダーの非常に細かい粒度のデータを取得することができる．そのデータをクライアントからサーバーへ送信
すると，クライアント数が膨大な場合はサーバー側に求められる能力が甚大となってしまう．このため，クライアント側で統○○県××村

計処理など事前に処理して送信するデータ量を調節する必要が

図 9 場所を指定して取得することができるある（図 8 の 2015 年の例）．

5. 3 状況や目的に応じた QoS
サービス提供者

サービス
提供者

前述したようなアドホックな情報収集をしたとしても，その1Gbps

100Gbps

負荷によってサーバーがクライアントからデータを取得できな10s間隔100ms間隔くなるということがあってはならない．このため，状況に応じて QoS をダイナミックに変化させる機構は重要である．
また，この手法によって，用途ごとに必要な QoS の基準で100ms 100ms 100ms

2015年
図8100ms 100ms 100ms

2025年

サーバー側の都合でデータの QoS を変更するデータを収集することができる．常時取得データを統計分析のためだけに使うなら，サーバーがクライアント側のデータを全て取得する必要はなく，クライアント側で統計処理を実施した状態でサーバーが収集しても問題ない．一方，証跡として平時

ところで，企業や家庭に設置するような設備は，何年も交換せずに使用することが多い．その理由は，クライアントの機器の性能が十分であること，クライアントの機器が方々に点在すること，一度設置すると変更工事が難しいことなどである．一のデータを残す必要がある場合，できるだけ粒度の細かい状態で平時のデータを保管しておくことが望ましくなる．

6. シミュレーター

方，サーバー側は，ネットワーク帯域や処理能力などを徐々に6. 1 概向上させることができ，クライアント側の全体の能力に，後か本稿で提案した「データを受信しつつオフピーク時にデータら徐々に追い付くことが可能である（図 8 の 2025 年の例）．

を回収する手法」を理解しやすくするために，シミュレーター

このとき，クライアント側とサーバー側との通信の頻度や観を構築して可視化した（図 10）．

データの精度（データ量）を変更する方法として，2 つ考えら可視化に際して，サーバーを空中に浮かぶ球として表現し，れる．もし，クライアント側からデータをプッシュするアーキ

クライアントを日本地図上に配置された透明の点として表現しテクチャであれば，クライアント側のアプリケーションやパラた．クライアントからサーバーに対してデータを送信すると，メータを遠隔から更新する方法が考えられる．もう一つは，本データを表す点がクライアントの座標からサーバーに向けて移ジュールを決定し，24 秒ごとに収集プロセスにスケジュールを転送する．スケジューラープロセスは，転送されてきたスケジュールを元にクライアントから情報を収集する．
クライアントもサーバーも，描画が必要な処理の内部で，描画メッセージを UDP で可視化ツールの Web サーバに送信している．

6. 3 スケジューリング方法
今回構築したシミュレーターのサーバーは，24 秒間に受信したイベントデータの受信パターンから，翌日の平時のデータ収集スケジュールを決定している．ここでは，サーバー側がどの
図 10

シミュレーション可視化の概観ように収集スケジュールを決定しているかを説明する．
サーバーは 24 秒ごとに過去 24 秒間でどの程度イベントデー動する．その点の色は，データがイベントデータの場合には赤タを取得したのかをヒストグラムとして算出する（図 12-a）．

く，平時のデータの場合には黄色い．

そのヒストグラムから，ピーク時の負荷を求めて，平時のデー

また，平時のデータをサーバーからクライアントに対して問タに使える IT リソースを算出する（図 12-b）．そのデータをい合わせることもできる．サーバーからクライアントへの問い元に，翌日の収集する際のヒストグラムを求めて，収集スケ合わせを，サーバーからクライアントの座標に対して伸縮する

ジュールとしている（図 12-c,d）．

緑の直線によって表現した．

今回は deadline を守るために QoS を変化させる手法は検討

なお，右上にはシミュレーション上での時刻を表示した．

しなかったが，たとえば，統計的な手法を用いて deadline まで

6. 2 シミュレータのアーキテクチャに情報を収集する方法 [16], [17] や，ウェブクローリングのスケシミュレーターは，可視化ツール部とシミュレーター部の 2

ジューリングアルゴリズム [18] の研究が役に立つ可能性がある．

つに分けて構築した（図 11）．
データ量

データ量

スケジューラー
収集プロセス

受信プロセス時刻

WebSocket
0時

WebServer

12時

サーバー

UDP

24時

時刻

0時

(a)

12時

24時

(b)

データ量

データ量

Webブラウザ（WebGL）

・・・ 4万 ・・・
クライアント（物件シミュレータ）時刻0時

可視化ツール

12時

時刻
0時

(c)

シミュレーター

6. 4 評

12時

24時

(d)

図 12

図 11 シミュレーターのアーキテクチャ概要

可視化ツール部は，Go [12] で書かれた Web サーバと Web ブ

24時

スケジューリングの手法

価ラウザで構成される．Web ブラウザは WebGL [13] に対応してサーバーのデータ受信状況がデータ収集手法によってどのよいれば，どの Web ブラウザでも問題ない．Web サーバーは，うに変化するのか，シミュレーターを用いて 3 とおりのシナリ

シミュレーターから UDP で描画メッセージを受信し，それをオで評価した．共通の条件とシナリオは以下のとおりである．

Websocket [14] 経由で Web ブラウザに表示している．

シナリオ共通条件

シミュレーター部では，各クライアントとサーバーを Er-•

1 日を 24 時間ではなく 24 秒とする

lang [15] のプロセスで実装しており並行に動作している．図中•

クライアント数：40000の青い四角形はクライアントをあらわしており，各クライアン•

サーバー数：1•

クライアントは，24 秒に 1 回，イベントデータをサー

トは 24 秒間に一度サーバーに対してイベントデータを送信している．送信するタイミングは，各クライアントにあらかじめ割り当てられた確率分布を元に，24 秒おきに各クライアント内部で決定される．

バーへ送信

•

クライアントのイベントデータの発生時刻は，ラプラス分布とガウス分布に従う．

シミュレーターのサーバーは 3 つの Erlang プロセスで実装– ラプラス分布：µ = 8, σ = 0.5

されいる．一つは受信プロセスである．受信プロセスは，クラ– ガウス分布：µ = 18, σ = 2.0

イアントから随時信号を受信しつづける．スケジューラープロ– 分布生成にノイズは入れない

セスは受信プロセスのデータ受信状況を定期的に観測し，スケシナリオ (a)： イベントデータが即時に送信される場合

サーバーの受信信号数

4000

3000

3000

3000

2000

2000

2000

1000

1000

1000

00

0:11
2:07
4:03
5:59
7:55
9:51
11:47
13:43
15:39
17:36
19:32
21:28
23:23

0

時刻

(c)

図 13

スケジューリングの有無の比較

クライアントは，イベントデータのみ送信する．平時のデータは発生しない．
シナリオ (b)： イベントデータと平時のデータが即時に送信される場合•

クライアントは，24 秒に 12 回，平時のデータをサーバー
クライアントの平時のデータの送信時刻は，一様分布にシナリオ (c)： イベントデータは即時に送信される一方で，平時のデータはクライアントに蓄積され，サーバーからの問い合わせに応答する場合
サーバーは，平時のデータを 24 秒以内に全クライアン

トから 12 回ずつ収集•

企業や家庭にセンサーなどを設置して，そのデータによってサービスを提供する事業者には，即時に受信し処理することが必要な情報（サービスの根幹に関わる情報）と，統計情報などで必要な情報（サービスを向上させるために必要な平時の情報）
えて，サービスの根幹に関わる情報に合わせて，IT リソースのピーク時性能を見積り，余剰分はサービスを向上させるために従う．

•活用する手法を提案した．とがある．本稿で紹介した手法は，これらの情報の特性を踏まへ送信

•

平時データ

(b)

(a)

•

イベントデータ

0:10
2:06
4:02
5:58
7:54
9:50
11:46
13:42
15:38
17:33
19:30
21:25
23:21

4000

0:14
2:09
4:05
6:01
7:56
9:52
11:48
13:43
15:39
17:35
19:31
21:28
23:23

4000

翌日の収集スケジュールは 24 秒経過時点で再作成必要な平時の情報の処理に利用するというものである．
この手法は，IT リソースの余剰分を有効利用できるだけな
く，サーバーとクライアントの性能の進化のずれを緩和したり，アドホックにサーバー側の都合でクライアント側の情報を取得できるようになったり，状況や目的に応じて QoS をダイナミックに変更させることができる．
また，このような手法を理解しやすくするために，シミュー

図 13 のグラフはそれぞれ，上記シナリオでのサーバーのデータ受信回数を示している．イベントデータも平時のデータも即時に送信する場合は，サーバーの信号受信量のピークが 4000 弱になっている．その一方で，サーバーからクライアントへ問い合わせをする場合は，ピークが約半分の 2000 強で済んでいる．

7. 今後の課題
本稿では，クライアントの情報を収集するスケジューリングの戦略として 24 秒（時間）単位のものをシミュレーションで利用した．実際には時間のパターン，曜日によるパターン，年間を通じたパターンにあわせたスケジューリングや，パターンではなく分単位などより細かい粒度でダイナミックにスケジューリングを実施する機構が必要である．このようなスケジューリングは，スマートグリッドの電力需要予測の研究 [19] などが参考になると考えている．
また，サービスを向上させるために必要な平時の情報を実際に取得するには，本稿で上げた課題以外にも，プライバシーについての課題がある．どの情報を顧客からプルしても問題ないのか，プルしてきたデータをサーバーでどのように扱うかという課題である．

8. ま と め
本稿では，時間帯によって負荷が大きく変動するような，センサー情報を収集するサーバーの IT リソースの余剰分を有効レションし可視化するアプリケーションを構築した．
文献[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, andMarimuthu Palaniswami. Internet of things (iot): A vision, architectural 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 Griﬃth, Anthony D Joseph,Randy Katz, Andy Konwinski, Gunho Lee, David Patterson, ArielRabkin, Ion Stoica, et al. A view of cloud computing. Communications 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-arc206aws-reinvent-2013.
[6] James Hamillton. Aws innovation at scale, Nov. 2014. http://www.
slideshare.net/AmazonWebServices/spot301-aws-innovationat-scale-aws-reinvent-2014.
[7] Borja Sotomayor, Rubén 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 center. 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 Wikström, and Mike Williams.
Concurrent programming in erlang. 1993.
[16] Susan V Vrbsky and Jane WS Liu. Approximate — a query processor 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 Proceedings of the 8th ACM European Conference on Computer Systems, pp.
29–42. ACM, 2013.
[18] Carlos Castillo. Eﬀective 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. Demand Forecasting In Smart Grids. Bell Labs Technical Journal,
Vol. 18, No. 4, pp. 135–158, 2014.