ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス

2023-03-19 YAPC::Kyoto 2023
https://yapcjapan.org/2023kyoto/timetable.html#talk-117

1. ジョブキューシステム Fireworqのアーキテクチャ設計と 運用時のベストプラクティス INA Lintaro id:tarao @oarat 2023-03-19 YAPC::Kyoto 2023
2. 自己紹介 2 id:tarao @oarat @tarao エンジニア (バックエンド)・エンジニアリングマネージャ • 2013~ はてなに新卒入社 • 2015~ はてなブックマークのシステム刷新 (テックリード) • 2021~ エンジニアリングマネージャ 今回に関連する話 • 10年でどう変わった? はてなブックマークでのPerlの 使い方 YAPC::Nagoya::Tiny 2019, 名古屋市中村区, November 2019 (ゲストスピーカー)
3. 3 Fireworq is 何?
4. Fireworq is 何? • ジョブキュー (メッセージキュー) • Go製 • ストレージはMySQL • at-least-once 4
5. Fireworq is 何? • HTTPでジョブを投げる • 指定ワーカーにPOSTしてくれる • 投入元 = ワーカー なら つまり非同期処理 5
6. Fireworq is 何? • HTTPでジョブを投げる • 指定ワーカーにPOSTしてくれる • 投入元 ≠ ワーカー なら つまりメッセージング 6
7. 7 以前の ジョブキュー ソリューション
8. TheSchwartz + WorkerManager 困りどころ • Perlでしか使えない • 重いジョブによるリソース占有 • ワーカー並列数を増やすと詰まる • ワーカーをメンテしづらい ◦ エントリーポイントが特殊 ◦ 環境セットアップが特殊 8
9. TheSchwartz + WorkerManager 困りどころ • Perlでしか使えない • 重いジョブによるリソース占有 • ワーカー並列数を増やすと詰まる • ワーカーをメンテしづらい ◦ エントリーポイントが特殊 ◦ 環境セットアップが特殊 9
10. TheSchwartz + WorkerManager • 複数のワーカーが一斉にジョブを掴む • ワーカーを増やしていくと詰まる 10
11. 11 Fireworqの設計
12. 設計思想 12 Portability 言語非依存 (インタフェースはHTTP) Reliability RDBMS (MySQL)で永続化 Availability プライマリ/バックアップのノード構成 Scalability 単一ディスパッチャ+多数のワーカー Flexibility 複数のキューを動的に設定可能 APIや管理Webコンソールで操作可能
13. アーキテクチャ • 単一ディスパッチャでポーリング 13
14. しくみ - 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
15. しくみ - ノード昇格 • プライマリ ◦ GET_LOCK成功 • バックアップ ◦ GET_LOCK待ち ◦ INSERTは可 ◦ プライマリが落ちると 直ちに昇格 15
16. 16 TheSchwartzからの移行
17. 元のワーカーの想定 package My::Worker use parent qw(TheSchwartz::Worker); sub work { my ($class, $job) = @_; ... $job->completed; } 17
18. TheSchwartz::Fireworq ワーカーをweb app化: app.psgiに以下を追加 enable ‘TheSchwartz::Fireworq’, path => ‘/work’; 18
19. TheSchwartz::Fireworq ジョブの投入側: クライアントが変わるだけ my $client = TheSchwartz::Fireworq->new( server => 'http://localhost:8080', # Fireworq worker => 'http://localhost:5000/work', # ワーカー ); $client->insert('My::Worker', { @_ }); 19
20. 20 Fireworqの 運用プラクティス
21. 複数キューの使い分け • 時間のかかるジョブはキューを別にする • ジョブカテゴリは細かく分けておく ◦ カテゴリごとに配送先キューを設定するため 21
22. スロットリング • 前提: ジョブは羃等にしておく • TheSchwartzではuniqkeyで可能だった ◦ 本当の意味のスロットリングではない • 自前でやる必要がある ◦ キーごとに最終実行予定時刻を記録すれば可能 ◦ 投入ジョブの実行予定より後の予定があればスキップ ◦ なければrun_afterでインターバルを空けて投入 22
23. 失敗時の再送 • 自動で再送される ◦ 指定したmax_retriesの回数以内の場合 ◦ ジョブを掴んでいる途中でFireworqが落ちた場合 • それでも失敗したもの(permanent failure) ◦ GET /queue/<name>/failedで一覧が取れる ◦ POST /job/<category>で必要に応じて再投入する 23
24. Mackerelで監視 • mackerel-plugin-fireworq ◦ キューやノードの状態のメトリックを取る • mackerel-check-fireworq ◦ ジョブの失敗(permanent failure)をアラート 24
25. 25 まとめ
26. まとめ • Fireworqはジョブキュー ◦ 言語非依存でスケールする ◦ ワーカーもweb appのためわかりやすい • TheSchwartzからの移行は簡単 • 本番運用に必要なものは揃っている • コントリビュータ・メンテナ募集中 26
27. 27 質問?
28. 28 FAQ
29. Q. HTTP以外はサポートしないの? A. • gRPCとか? HTTP/2? ◦ サポートしてもよいかも ◦ コントリビュータ歓迎 • 必要なほどパフォーマンスがシビアな状況? ◦ 今のところ聞いたことがない ◦ 試してみてHTTPでは無理だったらおしえてください 29
30. Q. MySQL以外のストレージではダメ? A. • 内部コード的には変えられる ◦ インタフェースさえ満たせばなんでもよい設計 • 当初はRedisエンジンも実装予定だった ◦ 単にめんどうでやってないだけ ◦ コントリビュータ歓迎 30
31. 31 おわり