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 virtual IP (VIP) のみを許可するように (Azure App Service の Web Apps 機能の設定を介して) 構成されます。
    • セキュリティで保護されたトランスポート (HTTPS または SSL) が有効になっている Web Apps でホストされています。
    • Microsoft Entra ID と Open Authorization (OAuth) 2 を介して Azure App Service により提供される認証が有効になっています。
  5. 新しいブラウザーベースの Web アプリケーションは、既存の HTTP API と新しい API の 両方 のために Azure API Management インスタンスに依存します。
  6. 旅行業界の eコマース企業は、以前の UI と既存の機能を並行して保持したまま、一部のユーザーに (プレビュー用またはテスト用の) 新しい UI を表示できるようになりました。

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

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

コンポーネント

  • Azure API Management は、バックエンド API を抽象化するだけでなく、開発者やアプリケーション向けに横断的な機能と検出機能も追加します。 このシナリオでは、新しいクライアント アプリケーションで一貫して使用できるファサードとして API Management を使用し、また最新の標準を使用することにより、既存のレガシ バックエンド API の再構成と新しい API 機能の追加が可能になります。 API Management は既存の API と新しい API の両方のファサードとして機能するため、開発者は API Management ファサードの背後にあるレガシ バックエンドを反復的に最新化し、新しいフロント エンド開発への影響を最小限またはゼロに抑えることができます。
  • Azure App Service は、セキュリティ、負荷分散、自動スケーリング、自動管理など、すぐに使用できる機能が用意されている、Web ホスティング用のターンキー PaaS (サービスとしてのプラットフォーム) サービスです。 柔軟なターンキー ホスティングを利用でき、DevOps チームが機能の実現に専念できるため、Azure App Service はこのソリューション用に開発される新しい API に最適です。

代替

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

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

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

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

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

シナリオの詳細

旅行業界の eコマース企業は、従来のブラウザーベースのソフトウェア スタックを最新化しています。 既存のスタックはほとんどモノリシックですが、最近のプロジェクトには Simple Object Access Protocol (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」を参照してください。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

  • 可用性ゾーンが有効になっている Azure API Management インスタンスをデプロイすることを検討してください。 API Management を可用性ゾーンにデプロイするオプションは、Premium サービス レベルでのみ使用できます。
  • 可用性ゾーンは、異なるリージョンにデプロイされた追加のゲートウェイ インスタンスと組み合わせて使用できます。 これにより、1 つのリージョンがオフラインになった場合でもサービスの可用性が向上します。 マルチリージョン デプロイも、Premium サービス レベルでのみ使用できます。
  • 監視のために Azure Monitor を介してメトリックに接続することもできる Azure Application Insights との統合を検討してみてください。 たとえば、容量メトリックを使用して、API Management リソースの全体的な負荷と、追加のスケールアウト ユニットが必要かどうかを判断できます。 リソースの容量と正常性を追跡すると、信頼性が向上します。
  • ダウンストリームの依存関係 (API Management がファサードとして機能する API をホストしているバックエンド サービスなど) も回復性があることを確認します。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

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

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

注意

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

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

共同作成者

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

プリンシパル作成者:

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

次の手順

製品ドキュメント:

Learn モジュール: