Amazon MWAA ServerlessではTriggererが存在せずdeferrable modeが機能しない

こんにちは。サービス開発室の武田です。

前回の記事では、Amazon MWAA Serverlessにおけるセンサーの挙動と課金特性を検証しました。 reschedule modeが機能しない こと、 課金はタスクインスタンス毎に最低1分 であることを確認しています。

前回の結論は「poke mode一択」でしたが、ここで気になるのが deferrable mode の存在です。Apache Airflow 2.2で導入されたdeferrable operatorsは、ワーカースロットを解放して効率的にリソースを利用するしくみです。従来のMWAA（プロビジョニング型）ではAirflow 2.7.2以降でサポートされています。

MWAA Serverlessでdeferrable modeを使えれば、defer中は課金されずpoke modeよりコスト効率のよい選択肢になるはずです。

今回はこの仮説を検証してみました。 結論からいうと、deferrable modeはreschedule modeよりもさらに深刻な問題を引き起こします。

deferrable operatorsとは

通常のセンサーとの違い

Airflowのセンサーには3つの待機方式があります。

deferrable modeのしくみ

deferrable operatorsは次のように動作します。

1. タスクが起動し、execute()が呼ばれる
2. execute()内でself.defer()を呼び出す
3. ワーカースロットが解放され、タスクはDEFERRED状態になる
4. Triggerer（asyncioイベントループ）がtriggerを実行し、条件を監視
5. 条件成立時、Triggererがタスクの再開をシグナル
6. 新しいワーカーでタスクが再開され、後処理を実行

ポイントは、ステップ4の Triggerer の存在です。Triggererは軽量な非同期プロセスで、多数のtriggerを並列に実行できます。従来のMWAA（Airflow 2.7.2+）では、AWSがTriggererサービスを自動管理しています。

MWAA Serverlessでの期待

MWAA Serverlessはタスク実行時間に応じた従量課金（$0.08/Hour per task、最低1分）です。deferrable modeが動作すれば、defer中はワーカーが解放されるため課金も停止するはず――というのが検証前の仮説でした。

公式ドキュメントを確認してみた

まず、MWAA Serverlessの公式ドキュメントを確認してみました。

deferrable / triggererに関する記述はありませんでした。これは前回検証したmode: rescheduleと同じパターンです（パラメータの存在自体が言及されていない）。

ただし、deferrableがサポートされていないパラメーター一覧にも載っていないため、受け付けられる可能性はあります。実際に動かして確認するしかありません。

検証環境

前回の記事と同じインフラを使用します。

ワークフロー定義

deferrable: trueを追加したSqsSensorのワークフロー定義です。

test_deferrable_sqs:
  dag_id: test_deferrable_sqs
  schedule: null
  default_args:
    owner: airflow
    start_date: "2024-01-01"
  tasks:
    wait_for_message:
      operator: airflow.providers.amazon.aws.sensors.sqs.SqsSensor
      task_id: wait_for_message
      sqs_queue: https://sqs.us-east-1.amazonaws.com/123456789012/my-queue
      deferrable: true
      poke_interval: 30
      timeout: 900
      wait_time_seconds: 5
      max_messages: 1
      delete_message_on_reception: true

前回のpoke modeテスト（mode: poke）との違いは、deferrable: trueが追加されている点だけです。

検証シナリオ

検証結果

発見: DEFERRED状態に入るがTriggererが動かない

3シナリオすべてで同じパターンが確認されました。

タスクは正常にDEFERRED状態へ遷移します。しかし、その後Triggererによる条件チェックは一切行われず、timeout設定値まで停滞した後FAILEDとなります。

D1: SqsSensor（deferrable × メッセージ事前投入）→ timeout後FAILED

メッセージが すでにキューに存在する状態 で実行しました。

Status: FAILED
DurationInSeconds: 951
StartedAt: 2026-03-03T07:01:39Z
EndedAt:   2026-03-03T07:17:31Z
AttemptNumber: 1

メッセージが事前に投入されているにもかかわらず、 951秒間DEFERRED状態のまま停滞し、最終的にFAILED になりました。

前回のreschedule modeでは、メッセージ事前投入時は最初のpokeでメッセージを検知してSUCCESS（3秒）でした。deferrable modeでは最初のpokeすら行われず、即座にdefer()が呼ばれてDEFERRED状態に入ります。

D2: SqsSensor（deferrable × 3分後メッセージ送信）→ timeout後FAILED

Status: FAILED
DurationInSeconds: 952
StartedAt: 2026-03-03T07:20:44Z
EndedAt:   2026-03-03T07:36:37Z
AttemptNumber: 1

180秒後にメッセージを送信しましたが、Triggererが動いていないためメッセージは消費されません。実行中にSQSキューの状態を確認したところ、メッセージがキューに残ったままでした。

{
    "ApproximateNumberOfMessages": "1",
    "ApproximateNumberOfMessagesNotVisible": "0"
}

poke mode（前回検証）では同条件でSUCCESS・DurationInSeconds=144秒でした。deferrable modeでは FAILED・DurationInSeconds=952秒 と、課金時間は約6.6倍になっています。

D3: S3KeySensor（deferrable × 存在しないキー）→ timeout後FAILED

Status: FAILED
DurationInSeconds: 360
StartedAt: 2026-03-03T07:17:02Z
EndedAt:   2026-03-03T07:23:03Z
AttemptNumber: 1

S3KeySensorでも同じ挙動です。DEFERRED状態に入り、timeout（300秒）後にFAILED。DurationInSeconds=360秒が計上されました。

前回のreschedule modeでは即FAILED（DurationInSeconds=1秒）でした。

3モード比較

これまでの全検証結果を並べます。SqsSensor（3分後メッセージ送信）での比較です。

メッセージ事前投入時の比較も重要です。

deferrable modeは、メッセージがすでに存在する場合でもFAILEDになります。reschedule modeでは「最初のpokeで条件を満たせば成功」という回避策がありました。しかしdeferrable modeではそれすら使えません。

なぜこうなるのか

Triggererが存在しない

MWAA Serverlessには Triggererプロセスが存在しません。

従来のMWAA（プロビジョニング型）では、Airflow 2.7.2以降でAWSがTriggererサービスを自動管理しています。しかし、MWAA Serverlessは従来のMWAAとは根本的に異なるアーキテクチャを採用しており、各タスクをマネージドなコンピュート環境で独立実行します。この環境にはTriggererプロセスが含まれていません。

結果として、次の流れが発生します。

1. タスクが起動（マネージドコンピュート環境）
2. SqsSensor.execute()が呼ばれる
3. deferrable=trueのため、即座にself.defer()を呼び出す
   → ここでポーリングは行われない
4. タスクがDEFERRED状態に遷移
5. Triggererが存在しないため、triggerが実行されない
   → SQSキューのメッセージはチェックされない
6. DEFERRED状態のまま停滞
7. timeout後にFAILED

reschedule modeとの違い

reschedule modeは 最初のpokeを実行してから 再スケジュールを試みます。そのため、最初のpokeでメッセージを検知すればSUCCESSになりますし、検知できなければ即FAILEDになります。失敗は高速です。

一方、deferrable modeは 最初のpokeすら行わず、即座にdefer()を呼び出します。そのため、メッセージがすでにキューにあっても検知できません。Triggererが存在しないためDEFERRED状態は解消されず、timeoutまでの全時間も課金対象です。

DurationInSecondsへの計上

DEFERRED状態の間もDurationInSecondsにカウントされます。実際の検証結果で確認できます。

いずれもtimeout設定値に近い値が計上されています。タスクが実際に何も処理していなくても、DurationInSeconds（＝課金対象時間）は積み上がります。reschedule modeは「すぐ失敗する」ため被害は最低1分ぶんの課金に限られます。しかしdeferrable modeは「timeoutまで停滞し続ける」ため、timeout=900秒の設定なら約15分ぶんの無駄な課金が発生します。

まとめ

MWAA Serverlessではdeferrable: trueを設定してはいけません。

reschedule modeに続き、deferrable modeも「パラメータは受け付けるが実行時に機能しない」というパターンでした。しかもdeferrable modeの方が深刻で、高速に失敗するreschedule modeと異なり、timeoutまでの全時間にわたって無駄な課金が発生します。

あらためて強調しますが、 MWAA Serverlessでセンサーを使う場合はpoke mode一択です。（2026年3月時点）

この制約は公式ドキュメントに明記されていないため、従来のMWAAからの移行時は特に注意してください。

参考リンク

• Amazon MWAA Serverless ユーザーガイド
• MWAA Serverless サポートオペレータ一覧
• MWAA Serverless Airflowパラメータサポート
• Introducing Amazon MWAA support for Apache Airflow version 2.7.2 and deferrable operators（AWS Blog）
• Apache Airflow Deferrable Operators（Airflow公式ドキュメント）