渋谷ヒカリエの Azure Antenna で開催された Azure API Management ハンズオンに参加してきました。
当日の講義内容を復習するつもりでここに記していこうと思います。
Azure API Management とは
Azure API Management は、Azure が提供するマネージドな API ゲートウェイのサービスで、バックエンドにあるサービスを提供する API を一括で管理して様々な処理 (セキュリティ、レート制限、データ変換、監視、など) を仲介するものです。
API Management の機能概要
- API の保護と最適化
- ポリシーでアクセス制限、キャッシュ管理、データ変換、などなど
- 開発者エクスペリエンス
- ポータル利用で容易に開発
- 統一された管理/分析
- リアルタイムの使用量、応答性能、正常性分析
- あらゆる配置に適応
- インターネットも VPN/ExpressRoute も
- 柔軟なスケーリング
- スケールアップ/スケールアウト
導入事例
- システム間を緩やかにつなぐ「API ゲートウェイ」を Azure で実現、既存システムの資産を有効活用した新サービスを短期間で立ち上げられる基盤を確立
- PaaSのみでオープンAPI基盤をスピード開発、セブン銀行がAzure導入
- Microsoft Cognitive Services の基盤は API Management を採用しているそうです。
API Management の構成
以下のコンポーネントで構成されます。
- Azure ポータル...API 群を管理
- バックエンド API のスキーマ定義をインポート & 編集
- Product (API の管理単位?) で API をまとめる
- API のアクセス制御、キャッシュ、データ変換などのポリシーを設定
- 使用量、応答性能、正常性などの分析
- ユーザー (管理者、開発者、ゲスト) 管理
- 開発者ポータル...開発者向けの Web プレゼンス
- API ドキュメントを参照
- API のテスト
- API キーの管理
- などなど
- API ゲートウェイ
- API の呼び出しを受けて、バックエンドの API にルーティング
- 資格情報 (キー、JWT トークン、証明書など) を検証
- 使用量クォータとレート制限を適用
- バックエンド API のレビジョン、バージョン管理
- などなど
API ライフサイクル
API のライフサイクルに沿って、工程と役割を整理します。
API 構築
API 開発者の役割。
Open API (Swagger)、REST API (WADL)、SOAP API (WSDL) や Azure 上にデプロイした Logic App、API App、Function をインポートすることができます。
API の仕様はインポートしたスキーマ定義が自動的に反映されます。
※Azure ポータル上で編集することもできます。
※バックエンド API の仕様
※API Management に追加した結果 (開発者ポータル)
- 参考：最初の API のインポートと発行
- 参考：API の編集
- 参考：手動による API の追加
- 参考：OpenAPI 仕様のインポート
- 参考：SOAP API のインポート
- 参考：Logic App を API としてインポートする
- 参考：API App を API としてインポートする
- 参考：Function を API としてインポートする
また、バックエンド API が存在しなくても (使用できなくても)「モック API」として作成、テストすることもできます。
API 発行
API 管理者の役割。
インポートした API は、作成した「Product」という API の管理単位 (と私は解釈したが、ユーザーが利用する契約の単位となる) にまとめます。Product には複数の API を入れることができます。
Product に API を含めることによって、管理者、開発者がその API を呼び出せるようになります。
そして、Product、または API ごとにポリシーを適用して API の保護と最適化を行います。
ポリシーは、API のリクエスト、レスポンスなどに対して順に実行される一連のステートメントの集まりです。
ステートメントの例としては、リクエスト本文やレスポンス本文を XML から JSON に変換、API の呼び出し回数を制限するなどがあります。
なお、ポリシーの適用は、Global > Product > API の順で行われます。
※既定の Product「Starter」のポリシーは、1分間に上限5回まで、週に最大100回まで呼び出すことができると定義されています。
また、バージョン管理、リビジョン管理をサポートしているので、API の変更やライフサイクルの管理に柔軟にコントロールすることができます。
API 利用
アプリ開発者 (API 利用者) の役割。
API を Product に含めたので、その API を呼び出すことができます。API のドキュメントも確認できます。
※開発者ポータルにアプリ開発者を登録して利用させる
API のテストは、Azure ポータル、開発者ポータルから実施することができます。
※下図は、開発者ポータルでテストを実行した結果
なお、API のテストを実施する際は、「サブスクリプションキー」が必要です。この「サブスクリプションキー」は、開発者ポータルの PRODUCTS > API を含めた Product から入手することができます。
また、開発者ポータルのデザインをカスタマイズすることもできます。
API 運用
API 管理者の役割。
API の利用状況、パフォーマンス、メトリックなどを分析する機能があります。
※この機能は、Azure ポータルにはまだ移行しきれておらず、「発行者ポータル (まもなく廃止予定)」で確認。(2018年10月現在)
※REST API で取得することも可能。
API Management のセキュリティ
Azure API Management には、API 管理者向け、アプリ開発者向け、アプリケーション向けに機能を提供していますが、それぞれにアクセス制御を施しています。
※API ゲートウェイーAPI 間にある「OAuth 2.0」と「OpenID Connect」は、API ゲートウェイ側の機能ではなく、API サーバー側でこの認証が行っていれば使えるようになっているという意味。
配置パターン
想定される配置パターンは以下のとおり。
配置パターンその１
| 仮想ネットワーク | オフ |
| サービス エンドポイント | パブリック |
| バックエンド API | パブリック |
| アクセス方法 | インターネットから |
以下は、基本的な配置です。すべての価格レベルで実現できます。
配置パターンその２
| 仮想ネットワーク | 外部 |
| サービス エンドポイント | パブリック |
| バックエンド API | VNET 上 & オンプレミス上 |
| アクセス方法 | インターネットから |
以下は、社内ネットワーク上の API をインターネットに公開する場合の配置です。
API Management を仮想ネットワークに接続するには、価格レベルで「Premium (Developer)」を選択します。
配置パターンその３
| 仮想ネットワーク | 内部 |
| サービス エンドポイント | プライベート |
| バックエンド API | VNET 上 & オンプレミス上 |
| アクセス方法 | 社内ネットワークから |
以下は、社内ネットワーク上の API を社内から利用する場合の配置です。
※先と同様、API Management を仮想ネットワークに接続するには、価格レベルで「Premium (Developer)」を選択します。
配置パターンその４
| 仮想ネットワーク | 内部 |
| サービス エンドポイント | プライベート |
| バックエンド API | VNET 上 & オンプレミス上 |
| アクセス方法 | インターネットから |
| 社内ネットワークから |
以下は、社内ネットワーク上の API を社内外から利用する場合は、API Management だけでは実現できないため、インターネット公開用として Application Gateway を用いて実現します。
※先と同様、API Management を仮想ネットワークに接続するには、価格レベルで「Premium (Developer)」を選択します。
実運用で仮想ネットワークに接続したいとなった場合、価格レベルの選択肢が「Premium」しかない (お値段がとてもお高い!!) のがとても厳しいですね...
※近い将来(?)、Consumption Tier (従量課金) が設定される模様。
ハンズオン!!
API Management のインスタンスを作成
以下の記事の手順に従って作成しましょう。
料金レベルは、お試しなら「開発者 (SLA なし)」を選択しましょう。
なお、作成完了するまで20分くらいかかります。
参考：Azure API Management サービスの新しいインスタンスの作成
API の準備
バックエンドの API として、今回は Open API で作ったものを用意しました。
API のインポート
先ほど作った API のスキーマ定義をインポートします。
API Management インスタンス > API > Add API をクリックして、[OpenAPI specification] をクリック
[OpenAPI specification] に API のスキーマ定義を入力して [Create] をクリック
※[Display Name] と [Name] は、(スキーマ定義を読み込んで) 自動的にセットされる
インポート完了。
しかし、「Product」に追加せずに API をテストしてみると、401 が返ってきます。
API は Product に追加しないと利用できないので、Product に追加します。
API を呼び出してみる
API Management インスタンス > API > インポートした API をクリックし、[Test] タブを開きます。
任意の operation を選択、パラメーターなどを入力して [Send] をクリックします。
「200 OK」と戻り値が返ってきたことを確認します。
開発者ポータルでも同様のことができます。
API の呼び出しレートを設定してみる
"Addition" operation にポリシーを設定してみます。
inbound ポリシーに「Limit call rate」を追加して、呼び出しレートを IP アドレスごとに制限します。
ここでは、以下のとおりに設定してみます。
- Number of calls (Renewal period で指定した期間中に許容する呼び出し回数) ... 3 回
- Renewal period (クォータのリセット間隔) ... 3 秒
- Counter key (レート制限ポリシーに使用するキー) ... 呼び出し元 IP アドレス
- Increment condition (クォータに対して要求の件数をカウントする条件) ... 「2xx」を返却した時
では、Postman を使ってテストしてみます。
[Send] を何回か連打してみます。
しばらく連打していると、以下のようなレスポンスが返却され、レートが制限されていることが確認できます。
ここで注目すべきことは「API 発行」で先述したように、「ポリシーの適用は、Global > Product > API の順で行われる」ということです。
例えば、インポートした API を Product「Starter」に追加した場合、「Starter」のポリシーには「1分間に上限5回まで、週に最大100回まで呼び出し可」というものが適用されており、API のポリシーよりこのポリシーのほうが優先的に適用されます。
まとめ
API は簡単に公開することができますが、その際に「認証はどうするか」、「どのようにアクセス制限すべきか」、「利用状況の確認方法はどうするか」などを API の本来の目的以外のことを考えて実装する必要があります。Azure API Management を API のゲートウェイとして設置することで一括で管理でき、各 API のこれらの懸念点から解放されるだろうと実感しました。
ただ、社内ネットワーク上の API を管理しようとなると、コストがネックになりそうです。今後改善されることを期待したいです。