IBM Developer Japan Webサイトは2021年3月15日をもって終了となり、日本語コンテンツの一部は、オープンソースとして、提供予定です。 URLはこちら

IoT データを理解する

モノのインターネットに接続されるモノの数が多くなれば多くなるほど、IoT デバイスによって生成されるデバイスのステータス・データ、メタデータ、センサー測定値などのテレメトリー・データを含むデータ量が指数関数的に増えてきます。例えば、監視システムでは、CCTV カメラの映像と各種センサーの測定値を使用して異常の有無を検出します。こうしたデータを管理してデータが持つ意味を理解しなければ、IoT ソリューションが価値をもたらすことはありません。

ほとんどの IoT システムでは、データ・アナリティクスの手法が不可欠となります。通常は、収集した IoT データをダッシュボード、レポート、可視化、アラートといった形に変換する必要があるためです。このような仕組みが有用な使用ケースは数え切れないほどあります。例えば、接続されたデバイスのステータスをモニタリングする、デバイスの測定値を人間が理解しやすい形式で表示する、パターンを識別する、異常を検出する、ルールに基づいてアクションをトリガーする、結果を予測するなどです。さらに、センサー・データに基づいてビジネス上の意思決定を行うこともできます。

この記事では、データの保管、データの処理と分析、ルールの適用を含め、IoT データに対処する手法をいくつか説明します。

データの保管

一般に、IoT デバイスはデータ・ストレージ機能が限られていたり、バッテリー駆動型であったり、公衆がアクセス可能なエリアにデプロイされたりします。そのため、IoT デバイスが取得した大量のデータは、MQTT や CoAP などの通信プロトコルを使用して IoT サービスに送信され、そのサービスに取り込まれて処理されてから、保管されることになります。IoT アプリや IoT サービスに保管されてアクセスされるデータは、これまでになく増えてきています。

保管された IoT データを管理する際の問題は、増加し続けるデータ量に対処することだけではありません。他にも以下のような懸念事項があります。

  • 種類がさまざまに異なるデータに対処する
  • データの出所を追跡しつつ、アナリティクスに使用できるようにデータを変換、集約、統合する
  • データをセキュリティーで保護してデータの整合性とプライバシーを確保する
  • ハイパフォーマンス、信頼性、柔軟性、スケーラビリティー、コストの釣り合いがとれるようなストレージ・テクノロジーを選択する

IoT データを保管する上でのヒントをご覧ください。

種類がさまざまに異なるデータ

IoT デバイスによってキャプチャーされるデータは、構造化データ、半構造化データ、非構造化データなど、さまざまなデータ形式で生成されます。こうしたデータには、アナログ信号、多様なセンサー測定値、デバイスの正常性に関するメタデータ、さらに画像または動画の大容量ファイルが含まれることもあります。IoT データは均一ではないため、IoT データの保管に関しては、あらゆる事態に対処できる 1 つの手法というものは存在しません。

データの変換

通常、データはデバイス上で、あるいは理想的にはデバイス・ゲートウェイで変換されて正規化されます。イベントを順不同で受信した場合は並び替えを行ったり、時間に制約のあるデータであれば古いデータを破棄したりする必要があるためです。

データを変換する時点で、データの場所とタイムスタンプに加えて、そのデータをキャプチャーしたセンサーに関する出所情報が追加されることもよくあります。ロー・データを保管しておくとデバッグや履歴分析に役立ちますが、データを前処理してから保管すれば、データを複数回分析しなければならない場合に、コストのかかる変換を繰り返さなくても済みます。

帯域幅とストレージのコストを節約するために、データを変換してから選択的にデータを送信して保管するようにしてください。

データのセキュリティー保護

データの整合性とプライバシーを確保するには、セキュア・プロトコルと暗号化を使用して安全にデータを送信および保管する必要があります。このようなセキュリティー手法をアーキテクチャーのすべてのレベルで適用して、どんな形でもシステム外部から機密情報にアクセスできないようにしなければなりません。詳しくは、IBM developerWorks の記事「ネットワーク上の IoT データをセキュリティーで保護する」をご覧ください。

データ・ストレージ戦略

データはオンプレミス上にもクラウド上のどこかにでも保管できます。あるいは、この 2 つを組み合わせたハイブリッド戦略に基づいて保管することもできます。適切なデータ・ストレージ戦略を決定する際に重要な考慮事項としては、データのボリューム、ネットワークへの接続、利用可能な電力が挙げられます。

例えば、飛行機は基地局との接続を常時維持できるわけではないため、極めて重要なデータをオンプレミスのストレージに保管するためのメカニズムが必要になります。同様に、電源供給に不安があるデバイスには、電源供給状態に戻った時点で、あるいは手作業でデバイスを作動状態に戻した時点で極めて重要なデータを復元するために、オンプレミスの不揮発性ストレージが必要です (フライト・レコーダーと同じことです)。自律走行車が年間で生成するデータはペタバイト規模に上ることもあるので、すべてのデータをリアルタイムでクラウドに転送することはできそうにありません。一方、常に接続と電源を維持できる温度センサーのようなデバイスは、すべてのデータをクラウドに保管することができます。このようなデバイスにオンプレミスのストレージが必要になることはありません。

データにはさまざまに異なる目的がある点も考慮する必要があります。リアルタイムのアナリティクスではなくアーカイブを目的としたデータは、後に採用されるであろうアナリティクスの手法を補完する別の手法を使って保管することができます。その場合、データ・アクセスは迅速であり、各種のリアルタイムのデータ・アナリティクスに対応したクエリーを実行できる必要があります。

また、「エッジ・コンピューティング」によって、クラウドにデータをプッシュする前に、オンプレミスで前処理の負担を減らすという傾向も現れています。

データ・ストレージ手法

デバイスやゲートウェイ上で処理されるデータをエッジで一時的に保管するために使用するデータ・ストレージ手法は、(デバイスが設置される厳しい動作環境にも耐えるために) 物理的に堅牢でなければなりません。それと同時に、データを上流に送信する前に迅速かつ正確に前処理を行えるよう、速度と信頼性にも優れている必要があります。デバイスのデータ・ストレージでは、3DxPoint や ReRAM など次世代の不揮発性 RAM (NVRAM) を利用できます。これらの NVRAM テクノロジーは、NAND フラッシュよりも 1000 倍の速度でありながらも、DRAM ほど電力を消費しません。

リアルタイム・アナリティクスのようなアプリケーションで採用するストレージ・テクノロジーに求められる特性としては、同時読み取り/書き込み処理をサポートすること、高可用性であること、データ・アクセスとクエリーのパフォーマンスを最適化するために構成できるインデックスを使用していることが挙げられます。

膨大な量になるアーカイブ・データは、クラウド・ストレージ上で保管できます。クラウド・ストレージはアクセス速度の点では劣るかもしれませんが、コストが低く、しかもデータ量の増加に応じて柔軟にスケーリングするという利点があります。動画などの大容量ファイル形式のデータには一般に順次アクセスすることになりますが、こうしたデータはオブジェクト・ストレージ (Swift として知られている OpenStack Object Storage など) に保管できます。あるいは、Hadoop HDFS や IBM GPFS などの分散型ファイル・システムに直接書き込むこともできます。分散型ストレージに保管されるデータの読み取り、書き込み、アクセスを管理するには、Apache Hive のようなデータウェアハウス・ツールを利用できます。

IoT イベント・データによく採用されているデータ・ストレージ手法には、NoSQL データベースと時系列データベースの 2 つがあります。

  • NoSQL データベース: アナリティクスに使用する IoT データには、一般的にこのデータベースが選ばれています。その理由は、高スループットと低レイテンシーの実現を支援し、柔軟なスキーマレス手法で新しいタイプのデータを動的に追加できるためです。IoT データに使用されているオープンソースの NoSQL データベースには、CouchbaseApache CassandraApache CouchDBMongoDBApache HBase (Hadoop 用の NoSQL データベース) などがあります。ホスト型の NoSQL クラウド・ストレージ・ソリューションには、IBM の Cloudant データベースと AWS DynamoDB などがあります。
  • 時系列データベース: 時系列データベースは、リレーショナル・データベースまたは NoSQL 手法に基づくデータベースの場合があります。時系列データベースは時間ベースのデータのインデックス付けとクエリーを対象に設計されているため、本質的に経時的な IoT センサー・データのほとんどに理想的な選択です。IoT データに使用されている時系列データベースには、InfluxDBOpenTSBRiakPrometheusGraphite などがあります。

Apache Cassandra について詳しくは、チュートリアル「Set up a basic Apache Cassandra architecture」をご覧ください。

データの分析

IoT データを有効利用するには分析が必要になりますが、IoT デバイスによって生成される大量のデータを手作業で処理するのは実際的ではありません。そこで、ほとんどの IoT ソリューションでは自動化されたアナリティクスに依存することになります。アナリティクス・ツールをテレメトリー・データに適用して、記述的なレポートを生成したり、ダッシュボードとデータ視覚化によってデータを表示したり、アラートとアクションをトリガーしたりするといった仕組みです。

IoT ソリューションでの IoT データの処理とアナリティクスには、多種多様なオープンソースのアナリティクス・フレームワークまたは IoT プラットフォームを使用できます。こうしたアナリティクスでは、受信したデータをリアルタイムで分析するか、履歴データをバッチ処理して分析することができます。アナリティクスの手法には、分散型アナリティクス、リアルタイム・アナリティクス、エッジ・アナリティクス、機械学習があります。

分散型アナリティクス

IoT システムで大規模にデータを分析するには、分散型アナリティクスの手法を採用する必要があります。特に、単一のノードで保管または処理しきれない膨大な履歴データに対処する場合は、分散型アナリティクスが必須となります。分散型アナリティクスでは、データを複数のデータベースに分散することができます。例えば、Cloudant NoSQL データベースに接続して IoT データを保管する、IBM Watson IoT の Historian Service のように、1 時間、1 日、または 1 か月などの一定の期間を単位として、デバイス別のデータベースにデバイス・データを分類して保管することもできます。アナリティクスには、複数の地理的位置に分散された結果を集約する処理が必要になることもあります。その場合、分散型ストレージとコンピューティング・インフラストラクチャーの橋渡しになって、分散データベースに対してシームレスなクエリーの実行を可能にする、ストレージ・ドライバーあるいはアナリティクス・フレームワークを採用する必要があります。

分散データを処理する際に特に注目すべき点は、Hadoop コミュニティーから誕生したフレームワークのエコシステムです。Apache Hadoop はバッチ処理フレームワークとして、MapReduce エンジンを使用して分散データを処理します。Hadoop の成熟度は高く、いち早くビッグデータ・アナリティクスに取り掛かったオープンソース・フレームワークの 1 つです。後には、Hadoop の欠点のいくつかを改善することを目的に、Apache Spark も登場しました。

Hadoop と Spark は、IoT の履歴データをバッチ処理してアナリティクスを行うには理想的なフレームワークです。例えば、完全なデータ・セットが揃ってからデータの分析を行って結果を出すような、時間感度が重要にならないアナリティクスに使用するには、Hadoop や Spark をお勧めします。

リアルタイム・アナリティクス

大量の IoT データ・ストリームを対象としたアナリティクスは、通常はリアルタイムで行われます。特に、データ・ストリームに時間に依存するデータが含まれている場合、データをバッチで処理するのでは有用な結果を生成するには遅すぎます。また、レイテンシーが懸念事項となるアプリケーションでもリアルタイム・アナリティクスが必要になります。

リアルタイム・アナリティクスは、時系列のデータにも理想的な手法になります。バッチ処理とは異なり、リアルタイム・アナリティクス・ツールでは一般に時間枠での分析の制御やローリング・メトリクスの計算をサポートしているため、データ・セット全体での 1 つの平均値を計算するのではなく、例えば 1 時間ごとの平均値を追跡することができます。

リアルタイムのストリーム・アナリティクスを対象に設計されているフレームワークとしては、Apache StormApache Samza (通常は Kafka と Hadoop YARN で使用されます) が挙げられます。ストリーム・アナリティクスとバッチ・アナリティクスのどちらにも使用できるハイブリッド・エンジンには、Apache ApexApache SparkApache Flink などがあります。データ取り込み層として機能する Apache Kafka は、Spark、Storm、Hadoop などのエンジンで利用できます。これらのオープンソース・フレームワークの中から選択する際のガイドとしては、「Choosing the right platform for high-performance, cost-effective stream processing applications」をご覧ください。

エッジ・アナリティクス

IoT アナリティクスは一般にデバイスのロー・データには適用されません。分析の前に、重複を除去したり再配列したりするためにデータが前処理されるか、集約あるいは正規化されます。通常は、データの取得時にこのプロセスが IoT デバイス自体上で行われるか、データを集約するゲートウェイ・デバイス上で行われて、上流に送信する必要があるデータが判断されます。

データを収集するデバイスに可能な限り近い、ネットワークのエッジで適用するアナリティクスは、エッジ・アナリティクスと呼ばれます。Linux Foundation の EdgeX Foundry というオープンソースの IoT エッジ・コンピューティング・フレームワークは、エッジ・アナリティクスもサポートします。

エッジ・アナリティクスはレイテンシーが低く、帯域幅の要件を軽減します。それは、デバイスから大量のデータを送信する必要がないためです。ただし、制約の多いデバイスに備わっている処理能力は限られていることから、ほとんどの IoT ソリューションではエッジ・アナリティクスと上流のアナリティクスを組み合わせたハイブリッド手法を採用しています。

機械学習

従来型の数理統計モデルをアナリティクスに適用するとなぜ価値がもたらされるのかと言えば、目標の追跡、レポートの作成、洞察の抽出、傾向の予測、さらには特定の結果を求めて予測および最適化を行うために使用できるシミュレーションの作成が可能になるためです。例えば、特定のアクションを適用した場合の結果や、特定の機器が故障するまでの時間を予測できます。また、コストまたはパフォーマンスという点で IoT システムの構成を最適化することもできます。

ただし、時間が経つにつれて変化する変数が数多く含まれる動的データに適用する場合や、探している因子がわからなかったり、コストの削減や効率性の改善といった目的の結果を達成するために変更すべき変数がわからなかったりする場合、統計的分析モデルの価値は損なわれてしまいます。そのような場合は、統計モデルを使用するのではなく、データから学習する機械学習アルゴリズムを適用できます。

機械学習は履歴データにもリアルタイム・データにも適用できます。機械学習の手法を使用すれば、パターン、重要な変数、変数の間に存在する関係を識別して自動的に分析モデルを作成し、そのモデルを改善してからシミュレーションや意思決定に使用することができます。静的な統計分析モデルに勝る機械学習の手法の利点は、新しいデータを取り込みながらモデルを徐々に改善して、結果の改善につなげられるところにあります。

最先端の機械学習手法は主として、ニューラル・ネットワーク (畳み込みニューラル・ネットワーク、長・短期記憶ネットワーク) を使用する深層学習の分野で登場しています。将来有望な新しい研究分野には、能動学習、マルチモーダル学習とマルチタスク学習、Transformer ベースの言語モデルなどがありますが、そうは言っても、回帰、サポート・ベクター・マシン、デシジョン・ツリーなどの従来型の機械学習手法が今でも有効であることは、多くのアプリケーションで証明できます。

IoT に使用できるスタンドアロンのオープンソース深層学習フレームワークには、TensorFlowPyTorchTheano、Cognitive Toolkit CNTK などがあります。Apache Spark をベースに実行できる、H20 および DeepLearning4J という深層学習エンジンや SystemML といった機械学習ツールもあります。

ルールを適用してデータに対するアクションを実行する

ルール・エンジンは、アナリティクスによって IoT データから引き出された洞察を使用して、正確で繰り返し可能な決定を行います。IoT を対象にルールを実装するには、さまざまな手法があります。

  • デシジョン・ツリー: ツリー (グラフ・ベースの階層構造) を使用して決定点を表します。ツリー構造内の各リーフが特定の 1 つの決定に対応します。

追跡可能な変数の状態の数が増えるにつれ、デシジョン・ツリーは指数関数的に大きくなっていきます。

  • データ・フロー・グラフ: データ・フロー・グラフ (パイプとも呼ばれます) は、データの依存関係と関数間のフローを表すために使用されます。データ・フロー・グラフをベースに作成されているフレームワークの一例は、TensorFlow です。
  • 複合イベント処理 (CEP): 時系列データの処理によく使用されている CEP は、リアルタイムのセンサー・データにルールを適用する場合に最適です。
  • 推論エンジン: If-then スタイルのルールを実装します。
  • ビジネス・プロセス・マネジメント: 従来型の BPM システムのコンテキストでは多くの場合、ルールはデシジョン・テーブルとして実装されます。

エンジンの実装とは関係なく、ルールにはアクションをトリガーするために使用する条件をエンコードします。これらのアクションで、問題の回避、パフォーマンスの最大化、あるいはコストの最適化を目的に自律的にシステムを調整します。

オープンソースのアナリティクスとルール・エンジンは自己管理可能ですが、多くの IoT プラットフォームでは、IBM の Analytics for Apache Spark など、オープンソースのオファリングをベースとしたホスト型のアナリティクスおよびルール・ソリューションを提供しています。また IoT プラットフォームには、通常はカスタムの統合アナリティクス・ソリューションが組み込まれており、バッチ・アナリティクスとリアルタイム・アナリティクスの両方に加え、機械学習とルールのソリューションも組み込まれています。

まとめ

この記事では、データの管理、アナリティクスによる洞察の抽出、ルールを適用したアクションの実行を含め、IoT データが持つ意味を理解するためのツールと手法の概要を説明しました。

例えばコネクテッド・シティーなどの大規模で複雑な IoT システムを管理するには、IoT データ・アナリティクスが不可欠です。データ・アナリティクスを使用して需要を予測し、その予測に応答してルールを適用することで、例えば適応型交通信号を制御したり、スマート照明を管理したりするなどしてサービスを調整します。

小規模な IoT システムでも、IoT データ・アナリティクスによって効率性が向上します。例えば、一連の産業機器自動車のメンテナンスを行う場合、資産に取り付けたセンサーのデータを使用して、点検が必要になる時期を予測し、その予測に基づいて最適な時点でメンテナンスをスケジューリングすれば、機器や自動車の信頼性が向上すると同時に、不要なメンテナンス費用の節約、ダウンタイムの削減、生産性低下の回避を実現できます。