HiveMQは，IoTアプリケーションのために設計された，MQTTベースのメッセージングプラットフォームである。先日リリースされたHiveMQ 4では，MQTT 5サポートが追加され，拡張システムが改善されるとともに，DockerやKubernetes，AWS EC2との統合性が向上している。
HiveMQ 4は、ユーザプロパティや否定応答，トピックエイリアスといったMQTT 5の新機能をサポートすることにより，MQTT 3とMQTT ５クライアント間の透過的なコミュニケーションを実現している。また，エンタープライズシステムとの統合性向上を目的とした，新たな拡張システムが導入された。
Message Queuing Telemetry Transport (MQTT)は，IoTアプリケーション用のISO標準通信プロトコルである。デバイス間の１対多通信をサポートするための，パブリッシュ/サブスクライブプロトコルを定義している。MQTTクライアントはブローカサービスを通じて，メッセージのパブリッシュおよび/または新たなメッセージ通知のサブスクライブを行うことができる。
InfoQは今回、dc-square CTOのDominik Obermaier氏と話をする機会を得た。
InfoQ: MQTT 5がIoTアプリケーションにとってどのようなメリットのあるものなのか，簡単に説明して頂けますか？MQTT 3に対して，どのような点で改善されているのでしょう？
Dominik Obermaier: MQTTは1999年に最初に開発されて，2010年にMQTT 3.1仕様が公開されました。2010年以降，特にクラウドコンピューティングや大規模システム開発の領域では，多くの変化がありました。MQTTも広く普及していますので、仕様をアップデートする時期に差し掛かっています。MQTT 5のおもな目標は次のようなものです。
大規模システムをより簡単に，スケーラブルかつ信頼性の高い方法でホスト可能にする。
エラー処理を改善して，アプリケーション全般をよりレジリエントにする。
MQTTメッセージにユーザプロパティの追加を可能にすると同時に，パフォーマンスを改善し，より小規模なクライアントをサポートする。
要約すれば，MQTT 5は、MQTTをクラウドネイティブなアプリケーションのために，よりスケーラブルで信頼性の高いものにするものです。MQTT 3.1を仕様した単一のHiveMQデプロイメントでも，すでに1000万までの同時MQTT接続上で毎秒100万以上のメッセージをサポートしているのですが，MQTT 5はさらに大きな数字へのスケールアップの基盤となるものです。
InfoQ: MQTTの実装は非常に数が多く，競争も激しいのですが，HiveMQは競合製品に比較してどのような部分が際立っているのでしょう？
Obermaier: MQTTがこれほどポピュラーなIoT標準になったというのは，本当に素晴らしいことです。たくさんのIoTプラットフォームベンダが，サポート対象プロトコルのひとつとしてMQTTを加えています。しかしHiveMQでは，MQTTがプラットフォームのコアなのです。アドオンではありません。ネットワークに接続されたデバイス(コネクテッドデバイス)とクラウドプラットフォーム間でデータを転送するプロトコルとして，MQTTは最高のものだと思います。
当社の実装が優れているのは，次のような点においてです。
HiveMQは1,000万接続までスケールアップが可能です。HiveMQブローカは，当社の自動エラスティッククラスタリングによって実行時にスケールアップとダウンが可能である他，運用環境としてKubernetes，Openshift，DC/OSを備えたDockerのように，最先端のテクノロジをサポートしています。
クラスタノードの障害に対する耐性に優れています。HiveMQでは，クラスタノードごとに独立したデバイスセッションのプールを生成します。これはつまり，クラスタノードがフェールした場合，MQTTの全クライアントは，下位インフラストラクチャに関する知識を必要とせずに，別のノードでセッションを復帰することができる，ということです。対象とするIoTコネクテッドデバイスに対して非常にレスポンシブなユーザエクスペリエンスが必要で，常時接続によるエクスペリエンスが求められているような場合，これは非常に重要です。
HiveMQ 4では，新しい拡張フレームワークが導入されて，HiveMQとMQTTメッセージをさまざまなバックエンドシステムに容易に統合できるようになりました。例えば，InfluxDBとPrometheusと統合することで，MQTTメッセージデータを簡単に監視できるようになります。当社のユーザも，自身の(多くの場合はプロプライエタリな)セキュリティシステムとHiveMQを統合するために，拡張フレームワークを使用しています。
当社はMQTTベースのシステムのデプロイに必要な管理ツールやトラブル対応ツールの開発に，多くの時間を費やしています。例えばHiveMQでは，リアルタイムトレース記録をセットアップして，MQTTのクライアントとブローカ間のインタラクションを記録することが可能です。これにより，運用チームはデプロイしたシステムのボトルネックや問題の特定が，サポートチームは接続に問題を抱えるエンドユーザの支援が，それぞれ可能になります。
最後に，HiveMQはMQTTに100パーセント準拠しています。Eclipse PahoなどMQTT準拠の任意のクライアントを，HiveMQブローカに接続することができます。他のベンダの中には，100パーセント準拠していないために，自身のクライアントSDKの使用をユーザに求めているものもあります。当社には世界各国に110社を超えるユーザがいて，ベンダによるロックインを回避するために，100パーセント標準ベースの通信を必要としているのです。
InfoQ: MQTTはISO標準ですが，IoT分野で唯一のプロトコルという訳ではありません。他の広範に利用されているIoT通信プロトコルに比較して，MQTTが最高の価値を提供できるのはどのようなシナリオなのか，説明して頂けますか？
Obermaier: 仰るとおりプロトコルはたくさんありますし，実際のIoTソリューションではHTTPが頻繁に使用されています。MQTTが開発者にとってメリットのあるシナリオはたくさんあります。
定常的なネットワーク接続に頼ることのできないネットワーク接続プロダクトを開発している場合。例えばカーシェアリングアプリは，車がトンネルを通り抜ける際の接続ダウン時にも動作して、再接続を行う必要があります。MQTTでは，クライアントとブローカ間のセッション接続を持続することが可能です。
GSM/3G上での動作のように，ネットワーク帯域を効率的に使用する必要のあるIoTアプリケーションを開発している場合，MQTTのメッセージは極めて小さい上に，pub/subプロトコルを使うことで，HTTPや，あるいはXMPPのような冗長なXMLベースのプロトコルに比較して，通信量を小さくすることができます。MQTTは元々，ガソリン産業がパイプラインを監視する目的で，1999年に設計されました。そのためのプロトコルは，ネットワークと電力の面で効率的である必要がありました。これは今日のIoTプロダクトにおける重要な課題そのものです。
MQTTをIoTで普及させている技術面での大きな違いは，次のようなものだと思います。
ライトウェイトで，学習や利用が容易である(AMQPなどのヘビーウェイトなプロトコルと比較して)。
パブリッシュ/サブスクライブプロトコルは，コネクテッドデバイスによる大規模デプロイメントに適している。
TCP/IP上で動作するため，ファイアウォール・フレンドリであり，データセンタやクラウドプラットフォーム内に容易にセットアップできる。
接続は常にクライアント側から起動されるため，MQTTクライアントはインターネットからアクセスされることはない。これは大きなセキュリティ機能である。CoAPなど他のプロトコルと比較して，DoS攻撃の攻撃ベクトルをクライアント上で開くことのないMQTTは，設計面で安全なのだ。
InfoQ: IoTアプリケーションの大きな懸念のひとつにセキュリティがあります。MQTT 5とHiveMQ 4はこの点について，どのように機能するのでしょう？IoTデバイスをよりセキュアにするために，どのような改善が必要なのか，意見を聞かせてください。
Obermaier: セキュリティはIoTデプロイメントにおいて最も重要な課題のひとつです。よいニュースは，MQTT 5は設計面からセキュアであることです。パブリッシュ/サブスクライブアーキテクチャであるため，接続は常にクライアントによって開始されます。MQTTブローカ自身がクライアントに接続することはありません。ですから，MQTTクライアントにインターネット経由でアクセスすることは不可能で，デバイスが攻撃されることがないのです。
高度なアプリケーション層セキュリティ用に，MQTTはAUTHプロトコルパケットも導入しています。これにより，(KerberosやSCRAM，その他のSASLフレームワークプロトコルのように)チャレンジ/レスポンスプロトコルを使用したユーザ認証と承認が可能になります。旧来型のトークンないし資格ベースの認証機構(OAuth 2.0や懐かしいユーザ名/パスワード認証)ももちろん，引き続きサポートしています。
セキュリティに関連して，IT産業が長年にわたって学んだ重要な教訓のひとつは，車輪の再発明をするな！ということです。ですからMQTTでは，クライアントとブローカ間の暗号化通信にTLS(1.2または最新の1.3バージョンを推奨)を使用しています。TLSは今日のセキュアなインターネットの基礎であって，同じ方法がHTTPの他にも，SMTPやFTPといったインターネット・プロトコルで暗号化通信チャネルの作成に使用されています。
HiveMQ 4は，これまでにのべたセキュリティ機構をすべて実装しています。フレキシブルな拡張システムが，OAuth 2.0サーバやLDAP，あるいはデバイス管理データベースを，事前に用意されている拡張機能のプラグインすることで利用可能にしています。ブローカは高度な認証管理を提供していますので，個々のクライアントあるいはクライアントグループに対して，パブリッシュないしサブスクライブ可能なデータを制限することができます。またHiveMQは，エンタープライズシステムを含む企業環境にデプロイされることが多いので，OCSPステープリングやPKIの統合といった高度なセキュリティメカニズムが予め組み込まれています。
InfoQ: IoT通信プロトコルの進展についてどう思われますか？ひとつの共通標準に向かって収束しているのでしょうか？MQTTの将来においては，どのようなことを想定していますか？
Obermaier: IoTのユースケースは数が多いので，今後もさまざまなタイプのIoT通信プロトコルが存在することになるでしょう。ひとつの標準プロトコルが現れるとは思いません。ただし，最近の調査データを見ると，MQTTとHTTPが主流となっているようです。当社ユーザのデプロメールでも同じ傾向があります。
MQTTの将来という点では，エッジコンピューティングの通信プロトコルとしての採用に注目しています。エッジノードが相互通信を行ってネットワークメッシュを構成する場合，これは特に重要になります。MQTT-SNがメッシュネットワークの潜在的なソリューションとして，今後数年間で採用されていくでしょう。
これからはMQTTの時代であることは明らかなので，特に大規模デプロイメントにおいて，今後も採用事例が増え続けるものと思っています。