本記事では、PythonベースでのDjangoアプリケーションにおけるバックグラウンド処理基盤
として、Celery・Redis・PostgreSQLを統合し、最終的にsystemdによる本番運用レベルの
常駐サービス化に至るまでの一連の流れを、実際のエラーログとともに詳細に解説します。
【但し、この記事での本番レベルとはあくまでAI(Copilot）による評価です。ご承知おきを。】
本記事は、単なる技術解説ではありません。むしろ、開発者であれば誰もが一度は直面する
「なぜか動かない」という不安と、その正体を一つひとつ解き明かしていく思考のプロセス
を共有するものです。実際に、Celeryは起動している、Redisにも接続できている、タスクも
受信している――それにもかかわらず処理が失敗する。この「動いているのに動かない」
という状況は、初学者だけでなく経験者にとっても非常に厄介です。
本稿では、そうした曖昧な不具合をログから論理的に切り分け、原因を特定し、
最終的に安定運用へと至るまでの過程を丁寧に追っていきます。
技術そのものだけでなく、「どう考えるか」に焦点を当てている点が本記事の特徴です。
単なるチュートリアルではなく、
「なぜそのエラーが起きたのか」「なぜその修正が正しいのか」
という設計思想まで踏み込んで整理します。
1. Celery連携は成功しているのに動かない？エラーの本質を見抜く
ここでまず読者が直面するのは、「一見すべて正常に見えるのに処理が失敗する」
という非常に厄介な状況です。ログにはエラーが出ているものの、同時に
“成功しているようにも見える”情報が混在しているため、問題の所在がぼやけてしまいます。
多くの場合、この段階で「Celeryの設定が間違っているのではないか」
「Redisが不安定なのではないか」といった推測に引きずられがちです。
しかし実際には、問題はより地味で、しかし本質的な部分――
すなわちデータ構造の不一致に潜んでいるケースが少なくありません。
本章では、ログを冷静に読み解くことで
「どこまでが正常で、どこからが異常なのか」を切り分け、
問題の本質に到達するプロセスを整理していきます。
Celery・Redis・Djangoの連携はすでに完成していた
まず重要なのは、ログから読み取れる事実です。
Task greeting.tasks.crawl_task[...] received
これはつまり、
- Django → Celery へのタスク送信成功
- Redis がブローカーとして機能
- Worker がタスクを受信
という非同期処理基盤の核心部分が完全に動作していることを意味します。
つまり問題は「非同期処理」ではなく、
データベースとの整合性</strongにあります。
エラーの正体：カラム不一致
ProgrammingError: column "url" of relation "crawled_pages" does not exist
このエラーは極めて重要です。
一見単純な「カラムがない」問題ですが、
本質はもっと深く、
- Django側の設計
- Rails由来のDB構造
- クローラー実装
この3つの設計思想がズレている</strongことに起因しています。
2. RailsとDjangoの衝突：データモデルの非対称性
章のまとめ：
本章では、エラーの直接原因である「カラム不一致」の背後にある、
より本質的な問題――すなわちRailsとDjangoという異なるフレームワーク間の
データモデル設計のズレを明らかにしました。
一見すると単純なエラーに見える問題も、
その背景には設計思想の違いが潜んでいます。
ここでは、その構造的なズレを具体的に整理していきます。
■ 実際のテーブル構造（Rails側）
あなたのデータベースは以下のような構造を持っていました。
- page_url
- page_title
- content
- visited_at
- scope
- created_at
- updated_at
これは典型的なRails的設計であり、
命名規則やタイムスタンプの扱いが明確に統一されています。
■ Djangoクローラー側の前提
一方で、crawler.pyは以下のようなカラムを前提としていました。
- url
- title
- http_status
- depth
つまり、両者は完全に異なるデータモデルを前提としており、
そのままでは整合性が取れるはずがありません。
■ なぜこのズレが発生するのか
この問題は、実務的な開発環境において非常によく発生します。
- Railsで構築された既存データベース
- Djangoで追加機能を実装
- PostgreSQLで統合運用
この構成は柔軟性が高い一方で、
ORM（オブジェクトリレーショナルマッピング）の前提が異なるため、
データモデルの衝突が不可避となります。
つまり本質的な問題は、
技術的なエラーではなく設計思想の非対称性にあるのです。
3．正しい修正戦略：DBに合わせるか、コードに合わせるか
章のまとめ：
本章では、データ不整合を解消するための戦略として、
「DBを変更するか」「コードを変更するか」という二択を提示し、
実務的にはコード修正が最適である理由を整理しました。
■ 選択肢は2つしかない
この問題の解決方法はシンプルです。
- ① データベース構造を変更する
- ② アプリケーションコードを変更する
■ なぜコード修正が正解なのか
今回のケースでは、明確に「コード修正」が最適解となります。
- 既存データを破壊しない
- Rails側との整合性を維持できる
- 運用コストが低い
データベースはすでに運用中の資産であり、
それを変更するリスクは極めて高いためです。
■ 修正後のマッピング
コード修正により、以下の対応関係が成立します。
- url → page_url
- title → page_title
- body → content
このマッピングによって、
アプリケーションとデータベースの整合性が確立されます。
4．crawler.pyの最終完成形と設計思想
章のまとめ：
本章では、最終的に動作するコードの形だけでなく、
その背後にある設計思想――「整合性を優先する」という原則を整理しました。
■ 完成コードの本質
重要なのは「動くこと」ではなく、
全体システムとの整合性が取れていることです。
最終的なコードはシンプルですが、
その裏には明確な設計判断があります。
■ 設計上の重要ポイント
- Djangoがトランザクションを管理する
- SQLは必要最小限に留める
- Railsの命名規則に従う
これはつまり、
「フレームワークに合わせる」のではなく、
データベースという事実に合わせるという発想です。
5．Celeryの本番運用：systemdによる常駐化
章のまとめ：
本章では、Celeryを本番環境で安定運用するために、
systemdによるプロセス管理が不可欠であることを解説しました。
■ 手動運用の限界
従来の手動起動には以下の問題があります。
- 起動忘れのリスク
- サーバー再起動時に停止
- 運用の属人化
■ systemdによる解決
systemdを利用することで、
以下のような安定運用が実現します。
- 自動起動
- 自動再起動
- ログの一元管理
これは単なる便利機能ではなく、
本番運用の前提条件とも言えます。
6．systemctl statusの読み方と評価
章のまとめ：
本章では、systemctl statusの出力を正しく読み解くことで、
システムの健全性を判断する方法を整理しました。
■ 理想状態とは何か
- Active: active (running)
- Loaded: enabled
- エラーなし
■ 今回の状態の評価
今回の環境は、これらすべてを満たしており、
完全に本番運用可能な状態に到達しています。
これは単なる動作確認ではなく、
インフラとしての完成を意味します。
7．実際に何が完成したのか（全体像）
章のまとめ：
本章では、個々の技術要素ではなく、
それらが統合された「システム全体」としての完成度を整理しました。
■ 構成要素の整理
- Django（Webアプリケーション）
- Celery（非同期処理）
- Redis（メッセージキュー）
- PostgreSQL（データ永続化）
- systemd（運用管理）
これらが連携することで、
分散処理対応のバックエンド基盤が完成しています。
8．次に進むべきステップ（発展）
章のまとめ：
本章では、現在の完成状態を出発点として、
さらなる高度化に向けた具体的な発展ステップを提示しました。
■ 発展の方向性
- ① Celery Beatによる定期実行
- ② Flowerによる可視化
- ③ LlamaIndex連携による検索高度化
- ④ 並列処理最適化
これらを実装することで、
単なるクローラーから
知識生成システムへと進化していきます。
〆最後に〆
以上、間違い・ご意見は
以下アドレスまでお願いします。
全て返信できていませんが 見ています。
適時、改定をします。
nowkouji226@gmail.com
