Symfony Advent Calendar 2021 9日目の記事です。

SymfonyのMessengerコンポーネントについて、私は過去にも何度か情報発信してきていますが

今回はSymfony5以降で実装された、嬉しい改善ポイントについて書きます。

【Symfony5.1〜】 キューのバックエンドにSQSが増えました

ソース: https://symfony.com/blog/new-in-symfony-5-1-new-and-improved-integrations#messenger-component

SQSだけでなく他のサードパーティのキュー連携がいくつか追加されています。
カルテットではSymfonyアプリケーションを動かすのにAWS ECSを利用しているので、SQS連携によって、SQSへのキューのたまり具合によりmessenger:consumeコマンド用のECSタスクの起動数をオートスケールできるようになりました :tada:

いままではデータベースを利用しており、ジョブ数の予測に基づいて、一定時間内にさばけるようにスケジュールタスクとして立ち上げるタスク数を調整していました。この調整作業が不要になることと、予測よりもジョブ数が少なかったときのインフラ費用の無駄・予測よりもジョブ数が多すぎたときにユーザーをお待たせしてしまうということもなくなり、とても嬉しいupdateです。

【Symfony5.4〜】 1つのメッセージを処理するごとにコンテナやロガーがリセットされるようになりました

ソース: https://symfony.com/blog/new-in-symfony-5-4-messenger-improvements#reset-container-services-between-messages

いままで、MessageConsumerに対してMonologを利用してログを取っている場合、FingersCrossedHandlerを使っていると、途中で1個のメッセージ処理がエラーになった以後、同じMessageConsumerの実行中に正常に処理されたメッセージについてもログが流れてしまう問題がありました。特にSlackにログを流していると、1個メッセージがコケると数百〜数千のメッセージが流れてくることがあり、肝心のエラーログにたどり着くのが困難になっていました。
MessageHandler::invoke() 実装時にメインの処理をtry~catchで囲い、グローバルキャッチしてログを出して正常終了させるという方法は一応ありましたが、どのMessageHandlerにも同じ処理を実装するのはエレガントではありません 🤔
このupdateによって、

# config/packages/messenger.yaml
framework:
    messenger:
        reset_on_message: true

を設定しておくことにより、本当にエラーになったメッセージの分だけエラーログが出せるようになりました :raised_hands:

【Symfony5.4〜】 どのWorkerで処理されているかMessengerEventから取得できるようになりました

ソース: https://symfony.com/blog/new-in-symfony-5-4-messenger-improvements#worker-metadata

主にMessengerのイベントに対してlistener, subscriberを使ってなにか処理しているときに役立ちます。
たとえば、Workerが停止してしまったとき、「Transport async の heavy キューに対するWorkerが停止しました」みたいな通知をMonologを通じてSlackに送る、みたいなこともできますね :raised_hands: 今まではインフラレベルでどれが止まっているか見に行かないといけなかったのが、PHPの世界で解決できるようになっています。



やっぱり開発者を楽にする改善を続けてくれるSymfonyが大好きです！ ☺️
明日は @ttskch さんの記事です〜。