エッジ・ヘビー・データとそのアーキテクチャ
ビッグデータ時代のITアーキテクチャ
2013 年 56 巻 5 号 p. 269-275
詳細
2013 年 56 巻 5 号 p. 269-275
ビッグデータが普及するにつれ，データの多くはデータセンターではなく，ネットワークの辺縁部（エッジ）に格納され，処理される「エッジ・ヘビー・データ」の時代がくるとわれわれは予測する。このためのコンピューター・アーキテクチャは，現在のクラウドコンピューティングとは大きく異なるものになるだろう。われわれはエッジ・ヘビー・データ向けのアーキテクチャKrillの開発を進めている。このアーキテクチャは，データ価値密度を定義するデータ価値場と，確率的プログラミングモデルからなる。われわれは，この大きな変化を千載一遇のチャンスと捉え，ITのリーダーシップを取っていかなければならない。
ビッグデータの時代になって，情報技術（IT）の世界に大きなパラダイムシフトが起きるだろう。データの多くは「クラウド」と称されるデータセンターではなく，ネットワークの辺縁部（エッジ）に格納され，処理されるだろう。われわれはそれを「エッジ・ヘビー・データ」と呼ぶ。この大きな変化を千載一遇のチャンスと捉え，われわれはITのリーダーシップを取っていかなければならない。
ITを利用して，産業構造のイノベーションを促進するため，経済産業省は「IT融合政策」を発表している1）。その議論の中で出てきたのが，「IT融合に適したアーキテクチャは何か？」という問いであった。IT融合が目指すのは，特に農業・医療・都市交通などITがまだ十分に活用されていない分野のIT利活用で，そこではセンサーから大量のデータが生成される。したがってこの問いは「ビッグデータ時代のITアーキテクチャは何か」という問いでもある。
ITシステムはその設計・運用に多くのステークホルダーがかかわる複雑なシステムであり，そこでは「システムの構造・働きに関する共通理解」としてのアーキテクチャの概念が極めて重要である。よいアーキテクチャは，わかりやすく見通しがよい。ステークホルダー間の誤解が少ないために，信頼性が高い，柔軟で高性能なシステムが構築できる。また，よいアーキテクチャは，接続する機器やソフトウェア提供者などの新たなプレーヤーを引きつけ，その結果周囲にエコシステムを形成する。したがって，よいアーキテクチャを持つことは産業競争力の上でも重要である。
にもかかわらず，IT業界で主流になったアーキテクチャのほとんどは，米国発である。今までのわが国における研究開発の主眼は差別的な要素技術の開発にあり，アーキテクチャの研究開発投資が軽視されていたきらいがある。
あるアーキテクチャが主流になるためには，産業上の力関係や政治力も必要であり，技術的な優位性だけの問題ではない。しかし，クラウドの次に来る，今後主流になりうるアーキテクチャをいち早く捉え，準備しておくことは可能なはずである。特に，Cyber-Physical Systems（CPS）やビッグデータなどの流れから，新たなITアーキテクチャが生まれてくることは必至であり，情報・通信分野の研究開発もそのような流れを無視してはならない。
CPSが普及すると，センサーで発生する大量のデータを扱う必要がある。その際に必要とされる，新たなアーキテクチャはどんなものだろうか。（株）Preferred Infrastructureの岡野原大輔氏は，データの大部分がネットワークのエッジ部分で格納・処理される「エッジ・ヘビー・データ」の時代が来ると予測している2）。
なぜ，ビッグデータの時代には，ネットワークのエッジに多くのデータがたまるようになるのだろうか？ われわれは少なくともコスト，プライバシー，そしてレイテンシー（遅延時間）の3つの主要な要件があると考える。それらの要件を必要とする典型的な利用シナリオとして，（1）監視カメラ，（2）生体センサー，（3）パーソナルモビリティについて考える。
2.1 監視カメラ監視カメラは，典型的なエッジ・ヘビー・データの例である。監視カメラのデータは，デジタルレコーダーに記憶されるが，ネットワークを介してデータセンターに送られることは通常ない。現在市販されている典型的なレコーダーは，0.5～4テラバイト（TB）の記憶容量を持ち，記録された映像は，ハードディスクドライブ（HDD）が一杯になると上書きされ，（解像度やフレーム数にもよるが）数日から数か月の間，保存される。昨年の監視カメラの市場規模は，世界で750万台といわれており，100ギガバイト（GB）／カメラとすると，750ペタバイト（PB）のデータをローカルに保存していることになる。これらテラバイト級のデータは，センターに送って保存するにはコストが高すぎるため，エッジに格納される。
監視カメラの映像はしかし，どのカメラも同じ価値密度を持っているわけではない。毎日多くの人が出入りする正面玄関の監視カメラ映像は，ほとんど人通りのない，バックヤードの監視映像よりも高い価値密度を持っているだろう。また，時刻によっても価値密度が変化する。複数のレコーダーがあった場合，それらのレコーダー間で，データの価値密度に応じた最適なデータの配置をしてほしいだろう。
また，監視カメラは今後，周囲のカメラと連携することによって，より高度な分析を行うようになる。例えば，複数のカメラが連携してテロリストなど特定の人物の追跡を行う例を考えよう。すべての映像をセンターに送って解析するのではなく，あるカメラが指定された人物を捉えると，その情報を周囲のカメラに送ることによって，局所的に人物の追跡をすることができる。
このように，監視カメラのシステムは，すべてのデータをセンターに送ることがコスト的に合わないために，必然的にエッジにデータがたまる，エッジ・ヘビー・データとなる。
2.2 生体センサー血圧，脈拍，体温，呼吸など人体の生命に関する基本的なデータを収集し，疾患予測や健康増進，創薬といったことに役立てようとする動きが広がっている。
こうした情報を扱う際にはデータ量だけではなく，プライバシーも問題となる。個人単位でデータを隔離し，個人ごとに分析を行うといったことも考えられるが，より価値が高いのは伝染病の予測など社会のさまざまな組織単位（家族，企業，学校，地域など）における統計分析である。そのためには，データ交換が必要であり，プライバシーに配慮する必要がでてくる。
プライバシーにおいては，データを必要とする人と，必要とされる人との間で非対称性が生じる。例えば小さい子を持つ親があるイベントに参加しようと思ったときに，インフルエンザや風邪の可能性がある人はどのくらいいて，罹患（りかん）する確率はどの程度なのかを知りたい場合，その親に対して，その確率の情報だけを提供することができればよい（その逆は必ずしもそうではない）。また，企業においては従業員の健康状態（少なくとも勤務中）についての情報は知りたいであろうし，保健所や病院などは地域住民の健康状態を把握したいと考える。
こうした情報をすべてクラウドなど1か所に貯めて管理するのは危険であり，必要に応じたデータが流通できるような仕組みを考える必要がある。
2.3 パーソナルモビリティ現在使われているガソリン車・電気自動車などの移動体に加えて，将来的には1人乗りのパーソナルモビリティが普及すると考えられている。パーソナルモビリティの主な利点は個人あたりの輸送エネルギー効率であるが，次世代のITS（高度道路交通システム）とテレマティクス技術とを融合させることで，車の台数を超える数億の人間の移動情報や個人の意図，外部環境情報などと結び付けられて，膨大なデータが行き交う情報処理ネットワークが交通網の背後に形成される。
そこでキーになるのは，処理のリアルタイム性である。将来の都市交通システムにおいても，安心安全の重要性は変わらず，各移動体について危険を察知して回避する技術への需要が高まる。その達成のためには，車載カメラの画像やドライバーの動向，操作など多種多様なデータ量を瞬時に解析し，危険リスクを算出し，その回避行動をサポートあるいは自動化しなければならない。現代の移動体通信システムのように，中央サーバーに集められた情報を処理した結果を各移動体に送信する仕組みではネットワークのレイテンシー（遅延時間）の問題から高度な判断を必要な時間内に行うことは不可能であり，ここでもエッジ・ヘビー・データとして移動体レベルでの個別のリアルタイム処理が必要となる。
もう1つのキーは情報のローカリティである。地理的に近い移動体，あるいは過去似た状況にいた移動体同士は，情報を交換し合うことによって，近隣の事故情報，渋滞情報のほか，ヒヤリハットの発生情報など，その時々に必要な情報を得ることができる。しかし，数億の移動体の現在から過去にわたる情報の生データをすべて中央サーバーに集めて検索可能な形で要約，インデクシングすることは，監視カメラの例と同様に非常に困難である。この場合もエッジ・ヘビー・データとして重要な情報のみを抽出する処理をエッジ側で行うことによってネットワークを流れるデータの総量を抑え，重要なメタ情報のみがやり取りされるような仕組みを用意する必要がある。
2.4 その他また，現在データをためているとは言い切れないが，ためることができるものとしてスマートフォンが挙げられる。2011年に国内で出荷されたスマートフォンはおよそ2,000万台とされている。少なめに見積もって10GB／台としても200PBのデータをローカルに保存できる状態にある。McKinseyのレポートでは，日本は年間400PBのデータを生成していると記載されている。つまり，このうちの半分はスマートフォンにあってもおかしくはない。エッジ・ヘビー・データを可能にするインフラはすでに存在していると言える。
天文台から得られる大量の天文学データは，それぞれの組織のデータセンターに送られて格納される。全世界の天文学者がこれらのデータを利用して研究を行うが，データが1か所に集められることはない。データが巨大すぎて，移動させることができないからである。これも，エッジ・ヘビー・データの一形態と考えることができる。
エッジ・ヘビー・データを処理するITアーキテクチャはどのようなものになるだろうか。われわれは，データの価値を表現する「Krill」と名付けたアーキテクチャを設計している3）。Krillは，データ価値場と，確率的プログラミングモデルから構成される。
3.1 データ価値場エッジ・ヘビー・データの本質は，データの価値密度に濃淡があり，その価値密度に応じてデータが最適な場所で格納・処理されるということにある。したがって，エッジ・ヘビー・データを実現するアーキテクチャは，まずデータの価値密度を正しく表現できるものでなければならない。
自分があるデータを持っているとしよう。このデータの価値はいかばかりであろうか。データの消費者となる可能性があるのは，自分を含め，その他大勢のステークホルダーである。それぞれのステークホルダー（それぞれを，ここでは「krillノード」と呼ぶことにする）は，他のkrillノードが持っているデータに対する価値を宣言するものとする。これをデータ価値場と呼ぶ。図1は，krillノードが2つだけの場合におけるデータ価値場を示したものである。
データ価値とは，将来にわたる予測価値であることに注意してほしい。一般に，ある時刻t0に集められたセンサーデータの価値は，将来時刻tに依存した確率分布になる。台風の予報円のようなものだと考えてほしい。tが大きくなるほど，つまり将来になればなるほど，この確率分布は分散が大きくなり，価値についての不確かさが大きくなる（図2）。
あるkrillノードが時刻t0に集めたセンサーデータの価値の総量は，他のkrillノードからみた価値の総和である。例えば，ある監視カメラのある時刻における映像の価値は，その映像に他のステークホルダー（krillノード）がどれだけの興味を持っているかに依存している。興味を持つものが多い映像の部分，例えば人が写っているコマは，価値が高いし，そうでない部分は価値が低いだろう。各krillノードは，この予測価値モデルに基づいて，自分のデータについてどうするかを決めなければならない。データを将来にわたって保持するにはコストがかかるため，krillノードは，予測価値の低いデータは捨てる，圧縮するなどの最適化を行ってよい。逆に，予測価値の高いデータは，キャッシュをするなど，システムが自動的に最適な配置を行う。
データ価値を宣言する方法は，いくつかあり得る。1つは，有向グラフで表すやり方である（図3a）。グラフの各ノードはkrillノードを表し，そのkrillノードからみえる他のkrillノードの価値を，重み付きの辺で表す。これが最も一般的な方法となる。もし，krillノードが物理空間に配置されている場合は，krillノードに対してユークリッド空間上の価値関数を定義することによって価値を宣言することもできる（図3b）。
Krillアーキテクチャにおいては，データが必ずしも必要なとき必要な精度で得られるとは限らない。そのデータに自分が興味を持っていたとしても，他のkrillノードが興味を示さなかったために捨てられるかもしれないし，そもそも，自分の過去に宣言したデータ予測価値が間違っていたかもしれないからである。
通常のプログラミング言語を使うと，すべての演算の前に，「データが得られたか」あるいは「そのデータの精度はいかばかりか」を検査しなければならない。これはプログラマーにとって大きな制約となる。プログラミングを楽にするために，われわれは，すべてのデータは，あたかもすべてのkrillノードからみえているようなプログラミングを可能とするモデルを構築しようとしている。
われわれのプログラミングモデルでは，すべてのセンサーデータ（あるいはそれらから派生したデータ）は，分布を持つデータであることを仮定する。
X = Y + 3
というステートメントがあった場合，Yがセンサーデータであるのならば，これは確率変数であると考える。したがって，Xもまた，確率変数となり，内部では確率分布として表現される。入力の確率分布は，予測価値モデルと，そもそもセンサー自身が持つ精度から決まり，ガウス分布など，パラメトリックな分布である場合もあるし，粒子フィルタのようなもので近似される場合もある。プログラマーは，それらの詳細を知る必要がない。
それぞれのkrillノードには，例えばURLのようなグローバルなIDが付与されている。上記確率変数は，このグローバルIDによって識別される。複数のデータ（エージェント）を条件によってまとめて指定したい場合には，システムが用意したライブラリとクエリ言語によって，それらを得ることができる。例えば「私の周囲100m以内にあるデータのリスト」を要求すると，それらのURLのリストが返される。それらのURLにアクセスした時にデータがタイムリーに得られるか，またそのデータの精度（確率分布）がどうかは，実行時に確率的に決定される。
3.3 分散データ分析フレームワーク：Jubatusわれわれは，分散オンライン機械学習フレームワーク「Jubatus」4）を，上記のプログラミングモデルを可能にする第一歩と位置づけている。
Jubatusが実現している機械学習技術とは，大規模なデータに潜む法則性を統計的な手法によって導き出し，データの理解や将来の予測につなげる一連のアルゴリズムの集まりのことである。Jubatusは世界初の分散環境におけるオンライン機械学習を実現するフレームワークであるが，関連するコンセプトとしては，分散かつオンラインの機械学習アルゴリズム，生データと共有データの区別，学習・予測・分析とデータ共有の分離が挙げられる。
分散かつオンラインの機械学習アルゴリズムにおいては各エージェントが機械学習モデルを持ち，それぞれ単体でオンライン学習し，かつそれらが分散協調しながら互いに賢くなることを目指している。オンライン学習は，逐次的に得られる1つ1つのデータサンプルを処理して予測・分析モデルを少しずつ更新しながら現在の状況に追従していくことを可能にする仕組みである。一方で，分散協調動作として，更新されたモデルは裏側でエージェント間で共有され，よりよいモデルへと統合されている。
他の分散学習フレームワークとJubatusが異なる点は，生データと共有データの区別である。Jubatusにおいては，生データを価値密度の低いもの，そこから得られたモデルを価値密度の高いもの，と分類している。一言で機械学習モデルといってもさまざまな種類があるが，それらはモデルの形式さえ宣言すれば，多くはその特定のモデルタイプに関するパラメーターの集合として表現できる。パラメーターの集合は，その学習に用いた生データ集合のサイズに比べて圧倒的にコンパクトであり，それらをエージェント間で共有するネットワークや時間的なコストは非常に小さく抑えられる。これにより，モデルとパラメーター集合の形式が共有・統合可能となるように学習アルゴリズムを設計することと引き換えに，エッジ・ヘビー・データに対してエージェント間で分散協調する際のリソース効率を劇的に向上させることができる。
また，機械学習を用いた予測や分析がリアルタイムであることはエッジ・ヘビー・データの処理で非常に重要であるが，上記のように，モデルの更新・予測に必要な情報を各エージェントが保持していることで，これらは完全にローカルな処理となっており，毎回の予測・分析には分散並列処理を必要としないため，非常に高いリアルタイム性を実現することができる。
これらの仕組みをJubatusではUPDATE（学習），MIX（モデル共有・統合），ANALYZE（予測・分析）と呼び，分類，回帰，レコメンド，外れ値検知などさまざまな機械学習タスクが実行可能となっている。将来エッジ・ヘビー・データへの対応をより進める際に鍵となるのはMIX処理のロジックである。各エージェントが持つエッジ・デバイス上でJubatusを動作させ，自分にとって価値の高い情報を投機的に取得するという選択的なMIX要求ロジックを実現し，必要に応じて必要な形で賢くなる予測・分析モデルを実現することがJubatusの将来像となる。
3.4 デバイス・アーキテクチャデータの価値密度がわかっている場合，ハードウェアのアーキテクチャも最適化できる可能性がある。現在の半導体ディスク（SSD）は，素子単体での信頼性が低いために，多くの冗長性を持たせていて，それがコストや消費電力の上で足かせになっている。価値密度の低いデータは，必ずしも信頼性の高いストレージに置く必要はないので，信頼性の低い，つまりコストが安く消費電力の小さいストレージシステムに置くことができるのである。
ICTにおけるアーキテクチャの流れは，ほとんど常に米国を発信源としていた。どのアーキテクチャが商業的に主流になるかについては，技術的な観点のみならず，経済や産業の動向，政治的な動き，特定の企業の思惑など多くの要素があり，正確に見極めることは難しいだろう。しかし，次に何が現れてもすぐに対応できるように準備を整えておくことが，ICT産業に携わるものにとって，重要であると考える。われわれは，今後現れてくる応用シナリオを考え，そこで必要なアーキテクチャを考えて，1歩先を読んで準備しておくべきであろう。
