Azure Notification Hubs

解決する課題

• iOS・Android などプラットフォームごとに異なる通知サービスを、個別に実装・管理するのが煩雑
• キャンペーンやニュース速報を数百万台の端末へ一斉配信したいが、自前のループ送信では遅く破綻する
• ユーザーの属性や言語、地域に応じてセグメント別に出し分けたい
• デバイストークンの登録・失効管理をサーバー側で抱えたくない

これらを、各社の通知サービスを束ねる単一のハブに集約して解決します。アプリは1つの API を呼ぶだけで、各プラットフォームへの配信はハブが肩代わりします。

主要概念と用語

• PNS（Platform Notification System）: 各プラットフォームが提供する通知基盤。iOS は APNs、Android は FCM、Windows は WNS など。実際に端末へ通知を届けるのはこれらで、Notification Hubs はその前段の抽象化レイヤー
• 名前空間（Namespace）: ハブを束ねる管理単位。課金 SKU やリージョンを持つ
• 通知ハブ（Hub）: 配信の実体。各 PNS の資格情報（APNs 証明書や FCM キー）を設定する単位
• 登録（Registration）: 端末の PNS ハンドル（デバイストークン） とタグを結び付けた情報。古い方式
• インストール（Installation）: 登録を JSON で表現したより新しい方式。1端末＝1インストールとして部分更新ができ、扱いやすい
• タグ（Tag）: 端末に付与するラベル。country_jp や user_123 のように付け、これを指定してセグメント配信する
• タグ式: 複数タグを論理演算で組み合わせた配信条件（例: あるタグかつ別のタグ）
• テンプレート: 通知本文をプレースホルダ入りで定義する仕組み。プラットフォーム差や多言語を送信側で意識せずに出し分けられる

仕様・制限・クォータ

• 対応プラットフォーム: APNs（Apple）、FCM（Android）、WNS（Windows）などの主要 PNS に対応
• SKU と容量: Free / Basic / Standard。アクティブ端末は順に 500 / 20 万 / 1,000 万、含まれる月間プッシュは 100 万 / 1,000 万 / 1,000 万
• タグ: 1 登録またはインストールあたり最大 60 タグ。タグ式で対象を絞り込める
• ペイロードサイズ: 通知本文には各 PNS が定める上限が適用される。大きなデータは送らず、通知は「きっかけ」に留めてアプリが本体を取得する設計が基本
• 配信保証: 最大 1 回を意図したベストエフォートで、バッチを並列処理するため順序は保証されない。送信受理は端末到達を意味しない

内部の仕組み

横にスクロール

アプリは起動時に各 PNS から PNS ハンドル（デバイストークン） を取得し、それを Notification Hubs に登録（またはインストール）します。このとき端末の属性に応じたタグを併せて送ります。バックエンドが通知を送信するときは、宛先を「タグ式」で指定してハブに1回だけリクエストします。

ハブは登録情報から対象端末を解決し、各 PNS の形式に変換して APNs・FCM・WNS などへファンアウト（一斉送信）します。送信側は端末ごとのトークンや各社 API の差異を意識する必要がありません。PNS フィードバックとメッセージテレメトリで無効トークンや資格情報エラーを確認し、登録更新の不具合を調査します。

• テンプレート登録を使うと、端末側が受け取りたい形をあらかじめ定義でき、送信側は共通のプロパティを渡すだけで各プラットフォーム向けに展開される
• 直接送信（Direct Send）では登録を介さず、ハンドルを直接指定して送ることもできる

設計パターン / ベストプラクティス

• 登録はクライアントからではなくバックエンド経由で行う構成（セキュア登録）にし、誰がどのタグを付けられるかをサーバーで制御する
• インストール方式を採用し、登録ではなく1端末1インストールで部分更新する。重複登録や不整合を避けやすい
• タグ設計を最初に固める。ユーザー ID、地域、言語、購読カテゴリなどを体系立ててタグ化しておくと後からのセグメント配信が柔軟になる
• テンプレートで多言語・多デバイスを吸収し、送信側ロジックを単純化する
• 大量送信は一括（バッチ）送信を活用し、リアルタイム処理と切り離す。将来時刻へのスケジュール送信は Standard の機能として使い分ける

運用・監視

• Azure Monitor / メトリクスで送信数、各 PNS への成功・失敗、ペイロードエラーなどを監視する
• PNS フィードバックを確認し、無効トークンの増加や認証失効（証明書・キーの期限切れ）を早期に検知する
• APNs 証明書や FCM の資格情報の更新漏れは配信全停止に直結するため、有効期限の管理を運用タスクに組み込む
• 配信失敗が偏る場合は、特定プラットフォームの資格情報設定やペイロード形式の不備を疑う

コスト

• 課金は主に SKU（Free / Basic / Standard） と月間のプッシュ数・アクティブ端末数で決まる
• 小規模・検証は Free、本番 SLA と 20 万端末までの規模は Basic、豊富なテレメトリ・マルチテナンシー・スケジュール送信が必要なら Standard が目安
• 上限を超えた分は超過課金となるため、想定配信量に合った SKU を選ぶ
• 具体的な単価や無料枠は変動するため、公式の料金ページで最新値を確認する

セキュリティ

• アクセスは SAS（共有アクセス署名）ポリシーで制御し、Listen（クライアント登録用）と Full（バックエンド送信用）の権限を分離する
• クライアントには登録に必要な最小権限のみを配り、送信権限の資格情報をアプリに埋め込まない
• PNS 資格情報（APNs 証明書・FCM キーなど）はハブ側に安全に保管し、ローテーションを計画する
• 転送は TLS で保護される。重要データはペイロードに載せない方針と併用する

Well-Architected の観点

• オペレーショナル エクセレンス: 各 PNS の差異をハブに集約することで、配信ロジックを一元化し運用負荷を下げられる。資格情報の有効期限管理と監視を仕組み化することが要点
• 信頼性: プッシュはベストエフォートのため、通知を唯一の情報伝達手段にしない。重要状態はサーバーが正本を持つ
• セキュリティ: SAS の権限分離とマネージドな資格情報管理で、クライアントへの過剰な権限付与を避ける

試験で問われるポイント

関連サービス・比較

同じくイベントやメッセージを扱う Azure サービスとの守備範囲の違い、および AWS の相当サービスを整理します。

Azure 内では、システム間連携の Event Grid やメッセージキューの Service Bus が「サービス間」のイベント/メッセージを扱うのに対し、Notification Hubs は「エンドユーザーの端末」へのプッシュに特化します。サーバーレスの Functions と組み合わせ、イベント発生時に通知送信をトリガーする構成がよく使われます。

ハンズオン / CLI例

# az notification-hubはAzure CLI 2.67.0以降の拡張機能。
# 作成・認可ルールのサブコマンドは現在Experimentalのため、自動化前に変更点を確認する
# リソースグループを作成
az group create --name demo-rg --location japaneast

# Notification Hubs 名前空間を作成
az notification-hub namespace create \
  --resource-group demo-rg \
  --name demo-nhns-0614 \
  --location japaneast \
  --sku Standard

# 通知ハブを作成
az notification-hub create \
  --resource-group demo-rg \
  --namespace-name demo-nhns-0614 \
  --name demo-hub

# クライアント登録用に Listen 権限の SAS ポリシーを作成
az notification-hub authorization-rule create \
  --resource-group demo-rg \
  --namespace-name demo-nhns-0614 \
  --notification-hub-name demo-hub \
  --name listen-rule \
  --rights Listen

# 接続文字列を確認（バックエンドはこれを使って送信）
az notification-hub authorization-rule list-keys \
  --resource-group demo-rg \
  --namespace-name demo-nhns-0614 \
  --notification-hub-name demo-hub \
  --name DefaultFullSharedAccessSignature -o json