この参照アーキテクチャでは、Azure Integration Services を使用して、エンタープライズ バックエンド システムへの呼び出しを調整します。 バックエンド システムには、サービスとしてのソフトウェア (SaaS) システム、Azure サービス、およびご自身の企業内の既存の Web サービスが含まれる場合があります。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
バックエンド システム。 図の右側には、企業がデプロイまたは使用するさまざまなバックエンド システムが示されています。 これらのシステムには、SaaS システム、その他の Azure サービス、あるいは REST または SOAP エンドポイントを公開する Web サービスが含まれる場合があります。
Azure Logic Apps。 このアーキテクチャでは、HTTP 要求によってロジック アプリがトリガーされます。 ワークフローを入れ子にすることで、より複雑なオーケストレーションを実現することもできます。 Logic Apps ではコネクタを使用して、よく利用するサービスを統合します。 Logic Apps には何百ものコネクタが用意されていますが、カスタム コネクタを作成することもできます。
Azure API Management。 API Management は、次の 2 つの関連するコンポーネントで構成されます。
API ゲートウェイ。 API ゲートウェイは、HTTP 呼び出しを受け入れ、バックエンドにルーティングします。
開発者ポータル。 Azure API Management の各インスタンスによって、開発者ポータルへのアクセスが提供されます。 開発者は、このポータルから、ドキュメントとAPI を呼び出すためのコード サンプルにアクセスできます。 開発者ポータル内で API をテストすることもできます。
Azure DNS。 Azure DNS は、Azure インフラストラクチャを使用した名前解決を提供します。 Azure でドメインをホストすることで、その他の Azure サービスに使用しているのと同じ資格情報、API、ツール、課金情報を使用して DNS レコードを管理できます。 カスタム ドメイン名 (contoso.com など) を使用するには、カスタム ドメイン名を IP アドレスにマップする DNS レコードを作成します。 詳細については、API Management でのカスタム ドメイン名の構成に関するページを参照してください。
Microsoft Entra ID。 API ゲートウェイを呼び出すクライアントを認証するには、Microsoft Entra ID を使用します。 Microsoft Entra ID では、OpenID Connect (OIDC) プロトコルがサポートされています。 クライアントは Microsoft Entra ID からアクセス トークンを取得し、API ゲートウェイでトークンを検証することで要求が承認されます。 API Management の Standard または Premium レベルを使用している場合、Microsoft Entra ID によって開発者ポータルへのアクセスをセキュリティで保護することもできます。
コンポーネント
- 統合サービスは、アプリケーション、データ、プロセスを統合するために使用できるサービスのコレクションです。
- Logic Apps は、アプリケーション、データ、およびサービスを統合するエンタープライズ ワークフローを構築するためのサーバーレス プラットフォームです。
- API Management は、HTTP API のカタログを発行するためのマネージド サービスです。 これを使用して、API の再利用と検出可能性を高め、API ゲートウェイをプロキシ API 要求にデプロイできます。
- Azure DNS は DNS ドメインのホスティング サービスです。
- Microsoft Entra ID はクラウドベースの ID およびアクセス管理サービスです。 企業の従業員は、Microsoft Entra ID を使用して外部と内部のリソースにアクセスできます。
シナリオの詳細
統合サービスは、企業のアプリケーション、データ、プロセスを統合するために使用できるサービスのコレクションです。 このアーキテクチャでは、そのうち、ワークフローを調整する 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 インスタンスの容量」を参照してください。
各 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 を強制します。
シークレットの保存
パスワード、アクセス キー、または接続文字列を、ソース管理にチェックインしないでください。 これらの値が必要な場合は、適切な手段を使用して、値をセキュリティで保護してデプロイします。
1 つのロジック アプリがコネクタ内に作成できない何らかの機密値を必要としている場合、それらの値を Azure Key Vault に保存して、Resource Manager テンプレートから参照します。 デプロイ テンプレートのパラメーターと、各環境のパラメーター ファイルを使用します。 詳細については、ワークフロー内のパラメーターと入力のセキュリティ保護に関するページを参照してください。
API Management は、"名前付きの値" または "プロパティ" というオブジェクトを使用して、シークレットを管理します。 これらのオブジェクトでは、API Management ポリシー経由でアクセスできる値を安全に格納します。 詳細については、「Azure API Management ポリシーでの名前付きの値の使用方法」を参照してください。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。
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 料金計算ツールを使用します。 その他の考慮事項のいくつかを次に示します。
API Management
すべての API Management インスタンスは、実行されているときに課金されます。 スケールアップしても、常にそのパフォーマンス レベルを必要としない場合は、手動でスケールダウンするか、自動スケーリングを構成してください。
Logic Apps
Logic Apps では、サーバーレス モデルを使用します。 課金はアクションとコネクタの実行に基づいて計算されます。 詳細については、「Logic Apps の価格」をご覧ください。
詳細については、「Microsoft Azure Well-Architected Framework」のコストのセクションを参照してください。
次のステップ
関連リソース
信頼性とスケーラビリティを高めるには、メッセージ キューとイベントを使用して、バックエンド システムを切り離します。 このアーキテクチャは、このシリーズの次の記事に示されています。
Azure アーキテクチャ センターの次の記事にも関心をお持ちになるかもしれません。