/// BANGBOO BLOG ///

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30


May 9, 2024 List
Pubsub on May 09, 2024 12:00 AM

May 9, 2024

Pubsub
■pubsub
Publisher app → |GCPの壁| Topic(Schema) → Subscription 1や2 |GCPの壁| → Subscriber app
 サブスクライバーappにPull/PushさせるPull/Pushのサブスクリプションをトピックに紐づける設定をしておく

【図解付き】Cloud Pub/Subに概要や使い方についてわかりやすく解説 - KIYONO Engineer Blog (kiyono-co.jp)
Pub/Sub サービスの概要  |  Pub/Sub ドキュメント  |  Google Cloud
GCPのCloud PubSubで考慮すること - Carpe Diem (hatenablog.com)
Pub/Sub の割り当てと上限  |  Pub/Sub ドキュメント  |  Google Cloud
アプリで簡単にPubsubにパブリッシュや、サブスクもできるので、アプリ間の連携にPubsubが使える
 • 非同期処理(画像処理とか重めのもの
 • IDの種類 (message id, subscription id, topic id, ack id, project idあたりがアプリでは使われるっぽい
  ※ack idはpull時のみでPushのときはhttpステータスコードが200でackとなる
GCP - Pub/Sub サービス概要 #GoogleCloud - Qiita
Pub/Sub メッセージの作成とレスポンス  |  Python 用 App Engine フレキシブル環境に関するドキュメント  |  Google Cloud
トピック(メッセージのパブリッシュ先)
 • スキーマ/外部アクセス許可/リテンション/GCS/バックアップの設定がある (Push/Pullの設定はない)
 • パブリッシュ側のベストプラクティス (JWT) 
  Pub/Sub トピックにパブリッシュするためのベスト プラクティス  |  Pub/Sub ドキュメント  |  Google Cloud
サブスクライバのPushとPull (PushはEndpointが必要、デフォルトはpull)
 GCP - Pub/Sub サービス概要 #GoogleCloud - Qiita
 • at-least-once (少なくとも1回) 配信を提供します
 • 同じ順序指定キーを持ち、同じリージョンに存在している場合は、メッセージの順序指定を有効にできます
 • サブスクライバーが31日間未使用、またはサブスクリプションが未更新の場合、サブスクリプションは期限切れ
 • メッセージ数が多いとpull向き サブスクリプション タイプを選択する  |  Pub/Sub ドキュメント  |  Google Cloud
pushはhttpsが必要?
 push サブスクリプションを作成する  |  Pub/Sub ドキュメント  |  Google Cloud
 • push エンドポイントのサーバーには、認証局が署名した有効な SSL証明書が必要でhttps
 • Cloud run でEvent Arcを設定するとサブスクが自動作成されrunのデフォルトhttpsのURLが使われるが、これはPullよりPushで安定した
 • CronバッチならPullで安定するのでは?大量リクエストはPull向きとある(Pullは失敗処理込みの話かも知れん)
トピックのリテンション:デフォルトなし、最小値:10分、最大値:31日
サブスクのリテンション:デフォルト値:7日、最小值:10分、最大値:7日
 サブスクリプション プロパティ  |  Pub/Sub ドキュメント  |  Google Cloud
pubsub ack期限(Ack Deadline)
 •デフォルト60秒> 設定10分>ack延長で最大1時間まで伸ばせると思われる
 リース管理で確認時間を延長する  |  Pub/Sub ドキュメント  |  Google Cloud
 •exactly onceを設定しなければ期限の延長は保証されない
 •ack期限を過ぎる、あるいはNackを返す場合、メッセージは再配送される
 •ack応答期限の延長は99パーセンタイル(上位1%の値よりも小さい値のうち最大の値)で
 modifyAckDeadlineを返し、延長してもMaxExtension (ack期限を延長 する最大値) 60minまで?
  modifyAckDeadlineリクエストを定期的に発行すればよいらしい
メッセージの再試行を強制するには
 •nack リクエストを送信
 •高レベルのクライアント ライブラリを使用していない場合は、ackDeadlineSeconds を0に設定して modifyAckDeadline リクエストを送信する
exactly once
1 回限りの配信  |  Pub/Sub ドキュメント  |  Google Cloud
 •pullなら設定できる。他には、Cloud Dataflowを組み合わせる(プログラムコードでDataflowを使う感じかり、あるいはmessageについているunique idを利用して、KVS を用いたステート管理をして自前で重複を排除する
 •再配信は、メッセージに対してクライアントによる否定確認応答が行われた場合、または確認応答期限が切れる前にクライアントが確認応答期限を延長しな かった場合のいずれかか原因で発生することがある。
  ※exactly onceはエラーでも再配信でPubsubパニックしないようにしたいために使うものではない?
pubsubはトピックにPublishされたメッセージをDataflowに引き継げる
 •Apache Beamのウィンドウ処理とセッション分析とコネクタのエコシスエムがある
 •メッセージ重複の削除ができる
 •pubsub>dataflow>BQやGCS: この流れでログ等をストーリミングで入れ込める
BQサブスクリプション (PubSubはBigQuery Storage Write API を使用してデータを BigQueryテーブルに送信、GCSサブスクもある)
 Langganan BigQuery  |  Dokumentasi Pub/Sub  |  Google Cloud
 BigQuery サブスクリプションの作成  |  Pub/Sub ドキュメント  |  Google Cloud
サブスクライバーApp側のコードでのフロー制御によりちょっと待てよのトラフィック急増対応
 フロー制御を使用して一時的な急増を処理する  |  Pub/Sub ドキュメント  |  Google Cloud
デッドレタートピック (配信試行回数が見れる)やエラーでの再配信
 メッセージ エラーの処理  |  Pub/Sub ドキュメント  |  Google Cloud
  • Pub/Subサブスクリプションにデッドレタートピックを設定しておくと、一定の回数再送信が失敗したメッセージの宛先がデッドレタートピックに変更され貯められる
メッセージのフィルタ、同時実行制御により多いメッセージに対応
 サブスクリプションからのメッセージをフィルタする  |  Pub/Sub ドキュメント  |  Google Cloud
Pubsubをローカルでエミュレートする
 エミュレータを使用したローカルでのアプリのテスト  |  Pub/Sub ドキュメント  |  Google Cloud
pubsubのスナップショットやリテンション
クイックスタート: スナップショットまたはタイムスタンプまでシークして Pub/Sub でメッセージを再生する  |  Pub/Sub ドキュメント  |  Google Cloud
トピックにリテンションを設定しスナップショット作成> 過去のサブスクしたメッセは見えなさそう
サブスクにリテンションを設定しスナップショット作成> 過去のAckしたメッセは見えなさそう
スナップショットでどう使うのか?
 cloud pubsubで配信済みのメッセージを再送する #PubSub - Qiita
 キューがたまっているときに撮るものと思われる。またシーク時間のポイントを設定する意味がある
 スナップショットとシークを使いこなして特定期間の再実行を行う機能
  スナップショットで再実行する
  シークは指定時間か最後のスナップショット以降のサブスク再実行(実際pushでrunが再実行された)
Pubsubにどんなメッセージが入ってきているか確認する方法
 pull形式ならAckしなければpullボタンで拾い見れる (トピックでパブリッシュしてサブスクでPull し見る)
 トラブルシュートはログを見るかデッドレタートピックかGCSバックアップを見る?
デッドレターキュー(ドロップしたものの確認と救済?)
 サブスクでDLQのONしデッドレタートピックを設定し転送する>GCSにもバックアップできる
 DLTでメッセージ(実行済みOR未実行)の再生
データ形式:スキーマを使うか、スキーマなしならdataで取得できる
 トピックのスキーマを作成する  |  Pub/Sub ドキュメント  |  Google Cloud
 Cloud Pub/Subの概要とPythonでの実践 - case-kの備忘録
from google cloud import pubsub_v1
from avro.io import DatumReader, BinaryDecoder
from avro schema import Parse
project_id="your-project-id"
subscription id="your-subscription-id"
subscriber pubsub_v1.SubscriberClient()
subscription_path = subscriber.subscription_path(project_id, subscription_id)
avro_schema = Parse("""
{
"type": "record",
"name": "Avro".
"fields": [
{
"name": "ProductName",
"type": "string",
"default":""
},
{
"name": "SKU",
"type": "int",
"default": 0
}
}
def callback(message):
print(f"Received message: {message}")
reader = DatumReader(avro_schema)
decoder = Binary Decoder (message.data)
avro_record = reader.read(decoder)
message_id=message.message id
message.ack()
print("Message ID: (message_id}")
product_name = avro_record['ProductName']
sku= avro_record['SKU']
print("Product Name: (product_name}")
print("SKU: (sku}")
subscriber.subscribe(subscription_path, callback=callback)

def callback(message):
print("Received message: (message)")
data message data
message_id=message.message_id
message.ack()
print("Date (data)")
print("Message ID: (message_id)")

Pub/SubでStreamingPull APIを使用してメッセージをリアルタイムで処理する - G-gen Tech Blog
StreamingPull API を使用するとアプリとの間で永続的な双方向接続が維持され、Pub/Sub でメッセージが利用可能になるとすぐに pullされる。1 つの pull リクエストで 1 つの pull レスポンスが返る通常の 単項 Pull と比較すると、高スループット・低レイテンシ。必要なメッセージを残す処理をしたりも?GCP側の問題であっても通信が切れた場合は別サーバに繋ぎなおすためmodifyAckDeadlineも切れ再配信されるバグがある

/// BANGBOO BLOG /// - GCP runs off functions pubsub on scheduler

Posted by funa : 12:00 AM | Web | Comment (0) | Trackback (0)


PhotoGallery


TWITTER
Search

Mobile
QR for cellphone  QR for smart phone
For mobile click here
For smart phone click here
Popular Page
#1Web
#2Hiace 200
#3Gadget
#4The beginning of CSSレイアウト
#5Column
#6Web font test
#7Ora Ora Ora Ora Ora
#8Wifi cam
#9みたらし団子
#10Arcade Controller
#11G Suite
#12PC SPEC 2012.8
#13Javascript
#14REMIX DTM DAW - Acid
#15RSS Radio
#16Optimost
#17通話SIM
#18Attachment
#19Summer time blues
#20Enigma
#21Git
#22Warning!! Page Expired.
#23Speaker
#24Darwinian Theory Of Evolution
#25AV首相
#26htaccess mod_rewite
#27/// BANGBOO BLOG /// From 2016-01-01 To 2016-01-31
#28竹書房
#29F☆ck CSS
#30Automobile Inspection
#31No ID
#32Win7 / Win10 Insco
#33Speaker
#34Arcade Controller
#35Agile
#36G Suite
#37Personal Information Privacy Act
#38Europe
#39Warning!! Page Expired.
#40GoogleMap Moblile
#41CSS Selectors
#42MySQL DB Database
#43Ant
#44☆od damnit
#45Teeth Teeth
#46Itinerary with a eurail pass
#47PHP Developer
#48Affiliate
#49/// BANGBOO BLOG /// From 2019-01-01 To 2019-01-31
#50/// BANGBOO BLOG /// From 2019-09-01 To 2019-09-30
#51/// BANGBOO BLOG /// On 2020-03-01
#52/// BANGBOO BLOG /// On 2020-04-01
#53Windows env tips
#54恐慌からの脱出方法
#55MARUTAI
#56A Rainbow Between Clouds‏
#57ER
#58PDF in cellphone with microSD
#59DJ
#60ICOCA
#61Departures
#62Update your home page
#63CSS Grid
#64恐慌からの脱出方法
#65ハチロクカフェ
#66/// BANGBOO BLOG /// On 2016-03-31
#67/// BANGBOO BLOG /// From 2017-02-01 To 2017-02-28
#68/// BANGBOO BLOG /// From 2019-07-01 To 2019-07-31
#69/// BANGBOO BLOG /// From 2019-10-01 To 2019-10-31
#70/// BANGBOO BLOG /// On 2020-01-21
#71Bike
#72Where Hiphop lives!!
#73The team that always wins
#74Tora Tora Tora
#75Blog Ping
#76無料ストレージ
#77jQuery - write less, do more.
#78Adobe Premire6.0 (Guru R.I.P.)
#79PC SPEC 2007.7
#80Google Sitemap
#81Information privacy & antispam law
#82Wifi security camera with solar panel & small battery
#83Hope get back to normal
#84Vice versa
#85ハイエースのメンテ
#86Camoufla
#87α7Ⅱ
#88Jack up Hiace
#89Fucking tire
#90Big D
#914 Pole Plug
#925-year-old shit
#93Emancipation Proclamation
#94Windows env tips
#95Meritocracy
#96Focus zone
#97Raspberry Pi
#98Mind Control
#99Interview
#100Branding Excellent
Category
Recent Entry
Trackback
Comment
Archive
<     May 2024     >
Sun Mon Tue Wed Thi Fri Sat
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Link