IoT のためにネットワークが提供すべき 3 つの要素
それを念頭に置いて、IoT を既存の製品 (自動車、家電、玩具) と統合している人々や、実際に手にするまで必要だとは思わなかったまったく新しい製品で次の大物になろうとしている人々をサポートするため、現在テクノロジー業界全体でさらに多くのことが行われています。
本当に。 IoT の購入を行っている業界は政府機関が中心ですが (当社の 2016 年アプリケーション配信状況レポートによると)、通信、テクノロジー、クラウド サービス プロバイダーもそれに続いています。 実際、過去 12 か月間のすべての業界で購入率がかなり高く、消費者向け分野だけを見ていると明らかになるよりも多くの IoT 関連の取り組みが行われていることがわかります。
起こっていることの多くはインフラストラクチャ内で起きています。つまり、お子様のお気に入りのテディベアに埋め込まれたかわいい小さなチップを管理、計測、監視、保護、対話するバックエンドのアプリケーションによる接続性と即時応答を提供するネットワーク内で起きているのです。
他のアプリやクライアント (リモートのものはすべてクライアントです) と同様に、一貫性、予測可能性、信頼性をもって動作するために必要な基本的なサービス セットがあります。 つまり、セキュリティ、配信、可視性を実現するサービスが必要です。
安全
新しいテクノロジーでは、セキュリティは最後に注目される傾向があるため、まずはセキュリティから始めたいと思います。IoT のような新興テクノロジーでも、最近ではセキュリティ侵害が最も注目される傾向があるからです。
バックエンド アプリと通信する必要があります。 データの保存、更新やパッチの取得、構成の変更など、どのような場合でもバックエンド アプリと安全に通信する必要があります。 つまり、SSL または TLS を介した安全なトンネルのサポートを意味します。 これは、プレーンテキストではなく安全な HTTP を使用することを意味し、さらに、キーをハードコードしないことを意味します。 私はこれについては本気です。 やめてください。
セキュリティとは、ID の検証も意味します。 はい、これは車だということは知っていますが、誰の車なのでしょうか? 隣人が私のラジオをヘビーメタル局以外のものに合わせるべきだと判断する可能性を軽減するためには、物事を迅速かつ正確に識別し、それを許可されたユーザーや所有者に関連付けることができるサービスが必要です。 恐ろしい！
最後に、セキュリティとはプロトコル分析も意味します。 これは、IoT の世界全体で標準化が検討されている新しいプロトコルを考えると特に重要です。 プロトコルの脆弱性は重大なリスクとなる可能性があり (Heartbleed を覚えているかもしれません)、タイムリーに対処することが難しい傾向があります。 プロトコルの潜在的な悪用を検出する機能により、事前にリスクを軽減できます。
配達
トランザクションデータやその他のデータは、モノやバックエンド アプリに配信される必要があります。 そうすることは、必ずしも JSON でエンコードされたビットの束をどこかの REST API に押し込むだけの問題ではありません。 多くのものが IoT の新しい言語を話します。 MQTT、CoAP、AQMP。 しかし、それぞれのバックエンドアプリはどうでしょうか? 彼らは同じ機能と情報へのアクセスを Web およびモバイル アプリにも提供しているため、REST を利用できます。 つまり、配信パスのどこかに、プロトコルの相互運用性を提供するゲートウェイ、トランスレータ、仲介者が存在することになります。
これにより、車内のデバイスはMQTT経由でデータやメッセージを送信できるようになり、REST を話すバックエンド アプリがそれを理解できるようになります。 仲介者は、（安全に）傍受して翻訳し、デバイスとそのアプリ間のシームレスな会話を提供します。 仲介者は C3PO で、あなたの車 (または他の物) は R2D2 だと考えてください。 これは、ネイティブ プロトコルのサポートだけでなく、他のプロトコルのサポートを迅速に開発できるスクリプト プラットフォームを提供するソフトウェア定義のアプローチも意味します。 データ パス スクリプトは、ネットワーク プログラマビリティの 3 つの主要コンポーネントの 1 つですが、あまり言及されていません。 IoT に関しては、多種多様なプロトコルや言語をサポートすることになるため、このあまり知られていない機能によってもたらされる柔軟性は非常に貴重になります。
先ほど、規模を考慮する必要があると述べましたが、この配信ではその要件がサポートされていることがわかります。 たとえば、何百万ものサポートを拡張するには、おそらく分解ベースのアプリ アーキテクチャを使用することになります。 本格的なマイクロサービスではないかもしれませんが、少なくとも、より効率的 (かつコスト効率の高い) 方法論でさまざまな機能の拡張を可能にするために、機能ドメインを分離することになるでしょう。
ここで、メッセージベースの負荷分散のようなものが登場します。 この概念は、規模の有効性と費用対効果が不可欠であるDiameter や SIP などのプロトコルに関連してサービス プロバイダーの分野で言及されていたことを覚えているかもしれません。
MQTT などのプロトコルはメッセージに基づいているため、メッセージベースの負荷分散は重要です。 これらは、企業の奥深くに存在すると聞いたことがあるメッセージベースのミドルウェアとよく似た pub-sub (publish – subscribe) モデルです。 いずれにせよ、それらはメッセージに基づいており、それらのメッセージを解析して適切なサービスまたはデバイスに送信する必要があります。 これを実現し、拡張するには、負荷分散サービスがメッセージを解析して送信先を決定し、適切なリソースを選択して処理できる必要があります。
基本的なロードバランサーにはアプリケーション解析機能が限られているため、これは思ったほど簡単ではありません。 しかし、IoT デバイスが好むプロトコルのスケーリングをサポートすることが必須になります。
可視性
最後に、インフラストラクチャは可視性をサポートする必要があります。 それは、何が起こっているかを見る能力を意味します。 安全なトランザクション (SSL 検査) の可視性により、セキュリティ担当者は対策を講じ、不正な行為者を特定できるようになります。 使用パターンを可視化することで、適切なサービスの自動スケーリングが可能になります。
可視性とは、強力な運用分析だけでなく、レポート作成やログ記録も提供する「ビッグデータ」のことを指します。 このような複雑なアーキテクチャではトラブルシューティングが非常に困難になるため、ツールと人が問題を追跡するにはログ記録が重要になります。
IoT の拡張とサポートはガジェットだけに関係するものではありません。 ネットワーク、インフラストラクチャ、そしてそれをサポートするために必要な運用フレームワークにおいて、実行すべき作業はたくさんあります。 良いニュースとしては、クールなガジェットのサポートとなる (非常に重要な) バックエンド アーキテクチャに取り組んでいる人であれば、テスト用に 1 つ (または 3 つ) 必要であると常に主張できるということです。