Azure API Management インスタンスの容量
適用対象: Developer | Basic | Standard | Premium
容量は、より多くの負荷に対応できるように API Management インスタンスをスケーリングまたはアップグレードするかどうかについて情報に基づいて判断する上で、最も重要な Azure Monitor のメトリックです。 その構造は複雑であり、特定の動作が課せられます。
この記事では、容量の概要とその動作について説明します。 Azure portal の容量メトリックにアクセスする方法を説明し、API Management インスタンスのスケーリングまたはアップグレードを検討する時期を提案します。
重要
この記事では、Azure API Management インスタンスを監視し、その容量メトリックに基づいてスケーリングする方法について説明します。 ただし、個々の API Management インスタンスが実際にその容量に "達した" ときにどうなるかを理解することも重要です。 インスタンスの物理的な過負荷を防ぐためのサービスレベルの調整が Azure API Management によって適用されることはありません。 インスタンスは、その物理的な容量に達したとき、待ち時間が増えたり、接続がドロップされたり、タイムアウト エラーが発生したりするなど、過剰な負荷がかかって受信要求を処理できない Web サーバーと同じように振る舞います。 つまり、他のあらゆる外部サービスと同様、こうしたリスクに対処できるよう API クライアント側で備える必要があります (再試行ポリシーを適用するなど)。
前提条件
この記事の手順を実行するには、以下が必要です。
有効な Azure サブスクリプション
Azure サブスクリプションをお持ちでない場合は、開始する前に Azure 無料アカウントを作成してください。
API Management インスタンス。 詳細については、Azure API Management インスタンスの作成に関する記事を参照してください。
可用性
重要
容量メトリックの最大集計は、API Management の Premium レベルでのみサポートされています。
容量の概要
容量は、API Management インスタンスの負荷のインジケーターです。 リソース使用量 (CPU、メモリ) とネットワーク キューの長さを反映します。 CPU とメモリの使用量によって、以下によるリソース使用量がわかります。
- 要求処理など API Management のデータ プレーン サービス (要求の転送やポリシーの実行が含まれます)。
- API Management 管理プレーン サービス (Azure portal または Azure Resource Manager 経由で適用された管理アクション、開発者ポータルから来る負荷など)。
- 選択したオペレーティング システム プロセス (新しい接続での TLS ハンドシェイクのコストを伴うプロセスが含まれます)。
- プラットフォームの更新 (インスタンスの基になるコンピューティング リソースの OS 更新など)。
- アクティビティに関係なくデプロイされた API の数。追加の容量が消費される可能性があります。
合計容量は、API Management インスタンスの各ユニットの値の平均です。
容量メトリックは API Management インスタンスの問題を明らかにするように設計されていますが、容量メトリックの変更に問題が反映されない場合もあります。
容量メトリックの動作
実際の容量は、その構成があるため、多くの変数の影響を受ける可能性があります。次に例を示します。
- 接続パターン (要求に対する新しい接続と既存の接続の再利用)
- 要求と応答のサイズ
- 要求を送信する各 API または複数のクライアントで構成されたポリシー。
要求に対する操作が複雑になるほど、容量の使用量は多くなります。 たとえば、複雑な変換ポリシーの場合、単純な要求の転送よりもはるかに多くの CPU が使用されます。 バックエンド サービスの応答が遅い場合も、使用量が多くなります。
重要
容量は、処理されている要求の数を直接測定したものではありません。
容量は、要求が処理中でない場合でも、断続的にスパイクする場合や、ゼロより大きくなる場合があります。 これは、システム固有またはプラットフォーム固有のアクションが原因です。インスタンスをスケーリングするかどうかを判断する際には考慮しないでください。
低い容量メトリックが必ずしも API Management インスタンスに問題が発生していることを意味するものではありません。
Azure portal を使用して容量を調べる
Azure portal で API Management インスタンスに移動します。
左側のメニューの [監視] で [メトリック] を選択します。
使用できるメトリックから [容量] メトリックを選択し、既定の [平均] 集計のままにします。
ヒント
インスタンスを複数の場所にデプロイした場合は、間違った解釈を回避するために、常に場所ごとに [容量] メトリックの内訳を調べるようにしてください。
メトリックを場所別に分割するには、上部のセクションから [Apply splitting](分割の適用) を選択し、[場所] を選択します。
セクションの上部のバーから目的の期間を選択します。
メトリック アラートを設定して、予想外の出来事が発生したときに通知されるようにすることができます。 たとえば、API Management インスタンスが予想されるピーク容量を 20 分以上超えている場合に通知を受けます。
ヒント
サービスの容量が少なくなったときに通知するようにアラートを設定するか、Azure Monitor の自動スケーリングを使用して Azure API Management ユニットを自動的に追加することができます。 スケーリング操作には約 30 分かかるので、それに従ってルールを計画してください。
マスターの場所のスケーリングのみを実行できます。
スケーリングの判断に容量を使用する
容量は、より多くの負荷に対応できるように API Management インスタンスをスケーリングするかどうかを判断するためのメトリックです。 一般的な考慮事項は次のとおりです。
- 長期的な傾向と平均を確認する。
- 負荷の増加に関係しない可能性が高い突発的なスパイクを無視する (説明については、「容量メトリックの動作」を参照してください)。
- 一般的なルールとしては、容量の値が 60% から 70% を長時間 (たとえば 30 分) 超えた場合に、インスタンスをアップグレードまたはスケーリングします。 サービスやシナリオによって、異なる値が適している場合があります。
- インスタンスが 1 ユニットのみで構成されている場合は、容量の値が 40% を長時間超えた場合に、インスタンスをアップグレードまたはスケーリングします。 この推奨事項は、基になるサービス プラットフォームにおいて、ゲスト OS の更新プログラムのための容量を確保する必要性に基づいています。
ヒント
あらかじめトラフィックを見積もることができる場合は、予想するワークロードで API Management インスタンスをテストしてください。 テナントに対する要求の負荷を徐々に増やし、ピーク負荷に対応する容量メトリックの値を監視することができます。 前のセクションの手順に従って、Azure portal を使用して常に容量の使用量を把握してください。