Build 2018 が始まったようですね。基本的な内容は明日の朝にブチザッキを見て確認する予定ですが、Cloud Platform Release Announcements に Azure SignalR Service という心惹かれる項目があったので、サクッと確認してみました。
Azure Blog でも紹介されてました。SignalR を大規模に使うと、大体はスケーリングと管理がめんどくさくなってしまうのですが、その辺りは Azure にお任せという何時もの流れです。
内容からして SignalR の WebSocket などを利用した接続部分だけ外部サービスとして切り出すものだと思っていましたが、必然的にクロスドメインになるので少し挙動が気になってました。使えるトランスポートは WS / SSE / XHR のようです。
チュートリアルがまとまっていたので、参考にしつつ適当なアプリケーションを用意しました。
とりあえず先に Azure SignalR Service を作成しておきます。Preview 中は Pricing Tier としては Free / Basic が選べます。Basic を選んだ場合のみ 10 ユニットまで拡張することが出来るようになってます。
将来的には Standard や Premium が追加されて上限が増えるのではないかと予想します。
当然ながら使用可能なリージョンに日本はないので、West US 2 に作成することにしました。Basic での 1 ユニット当たりの価格は非常にお手軽ですね。おそらく裏側の Redis 分も含まれているはずです。
グローバル IP は固定みたいなので、カスタムドメインも設定できるようになりそうです。
恐らくこの性能でリミットがかかっているわけではなく、あくまでも目安という感じがします。*1
デプロイ自体は割とあっという間に完了します。数分以内に 3 ユニットが立ち上がってきたので、裏側はそれなりに気合が入っている感じがします。
Pricing Tier に Basic_DS2 とあったのが少し気になりました。VM のサイズ感ありますね。
アプリケーションの開発は ASP.NET Core SignalR と同じですが、追加で Azure SignalR Service 用の NuGet パッケージをインストールします。
この辺りはサンプルコードと同じなので省略しますが、普通に SignalR アプリケーションが動くようになりました。予想通り WebSocket 接続は Azure SignalR Service を向いていました。
negotiate が多いですが、初回の段階で Azure SignalR Service のエンドポイントを返しているので、その後のリクエストは全てローカルには流れてきません。
完全に Hub などの操作を行うサーバーサイドと、WS / SSE などでの配信を行う部分が完全に切り離された実装になっているので、スケールがさせやすそうです。
Azure Functions からも接続文字列だけあれば、簡単にメッセージを投げることが出来るみたいですが、クライアントライブラリが未整備のようなので、いきなり使うにはちょっとハードルが高いと思いました。
API のドキュメントがぱっと見公開されてないみたいなので、割と厳しそうです。とはいえ、アーキテクチャ的には重要な使い方になってくると思うので、GA までにはリリースされるのではないかと。
