会社の偉そうな人とお話をしていたときのお話です。面倒なのでIaaSについて。クラウドを利用するときには、そのインフラを提供するか、既にあるインフラを利用するかの２択しかありません。既にあるインフラとはAmazon EC2だったりするわけです。 Amazon EC2はXenと沢山のツールたちで動いています。GoogleのMapReduceだとか、いろんなものがオープンソースで実装し直されているように、Amazonのインフラもオープンソースでインプリし直されています。それが、Eucalyptusです。この人の存在はUbuntu 9.04のリリース情報で知ったのですが。

この人もXenを利用して、Amazonのコマンド群と同等のものを提供していて、マシンさえあればAmazonのクラウドと同じような環境を提供できます。会社の偉そうな人は、検証用に自分たちのクラウドを提供したいと言っていました。僕も、利用するだけじゃわからないので、検証用に自分たちのクラウドを作ってみたいとは思います。でも、マシーンがない・・・。

さて、検証というか実験用に自分たちのクラウドを構築するのは楽しいです。でも、これでビジネスになるかというと、難しそうなので悲しいです。大量のサーバがないとスケールのメリットが十分得られないとか、理由は様々です。つまり、第2のAmazonになることは無理だろう、と思っていました。

でも、アメリカは不思議な国です。この不況下でデータセンターがつぶれたりして、それを買いあさっている会社があったりするそうです。買い漁ったデータセンターでクラウドを提供しようとしているらしいです。それで飯が食っていけるか知りませんが、壮大な試みです。まあ、Amazonの数万台というサーバを聞くと、普通はそこで諦めちゃうので、それに対抗しようだなんて大バカものの集まりかもしれません。

会社にはマーケティングができる人がいないなー、とか、営業とマーケティングは違うなー、とか思いつつ、Amazon EC2で会社の製品を動くようにしました。

会社の製品は、基本的にはWebサーバにApacheがいて、アプリケーションサーバにTomcatがいます。このあたりはIBMのWebSphereもサポートしていますが、高い上によくわからないので僕は嫌いです。そして、データベースサーバにはOracleがいます。これをAmazonEC2で動かしました。ちなみに、まだ検証段階なので、OracleはExpressEditionです。

Oracleのデータは定期的にS3にバックアップさせる運用にしようとかと思いましたが、バックアップに結構時間がかかるし、バックアップをとるまでにOSが落ちると悲しいので、OracleなどのデータはEBSにおくことにしています。ログファイルなどもEBSにおいた方がいいのか、実際の運用だと指定したログを集めるサーバに集中させた方がいいのか、まだよくわかりません。他の人たちはどうしているんでしょう？

OSを落としたらデータがなくなるということ以外は普通のLinuxのサーバでなにも特殊なことはありません。いや、特殊なことはあるんですが、それほど困ったことにはなりません。

動作はなんとなくもっさりしている感じがします。一番安いプランで動かしているせいかも知れません。 /proc/cpuinfoをみるとDual-Core AMD Opteron(tm) Processor 2218 HEで2.6GHzとでています。まあ、そんなに悪くはないですが、CPUの数が一個しかみえません。一番安いプランはCPUが一個だったか、Xenがそいうものなのかよくわかりません。CPUの負荷はそれほどかかっていない感じですが、仮想環境なので本当のところはわかりません。ネットワークは、数Mbpsでていました。まあ、このsプイードは、会社のネットワークとかプロキシの問題なのか、いろいろありすぎてわかりません。

次は、EC2上で複数のVMを動かしてEC2内でパフォーマンスのチェックです。その前にフィボッチ数列(僕が最初に思いつく負荷の高い処理)の計算でもさせるか？

Amazon EC2で遊び始めました。じゃなくって、仕事でいろいろ調査し始めました。EC2に限らず、最近仮想化技術とクラウドのお話をちらほら聞き始めています。海外のもEC2以外のサービスについても聞いたりしますが、とりあえず、日本のお話。

日本でも仮想化とクラウドのサービスを提供したりしている会社があります。何をもって、仮想化とかクラウドと呼ぶのか、そういう定義はおいておいて、キーワードだけで見ています。

サービスが提供されるまでの時間ですが、EC2だと、まあ数十分でサービスrが利用できるようになります。とても早いです。 一方、僕が聞いたサービスは、大体、２週間ぐらいかかります。2週間後にOSがインストールされた状態で引き渡されるならまだしも、そこからOSのインストールが始まります。

さて、サービスを利用できるまでの早さは、EC2に到底及びません。それじゃ、値段をみてみると、EC2は料金の出し方が従量課金(年間の契約もあるけど)だったり、ネットワークの利用量に依存したりして一概には言えませんが、あすなろブログのよこたんの「Amazon EC2/S3」の本によると数十万円とかになるそうで、一台のサーバあたりは数万円です。日本のサービスは十数万円とかストレージを含めると数百万円とかすごいことになったりします。

まあ、サポートの質だったり、バックアップ体制の違いだったり、いろいろあるので一概には言えませんが、やっぱりEC2安！ 

昔から開発時のバージョン番号とリリースするときのバージョン番号が微妙にずれたり、変更したくなってもいろいろと面倒なことがあったりしました。開発としてはそれほどバージョン番号にこだわりがなく、シーケンシャルに増えて行けばいいだけです。ブランチのメンテナンスもあるので、マイナーバージョンも必要ですが、まあ、今のバージョンが1でも50でもある程度管理しやすければ何でもいいです。

それとは別に、営業としては1.xや2.x、3.xなどでお客さんに与える印象がかなり変わるらしいです。また、マーケティングとしてもコントロールしいらしいです。まあ、僕としては、1.99とか2.99のようなバージョンも面白そうだとは思うんですが、それは変らしいです。まあ、僕でも変だと思います。

こうした開発と外部に公表するバージョンのミスマッチの解決手段の一つとしてコードネームみたいなものもありますが、アリエルでは定着しませんでした。

そして、僕はリリースした時期は大体覚えているのですが、そのバージョンはかなり混乱していて、一瞬考えないと間違えることもあります。僕はまだいいのですが、きっと社長はバージョン番号を把握していません。なので、開発内部でのバージョン番号はUbuntuのようなバージョン表記にしました。まあ、コードネームです。メジャーバージョンが年で、マイナーバージョンが月というやつです。今年の3月にリリースするものは9.03になります。大体、メンテナンス期間が一年間なので、リリースした月さえ把握しておけばなんとかなります。これでいろいろなものが一気に解決します。開発の内部的な呼び名はubuntu方式で、顧客に出すときは営業なりマーケの人が好きに決めていいよ、というようにしました。

 正確にはそうしたつもりだったんですが、誤解が発生して、ubuntu方式が顧客にだす正式なバージョンになりそうです。まあ、思惑通りには行きませんが、それほどこだわりもないので、なんでもいいです。 

最近、Amazon EC2で何かをしようとしていろいろ画策しています。まあ、個人的な興味を適当な理由を付けて会社の仕事としてやろうとう言うことです。

まず、前提条件として会社ではデータベースにOracleを使っています。今あるコードベースをOracle以外に移植するのは大変なコストがかかるので、今後もOracleを使い続けると思います。そのOracleですがCPUの単位で費用が決まります。 OracleはAmazon EC2上での動作をサポートしているとはいえ、ライセンスは既存の物理的なサーバのままです。

さて、Amazon EC2というかクラウドって、必要なリソースを割と簡単に割り当てたり、消しちゃったりできることがメリットだと思っています。 最初は、例えば4CPUで動いていて、負荷が高くなりそうな時期とかだけ8CPUで動かそうとしても、ライセンス違反になっちゃうような気がします。会計や給料系のアプリとかは負荷の時期が偏るかもしれません。結局、一番負荷が高い頃に合わせて見積もると、クラウドのメリットが半減するよう気がします。まあ、Oracleのライセンス体系とクラウドがあんまりマッチしていないんじゃないかなー、ということです。

まあ、Amazon EC2はそんなに高くない(というか安い)ので、ちょっとばかしゴージャスにしておくのがいいのかもしれません。

説明しても、お互いに認識の間違いがあることはよくあります。その場合、声の大きい方が正しいことになったりします。で、社内では時々、説明する方は説明して相手にわからせる義務があるとか、努力する必要があると言われることがあります。

でもね、「これは鉛筆です」と説明して、あとで、「それってボールペンだと思っていたよ」って言われると、どうしようもありません。議事録にも「これは鉛筆です」と書いています。でも、説明してわからせる義務があると言われると、説明する方が一方的に悪くなります。でも、これ以上、「これはペンです」をわかりやすく説明できないし、それ以上説明しても、聞いてもらえません。しかも、定期的に何回も説明しています。

説明しないとか、ドキュメントに書かないのはもってのほかですが、説明してわからないものはどうしようもないです。説明しているのに、それを一方的に説明する方の責任にすべきではないし、 義務とか努力とか、訳のわからないことを言うべきではないです。

まあ、明らかに説明が足りなかったというケースもあるので、説明する方は悪くないとは言えないですが、それでも、そのときは説明した人にもっと聞けばいいので、やっぱり、説明した人が一方的に悪いということはないはずです。  

至る所でiPhone3.0の話題になっていると思ったら、火曜の夜はなんかの発表会だったのね。すっかり忘れていました。

ニュースをざっとみると、順当な進化です。コピーペーストの機能も、確かに必要だけど、面白みはありません。Bluetoothを使った端末間の通信は、渋谷でインスタントプチチャット 機能が実現できるという数年来の幻想がかなうかもしれません。まあ、それ以外の機能も予測の範囲内だったり、インパクトがそれほどなかったりします。tetheringができるかもしれないのはうれしいのですが、モバイルWiMAXのスピードに3Gはかないません。

Engadgetのサイトの画像にはNotes Syncって書かれています。それが一番目についたのは昨日のエントリのせいかも知れません。

でも、冷めた目で見つつも新しいもの好きなので、待ち遠しい自分もいます。 

会社や世間(ひょっとしたら限られた僕の周りの世界)のスタンスとしてはNotesは古くさいシステムなので、さっさと今時のシステムに乗り換えちゃいましょう！です。まあ、確かにそういう側面もあるんですが、Railsにしても、それ以外のWebフレームワークにしても、かなりの労力がCRUDにあって、そこにわずかばかりのロジックをフレーバとして加えているだけです。

Notesは数十年前の古くさいシステムですが、クライアント・サーバで不定形文書を扱うCRUDに特化して、そこそこ効率的に開発できていたと思います。まあ、別の言い方をすれば、効率的すぎたのかも知れません。

インターネットがそのあとやってきて、Notesにもインターネットの影響を受け始めたときぐらいに、僕は新入社員でした。 Webに対応するためにノーツのテンプレートの中などにJavaScriptやらHTMLがいびつに入り込み始めました。それに加え機能は肥大化してどんどん重くなりました。でも、最近Notesを触る機会が増えたのですが、最近の感想は「Notes/Domino軽いじゃん」ということで、ハードウェアの進化は偉大かもしれません。もしくはデータ量が足りないだけかもしれません。いずれにせよ、数年前にNotesってほとんどのユースケースでオーバースペックじゃないかな、と思い始めました。まあ、Dominoの中にLDAPサーバはいらないし、メールサーバもなくていいです。いらない部分をそぎ落として非定型文書のCRUDに特価した開発環境で、DominoがいびつだったWebからのアクセスも、コーディングレスでかなりのことができれば面白いんじゃないかなー、というあたりで、今のアリエルの製品コンセプトが練られ始めました。まあ、簡単に言えば、Webに対応したスモールNotesです。まあ、マーケティング的にはNotesのエンタープライズの市場とサイボウズだとかのローエンド市場の間にニッチがあって、そのニッチからNotesのエンタープライズ市場に食い込めないかとか、なんとかでっち上げたような気がします。まあ、僕はマーケティングの人ではないので、好き勝手なことを言っていただけですが。

その後のお話はまた今度。 

登場人物

 - マネージャ M

 - ぺーぺーのエンジニア  P

 - 僕 O

----

M「プロジェクトAの進捗はどうなっていますか？」

P 「先週末実装の終了予定でしたが、ちょっと遅れいていて、今週終わります」

M 「わかりました」

 そして、進捗を管理表で 実装の終了予定日が何事もなかったかのように一週間延ばされました。

O 「えっ。遅れているのにそれだけ？」

M 「そうですが、何か？」

O 「・・・」

 (心の中で「そんなことだからプロジェクトが遅れてもみんな平気でいられるんだ」) 

O 「もう少しなんとかならないですか？」

M 「何とかしろとはどういうことですか？」 

O 「・・・」

 僕はこのとき風邪をひいていて、疲れたのでそのときは放置。

世の中、中々思い通りにならないです。 なかなか、Mは期日を守ることが大切だと認識してくれません。もしくは、どうすれば期日が守れるか、考えようとしてくれません。

今日は社内が技術的なことで盛り上がりました。ことの発端はこのblogエントリからです(その続き、そのまた続き)。同じ社内にソースコードがあるのに、このエントリからソースをコピペされて、いろんな環境で計測されたり、計測結果がそうなっている理由のうんちくが話し合われました。

こんな話題で盛り上がるのはこの会社の文化だなー、と思います。

社内のいろいろな結果は、もう少し時間をおいて(データが出尽くしてから)まとめます。 

先週の金曜日にライブドアテクニカルセミナーに行きました。行くまでは完全に忘れ去っていましたが、ライブドアと言えばPerlです。そして、Perlは僕の嫌いな言語の一つです。けれども、そんなことはどうでもよくって、とても面白かったです。正確には、もう少しそこがしりたいけど、その部分は隠されていたりとかしていて、ちらみせ状態です。

さて、最初はレコメンデーションエンジンのCicindelaです。なかなか面白そうです。エンジンはともかく、どれくらいのデータを処理するかとか、何を対象にマトリックスを作るかが大事そうです。エンジンさえあれば、もしくは同じエンジンならいいものが作れるとか、そういうものじゃなさそうです。まあ、そうは思っていましたが、その通りでした。

Cicindelaはパフォーマンスを意識して作られているらしいです。もとはApacheのプロジェクトをPerlに移植したらしいです。すると、Javaだと数秒の処理がPerlでは数十分かかったそうです。Javaはオブジェクトを大量に作るので、そのままの移植はやめて、オブジェクトをあまり作らないようにかえたら、Javaと同等かそれ以上のパフォーマンスになったそうです。まあ、それ以外にもいろいろあったんだとは思いますが。ただ、僕が今まで想像していた（見たことがあるもの）ものよりはマトリックスの作成のスピード速いです。

 そのあと、「インサイドlivedoor blog」ということで、システムの大きな構成とかを説明がありました。で、今回、システムをリニューアルしたらしいのですが、文字コードをEUCからUTF-8に変更して、古いものはEUCで、新しいものはUTF-8で動くそうです。すげー。まず、blogが始まったのがせいぜい2000年以降なので、最初からutf-8で作れよ、という気もします。その次に、一つのシステムに二つの文字コードが混在して、それを動く形でメンテナンスするのはすごいです。文字コードてバグの元で、Javaの一番のメリットは文字コードが言語仕様として統一されたことだと思っています。まあ、簡単に一つにできなかったんでしょうけど、混在したシステムをちゃんと作るのも大変な作業です。

そのあと、「ライブドアのネットワーク」についてのお話でした。トラフィックのパターンからユーザの行動を説明していました。この手のお話は好きなんですが、興味のないひとには興味がないかもしれません。

最後にWinnyの作者の金子さんのSkeetCastというコンテンツ配信のお話でした。正直、よくわかりませんでした。だれにメリットがあるかよくわかりません。いずれにしても、うちではDRM付きのWindows Mediaのファイルを見れないし見ないので、僕にはまったくメリットがありません。