Application Integration

カテゴリ概要

Azure のアプリケーション統合サービスは、メッセージング、イベント駆動、ワークフローオーケストレーション、API 管理を提供するサービス群である。AWS では SQS（キュー）と SNS（Pub/Sub）が明確に分離されているが、Azure の Service Bus はキューとトピック（Pub/Sub）を 1 つのサービスで提供する点が大きな設計思想の違いである。また、Logic Apps は Step Functions よりもローコード寄りのワークフローサービスであり、SaaS 連携のコネクタが豊富に用意されている点が特徴的である。

サービスマッピング一覧

主要サービス詳細

Azure Service Bus（AWS: SQS + SNS）

エンタープライズ向けのフルマネージドメッセージブローカーで、キュー（ポイント・ツー・ポイント）とトピック（Pub/Sub）の両方のメッセージングパターンを単一サービスで提供する。

AWS エンジニアが知っておくべき違い:

• キューとトピックを 1 つのサービスで提供 — AWS では SQS（キュー）と SNS（Pub/Sub）が別サービスであり、SNS → SQS のファンアウトパターンでは 2 サービスを組み合わせる必要がある。Service Bus はキュー（1:1 配信）とトピック + サブスクリプション（1:N 配信）を同一サービス内で使い分けられる
• セッション機能で FIFO と関連メッセージのグルーピングが可能 — SQS FIFO キューに相当する順序保証に加え、セッション ID で関連するメッセージをグループ化し、同一コンシューマーで順序通りに処理する機能がある
• デッドレタリング・遅延メッセージ・スケジュール送信が標準 — SQS のデッドレターキューに相当する機能に加え、メッセージの遅延配信やスケジュール送信が組み込み機能として提供される
• トランザクションサポート — 複数のメッセージ送信操作をトランザクションとしてアトミックに実行できる。SQS にはこの機能はない
• Premium Tier で専用リソースと高スループット — Premium Tier ではメッセージングユニット（専用リソース）が割り当てられ、予測可能なパフォーマンスを確保できる。SQS にはティアの概念はない

Azure Queue Storage（AWS: SQS Standard）

Azure ストレージアカウントに付属する軽量なメッセージキューサービスで、大量のメッセージを低コストで格納・処理できる。

AWS エンジニアが知っておくべき違い:

• ストレージアカウントの一部として提供 — SQS が独立したサービスであるのに対し、Queue Storage は Blob Storage や Table Storage と同じストレージアカウント内に作成される。追加のサービス作成が不要で、既存のストレージアカウントにすぐにキューを追加できる
• Service Bus との使い分けが重要 — SQS は Standard と FIFO の 2 種類で幅広いユースケースをカバーするが、Azure ではシンプルなキューイングには Queue Storage、セッション・トランザクション・トピック等の高度な機能が必要な場合は Service Bus を選択する
• 最大メッセージサイズが 64 KB — SQS の 256 KB と比較して小さい。大きなペイロードが必要な場合は Service Bus（Standard: 256 KB、Premium: 100 MB）を使用する
• HTTP / HTTPS ベースの REST API でアクセス — SQS と同様に HTTP ベースだが、Azure Storage SDK を通じてアクセスするのが一般的

Azure Event Grid（AWS: EventBridge）

イベント駆動アーキテクチャを構築するためのフルマネージドイベントルーティングサービスで、パブリッシュ・サブスクライブモデルでイベントを配信する。

AWS エンジニアが知っておくべき違い:

• Azure リソースのイベントとのネイティブ統合 — EventBridge が AWS サービスのイベントを取り込むのと同様に、Event Grid は Azure リソース（Blob Storage へのファイル作成、Resource Group の変更、Entra ID のイベント等）のイベントをネイティブにサポートする。特に Blob Storage のイベント（作成・削除）との統合は S3 イベント通知より設定が容易
• イベントスキーマに CloudEvents を採用 — Event Grid は CNCF の CloudEvents 仕様をネイティブにサポートしており、標準化されたイベントフォーマットで他のシステムとの相互運用性が高い
• Push 配信モデルが基本 — EventBridge がイベントバスにルールを定義してターゲットに配信するのと同様に、Event Grid もサブスクリプション（ルール）で宛先にイベントを Push する。Webhook、Azure Functions、Service Bus、Storage Queue 等を宛先に設定できる
• Event Grid Namespaces で MQTT サポート — IoT デバイスとの通信に使用される MQTT プロトコルを Event Grid Namespaces でネイティブにサポートしており、IoT Hub を使わない軽量な IoT イベント処理が可能

Azure Logic Apps（AWS: Step Functions + EventBridge）

ビジュアルデザイナーを使ってワークフローを構築するローコード / ノーコードのオーケストレーションサービスで、数百の SaaS・オンプレミスサービスとのコネクタが用意されている。

AWS エンジニアが知っておくべき違い:

• Step Functions よりもローコード寄り — Step Functions は ASL（Amazon States Language）で状態遷移を定義するが、Logic Apps はビジュアルデザイナーで条件分岐・ループ・並列処理を含むワークフローを構築できる。コーディングなしでビジネスプロセスの自動化が可能
• SaaS 連携コネクタが豊富 — Office 365、Salesforce、ServiceNow、SAP など数百のコネクタが用意されており、エンタープライズ SaaS との統合が容易。Step Functions + Lambda でカスタムコードを書く処理の多くが、Logic Apps ではコネクタの設定だけで実現できる
• 消費プランと Standard プランの 2 種類 — 消費プラン（マルチテナント、従量課金）と Standard プラン（シングルテナント、App Service Plan 上で動作）がある。Standard プランは VNet 統合や複数ワークフローのホスティングが可能で、本番環境向け
• 組み込みの再試行ポリシーとエラーハンドリング — 各アクションに再試行ポリシー、タイムアウト、スコープ（try-catch 相当）を設定でき、複雑なエラーハンドリングをビジュアルに定義できる
• B2B 統合機能 — Enterprise Integration Pack で EDI、AS2、X12 などの B2B プロトコルをサポートし、企業間のデータ連携ワークフローを構築できる

Azure Durable Functions（AWS: Step Functions）

Azure Functions の拡張機能として提供される、コードファーストのオーケストレーションフレームワーク。

AWS エンジニアが知っておくべき違い:

• コードファーストのアプローチ — Step Functions が ASL（JSON ベースの状態遷移定義）でワークフローを記述するのに対し、Durable Functions は C#、JavaScript、Python 等のプログラミング言語でオーケストレーションロジックを直接記述する。プログラマーにとっては自然な記述方法である
• Azure Functions のプログラミングモデル内で動作 — 独立したサービスではなく Functions の拡張機能であるため、既存の Functions プロジェクトにオーケストレーション機能を追加できる。Step Functions + Lambda の 2 サービス構成が不要
• パターンが豊富 — 関数チェーン、ファンアウト・ファンイン、非同期 HTTP API、モニターパターン、ヒューマンインタラクション（承認フロー）等のパターンをサポート
• ビジュアルエディタはない — Step Functions の Workflow Studio のようなビジュアルエディタは提供されていない。ワークフローの可視化には Durable Functions Monitor 等のサードパーティツールを使用する

Azure API Management / APIM（AWS: API Gateway）

API のライフサイクル全体を管理するフルマネージドサービスで、API の公開・保護・分析・開発者ポータルを統合的に提供する。

AWS エンジニアが知っておくべき違い:

• 開発者ポータルが標準機能 — API Gateway ではサードパーティツールや自前で API ドキュメントサイトを構築する必要があるが、APIM はカスタマイズ可能な開発者ポータルを標準で提供する。API のドキュメント公開、開発者の自己登録、API キーの発行がポータル経由で行える
• ポリシーエンジンによる柔軟な制御 — XML ベースのポリシーで、認証・レート制限・レスポンス変換・キャッシュ・バリデーション等の処理をコードなしで定義できる。API Gateway のオーソライザーやマッピングテンプレートに相当するが、より多彩な処理が可能
• 複数の API をプロダクトとしてグルーピング — API をプロダクト単位でまとめ、サブスクリプション（APIキー）によるアクセス制御を行う。API Gateway の Usage Plan に相当するが、開発者ポータルとの統合度が高い
• 複数のティアが用意されている — Developer、Basic、Standard、Premium、消費の各ティアがあり、用途に応じて選択する。Premium ティアでは VNet 統合や複数リージョンデプロイが可能
• バックエンドの抽象化 — Azure Functions、App Service、Logic Apps、外部 API など、複数のバックエンドを単一の API ファサードで統合できる。API Gateway のステージ・統合設定に相当するが、設定の柔軟性が高い

Azure SignalR Service（AWS: 該当なし）

リアルタイム WebSocket 通信をフルマネージドで提供するサービスで、Web アプリケーションへのリアルタイム機能の追加を容易にする。

AWS エンジニアが知っておくべき違い:

• AWS に直接の対応サービスがない — AWS では API Gateway WebSocket API + Lambda で WebSocket 通信を実装できるが、接続管理やブロードキャストのロジックを自前で構築する必要がある。SignalR Service はこれらをフルマネージドで提供する
• ASP.NET SignalR のマネージドサービス — .NET エコシステムの SignalR ライブラリをクラウドサービスとして提供。サーバーサイドの接続管理やスケールアウトをサービス側で処理するため、アプリケーションコードはビジネスロジックに集中できる
• サーバーレスモードで Azure Functions と統合 — Azure Functions のバインディングとして SignalR Service を利用でき、サーバーレスアーキテクチャでリアルタイム通信を実現できる
• 自動フォールバック — クライアント環境に応じて WebSocket → Server-Sent Events → Long Polling に自動フォールバックする。接続方式を意識せずにリアルタイム通信を実装できる

Azure Notification Hubs（AWS: SNS モバイルプッシュ）

大規模なモバイルプッシュ通知を配信するためのマルチプラットフォーム対応のプッシュ通知サービス。

AWS エンジニアが知っておくべき違い:

• SNS のモバイルプッシュ機能に特化したサービス — SNS はメッセージング全般（HTTP、Email、SMS、モバイルプッシュ等）を扱うが、Notification Hubs はモバイルプッシュ通知に特化しており、APNs（iOS）、FCM（Android）、WNS（Windows）等の各プラットフォームへの配信を統合管理する
• タグベースのターゲティング — デバイスにタグを付与し、タグ式（論理式）で柔軟にプッシュ通知のターゲットを指定できる。SNS のトピックベースの配信よりも細かいセグメンテーションが可能
• テンプレート機能でプラットフォーム差異を吸収 — 各プラットフォームのペイロード形式の違いをテンプレートで吸収し、単一の API コールで全プラットフォームに通知を配信できる

AWS との主要な違い

メッセージングサービスの統合度

AWS では SQS（キュー）と SNS（Pub/Sub）が完全に独立したサービスとして設計されており、ファンアウトパターンでは SNS → SQS のサブスクリプションを設定する。Azure の Service Bus はキューとトピック（Pub/Sub）を単一サービスに統合しており、1 つの名前空間内でキューとトピックを自由に作成・管理できる。ただし、Azure にも軽量な Queue Storage が別途存在するため、要件に応じた使い分け（Queue Storage vs Service Bus）が必要になる点は AWS よりも選択肢が複雑である。

ワークフロー / オーケストレーションの二面性

AWS では Step Functions がワークフローオーケストレーションの主力サービスであり、ASL で定義する統一的なアプローチを取る。Azure ではローコードの Logic Apps とコードファーストの Durable Functions という 2 つのアプローチが並立している。Logic Apps は SaaS 連携やビジネスプロセス自動化に強く、Durable Functions は開発者がプログラミング言語で複雑なオーケストレーションを記述する場合に適している。ユースケースに応じてどちらを選ぶかの判断が求められる。

Event Grid と EventBridge の設計思想

Event Grid と EventBridge はどちらもイベント駆動アーキテクチャの中核サービスだが、Event Grid は Azure リソースのイベント（Blob 作成、リソースグループ変更等）との統合がより密接である。EventBridge は AWS サービスのイベントに加えてカスタムイベントバスや SaaS パートナーイベントに力を入れているのに対し、Event Grid は CloudEvents 標準の採用やMQTT サポートなど、オープンスタンダードとの親和性を重視している。

API Management の機能範囲

AWS の API Gateway は REST API / HTTP API / WebSocket API の 3 タイプに分かれており、機能セットがタイプごとに異なる。Azure API Management は単一サービスで REST・SOAP・GraphQL・WebSocket の API を管理でき、開発者ポータル、ポリシーエンジン、分析ダッシュボード、プロダクト管理が統合されている。API Gateway が軽量なゲートウェイに徹しているのに対し、APIM は API のライフサイクル全体をカバーする包括的なプラットフォームである。

リアルタイム通信のマネージドサポート

Azure SignalR Service は WebSocket を使ったリアルタイム双方向通信をフルマネージドで提供するサービスであり、AWS に直接の対応はない。AWS では API Gateway WebSocket API + Lambda + DynamoDB（接続管理）でリアルタイム通信を構築できるが、ブロードキャストやグループ管理などの高レベル機能は自前で実装する必要がある。チャット、ライブダッシュボード、リアルタイム通知などのユースケースでは、SignalR Service の方が実装コストが大幅に低い。

サービス選定の指針