クラウドを活用したIoTシステム設計 - Nomura Research Institute

トピックス
クラウドを活用した IoT システム設計
─ IoT システム構築における AWS 活用の勘所 ─
IoT(Internet of Things)ビジネスへの注目度が高まっている。どのよ
うに IoT ビジネスをデザインするかと同様に、どのように IoT システムを
デザインするかも重要である。本稿では、IoT システムの設計思想とクラ
ウドサービスの活用について考察する。
NRI ネットコム Web ネット事業本部
Web インテグレーション事業部 副主任システムエンジニア
さ と う
しゅん
佐 藤 瞬
専門は AWS をはじめとするクラウドサービスを活用したシステムアーキテクト
500 億もの「モノ」とつながる
IoT システム
IoT は「モノのインターネット」などと呼
ばれ、情報通信機器に限らず、さまざまな
18
想がある。本稿では、IoT システムの最適な
設計はどうあるべきかを考察する。
IoT システムの全体像
「モノ」
(例えば家の冷蔵庫や自動車など)が
IoT の対象となる分野は、ヘルスケアから
インターネットにつながる状態、またはその
家電、自動車、産業機械など多岐にわたる。
仕組みを指し、これにより私たちの生活やビ
その多くはセンサーを利用して何らかの情報
ジネスにおいて利便性の向上やコスト削減が
を収集し、インターネットを通じてサーバー
期待されている。
サイド(インターネット上にある Web サー
ITU(国際電気通信連合)によると、世界
バー)にデータを蓄積するものである。本稿
のインターネット人口は 30 億人を超えたと
では、このようなセンサーデータの収集・蓄
言われている。それに対して IoT は近年の発
積を行う IoT システムのサーバーサイドを対
展 に よ り、2020 年 に は 500 億 の デ バ イ ス
象として話を進めたい。
(モノ)がネットワークに接続されると予測
IoT システムに求められる機能は、大きく
さ れ て い る( 米 国 Cisco Systems 社 よ り。
分けて「収集」「蓄積」「分析」の 3 つだ。つ
http://www.cisco.com/web/about/ac79/
まり、モノのセンサーからのデータを受け取
docs/innov/IoT_IBSG_0411FINAL.pdf)。そ
る「収集」、受け取ったデータをデータスト
して、IoT システムが対象とするのはこの
ア に 保 存 す る「 蓄 積 」
、 保 存・ 蓄 積 さ れた
500 億のモノであり、人が見たり、操作した
データにさまざまな手法で行う「分析」であ
りすることを前提に作られた Web システム
る。もう少し詳細に見ていこう。
と同じ設計思想で対応することは難しい。モ
まずは「収集」だ。1 つの IoT システムに
ノ向けには、それに適したシステムの設計思
接続されるモノのセンサーの数は数万~数百
| 2016.09
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
万ともなり、それぞれが収集したデータを 1
析が求められる場合もある。分析手法に関し
秒や 1 分といった間隔で定期的に送信する
ては、アプリケーションの設計やどのような
ケースが多い。
ツールを使うかの問題であるため、IoT シス
通常の Web サイトであれば、サーバーサ
テムの構造に大きく依存することはないが、
イドで行う処理はほとんどがデータの参照で
どのような期間で分析を行いたいかは考慮す
ある。しかし、IoT システムの場合は、1 つ
る必要があるだろう。
1 つのデータ量自体は非常に小さいが、それ
らのデータを全て保存しなければならない。
これは大量の書き込み処理を、短時間で行う
RDB の限界とクラウドの活用
必要があるということだ。加えて、通常の
(1)IoT とリレーショナルデータベースの相性
Web サイトであれば、ピーク時と平常時で
データストアの選択は、IoT システムを考
ある程度アクセスに波があるが、IoT システ
える上で非常に重要性が高い。
ムの場合は、モノの数だけ 24 時間 365 日、
Oracle Database を始めとするリレーショ
常に同じ量のアクセスがある。これは、見方
ナルデータベース(以下 RDB)は、高い対
を変えれば常に最大量のアクセスをさばき続
応力と信頼性を持つため、IoT システムにお
けなければならないということになる。従っ
いても、まずは従来通り RDB を中心に考え
て、サーバーサイドでは大量の書き込み処理
るのが一般的だろう。しかし、RDB はデー
を継続的に行える処理能力と安定性が求めら
タの整合性を保つことを目的としており、大
れる。
量かつ頻繁にデータを更新する処理には向い
次にデータストアでの「蓄積」だ。収集し
ていない。さらに、IoT システムでモノが収
たデータは、さまざまな分析を行うため、リ
集するデータはほとんどが時系列で蓄積され
アルタイムから年単位の過去データまで、柔
るが、RDB はこのような履歴データの扱い
軟にアクセスできる必要がある。さらに、
は苦手としている。また、IoT システムに求
データの内容だが、モノは 1 種類とは限らな
められる要件は実に多様であり、RDB に向
い。1つのシステムの中で数種類のモノが使わ
いていない多くの処理を行う必要があるた
れるのであれば、収集されるデータの種類や
め、大量のコンピュータリソースと繊細な設
データ構造も異なってくる。そのため、サー
計が必要になる。
バーサイドのデータストアでは、データに柔
RDB にこだわり過ぎると、RDB がボトル
軟にアクセスができるとともに、さまざまな
ネックとなり、システム全体の柔軟性が失わ
データ構造に対応できることも求められる。
れ る。IoT シ ス テ ム 構 築 を 考 え る 上 で は、
そして、
「分析」だ。分析にはリアルタイ
RDB にとらわれずに柔軟にデータストアを
ム性の高いものと、数ヶ月~数年単位の期間
をまとめてバッチで行うものがある。さら
に、目的に応じたアドホック(特定条件)分
選択し、設計していくことが肝要である。
(2)クラウドサービスの活用
ここで選択肢となるのが、Amazon Web
2016.09 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
19
トピックス
Services(米国 Amazon.com 社により提供さ
AWS IoT は、 そ の 名 の 通 り IoT の た め の
れているクラウドサービス。以下 AWS)を
サービスである。モノからのリクエストを受
はじめとするクラウドサービスの活用だ。ク
け、リクエストの内容に応じてさまざまなア
ラウドサービスでは、さまざまな技術が提供
ク シ ョ ン を 起 こ す こ と が で き る。 ま た、
されており、これらを利用することで、多く
AWS IoT は MQTT という双方向の通信を可
の選択肢の中から最適なシステム構築が可能
能とするプロトコルを利用することができ、
となる。具体的な例を見てみよう。
これによりモノ側へサーバーサイドから指令
を出すことができる。さらに、モノが現在接
AWS を利用した IoT システム構築
ど、モノの状態を可視化する機能もある。
主要なパブリッククラウドでは、IoT に必
モノから一方的にデータを送るだけであれ
要な技術がサービスとして既に提供されてい
ば Kinesis Stream を利用し、サーバーサイド
る。ここでは、NRI がプレミアムパートナー
からモノ側へも通信を行いたい場合は MQTT
となっている AWS を紹介する。
を扱える AWS IoT を利用する。この 2 つの
(1)データを収集するクラウドサービス
サービスはモノの数が数億あっても対応でき
まずは、モノからの大量のデータをいかに
るよう設計されており、非常に伸縮性・順応
して受け取るかというところだ。これには、
性が高い。大量のリクエストをいかにさばく
Amazon Kinesis Stream( 図 1 参 照。 以 下
かという問題は、これらのサービスを利用す
Kinesis Stream)
、 ま た は AWS IoT( 図 2 参
るだけで解決できてしまう。
照)が利用できる。
また、AWS IoT と Kinesis Stream を両方同
Kinesis Stream はストリーミングデータの
時に使うことも可能だ。その場合は AWS IoT
処理を行うためのサービスであり、簡単に言
でリクエストを受け、AWS IoT から Kinesis
えば、送信されたデータを一時的に保存して
Stream にデータを流す。Kinesis Stream に
くれる。Kinesis Stream に保存されたデータ
データを送信する前に何らかの処理を行いた
は、一定期間いつでも取り出すことができ
い場合は、このような構成も考えられるだろ
る。Kinesis Streamでデータを受け取った後、
う。ただし、AWS IoT は Kinesis Stream を単
別のアプリケーション(図 1 中の Consumer
体で使う場合に比べ、コストが高くつく傾向
部分)で Kinesis Stream からデータを取得し、
にある。コストとのバランスを見つつ選択す
リアルタイム分析やデータストアへの保存と
る必要がある。
いった処理をすることができる。アプリケー
ションが自らデータを取得するため、処理量
20
続されているかといった状態の参照や識別な
(2)データを蓄積・分析するデータストアの
選択
を調整でき、アプリケーション自身やデータ
次にデータストアの選択だ。目的に応じて
ストアに過度な負荷を与えることなく処理す
適したデータストアは異なる。大容量データ
ることが可能だ。
であればオブジェクトストレージ(記憶装置
| 2016.09
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
クラウドサービスが単なる仮想
Kinesis Stream を利用するパターン
サーバーサイド
AWS
データストア
S3
DynamoDB
Redshift
Consumer
モノ
図 2 AWS
は終わり、現在はさまざまなサー
フォームと化している。クラウド
サービスを利用することはシステ
Consumer
データ処理
マシンやストレージであった時代
ビスを内包した巨大なプラット
Consumer
Kinesis Stream
クラウドを活用したIo Tシステム設計
図 1 Amazon
ム開発の効率化やコストの削減だ
けではなく、今までは実現できな
RDS
かったことが、実現可能になると
Consumer:データ処理を行うプログラム
いうことでもある。
IoT を利用するパターン
サーバーサイド
IoT
アクション
HTTP
MQTT
AWS IoT
IoT ルール
IoT
S3
DynamoDB
Redshift
Kinesis
Stream
Consumer
最新の技術動向の把握が
IoT ビジネスのカギ
IoT のような新しいビジネスが
生まれるとき、同時にシステムの
アクション
MQTT
モノ
データストア
│ Io Tシステム構築におけるAWS活用の勘所 │
AWS
RDS
設計思想や実現方式も変化しなけ
ればならない。ビジネスとシステ
ムには密接な関わりがあり、ビジ
ネスの目的・規模によって最適な
の管理・利用方式の 1 つで大容量データの保
システム設計も変化する。ビジネスをデザイ
存に適している)、高速な読み書きが必要で
ンすることと同様に、ビジネスに適したシス
あれば NoSQL(Not only SQL)
、分析であれ
テムをデザインすることが重要である。だか
ばデータウェアハウス(膨大な量のデータを
らこそ、ビジネスを理解した上で、最新の技
時系列に蓄積可能でデータ分析に最適化され
術動向をつかみ、それを使って設計・構築・
ている)
、マスターデータなど整合性が重要
運用できるシステムアーキテクト(システム
であれば、従来通り RDB が適しており、こ
の要件定義や設計の知識や技能を持った上級
れらを使い分けることが必要になる。AWS
エンジニア)や、そのような人材を擁するパー
においては、それぞれのデータストアが以下
トナー企業の存在が不可欠となるだろう。
の通りサービスとして提供されている。
野村総合研究所(NRI)グループは、実際
・Amazon S3(オブジェクトストレージ)
に AWS を利用した IoT システムの設計・構
・DynamoDB(NoSQL)
築を行い、実運用に耐えうることを検証して
・Redshift(データウェアハウス)
きた。その知見を生かし、企業の IoT システ
・RDS(RDB)
など
ム設計をサポートしている。
2016.09 |
レポートに掲載されているあらゆる内容の無断転載・複製を禁じます。すべての内容は日本の著作権法及び国際条約により保護されています。
Copyright © 2015 Nomura Research Institute, Ltd. All rights reserved. No reproduction or republication without written permission.
■
21