本記事のタイトルはいわゆる「釣り」です。MQTTは、最近ではMQTT5がリリースされるなど現在でも進化を続けている、とても洗練された使いやすいプロトコルです（本記事にMQTTを貶める意図は一切ありません）。
弊社アプトポッドでは、MQTTよりもターゲットを絞ったニッチな領域に向けた独自プロトコル “iSCP” を開発しております。本記事では、せっかく釣られてくださった皆様に、その “iSCP” の魅力について少しばかりご紹介できればと思います。
なお、本記事は aptpod Advent Calender 2022 の 21日目としてお送りします。
はじめに
お久しぶりです。VPoPの岩田です。昨年1月末に QUIC DATAGRAMに関する記事 を書いてから、忙しさにかまけてテックブログ投稿をサボっていたら、なんと2年弱もの長い年月が過ぎ去っていました。これはイカンということで、重い腰を上げて久しぶりに記事を書いてみることにします。
肝心の記事の内容についてですが、実は先日12月5日、弊社の業務提携先で出資元でもある株式会社マクニカ様が開催された MET2022（Macnica Exponential Technology 2022） というオンラインイベントに、弊社CTOの梶田と一緒に登壇しましたので、そのときにお話しした内容を再構成してご紹介したいと思います。
内容はズバリ「弊社の独自開発プロトコル iSCP（intdash Stream Control Protocol）とはナニモノか」になります。MET2022では、マクニカ様が企画・開発されているFMS（Fleet Management System、遠隔運行管理システム）についてのご紹介がメイントピックで、そのFMSを裏側から支えるテクノロジーという位置づけで弊社のiSCPについてもご紹介させていただきました。本記事ではその登壇のなかから、iSCPに関する部分のみを抜粋してご紹介いたします。
本記事では、以下の内容をご紹介します。
- 弊社ユースケースにおいてMQTTに不足していたポイント
- 弊社の独自プロトコルiSCP開発の経緯
- 弊社の独自プロトコルiSCPの特長
以下のような方には、なにかヒントになるかもしれません。
- メッセージ配送ミドルウェアをどう選定したらよいのかわからない
- 大量・高頻度なデータの伝送がうまくいかなくて困っている
- MQTTが苦手とするユースケースについて知りたい
2024/01/18 追記
MQTT5に関する連載始めました。ご興味お持ちいただけましたら、こちらも併せて覧ください。
そもそもintdashとは
iSCPをご紹介する前に、まずはiSCP（intdash Stream Control Protocol）が頭に冠しているintdashがそもそも何者かについてご説明しなくてはなりません。intdashは、弊社が開発している産業用IoTプラットフォームです（プラットフォームの名称であり、プラットフォームを構築するためのミドルウェア製品の名称でもあります）。
自動車や自律ロボットなどの高機能マシンを主にターゲットとして、それらが吐き出す大量かつ高頻度なIoTデータを、インターネットやLTE網などを利用してクラウドに集めたり、遠隔地に中継したりすることができます。intdashを用いることで、様々なIoTデバイスや高機能マシンをコネクテッド化し、相互に通信させることが可能になります。
intdashが持つ主な特徴は以下の3つです。
- 【データの伝送】IoTデバイス間をリアルタイム伝送でつなぐ
- 【データの保存】伝送されたデータはクラウドに蓄積する
- 【データの活用】蓄積されたデータにアクセスするAPIを提供する
1つめのintdashのリアルタイム伝送機能の実現のために、 intdashのサーバーとクライアントの間で使用されるプロトコルが、本記事のメイントピックであるiSCP（intdash Stream Control Protocol） になります。
iSCPが必要とされる背景
前述のとおり intdash / iSCPは自動車や自律ロボットなどの “高機能マシン” のコネクテッド化を主にターゲットとしています。このようなマシンでは、高機能であるが故に内部のバス上で大量のデータが飛び交っていますが、大量のデータに対してはデバイス側で集約・抽出処理を行い、サマリデータのみをクラウドに送信するアプローチを取ることが一般的です。
これは、大量のローデータ（生データ）をそのまま送信する方法では、消費帯域が多く回線費用がかさんだり、そもそもLTE回線では帯域が足りなかったり、デバイスの性能が送信処理に耐えきれなかったりと、様々な問題が発生するためです。
一方で、弊社が長らく支援させていただいている自動車の研究開発分野など、ニッチではあるものの一部のケースにおいて、このような事前処理のアプローチが取りづらい領域があることも分かっています。intdashは、試作車両のテストや各種車両からのデータ取りなどでご利用いただくことが多くありますが、これらのお客様にとっては、ローデータこそが取得したいデータであって、集約されてしまったサマリデータでは意味が無いからです。
ものづくり大国日本における ”ものをつくる側” の皆様のデジタルトランスフォーメーションをお手伝いするため、ものづくりにおいて不可欠な "計測器"をそのままクラウド上に移動させてしまうもの だと捉えていただくのが最もイメージに近いでしょうか。このようなユースケースにおいて、大量・高頻度なローデータの収集や伝送を実現するため、以下のような目的を持って開発されたプロトコルがiSCPになります。
- 伝送の低遅延化: すばやいトライアンドエラーを実現するため、リアルタイムに状態が把握できることは大きなメリットとなります
- 伝送効率の向上: 大量のデータからなるべく冗長性を排することで、モバイル回線の細い帯域を有効活用します
- 保存データの高信頼化: データ欠損なく保存しきることをプロトコルレベルで保証することで、安心して収集データを活用できます
- 多様なデータへの対応: 多様なデータを統一的に扱える仕組みとすることで、様々な試行錯誤に柔軟に対応できます
弊社の主力商品であるWebベースの可視化ダッシュボード「Visual M2M Data Visualizer」も、iSCPを使用して実現しているプロダクトのひとつです。 自動車などのマシン側から打ち上げられた大量データをWebアプリケーションで受け取り、ブラウザ上のダッシュボードで可視化するツールですが、 マシンからブラウザまでデータを届ける際のプロトコルとしてiSCPを使用しており、打ち上げられるデータが大量になってもブラウザでしっかり可視化することができます。
intdash / iSCPの適用先
ちなみに、intdashの適用領域は前述した研究開発領域のみにとどまりません。たとえば最近では、デリバリーロボットをはじめとするAGV/UGVの監視などにおいて、「普段はサマリデータだけで良いけれども、事故などの問題事象が発生した場合にはすべてのローデータをかき集めてすばやく状況把握や原因解析を行いたい」といった要望をいただくケースが出てきています。
このように、IoTのコモディティ化に伴って、ニッチな研究開発領域だけでなく一般のIoTサービスにおいても 「いざというときのために」すべてのローデータをリアルタイム伝送できるケイパビリティを備えておきたい、という志向が生まれつつある ように感じています。
また、AGV/UGVなどのユースケースでは、ロボットが自律的に対処できない場面に直面した場合のために遠隔操縦機能を備えておくと安心ですが、 遠隔操縦などを行う場合にも高頻度データの低遅延伝送は効果を発揮します。現状、遠隔操縦はまだそこまで広く社会実装されている状況ではありませんが、今後自律ロボットの普及に伴って、ロボット管理プラットフォームやそれに付随する遠隔操縦機能の需要も高まってくるのではないかと考えており、intdashはそのような領域にも適用可能です。
その他、intdashをバックエンドに使用したソリューションとして、最近新しいプロダクトをいくつか発表しておりますので、よろしければこちらもご覧ください。
自動車業界向け ECU遠隔適合ソリューション「Automotive Pro Remote CAL」 tech.aptpod.co.jp
モビリティ・ロボットの管制制御ソリューション「intdash Control Center」 tech.aptpod.co.jp
もちろんintdash自体は、データを伝送・蓄積・活用するための汎用的なプラットフォームになりますので、 これらの活用例に限らず、様々なサービスやソリューションのバックエンドとしてご活用いただけます。
なぜMQTTを使わなかったのか
ここからやっと本題に入ります。ここまで読み進めてくださった皆様がおそらくお持ちであろう 「IoTのリアルタイム伝送ならばMQTTがあるじゃないか、なぜそれを使わなかったんだ？」 という疑問にお答えします。
実は以前、弊社でもMQTTを使用してリアルタイム伝送機能を実現しようとしていたことがありました。しかしながら、MQTTでは、研究開発領域で求められる要件（リアルタイム性と確実なデータ永続化の両立）を実現することができず、泣く泣く使用を諦めたという過去があります。では、MQTTの何がいけなかったのか。
高頻度メッセージに対して低遅延性を実現できなかった
MQTTは一般的に、エンドツーエンドで低遅延にデータを転送できるプロトコルとして知られています。これは、PubSub型のメッセージングパターンの採用と、軽量でシンプルなプロトコル仕様により実現されています。MQTTは確かに、 「あるクライアントから送出されたデータが別のクライアントに到達するまでの時間が短い」 という意味で、低遅延伝送を実現可能なプロトコルです。
しかしながら、このプロトコルを "高機能マシン" が吐き出す大量データの伝送に適用するとどうなるでしょうか。一般的に自動車が吐き出す車両データ（CANデータ）は、秒間数千フレーム〜1万フレームにもなります。例えば、この大量フレームをMQTTのメッセージにそれぞれ詰め込んで送信したとすると、 少なくとも開発当時のMQTTブローカーでは、すべてのメッセージを送りきれる程のスループットが出ませんでした。
メッセージを送りきれないということは、各メッセージはその分滞留することになり、結果としてメッセージ配送に要する時間は増大します。要するに、メッセージ一つ一つの転送自体は低遅延に実現できるものの、大量のメッセージを送りつけるようなケースではメッセージの滞留によりリアルタイム性が損なわれてしまう、ということになります。さらに悲しいことに、 スループットの上限値は、QoS（メッセージの転送品質）の設定を上げるとさらに低下します。
世の中には、MQTTブローカーのスループットを調査したベンチマーク結果も多くありますが、その多くは、 複数のクライアントから同時にデータ送信を試行することで、クライアント全体として数万メッセージのスループットが出ることを確認するもの です。クライアント数が増えるケースについては、サーバーをクラスタリングして水平スケールにより対応することもできますが、我々が対峙している1台単体で数千〜数万のメッセージを生成してしまうようなケースでは、単にサーバー台数を増やせば解決というわけにはいきません。
このようなケースに耐えうるMQTTブローカーは、少なくとも企画当初は世の中に存在せず、intdash / iSCP開発の大きなきっかけとなりました。
※ MQTTの名誉のために若干のエクスキューズを入れておくと、これはMQTTの性能が悪いと言っているわけではありません。 MQTTは、1クライアントから受け取れるメッセージ数については弊社の要件を満たしませんでしたが、その代わりに水平スケールさせやすい仕様になっていると思っています。 一方で弊社のiSCPでは、1クライアントから受け取る大量メッセージを捌き切るためにステートフルなデータ保持の仕組みを敢えて導入したり、とにかく大量のデータを捌き切ることに仕様を全振りしています。 これは、あくまで対象とするユースケースの違い・プロダクトの思想の違いであって、どちらが良い悪いというものではありません。 ユースケースによっては、よりMQTTが適している場合もあれば、iSCPが適している場合もあり、適材適所でプロダクトを選択していけばよいだけのことです。
伝送効率化のために、結局 X over MQTT が必要になった
前のセクションを読まれた皆様の中には、 「1データずつ1メッセージで送信するからメッセージ数が膨大になるのであって、複数メッセージをまとめて送ればよいのではないか」 と気づいた方もいらっしゃると思います。そのとおりです。あくまでメッセージ数が多すぎることが原因なので、複数データをまとめて大きめなメッセージにしてからバルク送信すれば、スループット不足の問題はある程度回避することができます。一見、この方法で問題は解決できるように思えますが、これはまた別の問題を引き起こします。
バルク送信を採用するということは、MQTTのペイロードへのデータの格納方法として所定のフォーマットを定義するということです。これは、MQTTの上層にさらに別のプロトコルを定義することに相当します（X over MQTT）。このアプローチを取った場合、 各クライアントは MQTT のプロトコルに準拠しつつ、MQTT上に想定されているフォーマットに合わせた形式でMQTTのペイロードを構築して送信しなければなりません。すなわち、そのプロトコルは下層にMQTTを採用してはいるものの、MQTTで定義されている仕様に従っただけのクライアントからは通信ができないことになります。
これはたとえば、HTTPは主にTCP上のプロトコル（= HTTP over TCP）ですが、HTTPサーバーとただのTCPクライアントで通信するには、クライアント側にさらにHTTPを解釈するための自前実装が必要になることと同じだと考えていただければ、分かりやすいでしょうか。
MQTTを下層に使用したとして、結局その上層に独自のプロトコルを定義するのであれば、下層はわざわざMQTTに縛られる必要はありません。幸い、MQTTのプロトコル仕様は極めてシンプルで、MQTTブローカーにより提供される機能性の実装はそこまで複雑なものではないため、MQTTに依存することによって課せられる制約と、独自にプロトコルを定義するコスト とを天秤にかけた結果、弊社では独自のプロトコルを開発することを選択しました。
データの確実な永続化に対応できなかった
主にデータ収集用途で使用されることが多かったintdashでは、集めたデータの信頼性についても高い要件を課せられていました。 サーバーに送信されたデータは、取りこぼすこと無く確実にデータストアに保存しなければなりません。しかしながら、この機能性を既存のMQTTブローカーを用いて実現しようとすると、アーキテクチャが複雑化してしまうという問題がありました。
もちろん、MQTTにもQoS（メッセージの転送品質）という考え方があり、 "伝送経路での欠損については" 検出することができます。一般的に言われていることですが、この "伝送経路での欠損については" の部分が注意を要するところで、 MQTTのQoS設定を上げたとしても、エンドツーエンドでの欠損については検出することができません。
どういうことかというと、例えばパブリッシャーとサブスクライバーが存在した場合、検出ができるのはあくまで パブリッシャー〜ブローカー間 と ブローカー〜サブスクライバー間 それぞれの経路についてのみであって、例えば極端なケースでは、パブリッシャーからブローカーへ転送されたあと何らかのエラーによってデータが消失してしまうと、それをパブリッシャーは検出することができない、ということになります。
既存のMQTTブローカーを用いてリアルタイム機能およびデータの確実な永続化機能を実現しようとすると、データを永続化するクライアントをサブスクライバーとしてブローカーにぶら下げ、永続化サブスクライバーがデータストアへデータを保存することになりますが、このような形式では 送信クライアントからデータストアまでのエンドツーエンド経路におけるデータ欠損の可能性を排除することができず、結局MQTT上で独自のプロトコルを定義しなければならなくなります（前のセクションでも登場した X over MQTT という形になります）。
前のセクションでも言及したとおり、MQTTのプロトコル仕様自体は極めてシンプルで、同様のものをイチから考案することもできなくはありません。 MQTT上に独自プロトコルをスタッキングするくらいなら、はじめから独自のプロトコルを作ってしまったほうが柔軟でシンプルなものができあがるだろう ということで、さらに独自プロトコルの開発に踏み切る機運が高まりました。
もちろん世の中には、「プロトコル自体はMQTTを採用し、MQTTの標準仕様には無い機能性を追加した独自ブローカーを作る」というアプローチを取っている商用MQTTブローカーも存在します（このようなブローカーは、intdashの競合ということになります）。このようなアプローチを取るメリットは、一般のMQTTのライブラリやツール群を流用できることにあります。しかし、それと引き換えに、 MQTT標準仕様の範囲から逸脱しない範囲でしか機能を拡張できない、MQTTの仕様改訂への追従など自社でコントロールできない仕様変更リスクを抱える、などのデメリットもプロダクトに内包させる ことになります。
弊社としては、MQTT標準仕様の範囲だけでは実現できない機能性を追加したかったこと、テックベンチャーとしてMQTTに競合するような新しいプロトコルの確立に挑戦してみたかったことなども含め、メリット・デメリットだけでなく開発メンバーの思いやビジネス的な思惑等、様々なことを考慮して総合的に判断した結果、iSCPという独自プロトコルを開発することを選びました。
iSCPの特長
ここまで説明したMQTTを採用するにあたっての課題に対して、X over MQTT から派生して、MQTT部分も含めてすべてオリジナルなプロトコルスタックにより定義したものがiSCPです。 さらに、MQTTのようなPubSub部分も含めて独自で定義したため、MQTTにはない機能性もいくつか追加することができました。
iSCPの特長には様々なものがありますが、特徴的なものだけを拾い上げると、まずは大量・高頻度なデータを効率よく伝送できるように以下の特長を持っています。 これらの特長により、MQTTでは難しかった大量・高頻度なデータの伝送処理を実現しています。
- 複数データをまとめてバルク送信（もちろんバルクサイズは調整可能）
- メタ情報をあえてステートフルに保持することで、通信オーバーヘッドを削減
- WebSocketを参考にしたメッセージ圧縮方式の採用
また、主に研究開発にて要求されるリアルタイム性と確実な永続化の両立のため、以下の特長も備えています。
- ブローカーはデータを受信したら最優先で転送（永続化処理はあと回し）
- クライアントへのAckは永続化処理が完了してから返却
- Ackにより永続化確認ができないデータは別途あとから永続化
クライアントへのAck返却タイミングが永続化処理完了後となっている点がiSCPの特徴的な部分です。多くのプロトコルではAckは通信経路での到達確認や順序保証に使われるため、ある程度のAckが返却されない場合にはAck待ちにより送信が停止してしまいますが、iSCPにおいてはサーバーへデータが永続化されたかどうかの確認に用いられるものであるため、Ackの返却は必ずしも待つ必要がありません。大量にデータを送りつけ、欠損があった場合には検出だけしておき、帯域に余裕があるときに改めて欠損部分だけを永続化処理する、というのが iSCP の基本の考え方になります。
このような仕様により、 伝送時にはリアルタイム性を最優先に転送を行いつつ、後からではあるものの取りこぼすことなくデータを回収できる ようになっています。 このような機能性は、弊社でも実績の多い研究開発におけるデータ収集のユースケース（データを可視化しながらトライアンドエラーを行い、最終的にはすべてのデータを収集し切りたい）と極めて相性がよいものです。もちろんそれだけでなく、たとえば遠隔管制・フリート監視のようなユースケースでは監視時にはリアルタイム性が、事故発生時の解析等でにはデータの信頼性が重要なファクターとなるなど、研究開発以外のユースケースにおいても効果を発揮します。
また、最近では遠隔管制に関連して、ロボットに対する遠隔操縦に対する要望もいただくようになってきています。 このようなケースでは、データの詰まりによってリアルタイム性の失われやすいストリームベースの通信方式よりも、データグラムベースの通信方式が好まれる傾向があります。
このような要求にも応えられるようiSCPは現在も日々進化を続けており、iSCPのメジャーバージョンアップに向けて現在準備を進行しております。 メジャーバージョンアップ前の現行バージョンでは、下層に使用するトランスポートプロトコルとしてWebSocketしか選択できませんでしたが、 メジャーバージョンアップ後のバージョンでは、データグラムベースの通信方式に対するサポートが追加され、 WebSocketに加えて最新のトランスポートプロトコルであるQUICやWebTransportも使用可能となる予定です。
さいごに
いかがでしたでしょうか。弊社がなぜMQTTを捨て独自プロトコルの開発に踏み切ったのか、また、その結果生まれたiSCPがどのようなプロトコルなのか、この記事でお伝えできていれば幸いです。また、前述のMET2022にてご一緒させていただいたマクニカ様のFMS（Fleet Management System）のように、intdashやiSCPが持つ特長に少しでも興味や魅力を感じていただけましたら、ぜひとも皆様ご担当のシステムへの導入をご検討ください。
iSCP のクライアントライブラリ はオープンソース化していますので、どなたでも自由にご利用いただけます。また、プロトコル仕様書 も公開可能なものを用意しておりますので、プロトコル仕様をよく精査して導入をご検討いただけます。サーバーソフトウェア や弊社が運用する マネージドサービス は有償でのご提供となりますが、フリートライアルのプラン もご用意しております。その他些細なことでも構いませんので、プロダクトに関するお問い合わせについては、 弊社営業までご連絡ください。（私自身も、弊社プロダクトの開発責任者として全力でサポートさせていただきます）
結びとなりますが、アプトポッドではintdashやそれを取り巻く周辺プロダクトの販売だけでなく、intdashを活用したシステムインテグレーションや受託開発も行っております。当社が直接お手伝いをするだけでなく、当社が認定した信頼と実績のあるパートナー企業様にて、ご対応させていただくことも可能です。本記事でご紹介できなかった弊社のプロダクトやビジネス全般につきましては、弊社のコーポレートサイトをご覧ください。
「IoTシステムを構築したいがどんなアーキテクチャがよいのかわからない」「MQTTで構築した既存のIoTシステムがあるが限界を感じている」など、IoTシステム構築に関する一般的なご相談につきましても、お問い合わせいただければお力添えいたします。
※ 本記事をお読みいただき、アプトポッドのプロダクトやエンジニアリングに興味を持ってくださったエンジニアの方々からの連絡もお待ちしております。
まずはカジュアルな情報交換からでも構いません。会話をさせていただくなかで、募集中の職種をご紹介させていただきます。（採用ページはこちら）
最後までお読みいただき、ありがとうございました。
皆様よいクリスマスと年末をお過ごしください！ 🎄🎍
