この記事では、Azure アプリ Service での web アプリスケーリングに関する一般的な質問に回答します。
この記事で Azure の問題に対処できない場合は、MSDN および Stack Overflow の Azure 関連フォーラムを参照してください。 問題をこれらのフォーラムに投稿するか、または Twitter の @AzureSupport に投稿できます。 Azure サポート要求を送信することもできます。 サポート要求を送信するには、[Azure サポート] ページで [サポートを受ける] を選択します。
Web アプリ操作方法スケールアップしますか?
Azure ポータルを使用して、Web アプリをスケールアップできます。 Web アプリ ページで、左側のメニューから Scale Up (App Service プラン) を選択します。 詳しくは、「Azure App Service でアプリをスケールアップする」を参照してください。
Free App Service プランをスケールアップする前に、さらに実行する必要があるアクションはありますか?
App Service プランを Free レベルから切り替える前に、Azure サブスクリプションの 保留中の制限 を削除する必要があります。 Microsoft Azure アプリ Service サブスクリプションのオプションを表示または変更するには、「Microsoft Azure サブスクリプション - 使用制限の削除を参照してください。
Web アプリをスケーリングするときのインスタンス制限はありますか?
はい。制限は App Service プランのレベルによって異なります。 詳細については、「 App Service の制限」を参照してください。
10 を超えるインスタンスに対して Standard App Service プランをスケーリングできますか?
Standard App Service プラン レベルでは、10 個を超えるインスタンスがサポートされていません。 Premium App Service プランに移行すると、App Service プランごとに 30 個のインスタンス (選択したリージョン) を使用できるという利点を得ることができます。 価格レベルごとのインスタンス制限を確認するには、「 App Service の制限を参照してください。
異なる数のインスタンスで同じ App Service プランで App Services を構成できますか?
これを構成するには、アプリごとのスケーリングを有効にし、App Service の numberOfWorkers プロパティを目的のインスタンス数に変更します。 詳細については、「 Per-App Scaling」を参照してください。
Web アプリのスケールアップによって、別の Web アプリのスケールアップもトリガーされるのはなぜですか?
スケーリングは、App Service プラン全体で行われます。 同じ App Service プランで複数の App Services をホストする場合、この App Service プラン内のすべての App Services がスケールアップされます。
自動スケールが期待どおりに機能しないのはなぜですか?
"フラッピング" による無限ループを回避するために、意図的にスケーリングしないことを選択するシナリオが発生している可能性があります。通常、この動作は、スケールアウトしきい値とスケールインしきい値の間に十分なマージンがない場合に発生します。 "フラッピング" やその他の自動スケールのベスト プラクティスを回避する方法の詳細については、「 自動スケールのベスト プラクティスを参照してください。
自動スケール ルールによってスケーリングがトリガーされたタイミングを決定操作方法。
アクティビティ ログからスケール履歴を取得できます。 リソースをスケールアップ/スケールダウンするたびに、アクティビティ ログにイベントが記録されます。 [実行履歴]タブに切り替えることで、過去 24 時間のリソースのスケール履歴表示できます。完全なスケール履歴 (最大 90 日間) を表示するには、ここをクリックして詳細を表示します。 詳細については、「 リソースのスケール履歴を表示するを参照してください。
自動スケールが部分的にしかスケーリングされないのはなぜですか?
メトリックが事前に構成された境界を越えると自動スケールがトリガーされます。 キャパシティが期待値に対して部分的にのみ満たされる場合があります。 この動作は、必要なインスタンスの数が使用できない場合に発生する可能性があります。 そのシナリオでは、自動スケーリングによって、使用可能なインスタンス数が部分的に入力されます。 次に、自動スケールは再調整ロジックを実行し、キャパシティを増やします。 残りのインスタンスが割り当てられます。この割り当てには数分かかる場合があります。 数分後に期待するインスタンス数が表示されない場合、部分的リフィルが境界内にメトリックを表示するのに十分であったための可能性があります。 または、低いメトリック境界に達したため、自動スケールがスケールダウンされた可能性があります。
App Service プランを Premium V3 レベルにスケールアップすると、"Premium V3 はこのスケール ユニットではサポートされていません。 アプリの再デプロイまたは複製を検討してください。 エラーが発生します。 どうすればよいですか。
Premium V3 機能では、サイトを最新のハードウェア インフラストラクチャで実行する必要があります。 App Service プランを Premium V3 にスケールアップするには、PremiumV3 をサポートする App Service デプロイで Web アプリが実行されている必要があります。 詳細については、「 サポートされていないリソース グループとリージョンの組み合わせからスケールアップするを参照してください。
「過去 1 時間以内にスケール変更の最大量を超えました (XX の変更と制限は XX)」エラーが原因で、App Service プランをスケールアップまたはスケールダウンできません。 どうすればよいですか。
この問題を回避するには、1 時間以内に XX インスタンスを超えるインスタンスを解放するスケーリング操作を実行しないでください。 スケールダウン操作中にインスタンスを解放するたびに、インスタンスが再起動され、次の App Service プランでクリーンなインスタンスを取得できるようになります。 連続して実行するスケーリング操作が多すぎると、インスタンスの再起動によって他の App Services のパフォーマンスの問題が発生する可能性があります。 そのため、スケーリングの調整メカニズムを意図的に設定して、許容される制限を超えるスケーリング操作を連続して実行できないようにします。
Web アプリで診断設定 "AppServiceFileAuditLogs" が使用されており、App Service プランを Premium V2 から Basic レベルにスケーリングできません。 どうすればよいですか。
ファイル変更監査ログ "AppServiceFileAuditLogs" は、Premium、PremiumV2、Isolated App Service プランの App Services でのみ使用できます。 "AppServiceFileAuditLogs" が必要な場合、Basic レベルにスケールダウンすることはできません。 これらの監査ログを使用できるようにするには、Premium 以上のレベルの App Service プランを構成します。
"3 人未満のワーカーを持つ App Service プランでは、ゾーンの冗長性が許可されていません。 要求されたワーカー数: number" エラー。 どうすればよいですか。
可用性ゾーンのサポート には少なくとも 3 つのインスタンスが必要です。 App Service プランでゾーン冗長が有効になっているかどうか、および App Service プランで自動スケールが有効になっているかどうかを確認します。 その場合は、インスタンスの数を 3 未満の値に設定しないように自動スケール ルールを修正します。
お問い合わせはこちらから
ご質問がある場合は、 Azure コミュニティサポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。