時間のかかっているバッチ処理をCloud Pub/Subで改善する話

■イベント
BtoB SaaS Tech Night　〜各社の改善への取り組み方〜
https://sansan.connpass.com/event/303753/

■登壇概要
タイトル：時間のかかっているバッチ処理をCloud Pub/Subで改善する話
登壇者：技術本部 Bill One Engineering Unit　石川 勇太

■Bill One エンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

Transcript

1. Sansan株式会社 部署 名前 時間のかかっているバッチ処理 Cloud Pub/Subで改善する話 Sansan技術本部 Sansan技術本部 技術本部 Bill One Engineering Unit ⽯川 勇太
2. ⽯川 勇太 Sansan株式会社 技術本部 Bill One Engineering Unit 2023年3⽉にSansanへ中途⼊社、前職では漫画アプリの開発をメ インでやっていました。現在はBill One Engineering Unitにて Complicated Subsystem Team(社内ではKombuチーム)に所属し ています。 Kombuチームとしてシステム全体の課題改善をしたり、検索マ イクロサービスの開発に従事するとともに、同チームのチームマ ネージャーを兼務。
3. 会社概要 2 表参道本社 神山ラボ Sansan Innovation Lab 社 名 Sansan株式会社 所在地 表参道本社 東京都渋⾕区神宮前5-52-2 ⻘⼭オーバルビル13F グループ 会社 Sansan Global Pte. Ltd.（シンガポール） Sansan Global Development Center, Inc.（フィリピン） ログミー株式会社 株式会社ダイヤモンド企業情報編集社 クリエイティブサーベイ株式会社 株式会社⾔語理解研究所 従業員数 1,510 名（2023年11⽉30⽇時点） 2007年6⽉11⽇ 設 ⽴ ⽀店：⼤阪、名古屋、福岡 サテライトオフィス：徳島、京都、新潟 拠 点 寺⽥ 親弘 代表者
4. - Bill Oneの構成と⾮同期処理 - バッチ処理について - Cloud Pub/Subへの移⾏ アジェンダ
5. Bill Oneの構成と⾮同期処理
6. Bill Oneの構成と⾮同期処理 - Bill OneはGCPを採⽤し、Cloud Runを使ったマイクロサービス構成 - マイクロサービス間の連携は⾮同期で⾏なっており、⾮同期処理には Cloud Tasksを使った仕組みを⾃作している - DBはCloud SQL for PostgreSQLを使っており、Row Level Security(RLS)を設定して運⽤している > RLSを設定することにより、意図しないデータへのアクセスをさせ ないようにしている > ドメインイベントにもRLSが適⽤されている - バッチ処理でも⾮同期処理を使っている
7. アーキテクチャ
8. バッチ処理について
9. - Cloud Schedulerを使ってバッチ開始⽤Endpointを定期実⾏している - バッチ処理はテナント毎に⾮同期処理を発⾏することで開始され、 いくつかの⾮同期処理を連鎖させて処理している Bill Oneのバッチ処理について
10. Bill Oneのバッチ処理の課題 - プロダクト規模に⽐例してテナント数も増えたことで、バッチ開始時の ⾮同期処理発⾏に30分以上かかっている - ⾮同期処理にもRLSが適⽤されいるため、chunkするなどの⼿段で 処理時間の改善ができない
11. バッチ処理におけるCloud Tasksの課題 - Cloud Tasksで短時間に⼤量メッセージをエンキューすると、配信レイ テンシーが遅くなり時間がかかりすぎる - キューの過負荷 https://cloud.google.com/tasks/docs/manage-cloud-task-scaling?hl=ja - ⼆重注⼊パターンでCloud Tasksへ⼤量メッセージをエンキューすること ができるが、⾮同期処理に⼤きく⼿を加える必要があ https://cloud.google.com/tasks/docs/manage-cloud-task-scaling?hl=ja#large- scalebatch_task_enqueues - batch messagingできない - 複数のメッセージをまとめて送ることがCloud Tasksではできない
12. Cloud Pub/Subへの移⾏
13. なぜCloud Pub/Subへ移⾏したのか - ⼀部の処理ではすでにCloud Pub/Subが使⽤されていて、ある程度の 知⾒と課題があった - ⾮同期処理の仕組みに⼿を⼊れてCloud Tasksで⼆重注⼊パターンを使う 案もあったが、⺟数が増えていくと分割しても捌けなくなる未来がいず れくるため、根本的に配信速度を上げたい - Cloud Pub/Subはbatch messagingが可能なため、⼤量に発⾏しやすい - Cloud Pub/SubはGoogleサービスのいくつかで使われていたインフラを ベースに構築されており、Bill Oneの規模を遥かに上回るデータを扱って いるので、配信については⼗分な性能を期待できる
14. Cloud Pub/Subでの検証結果 - Cloud Pub/Subでの配信⾃体は数分かからずに完了したが、 配信スピードが早くCloud Run側で429が多発した - 既存の処理を流⽤するためにPush Subscriptionを使⽤したが、 流量制限ができない - 配信スピードが早く、Cloud Runのスケールアウトが間に合わずに 半数以上のリクエストが429になり、リトライ対象となった
15. Cloud Pub/Subでの検証結果 - 結果的にはCloud Pub/Subのリトライ機構で完了できたが、以下の懸念 がある - 短時間に⼤量にリクエストを送るため、その間に他のAPIアクセスがあっ た場合に影響が出てしまう - 急激なスケールアウトの発⽣ - 429が多く発⽣してログが汚れる
16. どう改善したか - 以下のGoogleのブログ記事にある通り、PreviewではあるがCloud Tasksに Buffer Task APIとキューレベルルーティング構成の機能が提供されており、 Cloud Pub/Subを組みわせることで改善できることがわかった > https://cloud.google.com/blog/ja/products/serverless/buffer-http-requests-with- cloud-tasks/
17. Buffer Task API - Buffer Task APIは呼び出し元がタスク構成（HTTP URL、ヘッダー、 認証）を提供することなく HTTP タスクを作成できる新しい API > Buffer Task APIを使う場合は、キューレベル ルーティング構成機能 でキュー⾃体にルーティング設定が必要 - SDKを使ってCloud Tasksにエンキューしていたが、 これを使うことによってルーティングは固定されるが、 HTTPリクエストを送るだけでエンキューが可能となる
18. キューレベルルーティング構成 - キューレベルルーティング構成とは、キューに積まれたタスクの ルーティングは本来エンキューするタスクが持っていますが、 これをキューレベルで上書きする機能 > これを使うとキューにつまれたタスクは、上書きされた ルーティングにしかリクエストされません - この機能単体ではあまり使われることはなさそうですが、 Buffer Task APIとCloud Pub/Subと組み合わせることで効果的に 利⽤できる
19. Cloud Pub/Sub & Cloud Tasksへの移⾏
20. Cloud Pub/Sub & Cloud Tasksでの検証結果 - お互いの課題を補完しあった構成になっており、Cloud Pub/Sub単体の 課題であったSubscriber側の流量制限が可能となり、Cloud Tasksで課 題だった⼤量タスクの配信が改善した > Cloud Pub/Sub単体と同条件で検証した結果、Publish速度はCloud Pub/Subと同様でCloud Tasksで流量制限可能になり、緩やかに⾮ 同期処理が発⾏された > 429も発⽣することなく、過度なスケールアウトも起こらずに 捌き切った
21. 移⾏後の感想 - Cloud Pub/Sub単体だけではSubscriberのスケールアウトに⼤きな懸念 があったが、Subscription側を⼯夫することで流量制限が可能になった - Previewではあるが、Cloud TasksのBuffer Task APIと組み合わせることで Subscriberへの流量制限が可能になり、ベストな形で実装できた - Cloud Pub/Subについては、PublisherとSubscriberを分割していてシン プルな構成だと思っていたが、意外と考えることが多く運⽤の複雑さは Cloud Tasksよりも⾼くなったと感じている
22. 移⾏後の感想 ⾮同期処理の選択肢としてGCPだとCloud TasksとCloud Pub/Subがある が、どの構成に対象が良いかは⾮機能要件やメリデメを加味して選択する 必要があると感じた メリット デメリット Cloud Tasks ⼆重注⼊パターン Cloud Tasksだけを使うので構成はシンプル。 ⼤量にエンキューする場合は、キューの過負荷 の考慮や⼆重注⼊パターンを使⽤するなど⼯夫 が必要になってくる。 Cloud Pub/Sub batch messagingがあるので、⼤量発⾏は Tasksよりもやりやすい。 Subscriber側が⼗分にスケールできる場合な どはCloud Pub/Sub単体の構成でも良い。 Cloud Pub/SubのPush Subscription⾃体に流量 制限がないため、Subscriber側で⼤量のリクエ ストの対策が必要。 Cloud Pub/Sub & Tasks Cloud Pub/Subの配信スピードとCloud Tasks での流量制限が可能になり、⼤量に送って緩 やかに処理することが可能。 Cloud Pub/SubとCloud Tasksを併⽤している ので障害点が2つになっていたり、何か起きた 時の調査がしづらい。 Preview機能を使っている。