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
ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス
Search
INA Lintaro
March 19, 2023
Technology
1
5.4k
ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス
2023-03-19 YAPC::Kyoto 2023
https://yapcjapan.org/2023kyoto/timetable.html#talk-117
INA Lintaro
March 19, 2023
Tweet
Share
More Decks by INA Lintaro
See All by INA Lintaro
record4s --- Extensible Records for Scala 3, and Domain Modeling with Structural Types
tarao
2
18k
仮想関数テーブルと型クラスを見比べる
tarao
1
1.7k
計算ファースト vs. 型ファースト / Computation First vs. Type First
tarao
4
22k
10年でどう変わった? はてなブックマークでのPerlの使い方
tarao
10
9.3k
Percolatorを用いたカテゴリ分類
tarao
0
3.3k
Other Decks in Technology
See All in Technology
C++26アップデート 2025-03
faithandbrave
0
440
はじめてのSDET / My first challenge as a SDET
bun913
1
260
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
0
290
Рекомендации с нуля: как мы в Lamoda превратили главную страницу в ключевую точку входа для персонализированного шоппинга. Данил Комаров, Data Scientist, Lamoda Tech
lamodatech
0
750
クラウド開発環境Cloud Workstationsの紹介
yunosukey
0
180
YOLOv10~v12
tenten0727
4
960
アセスメントで紐解く、10Xのデータマネジメントの軌跡
10xinc
1
440
3月のAWSアップデートを5分間でざっくりと!
kubomasataka
0
120
読んで学ぶ Amplify Gen2 / Amplify と CDK の関係を紐解く #jawsug_tokyo
tacck
PRO
1
160
watsonx.data上のベクトル・データベース Milvusを見てみよう/20250418-milvus-dojo
mayumihirano
0
120
Road to Go Gem #rubykaigi
sue445
0
740
意思決定を支える検索体験を目指してやってきたこと
hinatades
PRO
0
170
Featured
See All Featured
Agile that works and the tools we love
rasmusluckow
328
21k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Code Reviewing Like a Champion
maltzj
522
40k
Docker and Python
trallard
44
3.3k
GraphQLとの向き合い方2022年版
quramy
46
14k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.3k
Code Review Best Practice
trishagee
67
18k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.3k
Optimising Largest Contentful Paint
csswizardry
36
3.2k
Thoughts on Productivity
jonyablonski
69
4.6k
Rails Girls Zürich Keynote
gr2m
94
13k
Transcript
ジョブキューシステム Fireworqのアーキテクチャ設計と 運用時のベストプラクティス INA Lintaro id:tarao @oarat 2023-03-19 YAPC::Kyoto 2023
自己紹介 2 id:tarao @oarat @tarao エンジニア (バックエンド)・エンジニアリングマネージャ • 2013~ はてなに新卒入社
• 2015~ はてなブックマークのシステム刷新 (テックリード) • 2021~ エンジニアリングマネージャ 今回に関連する話 • 10年でどう変わった? はてなブックマークでのPerlの 使い方 YAPC::Nagoya::Tiny 2019, 名古屋市中村区, November 2019 (ゲストスピーカー)
3 Fireworq is 何?
Fireworq is 何? • ジョブキュー (メッセージキュー) • Go製 • ストレージはMySQL
• at-least-once 4
Fireworq is 何? • HTTPでジョブを投げる • 指定ワーカーにPOSTしてくれる • 投入元 =
ワーカー なら つまり非同期処理 5
Fireworq is 何? • HTTPでジョブを投げる • 指定ワーカーにPOSTしてくれる • 投入元 ≠
ワーカー なら つまりメッセージング 6
7 以前の ジョブキュー ソリューション
TheSchwartz + WorkerManager 困りどころ • Perlでしか使えない • 重いジョブによるリソース占有 • ワーカー並列数を増やすと詰まる
• ワーカーをメンテしづらい ◦ エントリーポイントが特殊 ◦ 環境セットアップが特殊 8
TheSchwartz + WorkerManager 困りどころ • Perlでしか使えない • 重いジョブによるリソース占有 • ワーカー並列数を増やすと詰まる
• ワーカーをメンテしづらい ◦ エントリーポイントが特殊 ◦ 環境セットアップが特殊 9
TheSchwartz + WorkerManager • 複数のワーカーが一斉にジョブを掴む • ワーカーを増やしていくと詰まる 10
11 Fireworqの設計
設計思想 12 Portability 言語非依存 (インタフェースはHTTP) Reliability RDBMS (MySQL)で永続化 Availability プライマリ/バックアップのノード構成
Scalability 単一ディスパッチャ+多数のワーカー Flexibility 複数のキューを動的に設定可能 APIや管理Webコンソールで操作可能
アーキテクチャ • 単一ディスパッチャでポーリング 13
しくみ - MySQLエンジン • 1テーブル = 1キュー • INSERTとUPDATEを 競合させない
• TheSchwartzや MogileFSもだいたい同じ 14 id next_try status 6 12:05 claimed 5 11:05 claimed 4 10:32 claimed 3 10:27 claimed 2 09:41 grabbed 1 09:07 grabbed 現在時刻 新規ジョブ INSERT位置 次に掴む UPDATE claimed ↓ grabbed
しくみ - ノード昇格 • プライマリ ◦ GET_LOCK成功 • バックアップ ◦
GET_LOCK待ち ◦ INSERTは可 ◦ プライマリが落ちると 直ちに昇格 15
16 TheSchwartzからの移行
元のワーカーの想定 package My::Worker use parent qw(TheSchwartz::Worker); sub work { my
($class, $job) = @_; ... $job->completed; } 17
TheSchwartz::Fireworq ワーカーをweb app化: app.psgiに以下を追加 enable ‘TheSchwartz::Fireworq’, path => ‘/work’; 18
TheSchwartz::Fireworq ジョブの投入側: クライアントが変わるだけ my $client = TheSchwartz::Fireworq->new( server => 'http://localhost:8080',
# Fireworq worker => 'http://localhost:5000/work', # ワーカー ); $client->insert('My::Worker', { @_ }); 19
20 Fireworqの 運用プラクティス
複数キューの使い分け • 時間のかかるジョブはキューを別にする • ジョブカテゴリは細かく分けておく ◦ カテゴリごとに配送先キューを設定するため 21
スロットリング • 前提: ジョブは羃等にしておく • TheSchwartzではuniqkeyで可能だった ◦ 本当の意味のスロットリングではない • 自前でやる必要がある
◦ キーごとに最終実行予定時刻を記録すれば可能 ◦ 投入ジョブの実行予定より後の予定があればスキップ ◦ なければrun_afterでインターバルを空けて投入 22
失敗時の再送 • 自動で再送される ◦ 指定したmax_retriesの回数以内の場合 ◦ ジョブを掴んでいる途中でFireworqが落ちた場合 • それでも失敗したもの(permanent failure)
◦ GET /queue/<name>/failedで一覧が取れる ◦ POST /job/<category>で必要に応じて再投入する 23
Mackerelで監視 • mackerel-plugin-fireworq ◦ キューやノードの状態のメトリックを取る • mackerel-check-fireworq ◦ ジョブの失敗(permanent failure)をアラート
24
25 まとめ
まとめ • Fireworqはジョブキュー ◦ 言語非依存でスケールする ◦ ワーカーもweb appのためわかりやすい • TheSchwartzからの移行は簡単
• 本番運用に必要なものは揃っている • コントリビュータ・メンテナ募集中 26
27 質問?
28 FAQ
Q. HTTP以外はサポートしないの? A. • gRPCとか? HTTP/2? ◦ サポートしてもよいかも ◦ コントリビュータ歓迎
• 必要なほどパフォーマンスがシビアな状況? ◦ 今のところ聞いたことがない ◦ 試してみてHTTPでは無理だったらおしえてください 29
Q. MySQL以外のストレージではダメ? A. • 内部コード的には変えられる ◦ インタフェースさえ満たせばなんでもよい設計 • 当初はRedisエンジンも実装予定だった ◦
単にめんどうでやってないだけ ◦ コントリビュータ歓迎 30
31 おわり