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
Cloudflare Workersで構築する非同期ジョブシステム
Search
AijiUejima
June 12, 2024
Technology
6
2k
Cloudflare Workersで構築する非同期ジョブシステム
「Cloudflare Workers活用事例 業務利用の決め手とその効果に迫るLunch LT」
https://findy.connpass.com/event/318382/
での発表資料です。
AijiUejima
June 12, 2024
Tweet
Share
More Decks by AijiUejima
See All by AijiUejima
エッジはフロントエンドなのか? バックエンドなのか? について考えてみる
aiji42
7
5.2k
VRTツールのダークホース Lost Pixelを紹介したい
aiji42
5
2.7k
オリジンサーバに手を付けないパーフォマンス改善
aiji42
5
1.5k
Cloudflare Fonts試してみた🔤
aiji42
2
740
Hyperdrive試してみた🛸
aiji42
3
1.3k
Workers Browser Rendering API について
aiji42
0
500
VercelとNext.jsの機能を最大限に活用したA/Bテスト手法
aiji42
6
1.4k
Cloudflare WorkersとKVで キャッシュを非同期に更新する | Cloudflare Meetup Nagoya
aiji42
1
870
ビギナー向け エッジランタイムのすすめ | エッジランタイムを意識した開発をはじめよう
aiji42
15
5.6k
Other Decks in Technology
See All in Technology
アジャイルな開発チームでテスト戦略の話は誰がする? / Who Talks About Test Strategy?
ak1210
1
390
AI Agent時代なのでAWSのLLMs.txtが欲しい!
watany
2
190
1行のコードから社会課題の解決へ: EMの探究、事業・技術・組織を紡ぐ実践知 / EM Conf 2025
9ma3r
8
3.3k
RayでPHPのデバッグをちょっと快適にする
muno92
PRO
0
190
【詳説】コンテンツ配信 システムの複数機能 基盤への拡張
hatena
0
210
依存パッケージの更新はコツコツが勝つコツ! / phpcon_nagoya2025
blue_goheimochi
3
200
サイト信頼性エンジニアリングとAmazon Web Services / SRE and AWS
ymotongpoo
7
1.3k
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
27
15k
Raycast Favorites × Script Command で実現するお手軽情報チェック
smasato
1
140
(機械学習システムでも) SLO から始める信頼性構築 - ゆる SRE#9 2025/02/21
daigo0927
0
260
Potential EM 制度を始めた理由、そして2年後にやめた理由 - EMConf JP 2025
hoyo
2
2.3k
OPENLOGI Company Profile
hr01
0
60k
Featured
See All Featured
Bash Introduction
62gerente
611
210k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
27
1.6k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
GraphQLとの向き合い方2022年版
quramy
44
14k
Scaling GitHub
holman
459
140k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
100
18k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
1k
Into the Great Unknown - MozCon
thekraken
35
1.6k
Transcript
2024/06/13 #Cloudflare_findy Cloudflare Workers で構築する 非同期ジョブシステム
None
非同期ジョブシステム
非同期ジョブシステム メインの処理から切り離されたジョブやタスクを管理するシステム - cronなどによって起動するバッチ処理 - DBのイベントをトリガーにするタスク - 3rdパーティーのシステムやツールから呼び出されるジョブ - …etc
Sidekiq(Ruby) や Celery(Python) などが代表的なミドルウェア
機能 - スケジューリングによる定期実行 - キューイング - リトライ処理 - ステータス管理 システムが複雑になっていくと更に高度なことが求められる
- フロー管理 - 排他制御や重複抑制
そんな非同期ジョブシステムを Cloudflare Workers を使って 構築・運用しているという話🏗
- 開発体験 - デプロイの速さ - 徐々にライブラリが対応してきている - 起動速度とスケーラビリティ - コスト
- Cloudflareにスタック・機能が揃った なぜCloudflare Workersを使うのか
非同期ジョブシステム構築 に使える機能
スケジューリング Cloudflare Workers の Cron Triggers cronの記法で設定を書くと、設定時刻・頻度でWorkersを起動できる
キューシステム キューを登録するプロデューサーWorkerと、 キューを処理するコンシューマーWorkerを構築できる Cloudflare Queues enqueue dequeue リトライ回数や待機などの設定も可能 producer consumer
ただ、この2つだけでは足りない Cloudflare Queues - キューのステータスを管理しづらく、成功したキューは揮発する - 他のキューの参照、過去のキューを確認などはできない - 排他制御や重複抑制などがし辛い -
過去の実績(失敗率や実行時間など)を分析するなどもできない - プロバイダーとコンシューマーは1対1 - ジョブの種類が多くなればなるほどコードが複雑になる - ちょっとだけ不安定 - たまにキューが消失する
なので 複雑な非同期ジョブ管理システム を構築するのは諦めていた...😂
今春、D1の一般公開と Service Bindings RPCの発表によって 大きく状況が変わった🤩 https://blog.cloudflare.com/making-full-stack-easier-d1- ga-hyperdrive-queues https://blog.cloudflare.com/javascript-native-rpc
キューをD1に保存することで、ジョブの情報の永続化を可能にする - 不安定さへの対処 - 検索可能性 - 排他処理などのジョブを跨ぐ管理・制御 - ログストア -
専用の管理画面の構築 キューのステータス管理と半永続化 D1 Cloudflare Workers 用の永続データストア (SQLite)
これまでも Service Bindigs (別ワーカーをグローバルネットワークを経由せずシステムコールで 呼び出せる) はあったのだが、fetchのインタフェースにしか対応しておらず、使い勝手があまり良くなった。 SB RPCでは、他のWorkerに展開されているモジュールコードを、同一ワーカー内にあるように コールできるようになった。 コードベースの切り出しと隠蔽
Service Bindings RPC Workerから別WorkerをRPCで呼び出し可能になる SBからSBを呼び出すことでProxyモジュールを経由してジョブを呼び出せる 一つのインターフェースで同期的に処理させたり、キューに流して非同期的に処 理させたりできる。(複雑なジョブの管理をシンプルにできる)
これらを使ってどう構築するか🏗
main job 📄Payload(type: A) メインWorkerから、分岐可能なフラグを持つペイロードを持たせてエンキューし、 ジョブWorker側で処理を呼び分ける。 ※分岐が増えていくと管理が複雑になり、またインタフェースの設計がかなり重要に なってくる 📄Payload(type: B)
Before
main proxy メインワーカーでエンキュー、ジョブワーカーでデキューをやめて、 キューの前後にエンキュー・デキュー専用のプロキシワーカーを用意。 さらに、間を Service Bindings RPC でつなぐ RPC
RPC job-A job-B proxy’ After
main proxy 一見複雑に見えるが、 間を隠蔽し、インターフェースを工夫することで、メインワーカからは シンプルにjob-A, job-Bを起動することができる(見せかけられる)。 ※実際にはキュー越しなので非同期に処理される RPC RPC job-A
job-B proxy’ Blackbox env.MyProxy.asyncExec(“job-A”, payload) env.MyProxy.asyncExec(“job-B”, payload)
main proxy RPC RPC job-A job-B proxy’ D1 更にD1を挟んで、Queueデータを永続化する。 他のキューを検索可能になるので重複抑制ができるようになったり、
ログの分析や状態管理、管理画面を作って制御したりなどができる。
便利そうではあるが どう考えても構築が面倒🤮
npmパッケージ あります🚀
🎇 Kiribi
https://kiribi.pages.dev/
# kiribiをインストール $ npm install kiribi # d1とqueueを構築 $ npx
wrangler d1 crete kiribi-db $ npx wrangler d1 migrations apply kiribi-db –local # or --remote $ npx wrangler queue create kiribi-queue 数コマンド + wrangler.toml の編集で前述したような仕組みを構築可能 詳しくはドキュメントページ https://kiribi.pages.dev/ を参照
env.KIRIBI.enqueue(“MyJob”, payload, option) ジョブの呼び出し(エンキュー) import { KiribiPerformer } from “kiribi/performer”
export class MyJob extends KiribiPerformer { async perform(payload) { // 何らかの処理 } } ジョブの定義
Demo
None
None
None
None
None
Demo
パッケージ化されてるとはいえ 複数のWorkersを管理するのは大変では? 🫠 main proxy RPC RPC job-A job-B proxy’
D1
実際は1つのWorkersで構築可能 - Service Bindings RPCは自Workerを呼び出すこともできる - Queueに対して1WorkerでProvider/Consumer両方をさせることができる main RPC RPC
job-A job-B proxy’ proxy
実際は1つのWorkersで構築可能 main RPC RPC job-A job-B proxy’ proxy さらにKiribiで隠蔽すれば意外とシンプル✨ env.KIRIBI.enqueue(“MyJob”,
payload, option) - Service Bindings RPCは自Workerを呼び出すこともできる - Queueに対して1WorkerでProvider/Consumer両方をさせることができる
まとめ - Cloudflare Queues, SB RPC, D1などを組み合わせれば ある程度の規模に耐えうる非同期ジョブシステムが構築できる - 今回紹介した仕組みの部分はnpmのパッケージがある
- ドキュメント: https://kiribi.pages.dev/ - Github: https://github.com/aiji42/kiribi - PR/Star ぜひお願いします🙏 - Cloudflare Workers(+周辺ツール) x アイデアで 面白いものや仕組みを構築可能
ご清聴ありがとうございました