Silverlight から Azure Table Storage Service へダイレクトにアクセスするには

Silverlight から、Windows Azure の Table ストレージ サービスを利用する方法を検討してみました。考えられる方法は、以下が考えられます。 Web サービスを経由してアクセスする RIA サービス(内部で Table ストレージを使用する) — Silverlight クライアント Web サービス側では、Azure SDK のストレージ クライアント ライブラリを使用できる ダイレクトにアクセスする Table ストレージ サービス — Silverlight クライアント Table ストレージは OData 形式なので、 WCF Data サービス クライアントが使えるかも RIA サービスを使った Table ストレージの利用方法は、探せばサンプルが見つかることでしょう。ここでは、残りの WCF Data サービス クライアントを使う方法を検討します。最初に検討しないといけないのが、リクエスト ヘッダーに対して情報を追加することが可能かという点です。これに関しては、System.Data.Services.Client.DataServiceContext クラスが SendingRequest イベントを公開しているので、このイベントを使用すればできそうです。 SendingRequest イベントは、 引数として sender (DataServiceContextクラス) と…

0

Azure Storage Analytics サービスについて

Winodws Azure のストレージ サービスでは、Storage Analytics サービスが2011年8月より提供されています。リリースされた直後では、REST APIを使って有効や無効を切り替えていましたが、Windows Azure SDK  for .NET(1.6)ではマネージ API が提供されています。  Storage Analytics サービスは、ログ($Logs)がBlob ストレージに記録し、メトリック($MetricsTransactionsBlob、$MetricsTransactionsTable、$MetricsTransactionsQueue、$MetricsBlobCapacity)が Table ストレージに記録されます。 Storage Analytics サービスをマネージ API で有効にするには、以下のようなコードを使用します。Storage Analytics サービスの有効や無効の設定には、少し時間がかかることに注意してください。  var serviceProperty = new ServiceProperties() { Logging = new LoggingProperties() { Version = “1.0”, LoggingOperations = LoggingOperations.All, RetentionDays = 7 }, Metrics = new MetricsProperties() { Version = “1.0”,…

1

Ruby on Rails on Windows Azure(4)

一応、このシリーズは今回で終了する予定です(本当?)。これまでのシリーズを振り返ると以下のように記述してきました。 能楽堂がactiverecord-sqlserver-adapterを含めた理由とAzure対応の目標 Azure対応の目標を立てた理由とホワイトペーパー公開直前のバグ騒ぎ 能楽堂コンパニオンの解説 何とか、能楽堂 1.1.9の動作確認ができたのが先週末でした。能楽堂 1.1.9の動作確認では、私のrails 3.1.1に対する知識が無かったこともあり、artonさんにはとてもお世話になりました。能楽堂 1.1.9では、能楽堂 1.1.7に比べて新しいパッケージが含まれています。具体的には、以下の通りです。 Ruby 1.9.3-p0(1.9.3の正式版です) Rails 3.1.1(能楽堂 1.1.7は、Rails 3.1.0) activerecord-sqlserver-adapter-3.1.3 (SQL AzureでのDBCCバグは修正されています) waz-storage-1.1.1(Azureのストレージサービス用のパッケージです) これに伴って、rest-client-1.6.7とruby-hmac-0.4.0も追加されています。 私の無知が何かということを説明すると、Assetsに対する動作が Rails 3.1.0 と Rails 3.1.1で変更されていたことに気が付かなったことです。正確かどうかは不明ですが、私が遭遇した現象は以下のようなものです。 Rails 3.1.0:Assetsのリクエストを処理していたのがRailsらしい(production.logに記録される)。 Rails 3.1.1:Assetsのリクエストを処理するのはRailsからWebサーバーになった(production.logにルーティングエラーが記録される)。 この理由から、Rails 3.1.1 ではAssetsをEnnouに処理させなければなりません。この設定は、config/environments/production.rbで config.serve_static_assets を true にします。この設定に辿り着くまでに、時間がかかってしまいました。 この設定が理解できたので、NougakuDoCompanionでは以下のような設定方法を追加しています。 config/environments/production.rb は、config.server_static_assets を必ず true に設定。 config/environment.rb は、Rails 3.1.xの場合に ENV[‘RAILS_RELATIVE_URL_ROOT’] を設定。 config/application.rb は、Rails 3.0.xの場合に config.action_controller.asset_path を設定。 この変更が完了してから、能楽堂…

0

Async CTP v3 がリリースされています

Visual Studio Asynchronous Programming で、Async CTP が v3 にアップデートされています。このバージョンの必要条件を読むと、 Visual Studio 2010 SP1 4月のAsync CTP SP1 Refreshからのアップグレードが可能 となっていました。実際にインストールしてみると、Async CTP SP1 Refreshに対して、以下のような更新が行われているようです。 Silverlight 5 対応 Windows Phone SDK 7.1 対応(ライブラリに変更はなかったです) Roslyn CTPとの互換性対応 サンプルなどは、変更されていませんでした。Async CTP SP1 Refreshは、インストール条件にVisual Studio 2010 SP1をインストールしたクリーンな環境が必要だったのですが、v3は現時点の環境で問題なく導入できました。この機会にインストールされてみては、如何でしょうか。

0

Ruby on Rails on Windows Azure (3)

(1)と(2)のエントリーで、どのいう経緯でホワイトペーパーとNougakuDo Companionが出来上がってきたかを説明しました(まあ、前置きが長い気がしなくもありませんが…)。今回は、NougakuDo Companionを説明します。最初に、NougakuDo Companionの概要図を示します。 NougakuDo Companionは、図に示すように大きな機能は4つに分類することができます。それぞれの機能は、以下のような役割を持っています。 AdminWeb:管理サイト(ポート8080)で、能楽堂で作成したRailsアプリケーションの運用管理や、NougakuDo Comapnionのログ情報などを参照できる、ASP.NET MVC 3による Web アプリケーションです。マルチインスタンスで起動したRailsアプリケーションへの操作(再起動など)は、該当するインスタンスに対してメッセージをQueueストレージへ送信します。 Web Role:Windows Azureによって起動されるロールで、NougakuDoControllerを動作させるための準備作業とNougakuDoControllerを起動します。また、マルチインスタンスで起動した場合のRailsアプリケーションに対する操作(再起動など)メッセージをQueueストレージから取得します。また、マルチインスタンスの管理用にインスタンス情報をTableストレージに格納します。 NougakuDoController:NougakuDoCompanionの中核機能を実装した実行ファイル(exe)で、能楽堂で作成したRailsアプリケーションに対する様々な操作を行います。 1)インストール:Blobストレージから、能楽堂ランタイム(実行ファイル)やRailsアプリケーションのzipファイルを取得して、ローカルリソースに展開します。 2)設定:能楽堂のローンチャで行う設定情報をAdminWebで設定した情報を使って設定します。 3)運用管理:NougakudoLauncherを使って起動したRailsアプリケーションに対する停止や起動、再起動などの操作を行います。 NougakudoLauncher:能楽堂を使ったRailsアプリケーションの起動を行う実行ファイル(exe)で、停止操作ではruby.exeにCTRL+Cを送る機能を持っています。 最初のプレビューは、NougakuDoControllerとNougakudoLauncherです。この2つが動き出せば、能楽堂を使ったRailsアプリケーションを動かせますので、このプレビューを使ってローカル環境でのテストとAzureを使ったテストを行っていたのは、いうまでもありません。唯、このプレビューでの失敗もありました。それは、当初からAzureを前提としていたために SDK のStrage Emulatorを想定していなかったことです。このプレビューに、応急処置的にASP.NETのUIを付けたものを artonさんにお渡しして、SDK 環境で試せないの?と質問された時に、慌てて対応したのが、7月後半のシアトル出張の真っ最中だったのは内緒です。NougakuDoControllerやNougakudoLauncherを単独で実行できるように実装したのは、明確な理由があります。その理由は、以下のような考えを前提としたからです。 シンプルであるべき(Simple is best) やり易い環境であるべき ご存じのようにAzureはクラウド環境ですから、インテリトレースが使えると言ってもデバッグを考えると難しいのも事実でしょう。だからこそ、シンプルで実装し易い環境へ持ってくるべきだと考えたのです。この考えから、NougakuDoControllerは、Azure SDKで提供されるAPIからストレージサービスAPIしか使用していません。では、Azure特有のインスタンス情報などをどうしたかといえば、azure.xmlという設定ファイルから情報を取得するようにしています。つまり、ロールインスタンスのコードでazure.xmlを作成することで、Azureのサービスランタイム APIに依存しないようにしたことになります。この特徴が、Azure以外の環境に持っていく場合に効果を発揮できるでしょうし、NougakuDoController単体でのデバッグを容易にするという効果を発揮しました。利点ばかりではなく、もちろん欠点もあります。それは、管理サイトやWeb ロールとの連携をどのように行うかということです。基本的に、別プロセスとして動作していますから、プロセス間連携をどのように実装するかという課題です。 この課題に対して採用した方法が、ファイルを介して連携するという方法です。共有メモリなどを使うよりも、シンプルで、実装コストもかかりません。ファイルを使った連携で注意しないといけないのが、ファイルの排他ロックの問題です。この理由から、FileSystemWatcherクラスを使ったCreatedイベントを多用しています。一般的に、FileSystemWatcherクラスのイベントは、次のように発生します。 Created:空の新規ファイルを作成(Windows エクスプローラーで新しいテキストファイルを作成) Changed:内容を出力した場合(メモ帳で内容を書き換え、上書き保存した場合など) Renamed:ファイル名を変更(Windows エクスプローラーで新しいテキストファイルを作成して、直後にファイル名を変更など) という順序で、イベントが発生します。この理由から、ファイル名に意味を持たせて空のファイルを作成することでプロセス間連携に利用しています。もちろん、連携ミスなどを考慮して空のファイルを作成する前に、既存のファイルを削除してから作成するようにして目的のファイル システム イベントを発生させるようにしています。ローカル環境ではスムーズに動作しましたが、実際にAzure上で動作させた場合に問題も発生しました。それは、ファイルロックが発生して例外が発生したことです。この原因は、可能性として仮想マシンであるがためにファイル システム イベントの発生タイミングに遅れがあることではないかと考えて、リトライロジックを組み込んで回避しています。 NougakuDoControllerがRailsアプリケーションを管理する上で重要なものは、アプリケーションの設定ファイル(configuration.xml)です。この設定ファイルは、管理サイトの「NougakuDo Runtime & Apps」でも設定することができます。NougakuDoControllerでは、この設定ファイルを使って以下のようなことを行っています。 バージョンチェック(シンプルに、バージョンが一致するかしないかの判断です) 標準で5分間隔でBlobストレージに対してチェックを行います。 バージョンが一致しなければ、以下の作業を実施。 zip ファイルをBlobストレージからダウンロード Rails…

0

Ruby on Rails on Windows Azure (2)

前回のエントリーでは、能楽堂の概要と特徴を説明して、RailsアプリケーションをWindows Azureに配置する場合に考えた目標を説明しました。なぜ、このような目標を考えたのかを最初に説明します。Ruby on RailsをWindows Azureで動作させる情報は、検索するとたくさん見つけつることができます。たとえば、Ruby on Rails in Windows Azure などでは、RubyのインストールからRails環境の構築と Windows Azureへ配置するための Azure用のアプリケーション パッケージの作成方法までを解説しています。この方法でも、技術的にはRailsがWindows Azureで動作するという観点からは良くできていると私も考えています。でも、Railsアプリケーションを開発されている方の立場になって考えた場合は、どうなんだろうという疑問があるのも事実です。私が考えるRailsアプリケーションの開発者は、アプリケーションの開発から運用を以下の手順で行うと思います。 開発環境の準備(RubyやRuby on Rails、データベース環境)。 Railsアプリケーションの開発とテスト 本番環境への配置 自前でサーバーを用意するか、ホスティング環境を用意して、環境を整えてからアプリケーションを配置 このように考えた場合に、Windows Azure アプリケーション開発環境を理解するというのはRailsアプリケーション開発以外に学ばないといけない知識になってくるわけです。つまり、余計な負担が生じてしまうのです。もちろん、採用したプラットフォームを最大限に生かすのであれば、それらの知識は必要不可欠です。でも、Railsアプリケーションのホスティング先としてのWindows Azureを考えた場合は、必要のない知識だと言えるでしょう。このように考えた結果が、RailsアプリケーションをWindows Azureへ配置するためのツールとして NougakuDo Companionの設計目標にまりました。つまり、NougakuDo Comapnionを使う上で、利用者が学ぶべき知識は以下の事柄になります。 Windows Azure コンピュートサービスの製品知識(仮想マシンのサイズなど)とVisual Studio 2010の操作 Visual Studio のプロジェクト プロパティで仮想マシンサイズを変更して、設定情報を変更できる。 Visual Studio でAzure用のアプリケーションパッケージの作成ができる。 Windows Azure 管理ポータルの使用方法 ストレージ サービスの使用方法(たとえば、Azure Storage Explorerなどのツールの操作) つまり、Windows Azure のWeb ロールなどの知識やC#などのプログラミング言語の知識がなくても、Visual Studioの操作方法とWindows Azure管理ポータルを使った操作ができれば、RailsアプリケーションをWindows…

0

Ruby on Rails on Windows Azure (1)

このところ、色々なことがありまして、Blogも更新していませんでした。タイトルにあるようにRubyをWindows Azureのコンピュート サービスで動かすにはどうしたら良いか、ということについて、何回かにわけて書いて行こうと思います。そもそものきっかけは、7月にあったRuby会議2011の約10日前に秋葉原の某所で開催されたミーティングに参加したことでした。このミーティングの主題は、Ruby on RailsアプリケーションをAzureで動かしてみたら遅かったので、Windows上のRubyは遅いのではないかという話から、実際にベンチマークなどを計測して検証しようというものでした。このミーティングの中で、artonさんが作成されている能楽堂(NougakuDo)というx64 Windows用のRuby on Railsの開発環境を使ってベンチマークを計測しているという話がでました。ミーティング終了後に食事をしながら、能楽堂をAzureに配置して動作させるというホワイトペーパーを作成できませんかという話が出ました。この話がきっかけになって、実際にAzureへ配置した場合にデータベースをどうしたら良いかという検討を私がしました。ここで考えられるのが、次の2種類になります。 SQLite:能楽堂にバンドルされている。 SQL Azure:何が使えるかは、調べなきゃいけません。 SQLiteを採用した場合の問題点を考えると、Windows Azureがステートレス サーバーであるためデータベース ファイルなどの維持をどうするかという点に行きつきます。また、複数インスタンス(サーバー)を起動した場合にデータの一元管理をどうするかという問題も考えなければなりません。そこで、SQL Server用に使用できるActiveRecord用のAdapterがないかと探してみた結果、activerecord-sqlserver-adapterが見つかりました。このadapterの説明を読むと、SQL Azureにも対応していて今回の用途に使えそうなので、必要なモジュールを調べると以下のものが必要であることがわかりました。 TinyTDS:RubyからDB-Libraryを使用するためのモジュール FreeTDS:UNIXやLinuxからSQL ServerやSybase databaseへ接続するためのプロトコルであるTDSの実装モジュール この2つのモジュールのインストール方法を調べると、x86向けばかりで、このままではx64環境である能楽堂で使用することができません。そこで、artonさんにお願いして能楽堂へバンドルして頂いたのが、NougakuDo 1.0.2になります。この作業と並行して、Azureのコンピューティング サービスへ手動で能楽堂を配置して、Ruby on Railsアプリケーションを作成して、問題なく動作するのを確認していました。確認作業は、以下のような方法をとりました。 実装のないWorkerロールのパッケージを配置。 リモートデスクトップで接続して、次の作業を実施。 能楽堂のインストール。 Ruby on Rails アプリケーションの作成と動作確認。 Azure上で能楽堂の動作に問題がないことが確認できれば、次は能楽堂で作成したRailsアプリケーションをAzure上へ配置する方法の検討を行いました。検討したことは次のような目標です。 Azure のマルチインスタンスへ対応する Railsアプリケーションのアップデートができる 能楽堂のアップデートができる Railsアプリケーションの再起動を含めた運用管理ができる。 あまり参考にしていないのですが、Smarx roleなどもありましたが、私が考える上記のような目標を達成できないので、目標を実現するための実装方法の検討と最小限度のコンセプトプログラムを作成しました。この作成を何とかRuby会議2011までに作成したのが、NougakuDo Companion の最初のバージョンになります。NougakuDo Companion の説明は、次以降のエントリーを考えていますが、能楽堂の特徴を簡単に説明します。 x64 対応の Ruby 1.9系で、MSVCRT(Visual C++ 2010)対応。 Ennou という http.sysを使用する Web…

0

Windows Azure におけるシンボリックリンク作成について

前回のエントリでは、Windows Azureのローカルリソースを使った場合にパスの長さが問題になるかも知れませんと記述しました。何故かという理由を以下に示します。 Windows Azure上のローカルリソースは、リソースドライブに中で「guid.リソース名」という名前が付与されます。このために、指定したリソース名の正式なフォルダー名はかなり長くなります。 Development Fabricでは、「%UserProfile%\AppData\Local\dftmp\s0\deployment id\res\instance id\diirectory\リソース名」になります。 Development Fabricを使ったテストでは、長いパスの問題が顕著に発生する傾向にあります。これを回避するには、コマンドプロンプト(cmd.exe)が用意しているコマンドである「mklink」を活用する必要があります。mklinkの良く使うオプションを以下に示します。 mklink  シンボリックリンク名  リンク元のファイル名 mklink  /d  シンボリックリンク名  リンク元のフォルダ名 mklinkコマンドで作成するシンボリックリンクですが、コマンドの入力時に存在しないファイル名かフォルダー名である必要があります。単純に言えば、新しいファイルシステムのアイテムを作成するので、同名のアイテムがあるとエラーになるということです。無事に作成できると、dirコマンドでは「2011/08/19  16:49    <SYMLINKD>     リンク先名 [リンク元名]」と表示されます。シンボリックリンクを削除するには、rmコマンドやdelコマンドやWindows エクスプローラーを使う必要があります。特にシンボリックリンクのフォルダーを削除するのに、.NET FrameworkのDirectoryクラスやDirectoryInfoクラスを使用してはいけません。その理由は、リンク元のフォルダーが削除されてしまうからです。この理由から、C#などではProcessクラスを使用する必要があります。以下にサンプルコードを示します。 static bool CreateSymbolicLink(string linkDestination, string linkSource) { var cmdexe = new ProcessStartInfo(“cmd.exe”); cmdexe.WorkingDirectory = System.Environment.CurrentDirectory; cmdexe.UseShellExecute = false; var proc = new Process(); cmdexe.Arguments = “/c mklink /d ” + linkDestination…

0

Windows Azure コンピュートサービスについて

最近、Windows Azureを使う機会が多いので、気が付いたことを色々と記載していきます。基本的なこととして、1)コンピュートサービス、2)ストレージサービス、3)SQL Azure、4)ACSやサービスバスなどのAppFabricというサービスに分かれているのはご存知だと思います。その中でコンピュートサービスを中心にすると、仮想マシンの役割によって1)Webロール、2)Workerロール、3)VMロール(現時点ではCTP)の3種類になります。が、それぞれの仮想マシンの特徴を一言で表現すれば、ステートレス サーバーということができます。つまり、仮想マシンの再起動や再イメージ化によってローカルストレージのデータが失われるということです。メリットは、問題があったインスタンスを破棄して、新しいインスタンスを容易に作成できるということになります。実際の仮想マシンのローカルリソースがどうなっているかを確認したのが、以下の図になります。 この図は、Webロールにリモートデスクトップで接続してキャプチャしたものです。この図から解ることは、以下のようなドライブ構成になっていることです。 Cドライブ:ローカルリソース用(ログなど)。 Dドライブ:OS用。 Eドライブ:ロールのアプリケーション用で、%RoleRoot%が示すドライブです。 %RoleRoot%環境変数は、ドライブレターを保持する変数ですから、この例では「E:」となります。実際のロールのアプリケーションは、approotフォルダーに格納されますが、このフォルダーの構造が、WebロールとWorkerロールで少しだけ異なっています。具体的には以下のようになります。 Webロール:Binサブフォルダーにロール用のアセンブリが格納されて、approot直下にWebアプリのファイルやコンテンツが格納されます。 Workerロール:approot直下にロール用のアセンブリが格納されます。 この違いは、StartTaskを指定する場合に重要になります。StartTaskのデフォルトパスは、WebロールではBinサブフォルダを示し、Workerロールではapproot直下を示すからです。この理由から、Visual Stduioのプロジェクトでは、StartTaskに指定するモジュールを出力先ディレクトリーへコピーと設定することをお勧めします。 次に仮想マシンが動作している権限について、以下に示します。 ASP.NETアプリ:Network Serviceアカウント。 ロールインスタンス:標準は権限の少ない特殊なアカウントで、executionContextでElevatedを指定した場合はSystemアカウントとなります。 仮想マシンのサイズによって利用できるローカルストレージは、Cドライブに確保されますが、指定した容量による制限が課せられます。このローカルストレージに指定したフォルダーに対するACLは、ロール用の特殊なアカウントとNetwork Serviceアカウントがフル アクセスに近い権限が設定されます。しかし、サブフォルダなどに対する権限の継承が設定されていませんので、普通のファイルシステムとして使用する場合は、適切なACLの設定を自分で行う必要があります。 DirectoryInfo dirInfo = new DirectoryInfo(folder); DirectorySecurity dirSec = dirInfo.GetAccessControl(); dirSec.AddAccessRule( new FileSystemAccessRule(“NETWORK SERVICE”, FileSystemRights.FullControl, InheritanceFlags.ObjectInherit | InheritanceFlags.ContainerInherit, PropagationFlags.None, AccessControlType.Allow)); dirInfo.SetAccessControl(dirSec); と行うか、icacls.exeを使って、(OI)(CI)(F)の権限を設定します。 権限設定を行う場合ですが、データが存在するフォルダーに対して行うと時間がかかるので注意が必要だということと、アクセスする必要があるアカウントに対して設定する必要があります。前述の例では、Network Serviceで設定していますが、Elavatedの場合であればSystemに対しても設定する必要があります。 それとWebロールを使う上で仕様になっているのが、テンポラリーのサイズ制限が100MBになっていることです。この制限を変更するには、ローカルリソースを使ってロールのスタートイベントやStartTaskなどで適切に変更する必要があります。後は、ローカルリソースを使った場合に問題になるのは、パスの長さかも知れません。パスの長さが問題になる場合は、mklinkコマンドを使ってシンボリックリンクを短いパスとして設定する方法が考えられます。

0

DynamicMethod on Windows Phone 7

6月に「プログラミング .NET Framework」書籍の座談会に参加しまして、そこで何度か動的にILを Phone 7上で作成できませんか?という質問を受けました。Windows Phone 7のCompact Frameworkは、それまであまり調べていませんでしたので、DynamicMethodについて色々と調べてみました。 Windows Phone 7について 結論から説明すると内部的にはSystem.Reflection.Emit.DynamicMethodは存在しています。但し、開発ツールではSystem.Reflection.Emit名前空間を使用できるようになっていません。従って、「asm.GetType(“System.Reflection.Emit.DynamicMethod”)」のようにリフレクションを使って、DynamicMethodの型を取得する必要があります。 コードネームMangoについて 提供されているベータの開発ツールでは、Windows Phone 7.1となりますが、Mangoでは普通にDynamicMethodが使用できるようになっています。このことから考えると、Mango世代では動的IL生成を普通にサポートしますので、将来的にはDynamic Language Runtimeなどもサポートされるかも知れません。

0