Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
FIFOキューで実現する Spring Bootの非同期処理とその性能評価方法
Search
Recruit
PRO
June 19, 2024
Technology
5
320
FIFOキューで実現する Spring Bootの非同期処理とその性能評価方法
2024/06/16 に、JJUG CCC 2024 Springで発表した、石塚と清水の資料です。
Recruit
PRO
June 19, 2024
Tweet
Share
More Decks by Recruit
See All by Recruit
スタサプ ForSCHOOLアプリのシンプルな設計
recruitengineers
PRO
3
840
リクルート流データ基盤塾~鶴谷と学ぶ~
recruitengineers
PRO
4
96
『SUUMO』 スマホサイト デザインリニューアルへの挑戦
recruitengineers
PRO
5
260
『リクルートダイレクトスカウト』 のリニューアルから振り返る: ビジョンドリブンの可能性
recruitengineers
PRO
3
250
負債あるモノリスのオブザーバビリティに組織で向き合う
recruitengineers
PRO
9
370
あなたの知らないiOS開発の世界
recruitengineers
PRO
4
310
大規模プロダクトにおける組織作りと技術ポートフォリオマネジメント
recruitengineers
PRO
4
420
OR学会2024秋_短期収益と将来のオフ方策評価性能を考慮したクーポン割当方策混合比の決定
recruitengineers
PRO
5
640
リクルート新人研修2024 テキスト生成AI活用
recruitengineers
PRO
12
920
Other Decks in Technology
See All in Technology
AWS Step Functionsのタスク入出力に秩序を与えよう
haku__hime
0
140
Rist_Meetup_Kaggleは業務の役にたつ - ビジネスコンテンツ情報を活用する BtoB 事業編 - / rist-meetup-20241012
taro_masuda
1
370
最新のAIツールは何を解決しようとしているのか - Python エンジニアが取り組むべき "越境" とは - / Python-Engineer-in-AI-Era
iktakahiro
1
110
ZOZOのデータマネジメントの取り組み:これまでとこれから / ZOZO's Data Management Initiatives
takagiyudai
0
170
Delta Commit…の最近...
akuwano
2
140
RSGT Walk Through
kawaguti
PRO
2
420
Snowflakeでスロークエリ改善に取り組んだ話
tabata0208
0
150
LeSS Yoake 2024 スポンサーセッション
riki_hiraoka
0
240
新入社員 オンボーディング改善プロジェクト - シンプルな仕組みで変革のきっかけを
enpipi
0
520
VPoE Meetup Vol.1 VPoEとして実践してきたことと反省点
coconala_engineer
2
200
複数の外部サービスデータの統合と変換を実現する Railsのインポートアーキテクチャ / Rails import architecture for integration and transformation of multiple external service data
aiandrox
0
390
カメラ単体で物体の3次元 座標を扱う方法
kenmatsu4
1
190
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.8k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
31
1.7k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
How GitHub (no longer) Works
holman
311
140k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
26
730
How to Ace a Technical Interview
jacobian
275
23k
Product Roadmaps are Hard
iamctodd
PRO
48
10k
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.3k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Intergalactic Javascript Robots from Outer Space
tanoku
268
27k
Transcript
Copyright © Recruit.co., Ltd. All rights reserved. FIFOキューで実現する Spring Bootの非同期処理とその性能評価方法
2024/06/16 (日) JJUG CCC 2024 Spring 株式会社リクルート HR Engineerグループ 石塚 崚斗/清水 海州
Copyright © Recruit.co., Ltd. All rights reserved. 自己紹介 1 石塚
崚斗 Ishizuka Ryoto • エンジニア歴4年目 • チームリーダー • SRE → Backend/Frontend • AWS/Kotlin/Spring boot 清水 海州 Shimizu Kaishu • エンジニア歴2年目 • 案件推進担当 • Backend → SRE • Kotlin/Spring boot
Copyright © Recruit.co., Ltd. All rights reserved. 今日お伝えすること 2 明らかに「重い」処理を切り離すために
非同期処理を導入します。技術的には Message QueueとMessage APIをク ラウド上に構築します。 非同期処理の実現方法 メッセージAPIのスループットを計測 して非同期処理の性能を評価します。 拡張性のためにある閾値に基づく オートスケーリングを実装します。 性能とスケーリング 「分離」は時として「局所化」した 非機能要件の把握を困難にしま す。マイクロサービス化における 落とし穴について説明します。 「分離」と「局所化」
Chapter1 Chapter2 Chapter3 Chapter4 何をしているの? 課題とその解決方法は? もっと俯瞰したら? 5 min. 10
min. 5 min. 5 min. 俯瞰したら? Copyright © Recruit.co., Ltd. All rights reserved. 今日の流れ 3
Chapter1 Chapter2 Chapter3 Chapter4 何をしているの? 5 min. Copyright © Recruit.co.,
Ltd. All rights reserved. 今日の流れ 課題とその解決方法は? 10 min. 5 min. 俯瞰したら? もっと俯瞰したら? 5 min. 4
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 5 質問に答えるだけで「早く」「簡単に」職務経歴書を作成できるサービス
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 6 質問に答えるだけで「早く」「簡単に」職務経歴書を作成できるサービス
※ 画像はイメージです
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 7 リクルートのHRメディアに対して
Web API を提供 AWS Cloud Web API ALB メディアX メディアY メディアZ
レジュメのPDFを 各メディアに連携せよ MISSION
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 9 AWS
Cloud Web API ALB メディアX メディアY メディアZ Web APIにPDF生成処理を実装 してPDFを連携する 安直な案
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 10 AWS
Cloud Web API ALB メディアX メディアY メディアZ Web APIにPDF生成処理を実装 してPDFを連携する 安直な案 PDF生成は非常に「重い」処理
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 11 AWS
Cloud Web API ALB メディアX メディアY メディアZ PDF生成は非常に「重い」処理 Web APIにPDF生成処理を実装 してPDFを連携する 安直な案
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 12 AWS
Cloud Web API ALB メディアX メディアY メディアZ Message Queue 非同期処理を行うMessage APIで生成されたPDFを連携する 改善案
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 13 AWS
Cloud Web API ALB メディアX メディアY メディアZ Message Queue Message API 非同期処理を行うMessage APIで生成されたPDFを連携する 改善案
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 14 AWS
Cloud Web API ALB メディアX メディアY メディアZ Message Queue Message API 非同期処理を行うMessage APIで生成されたPDFを連携する 改善案 分離
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 15 AWS
Cloud Web API ALB メディアX メディアY メディアZ Message Queue Message API 非同期処理を行うMessage APIで生成されたPDFを連携する 改善案 分離 局所化
Chapter1 Chapter2 Chapter3 Chapter4 何をしているの? 5 min. Copyright © Recruit.co.,
Ltd. All rights reserved. 今日の流れ 課題とその解決方法は? 10 min. 5 min. 俯瞰したら? もっと俯瞰したら? 5 min. 16
PDF連携が大幅に遅延 障害発生
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? PDF連携が大幅に遅延 18
AWS Cloud メディアX Message API Message Queue QueueにMessageが 大量に溜まってしまった メディアY メディアZ
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? PDF連携が大幅に遅延 19
AWS Cloud メディアX Message API Message Queue > Messageが 入る速度 Message APIの 処理速度 メディアY メディアZ
性能試験が不十分だった 根本原因
1. 負荷の低減 • 重複排除処理を実装 2. 水平拡張性の担保 • Message APIが1msgを捌くのに要する時間を計測 •
ECSにAuto Scalingを実装 対策
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? スループット ほぼ無制限
制限あり 配信 少なくとも1回 1回のみ 順序 可変 先入れ先出し Group id ×(付与できない) ◦(付与できる) 重複排除 ×(不可) ◦(可能)※ 一定時間再処理不可 重複排除処理を実装 22 標準キュー FIFOキュー
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? 重複排除処理を実装(As-Is) 23
AWS Cloud Message API … × 10 を同時処理 不要な処理※が 含まれる ※ 同一会員の重複処理
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? 重複排除処理を実装(To-Be) 24
AWS Cloud Message API … Group idごとに 1回だけ処理 Queueでは 重複排除しない Group id※付与 ※ 会員IDごと × 10 を同時処理
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? 重複排除処理を実装 25
Group idの付与 Group idごとに1回だけ処理
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? Message APIが1msgを捌くのに要する時間を計測
26 AWS Cloud Message API … 負荷掛け スループット計測
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? Message API
1タスクが1msgを捌くのに要する時間を計測 27 1タスクで 8 [msg/s] = 1タスクで 0.125 [s/msg]
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? ECSにAuto Scalingを実装
28 AWS Cloud Message API PDF連携のSLOを10sとすると Message API 1タスクあたりの許容バックログは 10 [s] / 0.125 [s/msg] = 80 [msg] Auto Scaling
Copyright © Recruit.co., Ltd. All rights reserved. 課題とその解決方法は? Message API
FIFOキューによる重複排除 & ECSのAuto Scaling 29 AWS Cloud メディアX メディアY メディアZ Message Queue < Messageが 入る速度 Message APIの 処理速度
Chapter1 Chapter2 Chapter3 Chapter4 何をしているの? 5 min. Copyright © Recruit.co.,
Ltd. All rights reserved. 今日の流れ 課題とその解決方法は? 10 min. 5 min. 俯瞰したら? もっと俯瞰したら? 5 min. 30
性能試験が不十分だった 根本原因
丁寧に性能試験すればいい 恒久対策
面白くない
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 34 エンジニア
アーキテクト
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 35 エンジニア
アーキテクト
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 36 エンジニア
アーキテクト 当然 は作るもの
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 37 エンジニア
アーキテクト 当然 は作るもの
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 38 エンジニア
アーキテクト 当然 は作るもの が抜け落ちた
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 39 エンジニア
手段の一部の つもり 完全な手段と 捉えた が抜け落ちた アーキテクト 当然 は作るもの
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 40 目的
PDFを10s以内に生成 手段 QueueとAPIの実装 選定 理由 ボトルネック局所化 水平拡張性の容易性 エンジニア アーキテクト
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 41 目的
PDFを10s以内に生成 手段 QueueとAPIの実装 選定 理由 ボトルネック局所化 水平拡張性の容易性 目的 PDFを10s以内に生成 手段 QueueとAPIの実装 選定 理由 ボトルネック局所化 水平拡張性の容易性 エンジニア アーキテクト
目的からの逸脱
1. 「目的」をエンジニアに伝える • 手段とその選定理由はエンジニアに任せる 2. 「目的から逸脱する可能性が低い手段」をエンジニアに伝える • エンジニアは手段を実装するだけ 考え得る方法
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 44 「目的」をエンジニアに伝える
アーキテクト エンジニア エンジニア 目的 目的
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 45 「目的」をエンジニアに伝える
アーキテクト エンジニア エンジニア 手段 目的 目的
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 46 「目的」をエンジニアに伝える
アーキテクト エンジニア エンジニア 十分な 経験・能力 手段 目的 目的
Copyright © Recruit.co., Ltd. All rights reserved. 俯瞰すると何が見えるの? 47 「目的から逸脱する可能性が低い手段」をエンジニアに伝える
アーキテクト エンジニア 手段 手段
Chapter1 Chapter2 Chapter3 Chapter4 何をしているの? 5 min. Copyright © Recruit.co.,
Ltd. All rights reserved. 今日の流れ 課題とその解決方法は? 10 min. 5 min. 俯瞰したら? もっと俯瞰したら? 5 min. 48
Copyright © Recruit.co., Ltd. All rights reserved. 何をしているの? 49 AWS
Cloud Web API ALB メディアX メディアY メディアZ Message Queue Message API 非同期処理を行うMessage APIで生成されたPDFを連携する 改善案 分離 局所化
非機能要件を担保するために Web APIをMessage QueueとMessage APIに「分離」した。 「局所化」された非機能要件を満たせなかった。 今回の事象
「分離」するマイクロサービス化が流行っているが 「局所化」された非機能要件を忘れていないか?
Copyright © Recruit.co., Ltd. All rights reserved. もっと俯瞰すると何が見えるの? 52 必要以上に「分離」されたマイクロサービス
Copyright © Recruit.co., Ltd. All rights reserved. もっと俯瞰すると何が見えるの? 53 必要以上に「分離」されたマイクロサービス
全体を結合して得られる機能要件は、 実現したい「コト」そのものである。 さらに機能要件には、 開発者の「常識」で補完されやすい性質がある。 機能要件は、 抜け漏れが発生することは少ない傾向にある。
Copyright © Recruit.co., Ltd. All rights reserved. もっと俯瞰すると何が見えるの? 54 必要以上に「分離」されたマイクロサービス
「機能要件以外」と定義される非機能要件は、 どのように「分離」され、 どのように「局所化」されているのか分かりにくい。 開発者に知識や経験がないと、 非機能要件の補完は難しいだろう。 したがって、各サービスの開発者が マイクロサービス全体の非機能要件を把握するのは、 非常に困難だろう。
Copyright © Recruit.co., Ltd. All rights reserved. もっと俯瞰すると何が見えるの? 55 必要以上に「分離」されたマイクロサービス
個別最適=全体最適
Copyright © Recruit.co., Ltd. All rights reserved. もっと俯瞰すると何が見えるの? 56 必要以上に「分離」されたマイクロサービス
Copyright © Recruit.co., Ltd. All rights reserved. もっと俯瞰すると何が見えるの? 57 必要以上に「分離」されたマイクロサービス
個別最適 個別最適 個別最適 個別最適
Copyright © Recruit.co., Ltd. All rights reserved. もっと俯瞰すると何が見えるの? 58 必要以上に「分離」されたマイクロサービス
個別最適 個別最適 個別最適 個別最適 ≠ 全体最適
どのような要件を「局所化」するために、 どのようにコンポーネントを「分離」するのか。 「分離」された全体のアーキテクチャにおいて、 「局所化」された要件はどこが担保するのか。 大規模プロダクトにおいては、 「分離」と「局所化」のバランスを整え、 全体を最適化するコーディネータが必要になるだろう。
Copyright © Recruit.co., Ltd. All rights reserved. まとめ 60 明らかに「重い」処理を切り離すために
非同期処理を導入した。技術的には Message QueueとMessage APIをク ラウド上に構築した。 非同期処理の実現方法 Message APIのスループットを計測し て非同期処理の性能を評価した。拡 張性のために許容バックログに基づ くAuto Scalingを実装した。 性能とスケーリング 「分離」は時として「局所化」した 非機能要件の把握を困難にする。 マイクロサービス化における落 とし穴を説明した。 「分離」と「局所化」