つれずれなるままの開発日記(最近はFlexばかり..)

Archive for 2010/1/6

2009年は、クラウド、クラウドと言葉だけが聞かれたが、周りでは全くといって「クラウド」を使ったという話は聞かなかった。

というのも、自分自身がクラウドに手をつけていないためもあると思うが、まだまだ、本格的になってはいないのかもしれない。という訳で、今年はその前に簡単に個人的に試せる、Google App Engine を試してみようと思っている。

さて、「クラウド」といえば、今年から、国内でもちょこちょことクラウドを提供する会社が出てきた。

たとえば、ソフトバンク系列の会社でも「ホワイトクラウド」というサービスを始めるらしい。

これで、日本国内の法律でいろいろと考えられるので、データの保守という観点でも利用しやすくなっていくだろう。

いろいろな会社のクラウドのサービスをみていると、企業でもっとも使いやすいのは、Amazonなどのようにシステム環境を提供してくれるケース(IaaS/HaaS)だと思う。これだと、自社にエンジニアがいて、今まで自分たちでサーバを保持（レンタル）し運用してきた会社などが比較的スムーズに移行できると思う。

が、私が思うのは、役割の違うクラウド自体を連携して使うようにしてもいいのではないかと思ってる。特に「スモールスタート（低予算）」を余儀なくされるもので、BtoBtoCではありではないかと思う。

IaaS/HaaSモデルはトータル的にみて、Googleのようなクラウド(PaaS)に比べて利用料金も高いだろう。それは、システムを保守する人が必要だろし、ハードの保守がなくなっただけで、OSやミドルウェアから解放された訳ではないのだ。コストについては感覚で述べているので、正しくはよくわからないが、あまり間違ってはいないと思う。IaaS/HaaSではアプリケーションの構造もあまり変えなくていいし、既存のエンジニアの技術の延長で使えることが多いと思う。

ということは、当然、これまでかかるコストが劇的に減ることはないだろう。

そこで、Googleのクラウド(PaaS)をデータの「表示と入力」のインターフェースととらえ、「計算と保存」を他のクラウド(IaaS/HaaS)や、プライベートクラウド等で補完すればいいと思っている。もちろん、複数のシステム間のデータ同期などで多少ややこしくなるが、自分たちで、システムからサービスまで構築できるところは、アプリ環境の違いなどたいした違いでもないと思う。

（自社でできない場合や、すべてを任せられない場合などには、組織構造の問題も含めて逆に高くつくことにもなってしまうかもしれない）

しかし、アプリケーションの構造が強制的に変わる。それは、コストのはかり方に関する認識も変わってもおかしくはないほどの変化をもたらせることも可能になるのではないだろうか。

特に、成功していないようなサービスの場合には、扱わなければならないデータの量も少ない。これであれば、「計算と保存」部分はサービスによっては、自社で細々と運用してしまってもかまわない。

そして、重要な点は「計算と保存」の部分のサービスを２４H、３６５の品質を問わないように設計する必要があるだろう。これが実現できれば、システムの保守は断然低コストになる。

止めなくてはならい時は止められ、そして、規模を大きくしたいときには、IaaS/HaaSへの移行ができるようにしておくのだ。

このようにすることができれば、サービスの成功結果と比例したコスト構造を持たせることができるので、初期投資があまりなくても、比較的新規サービスがしやすいのではないかと思う。

ところが・・・・ここまで書いていいことがかなりあるなーと思ったが、ちょっと疑問が生じた。

今まで私は、Javaで構築されたシステムが24-365で運用されているのをほとんどみたことがない。

ほとんどのシステムがリソースを食い続け、システム停止に陥るのだ。このため、定期的に再起動している。昔、ある会社ではこの問題のために、１２台のWEBサーバを２４台に増やそうかというようにもめているところに、私がたまたま、他の会社で似たような問題で解決したので、会社のおつきあいから、その会社に行って、問題をみたことがある。このような問題がいろいろなところで見受けられた。

要するにプログラマが悪いのだが、ちょっとしたことでこのような事象が発生するだろう。

そのときに、OSの状態を見てどのリソースを食っていたかみることができた。

さて、このようなことが起きたときに、Googleクラウドではどのようになるのだろうか・・・

また、どのようにして調べるのだろうか・・・

これもちょっと興味があることではある。