Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
モチベーションクラウドを支える非同期処理の変遷
Search
リンクアンドモチベーション
PRO
February 01, 2021
Technology
250
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
モチベーションクラウドを支える非同期処理の変遷
リンクアンドモチベーション
PRO
February 01, 2021
More Decks by リンクアンドモチベーション
See All by リンクアンドモチベーション
AI活用勉強会は いいぞ!
lmi
PRO
1
270
AI時代だからこそ、 一次情報を足で稼ぐ
lmi
PRO
0
56
非開発組織のDX推進 ―― AI時代こそ「要件定義」が勝負
lmi
PRO
1
400
全社員がAIを「使う」の次へ ーノンエンジニア1,500人が安全に業務を作り変えるゴールデンパスとガードレール
lmi
PRO
3
3.7k
2年で50%しか進まなかった1,500ファイルの型付けを、3週間で片付けた話
lmi
PRO
0
120
「React でいいじゃん」と思ってた私が、「Vue 熱いじゃん」ってなった話
lmi
PRO
1
430
「AIがあれば越境できる」と思ったら、 AI Slopの山ができた
lmi
PRO
1
520
上司のダメ出しを全部AIに食わせ続けたら、 最強の相棒になってきた話
lmi
PRO
0
70
ペーペーのPdMがドペーペーの開発者になったら、見えた世界
lmi
PRO
0
77
Other Decks in Technology
See All in Technology
OR学会2026年秋期大会_機械学習と数理最適化の融合による、配合レシピ最適化システム開発事例
brainpadpr
0
120
Datadog の学び方 - あるいは、オブザーバビリティを学ぶとは何か
mananyuki
1
530
12 個 Tool と、 4,096 Token
hlum
0
110
AgentCoreで実践するハーネスエンジニアリング
yakumo
1
300
分析の民主化を支えるメタデータ整備の実践
kakehashi
PRO
4
1.2k
The seven pitfalls of AI (revised version)
ufried
0
310
自主式軟體工廠
philipz
0
250
分析AIエージェントを育てる、動く環境を育てる
codatum
1
750
ファミコンでPHPを動かす / PHP on the Famicom side b
tomzoh
0
140
生成AIと進める探索的データ分析(2026.10.03 第122回Tokyo.R勉強会)
tatamiya
2
1.5k
並行性の問題を防げ!実践トランザクション入門
occhi
0
280
ハードウェアコンペでもAI駆動開発が進んでいる話
iotengineer22
1
670
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
46
8.3k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
570
Balancing Empowerment & Direction
lara
6
1.3k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
790
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.9k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
250
1.3M
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
840
Code Reviewing Like a Champion
maltzj
529
40k
The untapped power of vector embeddings
frankvandijk
2
1.9k
Building AI with AI
inesmontani
PRO
1
1.3k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
68
58k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
520
Transcript
モチベーション クラウドを支える 非同期処理の変遷 伊藤遼
自己紹介 伊藤 遼 • (株) リンクアンドモチベーションに新卒入社 2年目 • 配属当初から弊社プロダクトの性能改善チームに所属 (エンジニア歴
1年)
今日話すこと • プロジェクトの背景 • 何をしたか • 苦労したこと • やってよかったこと •
これから目指すところ モチベーションクラウドの非同期処理を刷新した話
非同期処理効率化プロジェクトの背景 • 超大手企業への導入 1社あたりの処理負荷の増大 • 導入社数の増加 同時処理数が増加 プロダクトの成長により....
バッチサーバー1台で、cronを回していたので 1処理の負荷が高まりサーバの限界を超えた... 何が起きたか? part 1 処理 A SaaSだと企業ごとに処理するので、 企業規模が大きくなると1処理の量が増えて許容量を超える 鳴り響くサーバアラート
処理 B 処理 C 処理 A 処理 B 処理 C
単一サーバ + 大量のcron • サイズの大きい単一サーバで運用 • 毎分20超、毎時10超のrake taskが起動 負荷が集中すると1台しかないサーバが耐えきれない 可用性を高めるためにスケーラブルにしたい
課題
A 社 の 処 理 各社の 待ち時間 何が起きたか? part 2
ユーザーからのクレーム SaaSだと企業ごとに処理するので、 導入企業数が多くなると待ち時間がながくなる 直列処理のため耐えられないほどの待ち時間がかかった B 社 の 処 理 C 社 の 処 理 A 社 の 処 理 B 社 の 処 理 C 社 の 処 理 D 社 の 処 理 E 社 の 処 理 F 社 の 処 理 許容待ち時間 許容待ち時間
処理が直列で実行されていた • 企業規模や企業数が多くなると後続の処理が遅延 • 例外発生時、後続の処理が遅延 (もしくは処理されない) 企業毎に処理を並列化したい 課題
検討したgemとアーキテクチャ gem \ 判断基準 ⭐ キュー 運用実績 負荷耐性 運用コスト sidekiq
10.7k redis × ◯ × resque 8.8k redis × ◯ × delayed_job 4.6k DB × × △ shoryuken 1.7k SQS × ◯ ◯ active elastic job 253 SQS ◯ ◯ ◯ 1. 可用性を高めるためにスケーラブルにしたい 2. 企業毎に処理を並列化したい
gem \ 判断基準 ⭐ キュー 運用実績 負荷耐性 運用コスト sidekiq 10.7k
redis × ◯ × resque 8.8k redis × ◯ × delayed_job 4.6k DB × × △ shoryuken 1.7k SQS × ◯ ◯ active elastic job 253 SQS ◯ ◯ ◯ 運用実績、負荷耐性、運用コストの観点で active elastic job (SQS + Worker) 構成に決まった 検討したgemとアーキテクチャ
どうやって解決したか • EC2 1台 SQS + EB worker構成にした
• SQSは重複配信される可能性がある 既存の処理は冪等性が担保されていない 重複実行されないような制御を実装 苦労したこと part 1 処理 A して
処理 A して 処理 A して
• 例外発生時のリトライ処理の実装 SQSには失敗時の自動リトライ用の仕組みがある 処理時間や重要度が様々なのでカスタマイズしたい 処理ごとにリトライ待機時間、回数制限を 定義できるようにした 苦労したこと part 2 処理
A × 5 処理 B × 50
• 実行条件が揃っていない時はリトライさせたい 実行条件が処理ごとにバラバラ 処理ごとに実行可能かどうかを定義できるようにした 苦労したこと part 3 処理 A して
処理 B して 集計処理完了? 一括処理完了?
結果 • 待ち時間が短くなった! • 負荷集中にもAutoScaleで自動対応できるようになった! 実績として、 過去最大社数の同時サーベイの実施も問題なし!
• 1つの処理で複数の責任をもっていたでっかい処理を 適切に分割できた • 非同期処理するためだけのテーブルの削除 副次効果 今後の開発生産性にも寄与
今後の予定 • 残りの非同期処理の SQS + Worker化 (全ての非同期処理の刷新) • 脱cron (ジョブスケジュラーの導入)
• ECS化
今日みたいな根本的なアーキテクチャ変更も 若手がガンガン実施してます! チャレンジしたい人大募集! ※興味がある方はぜひご連絡ください! ↓ ご清聴いただき、ありがとうございました!