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
リンクアンドモチベーション
February 01, 2021
Technology
0
210
モチベーションクラウドを支える非同期処理の変遷
リンクアンドモチベーション
February 01, 2021
Tweet
Share
More Decks by リンクアンドモチベーション
See All by リンクアンドモチベーション
影響力タイプ診断(EM編) / EMOasis-08-link-and-motivation
lmi
1
100
「アカウントください」はPRで —IaC化によるユーザー管理の改善 / Engineering-Productivity-Meetup-04-link-and-motivation
lmi
0
140
AIが悪いんじゃないよ、君が悪いんだよ / AI-engineering-summit-link-and-motivation
lmi
1
110
生成AIを活用して一月で10万行、20倍速で新規プロダクトを形にする開発術 / 20x-product-development-link-and-motivation
lmi
0
340
生成AI活用で「一人当たり売上高140%」の実現 / generativeai-summit-5-link-and-motivation
lmi
0
90
生成AIで実現!スッキリ解決、デッドコードの整理術 /cleaning-up-dead-code-link-and-motivation
lmi
0
680
リンクアンドモチベーション 営業コンサルタント向け紹介資料 / Introduction to Link and Motivation for Sales and Consultants
lmi
0
140k
リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers
lmi
4
420k
AIとともに歩んだライブラリアップデートの道のり/ vue-fes-japan-2024-link-and-motivation
lmi
2
7.2k
Other Decks in Technology
See All in Technology
CI/CD/IaC 久々に0から環境を作ったらこうなりました
kaz29
1
170
本が全く読めなかった過去の自分へ
genshun9
0
170
AWS アーキテクチャ作図入門/aws-architecture-diagram-101
ma2shita
29
11k
5min GuardDuty Extended Threat Detection EKS
takakuni
0
140
VISITS_AIIoTビジネス共創ラボ登壇資料.pdf
iotcomjpadmin
0
160
登壇ネタの見つけ方 / How to find talk topics
pinkumohikan
3
380
Claude Code Actionを使ったコード品質改善の取り組み
potix2
PRO
6
2.2k
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
11
3.9k
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
210
Uniadex__公開版_20250617-AIxIoTビジネス共創ラボ_ツナガルチカラ_.pdf
iotcomjpadmin
0
160
AIの最新技術&テーマをつまんで紹介&フリートークするシリーズ #1 量子機械学習の入門
tkhresk
0
140
Witchcraft for Memory
pocke
1
300
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Building an army of robots
kneath
306
45k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
A Modern Web Designer's Workflow
chriscoyier
694
190k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
20k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Why You Should Never Use an ORM
jnunemaker
PRO
57
9.4k
The Cost Of JavaScript in 2023
addyosmani
51
8.4k
Stop Working from a Prison Cell
hatefulcrawdad
270
20k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
107
19k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
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化
今日みたいな根本的なアーキテクチャ変更も 若手がガンガン実施してます! チャレンジしたい人大募集! ※興味がある方はぜひご連絡ください! ↓ ご清聴いただき、ありがとうございました!