適用対象: Basic | Basic v2 | Standard | Standard v2 | Premium | Premium v2
Azure API Management サービス インスタンスは、一連の規則に基づいて自動的にスケーリングできます。 この動作は、Azure Monitor の自動スケーリングで有効にし、構成することができます。
この記事では、自動スケールの構成手順を説明し、自動スケール規則の最適な構成を提案します。
注
- 複数のスケール ユニットをサポートするサービス レベルでは、API Management インスタンスを手動でスケーリングすることもできます。
- 従量課金レベルの API Management サービスは、トラフィックに基づいて自動的にスケーリングされ、追加の構成は不要です。
重要
API Management サービスのインフラストラクチャ (カスタム ドメインの構成、CA 証明書の追加、スケーリング、仮想ネットワーク構成、可用性ゾーンの変更、リージョンの追加など) の変更は、サービス レベルとデプロイのサイズによっては、完了するまでに 15 分以上かかることがあります。 スケール ユニットまたはマルチリージョン構成の数が多いインスタンスの場合、より長い時間が予想されます。 API Management へのローリング変更は、容量と可用性を維持するために慎重に実行されます。
サービスの更新中は、他のサービス インフラストラクチャの変更を行うことはできません。 ただし、API、製品、ポリシー、およびユーザー設定を構成できます。 サービスではゲートウェイのダウンタイムが発生 せず 、API Management は中断することなく API 要求に サービスを提供し続けます (開発者レベルを除く)。
前提条件
この記事の手順を実行するには、以下が必要です。
- 有効な Azure サブスクリプションを持っている。
- Azure API Management インスタンスがある。 詳細については、Azure API Management インスタンスの作成に関する記事を参照してください。
- API Management インスタンスの容量の概念を理解している。
- API Management インスタンスの手動スケーリングについて、コストの影響を含めて理解している。
Azure API Management の自動スケールの制限事項
自動スケールの動作を構成する前に、スケーリングの決定に関する特定の制限および影響を考慮する必要があります。
- API Management インスタンスの価格レベルによって、スケーリングできるユニットの最大数が決まります。 たとえば、Standard レベルでは、4 ユニットまでスケーリングできます。 Premium レベルでは、任意の数のユニットを追加できます。
- サービスが別の操作によってロックされている場合、スケーリング要求は失敗し、自動的に再試行されます。
- サービス インスタンスが複数のリージョン (場所) にデプロイされている場合は、Azure Monitor 自動スケーリングを使用して自動スケーリングできるのはプライマリ ロケーション内のユニットのみです。 他の場所の単位は、手動またはカスタム スケーリング ツールを使用してスケーリングできます。
- サービス インスタンスがプライマリの場所に可用性ゾーンを使用して構成されている場合は、可用性ゾーンの既定の自動設定のままにすることをお勧めします。 特定のゾーンを選択する場合、自動スケール ルールと制限内の API Management ユニットの数は、構成されたゾーンの数の倍数である必要があります。
API Management インスタンスの自動スケーリングの有効化と構成
次の手順に従って、Azure API Management サービスの自動スケーリングを構成します。
Azure portal にサインインし、API Management インスタンスに移動します。
左側のメニューで、[デプロイとインフラストラクチャ]>[スケールアウト (自動スケール)]、[カスタム自動スケール] の順に選択します。
[Default] (既定値) スケール条件で、[Scale based on a metric] (メトリックに基づいてスケーリングする) を選択し、次に[規則の追加] を選択します。
新しいスケールアウト規則を定義します。
たとえば、過去 30 分間の平均容量メトリックが 70% を超えたら 1 ユニットの API Management の追加をトリガーするようなスケールアウト規則が考えられます。 次の表は、そのような規則の構成例を示しています。 環境内でスケールアウト規則を定義する場合は、上記の制限事項を確認してください。
パラメーター 値 注記 メトリックのソース 現在のリソース 現在の API Management リソース メトリックに基づく規則を定義します。 条件 メトリックの名前 容量 容量メトリック は、Azure API Management インスタンスによるリソースの使用状況を反映した API Management メトリックの 1 つです。 API Management サービス レベルでサポートされている容量メトリックを選択します。 場所 API Management インスタンスのプライマリの場所を選択 演算子 より大きい メトリックのしきい値 70% 平均容量メトリックのしきい値。 このしきい値の設定に関する考慮事項については、「スケーリングの判断に容量を使用する」を参照してください。 期間 (分) 30 容量メトリックの平均値を算出するタイムスパンは使用パターンに固有です。 期間が長いほど、反応はスムーズになります。 間欠的なスパイクは、スケールアウトの決定にあまり影響を与えません。 ただし、スケールアウトのトリガーも遅れることになります。 統計時間単位 平均 操作 操作 カウントを増やす量 インスタンス数 1 Azure API Management インスタンスを 1 ユニットずつスケールアウトします。 クールダウン (分) 六十 ほとんどの場合、クール ダウン期間が 60 分の場合、多くのスケールアウトがトリガーされません。 [追加] を選んで規則を保存します。
別のルールを追加するには、[規則の追加] を選択します。
次に、スケールイン規則を定義する必要があります。 これにより、API の使用量が減少したときにリソースが無駄にならないようにします。
新しいスケールイン規則を定義します。
たとえば、過去 30 分間の平均容量メトリックが 35% を下回ったら 1 ユニットの API Management の削除をトリガーするようなスケールイン規則が考えられます。 次の表は、そのような規則の構成例を示しています。
パラメーター 値 注記 メトリックのソース 現在のリソース 現在の API Management リソース メトリックに基づく規則を定義します。 条件 時間の集計 平均 メトリックの名前 容量 スケールアウト規則に使用したものと同じメトリックです。 場所 API Management インスタンスのプライマリの場所を選択 演算子 より小さい しきい値 35% スケールアウト規則と同様に、この値は API Management インスタンスの使用パターンに大きく依存します。 期間 (分) 30 スケールアウト規則に使用したものと同じ値です。 統計時間単位 平均 操作 操作 カウントを減らす量 スケールアウト規則に使用したものとは逆です。 インスタンス数 1 スケールアウト規則に使用したものと同じ値です。 クールダウン (分) 90 スケールインはスケールアウトよりも慎重に行うことが望ましいため、クール ダウン期間を長くすることをお勧めします。 [追加] を選んで規則を保存します。
[Instance limits] (インスタンスの制限) で、API Management ユニットの[Minimum] (最小)、[Maximum] (最大)、[Default] (既定値) の数を選択します。
注
API Management には、インスタンスをスケールアウトできるユニット数の制限があります。 この制限はサービス レベルによって異なります。
[保存] を選択します。 自動スケーリングが構成されます。