質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.48%
Redis

Redisは、オープンソースのkey-valueデータストアで、NoSQLに分類されます。すべてのデータをメモリ上に保存するため、処理が極めて高速です。

Q&A

解決済

1回答

3715閲覧

pub-subモデルの冗長化について

TetsuyaZama

総合スコア216

Redis

Redisは、オープンソースのkey-valueデータストアで、NoSQLに分類されます。すべてのデータをメモリ上に保存するため、処理が極めて高速です。

0グッド

0クリップ

投稿2015/08/09 07:34

編集2015/08/14 22:25

Redis等のpub-subモデルで連携しているアプリケーションで、
0. あるメッセージをSubscriberが受け取る
0. そこそこ負荷のかかる処理を実行する
0. 処理結果をPublishする
というプロセスがあるとします。

このプロセスを冗長化(+負荷分散)したい場合、どういった方法が考えられるでしょうか?
イメージとしては、単なるHTTPで動いているWebサーバの前にロードバランサを置くような構成を、Pub/Subモデル動いているアプリケーション(群)で実現したいといった感じです。

パッと思いつくのは、
0. LoadBarance用のプロセスを作り、それをSubscriberにする
0. 当該の負荷のかかるプロセスはRest等でKickできるようにしておく
0. LoadBarance用プロセス内部で自分でラウンドロビン等の処理を書き、割り振るサーバを決定する
0. 割り振られたサーバはRestでメッセージを受け取り、処理結果をPublishする
といったところですが、何かデファクトスタンダード的な手法があるようであれば、ご教示いただけると幸いです。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

ベストアンサー

Pub/Subというと、通常は購読者(Subscriber)に対してメッセージを
発行(Publish)することをいうと思いますが、ここではSubscribeをメッセージの受信、
Publishをメッセージの送信としている様に読めましたが、その認識であっているでしょうか?

一般的には、Pub/Subで冗長化というと、
ブローカーやメッセージバスを冗長化するのだと思います。
Publishしたら、Subscriberに確実にメッセージが届くことを
保証するイメージです。

TatsuyaZamaさんが気にされているのは、
Subscriberが確実に処理を完了する事を保証するための冗長化と思いますが、
それはPub/Subはあまり関係しないので、質問に記述されている方法を含め、
ある意味どんな方法でもよい気がします。

ある程度Pub/Subの特徴を活かすなら、
0.その負荷のかかる処理を実行するSubscriberを複数登録しておく。
0.Publishされた時にそれらのSubscriberが同じ処理をする。
0.終わったら結果をまたPublishする。
0.(同じ処理を複数のSubscriberで実行するので、複数のSubscriberが処理に成功すると、無駄にはなるが、それは許容する。)
という方法もあると思います。
ある種の投機的実行ですね。

投稿2015/08/13 00:05

eripong

総合スコア1546

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

TetsuyaZama

2015/08/14 22:20

ご回答ありがとうございます。 >ここではSubscribeをメッセージの受信、 Publishをメッセージの送信としている様に読めましたが、その認識であっているでしょうか? はい、すみません、そう解釈して頂ければと思います。 >TatsuyaZamaさんが気にされているのは、 >Subscriberが確実に処理を完了する事を保証するための冗長化と思いますが、 確かにおっしゃる通り、いわゆる可用性の確保という点も大事なのですが、 ここではそれに加えて、(このSubscriberはそこそこ負荷のかかる処理をしなければいけないので)負荷分散の要素も考えなくてはならないイメージでした。すみません、こちらの質問が分かりにくいですね。。。 さらに、処理が終わったらその結果をもとにPublishしなければならないため、単にSubscriberを増やすとその処理完了後のメッセージが複数Publishされてしまう点も気になっています。 よって、 >(同じ処理を複数のSubscriberで実行するので、複数のSubscriberが処理に成功すると、無駄にはなるが、それは許容する。) これが許容できるケースであれば、ご提示頂いた「投機的実行」が有効かと思うのですが、許容できない場合はみなさんどうされているのかなという点が疑問でした。
eripong

2015/08/15 14:48

参考になって良かったです。 spoutがあるなら、Redisでもできますね。 Hadoop/YARN、Sparkなども選択肢に入るかも知れません。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.48%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問