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

# Amazon EventBridge Pipes のバッチ処理と同時実行
<a name="eb-pipes-batching-concurrency"></a>

## バッチ処理動作
<a name="pipes-batching"></a>

EventBridge Pipes は、ソースから、そしてそれをサポートするターゲットへのバッチ処理に対応しています。さらに、バッチ処理からエンリッチメントまでは AWS Lambda および でサポートされています AWS Step Functions。サービスが異なればサポートされるバッチ処理のレベルも異なるため、ターゲットがサポートするバッチサイズよりも大きいバッチサイズのパイプを構成することはできません。例えば、Amazon Kinesis ストリームソースは、最大バッチサイズ 10,000 件のレコードをサポートしますが、Amazon Simple Queue Service は、バッチあたり最大 10 件のメッセージをターゲットとしてサポートします。そのため、Kinesis ストリームから Amazon SQS キューへのパイプは、ソースの最大バッチサイズを 10 に設定できます。

バッチ処理をサポートしないエンリッチメントまたはターゲットを使用してパイプを設定すると、ソースでバッチ処理を有効にすることはできません。

ソースでバッチ処理が有効化されると、JSON レコードの配列がパイプを通過し、サポートされているエンリッチメントまたはターゲットのバッチ API にマッピングされます。[Input transformers](eb-pipes-input-transformation.md) は、配列全体ではなく、配列内の個々の JSON レコードに個別に適用されます。これらの配列の例については、[Amazon EventBridge Pipes ソース](eb-pipes-event-source.md) を参照し、特定のソースを選択してください。パイプは、バッチサイズが 1 の場合でも、サポートされているエンリッチメントまたはターゲットにバッチ API を使用します。エンリッチメントまたはターゲットにバッチ API がないものの、Lambda や Step Functions などの完全な JSON ペイロードを受け取る場合、JSON 配列全体が 1 回のリクエストで送信されます。バッチサイズが 1 の場合でも、リクエストは JSON 配列として送信されます。

パイプがソースでバッチ処理するように設定されていて、ターゲットがバッチ処理をサポートしている場合、エンリッチメントから JSON 項目の配列を返すことができます。この配列は、元のソースよりも短い配列でも長い配列でもかまいません。ただし、配列がターゲットがサポートするバッチサイズよりも大きい場合、パイプはターゲットを呼び出しません。

### サポートされているバッチ処理可能なターゲット
<a name="pipes-batchable-target"></a>


| ターゲット | 最大バッチサイズ | 
| --- | --- | 
| CloudWatch Logs | 10,000 | 
| EventBridge イベントバス | 10 | 
| Firehose ストリーム | 500 | 
| [Kinesis ストリーム] | 500 | 
| Lambda function | 顧客による定義 | 
| Step Functions ステートマシン | 顧客による定義 | 
| Amazon SNS トピック | 10 | 
| Amazon SQS キュー | 10 | 

次のエンリッチメントとターゲットは、バッチイベントペイロード全体を受け取って処理しますが、バッチのサイズではなく、イベントの合計ペイロードサイズによって制約されます。
+ Step Functions ステートマシン (262144 文字)
+ Lambda 関数 (6MB)

### 部分的なバッチ処理失敗
<a name="pipes-partial-batch-failure"></a>

Amazon SQS および Kinesis や DynamoDB などのストリームソースの場合、EventBridge Pipes はターゲット障害の部分的なバッチ障害処理をサポートします。ターゲットがバッチ処理をサポートしていて、バッチの一部のみが成功した場合、EventBridge はペイロードの残りの部分のバッチ処理を自動的に再試行します。最新のエンリッチメントコンテンツの場合、この再試行は、設定されたエンリッチメントの再呼び出しを含め、パイプ全体で行われます。

エンリッチメントの部分的なバッチ障害処理はサポートされていません。

Lambda と Step Functions ターゲットの場合、ターゲットから構造を定義したペイロードを返すことで部分的な障害を指定することもできます。これは再試行が必要なイベントを示しています。

**部分的障害ペイロード構造の例**

```
{ 
  "batchItemFailures": [ 
    {
      "itemIdentifier": "id2"
    },
    {
      "itemIdentifier": "id4"
    }
]
```

この例では、`itemIdentifier` が、元のソースからのターゲットにより処理されるイベントの ID と一致しています。Amazon SQS の場合、これは `messageId` です。Kinesis と DynamoDB の場合、これは `eventID` です。EventBridge Pipes がターゲットからの部分的なバッチ障害を適切に処理するには、これらのフィールドをエンリッチメントによって返される配列ペイロードに含める必要があります。

## スループットと同時実行動作
<a name="pipes-concurrency"></a>

パイプが受信したエンリッチメントまたはターゲットに送信されるすべてのイベントまたはイベントのバッチは、パイプの*実行*と見なされます。`STARTED` 状態のパイプは、ソースからのイベントを継続的にポーリングし、利用可能なバックログと設定されたバッチ設定に応じてスケールアップとスケールダウンを行います。

パイプの同時実行のクォータ、およびアカウントとリージョンごとのパイプ数については、[EventBridge Pipes クォータ](eb-quota.md#eb-pipes-limits) を参照してください。

デフォルトでは、1 つのパイプは、ソースに応じて次の最大同時実行数にスケーリングされます。
+ **DynamoDB** — 同時実行数は、パイプ上で設定されている `ParallelizationFactor` にストリーム内のシャード数を掛けた数まで増加する可能性があります。
+ **Apache Kafka** — 同時実行数は、トピックのパーティション数 (最高 1000) まで増加する可能性があります。
+ **Kinesis** – 同時実行は、パイプで`ParallelizationFactor`設定された にストリーム内のシャードの数を乗算した値まで増加できます。
+ **Amazon MQ** — 5
+ **Amazon SQS** – 1250

最大ポーリングスループットまたは同時実行数の制限をより高くする必要がある場合は、[サポートにお問い合わせください](https://console.aws.amazon.com/support/home?#/case/create?issueType=technical)。

**注記**  
実行制限はベストエフォート型の安全制限と見なされます。ポーリングがこれらの値を下回ることはありませんが、パイプやアカウントがこれらの推奨値よりも高くなる可能性があります。

パイプの実行は、エンリッチメント処理とターゲット処理を含めて最大 5 分に制限されています。この制限を引き上げることはできません。

ソースが厳密に順序付けされたパイプ (Amazon SQS FIFO キュー、Kinesis および DynamoDB Streams、Apache Kafka トピックなど) は、FIFO キューのメッセージグループ ID 数や Kinesis キューのシャード数など、ソースの設定によって同時実行性はさらに制限されます。これらの制約内で順序付けは厳密に保証されるため、順序付けされたソースを持つパイプはこれらの同時実行制限を超えることはできません。