Azure Communication Services のサービス制限
この記事では、Azure Communication Services API の制限事項と考えられる解決策について説明します。
調整パターンとアーキテクチャ
サービスが制限に達した場合は、ユーザーに HTTP 状態コード 429 (要求が多すぎます) が返されます。 一般的に、スロットリングには次のベスト プラクティスが使用されます。
- 要求あたりの操作の数を減らす。
- 呼び出しの頻度を減らします。
- すべての要求が使用制限に加算されるため、すぐに再試行することは避けてください。
調整と制限を処理するようにサービス アーキテクチャを設定する方法に関するより一般的なガイダンスについては、調整パターンに関する Azure Architecture のドキュメントを参照してください。 調整制限を引き上げるには、Azure サポートに要求します。
- Azure portal を開き、サインインします。
- [ヘルプとサポート] を選択します。
- [新しいサポート リクエストを作成します] を選択します。
- [問題の説明] テキスト ボックスに「技術」と入力し、[移動] をクリックします。
- [サービスの選択] ドロップダウン メニューから、[サービスとサブスクリプションの制限 (クォータ)] を選択し、[次へ] を選択します。
- [問題] の説明で、[問題の種類]、[サブスクリプション]、[クォータの種類] 値を選択し、[次へ] を選択します。
- 推奨される解決策が表示された場合はその内容を確認し、[次へ] を選択します。
- 必要に応じて他の詳細を追加し、[次へ] を選択します。
- [確認と作成] で、入力内容を確認し、必要があれば修正した後、[作成] を選択します。
[Azure サポートに要求する] の手順に従います。
電話番号を取得する
電話番号を取得する前に、サブスクリプションが地理的およびサブスクリプションの要件を満たしていることを確認してください。 そうでない場合、電話番号を購入することはできません。 電話番号 SDK と Azure portal を使用した番号の購入には、以下の制限事項が適用されます。
| 操作 | 範囲 | 期間 | 制限 (要求の数) |
|---|---|---|---|
| 電話番号を購入する | Azure テナント | - | 1 |
| 電話番号の検索 | Azure テナント | 1 週間 | 5 |
実行するアクション
詳細については、電話番号の種類とテレフォニーの概念に関するページを参照してください。
番号購入の制限を引き上げるには、Azure サポートに要求します。
- Azure portal を開き、サインインします。
- [ヘルプとサポート] を選択します。
- [新しいサポート リクエストを作成します] を選択します。
- [問題の説明] テキスト ボックスに「技術」と入力し、[移動] をクリックします。
- [サービスの選択] ドロップダウン メニューから、[サービスとサブスクリプションの制限 (クォータ)] を選択し、[次へ] を選択します。
- [問題] の説明で、[問題の種類]、[サブスクリプション]、[クォータの種類] 値を選択し、[次へ] を選択します。
- 推奨される解決策が表示された場合はその内容を確認し、[次へ] を選択します。
- 必要に応じて詳細を追加し、[次へ] を選択します。
- [確認と作成] で、入力内容を確認し、必要があれば修正した後、[作成] を選択します。
ID
| 操作 | 概算時間 (秒) | 制限 (要求の数) |
|---|---|---|
| ID の作成 | 30 | 1,000 |
| ID の削除 | 30 | 500 |
| アクセス トークンの発行 | 30 | 1,000 |
| アクセス トークンの取り消し | 30 | 500 |
createUserAndToken |
30 | 1,000 |
exchangeTokens |
30 | 500 |
実行するアクション
チャット スレッドを作成したり、通話を開始したりする前に、ID とトークンを取得することをお勧めします。 たとえば、Web ページの読み込み時やアプリケーションの起動時にこのタスクを実行します。
詳細については、「Azure Communication Services に対する認証」を参照してください。
sms
大量のメッセージを送信または受信するときに、429 エラーが発生することがあり ます。 このエラーは、まもなくサービスの制限に達することを示しています。 メッセージはキューに入れられ、要求の数がしきい値を下回った後に送信されます。
SMS の転送率の制限:
| 操作 | 数値型 | 範囲 | 概算時間 | 制限 (要求数) | 1 分あたりのメッセージ単位 |
|---|---|---|---|---|---|
| メッセージの送信 | 通話料無料 | 番号あたり | 60 | 200 | 200 |
| メッセージの送信 | ショート コード | 番号あたり | 60 | 6000 | 6000 |
| メッセージの送信 | 英数字送信者 ID | リソースあたり | 60 | 600 | 600 |
実行するアクション
レート制限を超える要件がある場合は、より高いスループットを実現するための要求を Azure サポートに送信します。
SMS SDK とサービスの詳細については、SMS SDK の概要または SMS の FAQ に関するページを参照してください。
メール
送信できる電子メール メッセージの数には制限があります。 サブスクリプションに応じたメールのレート制限を超えた場合、要求が拒否されます。 再試行までの時間が経過した後に、これらの要求をもう一度試すことができるようになります。 必要に応じて、送信ボリュームの制限を引き上げるリクエストを行って、制限に達する前に対処してください。
Azure Communication Services のメール サービスは、高スループットをサポートするように設計されています。 ただし、このサービスには、お客様がオンボードを円滑に行い、新しいメール サービスに切り替えるときに発生する可能性のあるいくつかの問題を回避できるように、初期レート制限が設けられています。
メールの配信状態を注意深く監視しながら、2 週間から 4 週間かけて、Azure Communication Services Email を使用するメールの量を少しずつ増やすことをお勧めします。 このように段階的に増やすと、サード パーティのメール サービス プロバイダーはドメインのメール トラフィック用の IP の変更に適応できます。 少しずつ変更すると、送信者評価を保護し、メール配信の信頼性を維持する時間が得られます。
Azure Communication Services のメール サービスでは、1 時間あたり最大 100 万から 200 万メッセージの大量のメッセージがサポートされます。 高スループットは、次のような複数の要因に基づいて有効にすることができます。
- 顧客のピーク時のトラフィック
- ビジネス ニーズ
- 障害率を管理する機能
- ドメインの評価
失敗率の要件
高いメール クォータを有効にするには、メールの失敗率が 1% 未満である必要があります。 失敗率が高い場合は、クォータの引き上げを要求する前に問題を解決する必要があります。 お客様は、失敗率を積極的に監視する必要があります。
クォータの引き上げ後に失敗率が上がった場合、Azure Communication Services はお客様に連絡して、直ちに対処することを求め、解決のタイムラインを確認します。 極端なケースでは、指定されたタイムライン内で失敗率が管理されない場合、Azure Communication Services は、問題が解決されるまでサービスを減らしたり中断したりする可能性があります。
関連記事
Azure Communication Services には、失敗率の監視と管理に役立つ豊富なログと分析が用意されています。 詳細については、次の記事をご覧ください。
- Azure Communication Services のメールにおける送信者の評判を向上させる
- メールの分析情報
- Azure Monitor の診断設定でログを有効化する
- クイックスタート: メール イベントを処理する
- クイック スタート: 管理クライアント ライブラリを使用して Azure Communication Services のドメイン抑制リストを管理する
Note
制限の引き上げの要求は、「メール ドメインのクォータの引き上げ」の手順に従って行ってください。 クォータの引き上げは、検証済みのカスタム ドメインでのみ利用でき、Azure が管理するドメインではできません。
メールのレート制限
| 操作 | Scope | 時間枠 (分) | 制限 (電子メールの数) | より高い制限が利用可能 |
|---|---|---|---|---|
| 電子メールの送信 | サブスクリプションあたり | 1 | 30 | はい |
| 電子メールの送信 | サブスクリプションあたり | 60 | 100 | はい |
| 電子メールの状態の取得 | サブスクリプションあたり | 1 | 60 | はい |
| 電子メールの状態の取得 | サブスクリプションあたり | 60 | 200 | はい |
次の表に Azure マネージド ドメインの制限を一覧表示します。
| 操作 | Scope | 時間枠 (分) | 制限 (電子メールの数) | より高い制限が利用可能 |
|---|---|---|---|---|
| 電子メールの送信 | サブスクリプションあたり | 1 | 5 | いいえ |
| 電子メールの送信 | サブスクリプションあたり | 60 | 10 | いいえ |
| 電子メールの状態の取得 | サブスクリプションあたり | 1 | 10 | いいえ |
| 電子メールの状態の取得 | サブスクリプションあたり | 60 | 20 | いいえ |
メールのサイズ制限
| Name | 制限 |
|---|---|
| 電子メールの受信者の数 | 50 |
| 電子メール要求の合計サイズ (添付ファイルを含む) | 10 MB |
| サブスクリプションあたりの認証済み接続の最大数 | 250 |
すべてのメッセージ サイズの制限に関して、base64 エンコードによってメッセージのサイズが大きくなることを検討してください。 メッセージの添付ファイルとその他のバイナリ データが Base64 エンコードされた後に発生するメッセージ サイズの増加を考慮して、サイズ値を大きくする必要があります。 Base64 エンコードはメッセージのサイズを約 33% 増加させるため、メッセージ サイズはエンコード前のメッセージ サイズより約 33% 大きくなります。 たとえば、最大メッセージ サイズの値を約 10 MB に指定した場合、実際の最大メッセージ サイズの値は約 7.5 MB になることが予想されます。
10 MB を超える添付ファイルを送信する
最大 30 MB の添付ファイルを電子メールで送信するには、サポート リクエストを行ってください。
30 MB を超える添付ファイルを電子メールで送信する必要がある場合は、この代替ソリューションを使用します。 ファイルを Azure Blob Storage アカウントに格納し、メールにファイルへのリンクを含めます。 Shared Access Signature (SAS) を使用してファイルをセキュリティで保護できます。 SAS を使うと、ストレージ アカウント内のリソースに対してセキュリティ保護された委任アクセスが可能になります。 SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。
Blob Storage アカウントを使用する利点:
- 大規模なファイルを処理できます。
- SAS またはキーを使用して、ファイル アクセスを正確に管理できます。
詳細については、以下を参照してください:
実行するアクション
メール クォータを増やすには、メール ドメインのクォータの引き上げに関する記事の手順に従ってください。
Note
メール クォータの引き上げ要求の評価と承認には最大で 72 時間かかる可能性があります (金曜日の午後に行われる要求は特に時間がかかります)。
チャット
Azure Communication Services はチャットをサポートしています。
チャットのサイズ制限
| Name | 制限 |
|---|---|
| 通話あたりの参加者数 | 250 |
参加者のバッチ: CreateThread |
200 |
参加者のバッチ: AddParticipant |
200 |
ページ サイズ: ListMessages |
200 |
| メッセージ サイズ | 28 KB |
| Azure Bot Service あたりの Azure Communication Services リソースの数 | 1,000 |
チャットのレート制限
| 操作 | 範囲 | 10 秒あたりの制限 | 1 分あたりの制限 |
|---|---|---|---|
| チャット スレッドを作成する | ユーザーあたり | 10 | - |
| チャット スレッドの削除 | ユーザーあたり | 10 | - |
| チャット スレッドの更新 | チャット スレッドごと | 5 | - |
| 参加者の追加または参加者の削除 | チャット スレッドごと | 10 | 30 |
| チャット スレッドの取得またはチャット スレッドの一覧表示 | ユーザーあたり | 50 | - |
| チャット メッセージを取得する | チャット スレッドあたりのユーザーごと | 50 | - |
| チャット メッセージを取得する | チャット スレッドごと | 250 | - |
| チャット メッセージを一覧表示する | チャット スレッドあたりのユーザーごと | 50 | 200 |
| チャット メッセージを一覧表示する | チャット スレッドごと | 250 | 400 |
| 開封確認メッセージを取得する (20 人の参加者の制限) | チャット スレッドあたりのユーザーごと | 5 | - |
| 開封確認メッセージを取得する (20 人の参加者の制限) | チャット スレッドごと | 100 | - |
| チャット スレッドの参加者を一覧表示する | チャット スレッドあたりのユーザーごと | 10 | - |
| チャット スレッドの参加者を一覧表示する | チャット スレッドごと | 250 | - |
| メッセージの送信、メッセージの更新、またはメッセージの削除 | チャット スレッドごと | 10 | 30 |
| 開封確認メッセージを送信する | チャット スレッドあたりのユーザーごと | 10 | 30 |
| 入力インジケーターの送信 | チャット スレッドあたりのユーザーごと | 5 | 15 |
| 入力インジケーターの送信 | チャット スレッドごと | 10 | 30 |
Note
20 名を超える参加者がいるチャット スレッドの場合は、開封確認メッセージと入力インジケーターの機能はサポートされません。
チャットの保存
Azure Communication Services では、チャット スレッドの作成時に設定したアイテム保持ポリシーに従ってチャット メッセージが保存されます。
重要
この記事で説明されている機能は、現在パブリック プレビュー段階にあります。 このプレビュー バージョンはサービス レベル アグリーメントなしで提供されており、運用環境のワークロードに使用することは推奨されません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。
チャット スレッド作成 API の保持ポリシーを使用して、無期限メッセージ保持と自動削除 (30 日から 90 日) のどちらかを選択できます。 また、チャット スレッドに対してアイテム保持ポリシーを未設定にしておくこともできます。
厳格なコンプライアンス要件に従う必要がある場合は、チャット スレッド削除 API を使用してチャット スレッドを削除することをお勧めします。 新しいアイテム保持ポリシーの適用以前に作成されたスレッドは、そのスレッドに適用するポリシーを変更しない限り影響を受けません。
Note
誤ってメッセージを削除した場合、システムでは復元できません。 保持ポリシーによってスレッドが削除された後に、削除されたチャット スレッドに対するサポート リクエストを送信した場合、そのスレッドを取得することはできません。 そのスレッドに関する情報は現在入手できません。 必要な場合、スレッドの作成時点から 30 日以内に、できるだけ早くサポート チケットを開けば対応できることがあります。
音声およびビデオによる通話
Azure Communication Services は、音声およびビデオ通話をサポートしています。
PSTN 通話の制限事項
| Name | 範囲 | なし |
|---|---|---|
| 同時発信呼び出しの既定数 | 番号あたり | 2 |
Note
同時着信呼び出しには制限がありません。 また、送信同時呼び出しの制限を引き上げる要求を Azure サポートに送信することもできます。 審査チームがすべての要求を審査します。
呼び出しの最大制限
| Name | 制限 |
|---|---|
| 参加者数 | 350 |
Calling SDK ストリーミング サポート
Azuer Communication Services Calling SDK では、次のストリーミング構成がサポートされています。
| 制限 | Web | Windows/Android/iOS |
|---|---|---|
| 同時に送信できる発信ローカル ストリームの最大数。 | 1 つのビデオまたは 1 つの画面共有 | 1 つのビデオ + 1 つの画面共有 |
| 同時にレンダリングできる着信リモート ストリームの最大数。 | 9 つのビデオ + 1 つの画面共有 | 9 つのビデオ + 1 つの画面共有 |
Calling SDK ではこれらの制限は適用されませんが、これらの制限を超えるとパフォーマンスが低下する可能性があります。
Calling SDK のタイムアウト
Azure Communication Services Calling SDK では、次のタイムアウトが適用されます。
| アクション | タイムアウト (秒) |
|---|---|
| 参加者を再接続または削除します。 | 120 |
| 通話から新しいモダリティを追加または削除します。 (ビデオまたは画面共有を開始または停止します。) | 40 |
| 通話転送操作に関わるタイムアウト。 | 60 |
| 1:1 通話確立に関わるタイムアウト。 | 85 |
| グループ通話確立に関わるタイムアウト。 | 85 |
| PSTN 通話確立に関わるタイムアウト。 | 115 |
| 1:1 通話のグループ通話への昇格に関わるタイムアウト。 | 115 |
実行するアクション
音声およびビデオの Calling SDK とサービスの詳細については、Calling SDK の概要またはSDK と API の既知の問題に関するページを参照してください。 一部の制限を引き上げる要求を Azure サポートに提出することもできます。 審査チームがすべての要求を審査します。
Job Router
大量の要求を送信または受信するときに、ThrottleLimitExceededException エラーが発生することがあり ます。 このエラーは、まもなくサービスの制限に達することを示しています。 要求の処理に使われるトークン バケットが一定時間後に補充されるまで、要求は失敗します。
Job Router のレート制限
| 操作 | 範囲 | 概算時間 (秒) | 制限 (要求の数) | タイムアウト (秒) |
|---|---|---|---|---|
| 一般的な要求 | リソースあたり | 10 | 1.000 | 10 |
実行するアクション
レート制限を超える量のメッセージを送信する必要がある場合は、acs-ccap@microsoft.com へメールでお問い合わせください。
Teams の相互運用性と Microsoft Graph
Teams 相互運用性シナリオを使用している場合は、おそらく、いくつかの Microsoft Graph API を使用して会議を作成することになります。
Microsoft Graph で提供される各サービスには、それぞれ異なる制限があります。 サービス固有の制限については、この Web ページで詳しく説明しています。
実行するアクション
エラー処理を実装するときに、HTTP エラー コード 429 を使用して調整を検出します。 失敗した応答には、Retry-After 応答ヘッダーが含まれます。 Retry-After 遅延を使用して要求をオフにします。 クライアントが調整されている間も Microsoft Graph がリソースの使用状況を継続的にログに記録するため、調整から回復する最も簡単な方法です。
Microsoft Graph の調整の制限の詳細については、Microsoft Graph のドキュメントを参照してください。