Azure API Management

このエントリは、2019/06/13現在の情報に基づいています。今後の改廃や機能追加により、記述内容との齟齬が発生する場合があります。

API Managementとは?

既存のバックエンドのサービスをAPIとして作成、文書化、有効化し、アクセス制御を提供し、統計情報を取得するプロセス。

Azure API Managementとは?

API ManagementのためのフルマネージドPaaSサービス。

構成要素

  • ゲートウェイ
  • 管理ツール(Azure Portal)
  • 開発者ポータル

ゲートウェイ

フルマネージドゲートウェイのため、利用者が別途IaaS上にゲートウェイをインストールする必要はない。ただしAzure API Managementはハイブリッド型API Managementサービスではないため、現時点ではゲートウェイはAzureにのみ展開(オンプレミスへの配置は不可、現在オンプレミス用ゲートウェイは開発中)。そのため、オンプレミスのAPIをバックエンドサービスとして利用する場合、VPNもしくはExpressRouteなどを使ってアクセスできるようにする必要がある。

Self-hosted API Management gateway is in development
https://azure.microsoft.com/en-us/updates/self-hosted-api-management-gateway/

ゲートウェイは各リージョンに分散配置可能。この場合、当該リージョンのゲートウェイにAPI成果物がデプロイされる。APIアクセス時には、アクセス元に応じて待ち時間の観点から最も近いゲートウェイにルーティングされる。リージョンがオフラインのときは、トラフィックは自動的に次に最も近いゲートウェイにリダイレクトされる。バックエンドサービスがプライマリリージョンにしかない場合、せっかくゲートウェイを分散配置しているのにレスポンスがいまいち、ということになってしまうので、可能な限りゲートウェイと同一リージョンにバックエンドサービスを配置するべきである。

管理サービスはプライマリにのみ存在し、他リージョンにレプリケートされない。そのためプライマリリージョンが停止した場合、設定またはポリシーの更新プログラムを含む構成の変更を Azure API Management サービスインスタンスに適用できなくなる(換言すると、バックアップ・リストアの構成は必須)。

開発者ポータル

カスタマイズ可能なAPI利用者向けの情報公開用ポータル。マネージドとセルフホストの両方を利用できる。後者の場合、Azure外に配置可能。詳細は以下のドキュメントを参照。

Managed and self-hosted versions
https://docs.microsoft.com/ja-jp/azure/api-management/api-management-howto-developer-portal#managed-and-self-hosted-versions

Azure Portalからは旧来の開発者ポータルとプレビューの新しい開発者ポータルへのリンクがある。

  • (旧ポータル)https://{インスタンス名}.portal.azure-api.net/
  • (新ポータル)https://{インスタンス名}.developer.azure-api.net/

APIの作成

どんなAPIを公開できるか?

SOAP、RESTとも可。具体的には、下図に記載のオプションでバックエンドサービスのメタデータのインポートもしくは既存のサービスの情報を指定する。

API定義

URLスキーム、Descriptionなどを記述する。サブスクリプションが必要な場合、API Keyを指定する必要がある(指定方法はQuery ParameterもしくはHTTP Header)。その他、認証のしくみ(認証無し、OAuth2、OIDC)や製品(Products、他社製品でいうレートリミットプランやサブスクリプションプラン)を指定できる。

パイプライン(フロー)の定義

APIの設計(Design)タブをクリックすると、Frontend、Request/Response processing、Backendといったペインに分かれて編集できるようになっている。

APIデザインの画面

FrontendとBackendのペインでは、エンドポイントや証明書などの設定を行う。FrontendはOpenAPI仕様で確認できる(言い換えると、OpenAPI仕様でAPIのメタデータをインポート・エクスポートできる)。

Frontendの例
Backendの例

Request/Response Processing、Backendではポリシーを追加して種々の設定を追加する。[+Add policy] ボタンをクリックすると、よく使われるポリシーがリストアップされる(下図)。この中にないポリシーはOther policiesをクリックして追加していく。

ポリシー追加(1)
ポリシー追加(2)

ポリシーは各エンドポイント、各メソッドごとに定義する。

ポリシーには階層があり、上位から評価される。上位ポリシーは<base />に定義される(<base />を削除すると上位ポリシーを無視できる)。

  • グローバルレベル(APIのAll APIsに設定)
  • 成果物レベル(製品)
  • APIレベル(All Operationsに設定)
  • 各Operationレベル

そのため、例えばAPIの各Operationに共通するポリシーを設定する場合、All Operationsのフロー内で設定できる(つまり、個々のオペレーションごとに設定する必要はない)。

BackendにはGlobalレベルで<forward-request />が設定されている(これがBackend Serviceへの転送のためのポリシー)。Backendには1個だけしかポリシーを指定できないため、どうしても複数ポリシーを設定する必要がある場合、以下のように設定する。

  • <base />を削除(つまりGlobal Policyを削除)
  • 入れ子にして、<forward-request />を追加(API Operationレベルで設定)

ポリシー

ポリシーは、API のリクエストまたはレスポンスに対して順に実行される一連のステートメントのコレクション。これを使ってAPIの動作を変更できる。Azure API Managementには基本的なポリシーは揃っている。
ポリシーはアップデートされていくため、最新情報はドキュメントを参照することを推奨。

API Management のポリシー
https://docs.microsoft.com/ja-jp/azure/api-management/api-management-policies
API Management policies
https://docs.microsoft.com/en-us/azure/api-management/api-management-policies

キャッシュ

APIレスポンスを保持するためのキャッシュを内包しており、ポリシーでアクセス可能。内包するキャッシュ以外に、カスタムキャッシュとしてRedis Cacheを利用できるため、外部でデータを更新したものをAPI Managementで取得することも可能。

リビジョンとバージョン

Azure API Managementの場合、破壊的な変更と破壊的でない変更を組み合わせることができる。破壊的変更の場合、URLにバージョンを指定、破壊的でない変更はHTTP Headerにリビジョンをつけて区別するよう推奨している。

リビジョン(破壊的でない変更)

URLなどには変更はなく、開発者が明示的に指定しなくても最新のリビジョンにアクセスできるしくみ。HTTP Headerでのみ指定できる。

バージョン(破壊的な変更)

複数のバージョンを保持できる。Version指定する方法は以下。

  • HTTP Header
  • Query Parameter
  • URL Path

リビジョンつきのバージョンを複製する場合、最新のリビジョンのみ複製する。

運用

可用性

プライマリインスタンスは最初に作成したインスタンス。他リージョンにゲートウェイを配置したり、同一リージョンに複数ユニットを立てたりすることが可能。

他リージョンにゲートウェイを配置した場合、バックエンドサービスもそのリージョンに配置することを強く推奨している。

バックアップ・リストア

API管理サービス自体は他リージョンへのレプリケートや同一リージョンでの複数配置はできないため、複数のソースを保持できない。そのため、バックアップ・リストアは必須。注意点は以下。

  • バックアップの有効期限は30日
  • 復元先のサービスの SKU は、復元されるバックアップ サービスの SKU と一致しなければならない
  • 復元処理の進行中にサービス構成 (API、ポリシー、開発者ポータルの外観など) に対して行われる変更は、上書きされることがある

バックアップ・リストアの詳細は以下のドキュメントを参照。

Azure API Management でサービスのバックアップと復元を使用してディザスター リカバリーを実装する方法
https://docs.microsoft.com/ja-jp/azure/api-management/api-management-howto-disaster-recovery-backup-restore
How to implement disaster recovery using service backup and restore in Azure API Management
https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-disaster-recovery-backup-restore

構成管理

Gitで構成情報を管理できる。

Git を使用して API Management サービス構成を保存および構成する方法
https://docs.microsoft.com/ja-jp/azure/api-management/api-management-configuration-repository-git
How to save and configure your API Management service configuration using Git
https://docs.microsoft.com/en-us/azure/api-management/api-management-configuration-repository-git

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google フォト

Google アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中