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
モチベーションクラウドを支える非同期処理の変遷
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
リンクアンドモチベーション
PRO
February 01, 2021
Technology
230
0
Share
モチベーションクラウドを支える非同期処理の変遷
リンクアンドモチベーション
PRO
February 01, 2021
More Decks by リンクアンドモチベーション
See All by リンクアンドモチベーション
RubyKaigiに参加することで気づいた 「俺、Rubyのこと全然知らなくね?」/ RailsTokyo#4
lmi
PRO
0
60
非エンジニアの私の、AIを動かすコツ ── 振り返る、Whyを伝える、歩み寄る / LT大会&交流会 by QuratedLab
lmi
PRO
0
22
逃げ場をなくしたら見えた景色 — 新人SREがAIで「自分の領域」を作るまで/rookie-sre-no-way-back_link-and-motivation
lmi
PRO
0
74
AI時代の新卒を黄金世代にするために 〜やってよかったこと、まだ足りないこと〜/ai-native-engineers_link-and-motivation
lmi
PRO
0
120
失敗から学ぶ ~サブエージェントの正しい使い方~/subagent-lessons-learned_link-and-motivation
lmi
PRO
0
560
ワクワクは「管理」できないが 「設計」することはできる/designing-excitement--link-and-motivation
lmi
PRO
0
92
IFを定義して、コードとチームを守れ!/protect-code-and-team-link-and-motivation
lmi
PRO
0
420
120個作って、ようやく気づいた。 AIツールは“作る”より“使われ続ける”が難しい/Generative AI × Workflow Automation-lmi
lmi
PRO
0
73
太りすぎコアモデルのダイエット作戦(減量編) / railstokyo-03-lmi
lmi
PRO
0
100
Other Decks in Technology
See All in Technology
マンション備え付けのネットワークとLTE回線を組み合わせた ネットワークの安定化の考案
harutiro
1
140
RedmineをAIで効率的に使う検証
yoshiokacb
0
160
障害対応のRunbookは作った、でも本当に動くの? AWS FIS で EKS の AZ 障害を再現してみた
tk3fftk
0
120
データ分析基盤の信頼を支える視点と設計
yuki_saito
0
120
Directions Asia 2026 | Beyond Buildable AI Agents: Let’s Visualize Partner Value in the AI Era
ryoheig0405
0
130
GCASアップデート(202603-202605)
techniczna
0
240
その英語学習、AWSで代替できませんか?
suzutatsu
1
170
生成AI時代に信頼性をどう保ち続けるか - Policy as Code の実践
akitok_
1
530
Loadbalancing exporter internals
ymotongpoo
1
120
サプライチェーン攻撃への備えについて考えている #湘なんか
stefafafan
2
2k
続 運用改善、不都合な真実 〜 物理制約のない運用改善はほとんど無価値 / 20260518-ssmjp-kaizen-no-value-without-physical-constraints
opelab
2
290
React Compiler導入から21ヶ月、いま始めるならこうやる
astatsuya
2
280
Featured
See All Featured
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
400
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
440
Embracing the Ebb and Flow
colly
88
5k
Building AI with AI
inesmontani
PRO
1
1k
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
120
YesSQL, Process and Tooling at Scale
rocio
174
15k
Faster Mobile Websites
deanohume
310
31k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.5k
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
0
510
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化
今日みたいな根本的なアーキテクチャ変更も 若手がガンガン実施してます! チャレンジしたい人大募集! ※興味がある方はぜひご連絡ください! ↓ ご清聴いただき、ありがとうございました!