

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon MWAA での Apache Airflow のパフォーマンス調整
<a name="best-practices-tuning"></a>

このトピックでは、[Amazon MWAA での Apache Airflow 設定オプションの使用](configuring-env-variables.md) を使用して Amazon Managed Workflows for Apache Airflow 環境のパフォーマンスを調整する方法について説明します。

**Contents**
+ [

## Apache Airflow 設定オプションの追加
](#best-practices-tuning-console-add)
+ [

## Apache Airflow スケジューラー
](#best-practices-tuning-scheduler)
  + [

### パラメータ
](#best-practices-tuning-scheduler-params)
  + [

### 制限
](#best-practices-tuning-scheduler-limits)
+ [

## DAG フォルダー
](#best-practices-tuning-dag-folders)
  + [

### パラメータ
](#best-practices-tuning-dag-folders-params)
+ [

## DAG ファイル
](#best-practices-tuning-dag-files)
  + [

### パラメータ
](#best-practices-tuning-dag-files-params)
+ [

## タスク
](#best-practices-tuning-tasks)
  + [

### パラメータ
](#best-practices-tuning-tasks-params)

## Apache Airflow 設定オプションの追加
<a name="best-practices-tuning-console-add"></a>

環境に Airflow 設定オプションを追加するには、次の手順に従います。

1. Amazon MWAA コンソールで、[環境ページ](https://console.aws.amazon.com/mwaa/home#/environments) を開きます。

1. 環境を選択します。

1. **編集** を選択します。

1. **次へ** を選択します。

1. **Airflow 設定オプション** ペインで **カスタム設定を追加** を選択します。

1. ドロップダウンリストから設定を選択して値を入力するか、カスタム設定を入力して値を入力します。

1. 追加する設定ごとに **カスタム設定を追加** を選択します。

1. **保存** を選択します。

詳細については、[Amazon MWAA での Apache Airflow 設定オプションの使用](configuring-env-variables.md) を参照してください。

## Apache Airflow スケジューラー
<a name="best-practices-tuning-scheduler"></a>

Apache Airflow スケジューラーは Apache Airflow のコアコンポーネントです。スケジューラーに問題があると、DAG の解析やタスクのスケジュール設定ができなくなる可能性があります。Apache Airflow スケジューラーの調整の詳細については、Apache Airflow ドキュメンテーションウェブサイトの [スケジューラーのパフォーマンスのファインチューニング](https://airflow.apache.org/docs/apache-airflow/2.2.2/concepts/scheduler.html#fine-tuning-your-scheduler-performance) を参照してください。

### パラメータ
<a name="best-practices-tuning-scheduler-params"></a>

このセクションでは、Apache Airflow スケジューラー (Apache Airflow v2 以降) で使用できる設定オプションとそのユースケースについて説明します。

------
#### [ Apache Airflow v3 ]


| 設定 | ユースケース | 
| --- | --- | 
|  **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** Celery エグゼキュターがタスクの状態を同期するために使用するプロセスの数です。 **デフォルト:** 1  |  このオプションを使用すると、Celery エグゼキュターが使用するプロセスを制限することでキューの競合を防ぐことができます。デフォルトでは、CloudWatch Logs にタスクログを配信する際にエラーが発生しないように値が `1` に設定されています。この値を `0` に設定すると最大数のプロセスを使用することになりますが、タスクログの配信時にエラーが発生する可能性があります。  | 
|  **[scheduler.scheduler\$1idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#scheduler-idle-sleep-time)** スケジューラーの「ループ」で DAG ファイルが連続して処理されるまでに待機する秒数。 **デフォルト:** 1  |  このオプションを使用すると、DAG 解析結果の取得、タスクの検索とキューへの追加、*エグゼキューター* でのキュー内のタスクの実行が完了した後に、スケジューラーがスリープする時間を **長くする** ことで、スケジューラーの CPU 使用率を解放できます。この値を増やすと、Airflow v2 および Apache Airflow v3 の `dag_processor.parsing_processes` 環境で実行されるスケジューラーのスレッド数が消費されます。これにより、スケジューラーが DAG を解析する容量が減り、DAG がウェブサーバーに取り込まれるのにかかる時間が長くなる可能性があります。  | 
|  **[scheduler.max\$1dagruns\$1to\$1create\$1per\$1loop](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#max-dagruns-to-create-per-loop)** スケジューラー「ループ」ごとに作成する *DagRuns* の DAG の最大数。 **デフォルト**: 10  |  このオプションを使用すると、スケジューラーの「ループ」での *DAGRun* の最大数を **減らす** ことで、タスクのスケジューリングに必要なリソースを解放できます。  | 
|  **[dag\$1processor.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parsing-processes)** スケジューラーが DAG をスケジュールするために並列して実行できるスレッドの数。 **デフォルト:** `(2 * number of vCPUs) - 1` を使用する  |  このオプションを使用すると、スケジューラーが DAG を解析するために並列して実行するプロセスの数を **減らす** ことで、リソースを解放できます。DAG の解析がタスクスケジューリングに影響している場合は、この数を低く抑えることをお勧めします。環境の vCPU 数よりも小さい値を指定する **必要があります**。詳細については、[制限](#best-practices-tuning-scheduler-limits) を参照してください。  | 

------
#### [ Apache Airflow v2 ]


| 設定 | ユースケース | 
| --- | --- | 
|  **[celery.sync\$1parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** Celery エグゼキュターがタスクの状態を同期するために使用するプロセスの数です。 **デフォルト:** 1  |  このオプションを使用すると、Celery エグゼキュターが使用するプロセスを制限することでキューの競合を防ぐことができます。デフォルトでは、CloudWatch Logs にタスクログを配信する際にエラーが発生しないように値が `1` に設定されています。この値を `0` に設定すると最大数のプロセスを使用することになりますが、タスクログの配信時にエラーが発生する可能性があります。  | 
|  **[scheduler.idle\$1sleep\$1time](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#scheduler-idle-sleep-time)** スケジューラーの「ループ」で DAG ファイルが連続して処理されるまでに待機する秒数。 **デフォルト:** 1  |  このオプションを使用すると、DAG 解析結果の取得、タスクの検索とキューへの追加、*エグゼキューター* でのキュー内のタスクの実行が完了した後に、スケジューラーがスリープする時間を **長くする** ことで、スケジューラーの CPU 使用率を解放できます。この値を増やすと、Airflow v2 および Apache Airflow v3 の `scheduler.parsing_processes` 環境で実行されるスケジューラーのスレッド数が消費されます。これにより、スケジューラーが DAG を解析する容量が減り、DAG がウェブサーバーに取り込まれるのにかかる時間が長くなる可能性があります。  | 
|  **[scheduler.max\$1dagruns\$1to\$1create\$1per\$1loop](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#max-dagruns-to-create-per-loop)** スケジューラー「ループ」ごとに作成する *DagRuns* の DAG の最大数。 **デフォルト**: 10  |  このオプションを使用すると、スケジューラーの「ループ」での *DAGRun* の最大数を **減らす** ことで、タスクのスケジューリングに必要なリソースを解放できます。  | 
|  **[scheduler.parsing\$1processes](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes)** スケジューラーが DAG をスケジュールするために並列して実行できるスレッドの数。 **デフォルト:** `(2 * number of vCPUs) - 1` を使用する  |  このオプションを使用すると、スケジューラーが DAG を解析するために並列して実行するプロセスの数を **減らす** ことで、リソースを解放できます。DAG の解析がタスクスケジューリングに影響している場合は、この数を低く抑えることをお勧めします。環境の vCPU 数よりも小さい値を指定する **必要があります**。詳細については、[制限](#best-practices-tuning-scheduler-limits) を参照してください。  | 

------

### 制限
<a name="best-practices-tuning-scheduler-limits"></a>

このセクションでは、スケジューラーのデフォルトパラメータを調整する際に考慮する制限について説明します。<a name="scheduler-considerations"></a>

**scheduler.parsing\$1processes、scheduler.max\$1threads (v2のみ)**  
1 つの環境クラスの vCPU ごとに 2 つのスレッドを使用できます。環境クラスのスケジューラー用に少なくとも 1 つのスレッドを予約する必要があります。タスクのスケジュールが遅れていることに気付いた場合は、[環境クラス](environment-class.md) を増やす必要があるかもしれません。例えば、大規模な環境では、スケジューラ用に 4 vCPU の Fargate コンテナインスタンスがあります。つまり、他のプロセスに使用できるスレッドの `7` 合計は最大数になります。つまり、2 つのスレッドに 4 つの vCPUs を乗算した値から、スケジューラー自体の 1 を引いた値です。`scheduler.max_threads` (v2のみ) および `scheduler.parsing_processes` で指定する値は、環境クラスで使用できるスレッド数 (以下を参照) を超えてはなりません。  
+ **mw1.small** — 他のプロセスの `1` スレッド数を超えてはいけません。残りのスレッドはスケジューラー用に予約されています。
+ **mw1.medium** — 他のプロセスの `3` スレッド数を超えてはいけません。残りのスレッドはスケジューラー用に予約されています。
+ **mw1.large** — 他のプロセスの `7` スレッド数を超えてはいけません。残りのスレッドはスケジューラー用に予約されています。

## DAG フォルダー
<a name="best-practices-tuning-dag-folders"></a>

Apache Airflow スケジューラーは、環境内の DAG フォルダーを継続的にスキャンします。含まれている `plugins.zip` ファイル、または「airflow」インポートステートメントを含む Python (`.py`) ファイル。生成されたすべての Python DAG オブジェクトは *DagBag* に格納され、そのファイルがスケジューラーによって処理され、スケジュールする必要があるタスク (ある場合) が決定されます。DAG ファイルの解析は、そのファイルに実行可能な DAG オブジェクトが含まれているかどうかに関係なく行われます。

### パラメータ
<a name="best-practices-tuning-dag-folders-params"></a>

このセクションでは、DAG フォルダー (Apache Airflow v2 以降) で使用できる設定オプションとそのユースケースについて説明します。

------
#### [ Apache Airflow v3 ]


| 設定 | ユースケース | 
| --- | --- | 
|  **[dag\$1processor.refresh\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#config-dag-processor-refresh-interval)** DAG フォルダーをスキャンして新しいファイルを探す必要のある秒数。 **デフォルト:** 300 秒  |  このオプションを使用すると、DAGs フォルダーを解析する秒数を **増やす** ことでリソースを解放できます。DAG フォルダーに大量のファイルがあることが原因で、`total_parse_time metrics` で解析時間が長くなる場合は、この値を増やすことをお勧めします。  | 
|  **[dag\$1processor.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-file-process-interval)** スケジューラーが DAG を解析して DAG への更新が反映されるまでの秒数。 **デフォルト:** 30 秒  |  このオプションを使用して、DAG を解析する前にスケジューラーが待機する秒数を **増やす** ことで、リソースを解放できます。例えば、`30` の値を指定すると、DAG ファイルは 30 秒ごとに解析されます。お使いの環境の CPU 使用率を下げるには、この数値を高くしておくことをお勧めします。  | 

------
#### [ Apache Airflow v2 ]


| 設定 | ユースケース | 
| --- | --- | 
|  **[scheduler.dag\$1dir\$1list\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-dir-list-interval)** DAG フォルダーをスキャンして新しいファイルを探す必要のある秒数。 **デフォルト:** 300 秒  |  このオプションを使用すると、DAGs フォルダーを解析する秒数を **増やす** ことでリソースを解放できます。DAG フォルダーに大量のファイルがあることが原因で、`total_parse_time metrics` で解析時間が長くなる場合は、この値を増やすことをお勧めします。  | 
|  **[scheduler.min\$1file\$1process\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-file-process-interval)** スケジューラーが DAG を解析して DAG への更新が反映されるまでの秒数。 **デフォルト:** 30 秒  |  このオプションを使用して、DAG を解析する前にスケジューラーが待機する秒数を **増やす** ことで、リソースを解放できます。例えば、`30` の値を指定すると、DAG ファイルは 30 秒ごとに解析されます。お使いの環境の CPU 使用率を下げるには、この数値を高くしておくことをお勧めします。  | 

------

## DAG ファイル
<a name="best-practices-tuning-dag-files"></a>

Apache Airflow スケジューラーループの一部として、個々の DAG ファイルが解析されて DAG Python オブジェクトが抽出されます。Apache Airflow v2 以降では、スケジューラーは同時に最大数の [解析プロセス](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parsing-processes) を解析します。同じファイルが再び解析される前に、`scheduler.min_file_process_interval` (v2) または `dag_processor.min_file_process_interval` (v3) で指定された秒数が経過する必要があります。

### パラメータ
<a name="best-practices-tuning-dag-files-params"></a>

このセクションでは、Apache Airflow DAG ファイル (Apache Airflow v2 以降) で使用できる設定オプションとそのユースケースについて説明します。

------
#### [ Apache Airflow v3 ]


| 設定 | ユースケース | 
| --- | --- | 
|  **[dag\$1processor.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dag-file-processor-timeout)** *DagFileProcessor* が DAG ファイルの処理をタイムアウトするまでの秒数。 **デフォルト:** 50 秒  |  このオプションを使用すると、*DAGFileProcessor* がタイムアウトするまでの時間を **増やす** ことでリソースを解放できます。DAG 処理ログにタイムアウトが発生し、実行可能な DAG が読み込まれなくなる場合は、この値を増やすことをお勧めします。  | 
|  **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#dagbag-import-timeout)** Python ファイルをインポートするまでの秒数がタイムアウトします。 **デフォルト:** 30 秒  |  このオプションを使用すると、Python ファイルをインポートして DAG オブジェクトを抽出する際にスケジューラーがタイムアウトになるまでにかかる時間を **増やす** ことで、リソースを解放できます。このオプションはスケジューラーの「ループ」の一部として処理され、`dag_processor.dag_file_processor_timeout` で指定されている値よりも小さい値が含まれている必要があります。  | 
|  **[core.min\$1serialized\$1dag\$1update\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-update-interval)** データベース内のシリアル化された DAG が更新されるまでの最小秒数。 **デフォルト:** 30  |  このオプションを使用すると、データベース内のシリアル化された DAG が更新されるまでの秒数を **増やす** ことで、リソースを解放できます。DAG の数が多い場合、または複雑な DAG がある場合は、この値を増やすことをおすすめします。この値を増やすと、DAG がシリアル化されるときのスケジューラーとデータベースへの負荷が軽減されます。  | 
|  **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#min-serialized-dag-fetch-interval)** シリアル化された DAG が DAGBag に既に読み込まれているときに、データベースから再フェッチされる秒数。 **デフォルト**: 10  |  このオプションを使用すると、シリアル化された DAG を再フェッチする秒数を **増やす** ことでリソースを解放できます。データベースの「書き込み」速度を下げるには、この値を `core.min_serialized_dag_update_interval` で指定した値より大きくする必要があります。この値を増やすと、DAG がシリアル化される際のウェブサーバーとデータベースの負荷が軽減されます。  | 

------
#### [ Apache Airflow v2 ]


| 設定 | ユースケース | 
| --- | --- | 
|  **[core.dag\$1file\$1processor\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-file-processor-timeout)** *DagFileProcessor* が DAG ファイルの処理をタイムアウトするまでの秒数。 **デフォルト:** 50 秒  |  このオプションを使用すると、*DAGFileProcessor* がタイムアウトするまでの時間を **増やす** ことでリソースを解放できます。DAG 処理ログにタイムアウトが発生し、実行可能な DAG が読み込まれなくなる場合は、この値を増やすことをお勧めします。  | 
|  **[core.dagbag\$1import\$1timeout](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dagbag-import-timeout)** Python ファイルをインポートするまでの秒数がタイムアウトします。 **デフォルト:** 30 秒  |  このオプションを使用すると、Python ファイルをインポートして DAG オブジェクトを抽出する際にスケジューラーがタイムアウトになるまでにかかる時間を **増やす** ことで、リソースを解放できます。このオプションはスケジューラーの「ループ」の一部として処理され、`core.dag_file_processor_timeout` で指定されている値よりも小さい値が含まれている必要があります。  | 
|  **[core.min\$1serialized\$1dag\$1update\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-update-interval)** データベース内のシリアル化された DAG が更新されるまでの最小秒数。 **デフォルト:** 30  |  このオプションを使用すると、データベース内のシリアル化された DAG が更新されるまでの秒数を **増やす** ことで、リソースを解放できます。DAG の数が多い場合、または複雑な DAG がある場合は、この値を増やすことをおすすめします。この値を増やすと、DAG がシリアル化されるときのスケジューラーとデータベースへの負荷が軽減されます。  | 
|  **[core.min\$1serialized\$1dag\$1fetch\$1interval](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#min-serialized-dag-fetch-interval)** シリアル化された DAG が DAGBag に既に読み込まれているときに、データベースから再フェッチされる秒数。 **デフォルト**: 10  |  このオプションを使用すると、シリアル化された DAG を再フェッチする秒数を **増やす** ことでリソースを解放できます。データベースの「書き込み」速度を下げるには、この値を `core.min_serialized_dag_update_interval` で指定した値より大きくする必要があります。この値を増やすと、DAG がシリアル化される際のウェブサーバーとデータベースの負荷が軽減されます。  | 

------

## タスク
<a name="best-practices-tuning-tasks"></a>

Apache Airflow スケジューラーとワーカーはどちらもタスクのキューイングとデキューに関与します。スケジューラーは、解析済みのスケジュール設定が完了したタスクを **なし** ステータスから **スケジュール済み** ステータスに移行します。同じく Fargate のスケジューラーコンテナーで実行されているエグゼキューターは、それらのタスクをキューに入れ、そのステータスを **キューで待機中** に設定します。ワーカーにキャパシティがあると、キューからタスクを取り出してステータスを **実行中** に設定し、その後、タスクが成功したか失敗したかに基づいてステータスを **成功** または **失敗** に変更します。

### パラメータ
<a name="best-practices-tuning-tasks-params"></a>

このセクションでは、Apache Airflow タスクで使用できる設定オプションとそのユースケースについて説明します。

Amazon MWAA がオーバーライドするデフォルトの設定オプションは *赤* でマークされています。

------
#### [ Apache Airflow v3 ]


| 設定 | ユースケース | 
| --- | --- | 
|  **[core.parallelism](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#parallelism)** `Running` のステータスを持つことができるタスクインスタンスの最大数。 **デフォルト:** `(maxWorkers * maxCeleryWorkers) / schedulers * 1.5` に基づいて動的に設定されます。  |  このオプションを使用すると、同時に実行できるタスクインスタンスの数を **増やす** ことでリソースを解放できます。指定する値は、使用可能なワーカーの数にワーカーのタスク密度を掛けた値である必要があります。この値を変更するのは、多数のタスクが「実行中」または「キューで待機中」の状態で停止している場合のみにすることをおすすめします。  | 
|  **[core.execute\$1tasks\$1new\$1python\$1interpreter](https://airflow.apache.org/docs/apache-airflow/3.0.6/configurations-ref.html#execute-tasks-new-python-interpreter)** Apache Airflow が親プロセスをフォークするか、新しい Python プロセスを作成してタスクを実行するかを決定します。 **デフォルト:** `True`  |  `True` に設定すると、Apache Airflow はプラグインに加えた変更を、タスクを実行するために作成された新しい Python プロセスとして認識します。  | 
|  **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA は、このオプションの Airflow ベースインストールをオーバーライドして、自動スケーリングコンポーネントの一部としてワーカーをスケーリングします。 **デフォルト:** 該当なし  |  *このオプションに指定された値はすべて無視されます。*  | 
|  **[celery.worker\$1autoscale](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-autoscale)** ワーカー向けのタスク同時実行性。 **デフォルト:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/mwaa/latest/userguide/best-practices-tuning.html)  |  このオプションを使用すると、ワーカーの `minimum`、`maximum` のタスク同時実行を **減らす** ことでリソースを解放できます。ワーカーは、そのための十分なリソースがあるかどうかに関係なく、構成された `maximum` までの同時タスク受け入れます。十分なリソースがない状態でタスクをスケジュールすると、タスクはすぐに失敗します。リソースを大量に消費するタスクの場合は、タスクあたりの容量を増やすために値をデフォルトより小さくしてこの値を変更することをお勧めします。  | 

------
#### [ Apache Airflow v2 ]


| 設定 | ユースケース | 
| --- | --- | 
|  **[core.parallelism](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#parallelism)** `Running` のステータスを持つことができるタスクインスタンスの最大数。 **デフォルト:** `(maxWorkers * maxCeleryWorkers) / schedulers * 1.5` に基づいて動的に設定されます。  |  このオプションを使用すると、同時に実行できるタスクインスタンスの数を **増やす** ことでリソースを解放できます。指定する値は、使用可能なワーカーの数にワーカーのタスク密度を掛けた値である必要があります。この値を変更するのは、多数のタスクが「実行中」または「キューで待機中」の状態で停止している場合のみにすることをおすすめします。  | 
|  **[core.dag\$1concurrency](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#dag-concurrency)** 各 DAG で同時に実行できるタスクインスタンスの数。 **デフォルト:** 10000  |  このオプションを使用すると、同時に実行できるタスクインスタンスの数を **増やす** ことでリソースを解放できます。例えば、10 個の並列タスクを含む 100 個の DAG があり、すべての DAG を同時に実行したい場合、利用可能なワーカーの数に `celery.worker_concurrency` でのワーカータスクの密度を掛け、それを DAG の数で割って最大並列処理を計算できます。  | 
|  **[core.execute\$1tasks\$1new\$1python\$1interpreter](https://airflow.apache.org/docs/apache-airflow/2.10.3/configurations-ref.html#execute-tasks-new-python-interpreter)** Apache Airflow が親プロセスをフォークするか、新しい Python プロセスを作成してタスクを実行するかを決定します。 **デフォルト:** `True`  |  `True` に設定すると、Apache Airflow はプラグインに加えた変更を、タスクを実行するために作成された新しい Python プロセスとして認識します。  | 
|  **[celery.worker\$1concurrency](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-concurrency)** Amazon MWAA は、このオプションの Airflow ベースインストールをオーバーライドして、自動スケーリングコンポーネントの一部としてワーカーをスケーリングします。 **デフォルト:** 該当なし  |  *このオプションに指定された値はすべて無視されます。*  | 
|  **[celery.worker\$1autoscale](https://airflow.apache.org/docs/apache-airflow-providers-celery/stable/configurations-ref.html#worker-autoscale)** ワーカー向けのタスク同時実行性。 **デフォルト:** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/mwaa/latest/userguide/best-practices-tuning.html)  |  このオプションを使用すると、ワーカーの `minimum`、`maximum` のタスク同時実行を **減らす** ことでリソースを解放できます。ワーカーは、そのための十分なリソースがあるかどうかに関係なく、構成された `maximum` までの同時タスク受け入れます。十分なリソースがない状態でタスクをスケジュールすると、タスクはすぐに失敗します。リソースを大量に消費するタスクの場合は、タスクあたりの容量を増やすために値をデフォルトより小さくしてこの値を変更することをお勧めします。  | 

------