Amazon CodeCatalyst は新規のお客様には提供されなくなりました。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、「[CodeCatalyst から移行する方法](migration.md)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 実行のキュー動作の構成
Amazon CodeCatalyst のデフォルトでは、複数のワークフロー実行が同時に発生すると、CodeCatalyst がそれらをキューに入れ、開始された順序で 1 つずつ処理します。このデフォルトの動作は、*実行モード*を指定することで変更できます。以下の実行モードがあります。
+ (デフォルト) キュー実行モード – CodeCatalyst は実行を 1 つずつ処理します。
+ 優先実行モード – CodeCatalyst は実行を 1 つずつ処理し、新しい実行が古い実行を追い越します。
+ 並列実行モード – CodeCatalyst は複数の実行を並列で処理します。
ワークフロー実行の詳細については、「[ワークフローの実行](workflows-working-runs.md)」を参照してください。
**Topics**
+ [キュー実行モードについて](#workflows-configure-runs-queued)
+ [優先実行モードについて](#workflows-configure-runs-superseded)
+ [並列実行モードについて](#workflows-configure-runs-parallel)
+ [実行モードの構成](#workflows-configure-runs-configure)
## キュー実行モードについて
*キュー実行モード*では、実行は順番に行われ、待機中の実行がキューを形成します。
アクションとアクショングループへのエントリポイントでキューが形成されるため、*同じワークフロー内に複数のキュー*を含めることができます (「[Figure 1](#figure-1-workflow-queued-run-mode)」を参照)。キューに入れられた実行がアクションに入ると、アクションはロックされ、他の実行は入れなくなります。実行が終了してアクションを終了すると、アクションのロックが解除され、次の実行の準備が整います。
[Figure 1](#figure-1-workflow-queued-run-mode) は、キュー実行モードで構成されたワークフローを示しています。以下が示されています。
+ ワークフローを通過する 7 つの実行
+ 2 つのキュー: 1 つは入力ソース (**Repo:main**) に入る前のキュー 、もう 1 つは **BuildTestActionGroup** アクションに入る前のキュー
+ 2 つのロックされたブロック: 入力ソース (**Repo:main**) と **BuildTestActionGroup**
ワークフロー実行の処理が終了する時の動作は次のようになります。
+ **Run-4d444** がソースリポジトリのクローン作成を終了すると、入力ソースを出てキューで **Run-3c333** の後ろに入ります。次に、**Run-5e555** が入力ソースに入ります。
+ **Run-1a111** が構築とテストを終了すると、**BuildTestActionGroup** アクションを出て **DeployAction** アクションに入ります。次に、**Run-2b222** が **BuildTestActionGroup** アクションに入ります。
**図 1**: 「キュー実行モード」で構成されたワークフロー
![\[「キュー実行モード」で構成されたワークフロー\]](http://docs.aws.amazon.com/ja_jp/codecatalyst/latest/userguide/images/flows/RunMode-Queued.png)
次の場合はキュー実行モードを使用します。
+ **機能と実行の間で 1 対 1 の関係を維持したい (これらの機能は優先モードを使用する場合にグループ化されることがある)**: 例えば、コミット 1 で機能 1 をマージすると実行 1 が開始され、コミット 2 で機能 2 をマージすると実行 2 が開始され、その後も同様に続いていきます。キューモードの代わりに優先モードを使用する場合、機能 (およびコミット) は他よりも優先される実行でグループにまとめられます。
+ **並列モードを使用する際に発生する可能性のあるレース条件や予期しない問題を回避したいと考えている**: 例えば、Wang と Saanvi の 2 人のソフトウェアデベロッパーが、ワークフローをほぼ同時に開始して Amazon ECS クラスターにデプロイする場合、Wang の実行はクラスターで統合テストを開始し、Saanvi の実行は新しいアプリケーションコードをクラスターにデプロイするため、Wang のテストが失敗するか、間違ったコードをテストする可能性があります。別の例として、ロックメカニズムを持たないターゲットがある場合、2 つの実行が予期しない方法で互いの変更を上書きする可能性があります。
+ CodeCatalyst が実行の処理に使用するコンピューティングリソースの**負荷を制限したい**: 例えば、ワークフローに 3 つのアクションがある場合、同時に最大 3 つの実行を走らせることができます。一度に走らせることができる実行数の上限を設定すると、実行スループットを予測しやすくなります。
+ ワークフローによって**サードパーティーのサービスに対して行われたリクエストの数を制限したい**: 例えば、Docker Hub からイメージをプルする手順を含むビルドアクションがワークフローにある場合があります。アカウントごとに 1 時間で実行できる[プルリクエストの数は Docker Hubによって制限されており](https://www.docker.com/increase-rate-limits)、制限を超えるとロックアウトされます。キュー実行モードを使用して実行スループットを遅くすると、Docker Hub へのリクエストが 1 時間あたりに生成される回数が少なくなり、ロックアウトやビルドおよび実行の失敗が発生する可能性が低くなります。
**最大キューサイズ**: 50
**[最大キューサイズ]** に関する注意事項:
+ 最大キューサイズとは、ワークフロー内の*すべてのキュー*を合算して許可されている実行の最大数を指します。
+ キュー内の実行数が 50 件を超えると、CodeCatalyst では 51 件目以降の実行が削除されます。
**失敗動作**:
アクションによって処理されている間に実行が応答しなくなった場合、その実行の後の実行は、アクションがタイムアウトするまでキューに保持されます。アクションは 1 時間後にタイムアウトします。
アクション内で実行が失敗した場合、その後にあるキューの先頭の実行の続行が許可されます。
## 優先実行モードについて
*優先実行モード*は*キュー実行モード*と同じですが、以下のような違いがあります。
+ キューに入れられている実行がキュー内の別の実行に追いついた場合、後続の実行が前の実行よりも優先 (引き継ぎ) され、前の実行がキャンセルされて「優先済み」としてマークされます。
+ 最初の箇条書きで説明されている動作の結果として、優先実行モードが使用されている場合にキューに含められる実行は 1 つだけとなります。
[Figure 1](#figure-1-workflow-queued-run-mode) のワークフローを参考として使用し、このワークフローに優先実行モードを適用すると、次のような結果になります。
+ **Run-7g777** はキュー内の他の 2 つの実行より優先され、これが **Queue \$11** に残る唯一の実行になります。**Run-6f666** と **Run-5e555** はキャンセルされます。
+ **Run-3c333** は **Run-2b222** より優先され、**Queue \$12** に残る唯一の実行になります。**Run-2b222** はキャンセルされます。
以下が必要な場合に優先実行モードを使用します。
+ キューモードよりも高いスループット
+ キューモードよりもサードパーティーサービスへのリクエストの数を少なくする (Docker Hub などのサードパーティーサービスにレート制限がある場合に便利)
## 並列実行モードについて
*並列実行モード*では、実行は互いに独立しており、他の実行が完了するまで待たずに開始します。キューはなく、ワークフロー内のアクションが完了するまでにかかる速度にのみ実行スループットが制限されます。
ユーザーごとに独自の機能ブランチがあり、他のユーザーと共有していないターゲットにデプロイする開発環境で並列実行モードを使用します。
**重要**
本番環境の Lambda 関数など、複数のユーザーがデプロイできる共有ターゲットがある場合は、競合状態が発生する可能性があるため、並列モードを使用しないでください。並列ワークフロー実行が共有リソースを同時に変更しようとしたときに*競合状態*が発生し、予測不可能な結果につながります。
**並列実行の最大数**: CodeCatalyst スペースあたり 1,000
## 実行モードの構成
実行モードは、キュー実行モード、優先実行モード、または並列実行モードに設定できます。デフォルトはキュー実行モードです。
実行モードをキュー実行モードまたは優先実行モードから並列実行モードに変更すると、CodeCatalyst ではキューに入っている実行をキャンセルし、アクションによって現在処理されている実行をキャンセルする前に完了することが許可されます。
実行モードを並列実行モードからキュー実行モードまたは優先実行モードに変更すると、CodeCatalyst では現在実行中のすべての並列実行を完了できます。実行モードをキュー実行モードまたは優先実行モード変更した後に開始した実行では、新しいモードが使用されます。
------
#### [ Visual ]
**ビジュアルエディタを使用して実行モードを変更するには**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。
1. プロジェクトを選択します。
1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。
1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。
1. **[編集]** を選択します。
1. 右上の **[ワークフローのプロパティ]** を選択します。
1. **[詳細]** を展開し、**[実行モード]** で次のいずれかを選択します。
1. **キュー** - 「[キュー実行モードについて](#workflows-configure-runs-queued)」を参照
1. **優先** - 「[優先実行モードについて](#workflows-configure-runs-superseded)」を参照
1. **並列** – 「[並列実行モードについて](#workflows-configure-runs-parallel)」を参照
1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。
1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
------
#### [ YAML ]
**YAML エディタを使用して実行モードを変更するには**
1. [https://codecatalyst.aws/](https://codecatalyst.aws/) で CodeCatalyst コンソールを開きます。
1. プロジェクトを選択します。
1. ナビゲーションペインで **[CI/CD]**、**[ワークフロー]** の順に選択します。
1. ワークフローの名前を選択します。ワークフローが定義されているソースリポジトリまたはブランチ名でフィルタリングすることも、ワークフロー名またはステータスでフィルタリングすることもできます。
1. **[編集]** を選択します。
1. **[YAML]** を選択します。
1. `RunMode` プロパティを次のように追加します。
```
Name: Workflow_6d39
SchemaVersion: "1.0"
RunMode: QUEUED|SUPERSEDED|PARALLEL
```
詳細については、「[ワークフロー YAML 定義](workflow-reference.md)」の「[最上位プロパティ](workflow-reference.md#workflow.top.level)」セクションの `RunMode` プロパティの説明を参照してください。
1. (省略可) **[検証]** を選択して、ワークフローの YAML コードをコミットする前に検証します。
1. **[コミット]** を選択し、コミットメッセージを入力し、再度 **[コミット]** を選択します。
------