Celery on Ubuntu 応用 — タスクキューの監視・スケジューリング・Flower

開発環境

この記事のポイント

  • Ubuntu 24.04 LTS で Celery 5.4.0 + Redis + Flower 2.0.1 を実際に動かして確認
  • Flower の WebUI（ポート 5555）からワーカー稼働状況・タスク履歴をブラウザで監視できる
  • Celery Beat で interval（秒数）と crontab（曜日・時刻）の2種類のスケジュールを設定できる
  • celery -A tasks worker --detach でバックグラウンド起動し、systemd で自動起動管理する流れを解説
  • 実測：add() タスクが約 0.0015〜0.0019 秒で完了、全4タスクをキューに流して結果を確認

Celery の「タスクを投げて非同期に動かす」基礎は分かった。でも実際に本番で使おうとすると、「今ワーカーは生きているのか」「タスクがどこで詰まっているのか」が見えなくて困る——私が最初に詰まったのはここでした。

この記事では Flower を使ったリアルタイム監視とCelery Beat によるスケジューリングを実際に Ubuntu 24.04 LTS で動かして解説します。コマンドの実行ログと Flower の画面スクリーンショットも載せているので、自分の環境と照らし合わせながら読み進めてください。

動作確認済み環境




ubuntu@linuxlab: ~
$ cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME=”Ubuntu 24.04.4 LTS”
$ python3 –version
Python 3.12.3
検証環境パッケージ一覧（実測）
検証環境パッケージ一覧（実測）

上表のパッケージバージョンで全手順を確認しています。redis-py（Pythonクライアント）と Redis サーバー本体はバージョンが異なるので混同しないようにしてください。

Celery の全体構成を把握する

手順に入る前に、コンポーネントの関係を整理しておきます。

Celery アーキテクチャ概念図
Celery アーキテクチャ概念図

登場人物は5つです。

  • ブローカー（Redis）：タスクを一時保管するメッセージキュー。Worker はここからタスクを取り出す
  • Celery Worker：タスクを実際に実行するプロセス。複数起動して並列化できる
  • Result Backend（Redis）：タスクの実行結果を保存する場所。今回はブローカーと同じ Redis を使う
  • Celery Beat：定期実行スケジューラ。cron のように決まったタイミングでタスクをブローカーに投入する
  • Flower：Web監視ツール。ブラウザからワーカーの状態やタスク履歴を確認できる

インストール手順

手順1：Redis をインストールして起動する




ubuntu@linuxlab: ~
$ sudo apt-get update
$ sudo apt-get install -y redis-server
Setting up redis-server (5:7.0.15-1ubuntu0.24.04.4) …
$ sudo systemctl enable –now redis-server
$ redis-cli ping
PONG

PONG が返れば Redis は起動しています。Ubuntu 24.04 の apt パッケージは Redis 7.0.15 が入ります（2026-06-22 時点）。

手順2：Celery、Flower をインストールする




ubuntu@linuxlab: ~
$ python3 -m venv ~/celery_env
$ source ~/celery_env/bin/activate
(celery_env) $ pip install celery==5.4.0 redis==5.2.0 flower==2.0.1
Successfully installed celery-5.4.0 redis-5.2.0 flower-2.0.1
(celery_env) $ celery –version
5.4.0 (opalescent)
インストール確認ログ（実測）
インストール確認ログ（実測）

Ubuntu 24.04 でのパッケージ管理について

Ubuntu 24.04 以降、pip install をシステム Python に直接実行すると「externally-managed-environment」エラーが出ます。python3 -m venv ~/celery_env で仮想環境を作ってから使うか、--break-system-packages オプションをつけてください（プロダクション環境では仮想環境推奨）。

タスクの定義と Worker 起動

タスクファイルを作る




ubuntu@linuxlab: ~/myproject
$ cat tasks.py
import os, time
from celery import Celery

BROKER_URL = os.environ.get(“CELERY_BROKER_URL”, “redis://localhost:6379/0”)
app = Celery(“tasks”, broker=BROKER_URL, backend=BROKER_URL)

app.conf.update(
task_serializer=”json”,
result_serializer=”json”,
timezone=”Asia/Tokyo”,
enable_utc=True,
)

@app.task
def add(x, y):
return x + y

@app.task
def multiply(x, y):
time.sleep(0.1) # 重い処理を模倣
return x * y

CELERY_BROKER_URL を環境変数で差し込む書き方にしておくと、本番環境への切り替えが楽です。

Worker をバックグラウンドで起動する




ubuntu@linuxlab: ~/myproject
(celery_env) $ celery -A tasks worker \
–loglevel=info \
–detach \
–logfile=/var/log/celery/worker.log \
–pidfile=/var/run/celery/worker.pid
[2026-06-22 …] celery@hostname ready.

--detach をつけるとデーモン化されます。ログは /var/log/celery/worker.log に追記されるので、tail -f で流しながら動作確認するのが私のやり方です。

タスクを投入して結果を確認する




ubuntu@linuxlab: ~/myproject
(celery_env) $ python3
>>> from tasks import add, multiply
>>> r1 = add.delay(10, 20)
>>> r2 = multiply.delay(6, 7)
>>> r1.get(timeout=10)
30
>>> r2.get(timeout=10)
42
タスク実行ログ（実測）
タスク実行ログ（実測）

実測では add() が約 0.0015〜0.0019 秒、multiply()（内部に 0.1 秒スリープあり）が約 0.102 秒で完了しました。Worker ログには Task tasks.add succeeded in 0.0015s: 300 のように実行時間が出るので、遅いタスクを特定するのに便利です。

Flower で Worker を監視する

Flower を起動する




ubuntu@linuxlab: ~/myproject
(celery_env) $ celery -A tasks flower –port=5555
INFO: Starting Flower 2.0.1
INFO: Operational endpoint. /healthcheck
INFO: Listening on: http://0.0.0.0:5555

ブラウザで http://<サーバーIP>:5555 にアクセスすると Flower のダッシュボードが開きます。

Flower ダッシュボード — メイン画面

Flower ダッシュボード メイン画面（実撮影）
Flower ダッシュボード メイン画面（実撮影）

ダッシュボードにはアクティブなワーカー数と、処理中・成功・失敗のタスク数がリアルタイムで表示されます。上の画面は Ubuntu 24.04 + Celery 5.4.0 + Flower 2.0.1 で実際に起動したものです。

Flower — Workers ページ

Flower Workers ページ（実撮影）
Flower Workers ページ（実撮影）

Workers ページでは 各ワーカーのホスト名・状態・処理済みタスク数を確認できます。ワーカーが落ちているとここに反映されるので、障害検知の起点として使えます。

Flower — Tasks ページ

Flower Tasks ページ（実撮影）
Flower Tasks ページ（実撮影）

Tasks ページにはタスク名・状態・開始時刻・実行時間が並びます。FAILURE のタスクがあれば引数とトレースバックもここで確認できます。デバッグで一番使うページです。

Flower — Monitor ページ

Flower Monitor ページ（実撮影）
Flower Monitor ページ（実撮影）

Monitor ページではタスク処理数の時系列グラフを確認できます。急にタスク数が増えたタイミングやワーカーの処理能力のボトルネックを視覚的に把握できます。

Flower をVPS に公開する場合の注意

デフォルトでは認証なしで誰でも閲覧できます。外部に公開する場合は --basic_auth=user:password オプションか、Nginx でリバースプロキシを立てて Basic 認証をかけてください。

Celery Beat でタスクをスケジューリングする

Celery Beat は cron に相当するスケジューラです。定期的にタスクをブローカーへ投入します。Worker と Beat は別プロセスなので、両方を起動しないとタスクは実行されません。

スケジュール設定（tasks.py に追記）




ubuntu@linuxlab: ~/myproject
from celery.schedules import crontab

app.conf.beat_schedule = {
“add-every-30-seconds”: {
“task”: “tasks.add”,
“schedule”: 30.0, # 30秒ごとに実行
“args”: (16, 16),
},
“cleanup-every-morning”: {
“task”: “tasks.cleanup”,
“schedule”: crontab(hour=2, minute=0), # 毎朝 2:00
},
“weekly-report”: {
“task”: “tasks.send_report”,
“schedule”: crontab(day_of_week=”monday”, hour=9, minute=0),
},
}
Beat スケジュール定義確認（実測）
Beat スケジュール定義確認（実測）

上図は実際に Ubuntu 24.04 + Celery 5.4.0 で定義を確認したものです。crontab オブジェクトの文字列表現 <crontab: 0 2 * * * (m/h/dM/MY/d)> が Linux cron の書式と同じ順序で並んでいるのを確認できます。

Beat を起動する




ubuntu@linuxlab: ~/myproject
(celery_env) $ celery -A tasks beat \
–loglevel=info \
–detach \
–logfile=/var/log/celery/beat.log \
–pidfile=/var/run/celery/beat.pid
[INFO] beat: Starting…
[INFO] Scheduler: Sending due task add-every-30-seconds (tasks.add)

Beat は別ターミナルか --detach でバックグラウンド起動します。Beat ログに Sending due task ... が流れれば正常にタスクを投入できています。

Beat は必ず1プロセスだけ

Beat を複数起動すると同じタスクが重複実行されます。Worker は複数起動して構いませんが、Beat は必ず1プロセスで管理してください。celerybeat.pid ファイルが残っている場合は削除してから起動します。

systemd でプロセス管理する

VPS で本番運用する場合は systemd に登録してサーバー起動時に自動起動させます。




ubuntu@linuxlab: ~
$ sudo cat /etc/systemd/system/celery-worker.service
[Unit]
Description=Celery Worker
After=network.target redis.service

[Service]
Type=forking
User=ubuntu
Group=ubuntu
WorkingDirectory=/home/ubuntu/myproject
ExecStart=/home/ubuntu/celery_env/bin/celery \
-A tasks worker –detach \
–logfile=/var/log/celery/worker.log \
–pidfile=/var/run/celery/worker.pid
ExecStop=/bin/kill -s TERM $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target
$ sudo systemctl daemon-reload
$ sudo systemctl enable –now celery-worker
Created symlink … → /etc/systemd/system/celery-worker.service.

After=redis.service を指定しておくと Redis 起動後に Worker が立ち上がるので、サーバー再起動時の順序問題を防げます。Beat も同じ要領で celery-beat.service を作成してください。

よくあるエラーと解決策

① Connection refused — Redis に繋がらない




ubuntu@linuxlab: ~
kombu.exceptions.OperationalError: [Errno 111] Connection refused

redis-cli ping を実行して Redis が起動しているか確認します。Redis が落ちている場合は sudo systemctl start redis-server で起動してください。

② broker_connection_retry_on_startup 警告




ubuntu@linuxlab: ~
DeprecationWarning: The broker_connection_retry configuration setting will no
longer determine whether broker connection retries are made during startup
in Celery 6.0 and above.

Celery 5.4 以降で出る警告です。app.conf.broker_connection_retry_on_startup = True を追加しておくと消えます。動作には影響しませんが、Celery 6.0 対応として入れておくと安心です。

③ タスクが Flower に表示されない

Flower はデフォルトで最近のタスク履歴だけを表示します。celery -A tasks flower --persistent=True --db=/tmp/flower.db のように永続化オプションを追加すると再起動後もタスク履歴を保持できます。

④ Beat のタスクが重複実行される

Beat が複数起動しています。ps aux | grep celery で確認し、余分なプロセスを kill してください。/var/run/celery/beat.pid が残っている場合は削除してから起動します。

まとめ

Ubuntu 24.04 LTS + Celery 5.4.0 + Redis 7.0.15 + Flower 2.0.1 の組み合わせで、実際にタスクを動かしながら確認しました。

  • Celery Worker は --detach でバックグラウンド起動、systemd で自動起動管理
  • Flower（ポート 5555）でワーカー稼働状況・タスク履歴・処理グラフをブラウザで監視できる
  • Celery Beat の beat_schedule で interval（秒数）と crontab（cron 書式）の2種類のスケジュールを定義できる
  • Beat は必ず1プロセスだけ起動する
  • 外部公開するなら Flower に Basic 認証か Nginx のリバースプロキシをかける

Celery の応用として次のステップは、タスクの優先度付けとキューの分離です。重いタスクと軽いタスクを別キューに振り分けて Worker を分けると、重い処理が軽いタスクをブロックしなくなります。

VPS で本格的に Celery を動かすなら、メモリと CPU が確保できる環境が必要です。下の記事で各 VPS のスペックと料金を実測ベンチで比較しています。


Vultr 公式サイトでプランを確認する →

コメント

タイトルとURLをコピーしました