モノのインターネットの概要

モノのインターネット(IoT)は、明確な単一の定義を持たない技術やユースケースの膨大な集まりです。ひとつの見解としてですが、物理環境に組み込まれたネットワーク接続デバイスを使用して、既存のプロセスの一部を改善したり、これまでは不可能だった新しいシナリオを可能にしたりすることを IoT と定義しています。

これらのデバイス、つまり「モノ」は、ネットワークに接続して、センサーを通して環境から収集した情報を提供したり、他のシステムがアクチュエータを通して世界に接触して作用できるようにしたりします。モノは、すでに精通している一般的なモノの接続されたバージョンにすることも、まだ実現されていない機能のための新しい専用デバイスにすることもできます。また、個人的に所有して身に付けたり、自宅に設置したりするデバイスにすることも、工場設備や住んでいる都市のファブリックの一部に組み込むこともできます。それぞれは現実世界の貴重な情報をデジタルデータに変換し、これによってユーザーは製品、サービス、またはアプリケーションと相互作用する方法を視覚的にわかりやすくすることができます。

さまざまな業種で具体的なユースケースや機会が数多く存在しますが、いろいろな意味で、IoT の世界は始まったばかりです。これらのシナリオからは、共通の課題やパターンが見えてきます。IoT プロジェクトは、次のような、他のクラウド中心の技術アプリケーションと比較した場合に、その複雑さが増す新たな特徴を備えています。

  • 多様なハードウェア
  • デバイス上の多様なオペレーティング システムとソフトウェア
  • さまざまなネットワーク ゲートウェイ要件

このガイドでは、Google Cloud Platform と組み合わせることによって、Cloud Platform 上で堅牢で維持可能なエンドツーエンドの IoT ソリューションを構築することができる要素について説明します。

トップレベル コンポーネントの概要

ここでは、システムを 3 つの基本的なコンポーネント(デバイス、ゲートウェイ、クラウド)に分けて説明します。

3 つのコンポーネント

デバイスには、世界と直接相互作用するハードウェアとソフトウェアが含まれます。デバイスは、相互に通信するためのネットワークまたは集中型アプリケーションに接続します。インターネットに直接的または間接的に接続される場合もあります。

ゲートウェイは、インターネットに直接接続されていないデバイスをクラウド サービスに到達できるようにします。ゲートウェイという用語は、ネットワーキングにおいて特定の役割を果たしますが、デバイスのグループまたはクラスタの代わりにデータを処理するデバイスのクラスを記述するためにも使用されます。各デバイスからのデータが Cloud Platform に送信され、そこで処理され、他のデバイスからのデータや場合によっては他のビジネス トランザクション データと結合されます。

情報の種類

各デバイスは、さまざまな種類の情報を提供または使用することができます。情報はその形態ごとに異なるバックエンド システムによって最適に処理され、システムごとにデータレート、ボリューム、および望ましい API を中心として特化する必要があります。このセクションでは、IoT シナリオで見られる情報の一般的なカテゴリを列挙して説明します。

デバイス メタデータ

メタデータにはデバイスに関する情報が格納されています。ほとんどのメタデータが不変か、めったに変化しません。メタデータ フィールドの例を以下に示します。

  • 識別子(ID) - デバイスを一意に識別する識別子。デバイス ID は、デプロイ済みのデバイスの存続期間中は変更しないでください。
  • クラスまたは型
  • モデル
  • リビジョン
  • 製造日
  • ハードウェア シリアル番号

状態情報

状態情報は、環境のではなく、デバイスの現在のステータスを記述したものです。この情報は読み取り / 書き込みが可能です。また、それほど頻繁ではありませんが、更新されます。

テレメトリー

デバイスによって収集されたデータは「テレメトリー」と呼ばれます。これは、IoT デバイスからアプリケーションに提供される情報源データです。テレメトリーは、センサーを介して収集されることが多い、環境に関する読み取り専用データです。

テレメトリーの各ソースがチャネルになります。テレメトリー データは、デバイス上またはクラウド内のステートフル変数として保存することができます。

各デバイスは 1 分ごとにデータポイントを 1 つだけ送信しますが、大量のデバイスからのデータを処理しなければならない場合は、すぐにでもビッグデータの戦略とパターンを適用する必要があります。

コマンド

コマンドは、デバイスによって実行されるアクションです。コマンドの多くが、実装で利用可能な選択肢を制限する特性を持っています。これらの特性を以下に示します。

  • コマンドは状態データとして簡単に表現できません。

  • コマンドの多くがべき等ではありません。そのため、メッセージが重複するとたいていは別の結果が生成されます。メッセージング システムと同様に、コマンド機能の実装によって「1 回以上」や「1 回だけ」などの配信セマンティクスが決定されます。コマンド メカニズムは、戻り値を含めることも、個別の返信メッセージを介してまたは状態データの予想される変化を反映することによって行われる確認に依存することもできます。

  • コマンドの関連性は時間的に限られていることもあるため、コマンドには有効期間(TTL)またはその他の失効値を含める必要があります。

コマンドの例を以下に示します。

  • 右に 360 度回転させる。
  • セルフ クリーニング サイクルを実行する。
  • 速度を 10% 増加させる。

オペレーション情報

オペレーション情報は、ビジネス アプリケーションとは対照的に、デバイスの動作に最も関連するデータです。これには、CPU の動作温度やバッテリーの状態などが含まれます。この種のデータには、長期間の分析値が含まれていることはあまりありませんが、破損への対応や更新後のソフトウェアの性能低下の修正などの動作状態の維持を支援する短期間の値が含まれています。

オペレーション情報は、テレメトリーまたは状態データとして送信することができます。

デバイス

デバイスを構成するものは必ずしも明確ではありません。物理的なものの多くがモジュール式です。これは、マシン全体がデバイスなのか、各モジュールが個別のデバイスなのかを判断するのが難しい場合があることを意味します。この疑問に対する正しい答えは 1 つとは限りません。IoT プロジェクトを設計する際は、設計に含まれるさまざまなレベルの抽象化を考慮し、物理的なものとそれらの相互関係をどのように表現するかを決定する必要があります。アプリケーションに固有の要件が、情報を生成するものをデバイスと見なして個別の ID を付与するべきか、単に他のデバイスのチャネルまたは状態の詳細とするかの判断に役立ちます。

たとえば、ホテル内の部屋の温度を監視するという目標が設定されたプロジェクトを考えます。各部屋に、3 つのセンサーが取り付けられているとします。1 つはドア側の床に、1 つは天井に、もう 1 つはベッドの横に取り付けられています。このセットアップは、各センサーをデバイスとして表現することによってモデル化することができます。

{deviceID: "dh28dslkja", "location": "floor", "room": 128, "temp": 22 }
{deviceID: "8d3kiuhs8a", "location": "ceiling", "room": 128, "temp": 24 }
{deviceID: "kd8s8hh3o", "location": "bedside", "room": 128, "temp": 23 }

部屋全体を 1 つのデバイスとしてモデル化することもできます。部屋をデバイスと見なすことはあまりありませんが、IoT では、1 つの単位として管理、記録できるものがデバイスとして抽象化されます。デバイスという言葉は必ずしも、手で持つことができるデバイスを意味するとは限りません。このように考えると、次の 3 つのセンサーを含むデバイスとしてホテルの部屋をモデル化することができます。

{deviceID: "dh28dslkja", "room": 128, "temp_floor": 22, "temp_ceiling": 24, "temp_bedside": 23, "average_temp":  23 }

目標によっては、この 2 つのデータ表現の一方が他方より適切な場合があります。2 つ目の例の平均温度フィールドに注目してください。これがホテルに必要なものかもしれません。各センサーからのメタデータがそのままで最も価値があるか、それとも、メタデータの個別の部分が部屋全体に適用される意味を持っているか。部屋がスイートで、3 か所がバスルーム、ラウンジ、ベッドルームの場合はどうなるか。これらは、データをモデル化する方法を決定する場合に自問すべき質問の一例です。接続されたアプリケーションのドメインモデルは、デバイスを構成するものの正確な境界を定義します。

デバイスのハードウェア

ハードウェアを選択する場合の一般的な留意点

ハードウェアを選択する場合は、ハードウェアのデプロイ方法の影響を受ける次の要因を考慮してください。

  • 費用。データの価値がわかっている場合は、各デバイスに支援可能な費用について検討します。
  • I/O の役割。デバイスは、主に、センサー、アクチュエータ、または 2 つの役割の特定の組み合わせです。
  • 電力予算。デバイスが電源にアクセスできる場合もあれば、電力が不足している場合もあります。デバイスにバッテリーが必要か、太陽光発電が必要かを検討します。
  • ネットワーキング環境。デバイスが TCP/IP ルータブルとしてインターネットに直接接続できるかどうかを検討します。セルラーなど、接続の種類によっては、高トラフィックで高価な場合があります。ネットワークの信頼性と、遅延やスループットに対するその信頼性の影響について検討します。それがワイヤレスの場合は、送信電力で実現される範囲と、追加のエネルギー費用を検討します。

機能的な入力と出力

現実世界と相互作用するために使用されるデバイスは、センサー入力やアクチュエータ出力を可能にする、コンポーネントが組み込まれていたり、周辺機器に接続されたりします。これらのハードウェア I/O コンポーネントのために選択する特定のハードウェアは、機能要件に基づいている必要があります。たとえば、検出する必要がある動きの感度や複雑さによって、選択する加速度計の種類や代わりにジャイロが必要かどうかが決定されます。ガス検知を行う場合は、センサーで正確に検出可能なガスの種類が問題になります。デバイスを使用して出力を生成する場合は、ブザーの音量、モーターの回転速度、リレーの作動電流などの要件を考慮する必要があります。

環境性能によって決定される要件に加えて、これらの I/O コンポーネントや周辺機器の選択が、関連付けられた情報の種類の影響を受ける場合もあります。たとえば、マイクはテレメトリーとして送信することが最適な周波数に基づいてデータを確実にサンプリングしながら、ステッピング モーターをデバイス状態データで表現可能な特定の方向に設定することができます。これらのコンポーネントは、ハードウェア インターフェースを介してデバイスの論理システムに接続されます。

デバイスのプラットフォーム

IoT アプリケーションを構築するために利用可能なハードウェアは多様性に富んでいます。この多様性は、まず、ハードウェア プラットフォームのオプションに見られます。プラットフォームの一般的な例には、シングルボード コンピュータ(BeagleboneRaspberry Pi など)の他にマイクロコントローラ プラットフォーム(Arduino シリーズParticle 製のボード、Adafruit Feather など)があります。

これらのプラットフォームのそれぞれで、ハードウェア インターフェースを介して、複数種類のセンサー モジュールとアクチュエータ モジュールを接続することができます。

これらのプラットフォームは、汎用コンピューティングで使用されているものと同様の階層化されたアプローチを使用してモジュールとインターフェースします。ごく一般的なパソコンのマウスを想定している場合は、周辺機器、インターフェース、ドライバ、アプリケーションのレイヤを検討することができます。Linux や Windows などの標準的なオペレーティング システムでは、ハードウェア入力がドライバによって解釈されます。ドライバは、OS サービスに依存しており、カーネルの一部になっている場合もあります。簡単にするために、次の図ではオペレーティング システムが省略されています。

3 つのコンポーネント

ハードウェア インターフェース

ほとんどのハードウェア インターフェースがシリアル インターフェースです。シリアル インターフェースは、一般的に、複数の回線を使用して、プライマリ データ回線上のバイナリ情報のフローとタイミングを制御します。ハードウェア インターフェースの各タイプは、周辺機器と中央処理装置間の通信手段を定義します。

IoT ハードウェア プラットフォームは、複数の一般的なインターフェースを使用します。センサー モジュールとアクチュエータ モジュールは、次のインターフェースの 1 つ以上をサポートできます。

  • USB。ユニバーサル シリアルバスは、多種多様なプラグアンドプレイ対応デバイスに広く使用されています。
  • GPIO。汎用入力/出力ピンは、直接プロセッサに接続されます。その名前が示すように、これらのピンは、メーカーが設計していないカスタム使用シナリオを可能にするために、メーカーから提供されます。GPIO ピンは、デジタル信号またはアナログ信号を伝送するように設計できます。また、デジタルピンには HIGH か LOW の 2 つの状態しかありません。

    デジタル GPIO は、パルス幅変調(PWM)をサポートできます。PWM を使用すれば、電源のオン/オフを瞬時に切り替えることによって、「オン」のときに特定の期間または幅のパルスを出力することができます。デバイス内の効果は、より低い電力レベルにすることも、より高い電力レベルにすることもできます。たとえば、PWM を使用して LED の明るさを変更することができます。「オン」のパルス幅を広げるほど、LED が明るく点灯します。

    アナログピンは、オンボードのアナログ-デジタル変換(ADC)回路にアクセスできます。ADC は、アナログ音声信号などの連続するアナログ波形を定期的にサンプリングします。毎回、システム電圧を基準にした 0 と 1 の間のデジタル値がサンプリングされます。

    デジタル I/O ピンの値をコードで読み取る場合は、値を HIGH か LOW のどちらかにする必要があります。特定の時点のアナログ入力ピンは、範囲内の任意の値になる可能性があります。この範囲は、ADC の分解能によって異なります。たとえば、8 ビットの ADC は 0~255 のデジタル値を生成できるのに対して、10 ビットの ADC はより広い 0~1,024 の値の範囲を生成できます。値が大きいほど、分解能が高い、つまり、特定のアナログ信号のより信頼できるデジタル表現であることを意味します。

    ADC のサンプリング レートは、ADC が再現可能な周波数範囲を決定します。サンプリング レートが高いほど、デジタルデータ内の最大周波数が高くなります。たとえば、44,100 Hz でサンプリングされた音声信号は、標準的なフィルタリングやその他の処理を無視しながら、最大 22.5 kHz の周波数応答でデジタル音声ファイルを生成します。ビット精度は、信号の振幅の分解能を表します。

  • I2C。集積回路間シリアルバスは、バス上で複数のモジュールに別々のアドレスを割り当てることが可能なプロトコルを使用します。I2C は、「アイツーシー」、「アイアイシー」、または「アイ スクウェア シー」と発音されます。

  • SPI。シリアル ペリフェラル インターフェース バスデバイスは、単一のマスターと全二重通信を使用したマスター / スレーブ アーキテクチャを採用しています。SPI は、次の 4 つの論理信号を規定しています。

    • SCLK: マスターから出力されるシリアル クロック
    • MOSI: マスターから出力されるマスター出力スレーブ入力
    • MISO: スレーブから出力されるマスター入力スレーブ出力
    • SS: マスターからのアクティブロー信号出力であるスレーブ選択
  • UART。万能非同期送受信機デバイスは、データがプロセッサ上で処理された時点で、シリアル形式とパラレル形式間でデータを変換します。シリアルデータをパラレル形式でメモリ内に配置する必要がある場合に UART が必要です。

ソフトウェアでのハードウェアの抽象化

オペレーティング システムは、メモリやファイル I/O などの一般的なコンピューティング リソースを抽象化します。また、OS は、さまざまなハードウェア インターフェースを非常に低いレベルでサポートします。一般に、これらの抽象化を直接使用するのは容易なことではないうえ、多くの場合、OS は、IoT ソリューションの構築時によく見られるさまざまなセンサー モジュールとアクチュエータ モジュールの抽象化を提供しません。

プラットフォーム間のハードウェア インターフェースを抽象化するライブラリを利用することができます。これらのライブラリは、モーション検出器などのデバイスとより簡単な方法で連動できるようにします。ライブラリを使用すれば、ハードウェアを直接操作して低レベルの詳細を取得する代わりに、モジュールからアプリケーションに提供される情報を収集することに集中することができます。

一部のライブラリは、ハードウェア インターフェース上の軽量ドライバの形式で周辺機器を表現する抽象化を提供します。このようなライブラリの例としては、Johnny-Five JavaScript フレームワーク、MRAA(複数の言語をサポート)、EMBD Go ライブラリ、Arduino-wiringFirmata などがあります。

コンピューティング環境

お使いのプラットフォームのコンピューティング環境がソフトウェアを実行します。ハードウェアの電力と費用の制限によって、プロセッサの機能が異なります。一部のコンピューティング環境は、組み込み Linux オペレーティング システムをサポート可能なチップ(SOC)上の完全なシステムで構成されています。マイクロコントローラベースのデバイスはより制約が大きく、アプリケーション コードを、オペレーティング システムのサポートなしでプロセッサ上で直接実行することができます。

このようなコンピューティング環境は、アプリケーション コードのロジックとプラットフォームの物理ハードウェアの橋渡しになります。コンピューティング環境で実行されるソフトウェアは、起動中に、読み取り専用メモリ(ROM)から完全に読み込まれます。環境自体が段階的な起動プロセスで構成されている場合もあります。このプロセスは、ROM からブートローダーと呼ばれる小さなプログラムを読み込んでから、オンボード フラッシュまたは接続された SD カードからオペレーティング システム全体を読み込みます。

デバイス上の処理

データがセンサーから収集されたら、デバイスは、データをクラウドに送信する前に、データ処理機能を提供することができます。複数のデバイスが、クラウドに到達する前にデータを処理して、個別に一定量の処理をこなすこともあります。

処理には以下が含まれます。

  • データを別の形式に変換する
  • データを安全な方法でパッケージ化して、実用的なバッチにまとめる
  • データを検証して一連のルールを満たしていることを確認する
  • データを望ましい順番に並べ替える
  • データを拡張して中心的価値に追加の関連情報を付加する
  • データを要約して容量を削減し、不要なまたは無用な詳細を除去する
  • データを集計値にまとめる

デバイス上の分析は、複数の処理タスクを組み合わせることによって、より多くの情報をより小さなデータ フットプリントで送信できるようにする中間合成解釈を提供することができます。

3 つのコンポーネント

デバイス管理

デバイス管理は、他の IT 資産管理に似ており、主な課題は、デバイスのプロビジョニング、オペレーション、更新です。これらの課題は、ゲートウェイを含むすべてのデバイスに適用されます。

プロビジョニング

プロビジョニングは、新しいデバイスをセットアップして使用できる状態にするプロセスです。プロビジョニングには以下が含まれます。

  • 基本的なデバイス情報での起動。デバイスは、最低でも ID と基本的なメタデータを必要とします。
  • セキュアな通信に必要な認証情報と認証。たとえば、継続的な通信に使用できるトークンまたはキーをデバイスに提供できます。このような認証情報には、有効期限が設定される場合があります。
  • デバイスの承認。承認は、上記の認証情報を使用して、デバイスがアプリケーションまたは他のサービスと相互作用するための権限を設定します。承認は、デバイスが使用できる特定のリソースに対する、デバイス ID と認証情報に固有の権限です。
  • ネットワーク接続のセットアップ。デバイスは、他のサービスと通信してデータを送信可能なネットワーク接続を必要とします。
  • デバイスの登録。アプリケーションは、使用可能なデバイスを認識している必要があります。使用中のデバイスはデバイス レジストリに記録されます。このデバイス レジストリにより、クラウド側の認証が管理され、デバイスが特定のデータとリソース(テレメトリーのトピックや状態ストレージなど)に関連付けられます。

運用

IoT システムを日常的に動作させるためには、何が起こっているかに関する正確な情報を収集する必要があります。IT ハードウェア デプロイと同様に、ダッシュボードとアラート メカニズムを通したさまざまなイベントのロギングや主要ステータス指標のモニタリングがモノのスムーズな運用を支援します。Cloud Platform は、日常業務に有効活用可能な機能を提供します。

  • Stackdriver Logging がログを収集して保存します。重要なデバイス ライフサイクル イベントは監査目的で記録されます。テレメトリー イベントのサブセットは、分析やレポート作成のために Stackdriver Logging に中継できます。Stackdriver Logging を使用すると、カスタム ロギング ソリューションを構築する場合と比べて、多くの時間と労力を節約できます。

Over-The-Air 更新

標準的な IoT デプロイの大きさは、サイト上での個々のデバイスの更新が現実的ではないことを意味します。デバイスには、すでに、設計時点でなんらかのネットワーク接続が組み込まれているため、ネットワーク経由で更新を push することにより、デバイスの更新を容易にすることができます。携帯電話用語では、Over-The-Air(OTA)更新ですが、同じ考え方が IoT にも当てはまります。次のようなオプションがあります。

  • Android Things: Android-Things ベースのハードウェアを使用する場合は、OTA 更新が組み込まれています。
  • Cloud Platform 上での独自の Debian パッケージ リポジトリ(APT)のセットアップ。
  • Resin.ioYocto Project に基づく Resin.io を使用すれば、Docker や git などの使い慣れたツールを使用して、コンテナ イメージの更新を push することができます。

ゲートウェイ

ゲートウェイは、異なるプロトコルを使用しているネットワーク間のトラフィックを管理します。また、ゲートウェイは、プロトコル変換やその他の相互運用タスクを担当します。IoT ゲートウェイ デバイスは、デバイスとクラウド間の接続と変換を可能にするために採用されることがあります。一部のデバイスにはインターネット接続に必要なネットワーク スタックが含まれていないため、ゲートウェイ デバイスが、デバイスからデータを受信し、それを TCP/IP 経由で送信するためにパッケージ化するプロキシとして機能します。

デプロイに含まれているデバイスが次の状態の場合は、専用のゲートウェイ デバイスが要件になることがあります。

  • Bluetooth デバイスなどのインターネットにルーティング可能な接続がない。
  • トランスポート層セキュリティ(TLS)に必要な処理機能がないため、Google API と通信できない。
  • 必要なネットワーク送信を実行するための電力が足りない。

ゲートウェイ デバイスは、参加デバイスがそれなしで通信可能な場合でも使用されることがあります。このシナリオでは、ゲートウェイがクラウドに送信される前のデータを複数のデバイス上で処理することによって価値を提供します。この場合の直接入力は、個々のセンサーではなく、他のデバイスです。以下のタスクがゲートウェイ デバイスに任される可能性があります。

  • 単一のリンク経由でクラウドに送信可能な量を最大化するためにデータを凝縮する。
  • クラウドへの接続が一時的に中断されたときにデータをローカル データベースに保存してから、転送する。
  • タイムスタンプをうまく管理または同期できないデバイスに、一貫したタイムスタンプを提供するためのバッテリー バックアップ付きのリアルタイム クロックを提供する。
  • IPV6 から IPV4 への変換を実行する。
  • 関連性があるうえ、IoT データに関連付けられた他のフラットファイルベースの IoT データをローカル ネットワークから取り込んでアップロードする。
  • ファームウェア更新用のローカル キャッシュとして機能する。

Cloud Platform

IoT プロジェクトが稼働すると、多数のデバイスが大量のデータを生成し始めます。これらのデバイスを管理し、そのすべての情報を処理して使えるようにするためには、効率性とスケーラビリティに優れ、しかも安価な方法が必要です。データ、特に、ビッグデータの保存、処理、分析となると、クラウド以外は考えられません。

次の図は、Cloud Platform での IoT データ管理のさまざまなステージを示しています。

3 つのコンポーネント

デバイス管理

IoT Core デバイス マネージャー

Google Cloud IoT Core は、デバイス管理を目的としたフルマネージドのサービスを提供します。このサービスには、Cloud Platform のリソース階層内での登録、認証、承認に加え、クラウド内に保管されたデバイス メタデータの管理も含まれます。さらに、このサービスからデバイスにデバイス構成を送信することもできます。

取り込み

取り込みは、デバイスから Cloud Platform サービスに情報をインポートするプロセスです。Cloud Platform は、データがテレメトリーなのか、デバイスと IoT インフラストラクチャに関する運用情報なのかに応じて、異なる取り込みサービスを提供します。

IoT Core MQTT

Google Cloud IoT Core は、IoT Core で管理されるデバイスにセキュアな MQTT(Message Queue Telemetry Transport)ブローカーを提供します。この効率的なバイナリ業界基準による構成管理機能を使用することで、処理能力が限られたデバイスでもリアルタイムのテレメトリーを送信できるだけでなく、クラウドからデバイスに送信されたメッセージを瞬時に受信できます。IoT Core の MQTT ブローカーは、直接 Cloud Pub/Sub と接続します。

Cloud Pub/Sub

Google Cloud Pub/Sub は、グローバルに耐久性のあるメッセージ取り込みサービスを提供します。ストリームまたはチャネルに関するトピックを作成することにより、各デバイス上で登録者固有のチャネルを構築することなく、アプリケーションのさまざまなコンポーネントでデータの特定のストリームに登録できるようになります。Cloud Pub/Sub は、取り込み、データ パイプライン、ストレージ システムの接続を支援する他の Cloud Platform サービスにも自動的に接続します。

Cloud Pub/Sub は、受信データ ストリームとアプリケーションアーキテクチャ変更の両方のショック アブソーバーやレートレベラーのように振る舞うことができます。デバイスの多くは、テレメトリー データの保存や送信の再試行が制限されています。Cloud Pub/Sub は、大量のデバイスが現実世界のイベントに反応したときに発生する可能性のあるデータスパイクを処理するためにスケーリングし、そのようなスパイクをバッファリングしてデータ モニタリング アプリケーションから分離します。

Stackdriver Monitoring と Stackdriver Logging

前のセクションで説明したように、Cloud Monitoring と Stackdriver Logging は運用上のメリットをもたらします。運用情報は、付属のインターフェースを介してこれらのサービスによって取り込まれます。

パイプライン処理タスク

パイプラインは Cloud Platform に到着後のデータを管理します。これは生産ラインで部品を管理する方法に似ています。これには次のようなタスクが含まれます。

  • データの変換。 データを別の形式に変換できます。たとえば、キャプチャしたデバイス信号電圧を温度の較正単位尺度に変換できます。
  • データとコンピューティングの集約。 データを組み合わせることにより、複数のデバイス間でデータを平均化するようなチェックを追加して、1 台の不正なデバイスの影響を回避することができます。1 台のデバイスがオフラインになっても、すぐに使用可能なデータの存在が保証されます。パイプラインに計算を追加することにより、パイプライン内で処理中のデータにもストリーミング分析を適用することができます。
  • データの拡張。 デバイスが生成したデータと、デバイスに関する他のメタデータや、気象データや交通データなどの他のデータセットを組み合わせて、以降の分析で使用できます。
  • データの移動。 1 つ以上の最終保管場所に処理済みのデータを保存できます。

Cloud Dataflow

Google Cloud Dataflow は、バッチ オペレーション、抽出-加工-書き込み(ETL)パターン、連続ストリーミング計算などの複数の方法でデータを処理するためのマネージド サービスとして、オープン Apache Beam プログラミング モデルを用意しています。Cloud Dataflow は、特に、IoT シナリオに不可欠な大容量データ処理パイプラインを管理する場合に有用です。また、Cloud Dataflow は、パイプライン用に選択された他の Cloud Platform サービスとシームレスに統合するように設計されています。

データ ストレージ

現実世界からのデータは、形式もサイズもさまざまです。Cloud Platform は、画像や動画ストリームなどの構造化されていない blob から、デバイスまたはトランザクションの構造化されたエンティティ ストレージやイベントデータとテレメトリー データ用の高性能な key-value データベースまでのストレージ ソリューションの範囲を提供します。

IoT Core での状態の保管

デバイスの状態によっては、ハードウェアに直接接続されている場合があります。たとえば、デジタル GPIO ピンの状態をチェックするときは、ピンの電圧の物理的な読み取り値に基づいて、HIGH または LOW として観測されます。

これ以外のデバイスの状態は、アプリケーション レイヤに存在します。たとえば、recording-audio は、アプリケーションがマイクからサンプリングしているのか、ディスクに書き込んでいるのかによって、true または false, の状態条件を取ります。ハードウェア レベルでは、マイク自体がオンのままになっている可能性があります。

ソフトウェアの観点では、デバイス上で実行しているアプリケーション コードが真の情報源を維持します。このことは、デバイスの最新状態を読み取る他のソフトウェアにとっては、有益な場合が多く、必要不可欠な場合さえあります。IoT デバイスが一定時間低電力スリープモードに入ることがあったり、非常に信頼性の低いネットワーク上に存在することがあったりすることを考えると、デバイスの特定の状態をクラウド内に保管すると有効な場合があります。こうすれば、デバイス自体が一時的にオフラインになった場合でも、状態データを利用できます。

IoT Core では、デバイスの最新の状態を報告することや、アプリケーションが取得できるよう保管することができます。MQTT または HTTP を使用して送信される状態情報を IoT Core 内に維持すれば、デバイスの接続が切断されたりデバイスがオフラインになったりしても、状態情報をクラウド内で使用できます。

Datastore と Firebase でのアプリケーション データの保管

状態やテレメトリー データをモバイルアプリやウェブアプリで使用できるようにする必要がある場合、処理済みのデータまたは元データを、Cloud DatastoreFirebase Realtime Database といった構造化された、ただしスキーマレスのデータベースに保管するという方法で対処できます。これらのデータベースでは、IoT デバイスデータをドメインやアプリケーション レベルのオブジェクトとして表現できます。

Cloud Functions と Cloud Dataflow でのルール処理とストリーミング分析

IoT イベントおよびデータは、高速でクラウドに送信して、迅速に処理する必要があります。多くの IoT アプリケーションでは、データへの高速アクセスを可能にするために、物理環境へのデバイスの配置が決定されます。たとえば、輸送中に高温にさらされた農産物は、フラグを付けて、すぐに処分することができます。

この情報をすばやく処理して対処できることが重要です。 Google Cloud Functions を使用すれば、到着したイベントごとに適用可能なカスタム ロジックを記述することができます。これは、アラートをトリガーしたり、無効なデータをフィルタリングしたり、他の API を呼び出したりするために使用できます。Cloud Functions は、個別に公開されたイベントごとに動作することができます。

時間のウィンドウ テクニックや複数のストリームからのデータの収束などのより洗練された分析を使用してデータとイベントを処理する必要がある場合は、Cloud Dataflow がストリーミングとバッチデータに適用可能な高機能の分析ツールを提供します。

分析

多くの場合、IoT ソースから取得したデータを分析することが、物理世界を計測する目的そのものです。ストリーミング データが処理パイプライン内で分析された後、データの蓄積が始まります。時間が経つにつれ、このデータは、傾向を把握するための豊富な情報源となり、IoT デバイスの外部のソースからのデータを含む他のデータと組み合わせることができるようになります。

BigQuery と Cloud Datalab

Google BigQuery は、使い慣れた SQL インターフェースを使用して完全に管理されたデータ ウェアハウスを提供するため、他の企業分析やログのいずれかと一緒に IoT データを保存することができます。BigQuery の性能と費用により、貴重なデータを、ディスク スペースを節約するためにやむなく削除するのではなく、より長く保持できるようになります。

Cloud Datalab は、大規模なデータ探索、分析、可視化のための対話型ツールです。IoT データは、他のどのデータと組み合わせるかに応じて、さまざまなユースケースに有効に利用することができます。Cloud Datalab を使用すれば、オープンソース Jupyter プロジェクトに基づくホスト型のオンライン データ ワークベンチ環境を使用して、データを対話的に探検、変換、分析、可視化することができます。

機械学習

IoT データは多くの場合、本質的に多次元であり、ノイズが含まれます。このような特性があるため、従来の分析手法では、データから簡単に分析情報を引き出すことはできません。その一方、ディープ ニューラル ネットワークは、このような捉えにくい意味を持つ複雑なデータの処理に卓越した力を発揮します。 Tensorflow は、主要なオープンソース機械学習フレームワークです。Cloud Platform では、Cloud Machine Learning Engine を介して、分散管理されたトレーニング サービスで Tensorflow を適用できます。

Cloud Bigtable を使用した時系列ダッシュボード

特定の種類のデータは、コアな可視化とユーザー インターフェースを更新するための既知のインデックスとディメンションに沿ってすばやくスライスできる必要があります。Cloud Bigtable は、NoSQL データに低レイテンシで高スループットのデータベースを提供します。また、Cloud Bigtable は、質問がすでに十分理解されており、大量に消費または提供する必要のある使用頻度の高い可視化とクエリを促進するのに適した場所を提供します。

BigQuery と比較した場合、Cloud Bigtable の方が行または連続行のグループを対象とするクエリに適しています。これは、Cloud Bigtable が行ベースの形式を使用してデータを保存するためです。Cloud Bigtable と比較した場合、BigQuery の方がデータ集計が必要なクエリに適しています。

Cloud Storage Nearline のアーカイブ ストレージ

現実世界からのデータの蓄積が停止することはなく、データは必ずしも構造化されていません。Cloud Storage は、現在使用中のオブジェクト ストレージとまれにしか使用されないアーカイブ データの両方に単一の API を提供します。IoT デバイスがメディアデータをキャプチャした場合は、Cloud Storage が事実上無制限の容量を永続的かつ経済的に保存することができます。

まとめ

モノのインターネット構築ソリューションは、さまざまな領域全体の課題の解決を支援します。Cloud Platform は、デバイス管理、大規模なインフラストラクチャ、ネットワーキング、そして多様なストレージと分析のプロダクトを備えており、これらを利用するとデバイスが生成したデータを最大限に活用できます。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...