本文へジャンプします。

ニフティクラウド MQTT のご紹介(前編)

こんにちは。ニフティクラウド MQTT 開発に携わっている もりふじ です。

ニフティクラウドでは IaaS だけでなく RDB や Message Queue、ESS といった、アプリケーション開発に役立つミドルウエアを、簡単に利用できる機能を提供しています。これに加え、5月11日にニフティクラウド MQTT をリリースしました。

MQTT といえば、すでに 時雨堂さんsangoCloudMQTT などがリリースされており、ご存知の方も多いかもしれません。

これから前編/後編に渡り、今回リリースしたニフティクラウド MQTT について執筆したいと思います。
今回は MQTT についての簡単な紹介と、MQTT 利用に適したケース/必ずしも MQTT を利用しなくてもよいケースについてお話します。次回は、ニフティクラウド MQTT 開発において選定した OSS のベンチマーク取得結果や、そのプラグインへのコントリビュートについてお話ししたいと思います。

1. MQTT とは

sango の 「MQTT について詳しく知る」 を見ていただければとは思いますが、簡単にご説明します。

MQTT.org には、以下のようにあります。

MQTT is a machine-to-machine (M2M)/”Internet of Things” connectivity protocol. It was designed as an extremely lightweight publish/subscribe messaging transport. It is useful for connections with remote locations where a small code footprint is required and/or network bandwidth is at a premium.

MQTT は machine-to-machine (M2M) / “Internet of Things” 接続性の高いプロトコルです。
非常に軽量な publish/subscribe 型のメッセージ転送として設計されました。
コードのフットプリントが小さいこと、かつ/またはネットワーク転送が非常に高い場合のリモートコネクションの時に有効です。

というように、下記のような特徴を備えたプロトコルです。

  1. 小さな通信ヘッダ
  2. 1対多、多対多の Pub/Sub 型

1.1. 小さな通信ヘッダ

小さな通信ヘッダについて、少しだけ解説します。

curl コマンドで www.google.com に向けて GET リクエストを投げたときのリクエストヘッダは、次のようになります。

GET / HTTP/1.1
User-Agent: curl/7.37.1
Host: www.google.com
Accept: */*

サイズとしてはこれで 71 バイトです。
User-Agent および Accept は省略可能。また、 Host が自明な場合も省略できますから、

GET / HTTP/1.1

ここまでは小さくできます。それでも 14 バイトです。

これに対して、 MQTT では MQTT V3.1 Protocol Specification にある通り、通信に要するヘッダのサイズは最小 2 バイトで、14 バイトから 12 バイト分も省略できることになります。ヘッダが小さいことで生まれるメリットについては後述します。

1.2. 1対多、多対多の Pub/Sub 型

MQTT は Pub/Sub 型のモデルとなっています。
1 対 1 での通信ではない、中心に MQTT ブローカーをおいたモデルですから、 Publisher と Subscriber が P2P で接続し、組み合わせの数だけ通信コストを低くすることが出来ます。

2. MQTT に適したケース / MQTT でなくともよいケース

2.1. 適したケース/適していないケース

とても小さなヘッダであるということは、通信帯域が制限されている場合、または通信が高コストの場合に意味を持ちます。また、データ転送を行わないで済む、ということはデバイスはその分だけ電力消費量が少なくて済み、ひいてはバッテリーが長持ちするということになります。

先の特徴でも上げたとおり、 HTTP のヘッダを最も小さくした時の差である 12 バイトというのは大きいようで、実は大したことがありません。
あくまで「通信したいデータに対するヘッダの比率が大きい時」に 12 バイトは価値となってきます。

メッセージにおける、全体の通信量におけるヘッダの比率は次のような式で計算できます。

r = body / (body + header)

メッセージサイズ (byte) HTTP MQTT
2 0.125 0.500
22 0.611 0.917
100 0.877 0.980
1000 0.986 0.998

メッセージ全体のサイズが大きくなればなるほど、12 バイトの意義が小さくなっていくのが見て取れると思います。1000 バイトのメッセージを送信するとしたら 12 バイトは誤差と言えると思います。

ただし、ビッグデータのコンテキストと組み合わせて語られる文脈が多いように、通信コストが膨大であれば 12 バイトの価値が大きくなってきます。
Facebook のメッセージが MQTT を利用している理由として、 トータルでのネットワーク利用量、つまりコストがバカにならないと考えた結果だと考えられます。
その他にも、センサーの数が数万~数千万と膨大な数になってきた場合にも大きな価値となります。

同様の理由で Connection をあまり使い回せない状況かつセキュアな通信が求められる場合は、 1 回の Publish に対して毎回認証を含めた接続を行うとコストが大きいため、やりとり全体として 12 バイトの差が小さくなってしまい MQTT の価値が小さくなってきます。

いくつかの事例や、ヒアリングを行っていると「それ HTTP/S でよくない? MQTT である必要ないんじゃ?」ということを耳にします。

2.2. MQTT 適していない事例

たとえば、

  • 「ネットワークアダプタを介して情報を集約し、それをクラウドに貯めたい」
    • データを貯めることが目的であれば、1 対多のメッセージ配送は不要な上、通信帯域もそれほど気を使わなくてもいいはずです。
  • 「電源を取得できる機器であり、それほど頻繁に Pub/Sub しない、またはネットワーク帯域が十分に確保できる」
    • 帯域の心配がなくて、電源が取得できる状況でしたら、扱いやすいその他のプロトコルを選定することも考えましょう。
  • 「Publish ごとにセキュアな接続を行わなければならないような不安定な電波状況での利用」
    • 認証のやりとりをするのであれば、もはやヘッダの 12 バイトとか誤差です、誤差。

など、メリットである 1対多や小さいヘッダが活かせないのであれば別のソリューションを比較することを検討する方が良いかと思います。

2.3. まとめ

サービス全体として、メッセージサイズとヘッダのサイズの比を鑑みた上で取り回しのし易い HTTP/S を利用するのか、 MQTT を利用するのかを考えていくことが必要だと思います。

最後に

今回は MQTT について、そして必ずしも MQTT でなくとも良いケースをご紹介しました。次回は MQTT の実装毎のベンチと、実際に私たちが選定した mosquitto とそのプラグインに送ったコントリビュートについて紹介します。

ニフティクラウド 導入相談窓口
ニフティクラウド 無料セミナー

閉じる

閉じる

クラウドブログ編集部

クラウドブログ編集部

ニフティクラウド ユーザーブログ編集部のアカウントです。 編集部からのお知らせや、レギュラーライター以外のゲストによる寄稿記事を掲載していきます。

浜中 慶

浜中 慶

1980年、神奈川県生まれ。2003年ニフティ入社。 ポータルサイト開発を中心に、音楽配信サービス、CGMサービスなど様々なプロジェクトに企画/デザイン/システム担当として参加。現在は@niftyのポータルサービス向けコンテンツ管理システムの企画/開発/運用を担当。

吉田 雄哉

吉田 雄哉

株式会社co-meetingの創業メンバー。「取締役&External- facing Technologist」と名乗り新しいIT技術を広く伝える活動とWebアプリケーション開発を行う毎日。パッケージベンダーでのSaaS立上げ・製造業の情報システム部門で企画やPM・受託開発と従事してきたため、ベンダーサイドとユーザサイド の両方の視点を持ち合わせる。

石田 健亮

石田 健亮

株式会社ドリーム・アーツで小売事業者向けSaaS「Shopらん」を企画、開発。メインの仕事はプログラマーだがサーバー管理や営業もこなすユーティリティプレイヤー。最近好きな事はパフォーマンスチューニング。特に並列化プログラミングがマイブーム。キライなことはデータセンターでの作業。騒音と乾燥が弱点。ニフティクラウドでデータセンターに行く必要が無くなったことが本当の利点だ と思っている。

五月女 雄一

五月女 雄一

ニフティでは「インフラを守る簡単な様で奥が深いお仕事」をしています。 夢はインフラの気持ちが読めるエンジニアになること。

わたなべ かずひろ

わたなべ かずひろ

専門学校卒業後、ソフトウェア開発会社で電力系統制御システムの開発に従事。その後、CD-ROM等マルチメディア系PCソフトの開発を経て、1998年フリーランスに。 2000年8月に株式会社イーツーの設立に参画。携帯を含む様々なWeb系のシステム開発に携わる。現在はiPhone/Androidアプリなどの開発も手がけている。

市角

市角

ニフティクラウドのコントロールパネル設計・開発をメインに、たまにインフラの運用やお手伝いもやっていたりします。コントロールパネルや新機能の活用方法、アイデアなどを中心に書いていく予定です。

仲山 昌宏

仲山 昌宏

歌って踊れるインフラエンジニア兼、PHPもRubyもJavaも書くPerl使い。 物理サーバの運用に飽きて、フルラックに格安サーバ詰めて自宅プライベートクラウドを構築中。 今年は個人的には分散処理を攻めていきます。

猪飼 賢広

猪飼 賢広

1984年、愛知県名古屋市生まれ。大学は福島県にある某大学。2008年ニフティに入社。 開発系部署に配属後、主に各種テーマサイト開発のシステム面調整、開発進行管理役などとして参加。 現在もPC・ガラケーサイトの開発まわりを担当。インフラまわりを触る案件にも携わっており、日々修行中。 好きな芸人はなかやまきんに君とレイザーラモンRG。

久江 裕之

久江 裕之

ニフティクラウドのインフラ運用、OS提供の仕事をしています。 新しいOSやイメージが出る時にこのブログでご紹介いたします。入社5年目。一流のインフラエンジニアを目指して日々勉強中。

竹内 豪

竹内 豪

ニフティクラウド エンジニア

山口

山口

ニフティクラウドの基盤設計、新サービス/アライアンス/インフラ企画、その他雑用全般を担当しています。 クラウドに欲しい機能や、こんなふうに使ってほしいという想いが共有できれば良いですね。

芳中 隆幸

芳中 隆幸

ニフティクラウドの開発、運用を担当しています。

酒井 浩平

酒井 浩平

ニフティクラウドの中にいます。 ネットワークまわりの運用・開発や自動化などに取り組んでいます。 すべてのエンジニアを幸せにすることを目指しています。

higebu

higebu

ニフティクラウド IaaSのエンジニアです。 ネットワーク、DRサービス with VMware vCloud® Air™ Technology辺りの担当をしています。

武田

武田

ニフティクラウドの開発・運用を担当しています。 各種機能の内容についてなどで執筆させていただく予定です。

森藤 大地

森藤 大地

データに関する仕事が好きです。

宮原徹

宮原徹

日本仮想化技術株式会社 代表取締役社長兼CEO。仮想化技術に関するコンサルタントとして長年活動しており、特にベンチマークテストによる性能評価を得意としている。

荒谷翔

荒谷翔

株式会社はてなでMackerelのセールスデベロッパーとして勤務しています

東條 望

東條 望

2014年にニフティへ中途入社。 入社後から現在まで、ニフティクラウドのサービス企画・開発を担当しています。 各サービスの紹介を執筆させていただく予定です。