博士

ロボ子、Django 6.0に`django.tasks`っていうバックグラウンドタスクフレームワークが追加されたのじゃ！

ロボ子

バックグラウンドタスク、ですか。それは便利そうですね！具体的にはどんなことができるんですか？

博士

`django.tasks`は、タスクキューの共通APIを提供するものなのじゃ。タスクの作成とキューイングはDjangoがやってくれるけど、実行は別のプロセスやサービスで管理する必要があるみたい。

ロボ子

なるほど、タスクの実行自体はDjangoが面倒を見てくれるわけではないんですね。ワーカーメカニズムは提供されない、と。

博士

そうそう。でも、タスクの定義は簡単なのじゃ！ `@task`デコレーターを使うだけで、タスクの優先度とかキュー名、バックエンド名も指定できるぞ。

ロボ子

`@task`デコレーター、ですね。例えば、タスクの優先度を設定すると、どうなるんですか？

博士

優先度が高いタスクは、低いタスクよりも先に実行される可能性が高くなるのじゃ。例えば、ユーザーからのリクエストに即座に応答する必要があるタスクは、優先度を高く設定すると良いぞ。

ロボ子

なるほど。それから、`takes_context=True`とすると、タスクコンテキストにアクセスできるんですね。試行回数などの情報が得られる、と。

博士

そうじゃ！タスクが失敗した場合に、リトライ回数を制限したり、バックオフしたりするのに使えるぞ。でも、`django.tasks`自体は、リトライやバックオフなどの高度な機能は提供してないから、自分で実装する必要があるのじゃ。

ロボ子

自分で実装、ですか。少し手間がかかりますね。タスクの結果を取得するには、どうすればいいんですか？

博士

`get_result(result_id)`でタスクの結果を取得できるのじゃ。Django 6.0には`ImmediateBackend`と`DummyBackend`が付属していて、`ImmediateBackend`はタスクを即時実行、`DummyBackend`はタスクを実行しないぞ。

ロボ子

`ImmediateBackend`は開発環境で便利そうですね。本番環境では、別のバックエンドを使うことになるんでしょうか。

博士

その通り！データベースバックエンドを自分で実装することもできるのじゃ。タスクの状態を管理するために`Task`モデルと`TaskResult`モデルを作成して、`available_after`フィールドでタスクの実行可能時間を制御したり、`attempt_count`フィールドで試行回数を管理したりできるぞ。

ロボ子

データベースを使うことで、タスクの状態を永続化できるんですね。ワーカーは`QueueStore`のコピーを持ち、処理対象のキューに限定される、と。

博士

そうじゃ！ワーカーは未処理のタスクの情報をランナーに提供して、タスクの処理を推進するのじゃ。`peek`メソッドで最も緊急度の高いタスクのIDを取得して、`claim`メソッドで特定のタスクを要求できるぞ。

ロボ子

`peek`と`claim`、ですね。タスクを処理する際には、`process_task`メソッドを使うんですね。タスクが失敗した場合は、リトライ可能かどうかを確認する、と。

博士

`django.tasks`は、複雑なオーケストレーション、自動リトライ、ワーカーメカニズムは提供されないけど、一般的なユースケースの80%をカバーすると予想されているのじゃ。

ロボ子

なるほど。APIはシンプルで限定的ですが、標準化されたアプローチに近いんですね。今後の発展が楽しみです。

博士

そうじゃな！ところでロボ子、タスクをキューに入れることを、英語で何と言うか知ってるか？

ロボ子

えっと… enqueue ですか？

博士

正解！…って、そのまんまじゃな！