結論から言うと、圧縮タスク非同期化の標準ソリューションは Celery + Redis タスクキューで、コアアーキテクチャは Producer(FastAPI がタスクを投入)→ Broker(Redis が一時保存)→ Worker(Celery がタスクを消費し、Rust 圧縮エンジンを呼び出し)→ Backend(Redis が結果を保存)です。1万ファイルの一括圧縮に対し、100ファイルずつに分割し、12 Worker で並行処理すれば約40分で完了します。重要な設計ポイントは、タスク分割、優先度キュー、指数バックオフによるリトライ、死信キューでの保険です。以下ではキューアーキテクチャから説明し、Celery 設定パラメータ表と完全な実践ソリューションを示します。
圧縮サービスの全体デプロイにまだ不慣れな場合は、まず「Docker デプロイ圧縮サービス完全ガイド」をご覧ください。
一、圧縮タスクはなぜ非同期キューが必要か
ファイル圧縮は典型的な CPU 密集型＋IO 密集型タスクです。1件の100MB PDFの圧縮には5〜15秒かかり、同期インターフェースで処理すると HTTP 接続が長時間保留され、単機の並行処理能力は極めて低くなります。非同期キューは「提出」と「実行」を分離します：クライアントはタスク提出後すぐに task_id を受け取り、Worker がバックグラウンドで圧縮し、完了後にコールバックまたはポーリングで結果を返します。
| 処理方法 | 並行処理能力 | 応答遅延 | 失敗処理 | 適用規模 |
|---|---|---|---|---|
| 同期処理 | 低い（HTTP接続をブロック） | 5〜60秒 | リトライなし、直接エラー | 10ファイル未満 |
| スレッドプール | 中（スレッド数に制限） | 1〜5秒 | 手動実装が必要 | 10〜100ファイル |
| Celery非同期キュー | 高い（Workerの水平拡張） | 200ms未満 | 自動リトライ＋死信キュー | 100〜10万ファイル |
| Kubernetes+キュー | 非常に高い（HPAによる弾性スケール） | 100ms未満 | 完全なフォールトトレランス体系 | 10万ファイル超 |
SmartSlim ネットワーク版は FastAPI + Celery + Redis + MinIO アーキテクチャを採用し、単機で12並列タスクを安定実行、Kubernetes デプロイ時は HPA により3〜10レプリカ間で自動スケールします。このアーキテクチャはすでに複数の企業顧客の日次万件規模のファイル圧縮要件を支えています。
二、Celery タスクキューアーキテクチャ詳解
Celery タスクキューは4つのコアロールで構成されます:Producer(生産者)、Broker(メッセージブローカー)、Worker(作業プロセス)、Backend(結果ストレージ)。この4層の役割を理解してこそ、圧縮タスクキューを正しく設定できます。
| コンポーネント | 技術選定 | 役割 | 重要設定 |
|---|---|---|---|
| Producer | FastAPI | HTTPリクエストを受信し、タスクを組み立ててBrokerへ投入 | task.apply_async(queue=...) |
| Broker | Redis 7.x | 待機中のタスクメッセージを一時保存、優先度キューをサポート | broker_url, visibility_timeout |
| Worker | Celery 5.x | タスクを消費し、Rust 圧縮エンジンを呼び出して圧縮を実行 | concurrency, prefork pool |
| Backend | Redis | タスク状態・結果を保存 | result_backend, result_expires |
| ストレージ層 | MinIO | ストレージ元ファイル・圧縮後ファイル | S3互換プロトコル、分割アップロード |
1. Celery コア設定パラメータ表
Celery の設定はキューのスループットと安定性を直接決定します。次の表は圧縮シナリオの推奨設定で、SmartSlim の本番環境で検証済みです。
| パラメータ | 推奨値 | 説明 |
|---|---|---|
| broker_url | redis://:password@redis:6379/0 | Redisをメッセージブローカーとして使用、独立DBで衝突を回避 |
| result_backend | redis://:password@redis:6379/1 | 結果保存は独立DBを使用、Brokerと分離 |
| task_serializer | json | JSONシリアライズ、言語をまたぐ互換性 |
| result_serializer | json | 結果も同様にJSONを使用 |
| accept_content | ['json'] | JSONのみ受け付け、セキュリティ強化 |
| timezone | Asia/Shanghai | 時区統一 |
| task_acks_late | True | タスク完了後にACK、クラッシュ時もタスクを消失しない |
| worker_prefetch_multiplier | 1 | 各Workerは1タスクのみ先読み、長時間タスクの飢餓を回避 |
| task_time_limit | 600 | 単一タスクのハードタイムアウト600秒 |
| task_soft_time_limit | 540 | ソフトタイムアウト540秒、SoftTimeLimitExceededを発生させる |
| task_reject_on_worker_lost | True | Worker異常終了時にタスクを拒否し、再キューイング |
| result_expires | 86400 | 結果は24時間保持後に自動クリーンアップ |
2. 優先級キュー設計
圧縮タスクある軽重の分：ユーザー実時提出の圧縮リクエスト必要高速響すべき、定時アーカイブタスクできるゆっくり跑。を用いて Redis 優先級キュー実現差異化調度、高い優先級タスク優先される Worker 消費。
| キュー名 | 優先級 | 路により規则 | 典型タスク |
|---|---|---|---|
| compression_high | 9（最も高い） | ユーザー実時リクエスト | 単ファイル即時圧縮 |
| compression_normal | 5（デフォルト） | バッチ量タスク | 一括圧縮100–500ファイル |
| compression_low | 1（最も低い） | 定時アーカイブ | 夜間すべて量アーカイブ圧縮 |
| dlq_queue | —（死信） | 重试失敗のタスク | 人工排查または補償処理 |
三、実践事例：1万ファイルの非同期圧縮
ある企業のデータアーカイブシナリオです:1万件の歴史文書(PDF/Word/画像の混合、平均8MB/ファイル、合計約80GB)を統一して圧縮アーカイブする必要があります。要件は1時間以内に完了、圧縮率60%以上です。
ソリューション設計： 100ファイルずつに分割して100の子タスクとし、Celery group で一括投入、12 Worker が並列消費します。各子タスク内では Rust 圧縮エンジンを直列に呼び出して100ファイルを圧縮します。
実行パラメータとスループットの実測値：
| 指標 | パラメータ | 実測値 | 説明 |
|---|---|---|---|
| ファイル総数 | 10,000件 | — | 混合形式、平均8MB/件 |
| 分割粒度 | 100ファイル/片 | 100個の子タスク | スケジューリングオーバーヘッドとリトライコストのバランス |
| Worker並列数 | 12 | preforkモード | 単機12コアCPU |
| 単ファイル圧縮時間 | — | 平均3.2秒 | Rustエンジンmedium段階 |
| 単片の所要時間 | — | 約5.3分 | 100ファイルを直列処理 |
| 全体の所要時間 | — | 約44分 | 100片/12並列 |
| 圧縮率 | — | 67.3% | 80GB→26.2GB |
| 失敗数 | — | 17件 | ファイル破損、リトライ後に死信キューへ |
結果： 44分で1万ファイルの圧縮が完了、圧縮率67.3%、破損ファイル17件は自動的に死信キューに入り手動で処理しました。全体のアーキテクチャは安定し、CPU使用率はピーク89%、メモリ使用量はピーク4.2GBで、OOMやタスクの消失はありませんでした。
3. 重试と死信キュー戦略
圧縮タスクの失敗原因は2クラスに分けられます:一時的なエラー(IOタイムアウト、メモリ不足、並列数過多)と確定的なエラー(ファイル破損、未対応形式)。一時的なエラーはリトライで成功する可能性が高く、確定的なエラーはリトライに意味がありません。次の表に、リトライと死信の意思決定戦略を示します。
| エラータイプ | 典型例外 | 処理戦略 | リトライ回数 | 最終的な行き先 |
|---|---|---|---|---|
| 臨時性-IO | ConnectionError, TimeoutError | 指数バックオフでリトライ | 3次 | 成功または死信キューへ |
| 臨時性-リソース | MemoryError, OOMKilled | バックオフ延長＋グレードダウン | 2次 | 成功または死信キューへ |
| 確定性-ファイル | FileCorrupted, ParseError | リトライなし、直接死信キューへ | 0次 | dlq_queue |
| 確定性-形式 | UnsupportedFormat | リトライなし、直接死信キューへ | 0次 | dlq_queue |
| 確定性-権限 | PermissionDenied | リトライなし、アラート | 0次 | dlq_queue+アラート |
リトライ設定は Celery の autoretry_for・retry_backoff を使用し、初期バックオフ60秒、最大600秒、ランダムジッターを加えて雪崩を回避します。死信キューのタスクは独立した監視タスクで定期スキャンし、企業微信/DingTalkのアラートで運用担当者に通知して処理します。
| 監視指標 | 収集方法 | アラート閾値 | 処理動作 |
|---|---|---|---|
| キュー積圧量 | Redis LLEN | 500超 | Workerのスケールアウトを発動 |
| タスク失敗率 | Celery events | 5%超 | ログ調査＋投入の一時停止 |
| 死信キュー長 | Redis LLEN dlq | 10超 | 企業微信アラート |
| Worker存活数 | Celery inspect | 10未満 | Workerの自動再起動 |
| 平均タスク耗時 | Flower監視 | 30秒超 | 大容量ファイルの確認＋グレードダウン |
| CPU利用率 | node_exporter | 95%超 | レート制限＋スケールアウト |
圧縮 API の完全な呼び出し方法については、「圧縮 API 呼び出しガイド：REST インターフェース設計」をご参照ください。
四、シナリオ別のキュー設定推奨
業務シナリオによって、スループット・レイテンシ・信頼性への要求は異なるため、キュー設定も使い分けが必要です。以下の表に、一般的なシナリオの推奨設定を示します。
| シナリオ | Worker数 | 分片粒度 | 優先級キュー | 重试戦略 |
|---|---|---|---|---|
| 個人即時圧縮 | 2 | 不分片 | high | 高速重试3次 |
| 企業一括アーカイブ | 12 | 100ファイル/片 | normal/low | 指数退避3次 |
| 政府機密処理 | 4 | 50ファイル/片 | high | 厳格重试+監査 |
| 電商プラットフォーム画像 | 16 | 200ファイル/片 | normal | 高速重试2次 |
| 夜間定時アーカイブ | 8 | 500ファイル/片 | low | 緩やかなバックオフ5回 |
| リアルタイム動画トランスコード | 24 | 単一ファイル | high | リトライなし、失敗時にアラート |
一般的な原則:リアルタイムシナリオでは高優先度キュー＋小さな分割＋高速リトライ、一括シナリオでは通常キュー＋大きな分割＋指数バックオフ、機密シナリオでは厳格監査＋小さな分割＋多段リトライを使用します。企業級一括圧縮の完全なソリューションは「企業一括圧縮ソリューション：1万ファイルのバッチ処理」をご参照ください。
五、よくある質問FAQ
Q1:Celeryで圧縮タスクの非同期処理はどう実現する？
を用いて Celery + Redis で非同期タスクキューを構築します:FastAPI がリクエストを受信後、タスクを Redis Broker に投入し、Celery Worker が Broker からタスクを消費して Rust 圧縮エンジンを呼び出して圧縮を実行し、結果は Backend・MinIO に書き込まれます。task.apply_async で非同期実行し、task.id で状態をポーリングします。単機12 Workerの並列で、1万ファイルを100ファイルずつ分割すれば40分以内に完了できます。
Q2：圧縮タスク失敗の自動リトライ？
Celery の autoretry_for パラメータで自動リトライを設定します:max_retries=3、retry_backoff=True（指数バックオフ、初期60秒）、retry_backoff_max=600秒、retry_jitter=True（ランダムジッターで雪崩を回避）。3回リトライしても失敗するタスクは自動的に死信キュー dlq_queue へ振り分けられ、手動または補償タスクで処理します。一時的なエラー（IOタイムアウト/メモリ不足）にはリトライを推奨し、確定的なエラー（ファイル破損/未対応形式）は直接死信キューへ入れます。
Q3：1万ファイル一括圧縮の分割方法？
100ファイルずつ分割し、合計100の子タスクにします。Celery group または chord で一括投入し、12 Worker が並列消費し、各子タスク内で100ファイルを直列に圧縮します。単ファイル平均圧縮時間3秒、単片約5分、100片を並列化すると全体で約40分で完了します。分割粒度が細かすぎると（例えば1ファイルずつ）スケジューリングオーバーヘッドが大きくなり、粗すぎると（例えば1,000ファイルずつ）失敗時のリトライコストが高くなります。100は経験上の最適値です。
Q4：Celery と RQ のどちらが圧縮タスクキューに適している？
圧縮タスクには Celery を推奨します。Celery はタスク分割(group/chord)、優先度キュー、定時タスク、タスクチェーン、死信キューをサポートし、機能が完全です;RQ はより軽量ですが分割・優先度が不足しています。圧縮シナリオでは一般的に一括分割、優先度スケジューリング、失敗リトライなどの要件があり、Celery はネイティブサポートしています。性能面では両者とも Redis ベースでスループットは同等です。SmartSlim ネットワーク版は FastAPI + Celery + Redis + MinIO アーキテクチャを採用し、単機12並列で安定稼働しています。
まとめ
圧縮タスク非同期化の標準ソリューションは Celery + Redis タスクキューで、コアは Producer/Broker/Worker/Backend の4層分離です。万件規模のファイル一括圧縮に対しては、100ファイルずつの分割、12 Worker の並列処理で約40分で完了し、圧縮率は60%〜70%です。リトライ戦略では一時的なエラー(指数バックオフでリトライ)と確定的なエラー(直接死信キューへ)を区別し、6項目の監視指標でキューの安定性を保障します。
覚えておくべき3つのポイント:1つ目は task_acks_late=True でクラッシュ時もタスクを消失しないこと、2つ目は worker_prefetch_multiplier=1 で長時間タスクの飢餓を回避すること、3つ目は死信キューには必ず監視アラートを組み合わせることです。キューアーキテクチャと分割戦略を適切に選定すれば、圧縮サービスのスループットと安定性はもう一段上がります。