TIM Labs

KOMMYによるエントリー一覧

Azure SQLは便利ですがオンプレミスとは違うので不便な点もあります
そのうちの一つが(そして大きいのが)自動バックアップです

Azureの管理画面を通してのバックアップならできるのですが(保存先はBLOBも使用できます)それをバッチで実行するのが大変でした
大変というか事実上ツール頼りで、うちでは以下のようなツールを検討していました
http://www.idera.com/productssolutions/freetools/azuresqldatabasebackup

しかしついにAzure SQL 標準の機能として自動バックアップが実装されました(まだプレビューですが)

AzureSQLBackup.png

久しぶりにマジで得した気分です

1月31日の3ヶ月後は何月何日だろう?
C#で書くとこうなります

 DateTime d = DateTime.Parse("2012/1/31");
 d = d.AddMonths(3);

まあ皆さんの想像の通り4月30日になるわけですが少し前にこれが困った事態を引き起こしました。
図書館システムで返却日は貸出日の3ヶ月後というルールがあって、その通り計算していたのですが、それが上記のケースだったわけです。現場の感覚としては貸出期間が3か月未満になっておかしいということでした。

正直AddMonthsがありえない日を計算(上記では4月31日)を計算したときにどうなるのか全く知りませんでした。

ちょっと調べると(まあ調べるまでもないですが)表現可能なように日にち部分が削られるのが仕様なようです。まあデフォルトの動作はそんなものかな?と思って、じゃあこのようなケースで5月1日を返すようなオプションがあるのだろう、と探してみましたが... 見当たらない。あってもよさそうなものだけどなと思いながら、しょうがないので自分でルーチンを組みました。

組んでみて納得。AddMonthsの引数がマイナスの場合(さかのぼる)場合には「表現可能なように日にち部分が削られる」という今の仕様でないとうまくいかないですね。勝手に次の月にしたいケースは思いつきません。自作のルーチンではマイナスの場合は普通のAddMonthを呼ぶようにしました。

たぶんほかの言語でも同じだと思います。調べるの面倒なので調べませんが。
まあしょうもないネタですがDateTimeなんてありきたりのクラスにもまだまだ未知の部分があると知ってフレームワークの偉大さを再確認しました。


しばらく前に買って積読されていたので再度読み始めました
ゲーデルの定理を大学時代に知ったときは「結論はわかる。でもどうして証明可能であるという概念が実際に算術上の命題として表現できるのか?」を理解することができなませんでした。論文ではこの部分を丁寧に大量の中間概念を導入しながら証明していくのですが、個々が抽象的すぎてすぐに眠くなってしまうからです。

100年前にヒルベルトが目指した数学の完全な形式化、そしてその無矛盾性の証明は当時は高度に抽象的なものであったと思います。
しかし現在プログラミングを生業にしているとこの概念は極めて具体的で明瞭です。
なんせコンピュータとは形式的な記号の羅列をルールに従って操作しているだけなのですから。
ゲーデル数の概念はアセンブリ(プログラミング言語)そのものがビットの羅列で表現できることと同値だし、定理や推論規則の算術的操作への置き換えはCPUがそのビット列に対してビット操作(演算だ)するだけで動いていることと同値です。

そう、今回は違います。ゲーデルの証明を一つずつプログラム言語で記述してしまえばいい!
そういうことならHaskellでしょう。だってHaskellのプログラムってそのまま数学の証明みたいだもんね!

まあそんな野望を抱いて最初の1章を読み終え、さてそろそろプログラムを書くか...とHaskellに詳しい同僚に相談してみました

「無理っすよ、Haskellは述語論理(∀とか∃とか)を表現できないですから!Haskellに述語論理をのっけたAgdaってのがあります」

うーんなるほどね。世の中には大抵先を行く人がいるもんだな。
すげぇと感心しつつ、Haskellさえちゃんとやったことのない身としては恐怖を覚えたのでした。

まあ今回は本当に証明したいわけではなく、ゲーデルの証明をプログラミング言語で表現したいだけなのでExistとかForAllとかの関数を書けば済みそうではあります。とさっそく言い訳を...

AzureにはStickyセッションがない
なのでアプリケーション側でセッションサーバを用意することになるのだが、そのためにAzureが用意したのがAzure Cache Serviceです

ところでAzure管理ポータルの旧UIであるSilverlightバージョンの画面がとうとう廃止になるらしい

AzurePortal.png

しかし上記のようにAzure Cachingだけはなぜか新ポータルでサポートされません。よほど使われていないのか、黒い政治的な理由があるからなのか、技術的理由があるからなのかわかりませんが。

しかし問題はここからです。さっそくキャッシュサービスを管理してみましょう

AzureCaching.png
キャッシュで管理できる唯一の処理「キャッシュサイズの変更」を押します。
・・・何も反応がない、ただのしかばねのようだ

これ本当に焦りました。普段は小さめのキャッシュにしておいて費用を節約し、アクセスが増えそうな時に増やそうとしていたので
それがサイズを増やすことができない!

結局表示言語をEnglishにすることで無事キャッシュサイズの変更をすることができました。これが発生したのは4月なのでさすがに今は治っているだろうと思って(そしてこのブログのネタにするために)改めて試してみたのですが、いまだに日本語だとダメですね

日本でAzure Cachingを使っている人なんていないのか、みんなこのTIPSを知っているのか
何はともあれ、今後同じ問題にはまった人がこのエントリにたどり着ければいいなと思います

マイクロソフトにしては静かにオープンし、人知れず勢力を伸ばし、知らぬ間にアップデートを続けているAzure。
オープンし1年を迎えるが、遅まきながらAzureに触れてみて「Azureってやばいかも?」と思っている

まあこんなブログ読んでいる人ならAzureが何かくらい知っているだろうし、適当にググればいくらでも紹介記事があるので詳細まで説明しないが、とにかくやばいのである

何が?やばいのか

1、OSやミドルウェアのライセンスがかからない

従来MSテクノロジーvsOSSではライセンス費用がかさむ分MSテクノロジーが不利だった。その不利を打ち消すように「便利ですよー」「高機能ですよー」とやっていたわけだ

しかしAzureではインフラ代金は請求されるがライセンスなどまったくかからない。月間1億PVを稼ぐサイトや超大手の基幹システムならいざ知らず、数千万規模のシステムではこれはとてつもない破壊力を持っている

考えてみてほしい。開発費3000万のシステムで、そのインフラ初期費用はいくらいかかっているだろうか?ケースバイケースだと思うが、MSテクノロジーを使えば1000万くらいは普通にかかるだろう。これをOSSにして500万などというのが従来の世界観だった。

「ちょっと待って、クラウドの特徴はスケーラビリティとか超大規模システムじゃないの?」とか思ったかもしれない。私も最初はそう考えていた。しかしAzureの仕様を理解するにつれ、このクラウドはごく普通の、むしろ小じんまりな案件でこそ破壊力があると思うようになった。


2、PaaS(Platform as a Service)の力


Azureで手に入るのはASP.NETのアプリケーションプールであり、SQLServerのインスタンスだ。どうやってロードバランスするかとか、障害時のリカバリをどうするかとか、セキュリティパッチをいつ当てるかとか、ディスクフルの監視をしなくちゃとか、そういった運用的な雑務から一切合切解放されている。
Azure以外でこれを実現できるのはGoogleAppEngineくらいのものだと思う。J2EEやPHPでは同じようなものがない。
そしてJ2EEで今後PaaSが出てくるとは思えない。なぜならJ2EEのプラットフォームの統一は絶望的だろうからだ。LAMPならできるかも知れない。というかすでにあってもおかしくない(私が知らないだけだ)

何が言いたいかというと、PaaS競争は値段もあるけど、結局プラットフォーム競争になるわけであって、現時点では実績、機能、統一性の総合点でASP.NETが最強で、それを他社がPaaSとして提供してもWindowsやSQLServerのライセンスから逃れられない以上、Azureが最強なんじゃないかと


よく言われているけどマイクロソフトは過去に大きな方向転換を何度かしている。
IBMと袂を別ちWindowsを出し、ハードのおまけだったOSが主役になり、ハードこそOSのおまけになったとき。
IEを出し、IISを出し、スタンドアローン中心からインターネットを中心にすえたとき。
そしてあと10年たってみれば、Azureがサーバ市場支配の始まりとして3度目の大きな転換に数えられるときが来るのかもと、思ったりしています




このアーカイブについて

このページには、KOMMYが最近書いたブログ記事が含まれています。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。