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