Cloud Pub Subのメッセージ有効期限切れ

Question

Cloud pub sub を用いて、
ネイティブアプリのデータとクラウドのデータの同期を図ろうとしています。

そこでpub subの仕様を調べていたのですが

ドキュメントに
https://cloud.google.com/pubsub/docs/subscriber?hl=ja
デフォルトでは、7 日間の最大保持期間内に配信できなかったメッセージは削除されます。
とありました。

もしアプリが7日間オフラインであり続けた場合、メッセージは消えてしまうと言う事ですか？
その場合の同期はどのように撮ればいいのでしょうか？

Answer 1

もしアプリが7日間オフラインであり続けた場合、メッセージは消えてしまうと言う事ですか？

そのとおりです。背景は以下のとおりではないかと思います。

・Pub/Sub はリアルタイム、または 1日1回などの準リアルタイム処理を想定したもので、7日間もデータ処理が止まっているという状況を想定していない
・メッセージのデータ容量に応じた課金であるため、無期限の保持は Google にとって都合が悪い

代替手段の候補は下記かと思います。
・Pub/Sub Lite (無期限)
・Cloud Tasks (30日)
・Cloud Storage (無期限)
・Cloud SQL (無期限)
・Spanner (無期限)
・BigQuery (無期限)

Comments

[shugo]

なるほど、
改めて、Pub/Subの紹介ビデオをみてもマイクロサービスの疎結合を目指す為と書いてありました。
元から、スマホに関しては、考えてないのかもですね。

代替手段ありがとうございます。
Pub/Sub Liteについて調べたのですが、こちらはストレージ容量を超えると自動破棄されるようですね。
(そもそもメッセージだけで容量を使い切ることは早々ないと思いますが、可能性があるというだけで不安です)

Cloud SQLをPub/Subのように動かすのも一つの手ですね。ありがとうございます。

[68user]

データサイズ・頻度・どちらからどちらへ送るのか、などがわからないですが、
第一候補としては Cloud Storage ではないでしょうか。

安い、インスタンス管理などが不要、データ量は事実上制限なし、などが理由です。

[shugo]

大雑把に言うとapple musicやSpotifyのような音楽再生アプリを考えており、
WEBブラウザ、ネイティブアプリ双方で、
その「いいねした曲」や「ライブラリに加えた曲」のデータの同期を取りたいと思っていました。

データサイズは、曲自体はその都度クラウドから引っ張ってくる形にしようと思うので、少ないとは思います。
変更頻度としては、平均して一日一回程度でしょうか。

[68user]

構成を考えてみました (別に構成案を求めておられないでしょうが、こういうのを考えるのが好きなので)。

・1ユーザごとに、複数のPC・ブラウザ・スマホあり
　→ PCで追加したものが、他PCや iOS, Android など複数に連携されないといけない
　→ Pub/Sub はデータを処理したら削除 (ack) するものなので、多対多連携は不向き
・サーバ側で、マスタデータを持つ
　→ 端末追加時には全件連携が必要であるため
・各端末から追加/削除の差分を受け取り、マスタデータに反映する
　→ この処理があるので Cloud Storage だとめんどくさそう (いちいちファイルを開いて
　　 CSV や JSON のマージとかしたくない)

という前提だとすると、

・Cloud SQL または Datastore にて各ユーザのマスタデータを保持する
・各端末から 1日1回差分を Cloud Functions で受け取り、Cloud SQL or Datastore のマスタデータに反映
・各端末は 1日1回 Cloud Functions に差分要求が投げる (パラメータに前回要求時のタイムスタンプをつける)。
　Cloud Functions は Cloud SQL or Datastore のマスタデータからタイムスタンプ以降のデータ差分を取得し、
　返す (新しい端末からの要求なら全件返す)

Cloud SQL の方が高速かつ集計作業 (いいねの分析など) はやりやすいが、同時接続数など性能の上限は厳しめ。インスタンス管理の手間がかかる。
Datastore はインスタンス管理不要でスケールしやすいが、集計作業などは苦手 (KVS なので)。

Cloud SQL の場合、下記のようにすることで負荷を上げないように工夫することもできる。
　- 差分要求はそのまま Cloud SQL で受ける (read なので処理が軽い)。
　- 各端末から受け取った差分は Cloud Functions にて一旦 Pub/Sub に投げ、定期処理するバッチが
　　1つずつ Pub/Sub メッセージを取得して Cloud SQL に反映する
　　→ 複数クライアントから一気に差分登録が来て、重い write 処理で滞留することがないよう、
　　　 Pub/Sub を挟んで疎結合にする
　　→ Pub/Sub 7日間制限はあるが、定期処理バッチが 7日以上止まらない限り問題なし

[shugo]

わざわざありがとうございます！
とても参考になりました。

集計作業などはおそらくあまりする必要が無いので、Datastoreで良いかもしれません。
一回この流れを参考にしてみて、アプリを一回作ってみようと思います。