Downloaded 280 times
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2famazonauroratips-170307140000-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
![[AWSマイスターシリーズ] Amazon SQS / SNS](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2f20140212aws-meister-regenerate-sqs-sns-140216193336-phpapp02-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
MQTTとAMQPと.NET
- 1.
- 2.
- 3.自己紹介/所属等• デンキヤギ株式会社• 代表取締役•社員, フリーランス, 協業等 募集してます• DSTokai管理人• 東海地方のメタコミュニティ• IT勉強会カレンダーっぽいやつの東海地方版• NGK(名古屋合同懇親会)• エンジニア向けクロスコミュニティ忘年会• ここ数年は100人前後の参加者2
- 4.自己紹介/技術領域• フロントエンドアーキテクト(自称)• JavaScript(Haxe),WPFあたりがわりと得意• 周辺にGUIできる人が居なかった結果…• 普通のアーキテクト歴も5年ぐらいはある• 大量データ×フロントエンド• 100万件を操作する高速なExcelみたいなヤツとか…• フロントエンドに限らず、バックエンドも最適化3
- 5.
- 6.
- 7.
- 8.MQTT, AMQPの雑な説明• 通信プロトコルの一種•HTTP, FTP等と同じアプリケーション層のプロトコル• メッセージ転送 (MQ)• IoT/M2Mでの利用も想定されている• デバイス - サーバ間で小さなデータを送受信• 世間的にはMQTTの方がIoT向けっぽいけど、Microsoft的にはAMQP (後述)7
- 9.MQ : MessageQueue• メッセージ指向• Message Passing + Queue• 複数オブジェクト間でのメッセージ受け渡し• 受け取ったメッセージをQueueに格納• 非同期・疎結合• 送信側はメッセージ送信までを考えればよい• 受信側はQueueの消費だけを考えればよい• 分散システム・非同期処理がシンプルに書ける8
- 10.MQの移り変わり• 10-15年ぐらい前• MSMQ•JMS• わりと最近• AMQP• MQTT• STOMP• ZeroMQ• etc...9
- 11.Publish/Subscribeモデル• Publisher :メッセージ発信者• Subscriber : メッセージ購読者• Broker : メッセージ仲介者10・・・PublisherBroker / QueueSubscriber
- 12.Publish/Subscribeモデルの補足• Brokerは存在する・しないパターンがある• Brokerモデルvs Brokerlessモデル• このスライドではBrokerモデルを前提に解説• ReactiveExtensionsもPublish/Subscribeモデル11
- 13.MQ利用例• メッセージ配信基盤• 1:1,1:N, 配信順序, エラー再送, ...全部MQ任せ• 応用で資産や設定情報の配布とか• Job Queue• 時間のかかる処理をWorkerに処理依頼• 一時的な処理殺到時の負荷分散、キューイング• ログ収集サービス、SlideShareライクサービスなど• メッセージはとりあえず待ち行列に貯める• 待ち行列が増えすぎたら一時的にWorkerを増やす12
- 14.
- 15.MQTT : MQTelemetry Transport• 軽量・省電力なプロトコル• 1対Nに特化したメッセージ配信• 低速・不安定なネットワークでの利用を想定• 2010年に仕様公開・ロイヤリティフリー• プロトコル自体は1999年から存在し、枯れている• IBMが主導的な立場• 仕様策定、商用製品の提供14
- 16.軽量・省電力なプロトコル• 軽量プロトコル• ヘッダサイズが最小で2byte•シンプルなプロトコルシーケンス• HTTPとの比較 (IBMの資料による)• トラフィック10-100分の1 → スループット10-100倍• 消費電力 10分の1以下15
- 17.1対Nに特化したメッセージ配信• Publish/Subscribeモデル• TopicベースでPublish/Subscribe•“/”区切りの階層構造（ファイルパスっぽい）• Subscribe時にワイルドカードで指定可• /japan/tokyo/device1/cpu• /japan/tokyo/+/meory ←部分一致• /japan/tokyo/device1/# ←以下全て16
- 18.低速・不安定なネットワークでの利用を想定• QoS :Quality of Service• Durable subscribe• LWT : Last Will &Testament, 遺言状• 単にWillと表記するケースも• Retain : Retained Publication17
- 19.QoS : メッセージ配信の品質レベル•QoS 0 : 最高1回• メッセージが確実に届く保証はない• 配信失敗しても再送を行わない• QoS 1 : 最低1回• 必ずメッセージは届くが、重複する可能性がある• QoS 2 : 必ず1回• 必ずメッセージが届き、重複もしない• 当然、QoS 0の方が処理は軽い18
- 20.Durable subscribe• メッセージ再配信機能•意図せずにSubscriberの通信が断絶• その後、当該Subscriberが再接続• 切断～再接続までに発生したメッセージを再送• QoS 1, 2のメッセージを再配信• 明示的なdisconnect, unsubscribeを行った場合は再配信されない19
- 21.LWT• ClientはBroker接続時にLWTを設定可能• Clientが通信を切断時にメッセージを配信する•通信死活監視を行っていて、意図しない切断時にもちゃんとメッセージが配信される• LWTにもQoSを設定可能20
- 22.Retain• ClientがSubscribeする際に、最後に配信されたメッセージを取得できる• Brokerは最後のメッセージのみは必ず保存する•逆説的に、エラー再接続ではないケースでは古いメッセージを取得することはできない21
- 23.主なMQTT Broker• IBMMessageSight (商用,ハードウェア)• IBM WebSphere MQ Telemetry (商用)• 時雨堂 Akane (商用)• Mosquitto (OSS)• RabbitMQ (OSS, Plugin使用)• etc ...22
- 24.MQTT over WebSocket•WebSocket経由でMQTT接続するライブラリも存在する• Paho JavaScript Client• MQTT Brokerの前にWebSocket Gatewayを配置• Lighttpdでブリッジできることは確認した• たぶんNginx等のロードバランサーでもOKなはず23
- 25.MQTTの弱いところ• シンプルな仕様のため、できないことは多い• JobQueueは作れない• Subscriberが接続してくる前にPublisherが送信したメッセージは最後の一つしか残らない(Retain)• 1対1 メッセージ配信が考慮されていない• 認証の仕様が明確には定められていない• Brokerごとの実装に依存• 認証機能をサポートしていないBrokerも多い• OSSのBroker実装の層が薄い24
- 26.MQTTと.NET• MQTT .NETClient• Paho(M2Mqtt), WinRTにも対応• MQTTDotNet• nmqtt• MQTT .NET Broker• GnatMQ• 完成度がまだ低いので、素直にMosquittoかRabbitMQか商用Brokerを使った方が良い25
- 27.M2Mqtt, GnatMQの実装が微妙っぽい話• ソケットが同期通信で実装されている•パフォーマンス上の問題を抱えていそう…• WinRT版で無理やり同期処理…• Task<T>.Result で、非同期処理を同期待ち合わせ…• おそらく後付けで #ifdef したせい26
- 28.
- 29.AMQP : AdvancedMessage Queuing Protocol• Enterpriseに対応できるプロトコル• 高信頼性• 高度なメッセージ配信• アクセス制御• 相互運用性が高い• 仕様がオープン(OASIS)• ワーキンググループのメンバーが豪華28
- 30.高信頼性• メッセージ永続化• Publisherが送信したメッセージをBrokerが永続化•仮にBrokerが死んでも、再起動で復元できる• トランザクション• Subscriber側のメッセージを受け取る一連の処理をトランザクションを使って記述できる• tx.select, tx.commit, tx.rollback• メッセージは受け取れたが、後続処理でエラー発生というケースでも、メッセージがロストしない29
- 31.高度なメッセージ配信• Exchange (Direct,Fanout, Topic, Header)• Priority Queue• 優先度の高いメッセージを他より先に配信• QoS, Prefetching• メッセージを受け取れるSubscriber数を制限• 分散JobQueueを作るときに必須• immediate• Subscriberが存在していないときに配信できない30
- 32.Exchange• Direct• 特定のSubscriberのみに配信,1:1• Fanout• 全てのSubscriberに配信, 1:N (1:All)• Topic• 特定のTopicのSubscriberのみに配信, 1:N• Header• Header(KeyValue)の組み合わせで配信先を特定, 1:N31
- 33.アクセス制御• “virtual host”+ ACL• ACL : userごとのRead/Write権限• virtual hostごとにACLを設定• いわゆるマルチテナント的な分割もできる32
- 34.相互運用性• 実装面の仕様が明確化されている• メッセージフォーマット仕様が厳密•仕様書にTypeSystemの章とかある• セキュリティ・アクセス制御等も明確に仕様化• 複数プログラミング言語、ベンダー間の相互運用に問題が生じないようになっている• ライブラリAPIについては規定なし• JMSでは逆にAPIを定義するが、実装は未定義33
- 35.ワーキンググループのメンバーが豪華• テクノロジ系• Cisco,Red Hat, VMware, Microsoft, ...• 金融(証券)系• Bank of America, JP Morgan, Goldman Sachs, Barclays,CREADIT SUISSE, ....• 金融系が沢山いる＝金融系で使われている• トレーディングシステムでのメッセージング基盤• 以前はJMSだったらしい34
- 36.主なAMQP Broker• RabbitMQ•AMQPといえばRabbitMQ• Apache ActiveMQ, Apollo• Apache Qpid (, Red Hat Enteprise MSG)• IBM MQ Light• Microsoft Azure Service Bus & Event Hubs• Service Bus for Windows Server35
- 37.AMQPの弱いところ• 高機能な反面、仕様が複雑• “高機能・高信頼性”と”性能”がトレードオフ•MQTT等のシンプル系プロトコルとの比較• 要件によっては、NATSやKafka等も視野にいれる• トレードオフとはいえ…• 金融系で実績があることは重要• RabbitMQは完成度が高く、クラスタ構成が前提• MQTT Brokerでは商用とOSSの差が激しい36
- 38.AMQPと.NET• AMQP .NETClient• Broker製品ごとにライブラリが存在• RabbitMQ .NET Client (WCFもいける)• Qpid WCF• Azure SDK, ...• AMQP .NET Broker• 少なくともOSSは無いっぽい• 素直にRabbitMQかService Busを使いましょう37
- 39.AMQPとAzure Event Hubs•Azure Event HubsはIoT用サービスらしい• AMQPとHTTPプロトコルをサポートしている• IoTデバイスのバッテリーに優しくない気が…• AMQPプロトコルは重い (MQTTとの比較)• なんでMQTTサポートしてないんだろ…38
- 40.
- 41.まとめ• MQTTとAMQPはMQのプロトコル• それぞれの特徴は全然違う•MQTT : シンプル・省電力• AMQP : 高機能・高信頼性• .NETからはどちらのプロトコルも使える• Microsoft的にはAMQP推し• MQTTの.NET Clientの品質は検証が必要• MosquittoのBindingを作るのもありかも…40