今週末および来週以下のイベントで登壇します。
4/21 プログラミング生放送勉強会 第15回＠大阪 [Windows 8, JavaScript, Azure, Kinect 他] #pronama
プロ生はWindows AzureとKinectです。すごく浅いところを喋ります。ネタ思案中。
こちらは4月24日～25日にあるMicrosoftのイベントです。2日目（25日）の SP-011 Windows 8 と Azure で更に広がる VOCALOID の世界 というブレイクアウトセッションで、ボーカロイドの父、劔持さんと一緒に登壇します。Day 2のキーノートが先にあるので、そちらも是非！
National Association of Broadcasters (NAB) 2012 にてWindows Azure Media Servicesがアナウンスされました。
そもそもWindows Azure Media Servicesってなんでしょう？
発表されたばかりのこのサービスを利用すると、スマートテレビやセットトップボックス、MacOS、iOS、AndroidなどMS以外のプラットフォーム、それからもちろんXBoxやWindows Phone、Windows PCを含むほぼすべてのデバイスへのメディア配信を簡素化できるようです。
もともとこれらの機能はPlayReadyでおなじみのMicrosoft Media Platformで培われた機能ですね。つまり簡単に言うとMicrosoft Media PlatformのサーバーサイドがWindows Azureのサービスとして追加されるということです。
素晴らしいですね～！
さてサービス化されて何ができるんでしょう？まだ細かい機能が公開されてないので公式サイトを適当に見てみます。
メディアワークフローが構築できます。ニーズに合わせて構成を組み合わせたり構成済みの設定を利用したり。アップロードやエンコーディング、フォーマット変換、コンテンツ保護（DRM）、配信が行えます。
複数のフォーマットに変換して3rd Party製のCDNに配信したり外部アプリとREST API経由で連携したりできるみたいです。
各デバイスに必要なメディアの作成や管理、複数デバイス間での配信機能などを提供。
Windows Azure Media ServicesはMicrosoft Media Platformのクラウドサービス版です。既存のソリューションやカスタムワークフローなどニーズに合わせて簡単にサービスを管理できます。
標準的なHTTPや、3rd Party製のエージェントを使用したセキュアで高速なUDP通信を使用してWindows Azure Media Servicesのストレージにメディアをアップロードできます。
標準的なコデックとフォーマット、Smooth StreamingやHTTP Live Streaming、MPEG-DASHやFlashなどビルトインで提供されるWindows Azure Media Encoderまたは3rd Party製のエンコーダを利用できます。
ストリームの入力と出力を制御してライブラリ全体や個々のストリームを変換できます。
Liveやオンデマンドの音声やビデオを標準的なMPEG Common EncryptionやMicrosoft Play Readyを使って暗号化することができます。業界でも最も受け入れられているDRMをコンテンツに追加できます。またウォーターマークや電子透かしを追加することもできます。
Windows Azure CDNや3rd Party製のCDNを経由してコンテンツをシームレスに提供することができます。
ライブチャンネルのストリーミングやMedia Servicesを使ったエンコード、外部フィードからの配信などを簡単に作成し、配信できます。サーバー側DVRやリプレイ機能なども利用できます。
今時点ではプレビュー版なのでコストはかかりません。（但しストレージやネットワーク転送料、CDNなどの既存のWindows Azure機能に関するコストは発生します）
サインアップするにはメールしましょう！（※想定してるシナリオも書いてねとのこと）
この辺参照 → Windows Azure Media Services Preview for Developers
この辺の詳細はWindows Developer DaysのSC-008 Windows Azure Platformでの動画配信アプリケーション開発で聞けるみたいですよ！
小ネタです。Azure Storage Explorerだと出来なさそうだったのでPowerShellでサクッとAzure Blob Storageのコンテナのパーミッションを変更します。
Windows Azure PowerShell Cmdletsを起動して、Get-Containerコマンドでコンテナを取得します。
$container = Get-Container -StorageAccountName ***YourAzureStorageAccount*** -StorageAccountKey ***YourStorageKey***
取得できたらInstance（コンテナ）のGetPermission()メソッドを呼んで現在の権限を取得します。
$permission = $container[3].Instance.GetPermissions()
PublicAccessプロパティが現在の値です。（OffがPrivateコンテナ、ContanierがPublic Contanier、BlobがPublic Blobになります）
今現在はOffなのでPrivate（非公開）です。
このPublicAccessプロパティに”Container”等をセットし、Instanceプロパティ（コンテナ）のSetPermissions()メソッドを呼び出して設定を反映させます。
$permission.PublicAccess = "Container" $container[3].Instance.SetPermissions($permission)
無事コンテナのアクセスレベルが変わりました。
Windows Azureのセキュリティが心配で心配で夜も眠れない人に朗報。 クライアントPC等で企業向けに提供されているMicrosoft Endpoint Protection（以下MEP）がWindows Azureでも利用できるようになりました。（※2012年3月19日現在ではCTP）
「緊急」のセキュリティ更新プログラムが公開されてました。
みなさんご推察の通り、RDPを有効にしたWindows Azureのインスタンスも例外ではないと思います。
というわけで、このセキュリティ更新プログラムが適用されたGuestOS（1.17/2.9）がリリースされています。
※手動での適用はイメージが伝播するまでしばらく待ちましょう。（自動更新の場合は適用が開始される場合があるかと）
※ホスト側のリブートもありそうですね。
2月29日に発生したWindows Azureサービス中断ですが、Microsoftから公式として以下のRCA（根本原因分析）が出ていました。
詳細はリンク元を見て頂くとして、やはり発端はうるう日（2月29日）に証明書を発行できなかったのが原因のようですね。有効期限1年の証明書発行に問題があると。（うるう日なので）
これだけならせいぜい新規のインスタンス起動が出来ない程度じゃ？と思ったんですがFabricController側への障害通知が繰り返し行き、本来ソフトウェアの問題のはずがハードウェアの問題と捉えられてどんどん影響範囲が広がって行ったみたいですね。
時系列でも解説されていますが、なるほどという感じです。共用型で自動化されたPaaSならではな印象もうけますが、、、
バグそのものは早期に修正されたみたいですが、更新の過程で2次停止も起こったあたりも興味深いです。それだけPaaSのインフラを管理するのは複雑で大変なのかというのがわかりますね。
ただ今後の対策なども明確になっているようですので、再発の防止とより良いサービスの提供を目指してもらえるといいかな～。
サポートについてはパンクっぽい様子だったようで、利用者から見ても改善の余地はあるかと思ってます。（スパイクに対応させるのは難しいと思いますけどね…さばき方の問題かな）
技術者目線だとなるほど、ですが利用者目線だともう少し違う説明をしないといけないんだろうなぁ。もうひと踏ん張りですね。
以下余談。
問題の発生当初は実はグロサミでWelcome Receptionまっただ中だったわけです。でそのパーティーのさなか某はうはう氏がノートPC広げてAzureの障害が～と日本の仕事の対応してたんですね。で症状を聞くにその場にいた抱き枕氏と「これって閏年（うるう日）だからじゃないのー？日本はもう29日だよね。こっち（PST）はまだ28日だし大事になってないし。つまり閏年なバグじゃね？」「まさかー。ねぇ」とか冗談で言ってたわけですがドンぴしゃとは…
で、その後自分が関わってるサービスもぐるぐる祭りが続いたりそれなりに大変だったわけで（おそらく2次停止のほうに巻き込まれた感じ）。まぁ大変といってもインフラの問題なので出来ることはReImageやら再デプロイ程度でぐるぐる祭りを眺めてる程度なんですが。
さて日本人的に気になるのは世間体ですかね。SLA99.95％に何を求めてるかわかりませんがやたら要求だけは厳しい日本の企業にはどう映るかな、という心配はあります。1秒でも止まったらアウトなミッションクリティカルなシステムだとそもそも99.95%で保証なしなんて論外でしょうし、そうじゃないなら、自社運用でも何でも好きなのコストかけてがんばって運用すればいいじゃないですかとか思いますが。。このあたり思考停止してベンダーになすりつけてるところ多い気がするので心配ですね。そんなことなければいいんですが。
サービスをうまく使うには利用者側も勉強しましょう。これは大変ですけどその見返りも当然あるわけで。そこをないがしろにしてたらうまく行かないと思いますよと昨今のSI業界にも通じるような思いがあったりなかったり。（とはいえどっちの言い分もある程度わかるのでなんともですけどね。）
どんどん本筋とそれてしまった感がありますが、今後の展開次第では本筋と違う話ばっかりになる可能性もあるのでそんなのは嫌だなというのだけわかって頂けると嬉しいです。
たぶん後半は言葉足らずで的外れな部分もあるでしょうけど、まいっか。
2012年3月13日追記
日本語公式サイトで翻訳された内容が公開されたので追記。公式発表は大事ですよね。ちゃんと根本原因分析ができて公開できるのは凄いことだと思いますよ…
というわけで唐突ですが価格改定があったようです。
Announcing Reduced Pricing on Windows Azure Storage and Compute
XSサイズはSサイズと比較すると1/6になりました。Sインスタンス1台分で6台分のXSが動かせます。多少スペック低くても台数欲しい時とか上手く活用すればかなりコスト削減になると思います。
SQL Azureの値引きも先月発表されましたし、現実的な使いやすいプランになるのはいいことですね。
参考：
というわけで2月28日～3月2日に米国で開催されたMicrosoft 2012 MVP Global Summitに参加してきました。
一応思い出なんぞをつらつらと書いておこうと思います。（内容はNDAなので書けません）
今回は初参加だったのですが、時間に追われるのが嫌いなのと人見知りで団体行動が苦手なのでツアーはやめてちょっと期間を延長して行ってきました。
Worker Role上の.NET Frameworkの動作CLRバージョンに関した質問がMSDNフォーラムにあがってたので見てみました。
とりあえず適当にですね、Worker Roleを作ります。
public override void Run()
{
while (true)
{
Thread.Sleep(10000);
string clrVersionRuntime = System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion();
System.Diagnostics.Trace.WriteLine("CLRVersion:\t" + clrVersionRuntime);
}
}
寂しいので適当にCLRバージョンを吐き出すようにしました。
さてこいつを既定のママ（.NET Framework 4設定）で動作させてみます。
エミュレータ上
Windows Azure上
v4.0.30319 ですね。
では.NET Framework 3.5にしてみましょう。
エミュレータ上
Windows Azure上
※DebugViewでなぜかキャプチャできなかったのでProcess Explorerで。（最初からこうすれば（ｒｙ
v2.0.50727 でした。
想定通りと言えば想定通りです。
2月16日/17日に目黒雅叙園で行われたDevelopers Summit 2012に参加しました。
いろいろ縁がありましてなんとスピーカーでした。
「17-E-5 震災とHackとクラウドと」というタイトルで0311直後～1週間ぐらいに行ったHackについて話しました。
セッションそのものは冨田さん、菅さん、おいらの3人でそれぞれ分担という感じで。
またセッションにあたり熱い思いなどは冨田さんがまとめてるのでそちらを見て頂いたほうがいいかと思います。
Developers Summit 2012! / あれとアレは混ぜるな危険
こんな状況を乗り越えていくために、Developers Summitという場を通じて、そろそろ技術的にどんなことをしたかという事を共有しないと、次につながらないのではないかという思いを個人的に持っています。今回のセッションでは完全に技術の話にフォーカスして、次の危機に対してディベロッパーが立ち向かっていくためのヒントを共有したいと考えが根底にはあります。
Googleの及川さんも言っていましたが、技術者は無力ではないこと、技術者なりに出来ることがあるということを証明できたのが東日本大震災での成果の一つだと考えています。（実際には証明の途上にありますが）
その当事者として活動していただいた方が、震災直後にどんなことをしていたのかを共有することで、多くの方に「次は自分もできる」という気持ちを共有できれば本セッションは成功だと考えています。
冨田さんの資料はこちら
菅さんの資料はこちら
というわけでして、おいらのほうもですねキャッシュサイトの構築といったHackをやりましたのでそのあたりを喋らさせて頂きました。
おいらの資料はこちら。
中身見て頂いたらわかるかと思いますが、心情的なところはいったん置いておいて、技術面のみにフォーカスしました。技術面にフォーカスといいながらそんなに深い話じゃないんですが…
だって単にRevProxy置いただけですからね。平時ならそもそもRevProxyで対応とか第三者でやらないし、やるにしてももっといいやり方とか仕組みとか構成ってものがあるかと思います。
でまぁセッションでも口下手ながら言いましたが（文面も下手ですが）、内容じゃなくてその時に必要だったから、そのタイミングだったから活きたHackになったんじゃないかな、ということ。
※実際にはキャッシュサイトは周知されて使われないと意味がないので実測としてどうだったのかはあまり把握できてませんが…
補足すると、（今回のHackのターゲットだと）この手のシステムって、直近で必要で1～2週間もたてばたぶん破棄されるシステムなんだろうなと言うのは分かってて、やっぱり労力をかけずに泥臭くてもいいから作り上げて世に出すのが必要だったんだなと思います。そういう意味ではRevProxyにするとかどうやって作るかとかは気を使いました。純粋なTechとはちょっと違う気もしますがまぁそういう視点も必要だったかなと思います。
で短期で破棄される＋すぐに必要というサーバーを作るのにクラウドコンピューティングってほんとあってよかったです。触ってたのがWindows AzureだったのでAzure使ってますが、これ2年前とかならそもそもこういう対応も出来なかったし、自分は何もできなかったと思うんですよ。
あと競争じゃないけど本当にささっと出す必要があったんですよね。というかそう思ってました。なんでって誰かが暫定の解決策を出せればほかの人が同じようなことする手間をかけずに、違うことにリソースさけるじゃないですか。同じことするなんてもったいない！でも実際同じような話あったと思いますたぶん。なんか当時はTwitterやメール追うのも大変だったので記憶があいまいだけど。ただ、少なくともJAZ内での2度手間3度手間はなくせたかな～。
で、いろんな要因や人との縁（JAZの人たちや冨田さん、翔泳社の岩切さん達）が重なり、デブサミのスピーカーという場所に出たわけですが、ほんとうに境目なんてないんです。ちょっとしたことをやって手をあげたらなんかマッチしたぐらいの感覚。本当にその程度の差なんじゃないかな。だから冨田さんも言ってたように、今からでも遅くないしみんなもできるよ。だってゼロから何かを創造できるDeveloperなんだぜおれたちｗ
あんなしょぼいRevProxyじゃなくてもっとCoolな仕組み作ったぜ！とかいう話が今後いっぱいでてくるといいな～。それでこそ、このセッションをした甲斐があるってもんです。
なんかフォローのようななってないようなPostですが…そんな感じです！
ブチザッキ 