Cloud Pub/Sub Pull Subscriberの構成検討

Transcript

1. Cloud Pub/Sub Pull Subscriberの構成検討 株式会社ホワイトプラス　古賀 敦士
2. フルマネージドのリアルタイムメッセージングサービス メッセージを生成するサービスと、処理するサービスを非同期的に切り離す 2 Cloud Pub/Sub とは
3. 3 Push型／Pull型
4. 4 Push Subscription Pub/SubサーバーがSubscriberにメッセージをHTTPSリクエストとして送信 処理完了したら成功のステータスコードを返すことで確認応答 秒間メッセージ数が多い場合はPull Subscriptionを推奨 ← バッチによる急増を懸念
5. 5 Pull Subscription SubscriberはPub/Subサーバーに対してメッセージをリクエストする 処理完了したら確認応答リクエストを送信する バッチ型と常駐型の2つの実装方法が考えられる
6. 6 サブスクライバをバッチにし定期的に処理する ・メリット 常駐型よりもリソース効率が良い ・デメリット メッセージパブリッシュから処理完了までが 常駐方式よりも長い ← 懸念 バッチ型
7. 7 サブスクライバを常に稼働させてポーリングする ・メリット メッセージパブリッシュから処理完了までが短い ・デメリット 未処理のメッセージがない状態ではリソース効率が悪い 常駐型
8. 8 Google Cloud 製品の検討
9. 9 常駐型またはバッチ型が実装可能か オートスケールされるか の観点で調査
10. 10 Cloud Run（Service） 常駐方式：◯ or △ - always on CPU を使って可能 - リクエストを受信しないためオートスケールされない可能性あり? バッチ方式：◯ - 外部からの定期的なリクエストをトリガーにPullすることで可能 - オートスケール可能
11. 常駐方式：△ - タスクのタイムアウト・試行回数制限があり、それを超えると失敗扱いになる - スケジュール実行するが実行時間が実行間隔を埋めることで、常駐方式と同様になる - ex. 実行時間1h・タイムアウト1h10minのタスクを1h間隔で実行する - 事前に並列処理数を設定できるが、処理状況に応じたオートスケールは無し バッチ方式：△ - スケジュール実行することで可能 - 事前に並列処理数を設定できるが、処理状況に応じたオートスケールは無し 11 Cloud Run（Job）
12. 常駐方式：◦ - タスクのタイムアウト・試行回数制限があり、それを超えると失敗扱いになる - スケジュール実行するが実行時間が実行間隔を埋めることで、常駐方式と同様になる - オートスケール可能 バッチ方式：◯ - スケジュール実行することで可能 - オートスケール可能 12 Cloud Batch
13. 常駐方式：△ - フレキシブル環境ならば常時実行可能かも - リクエストが無ければオートスケールされないかも バッチ方式：◯ - スケジュール実行することで可能 - リクエストが無ければオートスケールされないかも 13 App Engine
14. 常駐方式：◯ or △ - 可能そう - オートスケール可能 バッチ方式：◯ or △ - 可能かも - オートスケール可能 14 Compute Engine（MIG）
15. 15 Discussion Time - Push Subscription での実装可能性 - Pull Subscriber の常駐型とバッチ型の良し悪し - 常駐型に向いてそうな Google Cloud 製品 - 記載の内容とは別にこういう考え方がある などなど、ご意見・ご感想をいただけると幸いです。