
2025.02.26
10年前とここまで違う 落とし穴だらけの“ERP to ERP”基幹システム刷新が抱えるリスクと実情
Laravel Queueの運用管理(全1記事)
リンクをコピー
記事をブックマーク
五十嵐正人氏:オープンロジの五十嵐です。よろしくお願いします。Vueだったりフロントの話が多いなか、サーバサイドの話をします。
「Laravel Queueの運用管理」といって、先月オープンロジでLaravelの勉強会させていただいた時も少し話したんですが、その続き的な内容の話をします。
まずは僕の紹介ということで、株式会社オープンロジという会社でCTOをやっています。基本的に0→1が好きで、前職でも別のスタートアップのCTOをやってたりしています。今は会社としては4、5年になって、0→1から1→10みたいなところになろうとしているフェーズの会社となります。
オープンロジはどういう会社かを簡単に紹介させてもらうと、誰でも簡単に使える物流アウトソーシングサービスです。
物流アウトソーシングサービスってなにかというと、主なお客様としてはECを営んでいる方なのですが、ECをやるとなると商品の在庫管理し受注があれば梱包し発送する必要があるのですが、そのような面倒な物流業務を代行するサービスになります。
従来は自分で倉庫会社さんを見つけ直接契約する必要あったのですが、それをオンライン上から誰でも簡単に登録できるようにし、我々がシステムを通して倉庫と荷主をマッチングします。最近はメルカリのように誰でも簡単に売れる時代になっています。、そのような方でもカジュアルに物流の委託ができるクラウドサービスを提供しているのが我々の企業になります。
技術スタックに関しては、どういうものも使っているかを簡単に紹介してもよかったんですが、そこらへんは去年のAdvent Calendarに書いてあるのでよかったら見てみてください。
基本的にはサーバサイドはLaravel で、フロントエンドはReactがメインです。新しいプロダクトではVueを使ったりしています。
本題に入りまして、まずはジョブの基本を話からさせていただきたいと思います。Laravelを使われている方はけっこういらっしゃると思いますが、我々はかなりジョブに振り切った使いかたをしています。
キーワードとして聞いたことがある方も多いかとは思うんですけど、「コマンドクエリの責務分離(CQRS)」というものがあります。このルールを取り入れることでいろいろ良いことがあります。
これも知ってる人からするとすごく当たり前の話かもしれませんが、Webのアプリケーションというのは、だいたい処理をするにあたってやることは、情報を読み取るか書き込むかのどちらかになります。
たとえば一番シンプルな構成でいうと、読み込むというのは、Webサーバ経由でDBに対してReadして、その結果をクライアントに返す。また、なにかしら書き込みがある場合は、POSTなどのメソッドをとおしてWebサーバ経由でDBに書き込んで、成功したら結果をクライアントに返します。この読み込みと書き込みを同じWebサーバ上でやらないようにしましょう、みたいなルールのことですね。
それを実現にするにはどうすればいいかというと、ジョブを活用しましょうということです。まずはCommandというかたちでWebサーバに投げます。Webサーバがやることは、それをQueueに対してEnqueueすることだけです。そしてmutableな処理をするJobサーバでそのQueueをDequeueしてWriteな処理を行います。
その結果をどうやってクライアントまで返すかというと、LaravelだとPusherやRedisなど、いろいろ選べる中で我々は今Pusherを使っているのですが、Pusher経由でクライアントに返すことで、ReadのサーバとWriteのサーバが別々でも、ちゃんと非同期にフィードバックを返すことができます。
こう書くとすごく難しそうに見えるかもしれませんが、Laravelは最初から、DDDやCQRSをよく意識した設計になっているので、すごく実装しやすいんです。
具体的なコードでいうと、例えば updateItemのようなController上のメソッドがあった場合、Eloquentでfindしてパラメータをセットしてsaveするような実装になってくるとは思いますが、CQRSだと単純にupdateItemというジョブを作って、ディスパッチしてあげるだけになります。
このジョブ、updateItemという中身の実装のハンドラに関しては、Controller上で実装していたものと同じような実装が入っているだけなんですが、こういったかたちであらゆる更新処理をジョブを経由するような実装にする方針にしています。
そうすることで、そのジョブという存在がとても大事になってくるので、ジョブがどのように処理されているか、ちゃんと成功したのか失敗したのか結果を管理することで、一元的にシステムがどうなっているかという情報を見れるように工夫しています。
ここ最近出てきたライブラリでLaravel HorizonとLaravel Telescopeというのがありまして、これはうちではまだ使ってないんですが「どういうものなのかな?」と思ってちょっと調べてきたので、簡単にご紹介します。
これがLaravel Horizonで、これがLaravel Telescopeです。すごい似ているんですよね。
Laravel Telescopeは比較的最近できたので知らない方もいらっしゃると思いますが、それぞれどんなものかというか、実際使っている人っていらっしゃいますか?
(会場挙手)
Telescopeはたぶんまだ出たばかりなのであまり使われている方はいないのかもしれませんが、HorizonはRedis専用のキューのモニタリングツールです。
TelescopeというのはLaravel内の状態を把握するための開発用デバッグツールです。Laravel Debugbarというものもありますが、あれよりも、リクエストからクエリやジョブの状態、あとは通知のイベントの結果など、Laravelの中でいろいろなイベントが発生すると思うのですが、それらの状態なを一元的に見ることができるツールです。
ここを見ればわかりますが、Exceptionとかログとかクエリとか、モデル、イベントなどいろいろなパラメーターがあります。
Horizonは、そういった本番運用用のモニタリングツールであって、Telescopeは開発用のデベロッパーツールです。
どちらもキューのサポートがあるんですけれども、Horizonに関してはRedis Onlyです。Telescopeはすべて、Redisに限らず、DBキューだったりSQSキューだったり、あとはSyncのジョブに対してもすべてどういう状態なのかが見えるようになっています。
Horizonには、Failed Jobをリトライする機能があったり、実際投げたジョブがどんなステータスになっているかを見ることができるなど、それぞれ一長一短がありますが、そもそもコンセプトとしてデバッグ用とモニタリング用ということで違いがあることがわかったかと思います。
オープンロジではジョブのステータスを別途記録していて、誰がいつどこでなにをやったかは、すべての更新処理をジョブに集約することでトラッキングできるようにしています。
これがLaravel Telescopeだと、同じようなものがあって、ユーザーがどのジョブをどういうパラメータで実行したのかが記録されています。これらの情報を記録する分DBには負荷がかかるのであくまでデバッグ用ではあるのですが、こういうところが欲しかった部分です。
クエリやジョブやメールがどんなクエリが発行されたのかまで見ることができるので、開発にあたって便利そうだなと思っています。
あとはFailed Jobの再実行もオペレーションにおいてはよくある話です。
これは我々独自で作ったんですが、任意のFailed Jobに対してリトライする画面を用意しています。
これに関してはLaravel Horizonでも同じような画面があるので、利用されている方もいらっしゃるとは思うんですけれども、我々はこのHorizonが出る前に運用していたので、こういうツールを使ったりして工夫していました。
Horizonのようなモニタリングツールが欲しいけど、同時にTelescopeみたいなちゃんとログってくれるようなのも欲しくて、どっちもどっちというか、どっちも少し足りない感じなのですが、どちらのニーズも満たすようなジョブの管理をするようなツールを求めているんですが、今は自分たちで実装したもので工夫しています。
まとめです。
すべての更新処理をジョブで実行することによってスケーラブルにもなるし、関心事が分離されるし、それぞれ個別にReadとWriteを別々にスケーリングできるのは大きなメリットです。オープンロジでは初期からこの設計でしていますが、おかげでここまでの規模でうまくスケーラブルにスケールできています。
あとはジョブの実行記録を残すことで、実証可能な監査証跡を残すことができるし、トラブルシューティングがしやすいので非常におすすめです。
このTelescopeにもし興味あって使う方がいたときに気をつけてほしいのが、あくまでDevelopment環境での利用が前提になります。Telescopeを調べてたらこのサイトが出てきたんですよ。これってたぶんどこかの会社さんがプロダクションでもう運用しているサーバで、Telescopeが出ちゃっています(笑)。
(会場笑)
これはあとで気が向いたら報告します。しかも、Laravel Debugbarも出ちゃってて、かなりやばいです。それで「どんな会社なのかな?」って調べてみたら、これタイの会社なんですよね。トラックの画像があるので我々と同じ物流系の会社さんのようなのでがんばってほしいんですが、このトップページでもLaravel Debugbarが出てしまうというけっこうやばい状態になっているので(笑)。
(会場笑)
開発ではすごく便利なツールなんですけれども、こういうポカをしないようにみなさん気をつけてください。はい、以上です。
(会場拍手)
関連タグ:
2025.03.25
減点を恐れてモチベ低下、果ては離職も… あらゆる“会社の害虫”を大繁殖させる「ラスボス」の正体
2025.03.21
マネージャーの「自分でやったほうが早い」という行動で失うもの 効率・スピード重視の職場に足りていない考え方
2025.03.24
最悪の場合、組織を死に至らせる“会社の害虫”とは 誤った意思決定や品質不祥事を招く要因
2025.03.25
ムダな仕事がなくならない“マッチョな職場”を変えるには 近年の過度な「KPI主義」が組織に与えた影響
2025.03.24
気づけばモラル崩壊……人材育成に無頓着な企業の末路 業績アップや採用にもつながる“人への投資”の重要性
2025.03.19
組織をダメにする“害虫”の正体は間違った思い込み AIやDXなど手段のみにこだわるダメ上司の見極め方
2025.03.21
査定時期に上司から1年前の失敗を指摘される理不尽 変えられない過去を議論する「成果主義」の弊害
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.03.24
AIの進化が行き着く先は「イノベーター」へ ChatGPT開発者サム・アルトマン氏 × 孫正義氏が語る、人工知能変革期の未来
2025.03.27
交渉で「落としどころを探る」という考えは捨てるべき プロが教える、チャンスを逃さない条件交渉のコツ
2025.03.25
減点を恐れてモチベ低下、果ては離職も… あらゆる“会社の害虫”を大繁殖させる「ラスボス」の正体
2025.03.21
マネージャーの「自分でやったほうが早い」という行動で失うもの 効率・スピード重視の職場に足りていない考え方
2025.03.24
最悪の場合、組織を死に至らせる“会社の害虫”とは 誤った意思決定や品質不祥事を招く要因
2025.03.25
ムダな仕事がなくならない“マッチョな職場”を変えるには 近年の過度な「KPI主義」が組織に与えた影響
2025.03.24
気づけばモラル崩壊……人材育成に無頓着な企業の末路 業績アップや採用にもつながる“人への投資”の重要性
2025.03.19
組織をダメにする“害虫”の正体は間違った思い込み AIやDXなど手段のみにこだわるダメ上司の見極め方
2025.03.21
査定時期に上司から1年前の失敗を指摘される理不尽 変えられない過去を議論する「成果主義」の弊害
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.03.24
AIの進化が行き着く先は「イノベーター」へ ChatGPT開発者サム・アルトマン氏 × 孫正義氏が語る、人工知能変革期の未来
2025.03.27
交渉で「落としどころを探る」という考えは捨てるべき プロが教える、チャンスを逃さない条件交渉のコツ