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
64
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
260
GCPを使った transaction log tailing と polling publisher の性能比較
atsushikoga
0
120
巨大なモノリスの静的解析をレベルMaxにする方法
atsushikoga
0
3k
Lenet の開発環境の紹介
atsushikoga
0
780
Other Decks in Technology
See All in Technology
リテール金融(キャッシュレス・ネット銀行・ネット証券)の競争環境と経済圏
8maki
0
1.3k
JAWS-UG Bedrock Claude Night
yamahiro
3
620
Postman v10リリース後を振り返る / Looking back at Postman v10 after release
yokawasa
1
160
VSCodeの拡張機能を作っている話
ebarakazuhiro
1
640
ルーターでプレゼンする
puhitaku
0
830
Building a RAG-poweredAI chat appwith Python and VS Code
pamelafox
0
110
LLM開発・活用の舞台裏@2024.04.25
yushin_n
3
880
On Your Data を超えていく!
hirotomotaguchi
2
700
生成AIの変革の時代に、直近1年で直面した課題とその解決策
ktc_wada
0
370
Reducing Cross-Zone Egress at Spotify with Custom gRPC Load Balancing Recap
koh_naga
0
210
エンジニア候補者向け資料2024.04.24.pdf
macloud
0
3.3k
いいたいことちゃんという
tkengo
0
110
Featured
See All Featured
Gamification - CAS2011
davidbonilla
76
4.6k
Unsuck your backbone
ammeep
663
57k
Git: the NoSQL Database
bkeepers
PRO
422
63k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
7
1k
The Language of Interfaces
destraynor
151
23k
Building an army of robots
kneath
300
41k
Infographics Made Easy
chrislema
238
18k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
A designer walks into a library…
pauljervisheath
200
23k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Debugging Ruby Performance
tmm1
70
11k
Documentation Writing (for coders)
carmenintech
60
3.9k
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 製品 - 記載の内容とは別にこういう考え方がある などなど、ご意見・ご感想をいただけると幸いです。