バックグラウンドワーカーに上限付きの予算を与える

有用な作業の 1 単位を定義する

内部 CSV エクスポートの場合、リクエストがエクスポートレコードを作成し、ワーカーが範囲を限定したデータセットを読み取り、出力オブジェクトを書き込み、レコードを完了としてマークします。最大有用スコープ、時間制限、キャンセル動作を定義します。実際の顧客に通知できない分離されたキュー、テストデータベース、宛先を使用してください。

計算時間をデータベースとストレージの待ちから分離します。ジョブ実行時間 1 つの数値ではこれらの区別が隠れます。ファイル全体をメモリ内で構築する場合と、範囲を限定したバッチをストリーミングする場合ではスケールの仕方が異なります。キューメッセージは、顧客データや資格情報を埋め込まずに作業を記述できる程度に小さく保ってください。

設計上、繰り返し配信を安全にする

永続的なエクスポート識別子を使用して、試行を 1 つの論理結果に関連付けます。一意性と、永続状態における原子的な所有権/完了遷移を強制します。エクスポートが存在するか確認してから別の保護されていない手順で挿入すると、同時試行が競合する可能性があります。オブジェクトを公開してキューメッセージを確認応答することも、障害境界を形成します。

# Illustrative contract, not queue implementation
job_type: export-account-report
logical_result: EXPORT_RECORD_ID
input_scope: AUTHORIZED_ACCOUNT_AND_DATE_RANGE
attempt_limit: REVIEWED_FINITE_LIMIT
completion: ONE_PUBLISHED_RESULT_FOR_THIS_EXPORT
retry: CLASSIFIED_TRANSIENT_FAILURES_ONLY
failed_result: INSPECTABLE_WITHOUT_CUSTOMER_SECRETS

Celery は遅延確認応答を冪等なタスクと結び付け、子プロセス終了後にも確認応答が行われる場合を文書化しています。キューのオプションは exactly-once 実行を生みません。システムの再配信セマンティクスを確認し、アプリケーション結果が再試行を許容するように設計してください。

技術リファレンス: Celery タスクの動作.

プロセスを増やす前に予算を設定する

アクティブなエクスポートごとに 300 MiB を使用する仮想ワーカーの場合、同時エクスポート 4 つでランタイムオーバーヘッド前にすでに約 1,200 MiB を意味します。これらはベンチマークではなく計画入力です。データベース接続、クエリメモリ、一時ディスク、出力帯域幅を加えてください。プロセス数は制限の 1 つにすぎません。

アクティブなエクスポート 1 つと現実的なバックログでリハーサルします。同じ API トラフィックを繰り返しながら 2 つに増やします。完了した有用なエクスポート、最古ジョブの経過時間、レイテンシ、失敗、ホスト圧力を比較します。データベース待ちが増える一方でスループットがほとんど改善しない場合は、同時実行の増加を止めてください。追加 CPU ではそのボトルネックが解消されない可能性があります。

障害がさらなる負荷を生むのを止める

再試行の前にエラーを分類します。一時的なストレージ障害は一時的な可能性があります。未承認のアカウントや未対応のエクスポート形式には、終端エラーまたは介入が必要です。対応している場合は、有限の試行予算と、バックオフとジッターを伴う遅延再試行を使用します。失敗したジョブは機密フィールドを除去して検査可能に保ってください。

外部呼び出しにタイムアウトを適用し、タスク全体の予算を設定します。試行を放棄しても、リモート側の副作用が発生しなかったことの証明にはなりません。タイムアウトした公開処理は、すでに出力を書き込んでいる可能性があります。別の結果を盲目的に公開するのではなく、エクスポートIDで突合してください。

デプロイと復旧にワーカーを含める

文書化されたシャットダウン動作を使用して、古いワーカーでの新規作業を停止します。進行中の作業は完了させるか、既知の期限のもとで安全に中断します。出力が書き込まれた後、完了が記録される前にクラッシュをテストしてください。代替の試行では、結果を重複させるのではなく、一貫した結果を見つける必要があります。

重複するリリース間でメッセージ形式の互換性を保ちます。新しいAPIが、古いワーカーでは読み取れないペイロードをエンキューする可能性があります。契約にバージョンを付け、新しいメッセージが現れる前にサポート対象のコンシューマーが存在するようにロールアウトを順序付けます。これらのデータベースライターを次に含めてください： スキーマ互換性レビュー.

次に変更する制約を選ぶ

同時実行設定、再試行ポリシー、タスク契約、測定された停止ルールを残します。高コストのエクスポートが小規模ジョブを遅延させる場合は、グローバル制限を引き上げる前に、独立した予算を持つ別のキューを検討してください。現実的なエクスポート負荷でAPIレイテンシが悪化する場合は、1台の共有ホストを拡張するよりも、ワーカーを分離する方が有効な場合があります。

変更後に同じワークロードを繰り返し、比較結果を保存します。 APIとワーカー」シナリオ App 2 と追加メモリが選択にどう関与するかを説明します。これらの手順は、マネージドキュー、無制限のジョブ、自動スケーリングを意味するものではありません。