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

このシナリオでは、旅行業界の e コマース企業が、Azure API Management を使用してレガシ Web アプリを移行します。 この会社では、新しい UI をサービスとしてのプラットフォーム (PaaS) アプリとして Azure でホストしています。 新しい UI は、既存の HTTP API と新しい HTTP API の両方に依存します。 これらの API は、パフォーマンスを向上させ、統合を簡素化し、将来の拡張性を可能にする、より効果的に設計されたインターフェイスを使用してデプロイします。

Architecture

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

Workflow

次のワークフローは、上記のダイアグラムに対応しています。

1. 既存のオンプレミス Web アプリは、引き続き既存のオンプレミス Web サービスを直接使用します。

2. 既存の Web アプリから既存の HTTP サービスへの呼び出しは変わりません。 このような呼び出しは、企業ネットワークの内部で行われます。

3. API Management は、Azure から既存の内部サービスへの呼び出しを行います。

   • セキュリティ チームは、トランスポート層セキュリティ (TLS) 経由のハイパーテキスト転送プロトコル Secure (HTTPS) などの セキュリティで保護されたトランスポート プロトコルを使用して 、API Management インスタンスからのトラフィックが企業のファイアウォールを通過して既存のオンプレミス サービスに通過できるようにします。

   • 運用チームは、API Management インスタンスからサービスへの受信呼び出しのみを許可します。 企業ネットワーク境界内 の許可リストに API Management インスタンスの IP アドレスを追加することで、 この要件を満たします。

   • ハイパーテキスト転送プロトコル (HTTP) サービスのオンプレミス要求パイプラインの新しいモジュールは、外部から発信された接続でのみ機能します。 パイプラインは 、API Management によって提供される証明書を検証します。

4. 新しい API には、次の特性があります。

   • API ファサードを提供する API Management インスタンスのみが、新しい API を表示します。 新しい API には直接アクセスしません。

   • 新しい API を開発し、 Azure PaaS Web API アプリとして発行します。

   • 新しい API を設定するには、 Azure App Service の Web Apps 機能の設定を 使用して、 API Management 仮想 IP (VIP) のみを受け入れます。

   • Web Apps は、HTTPS や TLS などのセキュリティで保護されたトランスポート プロトコルが有効になっている新しい API をホストします。

   • Azure App Service には、Microsoft Entra ID と Open Authorization (OAuth) 2 を使用した承認機能が用意されています。

5. 新しいブラウザー ベースの Web アプリは、既存の HTTP API と新しい API の両方の API Management インスタンスに依存します。

6. 旅行の e コマース企業は、一部のユーザーをプレビューまたはテスト用の新しい UI に誘導しながら、古い UI と既存の機能を並べて保持できます。

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

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

Components

• API Management は、すべての環境にわたる API の管理プラットフォームとゲートウェイです。 このアーキテクチャでは、既存のレガシ API と新しい API の ファサード として機能します。 新しいクライアント アプリは 1 つの一貫性のあるインターフェイスを使用します。チームは、フロントエンド開発への影響を最小限に抑えながら、そのファサードの背後にあるレガシ バックエンドを段階的に最新化できます。

• App Service は、セキュリティ、負荷分散、自動スケール、自動管理などのすぐに使用できる機能を提供する Web ホスティング用のターンキー PaaS ソリューションです。 このアーキテクチャでは、DevOps チームが機能の配信に集中できるように、App Service は柔軟なターンキー ホスティングを提供します。

Alternatives

• 組織がレガシ アプリを完全にホストする仮想マシン (VM) を含むインフラストラクチャを Azure に移行することを計画している場合、API Management は、アドレス指定可能な任意の HTTP エンドポイントのファサードとして機能できます。

• 組織が既存のエンドポイントをプライベートに保ち、パブリックに公開しない場合、組織の API Management インスタンスは Azure 仮想ネットワークにリンクできます。

  • API Management が Azure 仮想ネットワークにリンクされている場合、組織はプライベート IP アドレスを使用してバックエンド サービスに直接対処できます。

  • オンプレミスのシナリオでは、API Management インスタンスは、 Azure VPN Gateway とサイト間インターネット プロトコル セキュリティ (IPsec) VPN 接続 または Azure ExpressRoute 経由で内部サービスにプライベートに接続できます。 このシナリオは、 Azure とオンプレミスのハイブリッドになります。

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

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

  セルフホステッド ゲートウェイは、送信ソケットで Azure に接続する API Management ゲートウェイのコンテナー化されたデプロイです。 セルフホステッド ゲートウェイを使用するには、次の前提条件を満たす必要があります。

  • Azure で親リソースを使用してセルフホステッド ゲートウェイをデプロイする必要があり、追加コストが発生します。

  • API Management の Premium レベルを使用する必要があります。

シナリオの詳細

旅行業界の e コマース企業は、従来のブラウザー ベースのソフトウェア スタックを最新化したいと考えています。 既存のスタックはほとんどモノリシックですが、最近のプロジェクトから 一部の Simple Object Access Protocol (SOAP) ベースの HTTP サービス が存在します。 同社は、内部知的財産の一部を収益化するために、追加の収益ストリームを作成することを検討しています。

このプロジェクトの目標には、技術的負債への対処、継続的なメンテナンスの改善、回帰バグを減らした機能開発の高速化が含まれます。 このプロジェクトでは、リスクを回避するために反復的なプロセスを使用し、次の手順を並行して実行します。

• 開発チームは、VM でホストされているリレーショナル データベースで構成されるアプリのバックエンドを最新化します。

• 社内開発チームは、新しいビジネス機能を記述し、新しい HTTP API 経由で公開します。

• コントラクト開発チームは、Azure がホストする新しいブラウザー ベースの UI を構築します。

この会社では、新しいアプリ機能を段階的に提供しています。 これらの機能は、会社の e コマース ビジネスを推進するオンプレミスでホストされている既存のブラウザー ベースのクライアントおよびサーバー UI 機能を徐々に置き換えます。

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

考えられるユース ケース

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

このシナリオは、次のタスクに使用できます。

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

Considerations

これらの考慮事項では、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「 Well-Architected Framework」を参照してください。

Reliability

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の 設計レビュー チェックリスト」を参照してください。

• API Management インスタンスをデプロイするときに 可用性ゾーン をアクティブ化します。 API Management を可用性ゾーンにデプロイするオプションは、Premium サービス レベルでのみ使用できます。

• 別のリージョンにデプロイされた追加のゲートウェイ インスタンスがある可用性ゾーンを使用します。 この組み合わせにより、1 つのリージョンがオフラインになった場合のサービスの可用性が向上します。 マルチリージョンデプロイは、Premium サービス レベルでのみ使用できます。

• 監視のために Azure Monitor を通じてメトリックを表示する Application Insights と統合します。 たとえば、容量メトリックを使用して、API Management リソースの全体的な負荷と、 より多くのスケールアウト ユニットが必要かどうかを判断できます。 信頼性を向上させるために、リソースの容量と正常性を追跡します。

• API Management がカバーする API をホストするバックエンド サービスなどのダウンストリームの依存関係も回復性があることを確認します。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「 コストの最適化」のデザイン レビュー チェックリストを参照してください。

API Management には、次の 8 つのレベルがあります。

• 従量課金
• Developer
• Basic と Basic v2
• Standard および Standard v2
• Premium および Premium v2

これらのレベルの違いの詳細については、「 API Management の価格」を参照してください。

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

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

Contributors

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要著者:

• Ben Gimblett |シニア カスタマー エンジニア

その他の共同作成者:

• Andrew Cardy |シニア ソフトウェア エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• App Service の概要
• API Management の概要
• App Service でステージング環境を設定する
• API の変換と保護
• App Service を探索する

関連リソース

• API Management と GitHub を使用して優れた API 開発者エクスペリエンスを設計する