Teams でレートを制限してボットを最適化する

レート制限は、メッセージを特定の最大頻度に制限する方法です。 一般的な原則として、アプリケーションでは、個々のチャットまたはチャネルの会話に投稿するメッセージの数を制限する必要があります。 これにより、最適なエクスペリエンスが確保され、メッセージがユーザーへのスパムとして表示されません。

Microsoft Teams とそのユーザーを保護するために、ボット API は受信要求のレート制限を提供します。 この制限を超えるアプリは、エラー状態を HTTP 429 Too Many Requests 受け取ります。 すべての要求には、メッセージ、チャネル列挙、名簿フェッチの送信など、同じレート制限ポリシーが適用されます。

レート制限の正確な値は変更される可能性があります。アプリケーションは、API が を返すときに適切なバックオフ動作を実装する HTTP 429 Too Many Requests必要があります。

レート制限を処理する

Bot Builder SDK 操作を発行するときに、状態コードを処理Microsoft.Rest.HttpOperationExceptionしてチェックできます。

次のコードは、レート制限の処理の例を示しています。

try
{
    // Perform Bot Framework operation
    // for example, await connector.Conversations.UpdateActivityAsync(reply);
}
catch (HttpOperationException ex)
{
    if (ex.Response != null && (uint)ex.Response.StatusCode ==  429)
    {
        //Perform retry of the above operation/Action method
    }
}

ボットのレート制限を処理したら、指数バックオフを使用して応答を処理 HTTP 429 できます。

応答を処理 HTTP 429 する

一般に、応答を受け取らないように、簡単な予防措置を講じる HTTP 429 必要があります。 たとえば、同じ個人用またはチャネルの会話に対して複数の要求を発行しないようにします。 代わりに、API 要求のバッチを作成します。

429s を処理するには、ランダム ジッターで指数バックオフを使用することをお勧めします。 これにより、複数の要求で再試行時に競合が発生しないようにします。

応答を処理 HTTP 429 したら、一時的な例外を検出する例を確認できます。

注:

エラー コード 429 の再試行に加えて、エラー コード 412502504 も再試行する必要があります。

一時的な例外の検出の例

次のコードは、一時的な障害処理アプリケーション ブロックを使用して指数バックオフを使用する例を示しています。

public class BotSdkTransientExceptionDetectionStrategy : ITransientErrorDetectionStrategy
    {
        // List of error codes to retry on
        List<int> transientErrorStatusCodes = new List<int>() { 429 };

        public bool IsTransient(Exception ex) 
          {
          {
              if (ex.Message.Contains("429"))
                  return true;

              HttpResponseMessageWrapper? response = null;
              if (ex is HttpOperationException httpOperationException)
              {
                  response = httpOperationException.Response;
              }
              else
              if (ex is ErrorResponseException errorResponseException)
              {
                  response = errorResponseException.Response;
              }
              return response != null && transientErrorStatusCodes.Contains((int)response.StatusCode);
          }
    }

一時的な障害処理を使用して、バックオフと再試行を実行できます。 NuGet パッケージの取得とインストールに関するガイドラインについては、ソリューションへの 一時的な障害処理アプリケーション ブロックの追加に関するページを参照してください「一時的な障害処理」も参照してください。

一時的な例外を検出する例を確認したら、指数バックオフの例を参照してください。 障害時に再試行する代わりに、指数バックオフを使用できます。

バックオフの例

レート制限の検出に加えて、指数バックオフを実行することもできます。

次のコードは、指数バックオフの例を示しています。

/**
* The first parameter specifies the number of retries before failing the operation.
* The second parameter specifies the minimum and maximum backoff time respectively.
* The last parameter is used to add a randomized  +/- 20% delta to avoid numerous clients retrying simultaneously.
*/
var exponentialBackoffRetryStrategy = new ExponentialBackoff(3, TimeSpan.FromSeconds(2),
                        TimeSpan.FromSeconds(20), TimeSpan.FromSeconds(1));


// Define the Retry Policy
var retryPolicy = new RetryPolicy(new BotSdkTransientExceptionDetectionStrategy(), exponentialBackoffRetryStrategy);

//Execute any bot sdk action
await retryPolicy.ExecuteAsync(() => connector.Conversations.ReplyToActivityAsync( (Activity)reply) ).ConfigureAwait(false);

このセクションで説明する System.Action 再試行ポリシーを使用して、メソッドの実行を実行することもできます。 参照ライブラリを使用すると、固定間隔または線形バックオフ メカニズムを指定することもできます。

値と戦略を構成ファイルに格納して、実行時に値を微調整および調整します。

詳細については、「 再試行パターン」を参照してください。

また、スレッドごとのボットあたりの制限を使用してレート制限を処理することもできます。

スレッドあたりのボットあたりの制限

スレッドごとのボットごとの制限は、ボットが 1 つの会話で生成できるトラフィックを制御します。 会話は、ボットとユーザー、グループ チャット、またはチーム内のチャネルの間で 1:1 です。 そのため、アプリケーションが各ユーザーに 1 つのボット メッセージを送信する場合、スレッドの制限は調整されません。

注:

  • スレッドの制限である 3600 秒と 1800 操作は、複数のボット メッセージが 1 人のユーザーに送信される場合にのみ適用されます。
  • テナントあたりのアプリあたりのグローバル制限は、1 秒あたり 50 要求 (RPS) です。 そのため、1 秒あたりのボット メッセージの合計数がスレッドの制限を超えてはなりません。
  • サービス レベルでメッセージを分割すると、予想よりも RPS が大きくなります。 制限に近づくことを心配する場合は、 バックオフ戦略を実装する必要があります。 このセクションで提供される値は見積もり専用です。

次の表に、スレッドごとのボットごとの制限を示します。

シナリオ 秒単位の期間 許可される操作の最大数
会話に送信する 1 7
会話に送信する 2 8
会話に送信する 30 60
会話に送信する 3600 1800
会話を作成する 1 7
会話を作成する 2 8
会話を作成する 30 60
会話を作成する 3600 1800
会話メンバーを取得する 1 14
会話メンバーを取得する 2 16
会話メンバーを取得する 30 120
会話メンバーを取得する 3600 3600
会話を取得する 1 14
会話を取得する 2 16
会話を取得する 30 120
会話を取得する 3600 3600

注:

以前のバージョンの TeamsInfo.getMembers API と TeamsInfo.GetMembersAsync API は非推奨になっています。 1 分あたり 5 つの要求に調整され、チームごとに最大 10,000 人のメンバーが返されます。 最新のページ分割された API エンドポイントを使用するように Bot Framework SDK とコードを更新するには、「 チームおよびチャット メンバーの Bot API の変更」を参照してください。

また、すべてのボットのスレッドごとの制限を使用してレート制限を処理することもできます。

すべてのボットのスレッドごとの制限

すべてのボットのスレッドごとの制限は、すべてのボットが 1 つの会話全体で生成できるトラフィックを制御します。 ここでは、ボットとユーザー、グループ チャット、またはチーム内のチャネルの間の 1 対 1 の会話です。

次の表に、すべてのボットのスレッドごとの制限を示します。

シナリオ 秒単位の期間 許可される操作の最大数
会話に送信する 1 14
会話に送信する 2 16
会話を作成する 1 14
会話を作成する 2 16
会話を作成する 1 14
会話を作成する 2 16
会話メンバーを取得する 1 28
会話メンバーを取得する 2 32
会話を取得する 1 28
会話を取得する 2 32

次の手順

関連項目