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