IoTのためにネットワークが提供すべき3つの要素

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

モノのインターネット（IoT）は、引き続き注目を集めています。消費者向けのガジェットや機器が話題になりがちですが、私にとってより興味深いのは、早期導入企業がデータセンターで進めている舞台裏の準備作業です。

おそらく、大規模なIoTの取り組みを支えるには、やるべきことが山ほどあるからでしょう。そして、その「モノ」が消費者向けである以上、小規模なIoT展開など実際にはあり得ません。お気づきでないかもしれませんが、世の中には実に多くの消費者がいます。そして、彼らは目新しくて魅力的なモノが大好きなのです。

こうした状況を踏まえ、テクノロジー業界では現在、既存の製品（自動車、家電、玩具）にIoTを統合する企業だけでなく、手にして初めて必要性に気づくようなまったく新しい製品で次の大きな成功を目指す企業を支援するため、さまざまな取り組みが進んでいます。

実際、IoT関連の購入では政府機関が業界をリードしていますが（F5の「State of Application Delivery 2016」による）、通信事業者、テクノロジー企業、クラウドサービスプロバイダーもそれに迫っています。実のところ、過去12か月間はどの業界でも購入率がかなり高く、消費者向け分野だけを見ていては分からないほど、IoTに関する取り組みが広がっていることがうかがえます。

その多くはインフラストラクチャで進行しています。つまり、お子さまのお気に入りのテディベアに組み込まれた小さくてかわいらしいチップを管理、計測、監視、保護し、チップとやり取りするバックエンドアプリケーションに、接続性と即応性を提供するネットワークです。

あらゆるアプリやクライアントと同様に（実際、こうしたリモートデバイスはクライアントです）、一貫性と予測可能性、信頼性を保って動作するには、基本的なサービスが必要です。具体的には、セキュリティ、配信、可視性を実現するサービスです。

セキュリティ

新しいテクノロジーでは、セキュリティへの対応が後回しになりがちです。そこで、まずセキュリティから取り上げます。IoTのような発展途上のテクノロジーでさえ、昨今最も注目を集めるのはセキュリティ侵害だからです。

モノはバックエンドアプリと通信する必要があります。データの保存、アップデートやパッチの取得、設定の変更など、目的を問わず、モノはバックエンドアプリと安全に通信しなければなりません。そのためには、SSLまたはTLSによるセキュアトンネルをサポートする必要があります。また、平文ではなくセキュアなHTTPを使用し、モノに鍵をハードコードしてはなりません。これは非常に重要です。絶対にやめてください。

セキュリティには、アイデンティティの検証も含まれます。確かに、このモノが自動車であることは分かっています。しかし、*誰の*自動車なのでしょうか。モノを迅速かつ正確に識別し、認可されたユーザーや所有者と関連付けるサービスが必要です。そうすれば、隣人が私のカーラジオをヘビーメタル以外の局に合わせようとする可能性を軽減できます。なんと恐ろしいことでしょう！

最後に、セキュリティにはプロトコル分析も含まれます。IoT全体で新たなプロトコルの標準化が検討されていることを踏まえると、これは特に重要です。プロトコルのセキュリティ上の不備は重大なリスクとなる可能性があり（Heartbleedを覚えている方もいるでしょう）、迅速な対処が難しい傾向にあります。プロトコルが悪用される可能性を検知できれば、リスクに先手を打って対処できます。

デリバリー

トランザクションデータをはじめとする各種データは、モノやバックエンドアプリに配信する必要があります。そのために、JSONでエンコードした大量のビットをどこかのREST APIに送り込むだけで済むとは限りません。多くのモノは、IoTの新たな言語であるMQTT、CoAP、AQMPを使用します。一方、それぞれのバックエンドアプリはどうでしょうか。同じ機能や情報へのアクセスをWebアプリやモバイルアプリにも提供しているため、RESTを使用します。つまり最終的には、配信経路のどこかに、プロトコル間の相互運用性を実現するゲートウェイ、すなわち変換機能を担う仲介役が必要になります。

これにより、車載デバイスは、MQTTを介して、RESTを使用するバックエンドアプリが理解できるデータやメッセージを送信できます。仲介機能が通信を傍受し、安全に変換することで、デバイスとそのアプリ間のシームレスなやり取りを実現します。仲介機能をC3PO、車（またはその他のデバイス）をR2D2と考えると分かりやすいでしょう。これは、ネイティブプロトコルのサポートに加え、他のプロトコルへの対応を迅速に開発できるスクリプティングプラットフォームを提供する、ソフトウェア定義型のアプローチを意味します。データパススクリプティングは、ネットワークプログラマビリティを構成する3つの主要要素の1つですが、最も言及されることの少ない要素です。IoTでは、多種多様なプロトコルや言語への対応が必要になると考えられるため、あまり注目されてこなかったこの機能がもたらす柔軟性は、非常に大きな価値を持つでしょう。

先ほど、考慮すべき点としてスケールについて触れましたが、その要件への対応が求められるのがデリバリーです。たとえば、100万台のモノをサポートできるようにスケールするには、機能を分割したアプリケーションアーキテクチャを採用することになるでしょう。本格的なマイクロサービスでなくても、少なくとも機能ドメインを分離することで、より効率的かつ費用対効果の高い方法で各機能を個別にスケールできるようになります。

そこで役立つのが、メッセージベースの負荷分散です。この概念は、サービスプロバイダー分野で、DiameterやSIPなどのプロトコルと併せて取り上げられていたことを覚えているかもしれません。この分野では、効果的かつコスト効率に優れたスケーリングが不可欠です。

メッセージベースの負荷分散が重要なのは、MQTTのようなプロトコルがメッセージを基盤としているためです。これは、企業システムの内部で利用されているメッセージベースのミドルウェアと同様の、パブサブ（パブリッシュ／サブスクライブ）モデルです。つまり、メッセージを解析し、適切なサービスやデバイスに送信する必要があります。これを大規模に行うには、負荷分散サービスがメッセージを解析して送信先を判断し、その処理に適したリソースを選択できなければなりません。

基本的なロードバランサーのアプリケーション解析機能には限界があるため、これは言うほど簡単ではありません。しかし、IoTデバイスで多く利用されるプロトコルのスケーリングを支えるには、この機能が必要になります。

可視性

最後に、インフラストラクチャは可視性をサポートする必要があります。つまり、何が起きているかを把握できなければなりません。セキュアなトランザクションを可視化（SSLインスペクション）することで、セキュリティ対策を実行し、悪意のある攻撃者を特定できます。また、利用パターンを可視化することで、適切なサービスの自動スケーリングが可能になります。

可視性とは、「ビッグデータ」による高度な運用分析だけでなく、レポート作成やログ記録も含みます。このような複雑なアーキテクチャでは、トラブルシューティングが非常に困難になるため、ツールと担当者の双方が問題を突き止めるうえで、ログ記録が極めて重要になります。

IoTの拡張とサポートは、ガジェットだけの問題ではありません。ネットワークやインフラストラクチャ、そしてIoTを支える運用フレームワークには、取り組むべきことが数多くあります。幸い、魅力的なガジェットを支える（非常に重要な）バックエンドアーキテクチャを担当しているなら、テスト用に1台（あるいは3台）必要だと主張できます。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事