MS_AzureAPIManagement - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki
- 戻る
- API Gateway
- AzureのGW / LB的なモノ。
-
AzureのPaaS
- Azure WebJobs
- Azure Functions
- Azure API Management
- Azure 上で、API Gateway の機能を提供する。
- Azure Functions と組み合わせサーバレス・アーキテクチャで構築できる。
ポリシー定義から読み取れる。
- Microsoft Azure/Azure API Management とは
https://www.ossnews.jp/oss_info/Azure_API_Management - Azure API Management ポリシーの設定または編集方法
https://learn.microsoft.com/ja-jp/azure/api-management/set-edit-policies
補足(「ポリシーが機能そのもの」という把握): 本ページが
「機能はポリシー定義から読み取れる」としているのは的確である。
APIM の機能はほぼすべて、
要求/応答パイプラインに挿入する XML のポリシーとして表現される。<policies> <inbound> <!-- クライアント → APIM。認証・制限・書き換え --> <backend> <!-- APIM → バックエンド。転送先の決定 --> <outbound> <!-- バックエンド → APIM。応答の変換 --> <on-error> <!-- 例外時 --> </policies>適用範囲は グローバル → 製品 → API → 操作 の 4 階層で、
<base />で上位のポリシーを差し込む位置を制御する。
以下の「保護」「ネットワーク」「変換」は、
すべてこのパイプライン上のポリシーとして実装されている。
- キー(基本認証)
- クライアント証明書
補足: 「キー」はサブスクリプション キー(
Ocp-Apim-Subscription-Keyヘッダー)で、
厳密には基本認証ではなく API キー方式である。
現在は、これらに加えて次が一般的。
方式 用途 JWT の検証( validate-jwt)Azure AD / OIDC による認可。現在の主流 マネージド ID APIM → バックエンドへの認証(資格情報を持たない) クライアント証明書 相互 TLS サブスクリプション キーは「呼び出し元の識別と計量」には向くが、
ユーザー認可の手段としては弱い(漏洩時の失効単位が粗い)。
-
IP アドレス
-
HTTP ヘッダ
-
スロットル(絞り弁)
-
呼び出しレート
- サブスクリプションに基づいて制限
- キーに基づいて制限
-
ボリュームと帯域幅クォータ
- サブスクリプションに基づいて制限
- キーに基づいて制限
-
高度な要求スロットル
-
補足(レート制限とクォータの違い): 混同されやすいが役割が異なる。
レート制限( rate-limit)クォータ( quota)目的 バックエンドの保護(瞬間的な過負荷を防ぐ) 契約上の上限(月あたり N 回まで) 期間 秒〜分 日〜月 超過時 429 Too Many Requests 403 相当 バックエンドを守りたいのか、課金プランを表現したいのかで選ぶ。
補足: CORS(
corsポリシー)、JSONP などを指す。
バックエンド側に CORS 実装が無くても、
APIM 側で一元的に付与できるのが利点。
- HTTP 応答のキャッシュ
- 値キャッシュ(キャッシュから値を取得)
キャッシュの任意の部分の格納と取得
補足(SKU の選択が構成を決める): APIM は SKU によって
閉域構成の可否とスケールの仕方が大きく異なる。
SKU 特徴 Consumption 従量課金・サーバーレス。VNET 統合不可 Basic / Standard 固定ユニット。VNET 統合不可(Standard v2 は対応) Premium VNET 統合(内部モード)、複数リージョン、自動スケール v2 系(Basic v2 / Standard v2 / Premium v2) 起動が速く、VNET 統合の選択肢が広い新世代 完全な閉域構成(内部 VNET モード)を要求されるなら Premium 系
という判断になり、費用が跳ね上がるため、
設計初期に確認すべき最重要点である。
補足: これらは現在 Azure Monitor の
メトリック/Application Insights との統合で確認する
(APIM 組み込みの「分析」も Log Analytics ベースに移行済み)。
補足: 開発者ポータル(Developer Portal)を通じた
API 利用者のセルフサービス登録・サブスクリプション申請を指す。
現在は React ベースの新しい開発者ポータルが標準で、
セルフホストしてカスタマイズすることもできる。
- JSON から XML への変換
- XML から JSON への変換
- XSLT を使用した XML の変換
- 本文内の文字列の検索および置換
- ボディの設定
- ヘッダの設定
- クエリ文字列の設定
- URL の書き換え
- バックエンド サービスの変更
- 外部サービスの使用
Azure API Apps との関係
こちらは、WebAPI 自体を構築するためのサービス。
補足(この区別が重要):
クライアント │ ▼ [ API Management ] ← API の「入口」。認証・制限・変換・計量 │ ▼ [ API Apps / Functions / AKS ] ← API の「実装」APIM は実装しない。既存の API 群の前に立ち、
横断的な関心事(認証、レート制限、バージョニング、
ログ、変換)を引き受けるのが役割である。
-
API Management: API ゲートウェイの構築
https://azure.microsoft.com/ja-jp/products/api-management/ -
Azure API Management【API Gateway】 - Qiita
https://qiita.com/snomoto/items/aa62cbfc0de136391995
- Azure API Management のドキュメント
https://learn.microsoft.com/ja-jp/azure/api-management/
Tags: 移行, インフラストラクチャ, クラウド, Azure, セキュリティ, 通信技術, .NET開発, OWIN, ASP.NET, ASP.NET Web API