Windows Azure サービス中断の話

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日追記

日本語公式サイトで翻訳された内容が公開されたので追記。公式発表は大事ですよね。ちゃんと根本原因分析ができて公開できるのは凄いことだと思いますよ…

Windows Azureの価格改定

というわけで唐突ですが価格改定があったようです。

Announcing Reduced Pricing on Windows Azure Storage and Compute

  • Windows Azure Storage値下げ
    Pay-As-You-Goの場合、12%オフ(0.14ドル⇒0.125ドル) … GBあたり約11円/月に
  • Windows Azure ComputingのXSインスタンス値下げ
    従来の50%に(0.04ドル⇒0.02ドル) … 1XSインスタンスあたり約1,312円/月に

image

XSサイズはSサイズと比較すると1/6になりました。Sインスタンス1台分で6台分のXSが動かせます。多少スペック低くても台数欲しい時とか上手く活用すればかなりコスト削減になると思います。

SQL Azureの値引きも先月発表されましたし、現実的な使いやすいプランになるのはいいことですね。

参考:

Microsoft 2012 MVP Global Summitに参加してきました

というわけで2月28日~3月2日に米国で開催されたMicrosoft 2012 MVP Global Summitに参加してきました。

一応思い出なんぞをつらつらと書いておこうと思います。(内容はNDAなので書けません)

今回は初参加だったのですが、時間に追われるのが嫌いなのと人見知りで団体行動が苦手なのでツアーはやめてちょっと期間を延長して行ってきました。

続きを読む

Worker RoleのCLRバージョン

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で。(最初からこうすれば(ry

v2.0.50727 でした。

想定通りと言えば想定通りです。

[デブサミ 17-E-5 震災とHackとクラウドと] でスピーカーしました

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なんだぜおれたちw

あんなしょぼいRevProxyじゃなくてもっとCoolな仕組み作ったぜ!とかいう話が今後いっぱいでてくるといいな~。それでこそ、このセッションをした甲斐があるってもんです。

なんかフォローのようななってないようなPostですが…そんな感じです!

Azure上の非.NET アプリケーションからRoleEnvrionmentを触る

たんたかさんが PHPでRoleEnvironmentを使う というへんたい素晴らしいPostをしてたのでもっと手軽にできないかなーと。

もともとWindows Azure SDK 1.5以上でサービス定義ファイルにxPathを使用してRoleEnvironmentの値を環境変数にセットできるのですが、これがちょっと曲者。

というのもサービス定義ファイルのEnvironment要素に指定した環境変数はプロセス環境変数で、つまりRoleEntryPointがあるプロセスでしか見れません。

これはどういうことかというと、別プロセスとして動作するFull IISや、たとえばPHPなどからはせっかくの値が見れないってことですね。
これは不便極まりない!ということで冒頭のたんたかさんのBlogにあるようなHackが必要なわけですが、もっとお手軽にできるんじゃない?ということで試してみました。

まずサンプルということで、ASP.NET MVCで環境変数を出力するようなアプリを作っておきます。

<h1>Machine</h1>

<table>

@foreach (System.Collections.DictionaryEntry env in Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Machine)) {

         <tr>

                 <td>@env.Key</td>

                 <td>@env.Value.ToString()</td>

         </tr>

}

</table>

</p>

<p>

<h1>Process</h1>

<table>

@foreach (System.Collections.DictionaryEntry env in Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Process)) {

         <tr>

                 <td>@env.Key</td>

                 <td>@env.Value.ToString()</td>

         </tr>

}

</table>

</p>

<p>

<h1>User</h1>

<table>

@foreach (System.Collections.DictionaryEntry env in Environment.GetEnvironmentVariables(EnvironmentVariableTarget.User)) {

         <tr>

                 <td>@env.Key</td>

                 <td>@env.Value.ToString()</td>

         </tr>

}

</table>

</p>

 

適当にViewにはっておきましょう。

さてやること1つ目。サービス定義ファイルに環境変数を追加します。

<ServiceDefinition name="WindowsAzureProject3" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="MvcWebRole1" vmsize="ExtraSmall">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Runtime>
      <Environment>
        <Variable name="EnvironmentTest1">
          <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/Endpoints/Endpoint[@name='Endpoint1']/@address" />
        </Variable>
        <Variable name="EnvironmentTest2" value="EnvironmentTest2Value" />
      </Environment>
    </Runtime>
    <Startup>
      <Task commandLine="env.bat" executionContext="elevated" taskType="simple">
        <Environment>
        <Variable name="ENVIRONMENT3">
              <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/Endpoints/Endpoint[@name='Endpoint1']/@address" />
           </Variable>
        </Environment>
      </Task>
    </Startup>
  </WebRole>
</ServiceDefinition>

 

上記のEnvrionmentTest1、EnvrionmentTest2、Envrionment3はそれぞれテスト用です。後で見たらわかりますが、これらの値はASP.NETなアプリ(別プロセス)からは参照できません。

で、ここでのポイントはStartup要素以下のEnvrionmentですね。ここでスタートアップタスクに環境変数を渡してるのですがこのままだとStartupTaskのプロセスが終わったら消えてしまいます。

ということで、StartupTask内でプロセス環境変数をシステム環境変数につけかえましょう。

@echo off

setx ENVIRONMENT4 %ENVIRONMENT3% /M

Setxコマンドに/M引数つけてシステム環境変数に設定してるだけです。簡単!

注意点はシステム環境変数に設定するのでStartupTaskを管理者権限(Elevated)で動作させてるのと、システム環境変数を参照するには設定終わった後にプロセスが起動しないといけないのでtaskTypeをsimpleにして他のプロセスより先に実行されるようにしてるところでしょうか。

もし他にもStartupTaskがあるのであれば、優先順位を付けたりするといいかもです。

さて実際にデプロイして確かめてみましょう。

他の環境変数は取れてませんが、StartupTaskで付け替えたシステム環境変数はバッチリ取れてますね。

これで非.NETアプリ等でもシステム環境変数さえ触れればRoleEnvrionmentの値を触ることができますね!

KINECT for Windows はじめました

えー、勢い余って Kinect for Windows を買いました。

Kinectについてはもう言うまでもないですよね。Xbox 360版と何が違うかというと、Kinect for Windowsは40㎝の近距離でも認識できる近距離モードも備えてたり、最大4台まで1台のPCにつなぐことができる新しいデバイスです!(ファームが違うだけの気がしないでもないけど)

ということでさっそくですね、Kinect for Windows のデベロッパーサイトにいって Kinect SDK 1.0 をダウンロードしてセットアップしましょう!

EULAに同意してOKすればインストール⇒完了というお手軽さです。ちなみにEULAは商用利用も踏まえた形でいろいろ書かれてるので、一読しておくことをお勧めします。

インストール後、Kinect for Windows をPCに差せばドライバが自動的に適用されて利用可能な状態になります。

またスタートメニューにSDK関連のメニューが追加されます。

この中のKinect SDK Sample Browserを使うと、簡単にサンプルをみたり実行したりすることができるようです。

ちょっとアプリ組みたかったところですが、取り急ぎサンプルのKinect Explorerを実行してみました。

液晶PC上に設置するためのスタンドを買い忘れたのでもうちょっとちゃんとした使用感とかアプリとかは今後おいおい見ていこうかと思います~。

いろいろ夢が広がりますなぁ!

より詳しい情報はこちらとか参照ください!

Windows Azure Platform 2周年!

2月1日はWindows Azure Platformの日!

ということで、2010年2月1日から商用スタートしたWindows Azureも早いもので今日で2周年!おめでとうございます!

まだ2年か~とも言えますが、Windows Azureも少しは使える子になりました。憶測もいろいろありますが今後のアップデートも期待ができそうですし、何よりもっと世の中面白いことができるんじゃないかな~と思います!

個人的には実案件でノウハウ貯めたり吐き出したりしつつ今後も付き合っていこうかと思います。まぁ面白そうなこと(人柱的なこと)は飛びついてやりたいですね。※長期間するスタミナがなくなってきた&飽き性ともいう

というわけで3年目もがんばりましょー

※厳密にはUS時間なんでもうちょっと遅い感じですが(・ε・)キニシナイ!!

あの日デプロイしたパッケージのReadyを僕たちはまだ知らない

Windows Azure でデプロイするとぐるぐる祭りになることは非常によくあることだと思います。

というわけで今日はぐるぐる祭りの嵌りどころなどを少し。

OnStartで起動時の処理に失敗したりしてFalseを返すと再試行されます。このときStartup Taskなども再度走りますので、リトライが考えられてないと変なことになってしまいます。
※StartupTaskで嵌った場合はそもそもOnStartまで来なかったりしますけど(Simpleの場合)
※1回しか走らない想定のアプリケーションのインストール処理とかが該当するかと

ちなみにローカルPCのCompute Emulatorでデバッグ実行などを行うとデバッガが終わって再試行されないので気付きにくいですね。但し、CSRunコマンドから実行した場合はちゃんとエミュレートしてくれます。

OnStartが繰り返し呼ばれてるのがわかるかと思います。

そんなわけでOnStartのエラー処理はちゃんと考えて適切にしましょう。ただ変なまま起動するのがいいのか、このケースみたいにずっとビジーがいいのかは要件次第ですね。(というあたりが難しいところ)

あと、Windows Azureの管理ポータルで表示されるインスタンスのメニューですが、「再起動」はOSの再起動じゃなくて配置をもう一度最初からする的な意味の再起動です。

つまりStartup Taskも走ればOnStartも走るということで。OS上の再起動とは異なるので注意。
※エラートラップちゃんとしてなくて安易にやられるとOnStartでFalseかえってぐるぐる祭り開催!になります。
対処方法としては「初期状態にリセット」でReImageするとかですね。。

という感じで今日は自分が嵌った点をお伝えしました。とほほ。

 

※ぐるぐる祭りとは

ビジーやAbortのままReady状態にならない時の管理ポータルの見た目(アイコン)の事

例:

こんな感じでぐるぐる繰り返します。。。切ない。