クラウド、モバイル、ソーシャル、そしてビッグデータ。4つのトレンドが今、エンタープライズITの世界に大きな変化をもたらそうとしている。さらに、これらと密接に関係する「モノのインターネット(Internet of Things)」や「M2M(Machine-to-Machine)」の胎動も始まった。あらゆる"モノ"に埋め込まれたセンサー同士が会話することで、これまで想像もつかなかったような未来が訪れる。そこでのキーテクノロジーを理解することの重要性が日増しに高まっている。
全長１万7000kmのパイプライン。温度や流量、圧力などを検知する3万個もの各種センサーを随所に設置し、きめ細かな動作状況を一元的に監視する。もし油圧の急減といった緊急事態を検知したなら元栓を閉じるコマンドを自動的に送って対処。この間、わずか数秒のことであり、保守要員の到着を待たずして、危険を回避することを可能としている─。
M2Mを活用したリアルタイムの制御と保守というこの事例は、既に実現されているものである。M2Mは社会インフラのみならず、医療や自動車などの分野でも適用事例が増えているし、今後は様々な業界で可能性を探る動きがにわかに活発化してくるとみられる。
M2MやIoTの世界を支えるテクノロジーとして、センサーやストリーミング処理を思い浮かべる人は少なくないだろう。しかし、意外と見落としがちで、今後の本格的普及に向けて特に考慮しなければならないものとして「プロトコル」の問題がある。センサーや高度なデータ処理技術を組み合わせ、安全かつ豊かで合理的な社会基盤を創出しようとする「Smarter Planet」構想を早期から掲げて取り組んできたIBMは、どうとらえているのか。
ソフトウェア事業
WebSphere
テクニカル・セールス＆ソリューションズ
ICP - エグゼクティブ ITS
鈴木徹氏
「M2MやIoTを実現しようとする時、現状で最も使われているプロトコルはHTTPです。様々なデバイスで利用できる反面、ワイヤレス通信やセンサー同士の会話には最適化されておらず無駄が多い。膨大なデータのやり取りを考えると、もっと軽量なプロトコルが必要なのです」と語るのは、日本IBM ソフトウェア事業 WebSphere テクニカル・セールス&ソリューションズ ICP - エグゼクティブITSの鈴木徹氏だ。
センサーが1回の通信で送るデータ量は数十バイト程度と非常に小さい。これを短時間に何十回も送受信するのがM2Mの世界。さらに1:1のみならず1:Nの通信も多用される。ここで、ヘッダなどのサイズが大きいHTTPではオーバーヘッドがかさんでしまうのだ。「ワイヤレス環境を念頭に、イベントが発生するタイミングでリアルタイムに通信でき、しかもデータロスを起こすことなく確実にモノ同士の会話を成立させる最適なプロトコルが不可欠。そこでIBMが開発したのがMQTTなのです」と鈴木氏は説明する。
M2Mに最適化させたプロトコル「MQTT」
MQTTとは"MQ Telemetry Transport"の略で、はじめからIoTやM2Mに最適化させるために開発された、デバイス間通信のための新しいプロトコルだ。仕様はオープンソースで公開されており、Facebookメッセンジャーに実装されていることでも知られている。なお、MQTTの"MQ"は「WebSphere MQ」などIBMのメッセージング関連製品に付けられているMQ(Message Queuing)に由来している。当然、これまでのMQの展開で培ってきた知見が新プロトコルにも凝縮されている。
鈴木氏によればMQTTの特徴は大きく以下の3点に集約されるという。
まず、HTTPに比べて圧倒的に軽量であるという点だ。ヘッダサイズはわずかに2バイトながらも、APIとしてきちんと定義されているのでデータを生でpushすることができる。トラフィック量はHTTPの1/10になるため、実質的にスループットが10倍になる。また軽量であるため、デバイスの電池使用量が1/10以下になるというメリットもある。
2つめは非同期/双方向通信を実現するプロトコルである点だ。鈴木氏は「例えて言えばHTTPは電話のようなもので、必ず相手がいないと会話ができません。それに対しMQTTはメールやチャットに似ていて、相手が必ずしもリアルタイムでいる必要がなく、後からメッセージを読んでもらってもいい。つまり双方向でありながら非同期な通信を可能にします」と説明する。これは、例えばネットワークが不安定な状況下で有効に機能する。
また、MQTTは1対Nの通信を実現するPublish/Subscribe型メッセージ通信を実装しており、大量の同報通知なども可能にする。「送信側と受信側を疎結合させるので、パブリッシャーとサブスクライバーの立場が入れ替わっても構いません。サービスの品質を担保するためのオプションも充実しています。例えば、”メッセージを重複することなく、1回だけ、しかも確実に相手に届ける”といった指定が可能です。アプリ側でこのしくみを作ろうとするとかなり大変ですが、プロトコル単体でできることが多いので開発に柔軟性をもたせることが可能です」（同）。
そして3つめは、誰もが無料で利用できる点だ。標準化を進めれば、サードパーティによるデバイス開発コストの削減にもつながる。現バージョンのMQTT v3.1はOASIS標準化作業を進めており、M2M標準のプロトコルとしてさらに広く普及を図っていく構えだ。プロトコル自体がシンプルな作りであることもオープン/スタンダードを重視するIBMの姿勢が反映されている。
軽量で非同期/双方向、そしてオープンという、MQTTの3つの特徴を活かしたアプリを開発してもらうため、IBMはMQTTの開発環境(Java/JavaScript/C)を無償で提供している。「MQTTプログラミングには特別なスキルは必要ありません。JavaやCの開発者であれば難なくコーディングを習得できるでしょう。ひとりでも多くの開発者にMQTTネイティブなアプリケーションを開発してもらいたいですね」と鈴木氏は話す。
MQTTを最大限に活かすアプライアンス「MessageSight」
MQTTをベースにしたM2MやIoTを本格的に実現したい企業のために、IBMはメッセージングゲートウェイアプライアンスとして「IBM MessageSight」を提供している。
デバイス間で送受信した情報の集約手段として、IAサーバを数多く並べているケースは少なくないが、鈴木氏は「IAサーバをM2Mの基盤にすれば、キャパシティプランニングがボトルネックになる。相手が機械なので見積もりもチューニングも非常に困難」と指摘する。またクラウド上のインスタンスをデータ集約先とするアイデアについては「レイテンシが致命的」だという。
そうしたチューニングなどをいっさい必要とせず、1台でM2Mのバックエンドとなり得る存在がMessageSightだ。最大の特徴はアプライアンス1台で100万台ものデバイスの同時接続をサポートできること。メッセージ処理能力は秒間1000万件以上であり、「正直、このスペックで対応できない案件を見たことがまだありません」(鈴木氏)というほどの高い性能が特徴だ。
加えて、アプライアンスの特徴でもある導入の容易さも大きなメリットだ。鈴木氏は「MessageSightは箱を開けた30分後に本番環境での稼働が可能」とその手軽さを強調。管理画面もWebベースのGUIで分かりやすい。「スキルや経験がなくてもM2Mを活用できるということが実感できるはずです」(鈴木氏)。
もちろんセキュリティに関してもIBMならではの力の入れ方だ。アプライアンスという専用ハードウェアとファームウェアの組み合わせにより、DMZに配置可能なセキュアな基盤を提供する。また高可用性(HA)構成も可能だ。
MessageSight導入事例としては、米国Sprint社による「Sprint Velocity」が有名だ。これは、自動車の座席位置や、ラジオ、カーナビなどをリモート設定するサービス。例えば、オーナーがモバイルデバイスのアプリからドアオープンキーを押すとSprintがユーザーを認証し、自動車にコマンドが送られ、アンロックされる。以前はHTTP経由だったため一連の処理に60秒ほど要していたが、MessageSightを導入したことでパフォーマンスは劇的に改善されたという。
このほか、冒頭に触れた石油パイプラインのリアルタイム制御や、病院におけるペースメーカー管理の現場などでMQTTプロトコルが使われ、今後、MessageSightの導入も検討されている。導入事例も続々と増えている。「M2MプロトコルとしてのMQTTを活かすメッセージングハブとしての存在、それがMessageSightです」と鈴木氏。なお、MessageSightはあえてHTTPをサポートしていない。デバイス間通信にはMQTTが最適というIBMの強い自信が、そこには見える。
