銀の光と碧い空

クラウドなインフラとC#なアプリ開発の狭間にいるエンジニアの日々

Microsoft Build 2018 のSignalR関連のセッションの整理

Q#に引き続き、SignalR関連セッションの情報まとめです。

tech.tanaka733.net

(ブレークアウトセッション) Meet the new stack for real-time web communication: ASP.NET Core SignalR

youtu.be

ASP.NET Core SignalR overview

  • "Hubs" を使ったRPC style
  • ServerからClientはglobal, グループ、個別を選べる
  • HubのメソッドからのStreamの返り値はChannelクラスとなる
  • クライアントライブラリはTS/JSと.NET
  • JSONとMessagePackがドキュメント化されている実装プロトコル
  • WebScockets, Server Sent Events, Long Pollingから選択
  • ASP.NET Coreのrouting, DIとの統合
  • Redisもしくは新しいAzureのサービスを利用してスケールできる

既存のSignalR からの変更点

  • jQueryの依存性なし
  • メッセージの再送つきの自動再接続なし
  • Hubの状態ももたなくなった
  • 複数Hubのendpointもなし
  • 単一モデルでのスケールアウトもなし
  • 複数サーバー間のping-pongがなくなるため、sticky sessionが必要となる

SignalR機能概要

  • routing
  • Hubパラメーターbinding
  • JSON および MessagePackプロトコル
  • Controllerからのpush通知
  • グループとbackgroundサービスからのpush通知
  • 型付のHub
  • 認可
  • HubメソッドからのStream
  • .NET Client

Hubの下回りの構造

従来のSingalRは Hub-HubDispatcher-PersistentConnectionMiddleware-OWIN-System.Web HttpHandler

ASP.NET Core SignalR Hub-HubConnectionHundler-HubConnectionDispatcher-RoutingMiddleware-ASP.NET Core HTTP Pipeline

HTTPではなくTCP/IPを利用した転送も計画中

over HTTPの場合 Hub-HubConnectionHandler-HttpConnectionDispatcher-RoutingMiddleware-ASP.NET Core HTTP pipeline-Kestrel-Sockets or Libuv

over TCP/IP Hub-HubConnectionHandler-Kestrel-Sockets or Libuv

Project Bedrockの紹介

  • .NETのための新しい高パフォーマンスネットワーク抽象化
  • transport層からapplication層を取り除く
  • System.Net.Sockets と libuv を利用
  • アプリケーション層の書き換えなしに導入可能
  • ASP.NET Coreを対象
  • 新しいSystem.IO.Pipelines APIを利用
  • ClientとServer両方

ベンチマークを公開中 https://aka.ms/aspnet/benchmarks

Demoサンプル

KestrelHttpServer/BenchmarkApplication.cs at dev · aspnet/KestrelHttpServer · GitHub

Azure SignalR Service

  • SignalR clientの接続とスケールアウトのためのPaaS
  • ASP.NET Core SignalR と Bedrockを利用
  • サービスへの接続のオフロードやアプリケーションから/へのトラフィックの転送
  • ドキュメント化されているプロトコルが利用可能
  • web側のtrafficと独立してSignalRのみの簡単のスケールが可能
  • 2行のコードの変更で既存アプリから変更可能
  • public preview!

Azure SignalR Serviceの利用

これだったのか Hub-HubConnectionHandler-HubConnectionDispatcher-RoutingMiddleware-ASP.NET Core HTTP Pipeline

こうなる Hub-HubConnectionHandler-ServiceHubDispatcher-WebSocket Clients

今後の実装計画

  • クライアント再接続
  • より柔軟な接続。client intiated pingsなど
  • クライアント側の型付Hub
  • Java,C++,iOSなどのクライアント
  • TCP/IPを含めたさらなるtransports。サンプルではなく実際に利用できるものとして。

(シアターセッション) Build and manage real-time applications easily with the all new Azure SignalR Service

こちらは動画が公開されていないので、見てきたときのメモから。

Azure SignalR Service, a fully-managed service to add real-time functionality https://azure.microsoft.com/en-us/blog/azure-signalr-service-a-fully-managed-service-to-add-real-time-functionality/

数十人の参加者に開発したことのあるSignalRの規模を質問。ぱっと見た限り、100接続以上が10人くらい、1000接続が数人、10000接続以上はなし。

  • 上のセッションで公開したデモは2'40ほどの間に800人から接続され、100万メッセージ以上、秒間だいたい35kを処理。
  • Free Tier/Basic Tier
  • 使えるリージョンはいまのところ US E/US W/SE Asia/EU W
  • サービスを作成すると接続文字列が表示されるので、それをアプリ側で設定。
  • Azure Functionsを使ってServerless構成も可能

Microsoft Build 2018 のQ#関連のセッションの整理

Q# が発表されてから、おそらく公式のカンファレンスでは初めてではないかと思いますが、先週シアトルで行われたBuild 2018で技術解説セッションがありました。Youtubeでセッションが公開されているので、それを見た雑多なメモを残しておきます。

Empowering the quantum revolution with Q

youtu.be

マイクロソフトのユニークなソリューション

  • 統合的なソリューション Q#/Quantumn SDKを含めたソフトウェア開発キットや、Azureで提供されるというシミュレーターを含めた提供
  • スケーラブルなトポロジカル量子コンピューティング IBMやGoogleとは異なる、トポロジカル超伝導体のマヨラナ粒子を利用するといわれるスケーラブルな量子コンピューターを開発中
  • 大胆な投資とグローバルなチーム 昨年のIgniteで見せていたデバイスは世界中の研究室を巡って開発している

なぜ量子コンピューターか

たとえば2つの大きな素数の積の整数を素因数分解する問題を考えた場合、古典的コンピューターよりも量子コンピューターの方が圧倒的に早いことが期待されている。このような古典的コンピューターでは指数関数的に計算量が爆発する問題を、量子コンピューターでは線形程度の増加で抑えることができる。

今後、自然科学の分野で量子コンピューターが利用されることが期待されている。

Microsoftのめざす量子コンピューター

光が波と粒子の性質を兼ね備える、というところから説明がスタート。

30 qubitsで16Gb 40 qubitsで16Tb 50 qubitsで16Pb に相当。

重ね合わせ、量子測定、もつれ、などの物理現象と関連。

マヨラナ粒子は理論的には予測されていた。2000年、Micorosoftはマヨラナ粒子を利用したコンピューティングを数学者とともに進める。 2012年にその兆候を実験室で観測。

現在、GoogleやIBMなどがすでにQubitsを実現しているが、それらのスケーラビリティとエラーレートはそれぞれ違う。Microsoftはスケーラブルかつエラーレートの低いQubitの実現に向けて動いている。最初のエンタープライズレベルにスケーラブルなQubitを。いまの方向がそれを実現できるものだと信じている。

Qubitは15mKほどの低温の孤立した環境で実現している。これは希釈冷凍機を利用して実現しており、液体窒素(77K)、液体ヘリウム(4K)、宇宙背景放射(3K)より低い。 量子コンピューターそのものは15mKにあるが、希釈冷凍機のコンピューターと制御ソフトウェアは4Kにあり、量子コンピューターとは数千のワイヤーで繋がっている。 また、ライブラリを利用して記述して、実際の問題を解くために動かすソフトウェアは室温部分にある。

この、量子コンピューター、制御ソフトウェア、ライブラリと開発言語の3つのスタックが必要だと考えている。スケーラビリティに必要なものは次のようなものだと考えている。

  • スケーラブルなQubitの基礎
  • 冷凍装置
  • 量子と古典的コンピューターのインターフェース
  • 量子エラーを識別し訂正するための新しいプラットフォームの開発
  • スケーラブルなソフトウェアスタック
  • Azureとの完全な統合
  • アルゴリズムと現実世界の問題

スケーラブルなエンタープライズ量子コンピューターを最初に提供する」が今のところの目標らしい。

Microsoft Quantum Development Kit

量子ロジックのルール

  • 全ての操作は可逆的でなければならない
  • 測定は状態を破壊する
  • 状態を複製できない

量子状態をブロッホ球で表現する

古典的操作と量子操作の比較

  • 古典的操作
    • 1bit: NOT
    • 2bit: NAND/NOR n bit での全ての操作はn 入力をもつNANDgatesの有限回の操作で実現できる
  • 量子操作

    • 1 qubit
      • X,Y,Z パウリ回転
      • 位相演算子 S, H ゲート
    • 2 qubit
      • CNOT n qubitsでの全ての操作は、クリフォード群とT ゲートの有限回の操作で実現できる
  • 古典的コンピューター ドモルガンの法則で式の削減と変換ができる

  • 量子コンピューター Clifford群はパウリ群を共役作用のもとで不変である

Q#言語の特徴

  • ブロックスタイルの記述に近しい
  • 関数型言語に触発されている
    • デフォルトでイミュータブル
    • ファーストクラスの関数
    • 部分適用
  • 強い型システム
    • ジェネリクス
  • 量子特有のコンセプト
    • Functor
    • リソース管理
    • 古典制御部分との相互作用の削減

Q# 言語の論理モデル

Q# ライブラリとコードでホストプログラムを動かす。動かす先は、シミュレーターもしくはDriver経由で実際の量子ハードウェア、もしくはAzureシミュレーター。

QDK ライブラリ

  • HW固有のゲートをきれいに表現
  • 包括的なライブラリ
    • 数学
    • 位相推定、振幅増幅、QFT(量子フーリエ変換)
    • ハミルトニアンシミュレーター
    • 誤り訂正と蒸留
    • Quantum Characterization Verification & Validation (QCVV
    • Functional Abstraction & Combinator
  • 十分なサンプル
  • オープンソース、PRを受付

ターゲットマシン

  • 最先端のLocal Simulator: ローカルマシンの16GBで30qubitをシミュレーション
  • 最先端のAzure Simulator: 40 qubit以上
  • Quantum Trace Simulator: コードを評価して、どのくらい量子リソースが必要かを決定する
  • Microsoft Quantum System

参考資料

Setting up the Q# development environment | Microsoft Docs

Quantum computing | Microsoft

GitHub - Microsoft/Quantum: Microsoft Quantum Development Kit Samples and Libraries

付録:エラー訂正

古典的エラー訂正はノイズモデルに基く。0,1のビット配列を送信するときあるbitが誤って送信される確率をpとして、十分低いエラーレートでn論理ビット配列を送信するのに必要な物理bit配列はいくつになるのか?

量子エラー訂正ではエンタングルメント(もつれ)が鍵となる。1量子サイクルの間にqubitもしくは操作が失敗に終わる確率。

THR2503 Learn to build you first quantum solution with the Quantum Development Kit and Q

youtu.be

Visual Studio/Visual Studio Codeでの最初のQ#プロジェクトの作成を説明。 今までのプラグラミングとは異なるライブラリでプログラムを書いている。

Q#はQ#ライブラリを使ってQ#のコードを書き、それを古典的プログラムであるホストプログラムを通して実行する。実行先はシミュレーターもしくはDriver経由で実際の量子デバイスとなる。

実際にコードの説明。 Mainメソッドで、量子シミュレーターオブジェクトを生成し、Q#で記述したクラスを実行している。Q#で記述したコードはC#から通常のクラスとして見えている。 => 現在のSDKではQ#のコードはC#のコードにコンパイルされている(XAMLと同じようなイメージ)

Q#のコードはデフォルトで副作用がなく、また状態の複製も行えない。 Q#のコード中にブレークポイントをおき、そのときの変数の値を確認することもできる。

また、同じことがVisual Studio Codeで実現できる。.NET Coreで動くので、LinuxやmacOSでも開発できる。

Azure の Linux 仮想マシンを仮想マシンの内部からdeallocateする

このエントリはこちらのブログの日本語版になります。

developers.redhat.com

AzureにたてたLinux仮想マシンをdeallocateしたい場合、Azure Portalにログインできればそこからログインしたり、REST APIを実行する権限を作って適宜プログラムからdeallocateすることができます。しかし、そのLinuxにログインできる権限しか無い場合、OSのshutdownコマンドを実行してもdeallocateはされないため、仮想マシンの利用料金はかかり続けます。そこで仮想マシンの中からdeallocateするようにしてみたいと思います。

deallocateするにはREST APIを実行する必要があるので、Azure CLI 2.0をインストールして、Azure AD APPでService Principalを作成して認証を行います。もちろんService Principalのパスワードを指定してもいいのですが、パスワードを平文で保存することが懸念の場合は、Managed Service Identity (MSI)を利用してパスワードを利用せずに認証することができます。今回はその方法を紹介することにします。

続きを読む