[レポート] 米国における IoT / Big Data & Analytics 活用事例の最前線 – 先進事例に学ぶ IoT のベストプラクティス #awssummit

2015年06月02日、06月03日と開催され、大盛況のうちに幕を閉じた『AWS Summit Tokyo 2015』ですが、今回(というか去年辺りから)私はプレス枠での参戦をしておりました。

• AWS Summit Tokyo 2015 - クラウドで、未来を「今」に。- 2015年6月2～3日 グランドプリンスホテル新高輪にて開催

参加した幾つかのセッションについてはCodeZine様でレポートとして寄稿させて頂いていますが、非常に興味深い内容であった当セッションについては当ブログでもその内容についてレポートしたいと思います。40分のセッション時間がアッと言う間の内容の濃さでした。

• 米国における IoT / Big Data & Analytics 活用事例の最前線　－ 先進事例に学ぶ IoT のベストプラクティス【同時通訳】

IoT概要

• 登壇：Miha Kralj（Principal Solutions Architect, Amazon Web Services, Inc.）

まず登場したのはミハ・クラーリ氏。『40分掛けて、川本と私の方から、どのように(今回ご紹介する)新しい領域、所謂"IoT"にどのように対応して行くのか、お話したい。』と切り出し、セッションスタート。

• IoTというものが従来とどう違うのか、見て行きましょう。
• "IoT"の定義とは：
  • 少なくとも1つのコンピューティイング機能を持っている複雑なデバイスを指す。
  • 少なくとも1つ何か、制約があるもの。
  • ネットワーク側に縛りがある。非常に小さな、シンプルなものである事、環境が従来のものとは違うのだという事を認識すべき。
  • 通常は数千台、またはそれ以上の数量で展開されるもの。IoTの文脈で"モノ"と言ったら、何万台と言ったマシンを想定するのが普通。
  • 人的なやり取りなしにクリティカルな用途で利用されるもの。これは重要なポイント。30年という進化の中で、マシンのサイズは進化し、環境の中で小さなマシンやデバイスに発展進化して来た。スクリーンも無い。IoTの世界ではそういうものに対応していかなければならない。これがM2M(Machine to Machine：機器間通信)の時代。

• IoT(Internet of Things : モノのインターネット)に関するWikipediaの記述を見ると興味深い定義が。
  • サーバはただのもの。稼働するもの。
  • IoTの世界では、5〜10万のサーバを稼働させている。これは即ち『モノ扱い』としている。
  • IoTの話をする際に、対象は何になるだろうか？通常は『人とのやり取りが介入しないもの』を指す。
  • IoTで扱うモノは、スクリーンは必ずしもついていない。キーボードも無い。センサーもインプット用のものは無い。リセットも出来ない。
  • この定義を当てはめると、人とのやり取りが出来ない、という条件が"モノ"に当てはまる。つまり、携帯電話は"モノ"にはならない。一方でRaspberry Piは"モノ"の対象となる。

• あと、『実際にリーチ出来るか否か』というのも重要なポイントとなる。『アクセスが難しいデバイス』というのもIoTの定義に入るだろう。地中を掘り進むドリルに付けられたデバイスはIoT足り得るだろうし、ビデオレコーダーについては"モノ"とは成り得ない。
• これは我々が考えている定義だが、人とのやり取りが減れば減るほど、デバイスが小さくなればなるほど、データはより大きくなる。そして課題も新しいものが現れてくる。

• ここで事例を1つ紹介しよう。シアトル在住、蜂をすごく大事にされている人(？)によるAWSクラウドでの『蜂の巣箱のモニタリング』だ。
• 蜂の巣のと言うのは適切な温度管理が重要で、温度が高過ぎると蜂蜜を作ることが出来ず、場合によっては蜂が死んでしまうこともある。
• 暑いのか寒いのか、日陰に居るべきかどうか等をIoTのアプローチを使って検証してみた。
• Raspberry Piのマイクロサービス・デバイスを入れてセンサーで内部の温度を取得し、定期的にデータを送っている。
• 
• アーキテクチャを見てみよう。そんなに複雑なものではない。シンプルなPythonスクリプトが実行され、各種リソースを経由して適切な情報を表示している。
• 

• IoTアーキテクチャの例を見ていこう。ここでは"4つの大きな課題"に直面する事になる。バックエンドについてはの方から後ほど解説があります。
• 4つの課題とは、『IoT コマンドにおける課題』『IoT デバイスDevOpsにおける課題』『IoT 監査と承認における課題』『IoTテレメトリーに関する課題』です。

IoT コマンドにおける課題

まず最初に、コマンドを送るところから見ていこう。『適切なコマンドをデリバリーする』というのは、言うのは簡単だが、実は些細なことでは無い。最低限のコマンドだけを送れる、という事を念頭に、信頼できるコマンド、最小コネクションでトランザクション処理のもと、『正確なコマンドを送信する事』を心がける必要がある。

アーキテクチャを見ていこう。各デバイスへの指令を出すケースだ。各種リソースを通じての処理を行う過程で、フィードバックを得ていく必要がある。

IoT デバイスDevOpsにおける課題

• 開発に於ける課題を考えると、コマンドを送るという作業は難しい作業となる。物理的に置き換える事は出来ないし、リブート(再起動)もさせる事は出来ない。間違えたコマンドを送ってしまったらそのまま。
• 何の助けも無い。無いからこそ、開発を行い、パイプラインを作成し、ステージング、検証ステージに移して最終的なデバイスをしっかり検証して行く事が大事となる。
• 段階的、そして繰り返し行われる更新処理に対応するために、様々な条件下でも稼働するインテリジェントな例外処理管理が求められる。
• アーキテクチャを見ていこう。ファームウエアのアップデートを考える場合、バンドルを入手し、デバイスセットがちゃんと情報を受け取って更新を行う。
• DevOpsの場合はファームウエアの更新も必要。ステージング環境が更に重要度を増してくる。

IoT 監査と承認における課題

次に理解しなければマシンやユーザーが許可を持っているか否か、という事。リソースの複雑な認証プロセスに対応する事が求められるし、デバイス認証の更新も考えられる。クラウドのアーキテクチャを考えた場合、Cognitoがやはり重要なサービスとなってくるだろう。

IoT テレメトリーに関する課題

テレメトリー＝遠隔測定法。

• 遠隔測定法 - Wikipedia

センサーが情報を掴み、ストリームがその情報を受け取り、分析し、後で利用出来るようにデータを保管する。データが増えてくると産業的な段階へと進んでいく。データの小さな流れは小川に、そして河川に。データの川になって行く。

接続が途切れる問題への対応やセンサーデータの転送品質、また、ピークや落ち込みの波形を許容する柔軟性も求められる。

ここから先はバックエンドの話。高速のデータキャプチャを行うにはどのようなサービスがあれば良いのか、川本の方から解説を行います。

ビッグデータ処理の簡略化

• 登壇：Eugene Kawamoto（Sr. Mgr, Business Development, Amazon Web Services, Inc.)

ビッグデータとはそもそも何なのか。ビッグデータを簡略化・要素分解し、分かりやすく説明したいと思います。AWSでは、ビッグデータに関する豊富なツール群と連携しています。何を選ぶべきか。サービス・商用ツール、色々なものがあります。

ビッグデータパイプラインについて。考え方としては、何らかのデータのインプットがあり、何らかの回答を得たい。その過程で必要な処理を繋げています。大きく以下4つの処理・パターンに分ける事ができます。

• データ収集と蓄積
• イベントプロセッシング
• データプロセッシング
• データ分析

データ収集と蓄積

多くのお客様が目にするのが、データをS3に、『データレイク』として集め、そこからEMRやDynamo、Amazon ML等と組み合わせて使う、というケースでしょう。S3は御存知の様に"イレブンナイン"の非常に高い耐久率を誇るサービスです。

データ収集・蓄積の際は、データをどのように扱うか、扱う粒度によってその管理方法も変わって来ます。トランザクションデータであればRDSやAurora、ファイルであればDynamoDBやS3。StreamのデータであればKinesisが適しています。

以下は1つのアーキテクチャを実現した際に掛かる費用について算出したものです。色々なツイートを収集し、Redshiftに格納する..というような構成を想定しています。1日5億ツイートを収集して分析しようとするとどれくらい掛かるのか？毎秒5800ツイートを処理する計算になります。算出された数字は以下の様になります。これだけ多くの処理を行なったとしても、この程度のコストで済むのです。

イベントプロセッシング

イベントプロセッシングについては今流行のLambda。イベントドリブンなプログラミングで、リアルタイムのインプットをトリガに次のアクションを行わせる事ができます。どういうシーンで使う事ができるか？デバイスのエラー検知やパフォーマンスSLAのモニタリング、閾値を下回った在庫の通知など、様々なシーンで利用可能です。

データプロセッシング/データ分析

データプロセッシングはデータに関する問題の回答を得る部分。分析であればSQLやDWH、センチメント分析やページビュー予測と言った分析・予測等が代表的なものとして挙げられるでしょう。 データ処理のフレームワークは大きく2種類に分けられます。バッチ処理とストリーム処理です。前者はMapReduce、後者はリアルタイムで広告の分析などを行いたい場合、HBaseのクラスタを使って実施する事が出来ます。

IoT/ビッグデータ ユースケースの紹介

ここからはIoT/ビッグデータに関するユースケースの紹介です。まず1例目はスシロー様。米国の先進事例と言っておきながら日本の事例となってしまいましたが...(笑)

日本全国300以上の店舗において、寿司皿にセンサーデータを埋め込み、様々な寿司のデータを取り込んでいます。なぜkinesisを使うのか？バッチで送るとなるといろいろ大変だからです。リアルタイムでkinssisを使い、データを収集しています。また、可視化ツールにはtableuを使っています。

次の事例はコネクテッドデバイスの例、Dropcam社です。いわゆる『Wifiで接続出来る監視カメラ』です。自分の子供の様子を見たり、ペットの様子を見たり、泥棒監視等に使われています。2011年末にAWSに移行し、急激にデータが伸びました。彼らのブログによると、YouTubeで扱っている以上のデータを取り込んでいると言います。

• AWS Case Study: Dropcam

データについてはS3に保存し、メタデータのタギングにはDynamoDBを使っていました。構成図は以下の様な形となります。比較的一般的な構成です。動画メタデータのタギングで使っているDynamoDBはここではキーとなるサービスと言えるでしょう。

最後、3つ目の事例はWeatherBug。天気情報アプリです。

• Local and National Weather Conditions & Forecast - WeatherBug.com

色々な場所にセンサーデータを置き、様々な情報を観測しています。バックエンドAWSを利用し、データ蓄積にはDynamoDBを使っています。

構成は以下の様な内容となっています。アナリティクスやトレンド分析、異常発生予測等がこのアーキテクチャで可能となりました。

さいごに

以上でこのセッションの解説はおしまいとなります。これより先、もっと詳しい情報が知りたいならば、re:Inventに参加しよう！という形で締めました。40分みっちりIoTの勘所を押さえた、非常に聴き応えのある内容でした。この辺りの要点を踏まえつつ、来るべきIoTの波に備えて行きたいですね！こちらからは以上です。

• AWS re:Invent 2015