ポーリング処理廃止によるイベント駆動アーキテクチャへの移行

Transcript

1. ポーリング処理廃止による イベント駆動アーキテクチャへの移行 Go Junction #1
2. 自己紹介 所属 • CyberAgent / MGDX • 薬急便（医療系SaaS） • バックエンド兼SRE 最近の趣味 • プレミアリーグ観戦⚽ • 旅⾏✈   @eiaou_f フジガキ セイタロウ 藤垣 成汰朗
3. 予約検索の既存アーキテクチャ ‧各クライアントでポーリング ‧ポーリング間隔: 30sec ‧1回あたりのAPIコール数: 9回 予約検索APIで 2,000 req/sec
4. 課題 高負荷 スケーラビリティへ の懸念 非効率な リソース利用
5. 問題の本質 ポーリングの根本的な問題 は何か？
6. 問題の本質 データに変更があってもなくても、定期的にリクエストが発生する ＝ 無駄なリクエストが多い
7. 変更があったときにサーバーから クライアントへ通知すれば良いのでは…！
8. サーバープッシュ型の通信方式 選択肢 メリット デメリット WebSocket リアルタイム性が 高い 双方向通信が可能 低レイテンシ 通知用途には過剰機能 接続管理が複雑 スケーリングが難しい ※ Server-Sent Events ブラウザネイティブ対応 HTTP/1.1で動作 自動再接続あり 接続管理が複雑 スケーリングが難しい ※ gRPC Server Streaming 型安全・バイナリ効率が良い モバイル/BFF構成と相性◎ ブラウザはgRPC-Web経由で導入コス ト高 接続管理が複雑 スケーリングが難しい ※ ※接続がPodに固定されるため、別 Podに届いたイベントを他 Podの接続クライアントへ転送する仕組みが別途必要
9. サーバーからクライアントへの通信方式 選択肢 メリット デメリット WebSocket リアルタイム性が高い 双方向通信が可能 低レイテンシ 通知用途には過剰機能 接続管理が複雑 スケーリングが難しい ※ Server-Sent Events ブラウザネイティブ対応 HTTP/1.1で動作 自動再接続あり 接続管理が複雑 スケーリングが難しい ※ gRPC Server Streaming 型安全・バイナリ効率が良い モバイル/BFF構成と相性◎ ブラウザはgRPC-Web経由で導入コス ト高 接続管理が複雑 スケーリングが難しい ※ ※接続がPodに固定されるため、別 Podに届いたイベントを他 Podの接続クライアントへ転送する仕組みが別途必要
10. もう少し簡単な⽅法はないのか？
11. ありました
12. 新アーキテクチャ 1. 予約サービスからイベント発⽕ 2. Pub/Subにメッセージを配信 3. イベント伝播サービスが購読 4. イベント伝播サービスがFirestoreの薬局別 ドキュメントを更新 5. 薬局ドキュメントを監視しているフロント エンドがFirestoreの変更をリアルタイム検 知 6. 予約取得APIから予約データを取得
13. なぜFirestore？ • リアルタイム同期機能が標準装備 ◦ SDKを使うだけで、⾯倒な接続管理なしにリアルタイム同期が実現可能 • スケーラビリティ ◦ クライアント数の増加に対して、インフラ側での対応が不要 • 薬局ごとのドキュメント分離 ◦ 各薬局が⾃⾝に関係するドキュメントのみを購読するため、他の薬局のイベントなど不要 なデータを受信することがない • 既存のGoogle Cloud環境との親和性 ◦ すでにGKEやPub/Subを使⽤していたため、同じエコシステム内で完結できる点も⼤きな メリットでした
14. 短期間に多数のイベントが発⽣した 場合、そのままクライアントに伝播 すると、都度APIを呼び出してしまう 結局⼤量のリクエストが発⽣！ 課題：短時間に⼤量のイベントが発⽣するケース
15. Cloud Tasksを使ったスロットリング 機構を導⼊ ⼀定時間内に発⽣した複数のイベント を、1回の通知にまとめる APIリクエストの集中を回避！ 解決策：Cloud Tasksによるスロットリング
16. リアーキテクチャ後の結果 定性的 • 予約⼀覧更新のリアルタイム性の向上 定量的 指標 改善前 改善後 削減率 予約検索APIの秒間リクエスト数 約2,000/秒 約1,000/秒 50% DBコスト 100% 70% 30%
17. • 問題 ◦ ポーリング処理によりAPIサーバーやDBへの負荷が⾼い状況 • 解決策 ◦ Firestoreを利⽤することで、サーバーからクライアントへのイベント通知を実現し、ポー リング処理から移⾏することができた ◦ Cloud Tasksを利⽤してスロットリング機構を導⼊し、⼀定期間のイベントを1つのイベン トにまとめることに成功 • 結果 ◦ 対象APIの秒間リクエスト数が半減 ◦ DBコストも30％程度削減成功 まとめ
18. ご清聴ありがとうございました