Webhookゲートウェイの制限 ​

リアルタイムトリガー、webhooksコネクターを使用する場合、またはConnector SDKでWebhookトリガーを作成する場合、イベントはジョブになる前にWebhookゲートウェイに送信されます。 WorkatoのWebhookゲートウェイは、ワークスペースレベルで2つの制限を適用します:

• レート制限

• 指定された時間間隔内に送信できるイベント数。

• バイト制限

• 特定の時間間隔内で許可されるWebhookイベントの合計メモリサイズ。

レート制限 ​

Webhookゲートウェイは、イベント処理を効率的に管理するためにレート制限を使用します。 次の制限は、Dev、テスト、ProdなどのEnvironmentごとに適用されます:

リーキーバケットレート制限 ​

Webhookゲートウェイでは、次のプロセスによるリーキーバケット方式を使用します:

• 1秒間に20件を超えるイベントを受信した場合、超過したイベントはバースト許容量を消費します。

• 1秒間に20件未満のイベントを受信した場合、残りの容量はバースト許容量を補充します。ただし、バースト許容量が9,000件未満の場合に限ります。

定常レート（毎秒20件のイベント）とバースト許容量（9,000件のイベント）の両方を超過すると、レートが制限内に戻るまで、Webhookゲートウェイは追加イベントに対して429 Too Many Requestsレスポンスを返します。

シナリオ例 ​

次のシナリオは、Webhookゲートウェイがさまざまな量のイベントをどのように処理するかを示しています:

シナリオ1: 1秒間に25件のイベント ​

1秒間に25件のイベントを受信すると、Webhookゲートウェイは定常レート内で20件のイベントを処理します。 残りの5件のイベントは、バースト許容量の一部を消費します。

シナリオ2: 1秒間に10件のイベント ​

1秒間に10件のイベントを受信した場合、ゲートウェイは10件すべてのイベントを処理します。 未使用の容量（10件のイベント）は、最大制限に達していない場合に限り、バースト許容量を補充します。

シナリオ3: 1秒間に9,050件のイベント ​

このシナリオでは、1秒間に9,050件のイベントを受信します。 ゲートウェイは定常レートで20件のイベントを処理し、次の9,000件のイベントでバースト許容量全体を使い切ります。 残りの30件のイベントでは、定常レートとバースト許容量の両方を超過しているため、429 Too Many Requestsレスポンスが返されます。

バイト制限 ​

当社のWebhookゲートウェイには、すべてのWebhookの合計メモリを表す次のバイト制限があります:

1分あたりのバイト制限とバーストは、レート制限と同じように考えることができます。

レート制限の改訂 ​

各ビジネスには固有のイベント処理ニーズがあることを理解しています。 当社の目標は、お客様固有の要件に合わせた柔軟なレート制限を提供し、お客様の目的を支援することです。

既存のお客様については、毎秒20件のイベントという定常レートや18,000件のイベントのバースト許容量など、以前のドキュメントのバージョンに基づいて、より高いレート制限が設定されている場合があることを認識しています。 当社は、これらのより高い制限を引き続き尊重します。 レート制限に変更がある場合は、事前に通知されます。

標準のレート制限がお客様の要件を満たさない場合は、調整の可能性について当社のサポートチームにお問い合わせください。 当社はお客様と協力して、プラットフォームの安定性を維持しながら、利用状況がビジネス目標に合致するようにします。

Embedded Partner向けの追加情報 ​

共有コネクター機能を使用してコネクターを顧客に配布しているEmbedded Partnerの場合、顧客ワークスペース内の静的Webhookトリガーには、それぞれ独立したWebhookレート制限があります。 たとえば、顧客AのワークスペースへのWebhookイベントは、顧客BのワークスペースのWebhookレート制限にはカウントされません。

Webhookゲートウェイからのレート制限エラーの処理 ​

レート制限を超過すると、WorkatoのWebhookゲートウェイは429エラーで応答します。 これに加えて、WorkatoのWebhookゲートウェイは、次のイベントを正常に送信できるタイミングを把握するのに役立つ5つのヘッダーを、すべてのイベントに対して返します。

• Retry-After: リクエストを再試行する前に待機する秒数。
• X-Rate-Limit-Remaining: ゲートウェイが追加リクエストを拒否する前に送信できるイベント数。 値が0の場合、制限に達したことを示します。 この値が0のときにゲートウェイがリクエストを受け入れた場合、そのリクエストはその時間枠（秒）で受け入れられる最後のリクエストです。
• X-Rate-Limit-Reset: 定常レートが20リクエスト/秒（rps）であると仮定した場合、バーストレート制限がリセットされるまでの秒数。 リクエストがこのレートを下回る場合、許可されたレートと実際のレートの差分がバースト容量を補充します。 たとえば、システムが20rpsを許可し、12rpsを送信した場合、バースト容量が8rps分補充されます。
• X-Byte-Limit-Remaining: 429が返される前に送信できる、すべてのWebhookにわたる累積データ量
• X-Byte-Limit-Reset - バイトバースト許容量が補充されるまでの秒数

APIはこれらのヘッダーを使用して、Webhookイベントをどのように、いつスロットリングするかを把握できます。

Webhookレート制限の例 ​

これらの例では、次の制限を使用します:

• 20rpsの定常レート
• 18,000件のイベントのバースト容量

1,020rpsでは、ゲートウェイは最初の18秒間に18,360件のイベントを受け入れます。 その後は、20rpsのみを受け入れます。 X-Rate-Limit-Remainingの値は18000から0に減少します。 この値は、スロットリング前に受け入れられる最後のリクエスト、およびその後に拒否されるすべてのリクエストで0のままです。

リクエストが均等に分散された状態で1,020rpsで継続する場合、受け入れられたリクエストであっても、X-Rate-Limit-Remainingは0のままです。

X-Rate-Limit-Resetの値は、最初の20件の受け入れられたリクエストでは1から始まり、次の20件では2に増加し、最初の拒否されたリクエストでは900に達します。 18,000件のイベントのバースト容量を20rpsで補充するには900秒かかります。

ゲートウェイは、拒否されたリクエストにのみRetry-Afterを含めます。