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

Azure API Management
Azure Monitor
Azure App Service

このシナリオでは、旅行業界の eコマース企業が、Azure API Management を使用して従来の Web アプリケーションを移行します。 新しい UI は、Azure 上のサービスとしてのプラットフォーム (PaaS) としてホストされ、既存と新規の HTTP API の両方に応じて変わります。 これらの API は、パフォーマンスの向上、統合の簡易化、将来的な拡張性を可能にする、より望ましい設計のインターフェイスと共にリリースされます。

アーキテクチャ

アーキテクチャの図

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

ワークフロー

  1. 既存のオンプレミス Web アプリは、引き続き既存のオンプレミス Web サービスを直接消費します。
  2. 既存の Web アプリから既存の HTTP サービスへの呼び出しは変わりません。 このような呼び出しは、企業ネットワークの内部で行われます。
  3. 受信呼び出しは、Azure から既存の内部サービスに対して行われます。
  4. 新しい API:
    • API Management インスタンスを介してのみ公開され、API ファサードを提供します。 新しい API は直接アクセスされません。
    • Azure PaaS Web API アプリとして開発、公開されます。
    • API Management 仮想 IP のみを受け入れるように (Azure App Service の Web Apps 機能の設定を介して) 構成されます。
    • セキュリティで保護されたトランスポート (HTTPS または SSL) が有効になっている Web Apps でホストされています。
    • Microsoft Entra ID と OAuth 2 を介して Azure App Service により提供される認可が有効になっています。
  5. 新しいブラウザーベースの Web アプリケーションは、既存の HTTP API と新しい API の両方のために Azure API Management インスタンスに依存します。

API Management インスタンスは、レガシ HTTP サービスを新しい API コントラクトにマップするように構成されます。 この構成では、新しい Web UI は、一連のレガシ サービス/API と新しい API との統合を認識していません。

今後、プロジェクト チームは段階的に機能を新しい API に移植し、元のサービスを廃止します。 チームは、API Management 構成内でこれらの変更を処理するので、フロントエンド UI は影響を受けず、再開発作業が回避されます。

コンポーネント

代替

  • 組織が、レガシ アプリケーションをホストしている VM を含め、インフラストラクチャを完全に Azure に移行することを予定していても、API Management は、アドレス指定可能な HTTP エンドポイントのファサードとして機能することができるため、優れた選択肢になります。

  • 組織が既存のエンドポイントを非公開なままにして公開しないと決めた場合、組織の API Management インスタンスを Azure 仮想ネットワークにリンクできます:

  • 組織では、内部モードでデプロイすることで、API Management インスタンスを非公開に保つことができます。 その後組織は、Azure Application Gateway を使ったデプロイを使用して、一部の API のパブリック アクセスを可能にしながら、その他を内部のままにすることができます。 詳細については、「内部仮想ネットワーク内の API Management を Application Gateway と統合する」を参照してください。

  • 組織は、オンプレミスで API をホストすることを決定する場合があります。 この変更の理由の 1 つは、このプロジェクトのスコープ内にあるダウンストリーム データベースの依存関係をクラウドに移動できなかったことが考えられます。 その場合でも、組織はセルフホステッド ゲートウェイを使用してローカルで API Management を利用できます。

    セルフホステッド ゲートウェイは、送信ソケットで Azure に接続する API Management ゲートウェイのコンテナー化されたデプロイです。 1 つ目の前提条件は、Azure に親リソースがない場合、セルフホステッド ゲートウェイをデプロイできないことです。この場合、追加料金が発生します。 2 つ目は、API Management の Premium レベルが必要なことです。

Note

API Management を仮想ネットワークに接続するための一般的な情報については、こちらを参照してください

シナリオの詳細

旅行業界の eコマース企業は、従来のブラウザーベースのソフトウェア スタックを最新化しています。 既存のスタックはほとんどモノリシックですが、最近のプロジェクトには SOAP ベースの HTTP サービスもいくつかあります。 会社は、開発した内部の知的財産の一部を収益化するために、追加の収益源を作り出すことを検討しています。

このプロジェクトの目標は、技術的な負債に対処し、継続的なメンテナンスを改善し、回帰バグの少ない機能開発を加速することです。 このプロジェクトでは、反復プロセスを使用してリスクを回避し、いくつかの手順を並行して実行します。

  • 開発チームは、アプリケーション バック エンドを最新化しています。これは、VM 上でホストされるリレーショナル データベースから構成されます。
  • 社内開発チームは、新しい HTTP API を介して公開される新しいビジネス機能を作成します。
  • 契約開発チームは、Azure でホストされる新しいブラウザーベースの UI を構築します。

新しいアプリケーション機能が段階的に提供されます。 これらの機能により、現在会社の e コマース ビジネスを強化している既存のブラウザーベースのクライアント/サーバー UI 機能 (オンプレミスでホストされている機能) が段階的に置き換えられます。

管理チームのメンバーは、不必要に最新化することを望んでいません。 また、範囲とコストの管理を維持することを望んでいます。 この目的のために、既存の SOAP HTTP サービスを保持することに決めました。 また、既存の UI の変更を最小限に抑えるつもりです。 Azure API Management を使用して、プロジェクトの要件や制約の多くに対処できます。

考えられるユース ケース

このシナリオでは、従来のブラウザー ベースのソフトウェア スタックの最新化について説明します。

このシナリオは、次の目的で使用できます。

  • Azure エコシステムを活用することで、ビジネスにどのようなベネフィットが得られるかをご覧ください。
  • Azure へのサービスの移行を計画します。
  • Azure への移行が既存の API にどのように影響するかについて説明します。

考慮事項

これらの考慮事項には、ワークロードの品質を向上させる一連の基本原則である Azure Well-Architected Framework の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

可用性とスケーラビリティ

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を見つけることです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

API Management は、Developer、Basic、Standard、Premium の 4 つのレベルで提供されています。 これらのレベルの違いの詳細については、「Azure API Management の価格ガイダンス」を参照してください。

ユニットの追加や削除を行うことにより、API Management をスケーリングできます。 各ユニットのキャパシティは、そのレベルによって異なります。

注意

Developer レベルは、API Management 機能の評価に使用できます。 運用環境では使用しないでください。

予想されるコストを表示し、デプロイのニーズに合わせてカスタマイズするには、Azure 料金計算ツールでスケール ユニットと App Service インスタンスの数を変更します。

このシナリオのデプロイ

まず、ポータルで Azure API Management インスタンスを作成します。

または、特定のユース ケースに合わせて既存の Azure Resource Manager クイックスタート テンプレートから選択することもできます。

共同作成者

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

プリンシパル作成者:

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

次の手順

製品ドキュメント:

Learn モジュール: