Windows Azure

channel9で公開されているde:code2014のセッション動画で、エヴァの井上さんが話された「Azure Mobile Services & Notification Hubs で全てのデバイスにプッシュ通知を送る」をまとめた投稿です。

プッシュ通知とは?

image

アプリが非アクティブでもバックエンドでデバイスに新しい情報を表示することができる機能が、プッシュ通知です。好きなタイミングで好きなメッセージを送れる機能です。プッシュ通知によって、アプリケーションの起動きっかけを作るのです。

プッシュ通知の仕組み

image

バックエンドのアプリケーションから直接、端末のアプリケーションに通知を送っているわけではないのです。

image

バックエンドから、各ベンダーが提供するPNS(Platform Notification Services)経由で端末にプッシュ通知します。Windows 8の場合はWNS、iOSの場合はAPNs、Androidの場合はGCMとそれぞれおベンダーごとにPNSが異なり、プロトコルも異なります。

バックエンドからPNSには、ハンドルごとにリクエストをします。ハンドルは端末固有のトークンで、端末1つにつき1リクエスト送信する必要があります。たとえば、10万台のデバイスに通知する場合には、10万回リクエストを送信しないといけないのです。あるお客さんの例では、リクエストを送信し始めてから送信終了まで、4時間かかったケースもあります。

image

ハンドルは、アプリケーションがPNSから取得して、それをバックエンドのサーバーに保存して使用するという流れになります。

image

ハンドルは上記例のように、単なる文字れるです。一番上がAndroid、二つ目がWindowsのハンドルです。

image

一般的な課題としては、4つです。

プラットフォームごとに対応をしないといけないので、マルチプラットフォーム対応が必要になります。また、正常に送信できたのか失敗したのかをトレースしたいのでエラー処理が必要です。さらに、端末はどんどん買い換えていくのでハンドルが変わっていくので、サーバーにゴミデータがたまるので、データのライフサイクル管理が必要です。そして、大量の宛先に素早く送信するためのリアルタイム大量通知が課題になります。

Azureの2つの通知サービス

Microsoft Azureには2つの通知サービスが提供されています。
2種類の通知サービスが提供されているので、度々理解の混乱のもととなっています。

image

最初に登場したのが、BaaSの機能の一つとしてMobile Servicesの中でプッシュ通知を提供していました。その後に登場したのが、プッシュ通知に特化した通知ハブ(Notification Hubs)と言うサービスが提供されました。

image

Mobile Servicesの通知も改良されています。
管理ポータルでMobile Servicesのプッシュタブを見ると、上記画像のように表示されます。今は、通知ハブのAPIを使うように改良されているのです。
今後、通知の機能を使う場合には、通知ハブを意識していただければOKです。

image

通知ハブになると、いろいろな課題が改良されました。Mobile ServicesはBaaSの一部だったので、通知だけ欲しい顧客には大きすぎたり、あまり課題が改良されていなかったのです。

通知ハブのプッシュ通信

通知ハブはREST APIで操作します。
.NET、Node.jsのSDKが提供されており、直接REST通信をしなくても良いようになっています。

image

通知ハブは、プッシュ通知のハブとなるサービスです。
バックエンドとPNSの間にあって、様々な処理を受け持ちます。

バックエンドから通知ハブにリクエストを送り、通知ハブにデータベースがありハンドル情報を保持しているので、通知ハブから並列にPNSにリクエストを送信します。

image

通知ハブにリクエストを送信すると、ゲートウェイノードが受信しキューに登録します。通知ノードがキューを取得し、データストアからハンドルを取得します。ハンドルを取得して、数万とかある大量の通知だと判明すると、自動的に通知ノードがスケールします。通知ノードが自動的に何台も立ち上がって、並列に通知してくれます。

image

通知が失敗すると、PNSからエラーを受け取って、データストアに格納してくれます。また、ハンドルがどんどん新しいものに変わっていきますので、それも管理してくれます。期限切れしたハンドルは勝手に削除してくれます。

image

プッシュ通知の課題をしっかりと解決してくれています。
50万通で2040円ぐらいです。
これを自前で実装するには相当の開発と運用工数がかかるため、自前で用意するのが割にあわなくなっています。

image

どれぐらいスケールするのか。
Bingニュースの事例では、300万台以上の端末に2分以内で通知できています。

通知サービスの実装とテスト

image

提供されているSDKは、サーバーサイドは.NETとJavaScript、クライアントサイドはだいたい通常使われる端末は用意されています。

image

重要なクラスが2つあります。

NotificationHubClientクラスは、管理用のクラスです。通知ハブのデータべースの読み書きや通知の送信ができたり、なんでもできるサーバサイドのクラスです。

NotificationHubクラスは、PNSからハンドルをとってきて、通知ハブにハンドルを登録する、フロントのクラスです。

image

NotificationHubClientクラスは、Microsoft.ServiceBusの中に含まれているので、最初にNuGetで取得してきてください。

image

クライアントのほうは、Microsot.WindowsAzure.Messaging.Managedに、NotificationHubクラスが含まれているのでインストールしておいてください。

image

PushNotificationChannelManager.CreatePushuNotificationChannelForApplicationAsyncを呼ぶとPNSからハンドルを取得してきます。
NotificationHubで、通知ハブの名前を設定し、通知ハブの接続情報を指定します。
RegisterNativeAsyncで、ハンドルの情報を渡すと通知ハブのデータベースにハンドルを登録します。

 

image

image

Andoroidの場合も、同様の流れで操作できます。これはSDKが提供されているからです。
NotificationHubは同じで、Androidの場合はm、gcmからハンドルを取得してきて、通知ハブのデータベースにハンドル情報を登録します。

image

Microsoft Azureの管理ポータル上から、サーバーサイドの実装をしてなくてもプッシュ通知のテストをしたりすることができます。

サーバーサイドの実装です。
NotificationHubClient.CreateClientFromConnectionStringで、管理者用の接続情報を設定します。

image

メッセージ本文を設定し、送信します。メッセージ本文は、それぞれの端末の通知の従って記述します。そして、送信メソッドで送信します。
Androidは、SendGcmNativeNotificationAsync
iOSは、SendAppleNativeNotificationAsync
windowsは、SendWindowsNativeNotificationAsync

image

image

タグを使用して、特定のユーザーやグループだけに通知を送ることができます。通知ハブにタグを登録しておいて、タグでフィルタリングして送信できます。

image

image

タグは文字列です。
タグの登録には、RegisterNativeAsyncで、ハンドルとタグを指定します。

image

送信には、送信メソッドSendGcmNativeNotificationAsyncに、タグを渡してあげるだけでOKです。

タグのほかの使い方としては、アクセスログから長期間アクセスしていないユーザー全員にプッシュ通知をするというような使い方もできます。

image

image

image

テンプレート機能で一斉に複数プラットフォームにメッセージを変更して、データ送信することもできます。

image

大量配信のテストをしたいという要望があります。
その場合に裏技として、通知ハブに同じハンドルを大量に登録しておく方法があります。
同じハンドルを100件登録しておけば、100件の送信テストができます。
(同じ端末に100個通知されます…。)

Windows Azure

AzCopyを、お前らがもっと使えるようにガイドライン的なチュートリアルを用意してやるぜ!ってマイクロソフトがおっしゃって、ドキュメントがででで~んっと公開されています。

とりあえず、これを見ればAzCopyの全てがわかるって感じです。ここにかかれていない情報は、他にも書かれてないぜ!ぐらいの勢いで、大量の文章が用意されています。素敵。ぜひ日本語版も用意して!

主な使用例を抜粋。

 

  • 特定パターンに当てはまったBlobをアップロード
  • 別のストレージアカウントにBlobをコピーしてスナップショットをする
  • 複数のレスポンスファイルを指定する
  • ジャーナルファイルパスの指定
  • AzCopyのリジューム
  • 任意の場所にログ出力
  • 新しいファイルをBlobから取り除く
  • 古いファイルをBlobから取り除く
  • ストレージエミュレーターのBlobリソースに対してAzCopyの実行
  • Azure File共有からファイルシステムにファイルをダウンロード
  • Azure File共有からファイルシステムにファイルとディレクトリをダウンロード
  • ファイルシステムからファイルとディレクトリをAzure File共有にアップロード
  • 特定パターンにマッチしたファイルをAzure File共有にアップロード

Windows Azure

AzCopyの最新バージョンがリリースされました。
このバージョンでは、パフォーマンスや使用勝手の重要な改善が含まれています。

いくつか抜粋して紹介します。
アップデートの全体像は、原文を参照してください。

  • デフォルトでジャーナルファイルが生成されるようになりました。
    従来は、[/z]オプションが必要でしたが、今回のバージョンから指定しなくても生成されるようになりました。ジャーナルファイルは、デフォルトでは、%localAppData%\Microsoft\Azure\AzCopy\に格納されます。格納先パスは、/zオプションで宇和がクコとができます。
  • AzCopyの実行ログのデフォルトフォルダーが、%localAppData%\Microsoft\Azure\AzCopy\になりました。
  • インストールウィザードで、AzCopyのインストール先を指定できるようになりました。

Windows Azure

元記事:How to Monitor for Storage Account Throttlingを抜粋、意訳し加筆しています。

Azureサブスクリプション・サービスの制限、容量、制約」で説明されているように、ディスク毎に500IOPSの制限があり、ストレージアカウント毎に20,000IOPSの制限があるので、Azure仮想マシン用に、一つのストレージアカウントで40より多くのVHDsを置かないように案内しています。

デフォルトでは、各サブスクリプションでは最大20のストレージアカウントを持つことができます。サブスクリプションでもてるストレージアカウントの最大数は、Microsoftサポートに連絡することで、20から最大50まで増やすことができます。

ストレージアカウントのスロットリングのリスクは、一つのストレージアカウントに40以上のVHDsを置くと、仮想マシンにネガティブなパフォーマンス影響を及ぼすことです。40以上の仮想ディスクがあると、それぞれのディスクは500IOPSの制限に達する前に、20,000IOPSの制限にひかかってしまいます。

ストレージアカウントでディスク数を計測する

ポータルで、仮想マシン配下にあるDisksを見ることで、マニュアルでストレージアカウント毎のディスク数を取得することができます。

image

 

同じストレージアカウントのディスクで、場所カラムのDNS名が同じになります。たとえば、場所列のhttps://clnorthcentralusstorage.blob.core.windows.net/で、clnorthcentralusstorageがストレージアカウント名になります。

Azure PowerShellのGet-AzureDiskコマンドレットを使用すると、ストレージアカウント毎のディスク数を簡単に取得することができます。

Get-AzureDisk | Where-Object { $_.AttachedTo } | Group-Object {$_.Medialink.Host.Split('.')[0]} –NoElement

Count Name
----- ----
 46 clnorthcentralusstorage

ストレージアカウントのスロットリングを監視する

ストレージアカウントのスロットリングを監視するために、Azure管理ポータルで、ストレージを選択肢、監視したいストレージアカウントを選択し、構成タブを選択し、監視セクションで、Blobをオフから最小に変更します。

image

 

監視タブに切り替え、メトリックスの追加ボタンを選択し、監視する目トリックの選択から、調整エラーと調整エラーのパーセンテージを選択します。

image

監視を設定すると、6時間、24時間、7日間の最小、最大、平均、合計の発生数を表示することができます。

Windows Azure

Azureサブスクリプションを管理するためにマイクロソフトが一般提供しているツール(ポータル、新しいポータル、Powershell、X-Plat CLI)は、すべてAzure Service Management REST APIを使用しています。

Azure Powershellでデバッグ情報を参照するには、[-Debug]スイッチを指定します。

image

 

Azure Cross Platform CLIの場合は、[-vv]スイッチを指定します。

image

 

元ネタ:Learning Azure Service Management REST API through Powershell, and Azure CLI tools