SQSJobQueueBundleをつくってみました。

こんばんわ、ポリドッグです。 SQSJobQueueBundleを作ってみました。

前職ではBCCResqueBundle使っていましたが、今回はResqueを使わないので、自ずとBCCResqueBundleは使えません。 Amazon SQSでメッセージキュー的な処理をするので、SQSJobQueueBundleを作ってみました。

SQSJobQueueBundleを作った理由。

これは前職でBCCResqueBundleを使ってそれなりに使いやすかったってところがあって、使いました。
あとMessageQueueってある意味では、自由にいろいろなものを登録できてしますので、そこを制限したかったって理由もあるかと思います。　　

そもそもBCCResqueBundleの利点。

僕個人的な見解としては、BCCResqueBundleの利点は以下の二つだと思うんですよね。

MQにメッセージを登録するのではなくJobという処理するクラス(インスタンス)の情報を登録できる
ContainerAwareJobクラスを継承してJobクラスを作れば、DIコンテナが使える

メッセージでのやり取りって秩序を保つのが難しいので、やはりJobクラスがあったほうが便利だと思います。

そんなわけでつくってみた。

若干車輪の際発明な気もしますが、Jobに処理をまとめたかったので、SQSJobQueueBundleを作ってみました。
coreとなる処理はSQSJobQueueで実装しています。

一応今回はJobを扱えるという機能を提供することを目的としているので、その他の機能に関しては、サポートしません。
一部symfony2のコマンドでやったほうが便利そうなコマンドに関しては、SQSJobQueueBundleのコマンドで Aws\Sqs\SqsClientを利用したコマンドを提供をしています。
ただ、あくまでSQSJobQueueはAmazon SQSでJobを扱うというこに注力するといった思想で実装しています。

常駐するワーカーについて。

1

$ app/console sqs_job_queue:worker-start キュー名

といった形でキューを常駐させる機能もサポートしています。

@polidog あの。 |ω・`)ﾁﾗ SQSで、差し支えなかったら伺いたいことが。受信コンシューマ側、みんなどうやっているのだろう？と（無限常駐ワーカーにするとメモリ管理不安なので、CRON定期起動するPHPスクリプトとして自力でタイマ自死させてるのですが、微妙かなと)
— kuma_nana (@kuma_nana) February 28, 2015

上記のようなつっこみもありましが、メモリリークが若干しんぱいです。。。誰か、ちゃんとした検証してくれると嬉しいです＞＜
僕も検証するように努力します。

まとめ。

ほぼ初めてSymfony2のバンドルを作ってみましたが、作る環境には結構苦労しました。でも、かなりの勉強になりました。
それから、自分のエンジニアとして足りない部分が、課題点が浮き彫りになりました。
バンドルを作ってみて思ったことは、広い視点で捉えるためにも、Symfony2を使ってる方はぜひ自分のバンドルを作ってみるといいと思います。

また、かなりの荒削りな感じです。品質もお世辞にもいいものとは言えません。
しかし、これから品質の良いものを追求していこうと思いますので、何か問題がある場合は@polidogまでリプライか、もしくはpull requestとか送ってください。
なるべく早く対応しようと思うので、ぜひぜひよろしくお願いします。
もっとこうしたほうがいいとか、これって違うんじゃない？って意見がありましたら、教えてください！！！