この参照アーキテクチャでは、Azure Integration Services を使用して、エンタープライズ バックエンド システムへの呼び出しを調整します。 バックエンド システムには、サービスとしてのソフトウェア (SaaS) システム、Azure サービス、およびご自身の企業内の既存の Web サービスが含まれる場合があります。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
アプリケーションを
します。 アプリケーションは、Microsoft Entra で認証した後に API ゲートウェイを呼び出すクライアントです。 アプリケーションには、Web アプリ、モバイル アプリ、または HTTP 要求を行うことができるその他のクライアントを指定できます。 Microsoft Entra ID。 クライアント アプリケーションを認証するために使用されます。 クライアント アプリケーションは、Microsoft Entra ID からアクセス トークンを取得し、API ゲートウェイへの要求に含めます。
Azure API Management。 API Management は、次の 2 つの関連するコンポーネントで構成されます。
API ゲートウェイ。 API ゲートウェイは、クライアント アプリケーションからの HTTP 呼び出しを受け入れ、Microsoft Entra ID からのトークンを検証して、バックエンド サービスに要求を転送します。 API ゲートウェイは、要求と応答を変換し、応答をキャッシュすることもできます。
開発者ポータル。 開発者ポータル は、開発者が API を検出して操作するために使用されます。 開発者ポータルは、組織のブランドに合わせてカスタマイズできます。
Azure Logic Apps。 ロジック アプリは、バックエンド サービスへの呼び出しを調整するために使用されます。 ロジック アプリは、さまざまなイベントによってトリガーされ、さまざまなサービスを呼び出すことができます。 このソリューションでは、Logic Apps を使用してバックエンド サービスを呼び出し、コネクタを介して簡単に接続、カスタム コードの必要性を軽減します。
バックエンド サービスを
します。 バックエンド サービスには、データベース、Web サービス、SaaS アプリケーションなど、任意のサービスまたは基幹業務アプリケーションを使用できます。 バックエンド サービスは、Azure またはオンプレミスでホストできます。
コンポーネント
-
統合サービスは、アプリケーション、データ、プロセスを統合するために使用できるサービスのコレクションです。 このソリューションでは、Logic Apps と API Management の 2 つのサービスが使用されます。 Logic Apps は、システム間のメッセージ ベースの統合を容易にし、コネクタとの接続を容易にするために使用されます。 API Management は、バックエンド サービスのファサードを提供するために使用され、クライアントが対話するための一貫性のあるインターフェイスを可能にします。
- Logic Apps は、アプリケーション、データ、およびサービスを統合するエンタープライズ ワークフローを構築するためのサーバーレス プラットフォームです。 このソリューションでは、Logic Apps を使用してバックエンド サービスへの呼び出しを調整し、コネクタを介して簡単に接続できるため、カスタム コードの必要性が軽減されます。
- API Management は、HTTP API のカタログを発行するためのマネージド サービスです。 これを使用して、API の再利用と検出可能性を高め、API ゲートウェイをプロキシ API 要求にデプロイできます。 このソリューションでは、API Management は、レート制限、認証、バックエンド サービスへのキャッシュなどの追加機能を提供します。 さらに、API Management には、クライアントが API を検出して操作するための開発者ポータルが用意されています。
- Azure DNS は DNS ドメインのホスティング サービスです。 Azure DNS は、API Management サービスのパブリック DNS レコードをホストしています。 これにより、クライアントは DNS 名を API Management サービスの IP アドレスに解決できます。
- Microsoft Entra ID はクラウドベースの ID およびアクセス管理サービスです。 企業の従業員は、Microsoft Entra ID を使用して外部と内部のリソースにアクセスできます。 ここでは、Entra ID を使用して、OAuth 2.0 を使用して API Management サービスをセキュリティで保護し、Entra B2Cを使用して開発者ポータルをセキュリティで保護します。
シナリオの詳細
統合サービスは、企業のアプリケーション、データ、プロセスを統合するために使用できるサービスのコレクションです。 このアーキテクチャでは、そのうち、ワークフローを調整する Logic Apps と、API のカタログを作成する API Management という 2 つのサービスを使用します。
このアーキテクチャでは、API としてロジック アプリをインポートすることによって、複合 API が構築されます。 OpenAPI (Swagger) 仕様をインポートするか、または WSDL 仕様から SOAP API をインポートすることによって、既存の Web サービスをインポートすることもできます。
API ゲートウェイは、バックエンドからフロントエンド クライアントを分離するのに役立ちます。 たとえば、URL を再書き込みしたり、バックエンドに到達する前に要求を変換したりできます。 また、認証、クロス オリジン リソース共有 (CORS) のサポート、応答のキャッシュなど、多くのサービスにまたがる機能を処理することもできます。
考えられるユース ケース
バックエンド サービスへの同期呼び出しによってワークフローがトリガーされる基本的な統合シナリオの場合は、このアーキテクチャで十分です。 この基本的なアーキテクチャを基にして、キューとイベントを使用した、より高度なアーキテクチャを構築できます。
Recommendations
ここに示す一般的なアーキテクチャとは異なる、固有の要件がある場合があります。 このセクションに記載されている推奨事項は原案として使用してください。
API Management
API Management の Basic、Standard、または Premium レベルを使用します。 これらのレベルでは、運用サービス レベル アグリーメント (SLA) が提供され、Azure リージョン内でのスケールアウトがサポートされます。 API Management のスループット容量は、"ユニット" で測定されます。 各価格レベルには、最大スケールアウトがあります。Premium レベルでは、複数の Azure リージョン間でのスケールアウトもサポートされています。 お使いの機能セットと必要なスループットのレベルに基づいて、使用するレベルを選択します。 詳細については、「Azure API Management の価格」および「Azure API Management インスタンスの容量」を参照してください。
このソリューションでは、このアーキテクチャに必要な開発者ポータルがサポートされていないため、API Management 従量課金レベルは推奨されません。 開発者層は、運用環境以外の環境専用であり、運用環境のワークロードには推奨されません。 階層間の違いを詳しく説明した機能マトリックスについては、こちら
各 Azure API Management インスタンスには既定のドメイン名が付いています。これは azure-api.net のサブドメイン (例: contoso.azure-api.net) です。 ご自身の組織用にカスタム ドメインを構成することを検討してください。
Logic Apps
Logic Apps は、非同期や準長期実行の API 呼び出しなど、応答が低遅延でなくてもよいシナリオで最適に動作します。 低遅延が必要な場合、たとえば、ユーザー インターフェイスをブロックする呼び出しでは、別のテクノロジを使用します。 たとえば、Azure App Service にデプロイされた Azure Functions または Web API を使用します。 API Management を使用して、API コンシューマーに向けて API を配置します。
リージョン
ネットワーク待機時間を最小限に抑えるには、API Management および Logic Apps を同じリージョンに配置します。 通常は、ユーザーに最も近い (またはバックエンド サービスに最も近い) リージョンを選択します。
考慮事項
これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、アプリケーションは顧客に対するコミットメントを確実に満たすことができます。 詳細については、「信頼性
ここで、各サービス の SLA を確認
Premium レベルで 2 つ以上のリージョンにまたがって API Management をデプロイすると、より高度な SLA に対応できます。 「API Management の価格」を参照してください。
バックアップ
お使いの API Management の構成は、定期的にバックアップしてください。 バックアップ ファイルは、サービスがデプロイされているのとは別の場所または Azure リージョンに保管します。 RTO に基づいて、ディザスター リカバリー戦略を選択してください。
ディザスター リカバリー イベントで、新しい API Management インスタンスをプロビジョニングして、バックアップを新しいインスタンスに復元し、DNS レコードを補完します。
API Management サービスのパッシブ インスタンスは、別の Azure リージョンに保持します。 アクティブ サービスとの同期を保つには、定期的にそのインスタンスにバックアップを復元してください。 ディザスター リカバリー イベントの中でサービスを復元するには、DNS レコードのみを補完する必要があります。 このアプローチではパッシブ インスタンスの支払いが生じるため追加コストが発生しますが、回復時間は短縮されます。
ロジック アプリについては、コードとしての構成アプローチで、バックアップと復元を行うことをお勧めします。 ロジック アプリはサーバーレスなので、Azure Resource Manager テンプレートから迅速に再作成できます。 テンプレートはソース コントロールに保存し、お使いの継続的インテグレーション/継続的配置 (CI/CD) プロセスにテンプレートを統合します。 ディザスター リカバリー イベントの際は、新しいリージョンにテンプレートをデプロイしてください。
ロジック アプリを別のリージョンにデプロイした場合は、API Management の構成を更新します。 基本的な PowerShell スクリプトを使用して、API の Backend プロパティを更新できます。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティ
次の一覧は、セキュリティ上のベスト プラクティスをすべて網羅しているわけではありませんが、このアーキテクチャに特に該当するセキュリティ上のいくつかの考慮事項を示しています。
Azure API Management サービスには、固定のパブリック IP アドレスがあります。 Logic Apps エンドポイントを呼び出すためのアクセスを、API Management の IP アドレスのみに制限します。 詳細については、「受信 IP アドレスの制限」を参照してください。
ユーザーが適切なアクセス レベルを保持していることを確認するには、Azure ロールベースのアクセス制御 (Azure RBAC) を使用します。
OAuth/OpenID Connect を使用して、API Management にあるパブリック API エンドポイントをセキュリティで保護する。 パブリック API エンドポイントをセキュリティで保護するには、ID プロバイダーを構成し、JSON Web トークン (JWT) 検証ポリシーを追加します。 詳細については、Microsoft Entra ID と API Management で OAuth 2.0 を使用して API を保護する方法に関するページを参照してください。
相互証明書を使用して、API Management からバックエンド サービスに接続します。 API Management API に HTTPS を強制します。
シークレットの保存
パスワード、アクセス キー、または接続文字列を、ソース管理にチェックインしないでください。 これらの値が必要な場合は、適切な手段を使用して、値をセキュリティで保護してデプロイします。
ロジック アプリが機密データで動作する場合、詳細なガイダンスについては、Azure Logic Apps のワークフローのアクセスとデータのセキュリティ保護
API Management は、"名前付きの値" または "プロパティ" というオブジェクトを使用して、シークレットを管理します。 これらのオブジェクトでは、API Management ポリシー経由でアクセスできる値を安全に格納します。 詳細については、「Azure API Management ポリシーでの名前付きの値の使用方法」を参照してください。
コストの最適化
コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コストの最適化
一般的に、コストを見積もるには、Azure 料金計算ツールを使用します。 その他の考慮事項のいくつかを次に示します。
API Management
すべての API Management インスタンスは、実行されているときに課金されます。 スケールアップしても、常にそのパフォーマンス レベルを必要としない場合は、手動でスケールダウンするか、自動スケーリングを構成してください。
Logic Apps
Logic Apps では、サーバーレス モデルを使用します。 課金はアクションとコネクタの実行に基づいて計算されます。 詳細については、「Logic Apps の価格」をご覧ください。
詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「オペレーショナル エクセレンス
DevOps
運用、開発、およびテスト環境それぞれに対して個別のリソース グループを作成してください。 個別のリソース グループにより、デプロイの管理、テスト デプロイの削除、およびアクセス権の割り当てが行いやすくなります。
リソースをリソース グループに割り当てるときは、次の要素を検討してください。
ライフサイクル。 一般的に、同じライフサイクルのリソースは、同じリソース グループに配置します。
アクセス。 アクセス ポリシーをグループ内のリソースに適用するには、Azure ロールベースのアクセス制御 (Azure RBAC) を使用できます。
課金。 リソース グループのロールアップ コストを表示できます。
API Management の価格レベル。 開発環境およびテスト環境には、Developer レベルを使用してください。 運用前環境のコストを最小限に抑えるには、運用環境のレプリカをデプロイしてテストを実行し、シャットダウンします。
デプロイ
Azure Resource Manager テンプレートを使用して Azure リソースをデプロイし、コードとしてのインフラストラクチャ (IaC) プロセスに従います。 テンプレートを使用すると、Azure DevOps Services またはその他の CI/CD ソリューションを使用したデプロイの自動化が簡単になります。
ステージング
ワークロードのステージングを検討します。これは、さまざまなステージにデプロイし、各ステージで検証を実行してから次に進むことを意味します。 このアプローチを使用すると、高度に制御された方法で運用環境に更新プログラムをプッシュし、予期しないデプロイの問題を最小限に抑えることができます。 アクティブな運用環境を更新するためのデプロイ戦略としては、ブルーグリーン デプロイとカナリア リリースをお勧めします。 また、デプロイが失敗したときのために、適切なロールバック戦略を用意することを検討します。 たとえば、デプロイ履歴から以前に成功したデプロイを自動的に再デプロイすることができます。 その良い例が Azure CLI の --rollback-on-error フラグ パラメーターです。
ワークロードの分離
API Management と個々の任意のロジック アプリを別々の独自の Resource Manager テンプレートに配置します。 別々のテンプレートを使用することで、ソース管理システムにリソースを格納できます。 テンプレートは一緒にデプロイすることも、CI/CD プロセスの一環として個別にデプロイすることもできます。
バージョン
ロジック アプリの構成に変更を加えるか、または Resource Manager テンプレートを使って更新プログラムをデプロイするたびに、Azure では、該当のバージョンのコピーを保管して、実行履歴のあるすべてのバージョンを保管します。 これらのバージョンを使用して、履歴変更を追跡したり、特定のバージョンをロジック アプリの現在の構成として昇格させたりできます。 たとえば、ロジック アプリを以前のバージョンにロールバックすることができます。
API Management では、次に示すように、バージョンに関して 2 つの異なる補完的概念がサポートされています。
"バージョン" により、API のコンシューマーはニーズに基づいて API のバージョン (v1、v2、ベータ、または運用など) を選択できます。
"リビジョン" により、API 管理者が API の非破壊的変更を行い、これらの変更をデプロイできるようになります。その際、API コンシューマーにこれらの変更を通知する変更ログもデプロイされます。
開発環境でリビジョンを作成して、Resource Manager テンプレートを使って他の環境にその変更をデプロイできます。 詳細については、「API の複数のバージョンを発行する」を参照してください。
変更を適用してユーザーがアクセスできるようにする前に、リビジョンを使用して API をテストすることもできます。 ただし、この方法は、ロード テストや統合テストにはお勧めしません。 代わりに、別のテスト環境または運用前環境を使用してください。
診断および監視
操作の監視には、API Management および Logic Apps の両方で、Azure Monitor を使用します。 Azure Monitor は、各サービスに構成されているメトリックに基づいて情報を提供し、既定で有効になります。 詳細については、次を参照してください。
また、各サービスには、次のオプションがあります。
より詳細な分析およびダッシュボード化のために、Azure Log Analytics に Logic Apps ログを送信します。
DevOps 監視には、API Management 用に Azure Application Insights を構成します。
API Management では、カスタム API 分析のための Power BI ソリューション テンプレートをサポートしています。 独自の分析ソリューションを作成して、このソリューション テンプレートを使用できます。 Power BI ではビジネス ユーザー向けに、レポートを利用可能にします。
パフォーマンス効率
パフォーマンス効率は、効率的な方法でユーザーの要求に合わせてワークロードをスケーリングする機能です。 詳細については、「パフォーマンス効率
API Management のスケーラビリティを向上させるには、必要に応じてキャッシュ ポリシーを追加します。 また、キャッシュはバックエンド サービスに対する負荷を軽減するのに役立ちます。
提供する容量をより大きくするために、Azure リージョン内で Azure API Management をBasic、Standard、および Premium レベルにスケールアウトできます。 サービスの使用状況を分析するには、[メトリック] メニューで [容量メトリック] を選択して、適切にスケールアップまたはスケールダウンします。 アップグレードまたはスケーリング プロセスは、適用されるまでに 15 ～ 45 分かかる場合があります。
API Management サービスのスケーリングに関する推奨事項を次に示します。
スケーリングする際はトラフィック パターンを検討します。 トラフィック パターンが変動しやすい顧客は、より大きな容量を必要とします。
容量が一貫して 66% を上回る場合は、スケールアップの必要があることを示している可能性があります。
容量が一貫して 20% を下回る場合は、スケールダウンの機会であることを示している可能性があります。
運用環境で読み込みを有効にする前に、想定される負荷で API Management サービスのロードテストを必ず行います。
Premium レベルでは、複数の Azure リージョンにまたがって API Management インスタンスをスケーリングできます。 これにより、API Management は、より高度な SLA に対応できるようになり、複数のリージョンに位置するユーザーの近くでサービスをプロビジョニングできます。
Logic Apps サーバーレス モデルによって、管理者はサービスのスケーラビリティについて計画を立てる必要がなくなります。 サービスは、需要に合わせて自動的にスケーリングされます。
次のステップ
関連リソース
信頼性とスケーラビリティを高めるには、メッセージ キューとイベントを使用して、バックエンド システムを切り離します。 このアーキテクチャは、このシリーズの次の記事に示されています。
Azure アーキテクチャ センターの次の記事にも関心をお持ちになるかもしれません。