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
@nestjs/bull の活用について
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
odanado
PRO
September 30, 2022
Programming
0
1.5k
@nestjs/bull の活用について
odanado
PRO
September 30, 2022
Tweet
Share
More Decks by odanado
See All by odanado
Vitest Browser Mode への期待 / Vitest Browser Mode
odanado
PRO
3
5.3k
クラウド KMS の活用 / TOKYO BLOCKCHAIN TECH MEETUP 2022
odanado
PRO
0
1.3k
Vue.observable で状態管理 / vue-observable-state-management
odanado
PRO
4
2.1k
nuxtjs-axios-error-handling
odanado
PRO
0
390
ブロックチェーンアプリのトランザクションに対するデータ分析 / PyCon-JP-2019
odanado
PRO
0
450
スマートコントラクトに対する既知の攻撃とその対策 / bc.tokyo-21
odanado
PRO
0
270
最近のweb3.js事情 / bc.tokyo-19
odanado
PRO
2
550
YAPC::Tokyo 2019に スタッフ参加してみて / kichijojipm-18
odanado
PRO
1
2.3k
JavaScript + Dockerの知見 / knowledge-of-docker-in-javascript
odanado
PRO
9
55k
Other Decks in Programming
See All in Programming
S3ストレージクラスの「見える」「ある」「使える」は全部違う ─ 体験から見た、仕様の深淵を覗く
ya_ma23
0
820
Ruby and LLM Ecosystem 2nd
koic
1
1.2k
CSC307 Lecture 15
javiergs
PRO
0
260
存在論的プログラミング: 時間と存在を記述する
koriym
3
260
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
690
20260315 AWSなんもわからん🥲
chiilog
2
170
20260228_JAWS_Beginner_Kansai
takuyay0ne
5
600
[PHPerKaigi 2026]PHPerKaigi2025の企画CodeGolfが最高すぎて社内で内製して半年運営して得た内製と運営の知見
ikezoemakoto
0
230
CSC307 Lecture 14
javiergs
PRO
0
480
モダンOBSプラグイン開発
umireon
0
170
「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜
kentaroutakeda
3
1.3k
守る「だけ」の優しいEMを抜けて、 事業とチームを両方見る視点を身につけた話
maroon8021
3
1.1k
Featured
See All Featured
エンジニアに許された特別な時間の終わり
watany
106
240k
The Anti-SEO Checklist Checklist. Pubcon Cyber Week
ryanjones
0
95
Testing 201, or: Great Expectations
jmmastey
46
8.1k
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.2k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
1.7k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
150
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
230
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
1
320
The Curious Case for Waylosing
cassininazir
0
270
AI Search: Implications for SEO and How to Move Forward - #ShenzhenSEOConference
aleyda
1
1.2k
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
3.7k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
480
Transcript
@nestjs/bull の活用について NestJS meetup Online #4 @odan3240
目次 • 自己紹介 • 今日話すこと • @nestjs/bull とは • API
と Worker のサーバを分ける • ログに共通の ID を仕込む • bull の各種イベントをログに出力する 2
今日話すこと • バックエンドの非同期処理に @nestjs/bull を使用 • サービス運用で便利になる テクニックをいくつかご紹介 • サンプルコード
◦ odan-sandbox/nestjs-bull-patterns-sandbox • 前提知識 ◦ AWS Fargate にバックエンドのサーバがある ◦ ログの集計は CloudWatch 3
@nestjs/bull とは 4
@nestjs/bull とは • https://github.com/OptimalBits/bull は Redis バックエンドの非同期キューのライブラリ 5
@nestjs/bull とは • @nestjs/bull は bull の NestJS 向けのラッパー •
bull の Queue の仕組みを NestJS way な方法で扱える 6
@nestjs/bull とは • @nestjs/bull は bull の NestJS 向けのラッパー •
bull の Queue の仕組みを NestJS way な方法で扱える 7
API と Worker のサーバを分ける 8
API と Worker のサーバを分ける • API と Worker のサーバは求められる インフラの要件が異なる
◦ 水平スケールの条件など • 2つのサーバは独立で動くように プロセスを分けるのが良さそう • 「nestjs bull separate process」でググると Stack Overflow でヒットする 9
API と Worker のサーバを分ける 10 WebhookProcessor の登録の有無
API と Worker のサーバを分ける • registerQueueAsync ◦ queue.add を使うモジュールに登録する ◦
API サーバで呼び出されるモジュールなど • registerProcessorAsync ◦ 登録された job を実行するための関数 ◦ worker 用のプロセスを起動するモジュールに登録する 11
API と Worker のサーバを分ける 12 worker の実行
API と Worker のサーバを分ける • app.init() を実行すると アプリケーションが開始 • queue
に job が追加されると processor が実行されるようになる • ファイルは worker.ts で API サーバのエントリーファイル (main.ts) とは別 ◦ 別のプロセスで実行 ◦ コンテナを分けることも可能 13
ログに共通の ID を仕込む 14
ログに共通の ID を仕込む • pino-http は express 向けのロガーライブラリ • jsonl
ベースのログを出力する 15
ログに共通の ID を仕込む • nestjs-pino は pino-http の NestJS 向けラッパー
16
ログに共通の ID を仕込む • リクエストごとに共通の ID が割り振られていると 障害発生時の原因調査が楽 ◦ Observability
の向上 • ID で filter するとリクエストを受け付けてから レスポンスを返すまでの流れを把握できる ◦ 外部 API の呼び出しのログ ◦ クエリ発行のログ 17
ログに共通の ID を仕込む • worker でも pino-http みたいなことがしたい •
worker の処理が開始してから終了するまでに どういうログが出力されたか追跡可能だと良い 18
ログに共通の ID を仕込む 19 AsyncLocalStorage を使う
ログに共通の ID を仕込む 20 BaseProcessor を継承するだけ
bull の各種イベントをログに出力する 21
bull の各種イベントをログに出力する • bull は queue に入った job の状態に 応じて様々なイベントを
emit する 22
bull の各種イベントをログに出力する • OnQueueError ◦ job がエラーになったとき • OnQueueActive ◦
job がアクティブになったとき • OnQueueCompleted ◦ job が完了したとき • OnQueueFailed ◦ job が失敗したとき • これらのイベントのタイミングでログを 出力しておくと障害発生時に調査が楽になる 23
bull の各種イベントをログに出力する 24 イベントに対してログを出す
まとめ 25
まとめ • 運用を楽にする @nestjs/bull の使い方を紹介 ◦ API と Worker のサーバを分ける
◦ ログに共通の ID を仕込む ◦ bull の各種イベントをログに出力する • いわゆる Observability を改善すると 障害発生時の原因調査が楽 26