NewtMQ(v0.2) と RPC over MQ

 こんにちは、インフラ統括本部の大山 裕泰です。
 NewtMQ v0.2 をリリースしました。

https://github.com/newtmq/newtmq-server/releases/tag/v0.2.0

 v0.2 では temp-queue を実装し Brokered MQ を利用した高速な RPC 処理が実現できるようになりました。
 今回は RabbitMQ(AMQP) 及び RabbitMQ(STOMP) に加えて Broker-less MQ の ZeroMQ、Google 謹製の RPC フレームワーク gRPC、そして NewtMQ で RPC のベンチマークを取ってみました。
 尚、御馴染みの Apache Kafka には 同様の機能がない模様 なため、検証しておりません。

temp-queue とは?

 NewtMQ (v0.2) に実装した temp-queue の仕組みは、以前のツチノコブログエントリ で紹介した rabbitmq-stomp プラグインのものと同じ仕組みになります。RabbitMQ 本体にも 同様の機能 が実装されています。
 簡単に説明すると pub-sub モデルにおいては Publisher と Subscriber はそれぞれお互いの存在を認知しませんが、Subscriber が、受け取ったメッセージを送ったある Publisher に対してメッセージを返信したいケースにおいて、当該 Publisher 専用の一時キューに対してメッセージを送ることで Subscriber と特定 Publisher 間でメッセージパッシングを行えるようにする仕組みになります。

 MQ を介して RPC を行う際、この仕組みが有効に作用します。

RPC over MQ

 RPC はネットワークを介した計算機資源を活用する分散システムの世界で 30 年以上の歴史がある枯れた技術です。
 分散システムにおいてはネットワークや計算機に障害が発生した際においてもサービスが安定して稼働できること、そして計算機資源の動的な増減に対応できることが古くからの課題として知られています。これらの問題を解決する手段の一つとして MessageQueue が広く利用されてきました。
 大規模化・複雑化した今日のシステムの多くはこうした仕組みに支えられています。数千 ~ 数万のサーバから構成される OpenStack では、RabbitMQ を用いた RPC を行うアーキテクチャ を採っています。

Broker-less MQ

 ここで、今回の比較する ZeroMQ に代表される Broker-less MQ と呼ばれる MQ について紹介します。
 ’MQ’ という名前を冠している点で RabbitMQ や NewtMQ と同じく、Queuing や Pub/Sub といったシステムモデルの実装をサポートする機能を提供している点で共通ですが、メッセージを仲介する ‘Broker’ を持たない点で異なります。
 RabbitMQ や NewtMQ の場合、以下のように Pub/Sub モデルにおいてクライアント (Publisher 及び Subscriber) は Broker に対してメッセージの送信/取得を行います。Apache Kafka や MQTT の実装として知られる ActiveMQ Apollo もこちらに分類されます。
   

 対して ZeroMQ の場合、以下のように Publisher が直接 Subscriber プロセスに対してメッセージを送信します。

 Broker を持た無い MQ システムでは、Broker を介した MQ と比較していくつかのメリットがあります。まずクライアントと Broker 間の通信が無くなるため、通信に伴うトラフィック量を減らせる事ができます。また ‘Broker’ で行う処理を省くため高速なメッセージパッシングを行うことができます。

ZeroMQ

 ZeroMQ の用途は Queuing や Pub/Sub モデルの実装に止まりません。ここで ZeroMQ 自体について補足で紹介します。
 ZeroMQ では ‘ZeroMQ Socket’ と呼ばれる TCP Scoket を抽象化したオブジェクトに対して、1対1, 1対N, N対1, N対N の通信を実現する機能 を加えています。更に、これらの通信のベースに Queuing の仕組みを設ける事で通信の可用性を高め、従来の TCP Socket を用いた通信を行うアプリケーションに対して、高い機能性と可用性を備えた仕組みを提供しています。
 更に ZeroMQ の Router Socket を利用することで、メッセージの配送を仲介する Proxy をつくることができ Broker MQ のような振る舞いをさせることも出来ます。

測ってみた

 それではここで MQ を利用した RPC 処理のベンチマークを取ってみます。ベンチーマークは Broker MQ の雄 RabbitMQ(AMQP, STOMP) Broker-less MQ の代表格 ZeroMQ、そして RPC フレームワークとして現在非常に活発に開発が行われている Google 謹製の RPC フレームワーク gRPC、そして NewtMQ に対して行います。ベンチマークでは以下の RPC ベンチマークツールを利用します。

* https://github.com/userlocalhost2000/rpc-bench

 各クライアントライブラリはそれぞれ以下を使用しています。

ターゲット ライブラリ (バージョン)
RabbitMQ(AMQP) bunny (2.3.1)
RabbitMQ(STOMP) stomp (1.4.0)
NewtMQ stomp (1.4.0)
gRPC grpc (0.14.1)
grpc-tools (0.14.1)
ZeroMQ libzmq (4.2.0)
ffi-rzmq (2.0.4)
ffi-rzmq-core (1.0.5)

 今回は、各手法の実行時間の比較が目的のため、クライアント、サーバ、及び MQ を全て同一ホスト上で実行しています。実行ホスト環境は以下のとおりです。

CPU Intel Core i7-6700 CPU @ 3.40GHz
RAM 32GB
OS Ubuntu14.04
Ruby 2.2.2
RabbitMQ 3.6.1-1

 RPCBench では、クライアントがサーバに対して数値を送り、サーバが送られた数値に 1 を足して結果を返し、最終的にすべての結果が送った数値 + 1 になっているかを検査するまでに要した時間を、リクエスト数、同時実行数のパラメータを変えて取得できます。
 
 まず同時実行数を 1 に固定し、リクエスト数を 32k ~ 512k にそれぞれ設定した結果を以下に示します。

 予想通り ZeroMQ が最も早いですが NewtMQ もほぼ同じ程度の速度で RPC をさばけています。予想以上のスピードに我ながら驚いています(結果の取り違いを疑いました)。
 それぞれのベンチマークにおいて RPC サーバ処理 (数値を受け取って +1 する処理) は共通ですが、クライアントライブラリがそれぞれ異なるため、純粋に MQ の違いについての比較にはなりません。
 ただし RabbitMQ(STOMP) との比較に関しては、サーバ処理もクライアントライブラリもそれぞれ同じものを用いており、MQ だけが違うので純粋な NewtMQ と RabbitMQ(STOMP) の性能の違いがこの結果かわかります。

 続いてリクエスト数を 10k に固定し、同時実行数を 4 ~ 64 にそれぞれ設定した結果を以下に示します。

 

 やや ZeroMQ との差が開きましたが Broker MQ においては NewtMQ が最も速度が出ていることがわかります。

おわりに

 NewtMQ に temp-queue を実装したことで、RabbitMQ よりも高速に RPC を処理できることを確認しました。
 しかし NewtMQ はその他の機能面や信頼性、実績において RabbitMQ に遠く及ばないので、メジャーバージョンがリリースできるくらいまでは暖かい目で見守っていただければと思います。

 性能改善の余地はまだ残されているので、NewtMQ はまだまだ速くなると思っています。

JANOG38、JTF2016に登壇します!

(∩´∀`)∩<インフォメーションのお時間です♪

7月に行われるJANOG38、JTF2016に弊社のエンジニアが登壇します!

まずは、JANOG38からご紹介。

JANOG38ミーティング
日時 2016年7月6日(水)~8日(金)
会場 沖縄かりゆしアーバンリゾート・ナハ

日時 プログラム 発表者(敬称略)
2016年7月8日(金)
10:00
EDNS-client-subnetってどうよ? 改めRFC7871ってどうよ 水越 一郎 (東日本電信電話株式会社)
石田 慶樹 (日本インターネットエクスチェンジ株式会社)
高嶋 隆一 (株式会社DMM.comラボ)
末松 慶文 (九州通信ネットワーク株式会社)
2016年7月8日(金)
11:00
そんなMQで大丈夫か? ―より良いMQの使い所を考える― 大山 裕泰 (株式会社DMM.comラボ)
伊東 宏起 (さくらインターネット株式会社)
浅野 航平 (株式会社ワークスアプリケーションズ)
2016年7月8日(金)
14:45
DMM.comを支えるインフラのここまでとこれから 高嶋 隆一 (株式会社DMM.comラボ)
2016年7月8日(金)
17:00
できる! データドリブン障害検知 西塚 要 (エヌ・ティ・ティ・コミュニケーションズ株式会社)
佐々木 健 (株式会社DMM.comラボ)

3日目に4つもDMM.comラボから登壇しちゃいますヾ(*´∀`*)ノ
私もスタッフとして会場にいるので、見かけたら声をかけてくださいねー!

現在、JANOG38では出席登録を受付中です!
沖縄で熱い議論を交わしましょうー!

つづいて、July Tech Festa 2016のご案内です。

July Tech Festa 2016
日時 2016/07/24(日)
会場 産業技術大学院大学

プログラム 発表者
MOM (Message Oriented Middleware) に求めるモノ 大山 裕泰
チーム仕事を円滑にする読書会のすすめ saya

 

また、JANOG38、JTF2016ともに、DMM.comラボではブース出展をします!

IMG_8137
※写真はイメージです!実際のブースとは異なります!

ツチノコブログを見てきました!」と声をかけてくださった方に、ノベルティをプレゼント的な企画をしたいなあと、検討中です。

皆さまが喜んでくださるようなノベルティが作れるといいのですが…!
ノベルティについては形ができたらブログでも紹介しますね♪

それでは、イベント会場でお会いしましょう!

Hardening100 Value × Value はとてもタフな戦いだった件

久しぶりにツチノコBLOG書いてみたとうまつです。こんにちは。

先日、セキュリティ競技イベントである「Hardening 100 Value x Value」 に参加・協賛してきましたので、その様子を紹介いたします。

DSC_1531

 

Hardening ってなに?

Hardeningとは、セキュリティを軸にしたECサイトのディフェンスに特化の競技です。

ひとことで言うと・・・
「仮想の資金と脆弱性てんこ盛りなECサイトを渡されたチームが、そのECサイトのシステムを8時間の競技時間内に堅牢化(Hardening)してECサイトの売上を競い合う」
となります。

このため、単なるセキュリティの競技ではなく、ECサイト運営で如何にして売上を上げていくかにフォーカスされるので以下を要領よく処理していかなければなりません。

単に脆弱性対策をするだけでなく、以下への対応が求められるため、テンヤワンヤするというタフな競技内容となっています。

  • チームマネジメント
    • メンバーをタスクにアサイン
    • 意思決定
  • 販売
    • 売上管理
    • 在庫管理・発注
    • 商品価格設定
    • クレーム対応
  • ECサイトの堅牢化
    • ECサイト のOSやDaemonの管理
    • 各システムのバックアップ
    • パスワード管理
    • 定期的に実施される「kuromame6」というセキュリティの専門家チームによる容赦無いサイバー攻撃への対応
    • 攻撃された際にはJPCERTへの報告(本格的ですよね!)

などなど・・・・・

DSC_1791
競技中に無慈悲な暗躍をしていた kuromame6 のみなさん

競技内容

開催1日目は競技日です。殆どのチームが競技日までにチームビルディングを行い、作戦を練って競技に挑んでいる様子。興味深かったのは各チームごとのタスク管理で、たいていのチームは付箋(ポストイット等)を用いたアナログな管理を実践していました。

DSC_1545
奮闘中の各チーム

また、会場に設置されたディスプレイにてリアルタイムで各チームの健闘状況が表示されており、各チームの状態が一目瞭然でした。

各チームの成績が一目瞭然
各チームの成績が一目瞭然

 

足らないものは買え!

チームで足らないもの、例えばサービスや製品、そして各分野のエキスパートエンジニアを仮想の資金で調達できるマーケットプレイスが設置されています。
これにより、チームに足らないものを補うことができます。特に面白いかったのはエンジニアを時間単位で購入する制度で、ハイレベルなエンジニアを競技中に買うことが可能です。
というわけで、様々なチームが必要な物をどんどんアウトソースしていました。また、マーケットプレイスで調達できるエンジニアは有限であるため、戦略的にエンジニアを長時間確保して他チームに関わらせないような作戦も展開されたこともあったとか。

DSC_1530
マーケットプレイスに並ぶ「商品」のみなさま

会場全体を巻き込んでいく・・・

エンジニア調達の手段として、マーケットプレイスだけで良いのかとおもいきや、実は競技観覧者にコネがある人はそれを駆使して観覧者をエンジニアとして狩りだすことが可能だそうです。かくいう自分も、DNS周りの設定を何件かお手伝いさせていただきました。

DSC_1535
競技観覧者も巻き込んでいくの図

タフな勝負を勝ち抜いたのはTeam8の「No.Bee」

無慈悲なkuromame6の攻撃に耐え続けつつ売上をグイグイ伸ばしてグランプリを勝ち取ったのは チーム8「No.Bee」でした。

売上金額としては2億円以上を達成しており、他のチームを大きく引き離していました。No.Beeのチームメンバーには副賞としてDMM.comポイントカードを贈らせて頂きました。

DSC_1708
グランプリを勝ち取った超タフチームの No.Bee

全体を通して

Hardeningはチームメンバーのスキルが勝敗を大きく左右すると思いきや、実はスキルドリブンではなく、チームの結束力と意思決定の競技であるような印象を持ちました。というのも足らないスキルはマーケットプレイスで購入できるため、「スキルがないから・・・」といって尻込みする必要は無いという印象を持ちましたので興味ある方は遠慮せずHardening競技者に応募してみてはどうでしょう?

引き続き、11月に開催されるHardeningもDMM.comラボが協賛いたします。冬の沖縄でまたお会いしましょう。

DSC_1766
奮闘後の参加者

 

Interop2016で見つけたヤンデレ彼女用IoTまとめ [Interop Tokyo 2016]

mental_health_woman

ドーモ、ハジメマシテ、@arimoです。
6/8〜6/10に行われたInteropというイベントに行ってきました。
先にイベントの感想(まじめに)を言っておくと、

エンジニア向けInterop Tokyoの歩き方という記事で述べられていた

Interop Tokyoの展示内容は非常に難解なものが多いと言えますが、その難解さこそが魅力でもあると私は考えています。Interop Tokyoで行われた展示は、それを見た半年後、場合によっては数年後に初めて「あのときのあれは、あのような意味がある展示だったのか!」と気づくことが多い印象があるためです。

という感動がいずれ得られるかと思うと来年も行きたいな〜と思いました。
もう未知の世界すぎてまだよくわかっていないけどすごい技術の結晶だということはわかりました。

@arimoはわりとアプリケーションエンジニアなので、最新ネットワーク機器のエモさとかはまだほとんど理解できないので、IoTの展示をいくつか紹介したいと思います。

注意:使い方参考例は個人的な見解であり本来の使い方と著しく違う可能性があるため、正しい用法は公式サイトをご覧ください。

 

MT90G

IMG_3399
世界最小の3Gパーソナルトラッカー、つまり追跡マシンである。
耐水性、最長180時間スタンバイが可能。
公式サイトにも人の追跡、車の追跡、貴重品の追跡と書いてある。77*47*20mm、76gの小ささで、かつ位置情報の精度は10mである。
これはもう完全に浮気調査用かな?しかしただの位置情報発信機器であれば、職場などに移されたら意味をなさない。
よく読むと内蔵マイク・スピーカーがあり、通話もできる。
浮気を疑うまたは再構築中の彼氏のカバンに忍ばせ、明らかに位置情報が変わらない時は通話で直接確認ができる。携帯2台持ちの浮気彼氏殺しのIoT機器である。
「ね、これでいつも一緒だよ。わたしからは離れられないからね。早く結婚しようね。」

 

世界最小の小型タグ、MAMORIO

IMG_3407
縦35.5mm×横19mm×厚さ3.4mmという驚異的な薄さ、小ささ。
タグを紛失した地点の位置情報だけではなく、クラウドトラッキングという、「みんなでさがす」機能で、他のユーザが自分のタグとすれ違うとその情報がMAMORIO サーバに送信され、その時点でタグがどこにあるのかがわかる。MAMORIOが世に広まれば広まるだけ発見される確率も上昇する仕組みである。
過去に置き引き、落下で財布を2回も失くし、TokyuRubyKaigiで飲みすぎてMac(会社のマシンではない)とカメラの入ったカバンを駅の券売機のところに置き忘れたことのある私にとっては革命的な逸品である。なお一つ3500円程度だそうで、複数個買うのもお財布に優しい。

IMG_3426

”手元から離れました。”
あまりにも小型のタグ、こっそり彼氏の財布に忍ばせて彼氏と離れた場所や時間を再確認してもよし、再度会った時にアプリを確認してほくそ笑むもよし、あわよくば「みんなでさがす」機能でどこにいるかがわかってしまう。

IMG_3427

”誰かが見つけました!”
「このタグはわたしの分身だから、一緒に出かける気分になれる。でも早く帰ってきてね。早く結婚しようね。」
「ねえ、なんでそんな場所にいるの?今日は実家に帰るからって言ってたよね????電話出て????」

 

眠りの質が一目瞭然、beddit

IMG_3398
帯状のセンサーをシーツの下にひくだけで、心拍数や眠りの浅い深いがグラフとなって視覚化できる。なんとベッドから立った時間や覚醒している時間も一目瞭然である。
「こっそり彼氏のベッドに仕掛けちゃった。昨日は何時に寝たかな?何時に起きたかな?
なんで計測されていないの?無断外泊なの????わたしに黙って???」
「振動センサーと、スマートフォンのマイクの両方を利用して計測しているから、いずれ結婚したらわたしとあなたのいびきを聞き分けてくれるから、今から楽しみだね。早く結婚しようね。」
※センサーはコンセントからの給電が必要なためこっそり仕掛けよう
※Bluetoothでスマートフォンと通信するため、彼氏の携帯を見せてもらうか、自分で余分に端末を買って部屋に置いておく必要がある

 

Bluetooth Low Energy スマートソール

IMG_3397
見た目や使い心地は普通のインソールと変わらない、見た目はよくある靴底に敷く中敷きである。目立たず、使用者に気付かれないとなんと公式で謳っている。
ハブと中敷きをWi-Fiで同期して、もし規定範囲外にインソールが出るとPCやスマートフォンで警告を通知する。広い部屋でも狭い部屋でも監視する範囲を設定できる。
「ねえ、なんでこんな時間に出かけるの?さっきおやすみって言ったよね?電話出て????」
なんとインソールの着用者に通知メールが自動で送られる機能もある。
(メール着信)「全部見てるからね?」

 

データの収集、データの分析、そして異常を検知して通知してくれる超便利ツール、impulse

IMG_3403
IoTのセンサーなどで温度や振動などのデータをたくさん収集したとしても、それが異常な値か正常な値かが分からなければ意味をなさない。
その情報を収集して分析して異常な時は通知してくれるようなそんなツールである。
デモでは製造ラインにおいて良品と不良品を振り分けるようなものがあった。
Kibanaで視覚化されていて、データの遷移や不良品発見時もわかりやすい。
「あなたのこれまでの動向データの分析結果を見てみたら不良品だったみたい。新しい彼氏できたからじゃあね。」

 

NetFPGAでOpenFlowを柔軟に活用するShowNetデモ [Interop Tokyo 2016]

SDN/NFVサービスチェイニングのデモの中で、OpenFlowを今よりもさらに柔軟に使うコンセプトデモも含まれていました。

数年前と比べると、OpenFlowの仕様や実装が進化しているので、OpenFlowでできることは増えています。しかし、現在のOpenFlowは主にマッチと書き換えを行うものなので、直接計算は行えません(コントローラに判断を仰ぐ方法はありますが、それだとリアルタイムな処理は困難です)。

そこで、今年のShowNetではNetFPGA-SUMEとOpenFlowを使ってハッシュ計算を伴うロードバランシングを実現しています。

7

デモの内容としては、以下のようなものです。

  • イーサネットフレームは、NetFPGAを通過してからLagopusへとパケットが転送される。
  • OpenFlowで負荷分散をするための例として、送信元IPアドレスと宛先IPアドレスでハッシュして、イーサネットフレームに含まれる送信元イーサネットアドレスを書き換える。
  • NetFPGAは、ハッシュ結果を送信元イーサネットアドレス下位8ビットにマーキングをしていって、OpenFlowは送信元イーサネットアドレスの48ビットをマッチして使って転送。
  • NetFPGAに入ってくるイーサネットフレームは、上位のルータからなので、そもそも入力は毎回同じ送信元イーサネットアドレスだけど、NetFPGAが下位8ビットを変更する。

この他に、OpenFlowのフローエントリ数を減らす工夫(微調整)も行われています。

今回サーバ上で動いているVMは8台なので、3bitで全てのVMを指定できます。NetFPGAはそのまま8bitに埋め込み、Lagopusのルールは送信元MACアドレスのうちマスクを使って下位3bitのみを見ています。

8bitでは全てのパターンを指定するのに256個のフローエントリが必要になりますが、下位3bitを見るだけであれば8エントリのみで全てのVMにトラフィックを転送することができます。これによって、OpenFlowでIPアドレスをマッチして転送するのと同じことを、8個のフローエントリで実現しています。

L3な機能(VirNOS含む)が使われるときは、ARP解決のために、OpenFlowで宛先イーサネットアドレスを宛先とするL3デバイスのMACアドレスに書き換えています。

NetFPGAを使ったデモは、NOCメンバーがShowNet 2016のために独自開発されたものです。なかなかマニアックですが、こういうの大好きです。


LagopusとNetFPGA(上に基盤むき出しで乗っているのがPCIカード用給電されたNetFPGA)