全般
Notification Hubs のリソース構造について教えてください。
Azure Notification Hubs には、2 つのリソース レベルとして、ハブと名前空間があります。 ハブは、1 つのアプリのクロスプラットフォーム プッシュ情報を保持できる単一のプッシュ リソースです。 名前空間は、1 つのリージョンのハブのコレクションです。 推奨されるマッピングでは、1 つの名前空間を 1 つのアプリに対応付けます。 その名前空間内に、運用アプリで動作する運用環境ハブ、テスト アプリで動作するテスト ハブなどを配置できます。
Notification Hubs の価格モデルを教えてください。
最新の価格情報については、「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 のメッセージごとのテレメトリを使用して、デバッグのためにすべてのプッシュ要求とプラットフォーム通知システムのフィードバックを追跡できます。
- マルチテナント: プラットフォーム通知システムの資格情報を名前空間レベルで使用することができます。 このオプションにより、テナントを同じ名前空間内のハブに簡単に分割することができます。
- プッシュのスケジュール:通知をいつ送信するかをスケジュールすることができます。
- バルク操作: 登録のエクスポートとインポートに関するドキュメントで説明しているように、登録のエクスポート/インポート機能を有効にします。
Notification Hubs の SLA について教えてください。
Basic と Standard の Notification Hubs レベルでは、適切に構成されたアプリケーションは、少なくとも 99.9% の時間、プッシュ通知を送信したり、登録管理操作を行ったりすることができます。 SLA の詳細については、「Notification Hubs の SLA」ページを参照してください。
Note
プッシュ通知はサードパーティのプラットフォーム通知システム (Apple の Push Notification Service (APNs)、Google の Firebase Cloud Messaging (FCM) など) に依存するため、これらのメッセージの配信に対する SLA 保証はありません。 Notification Hubs がプラットフォーム通知システムにバッチを送信 (SLA 保証あり) した後、プッシュの配信 (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 の使用チュートリアルに関するページを参照してください。
テキスト メッセージ、電子メール、または Web 通知をサポートしていますか。
Notification Hubs は、モバイル アプリを実行しているデバイスに通知を送信します。 電子メールまたはテキスト メッセージの機能は用意されていません。 また、Notification Hubs には、すぐに使えるブラウザー内プッシュ通知の送信サービスもありません。 この機能は、サポートされているサーバー側プラットフォームで SignalR を使用すれば実装できます。
Notification Hubs を使用してプッシュ通知を送信する場合、サポートされるデバイス数は何台ですか。
サポートされているデバイス数の詳細については、「Notification Hubs の価格」ページを参照してください。
1000 万を超える登録デバイスのサポートが必要な場合、複数の名前空間でデバイスをパーティション分割する必要があります。
送信できるプッシュ通知の数を教えてください。
選択されているレベルに応じて、Azure Notification Hubs は、システムで通信されている通知の数に基づいて自動的にスケールアップします。
Note
使用の全体コストは、送信するプッシュ通知数に基づいて増加する場合があります。 レベルごとに上限があることに注意してください。概要については、「Notification Hubs の価格」ページを参照してください。
Notification Hubs を使用しているお客様は、毎日数百万のプッシュ通知を送信しています。 Azure Notification Hubs を使用している限り、プッシュ通知のリーチを拡張するために特別な処理は必要ありません。
プッシュ通知が自分のデバイスに到達するまでどのくらいの時間がかかりますか。
Azure Notification Hubs では、着信負荷が一定で均一な通常の使用シナリオにおいては、"1 分間に少なくとも 100 万件のプッシュ通知" を処理できます。 この数は、タグの数、着信する通知の性質、その他の外部要因によって異なります。
サービスは、この推定配信時間中に、登録したタグやタグ式を基にしてプラットフォームあたりのターゲットを計算し、プッシュ通知サービス (PNS) にメッセージをルーティングします。 デバイスに通知を送信するのは、PNS の役目です。
PNS は、通知の送信に関するいかなる SLA も保証しません。 ただし、ほとんどのプッシュ通知は、Notification Hubs に送信されてから数分以内に (通常は 10 分以内に) ターゲット デバイスに配信されます。 一部の通知は、もう少し時間がかかります。
Note
また、Azure Notification Hubs には、30 分以内に PNS に配信できないプッシュ通知を停止するポリシーがあります。 こうした遅延にはさまざまな理由が考えられますが、最も一般的な理由は PNS がアプリケーションをスロットルしているためです。
遅延に対する保証はありますか。
プッシュ通知の性質 (外部のプラットフォーム固有の PNS によって配信されるしくみ) のため、遅延に対する保証はありません。 通常、ほとんどのプッシュ通知は数分以内に配信されます。
Azure Notification Hubs ではデータはどこに格納されますか。
Azure Notification Hubs では、お客様の登録データはお客様が選択したリージョンに格納されます。 Notification Hubs では、メタデータ (Notification Hubs の名前、接続文字列、その他の重要情報など) のディザスター リカバリー対応を提供しています。 ブラジル南部と東南アジアを除くすべてのリージョンでは、メタデータ バックアップは別のリージョン (通常は Azure ペア リージョン) でホストされます。 ブラジル南部および東南アジア リージョンでは、バックアップは、これらのリージョンのデータ所在地の要件に対応するために同じリージョンに格納されます。
名前空間と通知ハブを使用するソリューションを設計する際には、何を考慮する必要がありますか。
モバイル アプリ/環境
- 1 つの環境、1 つのモバイル アプリに対して、1 つの通知ハブを使用してください。
- 複数テナントのシナリオでは、各テナントで個別のハブが必要になります。
- 運用環境とテスト環境で、同じ通知ハブを共有しないでください。 そのような設定では、通知を送信するときに問題が生じる場合があります (Apple では、Sandbox と Production Push エンドポイントをそれぞれ個別の資格情報で提供しています)。
- 既定では、Azure Portal または Visual Studio の Azure が統合されているコンポーネントから、登録済みのデバイスにテスト通知を送信できます。 しきい値は、登録プールからランダムに選択される 10 個のデバイスに設定されています。
Note
ハブが最初は Apple サンドボックス証明書で構成され、その後 Apple 運用証明書を使用するように再構成された場合、元のデバイス トークンは無効になります。 無効なトークンは、プッシュの失敗の原因になります。 運用環境とテスト環境は別にして、それぞれの環境で別個のハブを使用することをお勧めします。
PNS の資格情報
モバイル アプリがプラットフォームの開発者ポータル (Apple、Google など) に登録されている場合は、アプリの識別子とセキュリティ トークンが送信されます。 アプリのバックエンドは、プッシュ通知をデバイスに送信できるように、プラットフォームの PNS にこれらのトークンを提供します。 セキュリティ トークンは、証明書の形式 (たとえば Apple iOS や Windows Phone) またはセキュリティ キーの形式 (たとえば Google Android や Windows) にすることができます。 これらは、通知ハブで構成する必要があります。 構成は通常、通知ハブ レベルで行われますが、マルチテナントのシナリオでは名前空間レベルで行うこともできます。
名前空間
名前空間はデプロイのグループ化に使用できます。 また、マルチテナントのシナリオで、同じアプリの全テナントの全通知ハブを表すために使用することもできます。
地理的分散
プッシュ通知のシナリオでは、地理的分散は常に重要というわけではありません。 デバイスにプッシュ通知を配信するさまざまな PNS (たとえば、APNs や FCM) は、均等に分散されていません。
世界中で使用されるアプリケーションの場合は、Notification Hubs サービスを使用して、世界のさまざまな Azure リージョンでさまざまな名前空間にハブを作成することができます。
Note
この配置は、管理コスト (特に登録のコスト) が高くなるため、お勧めしません。 どうしても必要な場合にのみ行ってください。
登録はアプリのバックエンドから行うべきですか。クライアント デバイスから直接行うべきですか。
アプリのバックエンドからの登録は、登録を作成する前にクライアントを認証する必要がある場合に便利です。 アプリのロジックに基づいてアプリのバックエンドによって作成または変更される必要があるタグがある場合にも便利です。 詳細については、「バックエンド登録のガイダンス」ページと「バックエンド登録のガイダンス 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 が使用されます。
Note
Azure Notification Hubs では、メッセージのペイロードは記録されません。
機密情報が含まれているペイロードを送信するには、安全なプッシュのパターンを使用することをお勧めします。 送信者は、機密情報のペイロードが含まれていない、メッセージ識別子の付いた ping 通知をデバイスに配信します。 デバイス上のアプリがペイロードを受信すると、アプリはセキュリティで保護された API を直接呼び出して、メッセージの詳細をフェッチします。 このパターンの実装方法のガイドについては、Notification Hubs の安全なプッシュのチュートリアルに関するページを参照してください。
操作
ディザスター リカバリーのためにはどのようなサポートが提供されていますか。
「Azure Notification Hubs の高可用性」をご覧ください。
自分のデータはすべて暗号化された形式で格納されますか?
Azure Notification Hubs では、登録タグ以外の、保存中のすべての顧客データが暗号化されます。 このため、タグを使用して個人または機密のデータを格納しないでください。
監査ログ機能はありますか。
はい。 すべての Notification Hubs 管理操作は、Azure アクティビティ ログに記録されます。このログは、Azure portal 上で公開されます。 Azure アクティビティ ログでは、サブスクリプションのリソースに対して実行された操作に関する分析情報が提供されます。 アクティビティ ログを使用すると、サブスクリプションのリソースに対して行われた書き込み操作 (PUT、POST、DELETE) すべてについて、いつ、誰が、何を行ったのかを確認できます。 さらに、操作の状態など、重要性の大きなプロパティを確認することもできます。 ただし、 アクティビティ ログには、読み取り (GET) 操作は含まれません。
通知ハブはアンインストールを検出しますか?
デバイスを Registration
として保存した場合、その登録に初めて送信し、PNS がデバイスが無効であることを示すエラー状態コードで応答すると、デバイスは通知ハブから削除されます。
Installation
API を使用してデバイスを保存した場合、デバイスは上記のシナリオでは削除されません。 この決定は、ユーザーが再インストールするときに関連する可能性がある特定のユーザーに関するタグやその他のメタデータを保持するために行われました。
登録とインストールの両方に関して、有効期限を設定することで、デバイスが特定の時点で自動的にクリーンアップされるようにすることができます。 一般的なパターンは、ユーザーがアプリケーションを使用している限り、クライアント アプリケーションによって有効期限が 1 日に 1 回更新されて元に戻すようにすることです。
監視とトラブルシューティング
どのようなトラブルシューティングの機能がありますか。
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 のチュートリアル
Note
通知の成功は、単にプッシュ通知が外部の PNS (たとえば iOS および macOS の APNs や Android デバイスの FCM) に配信されたことを意味します。 ターゲット デバイスに通知を配信するのは、PNS の役目です。 通常、PNS は、配信メトリックを第三者に公開しません。