update.普段、Celeryは非同期(終了を待ち合わせない、結果を求めない)で使うことが主ですが、同期(終了を待ち合わせて、結果を求める)でワークフロー的な使い方もできます。同じ題材で、ワークフローの検証をしてみます。Celeryの用語は、以下になります。n台の環境を立てます。SQSにしたりするのがよいかもしれません。workerの定義です。諸事情でPython2をベースにしていますが、新規プロジェクトであればPython3の方がいいです。workerは簡易的に立ててますが、本番で使うのであれば、デーモン化した方がいいです。app.start()CeleryのApplicationの定義です。['proj.tasks']Celeryの設定ファイルとして、外出しにしたものです。ファイルを定義した方がいいですが、今は標準出力にしています。str(index))CeleryのTasksの定義です。書かれていますが、実務的にモジュール分割しています。baseで書くことが多いからです。これについては後述します。部分は、後続のタスクがなく、最後は非同期で投げっぱなしにしています。終了を待ち合わせて後続のタスクがある場合は、Groupsで並列処理としてまとめ上げる感じでしょうか。main()CeleryのCanvas(ワークフロー)の定義です。Chainsで直列処理、タスクのパイプライン的なことをしています。Digdagのようにyamlで書けないので、見通しが悪くなるのは残念ですが、分散特化とのトレードオフでしょうか。実行ビルドして起動します。1台が上がっています。workerを2台にスケールアップして、複数台構成にしてみます。分散コンピューティングができるかを検証します。2台がぶら下がる形となりました。1台目に入って、Taskが登録されているか確認し、ワークフローを実行してみます。projリポジトリをデプロイし、ブローカーのredisを介して繋がるイメージとなります。workerがバッチサーバというのもありです。9一部省略しています。2台に分散されて実行されていることが確認できました。baseで書くことが多いからです。baseの書き方は冷遇されている印象を受けました。言え、Classの方が保守し易いので、紹介してみます。やらせたいことは、Task.run()に記述します。書き方は以下の2パターンあるようです。app.tasks[_AddTask.name]このとおりに書いても動かないですね。tasks」が正しくて、ドキュメントが直ってないと見ました。以下のようになります。CustomTask呼び出し側1台目に入って、Taskの登録状況を見てみます。proj.tasks.func_base.subtask2.の書き方だと、今までと違う感じがしてきました。print('running')app.register_task(CustomTask())こちらの方が、今までのClass的な使い方に近いと思いました。Celeryを介さない直接実行running3.の書き方をすれば問題ないと思います。Taskが登録されていないことがわかりました。行えば、classのインスタンスが返って来るのですが、何回も流れるのは、何か弊害がありそうな気がします。ソースコードを読むと、以下のように書いてあります。functionベースで書くのが良さそうです。デバッガで止めたい時など。最後、ぐだぐだですみません。株式会社日本システム技研は、1976年に設立した長野に本社を構えるIT企業です。Python/Djangoの使用したWebアプリケーションの受託開発とプロダクト開発を行なっています。upLoginユーザーは見つかりませんでした。