このアーキテクチャは、 基本的なエンタープライズ統合 アーキテクチャに基づいていますが、エンタープライズ バックエンド システムを統合する方法が含まれています。 このアーキテクチャでは、メッセージ ブローカーとイベントを使用してサービスを分離し、スケーラビリティと信頼性を高めます。 基本的な統合アーキテクチャの設計とコンポーネントを理解していることを確認します。 これらの要素は、このアーキテクチャのコア コンポーネントに関する基本的な情報を提供します。
Architecture
この設計で参照されるバックエンド システムには、サービスとしてのソフトウェア (SaaS) システム、Azure サービス、メッセージ ベースのサービス、および企業内の既存の Web サービスが含まれます。
このアーキテクチャの Visio ファイルをダウンロードします。
シナリオの詳細
上記のアーキテクチャは、Azure Logic Apps を使用してバックエンド システムと直接ワークフローを調整し、Azure API Management を使用して API のカタログを作成する、よりシンプルな基本的なエンタープライズ統合アーキテクチャに基づいています。
このバージョンのアーキテクチャでは、システムの信頼性とスケーラビリティを高めるうえで役立つコンポーネントが 2 つ追加されています。
Azure Service Bus は、セキュリティで保護された信頼性の高いメッセージ ブローカーです。
Azure Event Grid はイベント ルーティング サービスです。 パブリッシュおよびサブスクライブイベント モデルを使用します。
このアーキテクチャでは、バックエンド サービスへの直接の同期呼び出しを行う代わりに、メッセージ ブローカー経由の非同期通信を使用します。 非同期通信には、次の利点があります。
Queue ベースの負荷平準化パターンを使用して負荷平準化を使用してワークロードのバーストを処理します。
複数のコンシューマーにメッセージをブロードキャストできるように、 Publisher-Subscriber パターン を使用します。
実行時間の長いワークフローの進行状況を、複数のステップまたは複数のアプリケーションが含まれている場合でも、確実に追跡します
アプリケーションの分離に役立ちます
既存のメッセージ ベースシステムとの統合
バックエンド システムが使用できない場合にメッセージをキューに登録する機能を提供します
Event Grid を使用して、システム内のさまざまなコンポーネントが、ポーリングやスケジュールされたタスクに依存するのではなく、イベントが発生したときに対応できるようにします。 メッセージ キューやトピックと同様に、Event Grid はアプリケーションとサービスを分離するのに役立ちます。 アプリケーションまたはサービスがイベントを発行すると、関心のあるサブスクライバーに通知されます。 送信者を更新せずに、新しいサブスクライバーを追加できます。
Event Grid へのイベント送信をサポートする Azure サービスは多数あります。 たとえば、新しいファイルが BLOB ストアに追加された場合に、ロジック アプリはイベントをリッスンできます。 このパターンでは、ファイルをアップロードしたり、キューにメッセージを配置したりして一連のプロセスを開始するリアクティブワークフローが作成されます。 プロセスは、並列または特定のシーケンスで実行される場合があります。
推奨事項
次の推奨事項を検討してください。 その他の推奨事項については、 Basic エンタープライズ統合アーキテクチャを参照してください。
Service Bus
Service Bus には、 pull モデルと proxied push モデルの 2 つの配信モデルがあります。
プル モデル: 受信者は、新しいメッセージを継続的にポーリングします。 複数のキューとポーリング時間を管理する必要がある場合は、ポーリングが非効率的である可能性があります。 ただし、このモデルでは、追加のコンポーネントとデータ ホップが削除されるため、アーキテクチャを簡略化できます。
プロキシされたプッシュ モデル: 受信側は、最初に Event Grid トピックの特定のイベントの種類をサブスクライブします。 新しいメッセージが使用可能になると、Service Bus は Event Grid を介してイベントを発生させ、送信します。 このイベントは、Service Bus からメッセージの次のバッチをプルする受信側をトリガーします。 このモデルを使用すると、システムはほぼリアルタイムでメッセージを受信できますが、リソースを使用して新しいメッセージを継続的にポーリングする必要はありません。 このアーキテクチャでは、デプロイ、管理、セキュリティ保護が必要な追加のコンポーネントが使用されます。
Service Bus メッセージを使用する Standard Logic Apps ワークフローを作成する場合は、Service Bus 組み込みコネクタ トリガーを使用することをお勧めします。 組み込みのコネクタは、追加コストを追加することなく、プル モデル構成の大部分を抽象化します。 この機能は、Logic Apps ランタイム エンジン内でコネクタが継続的にループするため、コスト、領域管理、セキュリティのバランスを適切に保ちます。 詳細については、「 Service Bus の組み込みコネクタ トリガーを参照してください。
PeekLock モードを使用してメッセージのグループにアクセスします。 PeekLock を使用すると、ロジック アプリは、メッセージを完了または中止する前に、各メッセージを検証する手順を実行できます。 この方法では、誤ってメッセージが失われるのを防ぎます。
Event Grid
Event Grid トリガーが起動すると、少なくとも 1 つ イベント 発生したことを意味します。 たとえば、ロジック アプリが Service Bus メッセージの Event Grid トリガーを取得すると、処理できるメッセージがいくつか存在する可能性があります。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
[信頼性]
信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
Microsoft Entra ID は、グローバルに分散された高可用性 SaaS プラットフォームです。
ビジネス要件とコスト許容度に応じてAPI Management を複数の高可用性構成でデプロイできます。 詳細については、「 Ensure API Management の可用性と信頼性を参照してください。
Logic Apps 従量課金レベルでは、geo 冗長ストレージがサポートされています。 詳細については、「 Logic Apps のビジネス継続性とディザスター リカバリーを参照してください。
Event Grid トピック、システム トピック、ドメイン、およびイベント サブスクリプションとイベント データのリソース定義は、リージョン内の 可用性ゾーン に自動的にレプリケートされます。 いずれかの可用性ゾーンで障害が発生したとき、Event Grid リソースは、ユーザーの介入なしに別の可用性ゾーンに自動的にフェールオーバーします。 詳しくは、「リージョン間のディザスター リカバリーおよび事業継続」を参照してください。
Service Bus Premium では、 geo-disaster recovery と availability zones がサポートされます。 Service Bus Standard では、 replication がサポートされます。
各サービスの可用性の保証の詳細については、オンライン サービスのS SLA に関するページを参照してください。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
Service Bus をセキュリティで保護するには、 Microsoft Entra 認証 と 管理された ID をペアにします。 Service Bus リソースの Microsoft Entra ID 統合により、Azure ロールベースのアクセス制御 (RBAC) が提供され、クライアントによるリソースへのアクセスをきめ細かく制御できます。 Azure RBAC を使用して、ユーザー、グループ、アプリケーション サービス プリンシパルなどのセキュリティ プリンシパルにアクセス許可を付与できます。 このシナリオのアプリケーション サービス プリンシパルはマネージド ID です。
Microsoft Entra ID を使用できない場合は、共有アクセス署名 (SAS) 認証を使用して、Service Bus リソースへのアクセス権と特定の権限をします。
たとえば、新しいメッセージを投稿するために Service Bus キューまたはトピックを HTTP エンドポイントとして公開する必要がある場合は、API Management を使用して、エンドポイントを前面に配置してキューをセキュリティで保護します。 その後、証明書または OAuth 認証を使用して、エンドポイントをセキュリティで保護できます。 エンドポイントをセキュリティで保護する最も簡単な方法は、HTTP 要求または応答トリガーを仲介者として持つロジック アプリを使用することです。
Event Grid サービスは、検証コードを使用してイベント配信をセキュリティで保護するのに役立ちます。 Logic Apps を使用してイベントを使用する場合、検証は自動的に行われます。 詳細については、「Event Grid security and authentication」(Event Grid のセキュリティと認証) を参照してください。
ネットワークのセキュリティ
設計全体でネットワーク セキュリティを検討します。
Service Bus Premium を仮想ネットワーク サブネット サービス エンドポイントにバインドできます。 この構成は、承認された仮想ネットワークからのトラフィックのみを受け入れるため、名前空間をセキュリティで保護するのに役立ちます。 Azure Private Link を使用して、プライベート エンドポイントを介して仮想ネットワークへのプライベート トラフィックのみを許可することもできます。
Logic Apps Standard と Premium を構成して、private エンドポイント経由の受信トラフィックを受け入れ仮想ネットワーク統合経由で送信トラフィックを送信できます。
Azure 仮想ネットワークを使用して、API Management インスタンスと API へのアクセスをセキュリティで保護できます。 このメソッドは、 private エンドポイントをサポートします。 詳細については、「 API Management を使用した仮想ネットワークの使用」を参照してください。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
コストの見積もりには、Azure 料金計算ツールをご利用ください。 その他の考慮事項のいくつかを次に示します。
API Management
すべての API Management インスタンスの実行時に課金されます。 スケールアップした後で、そのレベルのパフォーマンスが不要になった場合は、手動でスケールダウンするか、 自動スケールを構成します。
軽い使用ワークロードの場合は、 Consumption レベルを検討してください。これは、低コストのサーバーレス オプションです。 従量課金レベルは、API 呼び出しごとに課金されます。 その他のレベルは 1 時間あたりに課金されます。
Logic Apps
Logic Apps では、サーバーレス モデルを使用します。 課金は、アクションとコネクタ呼び出しの数に基づいて計算されます。 詳細については、「Logic Apps の価格」をご覧ください。
Service Bus のキュー、トピック、サブスクリプション
Service Bus のキューとサブスクリプションでは、メッセージを配信するためのプロキシされたプッシュ モデルとプル モデルの両方がサポートされます。 プル モデルでは、すべてのポーリング要求がアクションとして課金され、 長いポーリングを既定値の 30 秒に設定した場合でも、コストが高くなる可能性があります。 リアルタイムのメッセージ配信が必要な場合を除き、プロキシ化されたプッシュ モデルの使用を検討してください。
Service Bus キューは、Basic、Standard、Premium のすべてのレベルに含まれています。 Service Bus のトピックとサブスクリプションは、Standard レベルと Premium レベルで利用できます。 詳細については、「Service Bus の価格」をご覧ください。
Event Grid
Event Grid では、サーバーレス モデルを使用します。 課金は操作の数に基づいて計算されます。 操作には、ドメインまたはトピックに移動するイベント、高度な一致、配信試行、および管理呼び出しが含まれます。 最大 100,000 操作を無料で使用できます。
詳細については、「 Event Grid の価格 と ウェル アーキテクト フレームワークのコスト最適化を参照してください。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
基本的なエンタープライズ統合リファレンス アーキテクチャでは、DevOps パターンに関する ガイドが提供されますこれは、適切に設計されたフレームワーク Operational エクセレンス の柱に沿っています。
復旧操作を可能な限り自動化して、オペレーショナル エクセレンスの向上に役立ちます。 自動化を念頭に置いて、 Azure ログ監視 と Azure Automation を組み合わせて、Service Bus リソースのフェールオーバーを自動化できます。 フェールオーバーを開始する自動化ロジックの例については、 Failover フローに関する記事を参照してください。
パフォーマンス効率
パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
Service Bus Premium レベルは、より高いスケーラビリティを実現するためにメッセージング ユニットの数をスケールアウトできます。 詳細については、「 Service Bus Premium および Standard メッセージングレベル および 自動スケーリング機能を参照してください。
Service Bus に関するその他の推奨事項については、「 Service Bus メッセージングを使用したパフォーマンス向上のためのベスト プラクティスを参照してください。