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
220
モチベーションクラウドを支える非同期処理の変遷
リンクアンドモチベーション
February 01, 2021
Tweet
Share
More Decks by リンクアンドモチベーション
See All by リンクアンドモチベーション
プロダクトエンジニアは目指すものじゃない / product-engineer-2025-link-and-motivation
lmi
1
150
ツールを埋め込み組織と伴走する、エンジニアの価値のつくり方 / uv-study-link-and-motivation
lmi
0
53
テストコードからPRの質をあげる / megurolt-32-link-and-motiation
lmi
1
160
VueとAIは相性悪い?そんなの都市伝説です / vuefes2025-link-and-motivation
lmi
1
3k
インフラとアプリの境界を越える組織のつくり方 / Development Organizations in the AI Era
lmi
1
400
リンモチとRails / Link-and-Motivation-and-Rails
lmi
0
470
大きな目標を得た Kaigi on Rails 2025 / KoR2025-after-session-link-and-motivation
lmi
0
30
Four Keysが改善しても、生産性が上がらない不都合な真実 / pek2025-link-and-motivation
lmi
3
990
EMの仕事=余白のデザイン! / EM-Oasis-9-LMI
lmi
1
330
Other Decks in Technology
See All in Technology
AIエージェントによる業務効率化への飽くなき挑戦-AWS上の実開発事例から学んだ効果、現実そしてギャップ-
nasuvitz
5
1.5k
GPUをつかってベクトル検索を扱う手法のお話し~NVIDIA cuVSとCAGRA~
fshuhe
0
280
プロファイルとAIエージェントによる効率的なデバッグ / Effective debugging with profiler and AI assistant
ymotongpoo
1
590
Raycast AI APIを使ってちょっと便利なAI拡張機能を作ってみた
kawamataryo
0
210
어떤 개발자가 되고 싶은가?
arawn
1
240
可観測性は開発環境から、開発環境にもオブザーバビリティ導入のススメ
layerx
PRO
4
2.2k
Azure Well-Architected Framework入門
tomokusaba
1
150
[re:Inent2025事前勉強会(有志で開催)] re:Inventで見つけた人生をちょっと変えるコツ
sh_fk2
1
1k
AWSが好きすぎて、41歳でエンジニアになり、AAIを経由してAWSパートナー企業に入った話
yama3133
2
200
SRE × マネジメントレイヤーが挑戦した組織・会社のオブザーバビリティ改革 ― ビジネス価値と信頼性を両立するリアルな挑戦
coconala_engineer
0
310
AIがコードを書いてくれるなら、新米エンジニアは何をする? / komekaigi2025
nkzn
20
12k
Amazon Athena で JSON・Parquet・Iceberg のデータを検索し、性能を比較してみた
shigeruoda
1
250
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
331
21k
Code Review Best Practice
trishagee
72
19k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
140
34k
The Cost Of JavaScript in 2023
addyosmani
55
9.1k
Why Our Code Smells
bkeepers
PRO
340
57k
How to train your dragon (web standard)
notwaldorf
97
6.3k
YesSQL, Process and Tooling at Scale
rocio
173
15k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Building Applications with DynamoDB
mza
96
6.7k
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化
今日みたいな根本的なアーキテクチャ変更も 若手がガンガン実施してます! チャレンジしたい人大募集! ※興味がある方はぜひご連絡ください! ↓ ご清聴いただき、ありがとうございました!