Azure APIの制限とスロットリングの概要

Azure Resource Managerは、以下のレベルで管理APIリクエストをスロットリングします：

• サブスクリプションおよびテナントレベル

• リソースプロバイダーのレベル（例えば、コンピュートリソースプロバイダー）

Azure Virtual DesktopとNerdio Managerは、Microsoft Graph API経由で基盤となるAzure Resource Managerを利用し、APIの制限とスロットリングの対象となります。理論的には多くの異なるタイプのAPI制限が適用される可能性がありますが、このトピックは特にAVDに関連する制限に焦点を当てています。

API制限は、リクエストを行うセキュリティプリンシパル（ユーザーまたはアプリケーション）およびサブスクリプションIDに適用されます。一部のVM API制限は、特定のAzureリージョンに適用されます。そのため、サブスクリプション、リージョン、セキュリティプリンシパルが増えると、全体のAPI制限も上がります。

API制限について詳しく知るには、以下のMicrosoftリソースを参照してください：

• エンタープライズ向けAzure Virtual Desktop - 考慮事項と制限

• Azure Resource Manager APIスロットリング - サブスクリプションおよびテナント制限

• Azureサブスクリプションおよびサービス制限 - API管理制限

Nerdio ManagerがAPIを利用する方法

通常の運用時に、Nerdio ManagerはAzureへAPIコールを行い、各種操作を実施します。

• インタラクティブなUIの使用：Nerdio Managerユーザーがさまざまなページを移動し、ブラウザーを更新する際に、API経由でVMおよびAVDの値を更新します。インタラクティブなUIによるAPIの利用量は比較的少ないです。

• オートスケーリングが有効な場合、Nerdio Managerはデフォルトで5分ごとにホストプール内のVMおよびセッションホストの状態を確認するため、APIを利用します。この操作は、ホストプールごとにバックグラウンドで行われます。ホストプールの数が多く、各ホストプールに多くのVMがあるほど、環境の状態を確認するために使用するAPIコールの数も増加し、自動スケールの判断に影響します。

• 停止したVMの自動割り当て解除: ユーザーがデスクトップでWindowsをシャットダウンすると、VMは停止状態ですが、割り当て解除されていない状態になります。これは、VMがアクセスできないにもかかわらず、計算コストメーターがまだ動作していることを意味します。Nerdio Managerは、そのようなホストを自動的に検出し、コストを節約するために割り当て解除します。VM割り当て解除サービスは、バックグラウンドで10分ごと（デフォルト）に実行され、割り当て解除するVMをスキャンします。

• 各ホストプールの自動スケール操作中、Nerdio ManagerはCPU、RAM、AVDセッションの利用状況を自動的に収集し、有用な自動スケール履歴グラフを生成します。

• スケジュールされたタスク: Nerdio Managerのほとんどのタスクは、対話的ではなく、スケジュールに沿って実行するよう設定できます。例えば、ホストプールの再イメージ化は、真夜中に実行するよう設定できます。VMの再イメージ化中、Nerdio Managerはその間にAPIコールを多く使用します。

• その他: 次のアクションは少量のAPIコールを消費します:

  • Azure FilesおよびAzure NetApp Filesの自動スケーリング

  • メール通知

API使用の最適化に関する推奨事項

• 複数のAzureサブスクリプションを使用する

  • もし展開されているVMが2500台を超える場合、各サブスクリプションで最大2500台までを収容できるよう、展開を複数のAzureサブスクリプションに分けてください。

  • ハブ・スポークアーキテクチャを使用し、仮想ネットワークピアリングを通じて接続します。

  • VMがデプロイされているサブスクリプション内にFSLogixストレージを作成し、仮想ネットワークピアリングリンクを経由する過剰なネットワークトラフィックを避けます。

  • 単一のホストプールが複数のサブスクリプションにまたがることを避けてください（2つのサブスクリプションに同じホストプール内のVMが存在する場合）。

  • Nerdio Managerは、複数のサブスクリプションにまたがるAVD展開を管理できます。

• 異なるAzureリージョンを使用してください。

  • Azure APIのVM操作に関する制限はリージョンごとに異なります。リージョンが多いほど、API制限も高くなります。

  • 1つのサブスクリプションで2500台以上のVMを使用する場合は、異なるリージョンにVMを展開してください。

  • 組み込みのActive/ActiveホストプールDRを使用して、VMを2つのサブスクリプションに分散してください。詳細については、ホストプールの災害復旧を参照してください。

• SQL DBサイズの増加: 詳細については、Nerdio Managerを大規模な展開のためにスケールアップします。を参照してください。

• UI APIの最適化を適用: 詳細については、Nerdio Managerを大規模な展開のためにスケールアップします。を参照してください。

• App Service プランのサイズを増加: 詳細については、Nerdio Managerを大規模な展開のためにスケールアップします。を参照してください。

• VMデアロケーターサービスの調整: VMデアロケーターサービスによるAPIコールの数を減らすため、次のいずれかのオプションを選んでください。

  • ユーザーがWindowsをシャットダウンしても問題ない場合（例：ローカル管理者権限がない場合）、VMデアロケーターを全体的に無効にしてください。App Service 設定VmDeallocator:EnabledをFalseに設定してください。詳細については、高度な App Service の構成を参照してください。

  • VMデアロケーターサービスが実行される頻度を減らしてください。App Service 設定VmDeallocator:RepeatIntervalInMinutesを60または240分に設定してください（既定は10分です）。これにより、VMデアロケーターは実行頻度が下がり、API呼び出しの回数も減少します。詳細については、高度な App Service の構成を参照してください。

  • 一部のホストプールでのみ利用する場合は、必要なホストプールはそのままにして、不要なホストプールでは VMデアロケーターを無効にしてください。Nerdio Managerで、ホストプール > プロパティ > VM デプロイメントに移動し、電源オフだが割り当て解除されていない VM の「割り当て解除」のチェックを外してください。

• リソースグループをホストプールに合わせる: 複数のリソースグループにまたがる VM を含むホストプールは避けてください。最適な API 利用のため、リソースグループとホストプールは1対1に合わせるようにしてください。

• 自動スケール間隔を調整する: デフォルトでは、自動スケールプロセスは各ホストプールごとに5分ごとに実行されます。自動スケールバックグラウンドサービスの実行頻度を減らしてください。App Service 設定のAutoScale:RepeatIntervalInMinutesを10または15分に設定してください。詳細については、高度な App Service の構成を参照してください。

• 自動スケールの同時実行数を調整する: デフォルトでは、10のホストプールが同時に自動スケールによって処理されます。AutoScale:MaxAutoScaleProcesses App Service 設定を調整してください。詳細については、高度な App Service の構成を参照してください。

• 新しいVM作成の同時実行数を調整する: デフォルトでは、新しいVMがホストプールに追加されると、最大同時ジョブ数は100です。忙しいAzureサブスクリプションでは、これが他のバックグラウンドタスクに負担をかける可能性があります。VM作成プロセス中に API を過剰に消費しないように、Provision:MaxAddNewVMJobsCount App Service 設定を25または50に調整してください。詳細については、高度な App Service の構成を参照してください。

• 再イメージ時のバッチサイズを考慮する: ホストプールを再イメージ化する際に、同時に処理するホストの数を指定できます。再イメージ化のウィンドウ中に実行されている可能性のあるすべてのバックグラウンドタスクを考慮し、それに応じてバッチサイズを設定してください。

• 自動スケールおよび新しいVMプロビジョニングのための「再起動」試行を調整する: Nerdio Managerが自動スケールまたはVM作成操作中にAzureエラーに遭遇した場合、ジョブは一時停止し、数分後に再試行します。既定の再試行回数は2です。API上限に達して API スロットリングが発生する大規模な環境では、再試行回数を4または5に増やすことを検討してください。App Service 設定のAutoScale:RestartAttemptsおよびProvision:MaxRestartAttemptsを調整してください。詳細については、高度な App Service の構成を参照してください。