うーむ，MQTTの (MQTTではないが) shared subscriptionってMQTTの仕様に書かれているわけではなくて，HiveMQとかの独自実装なのか……
— 強い前世の業 (@moznion) 2017年11月7日
MQTTのsubscriber側でスケール可能にするにはやはりtopicごとわけてsubscribeするかどうかを決定するのが正道なんだろうけど，しかし相手 (broker) の都合でtopicが完全に固定されている場合などがあり，そういう時ってどうするんだ……
— 強い前世の業 (@moznion) 2017年11月7日
MQTTのsubscribe topicのワイルドカードに正規表現等が使えないかどうか調べたけど仕様的には使えなさそうだし，これまじでどうすりゃいいんだ．subscriber増やしても全部のsubscriberに等しくpublishされるからまったく意味がない
— 強い前世の業 (@moznion) 2017年11月7日
MQTT subscriber スケールアウト ただしtopicは固定されている 方法
— 強い前世の業 (@moznion) 2017年11月7日
brokerごと分けるの完全に厳しいな，しかしそれくらいしか思いつかないぞ
— 強い前世の業 (@moznion) 2017年11月7日
Shared subscription！！！ MQTTの正式な仕様になってくれ！！！！
— 強い前世の業 (@moznion) 2017年11月7日
MQTTを使うべきではないのでは？？？ (しかし色々な都合でクチがMQTTしかない)
— 強い前世の業 (@moznion) 2017年11月7日
MQTTをAWS SQSに直結させてほしい
— 強い前世の業 (@moznion) 2017年11月7日
実際subscriberの立場からしたらMQTTをダイレクトで取り扱うよりSQSみたいなリッチなやつのほうが良いってワケ．Publisherはそうもいかんだろうが……
— 強い前世の業 (@moznion) 2017年11月7日
Topicで分けるのがやっぱり正しいんだよなあ，わかる……
— 強い前世の業 (@moznion) 2017年11月7日
状況としては
- MQTTを使っている
- 複数のsubscriberがいて，それぞれに負荷分散したい
- MQTTの仕様的に，あるtopicをsubscribeしているsubscriberのどれか1つにだけ送る，というような仕様は存在しない
- IBM MessageSightやHiveMQなどは"shared subscription"という名前でそのような仕組みを提供している
- これはMQTTの仕様の「拡張」として取り扱われている
- 本筋でいくと，subscriberが複数いる場合に各subscriberに負荷分散したい場合は，各subscriberがsubscribeするtopicを分割すれば良い
- しかし色々な事情でtopicは実質1つしかない
- MQTTのsubscribe topicの指定に利用できるワイルドカードは素朴なものしかなく，正規表現のようなリッチなマッチャは存在しない
という時にどうやってsubscriberをスケールアウトさせるのかという話．brokerを増やすしか無いんだろうか……
