Instiq
第4章 · インフラストラクチャの設計·v2.0.0·更新 2026/6/3·読了目安 約11分

変更要約: AZ-305 第4章を深掘り(比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応)

4.2アプリ統合とメッセージングの設計

この節の要点

疎結合な統合——Service BusEvent GridEvent HubsAPI ManagementLogic AppsAzure Cache for Redis——を理解します。コンポーネントを分離しスケーラブルに連携します。

スケーラブルな設計は疎結合から。用途に応じて Service Bus・Event Grid・Event Hubs を使い分けます。

4.2.1メッセージングと統合

Azure のメッセージング/統合を用途別に整理した図。エンタープライズメッセージング(順序/トランザクション/デッドレター)は Service Bus(キュー/トピック)、イベントのリアクティブ配信(pub/sub・状態変化通知)は Event Grid、ビッグデータ/テレメトリの大量ストリーミング取り込みは Event Hubs、外部公開する API のゲートウェイ(認証/スロットリング/バージョニング)は API Management、ノーコードのワークフロー統合は Logic Apps、低遅延キャッシュは Azure Cache for Redis を並べた図。
メッセージングと統合
  • Service Busエンタープライズメッセージング(キュー/トピック・順序/トランザクション/デッドレター)。
  • Event Gridイベントのリアクティブ配信(pub/sub・状態変化通知)。
  • Event Hubs大量のストリーミング取り込み(テレメトリ/ビッグデータ)。
  • API Management/Logic Apps/RedisAPI ゲートウェイ/ノーコード統合/低遅延キャッシュ
試験ポイント

「順序/トランザクションのエンタープライズメッセージング=Service Bus」「状態変化のイベント通知=Event Grid」「大量テレメトリのストリーム=Event Hubs」「API の公開ゲートウェイ=API Management」「ノーコードのワークフロー=Logic Apps」 は AZ-305 で頻出です。3 つのメッセージングの使い分けが要点です。

続きは無料登録で読めます

冒頭を無料で公開中。無料登録でこの節の全文と、第4章以降を含む全参考書・全問題集が読めます。