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
190
モチベーションクラウドを支える非同期処理の変遷
リンクアンドモチベーション
February 01, 2021
Tweet
Share
More Decks by リンクアンドモチベーション
See All by リンクアンドモチベーション
リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers
lmi
4
300k
AIとともに歩んだライブラリアップデートの道のり/ vue-fes-japan-2024-link-and-motivation
lmi
2
5k
Aiderとともに進めるライブラリアップデートの第一歩 / ai-agent-software-link-and-motivation
lmi
1
91
AIとともに踏み出す技術的負債返済への一歩 / Tech-Debt-Meetup-link-and-motivation
lmi
1
98
開発チームへのディープダイブで見えてきた顧客=開発者の本当の課題/sre-next-2024-link-and-motivation
lmi
1
1.7k
dxd2024-生成AIに振り回された3か月間の成功と失敗/dxd2024-link-and-motivation
lmi
2
650
生成AIに振り回された3か月間の成功と失敗/dev-productivity-con2024-link-and-motivation
lmi
8
7.7k
ゼロから始めるVue.jsコミュニティ貢献 / first-vuejs-community-contribution-link-and-motivation
lmi
1
350
ハイパフォーマンスな組織をつくるための開発生産性の考え方 / developer-productivity-high-performer-link-and-motivation
lmi
3
1k
Other Decks in Technology
See All in Technology
LINEヤフーにおけるPrerender技術の導入とその効果
narirou
2
2.2k
Next.jsとNuxtが混在? iframeでなんとかする!
ypresto
2
1.8k
【LT】ソフトウェア産業は進化しているのか? #Agilejapan
takabow
1
130
Amazon Forecast亡き今、我々がマネージドサービスに頼らず時系列予測を実行する方法
sadynitro
0
190
セキュリティベンダー/ユーザー双方の視点で語る、 Attack Surface Managementの実践 - Finatextパート / cloudnative-architecture-of-asm
stajima
0
260
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
13
1.6k
もし大規模障害が、10分で解決できたら?
masaaki_k
0
110
rootlessコンテナのすゝめ - 研究室サーバーでもできる安全なコンテナ管理
kitsuya0828
3
400
【Startup CTO of the Year 2024 / Audience Award】アセンド取締役CTO 丹羽健
niwatakeru
0
2k
アジャイルでの品質の進化 Agile in Motion vol.1/20241118 Hiroyuki Sato
shift_evolve
0
210
Security-JAWS【第35回】勉強会クラウドにおけるマルウェアやコンテンツ改ざんへの対策
4su_para
0
200
OS 標準のデザインシステムを超えて - より柔軟な Flutter テーマ管理 | FlutterKaigi 2024
ronnnnn
1
370
Featured
See All Featured
Measuring & Analyzing Core Web Vitals
bluesmoon
4
140
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
4
380
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
We Have a Design System, Now What?
morganepeng
50
7.2k
A Philosophy of Restraint
colly
203
16k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
Fashionably flexible responsive web design (full day workshop)
malarkey
405
65k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
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化
今日みたいな根本的なアーキテクチャ変更も 若手がガンガン実施してます! チャレンジしたい人大募集! ※興味がある方はぜひご連絡ください! ↓ ご清聴いただき、ありがとうございました!