Difyコミュニティ、スケジュール処理後も接続が解放されず、常駐ワーカープロセスでRedisのアイドル接続が蓄積する可能性を報告

Difyのスケジュール実行型AIワークフローで、リソースのライフサイクルに関する問題が報告された。10月22日に作成されたissueによると、geventプールを使用し、schedule_pollerキューを消費する常駐Celeryワーカープロセスは、タスクのディスパッチ完了後もRedisの結果サブスクリプション接続を保持する可能性がある。報告者は、本番環境で接続数が1万を超えて蓄積したことがあると述べている。これは個別のデプロイ環境での観察であり、サービス停止やデータ損失が発生したとは報告していない。issue原文

報告は当初、Dify 1.16.1をベースに、Celery 5.6.3、gevent 26.4.0、redis-py 7.4.0を組み合わせたデプロイ環境から寄せられた。投稿者は、問題がgroup(...).apply_async()の結果コールバック経路にあると特定した。サブスクリプションを解除した後も、結果受信を担うdrainerが生存し、バックエンドと接続を保持し続ける可能性があるという。投稿者の分析によれば、task_ignore_result=Trueを設定しても、この経路でサブスクリプションが作成されるのを防げなかった。技術分析

この違いは運用上重要だ。Celeryの公式ドキュメントでは、task_ignore_resultはタスクの戻り値を保存するかどうかを指定する設定と定義されている。そのため、この設定だけを根拠に、すべての結果コンシューマーでリソースのクリーンアップが完了すると判断することはできない。エンジニアリングチームがスケジューラーの健全性を確認する際は、成功率や実行時間に加え、タスク終了後も接続数が増え続けていないかを監視する必要がある。Celery設定ドキュメント

報告では、継続稼働するテスト用ワーカープロセスを使い、複数回の実際のディスパッチバッチにわたってRedisのクライアントID、アイドル時間、最後に実行されたコマンドを追跡する方法が推奨されている。短時間で終了するテストプロセスは、終了時にソケットを閉じるため、問題を見えにくくする可能性がある。また、接続数がタスクごとに必ず1つ増えると解釈すべきではない。再現手順

投稿者はさらに、結果バックエンドを分離し、リソースを明示的にクリーンアップする修正案を提示している。ただし、現時点で検証可能な根拠は主に投稿者からの報告に限られる。今後は、メンテナーによる再現、修正のレビュー、長時間負荷での検証に注目する必要がある。現段階では、この影響をすべてのDifyデプロイ環境やクラウドサービスに一般化することはできない。