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

IoT アーキテクチャーによって IoT ソリューションの開発を単純化する

モノのインターネット (IoT) ソリューションを計画する際に直面する最大の課題の 1 つは、IoT ソリューションの複雑さにどのように対処するかです。典型的な IoT ソリューションでは、種類が異なる数多くの IoT デバイスに搭載されたセンサーから生成されたデータを分析して、洞察を得なければなりません。これらの IoT デバイスとクラウド・サービスまたはアプリケーションとの通信を可能にするためには、デバイスを直接、あるいはゲートウェイ・デバイスを介してネットワークに接続することになります (図 1)。

図 1. 人間の観点から見たモノのインターネット (出典: X-Force Research and Development 「IBM X-Force Threat Intelligence Quarterly 4Q 2014」、文書番号 WGL03062USEN、2014年11月公開、http://www.ibm.com/security/xforce/downloads.html)

alt

エッジ・コンピューティング という言葉は、物理デバイスがクラウドに接続される、IoT ネットワークのエッジで行われる処理を言い表します。IoT 分野で現在一般的になりつつあるエッジ・コンピューティング・アーキテクチャーでは、データ駆動型 IoT アプリケーション内でのレイテンシーの削減、プライバシーの強化、帯域幅コストの節約に重点が置かれています。

この記事では、データ駆動型 IoT アーキテクチャーを計画する際に適用できる、以下の戦略について説明します。これらの戦略は、開発を単純化し、複雑さに対処するのに役立ちます。さらに、IoT ソリューションのスケーラビリティー、柔軟性、堅牢性を確保する上でも効果があります。

  • 層化アーキテクチャーを採用する
  • 設計段階からセキュリティーを確保する (セキュリティー・バイ・デザイン)
  • 処理を自動化する
  • 相互運用性を考慮して設計する
  • リファレンス・アーキテクチャーに従う

層化アーキテクチャーを採用する

アーキテクチャーとは、物理的な側面 (つまり、モノ) と仮想的な側面 (サービスや通信プロトコルなど) を含め、IoT ソリューションの構造を説明するものです。多層アーキテクチャーを採用すると、アーキテクチャーの最も重要な側面のそれぞれについて、その動作の仕組みを他とは切り離して理解してから、IoT アプリケーション内ですべての側面を 1 つに統合するという方法をとることができます。このようなモジュール式の手法は、IoT ソリューションの複雑さに対処するのに役立ちます。

エッジ・アナリティクスが関与するデータ駆動型 IoT アプリケーションの場合、基本的な 3 つの層からなるアーキテクチャー (図 2 を参照) によって、情報のフローをとらえることができます。つまり、情報はデバイスからエッジ・サービスに渡され、エッジ・サービスからクラウド・サービスに渡されるという構図です。さらに詳細な IoT アーキテクチャーでは、他の層と垂直に交差する層として、アイデンティティー管理やデータ・セキュリティーなどの層も考慮されます。

図 2. IoT アーキテクチャーの層

alt

デバイス層

デバイス層 (図 2 に示されている一番下の層) に含まれるコンポーネントは、IoT デバイスに接続される物理センサーやアクチュエーター、そして IoT デバイス自体です。一般に、センサーやアクチュエーターが単独で「スマート」デバイスとして見なされることはありません。けれども、これらのコンポーネントは通常、処理能力がより高い IoT デバイスに直接、あるいは Bluetooth LE や ZigBee などのテクノロジーによってワイヤレスで接続されるため、デバイス層に含まれます。

IoT デバイスの中には関連するクラウド・サービスやアプリケーションと直接通信するものもありますが、通常はゲートウェイを介して上流に位置するコンポーネントと通信します。ゲートウェイとは、基本的な IoT デバイスよりわずかに処理能力が高い中間デバイスのことです。ゲートウェイには必ずしも直接センサーが接続されるわけではありませんが、ゲートウェイ・デバイスはデータ収集プロセスにおいて重要や役割を果たします。ゲートウェイ・デバイスでは、センサー測定値のロー・データに対し、基本的なアナログからデジタルへの変換、スケーリング、およびその他の正規化の処理を行うことができるためです。

エッジ層

エッジ層 (図 2 に示されている中間の層) には、ネットワークのエッジで行われるアナリティクスおよび前処理サービスが関連してきます。センサーから送られてくるデータ・ストリームを収集すると同時に処理することにより、エッジ・アナリティクスはリアルタイム (または、ほぼリアルタイム) で行われます。エッジでデータのフィルタリングや集約などの基本的な前処理タスクが行われた上で、前処理済みの重要なデータが上流のクラウド・サービスやアプリケーションに転送されて、さらに処理とアナリティクスが行われることになります。

クラウド層

エッジ層で前処理されたデータは、上流に送信されて、クラウド層 (図 2 に示されている一番上の層) にあるクラウド・アプリケーション内でさらに処理されて、保管および使用されます。データ処理を行うクラウド・アプリケーションは、多くの場合、モバイル・アプリケーションや Web ベースのクライアント・アプリケーションの機能によって補完されます。それは、エンド・ユーザーにデータを表示したり、ダッシュボードや視覚化を介して詳しく探索および分析するためのツールにアクセスできるようにしたりするためです。

「Security by Design (セキュリティー・バイ・デザイン」手法を実装する

IoT ソリューション全体のセキュリティーを確保するためには、IoT アーキテクチャーを構成するすべての層にまたがって、セキュリティーを最優先事項にする必要があります。セキュリティーは、IoT アーキテクチャーの個々の層で他とは切り離して最終的に対処するものとして考えるのではなく、IoT アーキテクチャーを構成するすべての層にまたがる懸念事項としてとらえる必要があります。多数のデバイスが接続される IoT ソリューションでは、個々のデバイスまたはゲートウェイのセキュリティーが侵害されたとしても、システム全体の保全性が維持されなければなりません。必ず、アーキテクチャーが複数の防御層をサポートするようにしてください。また、セキュリティーが侵害されたデバイスを IoT ソリューションが識別して無効化できるようにしてください。それには、ゲートウェイを使用して脆弱なデバイスを隔離したり、通信と使用パターンをモニターして異常を検出したりするなどの方法が考えられます。

IoT インフラストラクチャーの以下の側面に関する標準およびベスト・プラクティスを採用してください。

  • デバイス、アプリケーション、およびユーザーのアイデンティティー、認証、許可、アクセス制御
  • 鍵管理
  • データ・セキュリティー
  • セキュアな通信チャネルおよびメッセージの保全性 (暗号化を使用)
  • 監査
  • セキュアな開発およびデリバリー

処理を自動化する

採用する IoT アーキテクチャーでは、すべての層をまたがって自動化とオーケストレーションがサポートされるようにしてください。IoT ソリューションを本格展開する際に、迅速で簡単な開発およびデプロイをサポートできるよう、自動化機能の使用を計画する必要があります。例えば、エッジ層またはクラウド層では、コンテナー・テクノロジーを使用してマイクロサービス・アーキテクチャーを実装し、IoT プラットフォームに用意されたツール (Kubernetes など) を使用してオーケストレーションに対応することができます。これらの機能により、新しいデバイスやゲートウェイのセットアップ、デバイス・データを処理する新しいクラウド・アプリケーション・インスタンスのデプロイなどといった処理でエラーが発生しにくくなります。手作業による構成を避けることで、処理を反復可能にすることができます。数千台、さらには数百万台もの接続されたデバイスを伴う IoT ソリューションをスケーリング可能にするためには、処理が反復可能であることが不可欠です。

相互運用性を考慮して設計する

IoT アーキテクチャーにおいて最大の課題の 1 つとなるのは、IoT ソリューションにて採用するデバイス、ネットワーク・プロトコル、データ・フォーマットの多様性です。IoT ソリューションにて複数の IoT プラットフォームを採用することを予定している場合は、それぞれの IoT プラットフォーム内で使用されているテクノロジーを 1 つのまとまりのあるソリューションに統合できるかどうかを検討する必要があります。

IoT にて相互運用性を確保するための最良の戦略の 1 つは、標準を採用することです。標準を採用すれば、それらの標準に準拠しているコンポーネントである限り、新しいコンポーネントとの交換やコンポーネントの追加導入に柔軟に対応することができます。

リファレンス・アーキテクチャーも、IoT アーキテクチャーを計画する際のガイドラインとして役立ちます。通常、リファレンス・アーキテクチャーは標準に基づいており、デザイン・パターンとベスト・プラクティスをカプセル化しています。そのようなリファレンス・アーキテクチャーを採用した上で、リファレンス・アーキテクチャーに記述されているガイドラインに従って、そのアーキテクチャーを実装する IoT プラットフォームを選択することが、IoT アーキテクチャー内の相互運用性を確保する上で確実な戦略となります。

リファレンス・アーキテクチャーに従う

現在、相互運用性の向上を目的に、数多くのイニシアチブで IoT アーキテクチャーの標準化に向けた取り組みが進んでいます。数々の IoT プラットフォーム・ベンダーと研究パートナーがこれらのイニシアチブを通して協力して IoT リファレンス・アーキテクチャーの定義を進めています。リファレンス・アーキテクチャーは、アーキテクチャーの基礎として、IoT ソリューション内で使用する主要なビルディング・ブロックを記述するとともに、アーキテクチャー上の主要な概念を表す共有の用語を確定する役割を持ちます。IoT アーキテクチャーの標準化を目指すイニシアチブでは、効果的なデザイン・パターンとベスト・プラクティスを明らかにするために、既存の広範なソリューションを利用しています。

広く参照されている IoT リファレンス・アーキテクチャーとしては、以下が挙げられます。

  • Internet of Things – Architecture (IoT-A): IoT-A リファレンス・モデルおよびアーキテクチャーは、2013 年に EU ライトハウス・プロジェクトを経て開発されました。IoT-A は、さまざまなドメインにわたって適用できる具体的なアーキテクチャーを開発する目的で設計されています。
  • IEEE P2413 – Standard for an Architectural Framework for the Internet of Things (IoT): この現在進行中の IEEE 標準化プロジェクトでは、製造、スマート・ビルディング、スマート・シティー、インテリジェント輸送システム、スマート・グリッド、医療などの IoT ドメインの間の共通性を識別することを目的としています。
  • Industrial Internet Reference Architecture (IIRA): IIRA は、Industrial Internet Consortium により、産業 IoT アプリケーションを具体的な焦点として開発されました。Industrial Internet Consortium は、2014 年に AT&T、Cisco、General Electric、IBM、Intel が共同で設立したコンソーシアムです。

リファレンス・アーキテクチャーは、IoT ソリューションを開発するためのテンプレートとして使用できます。上記に挙げたアーキテクチャーでは、IoT アーキテクチャーのコンポーネントと各コンポーネントの役割を概要レベルでしか記述していませんが、抽象的な要件を特定のテクノロジーまたはテクノロジー・スタックにマッピングすることで、さらに具体化できます。

IoT リファレンス・アーキテクチャーのコンポーネント

リファレンス・アーキテクチャーの詳細はアプリケーションのドメインによって異なりますが、ほとんどの IoT リファレンス・アーキテクチャーでは、少なくとも以下の機能について記述しています。

  • デバイスとデバイス・データの管理
  • 接続と通信
  • アナリティクスとアプリケーション

さらに、リファレンス・アーキテクチャーでは一般に、非機能要件、つまり柔軟性、信頼性、サービス品質、相互運用性、統合に対処するためのメカニズムについても記述しています。

デバイスとデバイス・データの管理

リファレンス・アーキテクチャーのデバイス管理の側面は、デバイスとそのアイデンティティーおよびライフサイクルに関係しています。リファレンス・アーキテクチャーで記述しているデバイス管理の内容は以下のとおりです。

  • デバイスのオンボーディング
  • デバイス・ファームウェアの更新
  • 新規構成の適用
  • デバイスの無効化、有効化、デコミッショニングなどのリモート処理のトリガー

接続と通信

デバイス間、デバイスとゲートウェイ間、ゲートウェイとクラウド・サービスおよびアプリケーション間の接続と双方向通信の管理も、IoT リファレンス・アーキテクチャーに記述されることの多い重要な機能です。エッジ・コンピューティングの場合、イベント駆動型アーキテクチャーに従って、デバイスとサービス間の通信にパブリッシュ/サブスクライブ式のプロトコルとメッセージ・ブローカーを使用するのが適切な選択肢となります。

アナリティクスとアプリケーション

IoT デバイスから送信されるデータから価値を引き出すために、クラウド・アプリケーションでは、データ・ストリームまたはバッチを処理して実用的な洞察を特定する、視覚化およびアナリティクス・ツールを提供しています。使用ケースによっては、意思決定管理ツールやビジネス・プロセス・ツールでアラートをトリガーしたり、応答としてアクションを実行したりすることもできます。

具体的なリファレンス・アーキテクチャー

リファレンス・アーキテクチャーで規定されていることの多いパターンとガイドラインは、産業 IoT などの特定の IoT ドメイン内から引き出されている場合もありますが、その一方で、一連のドメインをまたがるソリューションを基に一般化されていることもあります。高位レベルで一般化されたアーキテクチャーをテンプレートとして使用することで、特定のドメインまたはプラットフォームに固有の具体的なアーキテクチャーを作成することができます。

汎用 IoT プラットフォームのベンダーは、多くの場合、応用しやすいリファレンス・アーキテクチャーと併せ、そのプラットフォームで提供しているツールとソフトウェア・エージェントを使用して、該当するリファレンス・アーキテクチャーに準拠した IoT ソリューションを開発するための実装ガイドを提供しています。そのような IoT プラットフォーム中心のリファレンス・アーキテクチャーには、以下の例があります。

IBM Industrie 4.0 リファレンス・アーキテクチャーは、ドメイン固有のリファレンス・アーキテクチャーの一例であり、IIRA リファレンス・アーキテクチャーと IBM IoT リファレンス・アーキテクチャーに基づき、産業 IoT アプリケーションを対象に設計されています。

まとめ

データ駆動型 IoT ソリューションを設計するのは、その規模、そして関連するデバイスおよび接続の多様性から、複雑なタスクとなります。この記事では、セキュアで柔軟かつスケーラブルな IoT アーキテクチャーを設計するための戦略を概説しました。