クラウド同上

Pub/Subはどのぐらい重複しているか気になっていませんか?

Author
liu
Lv:2 Exp:70

2018年11月入社し、技術本部所属です。異職種から転職してきたため、現在勉強中で、充実な毎日を送っています^ ^。よろしくお願いたします。

Cloud Pub/Subは送信者と受信者を切り離す多対多の非同期メッセージングを提供することによって、別々に開発されたアプリケーションの間で安全かつ高可用な通信を実現できます。Google Cloud Platform 上や外部でホストされているシステムをデベロッパーが速やかに統合できるようにするため、低レイテンシで耐久性のあるメッセージングを提供できます。

Pub/Sub特徴としてはat-least-onceです。通常、Cloud Pub/Sub は各メッセージを公開された順序で 1 回配信します。ただし、メッセージが順不同で配信される場合や複数回配信される場合があります。そこで実際Pub/Subはどのぐらい重複するかという疑問があります。重複レベルによって運用時重複排除必要があるかどうかに関わっています。

Pub/Subはどのぐらい重複するかを検証してみました。結果としては100万件一回の重複も発生していなかったです。通常運転状態で、ピーク性なども高くないような利用において重複は一般的に発生発生するものではないようです。
以下で検証方法を紹介します。

1. 概要

シェルスクリプトpublisher.sh、worker.shを作成します。
10個のpublisher.shを同時に起動してtopicにmessageをpublishします。10個のworker.shを同時に起動してmessageをpullし、txtへ保存します。下記はフロー図です。

2. シェルスクリプト作成・起動

2.1 publisher.sh作成

順序をわかりやすくするためにmessageの内容”hello”の後ろに番号iをつけます。

publisher.sh

2.2 publisher.sh起動

検証時間を節約するために、下記のコマンドでpublisher.shを10回起動します。

nohup sh ./publisher.sh 1 100001 &
nohup sh ./publisher.sh 100001 200001&
nohup sh ./publisher.sh 200001 300001&
nohup sh ./publisher.sh 300001 400001&
nohup sh ./publisher.sh 400001 500001&
nohup sh ./publisher.sh 500001 600001&
nohup sh ./publisher.sh 600001 700001&
nohup sh ./publisher.sh 700001 800001&
nohup sh ./publisher.sh 800001 900001&
nohup sh ./publisher.sh 900001 1000001&

2.3 worker.sh作成

messageをpullして、順序分かるための順番iだけを抽出します。

worker.sh

2.4 worker.sh起動

nohup sh ./worker.sh >> message.1.txt &
nohup sh ./worker.sh >> message.2.txt &
nohup sh ./worker.sh >> message.3.txt &
nohup sh ./worker.sh >> message.4.txt &
nohup sh ./worker.sh >> message.5.txt &
nohup sh ./worker.sh >> message.6.txt &
nohup sh ./worker.sh >> message.7.txt &
nohup sh ./worker.sh >> message.8.txt &
nohup sh ./worker.sh >> message.9.txt &
nohup sh ./worker.sh >> message.10.txt &

3. 結果集計

message.i.txtを一つのtxtにまとめて重複行はないか確認します。

message.i.txtをまとめて一つファイルにする方法は下記のリンクをご参照ください。
https://www.howtogeek.com/278599/how-to-combine-text-files-using-the-cat-command-in-linux/
ファイル中に重複行はないか確認する方法は下記のリンクをご参照ください。
https://webkaru.net/linux/uniq-command/

message.txtは全部100万行があって、その100万行には重複がないことは確認できました。

4. まとめ

100万件一件の重複もなかったです!!exactly-one-timeは一番良いですが、コストを含め、総合的に考える必要があります。ライトな使い方で少々発生しても気にしなくて良いなら、重複排除を入れなくても良いでしょう。

 

次の記事を読み込んでいます
次の記事を読み込んでいます
次の記事を読み込んでいます