マルチテナント ソリューションで Azure API Management を使用する
Azure API Management は、API 向けの包括的な API ゲートウェイでリバース プロキシです。 キャッシュ、応答のモック作成、開発者ポータルなど、API に重点を置いたアプリケーションに役立つ多くの機能を提供します。 この記事では、マルチテナント ソリューションに役立つ API Management の主な機能のいくつかをまとめます。
Note
この記事では、内部または外部で使用する API をホストする、独自のマルチテナント アプリケーションがあるときに API Management を使用する方法に重点を置きます。
マルチテナントの別の形式は、API Management ゲートウェイをサービスとして他のチームに提供することです。 たとえば、組織には複数のアプリケーション チームがデプロイして使用する、共有 API Management インスタンスがある場合があります。 この記事では、この形式のマルチテナントについては説明しません。 ワークスペースの使用を検討してください。これは、アクセス レベルが異なる複数のチーム間で API Management インスタンスを共有するのに役立ちます。
分離モデル
通常、API Management は、複数のテナントに対する要求を処理する単一のインスタンスを持つ共有コンポーネントとしてデプロイされます。 ただし、テナント モデルに基づいて、API Management をデプロイする方法は多数あります。 この記事では、デプロイ スタンプを使用してソリューションをデプロイすることを前提としています。
通常、API Management の使用方法は、分離モデルに関係なく似ています。 このセクションでは、分離モデル間のコストと複雑さの違いと、各アプローチが要求をバックエンド API アプリケーションにルーティングする方法について説明します。
| 考慮事項 | シングルテナント バックエンドを持つ共有インスタンス | 共有マルチテナント バックエンドを持つ共有インスタンス | 各テナントのインスタンス |
|---|---|---|---|
| サポートされるテナントの数 | 多数 | ほぼ無制限 | インスタンスごとに 1 つ |
| コスト | 低 | 低 | 高 |
| 配置の複雑性 | 低: スタンプごとに管理する 1 つのインスタンス | 低: スタンプごとに管理する 1 つのインスタンス | 高: 管理が必要な複数のインスタンス |
| ルーティング構成の複雑さ | より高い | より低い | 低 |
| 近隣ノイズの問題の影響を受けやすい | はい | はい | いいえ |
| テナント レベルのネットワーク分離 | いいえ | 番号 | はい |
| サンプル シナリオ | テナントごとのカスタム ドメイン名 | 共有アプリケーション層を備えた大規模なマルチテナント ソリューション | テナント固有のデプロイ スタンプ |
共有インスタンス分離モデル
複数のテナント間で API Management インスタンスを共有するのは一般的であり、コストとデプロイおよび管理の複雑さを軽減するのに役立ちます。 API Management インスタンスを共有する方法の詳細は、バックエンド API アプリケーションにテナントを割り当てる方法によって異なります。
シングルテナント バックエンド アプリケーション
テナントごとに個別のバックエンド アプリケーションをデプロイする場合は、1 つの API Management インスタンスをデプロイし、要求ごとにトラフィックを適切なテナント バックエンドにルーティングできます。 このアプローチでは、テナントごとにバックエンド ホスト名で API Management を構成するか、着信要求を正しいテナントのバックエンドにマップする別の方法を用意する必要があります。
このアプローチでは追加の検索が必要になるため、1 つの API Management インスタンスを共有する多数のテナントにスケーリングされない場合があります。 テナント バックエンドを検索する際に、パフォーマンスのオーバーヘッドが発生する可能性もあります。 ただし、このパフォーマンス オーバーヘッドの程度は、このような検索の設計方法によって異なります。
共有マルチテナント バックエンド アプリケーション
テナントが共通のバックエンド アプリケーションを共有するシナリオでは、すべての要求を 1 つのバックエンドにルーティングできるため、API Management のルーティング プロセスが簡略化されます。 ワイルドカード ドメインまたはプロバイダーが発行したドメインを使用する場合は、このアプローチでほぼ無制限の規模を実現できる可能性があります。 また、要求はテナントのバックエンドにマップされる必要がないため、カスタマイズされたルーティングの決定によるパフォーマンスへの影響はありません。
各テナントのインスタンス
状況によっては、テナントごとに API Management のインスタンスをデプロイする場合があります。 このアプローチは、テナントの数が少ない場合、またはテナント間でインフラストラクチャを共有することを制限する厳格なコンプライアンス要件がある場合にのみお勧めします。 たとえば、テナントごとに専用の仮想ネットワークをデプロイする場合は、おそらくテナントごとに専用の API Management インスタンスをデプロイする必要もあります。
ヒント
複数のインスタンスをデプロイする理由が、異なる地理的リージョン全体でユーザーをサポートすることだけの場合は、API Management の マルチリージョン デプロイ機能が要件を満たしているかどうかを検討してください。
API Management のインスタンスをデプロイするときは、Azure サブスクリプションまたはリージョン内の API Management インスタンスの数に適用される可能性がある制限など、サービスの制限を考慮する必要があります。
通常、シングルテナント インスタンスでは、すべての要求を 1 つのバックエンドにルーティングできるため、ルーティング構成は最小限に抑えられます。 このシナリオではカスタム ルーティングの決定は必要ないため、さらなるパフォーマンスへの影響はありません。 ただし、通常は共有インスタンスをデプロイする場合よりも高いリソース コストが発生します。 シングルテナント インスタンスをデプロイする必要がある場合は、セルフホストテッド ゲートウェイによって、既にデプロイしたテナント固有のコンピューティング リソースを再利用できるようになるかどうかを検討してください。
マルチテナント機能をサポートする API Management の機能
API Management は、ポリシーを使用して柔軟性を実現します。 ポリシーを使用するときに要求を検証、ルーティング、および処理する方法をカスタマイズできます。 また、API Management でマルチテナント ソリューションを設計する際は、ポリシーを使用してその機能の多くを実装します。
着信要求でテナントを識別する
各着信要求内で適切なテナントを識別する方法を検討してください。 マルチテナント ソリューションでは、他のユーザーではなくその特定のテナントのデータを返せるように、各要求を行っているユーザーを明確に把握することが重要です。
API Management は、要求の認証に使用できるサブスクリプションを提供します。 これらのサブスクリプションでは、要求を行っているサブスクライバーを識別するのに役立つ一意のサブスクリプション キーを使用します。 サブスクリプションを使用する場合は、API Management サブスクリプションを独自のテナントまたは顧客 IDにマップする方法を検討してください。 サブスクリプションは開発者ポータルに緊密に統合されています。 ほとんどのソリューションでは、サブスクリプションを使用してテナントを識別することをお勧めします。
または、他の方法を使用してテナントを識別することもできます。 以下に、定義したカスタム ポリシー内で実行されるアプローチの例を示します。
サブドメイン、パス、クエリ文字列など、URL のカスタム コンポーネントを使用します。 たとえば、URL
https://api.contoso.com/tenant1/productsで、パスの最初の部分のtenant1を抽出し、それをテナント識別子として扱います。 同様に、着信 URLhttps://tenant1.contoso.com/productsの場合は、サブドメインのtenant1を抽出します。 このアプローチを使用するには、Context.Request.Urlプロパティからパスまたはクエリ文字列を解析することを検討してください。要求ヘッダーを使用します。 たとえば、クライアント アプリケーションがカスタム
TenantIDヘッダーを要求に追加する場合があります。 このアプローチを使用するには、Context.Request.Headersコレクションから読み取ることを検討してください。JSON Web トークン (JWT) から要求を抽出します。 たとえば、ID プロバイダーによって発行された JWT にカスタム
tenantId要求があるとします。 このアプローチを使用するには、validate-jwt ポリシーを使用し、output-token-variable-nameプロパティを設定して、ポリシー定義がトークンから値を読み取ることができるようにします。テナント識別子を動的に検索します。 要求の処理中に外部のデータベースまたはサービスと通信できます。 このアプローチを使用すると、カスタム テナント マッピング ロジックを作成して、論理テナント識別子を特定の URL にマップしたり、テナントに関する追加情報を取得したりできます。 このアプローチを使用するには、end-request ポリシーを使用します。
このアプローチでは、要求の待ち時間が長くなる可能性があります。 この影響を軽減するために、キャッシュを使用して外部 API への呼び出しの数を減らすことをお勧めします。 cache-store-value および cache-lookup-value ポリシーを使用して、キャッシュ アプローチを実装できます。 バックエンド検索に影響を与えるテナントを追加、削除、または移動するたびに、必ずキャッシュを無効にしてください。
名前付きの値
API Management は名前付きの値をサポートします。これはポリシー全体で使用できるカスタム構成設定です。 たとえば、名前付きの値を使用してテナントのバックエンド URL を格納し、その同じ値をポリシー内の複数の場所で再使用できます。 URL を更新する必要がある場合は、1 か所で更新できます。
警告
マルチテナント ソリューションでは、名前付きの値の名前を設定するときに注意が必要です。 設定がテナント間で異なる場合は、必ずテナント識別子を名前に含めてください。 たとえば、tenantId が要求に適していることを確認した後、tenantId-key:value のようなパターンを使用できます。
別のテナントに対する要求を処理するときに、誤って別のテナントの値を参照したり操作されたりする可能性を減らすために、識別子を含めます。
着信要求を認証する
API Management ゲートウェイに対して行われる API 要求は、通常は認証される必要があります。 API Management は、OAuth 2.0 証明書やクライアント証明書など、ゲートウェイへの着信要求を認証するいくつかの方法を提供します。 サポートする必要がある資格情報の種類と、検証される必要がある場所を検討してください。 たとえば、API Management、バックエンド アプリケーション、または両方の場所で検証を行う必要があるかどうかを検討します。
詳細については、「Azure API Management での API への認証と認可」を参照してください。
Note
サブスクリプション キーまたは API キーを使用する場合は、別の認証方法も使用することをお勧めします。
サブスクリプション キーだけでは強力な認証形式ではありませんが、個々のテナントの API 使用状況を追跡する場合など、他のシナリオに役立ちます。
テナント固有のバックエンドにルーティングする
API Management を共有コンポーネントとして使用するときは、着信 API 要求を別のテナント固有のバックエンドにルーティングすることが必要になる場合があります。 これらのバックエンドは、別のデプロイ スタンプにある場合も、単一スタンプ内の別のアプリケーションである場合もあります。 ポリシー定義でルーティングをカスタマイズするには、set-backend-service ポリシーを使用します。 要求のリダイレクト先の新しいベース URL を指定する必要があります。
応答またはその他のデータをキャッシュする
API Management には、HTTP 応答全体またはその他のデータをキャッシュするために使用できる強力なキャッシュ機能があります。 たとえば、カスタム ロジックを使用する場合、または外部サービスからマッピングを検索する場合に、テナント マッピングにキャッシュを使用できます。
cache-store-value および cache-lookup-value ポリシーを使用して、キャッシュ アプローチを実装します。
警告
マルチテナント ソリューションでは、キャッシュ キーを設定するときに注意してください。 キャッシュ データがテナント間で変わる可能性がある場合は、キャッシュ キーにテナント識別子を含めます。
識別子を含めることで、別のテナントに対する要求を処理するときに、誤って別のテナントの値を参照したり操作されたりする可能性を減らします。
カスタム ドメイン
API Management を使用して、API ゲートウェイと開発者ポータル用に独自のカスタム ドメインを構成します。 一部の階層では、ワイルドカード ドメインまたは複数の完全修飾ドメイン名 (FQDN) を構成できます。
Azure Front Door などのサービスと共に API Management を使用することもできます。 この種の構成では、Azure Front Door はカスタム ドメインとトランスポート層セキュリティ (TLS) 証明書を頻繁に処理し、単一のドメイン名を使用して API Management と通信します。 クライアントからの元の URL に、後の処理のために API Management インスタンスに送信する必要があるテナント情報が含まれている場合は、X-Forwarded-Host要求ヘッダーの使用を検討するか、Azure Front Door ルールを使用して情報を HTTP ヘッダーとして渡します。
転送率の制限
マルチテナント ソリューションでは、クォータまたはレート制限を適用するのが一般的です。 レート制限は、近隣ノイズの問題を軽減するのに役立ちます。 レート制限を使用して、サービス品質を適用したり、異なる価格レベルを区別したりすることもできます。
API Management を使用して、テナント固有のレート制限を適用します。 テナント固有のサブスクリプションを使用する場合は、クォータ ポリシーを使用して、サブスクリプションごとにクォータを適用することを検討してください。 または、quota-by-key ポリシーを使用して、要求 URL または JWT から取得したテナント識別子など、他のレート制限キーを使用してクォータを適用することを検討してください。
収益化
API Management のドキュメントは、サンプル実装を含む API の収益化に関する広範なガイダンスを提供します。 収益化のアプローチでは、開発者が API を公開し、サブスクリプションを管理し、さまざまな使用モデルに基づいて課金することができるように、API Management の多くの機能を組み合わせます。
キャパシティ管理
API Management インスタンスは、要求の処理に使用できるリソースを表す一定の容量をサポートします。 複雑なポリシーを使用したり、さらに多くの API をインスタンスにデプロイしたりすると、より多くの容量が消費されます。 インスタンスの容量は、ユニットを追加購入するなど、いくつかの方法で管理できます。 インスタンスの容量を動的にスケーリングすることもできます。
一部のマルチテナント インスタンスでは、要求をさまざまなテナント バックエンドにルーティングするために多くのポリシーを使用する場合など、シングルテナント インスタンスよりも多くの容量が消費される場合があります。 容量計画を慎重に検討し、使用量が増加する場合はインスタンスの容量をスケーリングすることを計画します。 また、ソリューションのパフォーマンスをテストして、容量のニーズを事前に把握しておく必要があります。
API Management のスケーリングの詳細については、「Azure API Management インスタンスのアップグレードとスケーリングを行う」を参照してください。
複数リージョンのデプロイ
API Management は、マルチリージョン デプロイをサポートしています。つまり、構成を別のリソースにレプリケートしなくても、複数の Azure リージョン全体に単一の論理 API Management リソースをデプロイできます。 この機能は、ソリューションをグローバルに配布またはレプリケートする際に特に役立ちます。 API Management インスタンスのフリートを、複数のリージョン全体に効果的にデプロイできます。これにより、待ち時間の短い要求処理が可能になり、それらを単一の論理インスタンスとして管理できます。
ただし、完全に分離された API Management インスタンスが必要な場合は、独立した API Management リソースを異なるリージョンにデプロイすることもできます。 このアプローチでは、API Management インスタンスごとに管理プレーンが分離されます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- John Downs | プリンシパル ソフトウェア エンジニア
- Daniel Scott-Raynsford | パートナー テクノロジ ストラテジスト、Global Partner Solutions
その他の共同作成者:
- Arsen Vladimirskiy | プリンシパル カスタマー エンジニア
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
マルチテナント ソリューションでの統合のアーキテクチャ アプローチを確認する。