APIMのパフォーマンスについてよく聞かれるため要点をまとめる。

要点

APIMメトリックはCPUとメモリ、リクエストキューの長さで構成される
CPUとメモリの使用率は、リクエストだけでなく、OSのプロセス、プラットフォームの更新、APIでのポリシー処理などさまざまな要素で構成されるため一概にリクエスト数だけで判断はできない
したがって容量(Capacity)を計測し、それに応じてレベルのアップグレードやスケーリングを計画していくことが推奨される。アップグレードやスケーリングは最大15分から45分かかる
クラシックとv2間は行き来ができないため、可能な限り早めに移行が望ましい
メトリックに応じた自動スケーリングも設定することができる。

APIMのメトリック

まず公式Docより

容量メトリックは

CPUとメモリー
ネットワークのキューの長さに分かれる

CPUとメモリーについてはさらに

APIM Services
選択されたOSに分かれる

CPUとメモリの使用量によって、以下のリソース使用量がわかる。

要求処理など API Management のデータプレーンサービス (要求の転送やポリシーの実行が含まれます)。
API Management 管理プレーンサービス (Azure portal または Azure Resource Manager 経由で適用された管理アクション、開発者ポータルから来る負荷など)。
選択したオペレーティングシステムプロセス (新しい接続での TLS ハンドシェイクのコストを伴うプロセスが含まれます)。
プラットフォームの更新 (インスタンスの基になるコンピューティングリソースの OS 更新など)。
アクティビティに関係なくデプロイされた API の数。追加の容量が消費される可能性があります。

合計容量は、API Management インスタンスの各ユニットの値の平均です。

容量メトリックは API Management インスタンスの問題を明らかにするように設計されていますが、容量メトリックの変更に問題が反映されない場合もあります。

Ref: https://learn.microsoft.com/ja-jp/azure/api-management/api-management-capacity

ユニットとは
レベルによる処理能力の違い
アップグレードとスケーリング
1. 参照

ユニットとは

ユニットは専用の Azure リソースで構成され、1 秒あたりの API 呼び出しの数として表される特定の耐荷容量があります。この数値は呼び出しの制限を表しているのではなく、大まかな容量計画を行うための推定最大スループット値です。実際のスループットと待ち時間は、コンカレント接続の数とレート、構成されたポリシーの種類と数、要求のサイズと応答のサイズ、バックエンドの待ち時間などの多くの要因によって、大幅に異なります。

Ref: https://learn.microsoft.com/ja-jp/azure/api-management/upgrade-and-scale

つまり、ユニットは大まかな呼び出し回数を測るための基準で単純にその分リクエストを処理できるということではない。

容量メトリックの動作

実際の容量は、その構成があるため、多くの変数の影響を受ける可能性があります。次に例を示します。

接続パターン (要求に対する新しい接続と既存の接続の再利用)
要求と応答のサイズ
要求を送信する各 API または複数のクライアントで構成されたポリシー。

要求に対する操作が複雑になるほど、容量の使用量は多くなります。たとえば、複雑な変換ポリシーの場合、単純な要求の転送よりもはるかに多くの CPU が使用されます。バックエンドサービスの応答が遅い場合も、使用量が多くなります。

容量は、要求が処理中でない場合でも、断続的にスパイクする場合や、ゼロより大きくなる場合があります。これは、システム固有またはプラットフォーム固有のアクションが原因です。インスタンスをスケーリングするかどうかを判断する際には考慮しないでください。

低い容量メトリックが必ずしも API Management インスタンスに問題が発生していることを意味するものではありません。

Ref:Azure API Management インスタンスの容量 | Microsoft Learn

複雑なポリシーを実行した場合その分CPU使用率が多く使用されることになる。

重要なのは容量=リクエスト数ではないことにある。また、容量はリクエストがない時にでも発生したり、逆に少ないからといって問題がないとは言い切れない点にある。

容量の調べ方

ポータルの監視のメトリック → 容量の平均から取得する。

スケーリングの判断

容量は、より多くの負荷に対応できるように API Management インスタンスをスケーリングするかどうかを判断するためのメトリックです。一般的な考慮事項は次のとおりです。

長期的な傾向と平均を確認する。
負荷の増加に関係しない可能性が高い突発的なスパイクを無視する (説明については、「容量メトリックの動作」を参照してください)。
一般的なルールとしては、容量の値が 60% から 70% を長時間 (たとえば 30 分) 超えた場合に、インスタンスをアップグレードまたはスケーリングします。サービスやシナリオによって、異なる値が適している場合があります。
インスタンスが 1 ユニットのみで構成されている場合は、容量の値が 40% を長時間超えた場合に、インスタンスをアップグレードまたはスケーリングします。この推奨事項は、基になるサービスプラットフォームにおいて、ゲスト OS の更新プログラムのための容量を確保する必要性に基づいています。

ヒント

あらかじめトラフィックを見積もることができる場合は、予想するワークロードで API Management インスタンスをテストしてください。テナントに対する要求の負荷を徐々に増やし、ピーク負荷に対応する容量メトリックの値を監視することができます。前のセクションの手順に従って、Azure portal を使用して常に容量の使用量を把握してください。

Ref: https://learn.microsoft.com/ja-jp/azure/api-management/api-management-capacity#use-capacity-for-scaling-decisions

レベルによる処理能力の違い

Developer、Basic、Basic v2、Standard、Standard v2、Premium レベルから選択可能

Developerレベルは運用環境で推奨されないためBasic、Basic v2、Standard、Standard v2、Premium レベルから選択する。

もしくはすでにv2レベルが来ているためBasic v2 と Standard v2を選択することがこれからは推奨される。

利用できません	使用量	Developer	Basic	標準	Premium	Isolated プレビュー
スケールアウト (ユニット)	該当なし (自動スケーリング)	1	2	4	リージョンごとに 12(電話サポートなど)	リージョンごとに 12(電話サポートなど)
予測最大スループット(ユニットごと)	該当なし (自動スケーリング)	500 要求/秒	1,000 要求/秒	2,500 要求/秒	4,000 要求/秒	4,000 要求/秒

Ref: API Management の価格 | Microsoft Azure

ただしこちらには注意書きがあり

**スループットの数値は情報提供のみを目的としています。容量や予算の計画の根拠として使用しないでください。予想される運用環境を反映したロードテストを実施して、予期されるスループットの正確さを判断する必要があります。**スループットは、クライアントの同時接続の数と速度、構成されたポリシーの種類と数、ペイロードのサイズ、バックエンドの API パフォーマンスなどの要素の影響を受けます。表の数字は、セキュリティで保護された永続的なクライアント HTTP 同時接続数 1000、ペイロードサイズ最小、構成されたポリシーなし、低遅延のバックエンド API という条件のテストによって取得されたものです。

つまり、実際の環境で容量を計測しない限り正確な判断はできないと考えた方が良い。

アップグレードとスケーリング

公式Docより

特定の専用サービスレベル間でアップグレードまたはダウングレードを実行できます。
- クラシックレベル (Developer、Basic、Standard、Premium) 間でアップグレードおよびダウングレードできます。v2 レベル (Basic v2 と Standard v2) 間でアップグレードおよびダウングレードできます。
ダウングレードすると一部の機能が削除される可能性があります。たとえば、Premium レベルから Standard または Basic にダウングレードすると、仮想ネットワークや複数リージョンへのデプロイは利用できなくなる場合があります。