Cloud Pub/Sub Pull Subscriberの構成検討

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 製品 - 記載の内容とは別にこういう考え方があるなどなど、ご意見・ご感想をいただけると幸いです。

Cloud Pub/Sub Pull Subscriberの構成検討

Cloud Pub/Sub Pull Subscriberの構成検討

atsu.kg

More Decks by atsu.kg

Other Decks in Technology

Featured

Transcript