GCPを使った transaction log tailing と polling publisher の性能比較

Transcript

1. GCPを使った transaction log tailing と polling publisher の性能比較 　2023/3/17　株式会社ホワイトプラス　古賀
2. 非同期処理基盤（PoC） ① Service1がイベントをFirestoreに保存 ② Message Relay がイベントを取得 ③ Message Relay がイベントをPub/Subへ投げる ④ Service2がイベントを受け取って処理する
3. 非同期処理基盤（PoC） 2パターンの実装方法がある ・polling publisher ・transaction log tailing
4. polling publisher（pull 方式） ①常時稼働の worker が Firestore を定期的に polling する ②取得したイベントデータを Pub/Sub に投げる
5. transaction log tailing（push 方式） ①新規ドキュメント(イベント)作成時、Eventarc 経由でCloud Run に通知 ②リクエストに含まれるIDを元に Firestore からイベントを取得 ③取得したイベントを Pub/Sub へ投げる
6. 性能比較ポイント ・順序保証の有無 ・スケーラビリティ ・メンテナビリティ
7. 性能比較：順序保証の有無 ▪polling publisher（◯） workerがイベントを作成日時順に取得し Pub/Subへ投げる、を繰 り返すことで作成された順番で配信（順序保証）が可能 ▪transaction log tailing（×） おおよそイベントは登録された順番に処理フローに乗る Eventarc に順序保証の仕組みが無い（※） イベントの順序配信がない前提で受信側の処理を設計する ※厳密に言うと、トランスポート層の Pub/Sub に任意の順序指定キーを渡すことができないために順序保証ができない
8. 性能比較：スケーラビリティ ▪polling publisher（△） （順序保証する前提で）イベント量が増えると worker が律速 要因となりレイテンシが上がりやすい 小規模であれば問題にならない（要計測） ▪transaction log tailing（◯） イベント量が増えても Cloud Run・Firestore がスケールする ためレイテンシは上がりにくい
9. 性能比較：メンテナビリティ ▪polling publisher（△） 自前で順序保証ロジックを実装・保守しなければならない workerが詰まった時（配信遅延の閾値を超えた時）の緊急対 応、予防策（パフォーマンスチューニング等）が必要となり得る ▪transaction log tailing（◯） 順序保証・スケーリングについてのロジックの構築は不要 （稼働状況の監視、異常の検知は必要） 低いメンテナンスコストで安定稼働が可能
10. 比較結果 polling publisher transaction log tailing 順序保証の有無 ◯ × スケーラビリティ △ ◯ メンテナビリティ △ ◯ スケーラビリティ・メンテナビリティは transaction log tailing が優位、polling publisher は懸念あり 現行の非同期処理基盤では順序保証をしていないため、順序保証は必須でない 順序保証が無くても、受信したイベントと処理したイベントのタイムスタンプを比較する事で、受信側で生成順序を判 定してハンドリングするなど、ある程度設計でカバー可能 → 現時点では transaction log tailing の方向で検討中
11. Discussion Time ・polling publisher や transaction log tailing のメリット、デメリット ・順序保証の仕組みが必要な事例（もしあれば） ・発表内容についてのコメント