このシナリオでは、組織は、仮想ネットワーク内にデプロイされた Azure API Management を使用して、複数の API を内部的に統合します。
アーキテクチャ
このアーキテクチャの Visio ファイルをダウンロードします。
上記の図は、外部ユーザーによって使用される内部 API の完全なライフサイクルをカバーしています。
データフロー
データ フローは次のとおりです。
- Azure VM にインストールされた CI/CD パイプライン エージェントに接続された GitHub リポジトリに開発者がコードをチェックインします。
- エージェントは、ILB App Service Environment でホストされている API アプリケーションにビルドをプッシュします。
- Azure API Management は、API Management ポリシーで指定された HOST ヘッダー経由で上記の API を使用します。
- API Management では、すべての API に App Service Environment DNS 名が使用されます。
- Application Gateway は、API Management 開発者ポータルと API ポータルを公開します。
- Azure プライベート DNSは、App Service Environment、API Management、Application Gateway の間でトラフィックを内部的にルーティングするために使用されます。
- 外部ユーザーは、公開されている開発者ポータルを使用して、Application Gateway パブリック IP 経由で API を使用します。
コンポーネント
- Azure Virtual Network により、Azure リソースは他の Azure リソース、インターネット、およびオンプレミス ネットワークと安全に通信できます。
- Azure プライベート DNS を使用すると、カスタム DNS ソリューションを追加しなくても、仮想ネットワーク内でドメイン名を解決できるようになります。
- Azure API Management は、組織が API を外部、パートナー、および内部の開発者に公開して、その組織のデータやサービスを使用できるようにするために役立ちます。
- Application Gateway は、Web アプリケーションへのトラフィックを管理するために役立つ Web トラフィック ロード バランサーです。
- 内部ロード バランサー App Service Environment は、App Service アプリを大規模に安全に実行するための完全に分離された専用の環境を提供するAzure アプリ サービス機能です。
- Azure DevOps は、開発ライフサイクルを管理するためのサービスであり、計画とプロジェクト管理、コード管理、ビルド、およびリリースのための機能が含まれています。
- Application Insights は、複数のプラットフォームで使用できる Web 開発者向けの拡張可能なアプリケーション パフォーマンス管理 (APM) サービスです。
- Azure Cosmos DB は、Microsoft のグローバル分散型のマルチモデル データベース サービスです。
代替
- Azure のリフト アンド シフト シナリオでは Azure 仮想ネットワークにデプロイされ、バックエンド サーバーはプライベート IP アドレスを介して直接アドレス指定できます。
- オンプレミス リソースを使用している場合、API Management インスタンスは、Azure VPN Gateway とサイト間インターネット プロトコル セキュリティ (IPSec) VPN 接続または ExpressRoute を介して内部サービスにプライベートに戻りハイブリッド Azure とオンプレミスのシナリオを作成できます。
- Azure ベースの DNS サービスの代わりに、既存またはオープンソースの DNS プロバイダーを使用することもできます。
- Azure の外部にデプロイされた内部 API は、API Management Service を通じて API を公開することで、引き続きメリットが得られます。
シナリオの詳細
このシナリオでは、組織は Azure アプリlication Service Environment (ILB App Service Environment) を使用して複数の API をホストし、仮想ネットワーク内にデプロイ Azure API Management (APIM) を使用してこれらの API を内部的に統合したいと考えています。 API の潜在能力を最大限に活用できるよう、内部の API Management インスタンスを外部ユーザーに公開することもできます。 この外部公開は、Azure アプリlication Gateway を使用して実現できます内部 API Management サービスに要求を転送すると、App Service Environment にデプロイされた API が使用されます。
- Web API は、セキュリティで保護された HTTPS プロトコル経由でホストされ、TLS 証明書を使用します。
- また、アプリケーション ゲートウェイは、セキュリティで保護された信頼性の高い送信呼び出し用にポート 443 経由で構成されます。
- API Management サービスは、TLS 証明書を使用してカスタム ドメインを使用するように構成されます。
- App Service Environment に推奨されるネットワーク構成を確認します。
- Azure portal または PowerShell を使用して管理するには、API Management を許可するポート 3443 についての明示的な言及が必要です。
- APIM 内のポリシーを使用して、App Service Environment でホストされている API の HOST ヘッダーを追加します。 これにより、App Service Environment ロード バランサーが要求を適切に転送できるようになります。
- API Management は、App Service Environment でホストされているすべてのアプリの App Service Environment DNS エントリを受け入れます。 APIM ポリシーを追加 App Service Environment ロード バランサーが App Service Environment の下でアプリを区別できるように、HOST ヘッダーを明示的に設定します。
- 監視のために Azure Monitor を介してメトリックに接続することもできる Azure Application Insights との統合を検討してみてください。
- 内部 API のデプロイに CI/CD パイプラインを使用する場合は、仮想ネットワーク内 VM に独自のホステッド エージェントを構築検討してください。
考えられるユース ケース
- 顧客が変更を加えた後に、顧客の住所情報を内部的に同期する。
- 独自のデータ資産を公開することで開発者をプラットフォームに引き付ける。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。
可用性
可用性を向上させるため、さらに待機時間を削減するために、Azure API Management サービスを複数リージョン デプロイとしてデプロイできます。 この機能はプレミアム モードでのみ使用できます。 この特定のシナリオの API Management サービスは、App Service Environment からの API を使用します。 内部のオンプレミス インフラストラクチャでホストされている API 用に APIM を使用することもできます。
App Service Environment は、Traffic Manager プロファイルを使用して App Service Environment でホストされているトラフィックを分散させることにより、スケールと可用性を向上させることができます。
回復性
このシナリオ例では構成の方を詳しく説明していますが、App Service Environment でホストされる API は、要求のエラーを処理するのに十分な回復性を備えている必要があり、これは最終的には API Management サービスと Application Gateway によって管理されます。 API 設計で再試行とサーキット ブレーカー パターンを検討してください。 回復性に優れたソリューションの設計に関する一般的なガイダンスについては、回復性に優れた Azure 用アプリケーションの設計に関するページを参照してください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
上記の例のシナリオは完全に内部ネットワークでホストされているため、API Management と App Service Environment は既にセキュリティで保護されたインフラストラクチャ (Azure Virtual Network) デプロイされています。 Application Gateway を Microsoft Defender for Cloud と統合することにより、環境への脅威を防止および検出して、それに対応するためのシームレスな方法を提供できます。 セキュリティで保護されたソリューションの設計に関する一般的なガイダンスについては、「Azure のセキュリティのドキュメント」を参照してください。
コスト最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
API Management は、Developer、Basic、Standard、Premium の 4 つのレベルで提供されています。 これらのレベルの違いの詳細については、こちらの Azure API Management の価格ガイダンスを参照してください。
お客様はユニットの追加や削除を行うことにより、API Management をスケーリングできます。 各ユニットのキャパシティは、そのレベルによって異なります。
注意
Developer レベルは、API Management 機能の評価に使用できます。 運用環境では Developer レベルを使用しないでください。
予想されるコストを表示し、デプロイのニーズに合わせてカスタマイズするには、Azure 料金計算ツールでスケール ユニットと App Service インスタンスの数を変更します。
同様に、App Service Environment の価格ガイダンスをここで参照できます。
Application Gateway の価格は、必要なレベルとリソースに応じて構成できます。
パフォーマンス効率
パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。
スケーラビリティ
API Management インスタンスは、コンカレント接続の数と速度、構成されているポリシーの種類と数、要求と応答のサイズ、API でのバックエンド待機時間などのさまざまな要因に応じてスケールアウトできます。 インスタンスのスケールアウト オプションは、Basic、Standard、および Premium レベルで使用できますが、Basic と Standard のレベルではスケール上限の制約を受けます。 インスタンスはユニットと呼ばれ、Basic レベルで最大 2 ユニット、Standard レベルで最大 4 ユニット、Premium レベルで任意の数のユニットまでスケールアップできます。 また、規則に基づいたスケールアウトを可能にするために、自動スケーリング オプションも使用できます。
Azure App Service Environment は、価格レベルに基づく制限を使用してスケーリングするように設計されています。 App Service Environment の下にホストされているアプリは、アプリケーションの要件に応じてスケールアウトする (インスタンスの数) か、またはスケールアップする (インスタンス サイズ) ように構成できます。
Azure Application Gateway の自動スケーリングは、すべてのグローバル Azure リージョンでゾーンの冗長 SKU の一部として利用できます。 App Gateway の自動スケーリングに関連したパブリック プレビュー機能を参照してください。
このシナリオのデプロイ
前提条件と想定
- カスタム ドメイン名を購入する必要があります。
- すべてのカスタム ドメインに使用するための TLS 証明書 (Azure Certificates Service からのワイルドカード証明書を使用しました) が必要です。 開発テストのシナリオ用の自己署名証明書を購入することもできます。
- この特定のデプロイでは、ドメイン名 contoso.org と、そのドメイン用のワイルドカード TLS 証明書を使用します。
- デプロイでは、「デプロイ」セクションで説明されているリソース名とアドレス空間が使用されます。 リソース名とアドレス空間を構成できます。
デプロイと統合
前の Resource Manager テンプレートを使用してデプロイされたコンポーネントをさらに次のように構成する必要があります。
次の構成の仮想ネットワーク:
- 名前:
ase-internal-vnet
- 仮想ネットワークのアドレス空間: 10.0.0.0/16
- 4つのサブネット
- DNS サービス用の
backendSubnet
: 10.0.0.0/24 - 内部の API Management サービス用の
apimsubnet
: 10.0.1.0/28 asesubnet
ILB App Service Environment の場合: 10.0.2.0/24- テスト VM および内部 DevOps ホステッド エージェント VM 用の VMSubnet:10.0.3.0/24
- DNS サービス用の
- 名前:
プライベート DNS サービス (パブリック プレビュー) は、DNS サービスを追加するには仮想ネットワークが空である必要があるためです。
- 詳細については、デプロイ ガイドラインを参照してください。
App Service Environment with Internal Load Balancer (ILB) オプション:
aseinternal
(DNS:aseinternal.contoso.org
)。 デプロイが完了したら、ILB 用のワイルドカード証明書をアップロードしますApp Service Environment を場所として使用する App Service プラン
API アプリ (わかりやすくするために App Service) -
srasprest
(URL:https://srasprest.contoso.org
) - ASP.NET Model-View-Controller (MVC) ベースの Web API。 デプロイ後、次のように構成します- TLS 証明書を使用する Web アプリ
- 上記のアプリに対する Application Insights:
api-insights
- 仮想ネットワークの内部でホストされる Web API 用の Azure Cosmos DB サービスを作成します。
noderestapidb
- 作成された Azure プライベート DNS ゾーンに DNS エントリを作成する
- Azure Pipelines を利用して、Virtual Machines 上でエージェントを構成し、Web アプリのコードを内部ネットワークにデプロイすることができます
- API アプリを内部でテストする場合は、仮想ネットワーク サブネット内にテスト VM を作成します
API Management サービスの作成:
apim-internal
サブネット上の内部仮想ネットワークに接続するようにサービスを構成します:
apimsubnet
。 デプロイが完了したら、以下の追加手順を実行します- TLS を使用して、APIM サービス用のカスタム ドメインを構成します
- API ポータル (
api.contoso.org
) - Dev ポータル (
portal.contoso.org
) - [API] セクションで、App Service Environment DNS 名を使用して App Service Environment Apps を構成し、Web アプリの HOST ヘッダーのポリシーを追加します
- 作成した上記のテスト VM を使用して、Virtual Network の内部にある API Management サービスをテストします
- API ポータル (
Note
api.contoso.org
はパブリックに解決できないため、Azure portal からの APIM API のテストは機能しません。*- TLS を使用して、APIM サービス用のカスタム ドメインを構成します
API サービス (ポート 80 で
apim-gateway
) にアクセスするようにアプリケーション ゲートウェイを構成します。 アプリケーション ゲートウェイと、対応する正常性プローブと HTTP 設定に TLS 証明書を追加します。 TLS 証明書を使用するための規則とリスナーも構成します。
上記の手順が正常に完了したら、api.contoso.org
の Web レジストラー CNAME エントリに DNS エントリを構成し、Application Gateway のパブリック DNS 名 (ase-appgtwy.westus.cloudapp.azure.com
) を使用してportal.contoso.org
します。 パブリックから Dev Portal にアクセスできること、および Azure portalを使用して APIM サービス API をテストできることを確認します。
Note
APIM サービスの内部エンドポイントと外部エンドポイントに同じ URL を使用することはお勧めできません。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は次のとおりです。
プリンシパル作成者:
- Srikant Sarwa | シニア カスタマー エンジニア
その他の共同作成者:
- Shawn Kupfer |テクニカル ライター
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。