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
340
AI時代だからこそ、 一次情報を足で稼ぐ
lmi
PRO
0
60
非開発組織のDX推進 ―― AI時代こそ「要件定義」が勝負
lmi
PRO
1
400
全社員がAIを「使う」の次へ ーノンエンジニア1,500人が安全に業務を作り変えるゴールデンパスとガードレール
lmi
PRO
4
3.9k
2年で50%しか進まなかった1,500ファイルの型付けを、3週間で片付けた話
lmi
PRO
0
120
「React でいいじゃん」と思ってた私が、「Vue 熱いじゃん」ってなった話
lmi
PRO
1
440
「AIがあれば越境できる」と思ったら、 AI Slopの山ができた
lmi
PRO
1
540
上司のダメ出しを全部AIに食わせ続けたら、 最強の相棒になってきた話
lmi
PRO
0
70
ペーペーのPdMがドペーペーの開発者になったら、見えた世界
lmi
PRO
0
81
Other Decks in Technology
See All in Technology
実践! SRE × AI - ABEMA における AIOps -
tetsuya28
8
3.1k
Kiro Crewで「みのるん式」仕事術やってみた
minorun365
PRO
3
650
宣言型部分更新は何を解決しどこへ向かうのか
shuta13
1
470
1つのリクエストを追って理解する - llm-dのP/D分離
akhino
1
160
PHPカンファレンス関西の招待状 / Invitation to PHP Conference Kansai
ykanoh
0
210
React改造してみた
tsukina_7mochi
0
120
QA4AI 2026-Oct 生成AI時代の品質保証
tokuty
1
890
価値について
gree_tech
PRO
0
100
会社紹介資料 / Sansan Company Profile
sansan33
PRO
31
430k
NDIでApple Vision Proにリアルタイム映像送信
jyouryuusui
0
130
フィンテック養成勉強会#68
finengine
0
150
フロントエンドカンファレンス関西2026 - 速すぎるUIに、待ち時間を
teamlab
PRO
0
190
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Navigating the moral maze — ethical principles for Al-driven product design
skipperchong
2
630
Learning to Love Humans: Emotional Interface Design
aarron
275
41k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
2
310
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.9k
RailsConf 2023
tenderlove
30
1.6k
Rails Girls Zürich Keynote
gr2m
96
14k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
8.1k
Exploring anti-patterns in Rails
aemeredith
4
540
[RailsConf 2023] Rails as a piece of cake
palkan
59
7.1k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.9k
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
320
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化
今日みたいな根本的なアーキテクチャ変更も 若手がガンガン実施してます! チャレンジしたい人大募集! ※興味がある方はぜひご連絡ください! ↓ ご清聴いただき、ありがとうございました!