トピックス クラウドを活用した 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
© Copyright 2025 ExpyDoc