CeleryはSQLAlchemyを通してRDBMSをBrokerとして利用できると記憶していたのですが、Celery 4.0からはSQLAlchemyをBrokerとしてのサポートは終了していました。知識として持っていましたが、実際にCeleryのBrokerにRDBMSを使ったことはありませんでした。
今開発中のサービスではCeleryをTaskQueueとcronの両方の用途で使おうと考えていたので、Celeryの代わりにPostgreSQLをBrokerを使えるライブラリか、CeleryのためにRabbitMQやRedisといったCeleryがBrokerとして対応しているミドルウェアを用意しなければならなくなりました。
結果、hueyを採用することにしました。
PostgreSQLをBrokerにしたい理由
PostgreSQLをBrokerとして使いたい理由は、サービスが依存するミドルウェアを増やしたくないからです。今開発中のサービスは少人数で開発、運用されているのでミドルウェアを増やすことは負担の大きな増加に繋がります。大量のタスクを処理させるのなら、専用のミドルウェアを用意したほうが負担が少なくなるとも考えられますが、見積もりでは大量のタスクの処理はありません。
これらを理由に、Celery以外で目的を達成できるライブラリがあればそれを使い、なければ新たなミドルウェアを導入してCeleryを使うことにしました。
HueyとDramatiq
Celeryと同じように使え、PostgreSQLをBrokerとして使えるライブラリとしてhueyとDramatiqを見つけました。hueyもDramatiqもCeleryを意識したライブラリです。hueyの方が関数名などもCeleryに似せている印象を受けました。DramatiqのドキュメントのMotivationに機能の比較表があります。
表にあるように、Dramatiqはcronのように時間をトリガーにタスクを実行することができないので、そこはAPSchedulerやPeriodiqで補うことになります。特にPeriodiqはDramatiq外のプロジェクトですが、Dramatiqのために作られました。
HueyとDramatiqのどちらにするかは決め手に欠けました。どちらも開発が継続されていまし、GitHubのスターの数も大差ありません。DramatiqがPython3.5以上を対処にしていることを活かして静的型付けに対するサポートを持っていればよかったのですが、それもありません。
DramatiqはPostgreSQLを使うには外部のdramatiq-pgを導入しなければならなりません。Hueyはcontrib扱いですが、本体でPostgreSQLに対応しています。Contribなのですが、Contribに追加したのは作者自身です。Hueyの作者はpeeweeの作者でもあります。なのでHueyの方がPostgreSQLに対するサポートが厚いと感じたのでhueyを採用することにしました。
余談: PostgreSQLは専用ならパフォーマンスも出るはず
PostgreSQLはLISTENとNOTIFYやSKIP LOCKEDがあるので、専用に実装すればQueueとして悪くないものになれるはずです。もちろん元々Queueとして設計されたものには劣るでしょうが。dramatiq-pgはLISTENとNOTIFYを使っているので高いパフォーマンスを期待できます。