Azure Notification Hubs によるプッシュ通知:よく寄せられる質問

Azure Notification Hubs には、2 つのリソース レベルとして、ハブと名前空間があります。 ハブは、1 つのアプリのクロスプラットフォーム プッシュ情報を保持できる単一のプッシュ リソースです。 名前空間は、1 つのリージョンのハブのコレクションです。 推奨されるマッピングでは、1 つの名前空間を 1 つのアプリに対応付けます。 その名前空間内に、運用アプリで動作する運用環境ハブ、テスト アプリで動作するテスト ハブなどを配置できます。

最新の価格情報については、「Notification Hubs の価格」ページを参照してください。 Notification Hubs は、名前空間レベルで課金されます (名前空間の定義については、「Notification Hubs のリソース構造について教えてください」を参照してください)。Notification Hubs には、次の 3 つのレベルがあります。

• Free:プッシュ機能を試してみるには、このレベルで始めるのが適しています。 運用環境のアプリにはお勧めしません。 サブスクリプションごとに 1 か月あたり 500 デバイスと 100 万プッシュが提供されますが、サービス レベル アグリーメント (SLA) の保証はありません。
• Basic:このレベル (または Standard レベル) は、小規模な運用アプリにお勧めです。 サブスクリプションごとに 1 か月あたり 200,000 デバイスと 1,000 万プッシュがベースラインとして提供されます。
• Standard:このレベルは、中規模から大規模な運用アプリにお勧めです。 サブスクリプションごとに 1 か月あたり 1,000 万デバイスと 1,000 万プッシュがベースラインとして提供されます。 豊富な利用統計情報 (提供されるプッシュの状態に関する追加データ) が含まれます。

Standard レベルの機能:

• 豊富なテレメトリ:Notification Hubs のメッセージごとのテレメトリを使用して、デバッグのためにすべてのプッシュ要求とプラットフォーム通知システムのフィードバックを追跡できます。
• マルチテナント: プラットフォーム通知システムの資格情報を名前空間レベルで使用することができます。 このオプションにより、テナントを同じ名前空間内のハブに簡単に分割することができます。
• プッシュのスケジュール:通知をいつ送信するかをスケジュールすることができます。
• バルク操作: 登録のエクスポートとインポートに関するドキュメントで説明しているように、登録のエクスポート/インポート機能を有効にします。

Basic と Standard の Notification Hubs レベルでは、適切に構成されたアプリケーションは、少なくとも 99.9% の時間、プッシュ通知を送信したり、登録管理操作を行ったりすることができます。 SLA の詳細については、「Notification Hubs の SLA」ページを参照してください。

Azure Portal>[Notification Hubs の名前空間] または [Notification Hubs] の順に移動します。 更新するリソースを選択して、 [価格レベル] に移動します。 以下の要件に注意してください。

• 更新された価格レベルは、使用している名前空間内の "すべて" のハブに適用されます。
• デバイス数がダウングレード後のレベルでの上限を超えている場合は、ダウングレードする前にデバイスを削除する必要があります。

.NET、Java、Node.js、PHP、Python のサーバー SDK を利用できます。 Notification Hubs API は REST インターフェイスに基づくため、さまざまなプラットフォームを使用している場合や、追加の依存関係を避ける場合は、REST API を直接使用できます。 詳細については、Notification Hubs REST API に関するページを参照してください。

プッシュ通知がサポートされているのは、iOS、Android、Windows Universal、Windows Phone、Android China (Baidu 経由)、Xamarin (iOS と Android)、および Safari です。 詳細については、Notification Hubs の使用チュートリアルに関するページを参照してください。

Notification Hubs は、モバイル アプリを実行しているデバイスに通知を送信します。 電子メールまたはテキスト メッセージの機能は用意されていません。 また、Notification Hubs には、すぐに使えるブラウザー内プッシュ通知の送信サービスもありません。 この機能は、サポートされているサーバー側プラットフォームで SignalR を使用すれば実装できます。

サポートされているデバイス数の詳細については、「Notification Hubs の価格」ページを参照してください。

1000 万を超える登録デバイスのサポートが必要な場合、複数の名前空間でデバイスをパーティション分割する必要があります。

選択されているレベルに応じて、Azure Notification Hubs は、システムで通信されている通知の数に基づいて自動的にスケールアップします。

Notification Hubs を使用しているお客様は、毎日数百万のプッシュ通知を送信しています。 Azure Notification Hubs を使用している限り、プッシュ通知のリーチを拡張するために特別な処理は必要ありません。

Azure Notification Hubs では、着信負荷が一定で均一な通常の使用シナリオにおいては、"1 分間に少なくとも 100 万件のプッシュ通知" を処理できます。 この数は、タグの数、着信する通知の性質、その他の外部要因によって異なります。

サービスは、この推定配信時間中に、登録したタグやタグ式を基にしてプラットフォームあたりのターゲットを計算し、プッシュ通知サービス (PNS) にメッセージをルーティングします。 デバイスに通知を送信するのは、PNS の役目です。

PNS は、通知の送信に関するいかなる SLA も保証しません。 ただし、ほとんどのプッシュ通知は、Notification Hubs に送信されてから数分以内に (通常は 10 分以内に) ターゲット デバイスに配信されます。 一部の通知は、もう少し時間がかかります。

プッシュ通知の性質 (外部のプラットフォーム固有の PNS によって配信されるしくみ) のため、遅延に対する保証はありません。 通常、ほとんどのプッシュ通知は数分以内に配信されます。

Azure Notification Hubs では、お客様の登録データはお客様が選択したリージョンに格納されます。 Notification Hubs では、メタデータ (Notification Hubs の名前、接続文字列、その他の重要情報など) のディザスター リカバリー対応を提供しています。 ブラジル南部と東南アジアを除くすべてのリージョンでは、メタデータ バックアップは別のリージョン (通常は Azure ペア リージョン) でホストされます。 ブラジル南部および東南アジア リージョンでは、バックアップは、これらのリージョンのデータ所在地の要件に対応するために同じリージョンに格納されます。

モバイル アプリ/環境

• 1 つの環境、1 つのモバイル アプリに対して、1 つの通知ハブを使用してください。
• 複数テナントのシナリオでは、各テナントで個別のハブが必要になります。
• 運用環境とテスト環境で、同じ通知ハブを共有しないでください。 そのような設定では、通知を送信するときに問題が生じる場合があります (Apple では、Sandbox と Production Push エンドポイントをそれぞれ個別の資格情報で提供しています)。
• 既定では、Azure Portal または Visual Studio の Azure が統合されているコンポーネントから、登録済みのデバイスにテスト通知を送信できます。 しきい値は、登録プールからランダムに選択される 10 個のデバイスに設定されています。

PNS の資格情報

モバイル アプリがプラットフォームの開発者ポータル (Apple、Google など) に登録されている場合は、アプリの識別子とセキュリティ トークンが送信されます。 アプリのバックエンドは、プッシュ通知をデバイスに送信できるように、プラットフォームの PNS にこれらのトークンを提供します。 セキュリティ トークンは、証明書の形式 (たとえば Apple iOS や Windows Phone) またはセキュリティ キーの形式 (たとえば Google Android や Windows) にすることができます。 これらは、通知ハブで構成する必要があります。 構成は通常、通知ハブ レベルで行われますが、マルチテナントのシナリオでは名前空間レベルで行うこともできます。

名前空間

名前空間はデプロイのグループ化に使用できます。 また、マルチテナントのシナリオで、同じアプリの全テナントの全通知ハブを表すために使用することもできます。

地理的分散

プッシュ通知のシナリオでは、地理的分散は常に重要というわけではありません。 デバイスにプッシュ通知を配信するさまざまな PNS (たとえば、APNs や FCM) は、均等に分散されていません。

世界中で使用されるアプリケーションの場合は、Notification Hubs サービスを使用して、世界のさまざまな Azure リージョンでさまざまな名前空間にハブを作成することができます。

アプリのバックエンドからの登録は、登録を作成する前にクライアントを認証する必要がある場合に便利です。 アプリのロジックに基づいてアプリのバックエンドによって作成または変更される必要があるタグがある場合にも便利です。 詳細については、「バックエンド登録のガイダンス」ページと「バックエンド登録のガイダンス 2」ページを参照してください。

Azure Notification Hubs では、Shared Access Signature ベースのセキュリティ モデルを使用しています。 Shared Access Signature トークンはルートの名前空間レベルや詳細な通知ハブ レベルで使用できます。 メッセージ アクセス許可の送信や、通知アクセス許可のリッスンなど、さまざまな承認規則に従うように、Shared Access Signature トークンを設定できます。 詳細については、Notification Hubs のセキュリティ モデルに関するドキュメントを参照してください。

すべての通知は、プラットフォームの PNS によってターゲット デバイスに送信されます。 通知は、Azure Notification Hubs に送信されると、処理されて該当する PNS に渡されます。

Azure Notification Hubs を経由して送信者から PNS に至る間のすべての接続で、HTTPS が使用されます。

機密情報が含まれているペイロードを送信するには、安全なプッシュのパターンを使用することをお勧めします。 送信者は、機密情報のペイロードが含まれていない、メッセージ識別子の付いた ping 通知をデバイスに配信します。 デバイス上のアプリがペイロードを受信すると、アプリはセキュリティで保護された API を直接呼び出して、メッセージの詳細をフェッチします。 このパターンの実装方法のガイドについては、Notification Hubs の安全なプッシュのチュートリアルに関するページを参照してください。

「Azure Notification Hubs の高可用性」をご覧ください。

Azure Notification Hubs では、登録タグ以外の、保存中のすべての顧客データが暗号化されます。 このため、タグを使用して個人または機密のデータを格納しないでください。

はい。 すべての Notification Hubs 管理操作は、Azure アクティビティ ログに記録されます。このログは、Azure portal 上で公開されます。 Azure アクティビティ ログでは、サブスクリプションのリソースに対して実行された操作に関する分析情報が提供されます。 アクティビティ ログを使用すると、サブスクリプションのリソースに対して行われた書き込み操作 (PUT、POST、DELETE) すべてについて、いつ、誰が、何を行ったのかを確認できます。 さらに、操作の状態など、重要性の大きなプロパティを確認することもできます。 ただし、 アクティビティ ログには、読み取り (GET) 操作は含まれません。

Azure Notification Hubs には、トラブルシューティングを行うための機能がいくつか用意されています。これらは特に、通知が停止される最も一般的なシナリオで使用します。 詳細については、Notification Hubs のトラブルシューティングに関するホワイト ペーパーを参照してください。

Azure Notification Hubs では、Azure Portal で利用統計情報を表示できます。 使用できるメトリックの詳細については、Notification Hubs のメトリックに関するページを参照してください。

プログラムでメトリックにアクセスすることもできます。 詳細については、次の記事を参照してください。

• Retrieve Azure Monitor metrics with .NET (.NET を使用した Azure Monitor メトリックの取得) このサンプルでは、ユーザー名とパスワードを使用します。 証明書を使用するために、この例に示すように、FromServicePrincipal メソッドをオーバーロードして、証明書を提供します。
• Getting metrics and activity logs for a resource (リソースのメトリックとアクティビティ ログの取得)
• Azure 監視 REST API のチュートリアル