編集

内部の API を外部ユーザーに公開する

Azure API Management
Azure Application Gateway
Azure DevOps
Azure Monitor
Azure Virtual Network

このシナリオでは、ある組織が、仮想ネットワーク内にデプロイされた Azure API Management を使用して複数の API を内部的に統合します。

アーキテクチャ

外部ユーザーによって使用される内部 API の完全なライフサイクルを示すアーキテクチャ図。

このアーキテクチャの Visio ファイルをダウンロードします。

上記の図は、外部ユーザーによって使用される内部 API の完全なライフサイクルをカバーしています。

データフロー

データ フローは次のとおりです。

  1. Azure VM にインストールされた CI/CD パイプライン エージェントに接続された GitHub リポジトリに開発者がコードをチェックインします。
  2. ILB ASE でホストされている API アプリケーションにエージェントがビルドをプッシュします。
  3. Azure API Management は、API Management ポリシーで指定された HOST ヘッダー経由で上記の API を使用します。
  4. API Management は、すべての API に対して App Service Environment の DNS 名を使用します。
  5. Application Gateway は API Management の開発者と Azure portal を公開します。
  6. Azure Private DNS は、ASE、API Management、および Application Gateway 間でトラフィックを内部的にルーティングするために使用されます。
  7. 外部ユーザーは、公開された開発者ポータルを利用して、Application Gateway のパブリック IP 経由で API を使用します。

Components

  • Azure Virtual Network により、Azure リソースは他の Azure リソース、インターネット、およびオンプレミス ネットワークと安全に通信できます。
  • Azure プライベート DNS を使用すると、カスタム DNS ソリューションを追加しなくても、仮想ネットワーク内でドメイン名を解決できるようになります。
  • Azure API Management は、組織が API を外部、パートナー、および内部の開発者に公開して、その組織のデータやサービスを使用できるようにするために役立ちます。
  • Application Gateway は、Web アプリケーションへのトラフィックを管理するために役立つ Web トラフィック ロード バランサーです。
  • 内部ロード バランサーの App Service Environment は、App Service アプリを大規模かつ安全に実行するための完全に分離された専用環境を提供する Azure App Service の機能です。
  • Azure DevOps は、開発ライフサイクルを管理するためのサービスであり、計画とプロジェクト管理、コード管理、ビルド、およびリリースのための機能が含まれています。
  • Application Insights は、複数のプラットフォームで使用できる Web 開発者向けの拡張可能なアプリケーション パフォーマンス管理 (APM) サービスです。
  • Azure Cosmos DB は、Microsoft のグローバル分散型のマルチモデル データベース サービスです。

代替

シナリオの詳細

このシナリオでは、ある組織が既に Azure Application Service Environments (ILB ASE) を使用して複数の API をホストしており、ここで Virtual Network 内にデプロイされた Azure API Management (APIM) を使用して、これらの API を内部的に統合したいと考えています。 API の潜在能力を最大限に活用できるよう、内部の API Management インスタンスを外部ユーザーに公開することもできます。 この外部への公開は、Azure Application Gateway を使用して要求を内部の API Management サービスに転送し、次にそのサービスが ASE にデプロイされた API を使用することによって達成できます。

  • Web API は、セキュリティで保護された HTTPS プロトコル経由でホストされ、TLS 証明書を使用します。
  • セキュリティで保護された信頼できるアウトバウンド呼び出しのために、ポート 443 で Application Gateway も構成されます。
  • API Management サービスは、TLS 証明書を使用してカスタム ドメインを使用するように構成されます。
  • App Service Environment に推奨されるネットワーク構成を確認します。
  • Azure portal または PowerShell を使用して管理するには、API Management を許可するポート 3443 についての明示的な言及が必要です。
  • APIM 内のポリシーを利用して、ASE でホストされている API の HOST ヘッダーを追加します。 これにより、ASE のロード バランサーが要求を正しく転送することが保証されます。
  • API Management は、App Service Environment 下でホストされているすべてのアプリについて ASE の DNS エントリを受け入れます。 APIM ポリシーを追加して HOST ヘッダーを明示的に設定することによって、ASE ロード バランサーが App Service Environment の下にあるアプリを区別できるようにします。
  • 監視のために Azure Monitor を介してメトリックに接続することもできる Azure Application Insights との統合を検討してみてください。
  • 内部 API をデプロイするために CI/CD パイプラインを使用している場合は、Virtual Network 内の 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 と ASE は既に、セキュリティで保護されたインフラストラクチャ (Azure VNet) にデプロイされています。 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 の自動スケーリングに関連したパブリック プレビュー機能を参照してください。

このシナリオのデプロイ

前提条件と想定

  1. カスタム ドメイン名を購入する必要があります。
  2. すべてのカスタム ドメインに使用するための TLS 証明書 (Azure Certificates Service からのワイルドカード証明書を使用しました) が必要です。 開発テストのシナリオ用の自己署名証明書を購入することもできます。
  3. この特定のデプロイでは、ドメイン名 contoso.org と、そのドメイン用のワイルドカード TLS 証明書を使用します。
  4. デプロイでは、「デプロイ」セクションで説明されているリソース名とアドレス空間が使用されます。 リソース名とアドレス空間を構成できます。

デプロイと統合

Azure へのデプロイ

前の Resource Manager テンプレートを使用してデプロイされたコンポーネントをさらに次のように構成する必要があります。

  1. 次の構成の VNet:

    • 名前: ase-internal-vnet
    • VNet のアドレス空間:10.0.0.0/16
    • 4 つのサブネット
      • DNS サービス用の backendSubnet: 10.0.0.0/24
      • 内部の API Management サービス用の apimsubnet: 10.0.1.0/28
      • ILB ASE 用の asesubnet: 10.0.2.0/24
      • テスト VM および内部 DevOps ホステッド エージェント VM 用の VMSubnet:10.0.3.0/24

  2. DNS サービス追加以降の Private DNS サービス (パブリック プレビュー) では VNet が空である必要があります。

  3. 内部ロード バランサー (ILB) オプション付きの App Service Environment:: aseinternal (DNS: aseinternal.contoso.org)。 デプロイが完了したら、ILB 用のワイルドカード証明書をアップロードします

  4. 場所が ASE の App Service プラン

  5. API アプリ (例: App Services) - srasprest (URL: https://srasprest.contoso.org) – ASP.NET MVC ベース Web API。 デプロイ後、次のように構成します

    • TLS 証明書を使用する Web アプリ
    • 上記アプリへの Application Insights: api-insights
    • VNet の内部でホストされている Web API 用の Azure Cosmos DB サービスを作成します: noderestapidb
    • 作成した Private DNS ゾーンに DNS エントリを作成します
    • Azure Pipelines を利用して、Virtual Machines 上でエージェントを構成し、Web アプリのコードを内部ネットワークにデプロイすることができます
    • API アプリを内部でテストするには、VNet サブネット内にテスト VM を作成します

  6. API Management サービスの作成: apim-internal

  7. サブネット apimsubnet 上の内部 VNet に接続するよう、サービスを構成します。 デプロイが完了したら、以下の追加手順を実行します

    • TLS を使用して、APIM サービス用のカスタム ドメインを構成します
      • API ポータル (api.contoso.org)
      • 開発ポータル (portal.contoso.org)
      • [APIs] セクションで、ASE の DNS 名、Web アプリの HOST ヘッダー用に追加されたポリシーを使用して ASE アプリを構成します
      • 作成した上記のテスト VM を使用して、Virtual Network の内部にある API Management サービスをテストします

    注意

    api.contoso.org をパブリックに解決できないため、Azure portal からの APIM API のテストは機能しません。*

  8. API サービス: apim-gateway にポート 80 でアクセスするように Application Gateway (WAF V1) を構成します。 Application Gateway への TLS 証明書と、対応する正常性プローブおよび HTTP 設定を追加します。 TLS 証明書を使用するための規則とリスナーも構成します。

上記の手順が正常に完了したら、Application Gateway のパブリック DNS 名 ase-appgtwy.westus.cloudapp.azure.com を使用して、api.contoso.org と portal.contoso.org の Web レジストラー CNAME エントリの DNS エントリを構成します。 パブリックから Dev Portal にアクセスできること、および Azure portalを使用して APIM サービス API をテストできることを確認します。

注意

APIM サービスの内部エンドポイントと外部エンドポイントに同じ URL を使用することはお勧めしません (ただし、このデモでは両方の URL は同じです)。 内部エンドポイントと外部エンドポイントで異なる URL を使用する場合、HTTP リダイレクトなどをサポートする App Gateway WAF v2 を利用できます。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は次のとおりです。

プリンシパル作成者:

その他の共同作成者:

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

Azure API Management を使用して Web アプリを移行する