Something about Development Technology :-)

最近 気になるあのことや、ことのとについてあれやこれや書く Blog

Windows Azure Service Bus を活用した Windows 8 メトロ アプリケーションの開発 ~ クラウドカバー Episode 75

Windows Azure Service Bus を活用した Windows 8 メトロ アプリケーションの開発 ~ クラウドカバー Episode 75

  • Comments 0

 

今回のクラウドカバー「Episode 75 - Building Windows 8 Metro Apps using Windows Azure Service Bus」は、NathanNick をホストに、Service Bus の開発チームの Abhishek Lal をゲストに迎え、Windows 8 の メトロ アプリケーションにおいて、Service Bus をどのように活用していくかについて議論します。

 

 

では、いつものようにニュースから。

 

Announcing SQL Azure Data Sync Preview Update

最初のニュースは、SQL Azure の Data Sync サービスのアップデートから。

Data Sync は、クラウド上の SQL Azure と、オンプレミスの SQL Server を、あるいは、クラウドの SQL Azure 同士を同期するためのサービスで、プレビュー公開中です。

 

さて、この Data Sync においては同期対象となるデータを、Sync Group として定義するようになっています。これまで、この Sync Group の情報を変更しようとすると(たとえば、同期対象のデータを増やす、等)、Sync Group を作り直す必要がありましたが、これを編集(edit)できるようにした、というのが今回のアップデートのメインです。

Data Sync を評価中の方はぜひお試しくださいませ。

 

 

SQL Server 2012 is Generally Available!

コードネーム “Denali” (でなり)、と呼ばれていた SQL Server の最新版、”SQL Server 2012” のリリース(Generally Avaiable) のお知らせです。

SQL Server 2012 は、3月の初旬に完成しており、今回のアナウンス(4月2日付)では、この SQL Server 2012 の販売が開始されたことのお知らせとなります。

製品完成後、MSDN Subscription を通じて、開発者の方へは提供が始まっていましたが、4月からは開発者以外の方にも入手いただけるようになった、ということで、”Generally Avaiable” という言い方をしています。

 

さて、新機能満載の SQL Server 2012 ですが、日本においてもすでに、すてきナイスグループ様 、名古屋銀行様、ガンホー・オンライン・エンターテイメント様、などの企業において、導入を決定いただいております。

 

日本でのその他企業における先行事例については、同僚エバンジェリスト 井上大輔の Blog「SQL Server 2012 製品開発完了 (RTM)」もご参照ください。

 

 

Microsoft Online Backup Service using Windows Azure Blob Storage

Windows Server 2012 (※) を対象としたオンラインバックアップサービスの紹介ブログです。

このオンラインバックアップサービスですが、オンライン上のストレージとしては Windows Azure の Blob Storage を利用しており、バックアップ用のエージェントをインストールすることで、10GB までの枠内で、バックアップサービスを利用いただくことが可能です(現在はベータ公開中で、無償)。

 

Windows Server 2012 をご評価中の開発者/IT Pro の方は、ぜひ合わせてお試しください。

 

※ 現在開発中の次期 Windows Server は、コードネーム “8” で呼ばれており、リンク先ブログでもそのように記述されていますが、正式名称が “Windows Server 2012” になることが発表されています(開発中です)。

 

 

ということで、いよいよ本題の Service Bus なお話し。

image

 

 

Service Bus を簡単に言うと、「メッセージングとコネクティビティ のプラットフォーム」です。

最初に紹介する特長は、Synchronus (同期)な利用場面での Service Bus。これは、”コネクティビティ”(接続性)のための技術といえます。

 

2つのアプリケーションが、Service Bus によって接続され、連携を取ることができるのですが、この際にそれぞれのアプリケーションでは、外向きの通信(outbound) しか許可されていない環境にあったとしても、Service Bus によって、データを交換することができるようになります。

仕組みとしては、一方のアプリケーションがリスナーとなり、他方からの要求を待ち、要求があった際に回答を行う(同期して回答する。そのため、要求を発した側は、リスナーからの返信を待つ、という動きになる)事になります。

image

 

 

次に紹介するのが Asynchronous (非同期) な利用場面での Service Bus の利用法で、具体的には「メッセージング」の技術になります。

このメッセージングに関しては、「Queue」 と、「Topic & Subscription」 の2つの機能が提供されています。

 

メッセージングも、コネクティビティの一つではありますが、アプリケーション接続において存在している様々な要件、例えば、異なるネットワーク セグメント間をつなぎたい、あるいは異なるプラットフォーム間をつなぎたい、あるいは異なるネットワーク速度の環境でつなぎたい、等の要件がある際に、非常に有用なテクノロジとなります。

具体的には、間に「ブローカー」を介在させ、接続を行いたいアプリケーション同士は、「ブローカーにメッセージを送る」および「ブローカーからメッセージを受け取る」、という間接的な接続とすることになります。このため、アプリケーション間を「疎結合」とすることができ、クラウドベースのアプリケーションなどでは非常に有用な技術といえます。

 

 

では、最初に「Queue」の概要を説明しましょう。

Queue を利用すると、たとえば、様々なデバイスからのメッセージを Queue に対して送ることができるようになります。

この際、デバイスが知る必要があるのは、Queue のエンドポイントの情報と、アクセスするための認証情報です。認証に関しては ACS (Access Control Service) を利用しており、セキュリティを高めています。

 

また、Queue を使うことによって、一時的にリクエストが集中するなど、必要な計算力にムラがある際などにも、リクエストを処理するアプリケーションは自身のペースで Queue からリクエストを取りだし、処理を進めることが可能です。

 

image

左側のデバイス群から一時的にリクエストが集中しても、右側の処理を行うアプリケーションは

自身のペースで Queue からメッセージを受け取り、処理を進めることができる。

 

 

また、Service Bus は REST なサービスとして、HTTP でメッセージを処理することができるため、.net 以外の言語環境からも、利用することが可能です。

 

ここで、Nathan からは、同じ「Queue」の機能を持つものとして、Windows Azure Storage Queue と、Windows Azure Service Bus Queue の違いについての質問が。

これに対し Abhishek からは、いくつかの差があるが、一つ目には REST だけでなく .net ベースの TCP 接続が可能であること、トランザクションをサポートしていること、そして最後に long polling によって、メッセージ処理が終わったのちに呼び出し側がコールバックを受けることができる、といった特徴が挙げられました。

(詳しくは「Windows Azure Queues and Windows Azure Service Bus Queues - Compared and Contrasted」も参照ください。上記に上げた3つの特長は、それぞれ「Runtime protocol」「Transaction Support」「Receive Behaivior」にて記述されています)

 

 

また、Nick からはメッセージサイズはどのくらい?との質問が。

これに関しては、メッセージごとのサイズとしては Windows Azure Service Bus では 256KB、Windows Azure Storage Queue では 64KB、との回答。なお Queue 自体のサイズとしては、Service Bus では 5GB、Storage Queue では 100TB が上限となります(クラウドカバー中、Abhishek は、Storage Queue が 1TB と回答していますが、こちらのページにおいて 100TB と記述されています)。

 

 

さて、もう一つ紹介したいのが 、「Topic & Subscription」の機能。

「Queue」の基本的な動作は、「一つのメッセージを送って、一つのアプリケーションが受け取る」ですが、「Topic & Subscription」では、一つのメッセージをブロードキャスト、あるいはマルチキャストする、といった特徴があります。

 

具体的には、Topic は入り口に当たる存在で、その背後に Subscription として複数の Queue を持つようなイメージになります。

 

クラウドカバーの例では、Topic は、PCやデバイスなどから発注のデータを受け取り、背後にある Subscription にデータを渡していきます。

 

image

 

今回の例では、Subscription として、Audit(監査) のための Subscription、Inventory(在庫)のための Subscription、そして Sales(売上データ計上)のための Subscription が存在し、それぞれが異なるタイミングで(リアルタイム性を要求するもの、一日一度のバッチ的な処理でよいもの、等)メッセージを処理していきます。

 

 

Windows Azure Toolkit for Socail Games の作者でもある Nathan は、現在 Storage Queue を使用している部分を Tpoic & Subscription で書き換えても面白いだろうーなー、と反応。さらに Abhishek は、ゲームのようなシナリオの場合は、個々のデバイスに個別の Subscription を用意しておき、通信に使うのも面白いかもね、と。

 

また、非同期でデータをやり取りできる “メッセージング” は、オンプレミスに存在する様々なシステムやデバイス、あるいはクラウドのシステムなど、異なる環境で動作するアプリケーションを連携するためにほんとに有用なんだよ、と強調。

 

 

ということで、ここからはデモの時間♪

今回はタイトルにもある Windows 8 メトロアプリケーションでの活用という事で、Windows Azure Toolkit for Windows 8 を使いながらの Service Bus 解説。

 

まず最初に必要になるのは、管理ポータルにおける名前空間(Namespace)の作成です。

image

 

この際、Service Bus 以外の付加サービスである Access Control および Cache の申し込みも同時に行うことが可能です(今回のデモでは、Service Bus のみ作成します。なお、Cache は作成することで課金が行われますのでご注意ください)。

 

この際に、Service Bus を利用するための認証用の情報も生成されます。この情報は、Service Bus とともに作成される Access Control Service(ACS) に渡され、そこで認証を受けたユーザーだけが Service Bus を利用できるようになります。また、ACS を利用することで、様々なセキュリティ設定を付加することができます(この、”Service Bus を利用する際に使われる ACS” に関しては自動的に作成されます。上記画面ショットにある ACS 作成の申し込みは不要です)。

 

 

さて次は、用意した Service Bus のアドレスと認証情報(発行者情報(“owner”)と、デフォルトのキー)を、Toolkit for Windows 8 に含まれるメトロアプリケーションのサンプルに埋め込みます。

image

 

このアプリをデバッグ実行すると、メトロアプリケーションが立ち上がってきます。

image

 

 

最初は左上の “Simple Queue” を選択します。

すると、Queue を使用する際の代表的なシナリオに基づき、操作を体験できます。

最初に、① Queue を作成し、②その Queue に対してメッセージを送ります。今回は「Hello, World!」というメッセージを送った後に、「Hello, World! 2」「Hello, World! 3」というメッセージを送ります。

 

image

 

次に、③メッセージを受け取ります。最初に Queue に入れた「Hello, Workd!」のメッセージが取り出されます。

image

 

続いてメッセージを取り出すと、「Hello, World! 2」「Hello, World! 3」が表示されます(Service Bus の Queue においては、メッセージの順序性が保証されます。詳しくはこのページの Ordering Guarantee を参照してください)

 

最後に、④ Queue を消して、このシナリオは終了です。

なお、メトロアプリケーションでは、I/O操作や外部システムとの連携などでは、非同期呼び出しが基本になります。Service Bus の操作に関しても、非同期呼び出し用のメソッド(例えば、Queue.CreateAsync() や、Queue.SendAsync() といったメソッド)が用意されていますので、そちらを使用することになります。)

 

 

続いで、”Simple Topics” を実行します。

「Topic & Subscription」を使用する際でも、基本的な概念は Queue と同じです。

 

つまり、メッセージの送り手は、「Queue にメッセージを送る」のと同じように「Topicにメッセージを送る」操作を行います。また、メッセージの受け取り手は、「Queue からメッセージを受け取る」のと同じように「Subscription からメッセージを受け取る」操作を行います。

 

もし、Subscription が一つであれば、基本的な動作は先ほどの Queue と同じになります。

また、Subscription が複数あれば、メッセージの受け取り手は、それぞれの Subscription 毎にメッセージを受け取ることになります。

 

下の画面ショットは、”bar” という名前の Subscription と “foo” という名前の Subscription を作成し、Topic にメッセージを送った後、Topic からそれぞれの Subscription にメッセージが送られ、最後にクライアントから両方の Subscription にアクセスし、それぞれメッセージを取得した様子です。

image

 

なお、Nick からコメントが入っているように、通常は一つのクライアントが複数の Subscription を利用するのではなく、興味のあるトピックに基づいて Subscription や、アクセスするクライアントが別に存在するアーキテクチャになります。

 

 

次のデモでは、「Hello, World!」のメッセージを Topic に送った後、新しい Subscription として “later” を作成し、「Hello, World! later」というメッセージを Topic に送ったデモです。

この状態で、Subscription からメッセージを受け取りに行くと、bar と foo からは最初に入った 「Hello, World!」が、また、あとから作った later からは「Hello, World! later」が受信できます。

image

 

 

そして最後は、「エンジニアの UI はこうでなくっちゃ!」と Nathan 絶賛の Peek Lock のデモ

image

 

Peek Lock では、メッセージの処理が終わるまでは Queue からメッセージを削除せず、また他のアプリケーションがそのメッセージを処理してしまわないようにロックをかけることができます。

 

例えば、Queue に対して、黄色い丸、赤い三角、青い四角、とメッセージを送ったとします。

 

この状態で、Peek Lock を行うと、「黄色い丸」が取得できます。

この後、何らかの処理が無事に成功したとして、「Complete」ボタンを押すと、黄色い丸のメッセージは Queue から削除されます。

image

 

再び、Peek Lock のボタンを押し、メッセージを取り出すと「赤い三角」が取得できます。

この後、何らかの処理が失敗したとして、「Adandon」ボタンを押します。

image

 

 

すると、Queue からは「赤い三角」のメッセージが削除されず、再び Peek Lock のボタンを押すと、赤い三角のメッセージが取り出されます。

image

 

また、Peek Lock では、ロックの時間指定ができるため、一定時間を超えて処理が終わらなかった場合などは、ロックが解放され、再び Queue から取得可能なメッセージとして、扱われるようになります。

 

ということで、メトロアプリにおいても Service Bus を是非ご活用ください!

image

 

 

 

さて、最後は恒例の Tip of the Week!

image

 

今回の Tip of the Week は「Howto put .Net Framework 4.5 Beta & ASP.NET MVC 4 Beta on Windows Azure」より、Windows Azure で、.NET Framework 4.5 と MVC 4 (ベータ)を動かす方法。

 

MVC 4 だけであれば簡単に動かせますが(※)、.NET Framework 4.5 も動かしたいぜ!というギークな方向けの情報です。

 

ということで、今回のクラウドカバーは、Windows Azure Service Bus を活用した Windows 8 メトロアプリケーションの開発についての紹介でした。

 

それでは、Enjoy Azure!

 

 

 

※ MVC 4 は通常の Web Role と同様に Azure へデプロイ可能です(MVC 4 用の Web Role テンプレートもあります)。ただし、ベータにおいては、View の Home の index.cshtml、View の Shared の _Layout.cshtml が UTF-8 でエンコードされていないため、そのまま Windows Azure にデプロイすると日本語が文字化けしてしまいます(Razor 記法の場合)。そのため、それらのファイルを一旦 メモ帳等で開き、文字コードを UTF-8 に変更後、利用してください。この問題は MVC 4 の正式リリース時には解消されると思います。

image

 

Leave a Comment
  • Please add 3 and 2 and type the answer here:
  • Post