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
sidekiq_enterprise20190828
Search
Shinsuke Kawaida
August 28, 2019
Technology
1
3.9k
sidekiq_enterprise20190828
Shinsuke Kawaida
August 28, 2019
Tweet
Share
More Decks by Shinsuke Kawaida
See All by Shinsuke Kawaida
ginza rails sponsor talk
degwinthegreat
0
160
Other Decks in Technology
See All in Technology
アクセス制御にまつわる改善 / Improving access control
itkq
0
520
Compose Compiler Metricsを使った実践的なコードレビュー
tomorrowkey
1
220
レガシーをぶっ壊せ。AEONで始めるDevRelの話 / Qiita Night 2024-2-22
aeonpeople
3
1.3k
Postman v10リリース後を振り返る / Looking back at Postman v10 after release
yokawasa
1
160
Databricks における 『MLOps』
databricksjapan
2
170
ここが嬉しいABAC ここが辛いよABAC #再解説+補足編
masahirokawahara
1
270
Janus
bkuhlmann
1
490
ServiceNow Knowledge Learning Rise up
manarobot
0
200
ServiceNow Knowledge 24の歩き方 EYストラテジー・アンド・コンサルティング
manarobot
0
190
オーナーシップを持つ領域を明確にする
konifar
13
3.1k
現代CSSフレームワークの内部実装とその仕組み
poteboy
8
3.6k
長期間TiDBを使ってきた話 @ 私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT / Experiences with TiDB Over Time
chibiegg
2
880
Featured
See All Featured
Web Components: a chance to create the future
zenorocha
305
41k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
9
8.3k
For a Future-Friendly Web
brad_frost
172
9k
Fireside Chat
paigeccino
21
2.6k
Atom: Resistance is Futile
akmur
259
25k
The Pragmatic Product Professional
lauravandoore
25
5.8k
Automating Front-end Workflow
addyosmani
1356
200k
The Cult of Friendly URLs
andyhume
74
5.7k
Optimizing for Happiness
mojombo
370
69k
Large-scale JavaScript Application Architecture
addyosmani
504
110k
Ruby is Unlike a Banana
tanoku
96
10k
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
Transcript
4JEFLJR &OUFSQSJTFΛ ಋೖͯ͠ϝʔϧ৴+0#Λ վળͯ͠Έͨ !UBNBNVTIJ@ 1
2 ⾃⼰紹介
3 ⾃⼰紹介 ・川井⽥ 新介(かわいだ しんすけ) ・3年前まで⿅児島で農業したりしてた⼈ ・趣味はサウナ ・2019年1⽉メドピア⼊社 ・1⽉からRailsエンジニア
4 今⽇のお話
5 の前に
6 Rails ばっちこいな⼈
7 Sidekiq さわったことある⼈
8 Sidekiqとは queue管理にRedisを使い マルチスレッドでメモリに優しい Rubyの⾮同期処理 フレームワーク
9 有償版Pro・Enterprise
10 Enterprise 導⼊の理由
11 信頼性の向上 ・reliable_push ・super_fetch ・expiring_jobs
12 Reliable Push(pro) ( ( )
13 エンキュー! 500 あいつどこ⾏った? 普通のpush
14 エンキュー! 500 Reliable Push 隠し持ってたやつ エンキュー! オッケー!
15 Expiring Jobs(pro) 期 限 切 れ
16 URL: https://github.com/mperham/sidekiq/wiki/Pro-Expiring-Jobs
17 Super Fetch(pro)
18 普通のfetch フェッチ ① ② ③ ④ ② ③ ④
19 Super Fetch フェッチ ① ② ③ ④ ② ③
④ ① バックアップ
20 今⽇のお話
21 Sidekiq Enterpriseを導⼊して、 安⼼と信頼の定期実⾏ メール配信処理を実現した話
22 を
23 Sidekiq Enterpriseの 機能を紹介しながら していきます
24 なので
25 こんな気持ち ・Sidekiqの有償版きになるわぁ ・メール配信の定期実⾏って多重配信とかどう管 理してるのかしら ・普段Ruby触らないけど他⾔語の⾮同期処理でも 活かせるところあるかも で聞いていただけると嬉しいです。
26 本題
27 こんなJOBが ありました
28 5分おきに実⾏ 1.配信待ちのメルマガを取得 2.送信中に更新 3.配信対象ユーザー分メール送信 4.送信結果を保存 5.送信完了に更新
29 デプロイしたら死ぬ
30 デプロイ時 ・キューのfetchを停⽌ ・8秒待ってプロセス終了 ・終わらなかったJOBは Redisに戻される
31 再実⾏はされそう
32 5分おきに実⾏ 1.配信待ちのメルマガを取得 2.送信中に更新 3.配信対象ユーザー分メール送信 4.送信結果を保存 5.送信完了に更新
33 5分おきに実⾏ 1.配信待ちと送信中のメルマガを取得 2.送信中に更新!ココ
34 5分おきに実⾏ 1.配信待ちと送信中のメルマガを取得 2.送信中に更新!ココ ステータスは送信中のままなので、 再実⾏時配信対象として取得されない
35 送信中のメルマガも ひろうようにする
36 5分おきに実⾏ 1.配信待ちと送信中!のメルマガを取得 2.送信中に更新 3.配信対象ユーザー分メール送信 4.送信結果を保存 5.送信完了に更新
37 多重配信
38 5分おきに実⾏ 1.配信待ちと送信中のメルマガを取得 !ココ 送信JOB① 送信JOB② メールA DB 送信中にするぜ 送信中のも送信するぜ
39 ①ロックする 多重配信対策
40 5分おきに実⾏ 1.配信待ちと送信中のメルマガを取得してロック 2.送信中に更新 3.配信対象ユーザー分メール送信 4.送信結果を保存 5.送信完了に更新
41 5分おきに実⾏ 1.配信待ちと送信中のメルマガを取得 送信JOB① 送信JOB② メールA DB ロックして 送信中にするぜ ロックできない!!!
42 そもそも実⾏時間 が⻑すぎる
43 ②実⾏時間を短くする ためJOBを分ける 多重配信対策
44 インポートJOB メール配信JOB
45 5分おきに実⾏ 1.配信待ちと送信中のメルマガを取得してロック 2.送信中に更新 3.配信対象ユーザーをインポート 4.送信JOBをエンキュー インポートJOB
46 1.メール送信 2.送信結果を保存 メール送信JOB
47 インポートJOB メール配信JOB すべてのメール配信JOBが終了したら ステータスを更新したい
48 Batches(Pro)
49
50 インポートJOB エンキューするJOB(Batches) メール配信JOB !
51 インポートJOB エンキューするJOB(Batches) メール配信JOB リトライとかで 多重実⾏されないようにしたい
52 Unique Jobs(Ent)
53 指定した時間内に クラス名、引数、キューが 同じJOBを実⾏しないようにする
54 なんとかなった
55 学び ・設計から並列性、冪等性を 考慮した設計にしないとツライ
56 Wiki のBest Practicesにも 書いてある url: https://github.com/mperham/sidekiq/wiki/Best-Practices
57 でも
58 元々の問題
59 デプロイしたら死ぬ
60 Rolling Restart(Ent)
61 URL: https://github.com/mperham/sidekiq/wiki/Ent-Rolling-Restarts
62 ※メモリに注意 ※新旧のコードに互換性が必要 新プロセス⽴ち上げて 旧プロセスのworkerの終了を 待ってから、旧プロセスを終了する
63 学び ・設計から並列性、冪等性を 考慮した設計にしないとツライ ・Enterpriseだとなんとか してくれる機能がある
64 ご清聴ありがとうございました!