Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Cloud Pub/Sub Pull Subscriberの構成検討
Search
atsu.kg
October 19, 2023
Technology
0
280
Cloud Pub/Sub Pull Subscriberの構成検討
atsu.kg
October 19, 2023
Tweet
Share
More Decks by atsu.kg
See All by atsu.kg
OpenTelemetry PHPで始める!オブザーバビリティ入門
atsushikoga
0
670
GCPを使った transaction log tailing と polling publisher の性能比較
atsushikoga
0
180
巨大なモノリスの静的解析をレベルMaxにする方法
atsushikoga
0
3.4k
Lenet の開発環境の紹介
atsushikoga
0
920
Other Decks in Technology
See All in Technology
事業継続を支える自動テストの考え方
tsuemura
0
160
サーバーレスで楽しよう!お気軽に始められる3つのポイント / Have fun with Serverless!
_kensh
2
260
デザインから逆算して難易度を見積もるための観点
fumiyasac0921
0
100
攻撃者の視点で社内リソースはどう見えるのかを ASMで実現する
hikaruegashira
4
2.2k
自動と手動の両輪で開発するデータクレンジング
estie
2
130
WAF に頼りすぎない AWS WAF 運用術 meguro sec #1
izzii
0
300
CloudWatch Container Insightsを使ったAmazon ECSのリソース監視
umekou
1
140
DeepSeek on AWS
hariby
1
180
Fintech SREの挑戦 PCI DSS対応をスマートにこなすインフラ戦略/Fintech SRE’s Challenge: Smart Infrastructure Strategies for PCI DSS Compliance
maaaato
0
140
マルチデータプロダクト開発・運用に耐えるためのデータ組織・アーキテクチャの遷移
mtpooh
1
340
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
120k
トレードオフスライダーにおける品質について考えてみた
suzuki_tada
3
200
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
267
20k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
98
18k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Gamification - CAS2011
davidbonilla
80
5.1k
VelocityConf: Rendering Performance Case Studies
addyosmani
327
24k
The Cost Of JavaScript in 2023
addyosmani
47
7.3k
Statistics for Hackers
jakevdp
797
220k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
11
910
RailsConf 2023
tenderlove
29
980
Designing for humans not robots
tammielis
250
25k
Into the Great Unknown - MozCon
thekraken
34
1.6k
Transcript
Cloud Pub/Sub Pull Subscriberの構成検討 株式会社ホワイトプラス 古賀 敦士
フルマネージドのリアルタイムメッセージングサービス メッセージを生成するサービスと、処理するサービスを非同期的に切り離す 2 Cloud Pub/Sub とは
3 Push型/Pull型
4 Push Subscription Pub/SubサーバーがSubscriberにメッセージをHTTPSリクエストとして送信 処理完了したら成功のステータスコードを返すことで確認応答 秒間メッセージ数が多い場合はPull Subscriptionを推奨 ← バッチによる急増を懸念
5 Pull Subscription SubscriberはPub/Subサーバーに対してメッセージをリクエストする 処理完了したら確認応答リクエストを送信する バッチ型と常駐型の2つの実装方法が考えられる
6 サブスクライバをバッチにし定期的に処理する ・メリット 常駐型よりもリソース効率が良い ・デメリット メッセージパブリッシュから処理完了までが 常駐方式よりも長い ← 懸念 バッチ型
7 サブスクライバを常に稼働させてポーリングする ・メリット メッセージパブリッシュから処理完了までが短い ・デメリット 未処理のメッセージがない状態ではリソース効率が悪い 常駐型
8 Google Cloud 製品の検討
9 常駐型またはバッチ型が実装可能か オートスケールされるか の観点で調査
10 Cloud Run(Service) 常駐方式:◯ or △ - always on CPU
を使って可能 - リクエストを受信しないためオートスケールされない可能性あり? バッチ方式:◯ - 外部からの定期的なリクエストをトリガーにPullすることで可能 - オートスケール可能
常駐方式:△ - タスクのタイムアウト・試行回数制限があり、それを超えると失敗扱いになる - スケジュール実行するが実行時間が実行間隔を埋めることで、常駐方式と同様になる - ex. 実行時間1h・タイムアウト1h10minのタスクを1h間隔で実行する - 事前に並列処理数を設定できるが、処理状況に応じたオートスケールは無し
バッチ方式:△ - スケジュール実行することで可能 - 事前に並列処理数を設定できるが、処理状況に応じたオートスケールは無し 11 Cloud Run(Job)
常駐方式:◦ - タスクのタイムアウト・試行回数制限があり、それを超えると失敗扱いになる - スケジュール実行するが実行時間が実行間隔を埋めることで、常駐方式と同様になる - オートスケール可能 バッチ方式:◯ - スケジュール実行することで可能
- オートスケール可能 12 Cloud Batch
常駐方式:△ - フレキシブル環境ならば常時実行可能かも - リクエストが無ければオートスケールされないかも バッチ方式:◯ - スケジュール実行することで可能 - リクエストが無ければオートスケールされないかも
13 App Engine
常駐方式:◯ or △ - 可能そう - オートスケール可能 バッチ方式:◯ or △
- 可能かも - オートスケール可能 14 Compute Engine(MIG)
15 Discussion Time - Push Subscription での実装可能性 - Pull Subscriber
の常駐型とバッチ型の良し悪し - 常駐型に向いてそうな Google Cloud 製品 - 記載の内容とは別にこういう考え方がある などなど、ご意見・ご感想をいただけると幸いです。