Comments
Description
Transcript
トップエミュレータ
Gigandroid: 多数のスマートフォンを対象としたサービス検証基盤の 提案 Design Issues on Gigandroid 三輪 信介 ∗ 概 要 本稿では、多数のスマートフォンを対象としたサービスを検証するための基盤として、 Gigandroid を提案する。Gigandroid では、Android を対象に、多数の Android を模倣するととも にそれぞれの利用者の行動も模擬することによって、実際にあるスマートフォンのサービスを利 用した場合に起こりうる問題などを検証できるようにすることを目指す。Gigandroid は、多数の Android を模倣するエミュレータ部と、模倣した Android のセンサーに位置情報、温度情報、振 動、アプリケーションの操作など利用者の活動で変化しうる要素を模擬して提供するシミュレー タ部から構成される。本稿では、まず Gigandroid の構成要件について述べ、その上でエミュレー タ部の設計と概念検証実装について述べる。 はじめに 1 とはどうやって確かめることができるのか。こ れは、IoT デバイスが大量に配備された後にシ ステムとして正しく機能するのかということと 同種の問いである。そこで本稿では、Giga（10 億）台の Android から構成されるサービスやア プリケーション、システムなどの検証を可能と する基盤として、Gigandroid を提案する。本 稿では、Gigandroid の構成要件を述べ、実装 によって概念検証を行う。 ここ数年で急速に、使われるコンピュータ端 末はデスクトップやラップトップの PC から、ス マートフォンやタブレットなどに移行しており、 電話としての機能も兼ね備えたスマートフォン は人にもっとも近いデバイスの一つとして位置 づけられるだろう。また、スマートフォンには タッチスクリーンのような UI に加え、GPS、温 度センサー、振動センサーなど様々なセンサー が内蔵されており、人に身近でかつ大量に普及 している IoT デバイスともいえる。このよう な特性を踏まえ、スマートフォンとクラウドと PC を連携させるサービスや、移動しながら使 うことを前提に位置情報を利用するサービスな ど、スマートフォン向けのアプリケーションや サービスは多様化している。 スマートフォンの年間出荷台数は 13 億台を 超えて [1] おり、アプリケーションによっては 数百万ダウンロードを誇っているものもある。 では、それらがそれぞれ様々なセンサーや UI 操作などを経て、連携した場合、正しく動くこ 2 構成要件 Android 端末に関するサービスやアプリケー ション、システムの検証や実験などを行う上 では、検証や実験に必要となる台数分の Android 端末について、Android 端末へのセンサ や UI への入力の模擬とそれに伴うアプリや Android OS と各種のセンサの振る舞いを含めた Android 端末の挙動の模倣の両方が必要にな る。提案方式では、利用者の行動や周辺環境に よる Android 端末への UI やセンサへの入力情 報の模擬を行うシミュレータ部と、各種センサ の振る舞いを含めた Android 端末の模倣を行 うエミュレータ部に分けることとする。検証や ∗ 国立研究開発法人 情報通信研究機構 ソーシャルイ ノベーションユニット 1 実験の実施は、入力情報を整えてシミュレータ 部に入力し実行することで行い、検証や実験結 果は、エミュレータ部からセンサ情報の取得や ネットワークからのパケットキャプチャなどに よって取り出すこととする。 2.1 2.2 シミュレータ部とエミュレータ部の 連携 センサへの入力を行うシミュレータ部では、 すべての入力値を事前に用意する方式では、複 数の Android 端末利用者間の影響など動的な 要素が反映できない。そのため、センサ毎に関 連する「場」を用意し、その「場」に対する影 響が起こった場合、その影響を数値計算などで シミュレーションし、センサに値を送る方式を 考える。エミュレータ部には、シミュレータ部 からの入力を受け付けたり、シミュレータ部も しくは検証・実験の実施者に現在のセンサ値を 出力するインタフェイスが必要となる。 例えば、位置を示す場では利用者が移動すれ ばその利用者の位置情報が変化し、GPS 等に 入力される。屋内から屋外に出た場合には、温 度を示す場で気温の変化がシミュレートされ、 温度センサーに入力される等である。 Gigandroid では、このシミュレータ部で扱 う場の精度を、関連するエミュレータ部の忠実 度に合わせて変化させることで、シミュレータ 部の計算量を調整可能とすることを目指す。 エミュレータの忠実度 実際には、検証や実験を行う上で、各種セン サの振る舞いまで必要な Android 端末もあれ ば、なんらかの Web トランザクションが行わ れれば良い程度の Android 端末もある。また、 デバイスの違いまで含めた検証を求めるような 場合もある。このような違いを実デバイスに対 するエミュレータの忠実度と呼ぶことにする。 実デバイスそのものは一番忠実度が高く、実 デバイスでできる全てのことができる柔軟性 があるが、検証や実験を行う上ではコストも 高く、制御が困難なため繰り返した場合の再現 性も低い。逆に、特定のアプリケーション時の 動作の結果として発生するパケットトレースを 模擬するようなエミュレータは忠実度が低いと 考えられ、検証や実験を行う上でのコストは低 く、制御が容易なため繰り返した場合の再現性 も高いが、柔軟性が低く特定の事象しか発生し ない。Android 端末そのものを模倣するエミュ レータ [2] は、ちょうどこれらの中間の忠実度 を持つと考えられ、実デバイスでできる多くの ことができる柔軟性を持ち、検証や実験を行う 上ではエミュレータを実行するための PC 等が あれば複数台の端末を容易に模倣できる程度の コストであり、エミュレータの UI を介して制 御がうまくできればある程度の繰り返しに対す る再現性を担保できると考えられる。 Gigandroid では、非常に大きな規模のサー ビスなどを検証できるようにすることを考え るため、忠実度の違うエミュレータを組み合わ せられるようにすることで、現実的なコストで の検証・実験環境の構築を可能とすることを目 指す。 2.3 規模耐性 Gigandroid では、非常に大きな規模のサー ビスなどを検証・実験できるように、規模に対 する耐性が必要となる。規模に対する耐性を備 えるために、記述、駆動、制御のいずれの側面 においても、分割・併合が容易である必要があ ると考えられる。 また、規模が大きくなった場合、全体を完全 に統治することは非常に難しいと考え、検証や 実験の実行状況については統計学的な可用性や 観測可能性という概念を導入し、検証や実験の 結果はあくまで観測可能な標本の一つとして捉 えることとする。 なお、実際にはサービスやアプリケーション、 システムを構成するサーバやクラウドなども模 倣する必要があるが、本稿では割愛する。 2 User root Node Child Node Child C hild Node Nod dee Child C hild N Node od dee Child C hiilld Node hild Nod dee Child C hiild N h Node od dee Child C hild Node No od dee d Child C hiild ld Node ld Nod dee Child C hilild Node No N od de Leaf Node Leaf Node AE eemulator mulator eemulator mul ulat ator eemulator mulator AE eemulator mulator eemulator mul ulat ator eemulator mulator Leaf Node … AE eemulator mulator eemulator mul ulat ator eemulator mulator 図 1: Gigandroid エミュレータ部の概要 エミュレータ部のプロトタイプ 3 また、Android 端末エミュレータを用いるた めに、多数の Android 端末エミュレータを一 括して制御できる制御機構が必要となる。今回 は数千台程度を想定するため、単純な木構造と し、根となり UI となる Root ノードと実際に Android 端末エミュレータを動かす Leaf ノー ドで構成する。Root ノード内に UI のための子 ノードを Android 端末エミュレータの必要台 数分用意し、子ノードの状態を制御することで 全体を制御する。Leaf ノードは子ノードの状態 を監視し、子ノードの状態変化に応じて自身の Android 端末エミュレータを割当て、起動した り、停止したりする。（図 1） 実装 Gigandroid について、まずは数千台程度の Android 端末からなるサービスを想定し、Android 端末エミュレータを用いたエミュレータ 部のプロトタイプ実装を行ったので、その設計 と実装について述べる。 3.1 設計 エミュレータ部には、シミュレータ部からの 入力や検証・実験を行う実施者からの命令を受 け付けたり、Android 端末の各種センサの状態 情報について出力したりするために、下記のよ うな特性を持つインタフェイスを備える必要が ある。 3.2 実装 Android 端末エミュレータには、たくさんの 種類 [3, 4, 5] があるが、今回はもっとも入手 しやすく、かつ、各種のセンサ類の模倣機能ま で有しているという点から、Android SDK に 附属する Emulator コマンドによるもの（以降 Android Emulator、略称 AE）を利用すること とした。 AE のインタフェイスには、Telnet と ADB • 状態に応じて値が随時変化すること • 必要に応じて値を入出力できること • 端末毎に値を入出力できること • センサ毎に値を入出力できること • 遠隔から容易に入出力できること 3 User User 0) Set requests as profiles of children 0) Set status and scenario to children host_wrapper host_wrapper root Node root Node cchild ch h ld node hild d cchild hilld hild dn node ode cchild ch hild nod n node ode cchild hild n node ode cchild ch h ld node hild d cchild hild hild ld node node cchild ch hild node node nod cchild hild node node 1) Get non-allocated children, randomly 2) Write AE1’s uri to a allocating child’s api_uri 2) Get an allocated child’s status ae_mapper ae_mapper 1) Get AE2’s allocated_uri 3) Set AE2’s next event to event 3) Write allocated child’s uri to AE1’s allocated_uri ae_wrapper ae_wrapper 6) Notify AE2 driven done event ae_driver 4) Drive AE_driver according to event ae_driver 5) Drive AE2 AE1 AE1 AE2 AE2 a) Allocating AE1 to a child b) Event drive AE2 (Allocated child) 図 2: Gigandroid エミュレータ部の動作概要 （Android Debug Bridge）と GUI によるイン タフェイスがあるが、検証・実験の実施者から 容易に全てを操作することはできないので、主 要なセンサの値の変更と取得、シナリオベース での GUI 駆動を RESTful API（ae wrapper） から実行可能にした。また、AE の状態情報な ども同じ API から取得・操作できるようにし ている。 図 2 に主な動作を示す。Root ノードには、子 ノードを収容する DB があり、0) 検証・実験 の実施者は、この DB にどの Android OS の AE を何台、どんなハードウェアで必要とする かなどの AE に対する要求情報を記述してお く。この DB も RESTful API（host wrapper） で操作でき、子ノードの状態の変更やシナリオ の URL の入力などはこの API 経由で行う。ま た、Leaf ノードもこの API 経由で子ノードの 状態を監視する。 Leaf ノードの子ノード割当時の動作は次の 通り（図 2-a）。Leaf ノードの ae mapper は未 割当の AE があった場合（AE1 とする）、1) host wrapper 経由で未割当の子ノードを乱択, 2) あれば子ノードを割当済みにし、AE1 の URI を api uri に書き込み, 3) ae wrapper 経由で AE1 の allocated uri に割り当てた子ノードの URI を書き込む。このとき、子ノードを乱択す るのは衝突回避のためである。 また、ae mapper の割当済みの AE につい て（AE2 とする）の動作は次の通り（図 2-b）。 0) 検証・実験の実施者は、子ノードの状態や シナリオ情報を操作する。1) ae wrapper から 割り当てられている子ノード（allocated uri） と状態情報を読み込み, 2) host wrapper 経由 で allocated uri にある子ノードの状態を取得, 3) ae wrapper から得ていた状態と違う状態の 場合、状態遷移マップで子ノードの状態に近 づく次のイベントを探して ae wrapper 経由で AE2 のイベントを更新, 4) ae wrapper はイベ ント情報の変更を検出して、イベントに応じて ae driver を駆動する。5) ae driver は、AE を 起動、操作、停止し、6) 動作の終了によるイ ベントを ae wrapper に通知する。 ae wrapper は ae driver を介して、Android Emulator のセンサ情報の取得・更新を行うこ 4 4.2 提案方式では、RESTful API を導入し、 HTTP にて通信を行っている。これにより、一 般的で平易なインタフェイスから容易に遠隔か らセンサ情報の入出力や操作を行うことができ る。しかし、RESTful API としているため、状 態の監視等にはポーリングが必要となり、また、 センサのデータなど軽微な情報のやりとりでも HTTP の通信が必要となるなどオーバヘッド要 素ともなっている。このようなオーバヘッドの 解消には CoAP [7], MQTT [8], AMQP [9] 等 の昨今の IoT 向けに使われている軽量で publisher/subscriber モデルや queue モデルを利用 している通信プロトコルの導入が考えられる。 また、今回は数千台程度を想定した単純な 木構造による制御を採用しているが Giga ス ケールを考えるなら、多階層構造にすること や、木構造ではなく根に相当する部分を複数持 ち、Leaf 側から discovery/selection を行うよ うな方法、子ノード情報も複数の根で共有する ような仕組みなど検討すべき事は多い。制御に おける衝突回避も、今回は子ノードの単純乱択 としたが、何らかの戦略を入れる必要があると 考えられる。 図 3: 子ノードの数と割当終了までの時間 とができる。 4 評価と議論 エミュレータ部について、どの程度の規模に 耐えうるのかを評価した上で、現状の問題につ いて議論し、今後の課題を述べる。 4.1 議論と今後の課題 エミュレータ部の規模耐性 実験では、StarBED [6] のグループ N（スペ ックは表 1 の通り）を 20 台用い、1 台を Root ノード、残り 19 台を Leaf ノードとして実施 した。なお、Android Emulator の制限により、 1Leaf ノードあたり最大 64 台までしか Android Emulator は起動できない。 エミュレータ部の規模耐性を確認するため に、子ノードの割当時間として、最初の子ノー ドが入力されてから、最後の子ノードが割り当 てられるまでの時間を計測した（図 3）。横軸 は子ノード数、縦軸は時間（秒）である。横軸 は 2 を底とした対数軸であり、概ね横ばいの変 化であることから規模による伸びは緩やかと考 えられる。10 秒、20 秒に階段上の変化がある のは、現在の ae mapper の実装上、ポーリン グ間隔が 10 秒であるためと考えられ、ポーリ ング間隔を調整すれば、さらに性能向上が図れ ると考えられる。 このようなことから、数千台程度の規模であ れば、エミュレータ部は十分動作すると考えら れる。 5 関連研究 Android のサービスやアプリケーション、 シ ス テ ム 等 の 検 証 を 行 う 上 で は 、AndroidLeaks [10] のような静的な解析手法は、実行 時に動作を変えるようなアプリケーションや複 数台の Android が連携するようなサービスの 検証には適していない。これに対し、動的に解 析する手法として Andlantis [11] があるが、マ ルウェアを対象に大規模に Android エミュレー タを動かす方式で、センサ等を模倣することは できない。BareDroid [12] は同様にマルウェア を対象にして、大規模に実 Android 端末を制 御し解析するもので、同様の環境を流用できれ ば Gigandroid の最も忠実度の高いエミュレー タ部として応用が可能かも知れない。 5 表 1: StarBED グループ N のスペック CPU Intel Xeon E5-2650 (2.00GHz/8 core) x 2 Memory 128GB HDD/SSD 500GB HDD x 1, 200GB SSD x 4 NIC 10GigE x 1, 1GigE x 1 6 おわりに [7] Zach Shelby, Klaus Hartke, and Carsten Bormann. The constrained application protocol (coap). 2014. 本稿では、多数の Android 端末で構成され たサービスやアプリケーション、システム等の 検証を可能とする基盤として、Gigandroid を 提案した。Gigandroid は、端末利用者の行動 や周辺環境によって変化する値をセンサ等に入 力するシミュレータ部と、シミュレータ部から の入力を受けて実際に Android のアプリケー ション等が動作するエミュレータ部からなって おり、本稿では主にエミュレータ部の設計と実 装について述べ、その規模耐性について評価 を行った。今後は、シミュレータ部を含めて、 再度設計と実装を行い、実際に大規模なサービ ス等の検証・実験が行えるかを確認する予定で ある。 [8] Andrew Banks and Rahul Gupta. Mqtt version 3.1. 1. OASIS Standard, 2014. [9] Steve Vinoski. Advanced message queuing protocol. IEEE Internet Computing, No. 6, pp. 87–89, 2006. [10] Clint Gibler, Jonathan Crussell, Jeremy Erickson, and Hao Chen. AndroidLeaks: automatically detecting potential privacy leaks in android applications on a large scale. Springer, 2012. [11] Michael Bierma, Eric Gustafson, Jeremy Erickson, David Fritz, and Yung Ryn Choe. Andlantis: large-scale android dynamic analysis. arXiv preprint arXiv:1410.7751, 2014. 参考文献 [1] 総務省. 平成 27 年版 情報通信白書. 2015. [2] Google. About the android emulator. ⟨url: https://developer.android.com/ studio/run/emulator.html#about⟩. [12] Simone Mutti, Yanick Fratantonio, Antonio Bianchi, Luca Invernizzi, Jacopo Corbetta, Dhilung Kirat, Christopher Kruegel, and Giovanni Vigna. Baredroid: Large-scale analysis of android apps on real devices. In Proceedings of the 31st Annual Computer Security Applications Conference, pp. 71–80. ACM, 2015. [3] Bluestacks. Bluestacks. ⟨url: http://www.bluestacks.com⟩. [4] Andy OS inc. Andy. ⟨url: http://www.andyroid.net⟩. [5] Genymobile. Genymotion. ⟨url: https://www.genymotion.com⟩. [6] 情報通信研究機構テストベッド研究開発運 用室. Starbed4 プロジェクト. ⟨url: http://starbed.nict.go.jp⟩. 6