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.8k
ジョブキューシステム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
21k
仮想関数テーブルと型クラスを見比べる
tarao
1
2k
計算ファースト vs. 型ファースト / Computation First vs. Type First
tarao
4
22k
10年でどう変わった? はてなブックマークでのPerlの使い方
tarao
10
9.5k
Percolatorを用いたカテゴリ分類
tarao
0
3.6k
Other Decks in Technology
See All in Technology
生成AIで「お客様の声」を ストーリーに変える 新潮流「Generative ETL」
ishikawa_satoru
1
320
Goに育てられ開発者向けセキュリティ事業を立ち上げた僕が今向き合う、AI × セキュリティの最前線 / Go Conference 2025
flatt_security
0
350
GopherCon Tour 概略
logica0419
2
190
生成AIを活用したZennの取り組み事例
ryosukeigarashi
0
200
英語は話せません!それでも海外チームと信頼関係を作るため、対話を重ねた2ヶ月間のまなび
niioka_97
0
120
SoccerNet GSRの紹介と技術応用:選手視点映像を提供するサッカー作戦盤ツール
mixi_engineers
PRO
1
180
SOC2取得の全体像
shonansurvivors
1
400
コンテキストエンジニアリングとは? 考え方と応用方法
findy_eventslides
4
900
動画データのポテンシャルを引き出す! Databricks と AI活用への奮闘記(現在進行形)
databricksjapan
0
150
Pure Goで体験するWasmの未来
askua
1
180
ユニットテストに対する考え方の変遷 / Everyone should watch his live coding
mdstoy
0
130
SREとソフトウェア開発者の合同チームはどのようにS3のコストを削減したか?
muziyoshiz
1
100
Featured
See All Featured
Scaling GitHub
holman
463
140k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
GitHub's CSS Performance
jonrohan
1032
460k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Designing for Performance
lara
610
69k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
BBQ
matthewcrist
89
9.8k
The Art of Programming - Codeland 2020
erikaheidi
56
14k
Agile that works and the tools we love
rasmusluckow
331
21k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
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 おわり