Wakame-VDC v11.12をリリースしてみて

先月末にWakame-VDC v11.12がリリースされました。 私たちはこの半年の間、Wakame-VDCの安定化と、実案件への適用、運用、数多くのバグフィックスを通じて様々なナレッジが得られました。 今回のバージョンアップはそれらが全て反映されたもので、今すぐインストールDVDを入手することができます。

早速いろいろと感想が届いていて嬉しい限りです。(←日本語の感想はまだ無い)

OpenFlow対応

特に大きな機能追加は、前回ポストした通り、OpenFlowに対応したことです。おそらく正式リリースされたプロダクトの内、IaaSのようなクラウド基盤ソフトウェアとしては初めてではないでしょうか。 優秀なエンジニア達が組み上げた野心的な試みです。 現在はOpenFlow Specification v1.0.0に準拠する機能しか使えていません。 v1.1.0以降のバージョンに興味深い機能はたくさんあるのですが、まだ使える実装が無いのです。 今はOpen vSwitchと、Tremaを組み合わせています。OpenFlowに足りない機能は、一部Open vSwitchに依存していますし、Tremaも部分的にコードを改造して利用しています。 やってみて分かったのは「機能はするが、それぞれ外部環境となる動きがまだ激しく、安定を志向するユーザ様にとっては時期尚早と言う印象」です。 これとは逆に、新しい可能性を感じられる方々にとっては、Wakame-VDCは十分に検証用のシステムになり、大きな価値を提供できます。 クラウド基盤ソフトウェアにとって、ネットワークは最もエキサイティングな分野です。 この部分の機能拡張を強く進められたことは、Wakame-VDCのこれまで積み重ねて来た確たる実装と、拡張のしやすさ、そしてエンジニアのパワーであると改めて認識しています。

安定化への挑戦

Wakame-VDCは、品質の安定化に向けた取り組みもすでに始まっています。 一文字でもプログラムに変更があれば即時ビルドしてテストを通して確認するプロセス(Continuous Integration - CI)が出来ています。

テストは重要です。 特に、まとめてテストをするよりも、小さな変更が起こる度に行われるテストが重要です。 システム開発のご経験がある方ならご理解いただけるかもしれません。 バグは解析に時間がかかります。 注意深く解析してたどり着いた答えはいつも明快で、原因は小さな不注意です。 そしてプログラマはいつも「このコードは確かに悩みながら何度も書いた」とか「なぜこのバグをその時に見つけられなかったのか」悔やむのです。 CIのプロセスは今加えた変更が、これまでのテストを通さなくするものかどうかはっきりさせます。

また、冗長化構成を取れるように、インストールのガイドラインを準備中です。 これまでもアーキテクチャは冗長化可能なように設計をしてきましたが、ノウハウをまとめてアウトプットしてはいませんでした。 これは、Wakame-VDCが大手電力会社様の次世代向けインフラとして使われており、そこで手を尽くしてきたところです。 皆様にも良い事例としてお示しできるのではないかと考えています。

機能面でユーザへ安定を提供

今回追加された様々な機能が、ユーザに安定を提供します。 物理サーバの障害対応したり、DHCP無しの環境でも動作させられるようになったり、実に様々な試みが組み込まれています。ぜひお試しください。

今後はより開発に注力できる環境作りを

Wakame-VDCは、開発を始めて3年目に突入しました。 オープンソースプロジェクトがこのように長く続いたこと自体、クラウド基盤技術への注目度が高く、また必要とされていることをヒシヒシと感じます。 国内でこのような活動をしている企業はあまり聞きません。 使う側からすれば単純な機能に見えますが、それを研究しながら首尾良くプロダクトにまとめながら使える形にしていくところに、想像していた以上の難しさを感じています。

私共は、こうしたテクノロジをしっかりやっていく企業になりたい。今後は開発スピードを上げて、引き続き世の中へ価値を生み出していきたいと考えています。 そのための3年計画も考えました。 次々に施策を進めていきます。 今年もどうぞよろしくお願いいたします。これからもお楽しみに！

ご協力者募集中！

Wakame-VDCは、オープンソースライセンスに基づくプロダクトです。常々皆様と一緒に開発をしていきたいと思っています。メールなど何でも結構ですので、ご連絡ください。お待ちしております。

EC2互換APIの開発を始めましたけれども…！

AWS EC2のインターフェイスを受け付けられるだけでなく、相互互換するためのプロジェクトであるWakame-adaptersの開発を始めました。
現時点で実案件のニーズはあるので、作っておけば他に使いたい人も居るかしら…と言う判断です。将来的には、むしろWakameのWeb APIで、AWS EC2をコントロールする方向を考えています。

ただし、色々なところで以前から公言している通り、「AWS EC2のインターフェイスでWakame-vdcをコントロールできる機能をWakame Project内で未来永劫サポートする」ことをお約束するものではありません。

今回はその理由を以下に３つ述べておきます。

1. AWSのWeb APIは設計が古い
2. インターフェイスだけではなく、挙動も合わせなければならない
3. AWSが未来のクラウド像とは限らない

Wakame Projectでは、設計当初からAWSと互換するのを公式サポートするのだけは避けたいと思っていました。元々AWSのインターフェイスはモダンなWeb APIと比較すると仕様的に重くて、開発者に優しくないのです。
今どきXMLを使っているとか、パピルスに記されたクサビ形文字を読めと言っているようなものです。パースの手軽さを失っているので、新しいWeb APIが公開されただけでは気軽に試そうと思えない。そんな人は言語レベルでのアクセスライブラリの提供を待つことになります。（最近は提供速いのかな？）AWSクラスの素晴らしいエコシステムを持っていても、サードパーティがこれらを組み入れるのは更に後のことですし。
AWSもその内軽量のアクセス方法を併用してくるんじゃないかしら、と勝手に思っています。
 
次に2.についてですが、互換と言うのはインターフェイスだけを合わせれば済む話ではありません。内部の挙動も合わせる必要があります。IPアドレスが決まるタイミングや、ステータスの遷移パターン、例外処理など、期待される動作が一致していなければ動く物も動かないのです。
例えばIPアドレスなんかは、EC2ではインスタンスがブートしてから決まります。しかしWeb APIを利用するプログラムにしてみれば、早期にIPアドレスが決まればコードが簡潔になります。そうした効率的動作はWakame-vdcに組み込めるはずなのに、AWS EC2互換する時には使えないんですね。その辺りはやっぱり開発者に優しくない。

また、いくつかの案件ではEC2にはない特殊な要件がありました。それは互換APIのレベルには無い機能なので、実現すれば互換ではなくなるわけです。AWSと互換する宣言は、自分達の思惑や戦略を捨てて、AWSと同じ物を作ると言う意思がなければ言えない言葉です。
今後も背負っていくには少々重すぎます。

最後は3.です。
皆さんは未来のクラウドは仮想ネットワークが実現されていて、好きなネットワーク構成を自由にデザインできて手に入るようになっているのでは？と夢想したことはありませんか。
Yesと答えた方、そう、あなたです。もうあなたの未来にあるクラウドはAWS EC2と互換していません。AWSが未来のクラウド像であるとは限らないのです。

長々と書きましたけど、まとめると下記の通りです。

• AWSとWakameは似てるけど、目的が違う物です
• 目的が違うので、今似ていると言う理由だけで互換を宣言できないです

…と言うことで。

補足

誤解の無いように補足しますが、AWSがダメだと言っているのではありません。
APIのデザインは古くからやり続けて来た歴史的背景もありそうですし、未来のあるべき姿では無いと言うのも、自らのニーズに忠実に設計して生み出されたものであれば、我々が勝手に夢想して未来と思い込んだ物と異なるのは当然かも知れません。まさに今使える物を、欲しい人に届けている。だからAWSは凄い。

どこまでも真っ直ぐだなーと思うわけです。

ネットワークの仮想化について考えてみた結果がこれだよ！

ネットワークの仮想化を手がけている会社は少ないとおっしゃる方もいらっしゃいますが、IaaS型クラウド基盤のコード読んだらおわかりの通り、今やどのコードにも大なり小なりもう組み込まれています。「ネットワークの仮想化って一体なんだ？」に答えられる記事にできたらな、と思って、久しぶりに書きました。

ネットワークの制御を集中的なトポロジでやるとスケールしない

IaaS型クラウド基盤としては先駆者であるEucalyptusにもすでにネットワークを制御する試みはあります。Cluster Controllerと言う名前で、Node Controllerに対するパケットフローの掌握に挑んでいます。スケールアウトしなかったのとSPOFになった点を除けば、設計が悪かっただけで、 自由なネットワークを作るアプローチの一つであり、まさにネットワークの仮想化を目論んだ仕組みなんだと思います。

VLANは数に限りがあってスケールしない

僕達はWakame-VDCを作るにあたって悩んでいたことがひとつありました。それはもちろんネットワークです。
ユーザーが望むネットワークをどうやって自由自在に構築するのか、これに全く良いアイディアが無かったのです。逃げ道として考えたのが、貸し出す仮想サーバーのNICをいくつか用意し、VLANで区切られた目的別のネットワークに流すと言うものでした。しかし、VLANは12bitの上限があり、4000+α個作るともうそれ以上スケールしません。

スケールアウトさせるため分散を前提に制御せよ

悩んで悩んで、無い知恵を絞って考えていたら、ある時こうすれば良いと言う結論に至ったのです。それが、2010/11にリリースしたWakame-VDC v10.11に反映された分散ファイアウォールの考え方でした。そしてその発想は、2011/06にリリースしたv11.06の分散NATにも反映されています。

これらはどこに分散しているのかと言うと、「すべてのエッジノード(末端部分)に分散している」のです。エッジノードに分散してしまうと制御が大変ですから、ここにソフトウェアの力が必要になります。Wakame-VDCのネットワーク制御はすべてエッジノードで実現しています。

分散ファイアウォールの仕組み

分散ファイアウォールは、AWSで言うところのSecurity Groupsです。Wakame-VDCのインスタンス(ゲストOS)は、すべてホストOS側にファイアウォールを１つずつ持つ、と言う概念の設計がなされています。このファイアウォールで、パケットの送信元を調べallow/denyの制御をし、インスタンスを安全に保ちます。

実はAWSのSecurity Groupsの概念で一番面白い点は、「End to Endでルールを設定するだけで論理ネットワークが組める」と言う点にあります。

物理ネットワークでは、左図のように仮にフラットなスイッチ構成であったとしても、個々に持つファイアウォールで通信の制御を行えば...

右図のように論理的には直列のネットワークと似た動きを再現することができます。

エッジノードでの制御でも十分ネットワークのパケットフローをコントロールできます。しかもVLANを一切使わずに済ませることができました。
ここまで実装して、この辺りにネットワークの仮想化の未来像がありそうだと社内で議論していました。エッジノードでネットワークを制御すると言う方針はここで決まりました。

分散NATの仕組み

すっかりSecurity Groupsに気を良くした僕達は、IPアドレスの付与にNATが必要で、このコントロールもユーザーに与えようと言う話しになった時も結局分散して実装するアイディアを継続しました。Firewallができるなら、NATもできる、と言う単純な動機です。

WANに出ていくパケットに対し、指定のグローバルIPを付与しなおすと言うだけの仕掛けなのですが、これもインスタンス(ゲストOS)に分散させて配置しました。ここで使ったのは伝統的なNATの技術ですから、VMが送出したパケットを作法を守って変換すれば正しく通信ができるのです。

この実装が終わった時には、Default Gatewayもエッジノードに持って来たら便利だとか議論をしていました。ここまで来たので、エッジノードで全力を出してネットワークのあらゆるものを制御したらどうなるかや、OpenFlowの動向も踏まえて立ち返って整理しなおしました。

今後はOpenFlow対応してネットワークの仮想化を完了させる

僕達はこれらの経験から、次の結論を導きました。

1. VMを使うユーザが意識しているネットワーク体系を使える(=これが仮想ネットワーク)
2. しかしこのパケットはエッジノードで変換され、物理ネットワークを通過する
3. 変換のルールを作るために物理ネットワークはデーターベース化されている
4. 制御範囲である物理ネットワーク の境界がエッジノードであるから、インターネットから出入りするパケットも変換の対象である

そしてこれらエッジノードを制御するソフトウェアがIaaS型クラウド基盤の役目ではないかと考えています。もうVLANも何も必要ありません。L2だけで仮想化できるかも知れません。エッジノードがひたすら賢くなり、ユーザの望むネットワークを受け入れるのです。

こうしたパケットの制御は、OpenFlowの技術が適しています。これまでは同じ目的のためにLinuxに備わっているNetfilterを利用してきましたが、実装に縛られないため標準技術に対応する方が良いでしょう。僕達はNetfilterをOpenFlowに置き換える作業を行います。

今はハードウェアSwitchがOpenFlow対応してきている流れですが、僕達はできるだけエッジノードに処理を持って行きたいので、Switchの動向に現時点ではあまり魅力を感じていません。それよりも、エッジノード上で動くNICがOpenFlow対応するのを心待ちにしています。今はネットワークが1Gb, 10Gbと高速化しており、転送量だけを処理するのでCPUの負担は増え続ける一方だからです。

例えば、ここをサポートしてくれるNIC(クラウド対応NIC?)が出たら僕達は小躍りすることでしょう。
喜ぶのは僕達だけかも知れませんけど、SR/IO-V対応していてその先にOpenFlowで制御できるCPU(GPUっぽいもの?)が備わっているNICとかあと何年かしたら出そうな気がします。

＊言いたいことのまとめ

1. ネットワークの仮想化で
   ユーザ視点のネットワークを自由に用意できる
2. ネットワークの仮想化は
   エッジノードで物理ネットワークに相互翻訳される
3. ネットワークの仮想化のために
   クラウド対応NICの登場を期待してます！

引き続き、もうちょっと丁寧にまとめて行こうと思います。

OpenCloudCampusでWakame-VDCの話【そして技術面補足】

睡眠も準備も不足の状態で参戦。空気読んでテクノロジの話をもっとすべきだった。

Wakame-VDC v11.06 Release on Prezi

ちょっと発表内容とか全然関係なくなるんですが、このPreziってツール面白いんです。
リリースされた時にどこかのニュースサイトで見かけて、良いなーと思っていたところ、iPad版を出す！と宣言されていて、ならばいつかiPadがモニタ出力できるようになったら使おうと思ってたもの。
つい最近iPad2を手に入れて、こいつは外部出力できる！と思ってPreziの有料会員になったりやってみたのです。
ところが、肝心のiPad版のビュアーがAdobe系のフォーマットで差し込んだコンテンツ（背景は実写をベクターに変換してPDFで保存したもの）を表示できないと言うことが分かり、当日はPCでプレゼンしました。くっ…。

Wakame-VDC v11.06リリースしました！

これが一番のニュースです。Wakame Software Foundationのご意見を元に、仮想ネットワークの機能を盛り込んで、更に面白くなってきました。分散NATは以下のように設定します。

$ # Create the inside network
$ ./vdc-manage network add --ipv4_gw 192.168.2.1 --prefix 24

output => nw-5oj1klj9

$ # Create the outside network
$ ./vdc-manage network add --ipv4_gw 172.16.0.1 --prefix 24

output => nw-n9d3tvjv

内外のネットワークを定義して以下のようにマッピングします。

$ ./vdc-manage network nat nw-5oj1klj9 -o nw-n9d3tvjv

これで、nw-5oj1klj9に属するインスタンスは、nw-n9d3tvjvのネットワークからの通信を受けられるようになります。
この vdc-manageは、今回リリースに含めた管理コマンドです。
こんな調子で管理していくことができます。
個人的にはインフラの未来を感じます。
分散NATに代表されるように、分散Firewall (Security Groups)も既に実装されており、L3レベルでのフィルタリングは実現できています。
仮想ネットワークの機能としてはまだやりたいことがたくさんあるので、今年のテーマです。

その他、追加したものとしてはスライドにある通りで、LXC対応でパフォーマンスの良いインスタンスが使えるようになっていたり、外部オブジェクトストレージへスナップショットが転送できるようになっていたりしています。

開発者募集中

ぜひこの辺り興味のある方は一緒に開発をしてみませんか。Twitterなり何なり、ご連絡お待ちしております！

【簡単】Ubuntu v11.04にWakame-VDCを入れてみよう！

まだWakame-VDCを見たことが無い人はぜひ。
VirtualBoxなどでUbuntu v11.04をインストールして、ターミナルから以下を実行してみてください。

$ sudo apt-get install ebtables
$ sudo apt-get install ipset
$ sudo apt-get install git
$ git clone git://github.com/axsh/wakame-vdc.git
$ cd ./wakame-vdc/tests
$ sudo ./vdc.sh install
$ sudo ./vdc.sh

しばらくしてscreenが起動してきたら、ひとまずFirefoxなどで http://localhost:9000/ にアクセスしてみましょう。

起動してきました。この認証画面は、ID/Passwordの順に、demo/demoでログインできます。

Enjoy!

制約

• 【フル機能有効にはなっていない】特にZFSが無いので、Block Storageが有効になっていません。 ボリュームを作成しようとしても失敗します。自動的にダウンロードされるマシンイメージはサンプルです。認証の連携をしません。認証も連携させたい場合は、目的のインスタンスの上で、./wakame-vdc/tests/image-builder 以下のスクリプトを実行してください。 そのサーバーがブート時に連携するよう設定されます。
• 【unstable版】上記方法は安定しない最新版が適用されます。

子会社Axsh North America, Inc.を設立した背景について

無事に米国での登記が完了し、子会社として先週事務所をオープンさせました。
何年か前はRubyなど技術メインのブログだったのに、最近そう言う系の書き込みが無くなってすみません。

今求められるアプライアンス製品を作りたい

日本ではほぼソフトウェア開発ばかりやってきたわけですが、米国では認定ハードウェアセットの構築をして、ソフトウェアをプリインストールし、垂直統合型のアプライアンスとしての事業展開を目論んでいます。
日本でも実現できないか検討したのですが、ハードウェア寄りのビジネスはどうしてもリスクが高いとみられがちで、資金面での支援者を得るのが難しい側面があって、こういうのは実際に見込み顧客のいる場所でやはり自分達の力でやるべきだと判断しました。
僕たちも顧客が居ないのにアプライアンスを作りたいと思っているわけではないので。

ここ３ヶ月間は何度も米国へ出向いて、会社設立準備の他に平行して、顧客とコンタクトを続けていました。
現地のメンバーにうまくフォローされてコミュニティから歓迎を受けました。
本当にありがたいことです。
私は英語が得意ではありませんので、助かりました。

米国子会社の強みであるストレージ技術を活用していく

この辺りは、おおよそ「ソフト担当が日本」で「ハード担当が米国」となっていますが、日本から米国に技術者を派遣してハード対応のためのソフト要員として仕事をします。
米国子会社の強みは実はストレージ技術です。
現地法人のCEOは、元々金融系企業での経験が豊富で、その分野含めストレージについて幅広く熟知しています。
Wakame-VDCのブロックストレージにZFSを採用したのも彼の影響が大きいのです。

彼はストレージアプライアンスが世の中に多く出回っている事は当然良く知っていますし、 だからこそ我々が何をすれば良いのかも分かっています。
元々の日本の強みであるクラウドコンピューティング基盤となるミドルウェアの開発力と、ハードウェア構成が重要なストレージ技術の強みがうまく噛み合います。
このWakame-VDCの未来をワクワクした気持ちで描いているところです。

インターナショナルを意識したワークスタイルへの変化を促したい

ワークスタイルと言う観点では、日本側も社内の共通言語が英語になった点が大きいかもしれません。
元々オープンソースプロダクトを作っている間もソースコードのコメントは英語で書くなど、ある程度意識を持つようにはしてきましたが、今ではバグトラッキングなど米国との共有を図る必要がありそうなものは英語で記述されています。
しかし、実は弊社には正しい英語を話せる人はいません。
伝える気持ちを持って文章を書くという基本はどの言語も同じなのではと考えています。

また、オフィスの時差が10時間ほどあります。
うまく使えば、24時間の有人監視・対応も可能になります。
営業時間の始まりと終わりに少しオーバーラップする時間が作れるので、そこでコミュニケーションができる。
Webカメラと壁掛けテレビを使って互いに接続し「窓」のようにしてオフィスを繋ぎます。

これからはこうした仕事の仕方が当たり前になっていくのではないか、と思っています。
オープンソースプロダクトを扱う以上は、本来世界が相手であるはずです。
世界のどこからでも万人が参加できなければなりません。
こうした動きは日本にとっても大切なノウハウになるのではないでしょうか。
日本は優秀な国で、優れたマーケットですが、世界の一部でしかないのも事実です。

楽しく仕事をするための環境を提供したい

コスト面では、米国現地の生活は東京と比較すると非常に低いのも魅力です。
特に土地代が非常に安く、事務所費も大変ローコストなのに、ゆったり広く利用できます。
ただし、ネットワークの費用だけは日本が遙かに安いですね。

また、今回ドミトリーとして、ベッドルーム、バス・トイレが３つずつ備わっているタイプ(リビングと キッチンだけが共用)の大きな家を用意しました。
東京のワンルームより遙かに大きく、住み心地が非常に良いです。

弊社メンバーは、希望をすれば米国でのびのびと仕事をすることができる。
これは福利厚生としても良いオプションではないか、と思っています。

電力消費量削減を実現したい

今年は地震の影響もあり、日本では電力消費量の削減と言う課題が大きく掲げられています。
米国事務所へ社内サーバを移設したり、メンバーが米国で稼働したりすることによるPC、光熱費の削減が見込めます。
この辺りを意識して夏の前にオープンすることを目標に動きました。

まだ始まったばかりですが、今後もこうした取り組みの手を緩めることはありません。
近々Wakame-VDCの新しいバージョンもリリースをします。
今後も頑張っていきますので、どうぞよろしくお願いします。

クラウドごった煮会(CloudMix)でWakame-vdcの発表をいたしましたので、簡単なまとめを。

気分的に久しぶりの発表。
最近のクラウド動向の一部と言うことでWakame ProjectとWakame-vdcについてお話させていただきました。

簡単にまとめます。

1. Wakame-vdcはIaaSを構築するためのオープンソースソフトウェアです。
2. Wakame Projectには、Wakame-vdcの他、Wakame-os, Wakame-fuelが含まれています。
3. Wakame Software Foundationによって運営されています。
4. Wakame Projectは、世界中のデータセンターを一つのコンピュータにすると言うビジョンの元、それに必要なソフトウェアを開発しています。
5. Wakame-vdcは、ハイブリッドクラウドを構築する足がかりとしてご活用いただくことを想定しています。
6. リソースが大量に必要な部分は、AWSとも連携できるようにしていきます。

Wakame Project in cloud-mix

View more presentations from axsh co., LTD..

Wakame-vdcのリリースと今後の方針について

Wakame-vdcのリリース詳細

先月末(2010/10/29)にWakameTech#3を開催して、ここでWakame-osの話と、ベースとなるWakame-vdcのデモをお披露目しました。

link: Wakame Projectのページ

Wakame-vdcの意義

この辺なかなかご理解いただけないので、補足説明をしておきます。
Wakame-vdcのようなマシンリソースの管理システムは他にも存在します。 EucalyptusやOpenStack、CloudStackなどがそうです。 中には僕たちがこうしたソフトウェアを構築している事に対し、なぜ既存のものがあるのにそれを使わないのか、グローバルに展開しているソフトウェアに参画する方が良いのではないかなどご意見をくださる方もいらっしゃいました。
しかし、実際に僕たちがやりたいのはこの上のレイヤなのです。 この上のレイヤには、Wakame-osや、かつてのWakame-fuelがあります。 これが実現できると、今言われているWeb系システムの管理が大きく変化し、確実に便利になるのです。
実現するにあたって、一部Wakame-vdcのレイヤで対応しなければならない機能がどうしても出てきます。 だからこそ、その部分を誰かに頼っていてはいけないと思うのです。 実用性を証明し、それを他のクラウド事業者にご理解いただきたい。 そう考えています。

プロジェクトの再整理をした

2010/4にWakame-fuelをリリースして、外部状況が大きく変化する中、私がここ数年間の流れとして一番信じているのが「AWSのような大型データセンターと、企業特化型のデータセンターが連携・補完しあってエンタープライズサービスを形作る」と言うもの。 その流れの中で、足りないのは「企業特化型のデータセンターの基盤ソフトウェア」と、「連携・補完しあうための仕組み」なんだと思っています。この辺りはすでに結構色々な方が指摘している流れではないでしょうか。
そこまで腹をくくって、連携や補完について技術動向など踏まえて方向性をまとめまして、それをWakame-osより上の層と定義して着手することにしたのです。
しかし、実際連携と言う橋を掛けるには、出発点と到着点の２つが整備されなければ意味が無いわけです。 僕たちは出発点をWakame-vdcに託し企業内でご利用いただきながら、到着点としてAWSなどの大型データセンターサービスを見据えて行こうと、現時点ではそう考えています。

僕たちは2009/11頃からWakame-vdcの開発に着手することになりますが、その前にもWakame-vdcではなく上のレイヤへ進むかという検討と議論はありました。当時はAWS一択に近い状況で、プラットフォームとして決め込むにはやや絞りすぎている感は否めず、それで基盤技術となりそうなEucalyptusに注目するようにはなったのですが、コードを読んでみるとどうも方向性が違うと感じました。
僕たちが欲しかったのは、「上の層」の要求に対し変化できる「アジリティ」だったので、AWS互換は大げさでしたし、アーキテクチャや開発体制などがそれに応えられないと思いました。 色々調べましたが、案外シンプルで良さそうなものが見当たらず、結局作ることにしました。 仕組みはWakame-fuelとほぼ同じRuby+AMQPで行けると踏んで、検証コードなどいくつか試して実際の開発に乗り出します。 そして2010/2に動き始め某iDCの環境にて検証可能になり、色々あって2010/4にひっそり公開しました。

シンプルな基盤としてスタートし、実際にWakame-fuelの検討に入り流れの中で、一度根本的に見直しして、当初掲げていた設計思想に立ち返ってもう一度整理し直しました。 そこで出て来たのが、Wakame-osの概念です。
その検討中にも色々状況も変わり、Wakame Projectそのものを再度捉え直さねばならないタイミングが来ましたが、これも結局「上の層」がますます大切になったと言う結論です。 シンプルな基盤だったWakame-vdcも、色々な方々とお話しながらある一定の機能は必要とされてきたので、大きく機能拡張して2010/11/19リリースの今に至ります。

これからは、Wakame-vdcの機能拡張と、いよいよ「上の層」を攻めて行きます。ご期待ください。 

Wakame-osのリリースとその詳細

今回、Wakame-osなる物をリリースしました。
これはニーズから見た世界ではなく、日頃感じていることをまとめて形にする流れで生まれたプロダクトです。

require 'wakame'
process = WakameOS::Process.setup(:credential => {:user => 'your_name'})
process.fork {
  print "Running code on the remote!\n"
}

少し分かりづらいかも知れませんが、端的に言うと上記コードが動くものです。
特筆しなければならないのは、forkに付与されたblockが、新たに用意されたインスタンスの上で実行される、と言う点です。
このように、インスタンスの管理を、LinuxなどのOSが管理するプロセスのそれに近づけてみました。
ただし、この管理レイヤはいわゆる単体のマシン上で動作するOSを越えて動作するレイヤですので、僕たちは勝手にメタOSと呼んでいます。

Googleクラウドの核心
著者：ルイス・アンドレ・バロッソ、ウルス・ヘルツル
日経BP社(2010-08-05)
販売元：Amazon.co.jp
クチコミを見る
 上記書籍の原文(英語)では、このメタOSが動作するような環境を、Cluster Level Infrastructureと呼んでいて、Wakame-osはまさにこれのためのOSと思って作っています。

Wakame-osには大きく３つの特徴があります。

(1) 従来のプログラミングテクニックのまま、CPU資源のとらえ方に変化をもたらすことができる

従来のforkは同一OS内にプロセスが起動するものでしたが、今回のforkはOSを越えて、サーバとしてプロセスが起動するものです。
前者がやればやるほどCPU資源が分割されていくのに対し、後者はCPU資源が増設されていくように見えます。

まだオモチャのようなものですが、実態はforkによってサーバに処理を動的分散させると言うものです。
モンテカルロ法による円周率の計算などは、この仕組みで簡単に書けるようになります。
円周率の計算はHadoopの処理例にもなっていたりするのですが、インフラを用意し、アルゴリズムを変更してまでして実行する必要がありません。
単純にforkすれば良いので、バッチ処理などでも対象となるデータを単純に分割して並列処理させることができます。
MapReduceという仕組みにどう合せるかを考えるよりシンプルだと思いますし、実質そのレベルでバッチ処理が高速化したいと考えるケースの方が多いのではないかな、と思っています。

(2) 従来の管理方法でクラウドにアクセスできる

システム管理者はキーボードをマウスに持ち替えたくて仕方がないのではありません。
psコマンドやkillコマンドなど、慣れ親しんだCLIベースの操作を失わないことと、自分の仕事を手早く片付けるためのスクリプトが書ければ良いのです。
僕が従来からGUIはさほど重要ではないと思っている理由でもあります。
Wakame-osにはこれから機能を補っていきますが、ps/kill相当のコマンドが提供できます。
プロセスもそう管理したように、サーバも同じ手法で管理します。

実際現在のLinuxサーバ１台には100個ほどプロセスが起動しています。
同じ文脈が提供できれば、100サーバも管理できると踏んでいます。

(3) 設定でハイブリッドクラウドとして機能させることができる

この単純な理屈はAWSの他にも、AWSほどの機能を持たない異なるクラウド間でも共有しあえる物です。
forkする際には論理名を与えることができるので、論理名に紐尽くサーバの設定ファイルを記述しておくだけで、その処理は適宜任意のクラウド上で動作させることができるようになります。

例えばAWSにはHPC用のサーバがありますし、他のクラウドだとディスクI/Oが良いなど、価格面も含め個性があります。
使うサーバを設定ファイルとして別に記述できれば、高い柔軟性の確保と、動いているプログラムに与える影響を最小限にできます。 

今のところはそんな狙いを持ったものです。
開発者募集中です。 

献本していただきました。「よくわかるAmazon EC2/S3入門」

よくわかるAmazonEC2/S3入門 ―AmazonWebServicesクラウド活用と実践 (Software Design plusシリーズ)
著者：藤崎 正範
技術評論社(2010-06-11)
販売元：Amazon.co.jp
クチコミを見る

かなり前に献本いただいたのですが、読む時間が取れなかったので今更かもしれないと思いつつもレビューします。

クラウドという単語は最近少しずつ理解されつつあって、その定義について議論になることは少なくなりましたが、 そこをさらに一歩押し進めて、きちんと「実践して感じてみることができる入門書」だと感じました。
その分野を試すに当たって、良い入門書に出会うことができるかどうかは技術者にとって大きなテーマだと思います。

本書はその中でもいわゆるガイドとして最適な構成になっています。内容は詳細で、まさに入り口から運用まで手広く書かれていますので、あとはクレジットカードだけ準備していただければ今スグにでも試してみることができるのではないでしょうか。
途中に楽しいマンガも入っていて、読み手に深呼吸を与えてくれる点も見逃せません。

AWSはもはや「やったこと無いんですよね」と言えなくなってきています。
良い機会ですから、ぜひクラウドの世界に飛び込んでみてはいかがでしょうか。

[Wakame] AWSのユーザグループ会でLightning Talkして来た。スライドも少し修正して公開します。

無謀だった。よく考えたら５分で２トピックだものね。片方に注力すべきだった。

Wakameのアップデート

簡単にWakameの説明と、実績の情報しかなかったのですが、東芝様でWakameが使われている件に関しては、僕が考えていたよりも大きな反響があることを初めて実感できました。次はプロダクトについてのアップデートが話せるようにしたいです。

Amazon VPCをやってみた

これも密かに実績のある話しなんですが、詳細はお伝えできないので、VPCとしての一般論を発表してみました。 TwitterのTLでは色々突っ込みがあり、議論を呼び、プレゼンして良かったなと思っています。 VPCの問題点とか言うところで５分タイムアップとなり終了。 続きは懇親会で…と言うことになり、むしろ２度も発表させていただく流れになりまして、不手際の結果であるくせに厚かましくてすみません。

僕たちはもっとコンピューティングの未来を語った方が良い

色々お話させていただきましたが、ここ最近の結論はAPIの有無なんですよね。ホントに。その話しもそうなんですが、個人的にクラウドコンピューティングの先はこうなる！とか勝手に色々思っているので、技術者同士で一度大風呂敷を広げる会をやってみたいなと考えています。きっと世の中の技術者みんなが、ある程度のコンセンサスを持つと、世界は大きく変わると思うのです。

経営者や営業の方からは「技術者っていつも目先の面白いものに飛びついているだけだ」と見られることもしばしば。人間力は否定しませんが、技術こそが世界を動かす原動力でもあります。僕たちはもっと自信をもって未来を語って良い、そう思うのです。

賛同者はTwitter @sparklegateまでご連絡ください。

当日のスライド

JAWS-UG Lightning Talk 2010-04-07

View more presentations from Yamazaki Yasuhiro.

2010上期針説明、自分たちのアイデンティティは何かを考える

久しぶりにブログを書く。
弊社2月末締めで、3月から5期目に入りました。

１ヶ月遅れてやっと2010年の上期方針説明を行えた。

平たく言うと、あくしゅはOSを作るんだ、というビジョンを出した。
我々はもっとコンピューティングという姿に立ち返り、ネットワーク型アプリケーションという物が記述できる仕掛けを提供しなければならない。
それには今のAmazon EC2の仕組みがぴったりかと言うとそうでもない。
途中までEC2などは便利に使っていくとは思うのだけれども、これは最終的には自分たちで全てを取りそろえないことには、実現できない仕組みなのです。

正直、僕だけがワクワクしていても仕方ないので、これをメンバ全員と共有して、みんなで未来を作って行けたらと思っているところ。

メンバが2名増えました。

嬉しいことに、新規メンバが2名増えた。
以前はアルバイト抜きの正社員で7名だったので、それが9名になった。
特に1名は社会人になってからずっとお世話になっていた方で、ご自身から是非とご提案いただけたりするなど、願ってもいないことです。

今体制を組み直し、ちょっと大変だけれども、今年の目標に向かってどんどん進んで行けたらと思っている。
皆様今年も宜しくお願いいたします！

[Wakame] IaaSを本気で作る会のスライド(内部構造について)がアップされました

以前、IaaSを本気で作る会を開催した際に、Wakame 1.0(当時)の内部構造について色々発表して下さった登尾さんのスライドがアップされています。
直前に僕が発表した内容を踏まえて作ってくださいましたので、分かりづらい単語についてはそちらを一度ご覧ください。

色々議論して作った結果だけれど、こうして見てみると面白い仕組みになったなー、とか思います。

[Wakame] IaaSを本気で作る会のスライドをアップしました！

当日発表の資料(1/30の出来事)

その日にお集まりいただいた方々は皆様やはりこの手の動きに注目なさっている方ばかりで、懇親会も相当濃い感じでした。仮想化と言ってもサーバの仮想化ばかりに注目されていますが、その部分は比較的簡単なんです。実際はネットワークの仮想化が大きな課題になります。そして良い解決策が見当たらない部分なのです。

デモンストレーションはわかりにくい感じになりましたが、ネットワークの問題を無視すればIaaSは簡単に作れてしまいます。ちゃんとインスタンスも起動してきましたし、SSHでログインすることもできる。Web APIだって付いていて動いているわけです。

今後の課題は、ひたすらネットワークの課題解決を進めることと、管理ツールの充実を図ることでしょう。リリースは最低限デモでお見せしたレベルのものが動くところまで整えて出したいと思っています。

Wakame Tech #1

View more presentations from Yamazaki Yasuhiro.

「WakameTech #1 そろそろ本気でIaaS型クラウドを作る会」 やります。

IaaS型クラウドを本気で自作しよう！

待っていてもなかなか日本のデータセンタからAmazon EC2のようなIaaS型クラウドが出てこないので、そろそろ作ってみることにしました。
Eucalyptusを使うという選択肢で頑張っている方がいるのは知っているのですが、Amazon EC2と互換する意味があまりない(ツールやAPIのナレッジは貴重だとは思います)ので、 スクラッチから作ることにしました。

これら試行錯誤の結果を他の技術者と共有したい、そんな思いで立ち上げたカジュアル勉強会です。
ぜひご参加くださいませ！

WakameTech #1 - そろそろ本気でIaaS型クラウドを作る会

管理機能とかもう作りたくない時はGoogle Spreadsheetsに逃げる

応募フォームを作ったりアンケートを取ったり、その度にアプリケーションを開発するのは面倒なので、Google Spreadsheetsを使うことにした。
しかしどうもGoogle Formとか言うのは使いづらいし、もうちょっと何とかならんかなーと思ったので試作してみた。

こんな感じ

↑管理者は空っぽのSheetを開いてじっと見ています。

↑利用者は管理者が設置したサイト上にあるこんなhtmlに適当な値を入れてSubmitします。Submit後、利用者は「ありがとうございました」ページを見て立ち去ることでしょう。

↑管理者は、その値がシートにスポンと入るのを目撃します。自動更新されるみたいです。良くできてる…。

こんなのを作ろうと言うわけです。
調べていたらGoogle SpreadsheetsをActiveResourceのように扱う素敵なコードを発見したので利用することにしました。コードもまとまっていて、使いやすさも良かったので、即決。

やることは3ステップ。

1. Google Spreadsheetsに格納先シートを用意する
2. htmlを用意する
3. Controller(Rails)を用意したりする

 

Google Spreadsheetsに格納先シートを用意する

これは簡単。Spreadsheetドキュメントを作成して、Sheetを使うだけ。Excelを知っている人なら説明なしにやれるでしょう。1行目に欲しいデータセットのカラム名を列挙していきます。
今回は hoge, fuga, moke, created と書いてみました。
ちなみに、Web API経由だとアンダースコアは指定できないようなので、英数字だけでカラム名を付けると良いと思います。

htmlを用意する

app/views/gss/form_sample.erb

<html>
 <head>
  <title>Sample Form</title>
 </head>
 <body>
  <form method="post" action="append">
   <%= token_tag %>
   <input type="hidden" name="target_sheet" value="sample" /><!-- シートの指定 -->
   <input type="hidden" name="thanks_page" value="thanks_sample" /><!-- 画面遷移先 -->

   <!-- gsx_* はカラム名に対応する -->
   <input type="text" name="gsx_hoge" value="" />
   <input type="radio" name="gsx_fuga" value="A" />
   <input type="radio" name="gsx_fuga" value="B" />
   <select name="gsx_moke">
    <option value="OPT1">OPT1</option>
    <option value="OPT2">OPT2</option>
    <option value="OPT3">OPT3</option>
   </select>
   <input type="hidden" name="gsx_created" value="auto" /><!-- オマケ機能(後述) -->
   <input type="submit" name="go" value="submit" />
  </form>
 </body>
</html>

Controller(Rails)を用意したりする

app/controller/GssController.rb

require 'ares_google_spreadsheets'

class GssController < ApplicationController
  include Environment
  def method_missing(method)
    if(method.to_s.match(/(form_.*)|(thanks_.*)/))
      filename = params[:controller]+'/'+method.to_s
      render :file => filename, :use_full_path => true
    else
      raise NoMethodError.new(method.to_s)
    end
  end

  def append
    GoogleSpreadsheets::Base.user     = Settings.credential[:user]
    GoogleSpreadsheets::Base.password = Settings.credential[:password]

    records = {}
    params.each { |key, value|
      name = key.to_s.match(/gsx_(.*)/)
      if name
        method = Settings.auto_insertion[name[1]]
        value = method.call(value) if method
        records[key] = value
      end
    }
    target_sheet_key = params[:target_sheet]
    raise MissingParameterError.new('Please set \'target_sheet\' value in your html.') unless target_sheet_key

    target_sheet = Settings.target_sheet[target_sheet_key]
    raise TargetSheetNotFoundError.new('Please check Environment.target_sheet values.') unless target_sheet
    raise TargetSheetNotFoundError.new('Please check document_name and sheet_name in Environment.target_sheet.') unless
      (target_sheet.has_key?(:document_name) || target_sheer.has_key?(:document_id)) &&
      (target_sheet.has_key?(:sheet_name)    || target_sheet.has_key?(:sheet_id))

    doc_id = target_sheet[:document_id]
    if !doc_id
      docs = GoogleSpreadsheets::Spreadsheet.find(:all) || []
      docs.each { |doc|
        if(doc.title==target_sheet[:document_name])
          doc_id = doc.id
          break
        end
      }
      raise DocumentNotFoundError.new("document_name '#{target_sheet[:document_name]}' is not available.") unless doc_id
    end

    sheet_id = target_sheet[:sheet_id]
    if !sheet_id
      sheets = GoogleSpreadsheets::Worksheet.find(:all, :params => {
        :document_id => doc_id,
        :visibility  => 'private',
        :projection  => 'full'
      }) || []
      sheets.each { |sheet|
        if(sheet.title==target_sheet[:sheet_name])
          sheet_id = sheet.id
          break
        end
      }
      raise SheetNotFoundError.new("sheet_name '#{target_sheet[:document_name]}' is not available.") unless sheet_id
    end

    new_row = GoogleSpreadsheets::List.new({
      :document_id  => doc_id,
      :worksheet_id => sheet_id,
      :visibility   => 'private',
      :projection   => 'full'
    }.merge(records))
    new_row.save

    redirect_to :action => (params[:thanks_page] || 'thanks_default').split(/\./)[0]
  end

  class MissingParameterError < StandardError; end
  class TargetSheetNotFoundError < StandardError; end
  class DocumentNotFoundError < StandardError; end
end

config/environment.rb (設定ファイルなので、場所はenvironment.rbじゃなくても良いです)

require 'time'

module Environment
  class Settings
    def self.credential
      {
        :user     => '[e-mail]',
        :password => 'secret_password',
      }
    end
    # formのtarget_sheetに指定されるもので、シートを特定する設定を書きます
    def self.target_sheet
      {
        'sample' => {
          # 名前で指定する場合は以下を指定
          :document_name => 'Sample Sheet',
          :sheet_name => 'Sheet1',

          ## もしIDが分かっている場合は以下を指定
          ## 検索クエリを出さない分、高速です
          # :document_id => '...',
          # :sheet_id    => '...',
        },
      }
    end
    def self.auto_insertion
      {
        'created' => Proc.new { Time.now.rfc2822 },
      }
    end
  end
end

オマケ機能の説明

htmlでgfx_createdなどカラム名が指定されると、それに対応するProcが起動して値を自動的に上書きする機能が付いています。
例えば記録時間とかそのタイミングで決まるものなんかはここに定義しておけば良いかも。

あと、viewの命名規則があって、form_*.erbとthanks_*.erbは用意さえすればGssControllerが勝手に表示します。

欠点

サーバサイドで入力チェックを全くやっていないので、その辺機能不足です。値はGoogle Spreadsheetsにそのまま渡されるので、文字の最大長はそこで決まります。その他セキュアじゃないとか何かありそうなので、本気で使おうと思っている方は十分な検証をお願いします。

「フリー」を読めばWakameがフリーな理由もわかるはず

Wakameも「フリー」です

Wakameの説明をしているとたまに「Wakameを無料で配布してしまって、御社はどこで儲けるんですか？」という質問をいただくのですが、この書籍「フリー」をご覧いただくとわかるかもしれません。大体この本に書かれているモデルはうちの会社も似た感じなんです。

今年4月にリリースして以来、Wakameは各方面より色々な反響をいただきまして、おかげさまで年度内は殆どがWakame関連のお仕事で埋まりました。
リリース前には社内で何でもフリーにして良いのかと言う議論もあったのですが、僕個人的としてはプロダクトとしてフリーでやっていくことに疑問はありませんでした。 その辺り勘ではなく論理的にきちっと書かれた本が「フリー」なんだと思います。

Wakameは、全社員たった7名のうち、もっと言うとその内数名のプログラマによって生み出されているプロダクトです。そんな弱小集団が取れる戦略はフリーしかないってのも事実なんですよね。

クラウドを実現する技術とか言われたら期待しちゃいます

よーし、これでクラウドを実現しちゃうぞ〜！って本ではない

勝手に期待して読んだ方が悪いのかもしれないけれど、タイトルを見たら誤解しちゃう。クラウドというキーワードの周辺で目立った要素技術をピックアップしている紹介本。
酷評かもしれないけど、この本に書かれているのは要素技術としても本当に導入だけ。実現できるとかありえない。肝とも言えるネットワーク周辺の話が丸々抜けているのが痛い。

でも良いところもあります。プロセッサの仮想化については良くまとまっていますので、ここらを一度振り返ってまとめておきたい人にはお勧め。

あと、どうしても技術用語が5年くらい古いのが気になります。

これさえあればAmazon EC2/S3の活用で困らない！どんな人にもぴったりな本

たまに「Amazon EC2/S3って実際運用してみてどうなの？」と問われることがあります。

これからはそんな質問も減る！そう感じさせる本に出会いました。

最近出たAmazon EC2/S3関連の本の中では最も「運用」についてしっかり書かれている本です。
 

入門から実運用まで、これほど幅広く書かれているにもかかわらず、構成も文章もすっきりまとまっていて無駄がないのも素晴らしいところ。

実際にEC2/S3で動くシステムを作ってトラブルを恐れずに切り込んでいった人の生々しさがエッセンスとして随所に散りばめられており、知っている人が読んでも楽しい。

もし近場のお客様などでEC2/S3に興味を持っていそうな方がいたら、まず迷わずこの本を教えてあげて下さい。

聞きたいこと知りたいことが漏れなく詰まった一冊です。

時にはもっと気合いを入れてTwitterで発言することも大切だから、ブログを併用して解決することにした。

Twitterの危険性

お会いしたことはないのだけれど、小野さんと言う方が「Twitterは気軽にOutput可能にしてしまうため、そこから先を深堀する前に終わることが多いのでは」と言うようなエントリを書かれていた。 ふむふむなるほど、と思ったので僕もエントリしてみる。

僕も最初はアカウントを取って放置しておいたTwitterだったけれど、最近少しずつ使い始めていて、手軽さが気に入っている。 それと同時に、ブログのエントリが減ったのも事実だ。 そろそろ気合いを入れるべき発言をきちんと見極めないとなー、と思う。

気合いを入れて140文字で発言するためにBlogを使う

最近はlivedoor Blogに記事を書いたらTwitterに発言する、という機能がついている。 これを活用するのがよさそうだ。 140文字で発言されるのはブログのタイトルだ。 あたかもTwitterで発言したようにして、そのつぶやきを補ったり深堀したりするためにこの機能が使えそう。

スパコンの研究費は削減せず、むしろ防衛費に振り替えるってのはダメ？

なんだか事業仕分け(笑)が話題になって、スパコン切られそうだとかネットでニュースになっていますね。 あまり軍備としてのコンピュータについて触れている人がいないのでエントリを残してみます。

スパコンは気象予報などのシミュレーション分野では役に立っているのは有名です。 それ以外にも暗号技術の世界では解読に使えるコンピューティング能力の向上が非常に脅威ですから情報戦時代には必要だと思います。 そう言う意味で僕はスパコン開発は手を止めるべきではないと思う。 防衛省に移してでもやるべきだと考えます。

海外から買ってこい！日の丸印に意味は無い！CPUから設計している時代じゃないんだよ！なんて言っている人もいるけれど、上記理由で輸出しないって言われたらおしまいじゃないのかな。
調達が不明瞭だとか言うならならそこを正せばいいし、目標を達成できるとは思わないという意見もあるが、それは削減理由ではなく、むしろ大いにやるべき理由ではないか。 自分で稼いでその金でやれ、と言う意見もあって民間ではごもっともなんだけれど、僕は防衛費的な意味合いを考えると稼ぐためにやる研究ではないと思う。

Wakame 1.0開発者の募集を締め切りました。

Wakame 1.0開発者へのご応募ありがとうございました

おかげさまで2名のご協力者を得て、現在開発スピードが加速しております。
WakameはこれまでEC2上でスケールアウトするオートメーションを実現してきましたが、Wakame 1.0ではこの役割を根本的に捉えなおし、EC2はもちろんのこと、EC2以外のホスティングサービスでもスケールアウトするように改良中です。

もちろんこれにはデータセンタ側でもやるべきことがあります。
Wakame 1.0ではデータセンタで供給すべきスケールアウトのためのインフラからユーザアプリケーションまで垂直に提供できるようになる予定です。
すべての開発者に、開発時から使えるプログラマブルなデータセンタと、運用を楽にするシステムオートメーションを。
お楽しみに。

[Wakame]Wakameの開発にご協力くださる方を探しています

■急募："Wakame 1.0"開発協力者！

株式会社あくしゅでは"Wakame 1.0"の開発者を募集しています！
Wakameは次世代データセンターには欠かせないクラウドコントローラとして、今後大幅に機能拡張していきます。
Rubyでミドルウェアを開発してみたいという意欲あふれる方は是非お問い合わせください。

■仕事内容

1. "Wakame 1.0"の使用目的を拡大するために、ミドルウェア部分の機能拡張を実施
2. "Wakame 1.0"を使いやすくするために、GUIの追加開発を実施
3. "Wakame 1.0"を分かりやすくするために、ドキュメントの整備を実施

上記の内、得意なもの１つ以上をお願いすることになります。

■募集要項

• 下記(A)(B)(C)の知識・技術セットをいずれかお持ちの方
  1. Ruby, 現在のWakame, メッセージング, 並列処理, Xenなどのハイパーバイザの知識
  2. JavaScript, XHTML, Ruby on Rails, http通信(REST), ユーザビリティ, 画面設計の知識
  3. HTML, ドキュメンテーション
• システムの設計が得意で、オブジェクト指向を理解している方
• 人とのコミュニケーションが好きな明るい方
• 期間：2009年11月初旬〜2010年3月下旬

■条件

応募期限は10/26(月)までです。
それ以降10/30(金)までに一度仕事内容や関わり方をミーティング形式でご相談させていただきましてその後、弊社基準で判断してからお見積もりをお願いします。

■一言

設立３年目の若い会社です。
来年からは「世界のクラウドソリューションを」をテーマに事業展開していく予定です。
そのために今後は弊社で開発している"Wakame"を機能拡張し、より高度なプロダクトへと躍進させていきます。
あなたもぜひ、この新しいチャンスに乗ってみませんか？

■連絡先

Twitter: @axsh_co_ltd
E-mail: r_at_axsh_dot_net (_at_と_dot_は適宜文字列を置換してください)

なんでクラウドのデータは消えてしまうん？←節子…それ、クラウドやない

クラウドにデータを預けて大丈夫なのか？という議論がたまにあるけれども、僕はそんな議論をするより、データを預けて大丈夫なものをクラウドと呼べば良いだけなのに、と最近思う。
近頃の「クラウド」という言葉は、技術のコモディティ化が進行していることを良く表した生きているバズワードであって、コンセンサスが有る部分と無い部分を混在させた状態にあるのは間違いない。
僕がこのエントリで言いたいのはそのコンセンサスの中に「データ消失対策が十分に練られたものをクラウドと呼び、そうじゃないものはクラウドと呼べない/呼ばない」という点を追加できないかなぁと言うこと。

今週ちょうど厄介なニュースが飛び込んできた。

ネット史上最大の惨事のひとつ発生―Microsoft Danger、T-MobileのスマートフォンSidekickのユーザーデータのすべてを失う

悲しい事に、このニュースは「クラウドの弱点」だとしてコンセンサスを形作ってしまうかも知れない。はてブではクラウドというタグが付いたり、クラウドにネガティブなコメントもある。
それはそれで良いんだけれども、細かいがどうも釈然としない点がある。
今回はそれを問題にしてみたい。

T-MobileとMicrosoft Dangerが何重にもバックアップを取っていなかったことについて弁解の余地はない。特にSidekickはローカルの端末にデータを記録せず、すべてをクラウドに保管していたのだからなおさらだ。

ネット史上最大の惨事のひとつ発生―Microsoft Danger、T-MobileのスマートフォンSidekickのユーザーデータのすべてを失う

この引用で問題にしたいのはこのDangerのバックアップの仕組みについてではない。もちろんニュースになるような事件はあってはならないし、擁護するつもりはない。ただ、実際にどのような仕組みがあって、どう言った事情が背景にあるのかも良く分からないので、外から推測で指摘できることはない。

僕がこの場で問題にしたいのはこの記事にサラッと書かれた「ローカルなどクラウド以外のコピーを持っていないことは落ち度である」と暗に指摘している点だ。
はて、本当に「ローカルの端末にデータを記録」することがバックアップの防衛ラインとして重要なのだろうか？この発想こそが旧世代的で、いつまで経ってもクラウドにデータを持って行けない元凶であると思う。
そもそも、データストレージ型のクラウドの中で幾重にも防衛ラインが敷かれていれば、ローカルのバックアップなど本来は必要なくできる。そうするのがストレージとしてのクラウドの役目ではないだろうか。
ローカルにある使い古された故障ロットかもしれないHDDにコピーしてバックアップをした！と得意げに叫ぶ方がバックアップをなめているとしか思えない。RAIDで持てばいい？世代バックアップすればいい？メディアへの書き出しもしている？風化・劣化しないように暗室に保存している？違う違う、それは「クラウドが無かった時代にやらなければならなかった事」なんじゃないの？そう言いたい。

ストレージの標準APIに望むこととして、またこんな変な指摘が出てくる。

利用者側でバックアップをローカルや別のクラウドに持っておくなどの柔軟な操作が（実際にユーザーが行わないとしても）可能になっていることが望まれます。

クラウドストレージの標準APIがストレージ団体「SNIA」から提案される

僕は必要ないと思います。

それより、どのようなバックアップ手法をとっているのかが分かるとか、何か数値的な指標が出せる運用を宣言できていればいいんじゃないでしょうか。SLAみたいに。

ネットに必要なのは匿名か実名か

ネット上でも実名で表現を

少なくとも人とのつながりを目的とした利用においては、できる限り実名を明らかにするのが好ましい

上記は勝間さんの提案ですが、個人的にはほぼ反対。どんな場面においても匿名にする自由はあって然るべきです。
既存メディアと同等の信頼を得るために発信される情報は実名にしろなんて話にはならないでしょう。既存メディアだってうまく匿名を使い分けている。新聞記事にだって社名以外のクレジットが無いものがほとんど。芸名で通す芸能人が宗教にも使われている。実名というのが信頼を得たり失ったりする役に立っていない証左ではないだろうか。何かの影響は有るかも知れないけれども。

僕が実名でやりはじめた理由

それが最初の商品だったから、かな。
独立して仕事を始めましたとか言っても、何か売れるものを持っていたわけでもないし、何もないから名前でも出しておくか、ってただそれだけ。
学生時代も山崎という名前だし、前職でももちろん山崎だし、それなりにその名前で名刺を配ってきたりもしていたわけです。
どこぞの一社員として見られるのが大方とは言え、中には社名ではなく僕の名前を見てくださる方もいらっしゃるのではないか…そんな淡い期待があったに過ぎません。ちっぽけな「山崎泰宏」というタグがどこかに付いていたら良いな、と。

そう言う意味では、名前のユニーク性も大切かも知れない。ググると僕以外の「山崎泰宏」が何名か存在する。匿名というか偽名が許されるのであれば、ネット上では少し文字った名前でやっとけば良かったかなーなんてふと思うことがある。

実名で何か良いことあった？

音信不通だった大学時代の友人がメールをくれた以外、実質的には良いことは無いかも。

クラウドって何ですか？と聞かれた時の答えを１つ

最近、色々な人から聞かれるので、専門家ではないけれども僕なりの答えを述べておきます。身も蓋もない表現ですが。

クラウドとはネットワークコンピューティングのコモディティ化が進んだことを表す言葉

いきなりごめんなさいだけど、これに尽きると思います。

クラウドって別に新しい技術ではなく、既存の技術を高度に組み合わせてできたネットワークコンピューティングの体について、そろそろ何か名前付けとかないといちいち面倒だぞ、ってタイミングで出てきた、ズバりピタッとくる「ちょーどいい言葉」なんだろうなと思うんです。

Wakameを世に出してから、色々な方々とお話し合いさせていただきました。
技術的にクラウドを理解しようとする人や、物事の解決へのアプローチ・考え方からクラウドと言う言葉を使う人、ユーザの立場や世の中へのインパクトからクラウドを理解している人、様々な人がクラウドという言葉を使っています。
本当に良くできたバズワードなのです。
今この世の中がどのような技術を使っていて、それらが何を提供しているか何のコンセンサスもないのにクラウドという言葉を便利に使っていて、それなりに意味を通じさせてしまっているわけですね。

元々、"コンピュータ"という言葉そのものも最初は計算する「人」を表していた言葉だそうです。かつての"コンピュータ"は今とは違って、チューリングマシンでありノイマン型であり(おじさんにとっては)IntelでありWindowsでありExcelやWordまで想像させるような言葉ではなかったはず。

これまでも、コンピュータが高度にネットワーク化されたこの現状を、WebサービスだのASPだの色々な言葉が説明しようと試みられたわけだけれど、どこかそれそのものを具体的に言い過ぎている部分と足りていない部分があって、何だかクラウドって言う「間違っていないし、難しくもない抽象的な表現」を引き合いにしたら、それが「現代のコモンセンスで理解できた」と。
そう言う意味で、これを言い出したエリック・シュミット氏は天才を超えた天才だと思う。

クラウドに踊らされるな！昔からあった！我々も主張していた！と言う人々

恥ずかしいから止めた方が良いと思うんだよね…。踊らされるな！って言うと警告めいてはいるけれどもその反面、世間があなたの知識に近づいて来たのを恐れているようにも見えるし、昔からあった！なんて言っても認知されなきゃ無かったのと一緒だろうし、我々も主張していた！って言うと更に悪くて「じゃあ最初からクラウドって言えばいいじゃないか」って話にもなるんじゃないだろうか。

そう言う意味で、やっぱり良くできたバズワードだし、意味が通じるという側面は、ネットワークコンピューティングの複雑な技術がそれなりにコモディティ化した結果なのだと思う。

社内で下期方針を出しました。

社内で下期方針をプレゼン

売上伸ばして行こうという話に始まって、そのために何をすべきか、どこ目指すべきか、各々何をすべきかについて述べた。来年のWakameが進むべき道を描いて下期の成長戦略を企画したレベル。いつものことだが、この戦略もある部分では当り、ある部分では外れるはず。そうやって当たり外れが見えるだけでもマシだろう。

収益をどう上げるかって言う話も当然難しいんだけれど、お金の使いどころって言うのはもっと難しい。ひとまず、会社がどう維持されるのかについての計画があって、使って良いであろう予算と必要そうな経費とを相談しながら決めている。

何となくではあるが、結構独断で決めちゃったりもしたので、今後はきちんとその計画に沿って進めていかなければならない。

あと最近、資本政策やらベンチャーキャピタルについての本を何度も読んでいるので、「何？IPOしようとか思ってるの？」なんてからかわれているのだけれども実は理由は逆で、どうしてみんなIPOを目指すのだろうかと。それについて理解しようと思ったのがきっかけ。

でも読めば読むほどやらない方が良い気がしてくる。まだきちんと理解できていないのが理由なのだろうが、株というのは未だにどうも気持ち悪い代物で…。

そのうち、やりたい人が出てきた時にその理由が理解できないと困るので、もうちょっと粘って読んでみることにします。

[Wakame]Wakame 0.5.0リリースしました！

Wakame 0.5.0のリリースです。1ヶ月半ぶりなのは、Wakameの実案件が複数同時に進んでいてリソースを集中させることが難しく、そんな僕の采配の悪さのせいで開発が当初ここまでと決めたところまでなかなか進んでいません。申し訳ないです。

新機能：Wakame Masterが吹っ飛んでも復帰させられるように！

Wakame Masterの状態をDBに持つようにしたことで、途中で吹っ飛んでもDBに書かれたその状態から再開できるようになっています。今まで完全にオンメモリで動いていたので、そこを全面的にDBへシリアライズするよう書き換えられています。（最初からそう作れよって突っ込みはごもっともです…。）

目標：下期はWakameの開発にもっと力を入れたい！

最近、Wakameのロードマップが公表されていない点や、ドキュメントが不足している点を指摘されます。お問い合わせいただきました皆様本当にありがとうございます。

Wakameのあるべき姿として目指している画はあるものの、実績となる実案件も面白いので、ついついその対応で計画を流動的にしてしまっているだけなのです。プロダクトにご注目くださっている方にはとても申し訳ないと思っております。

下期はWakameと言うプロダクト開発にもっと注力していきたいと考えております。一緒にやってみたい方がいらっしゃいましたら、ぜひご連絡ください。
Wakameは「世界のクラウドソリューションへ」という安直なスローガンを掲げ、アホ臭いと言われようともけっこう真顔でそっち方面を目指しています。良いのか悪いのかもわからない。でも楽しい。

ちなみに、人材紹介系のリクルーティングサービスは絶対に使わない方針なので、その辺よろしくお願いします。＞テレアポの方

Amazon S3を共有ファイルシステムとしてマウントするとスケールアウトする時に便利

s3fsは共有ファイルシステムとして使うと超便利

ポイントは、複数のインスタンスからs3fsで同一バケットをマウントし、共有ディスク化できる、というところ。

ファイルアップロードするとローカルディスクに書き出しちゃう典型的なアプリに便利

結構この手のWebシステムは存在する。例えば、CMSのデザイン変更やブログ記事の写真など、アップロードされたファイルをディスクに書き出すような仕組みのWebシステムがあったとしよう。
そのシステムをそのままスケールアウトすると、アクセスを分散させることになって、毎回アップロード先のサーバが変わってしまう。
大抵の場合、アップロードされたサーバ上のファイルに書き出してしまうわけで、そのまま使うと各サーバのローカルファイルに保存され、他のサーバから参照できなくなってしまう。

NFS無用

できるだけWebシステムを変更せずに先述の状況を改善しようとすると、NFSなどの共有ファイルシステムが有効になってくるわけだが、どうもスケールアウトさせながらNFSの面倒をみるのがうっとおしい。そんなときにこそs3fsが便利なのです。

やってみよう！

早速、半袖先生に試してもらった。仕方なく表示が256Tのストレージになってるけど、理論上も無限のサイズ。さらにインスタンス間で共有できるとなれば、これを使わない手はないでしょう。

注意点

いくつか気になるところを試してもらったんだけど、S3の性質はちゃんと理解した上で使ったほうがいい。通信状況を見ていると大量にあるファイルのlsなんかは本当に悲惨だし、

% cat >> hoge

のようなファイルの追記をはPUTで丸ごとアップロードし直しだ。おそらくログなんか格納したら目も当てられなくなっちゃうだろうなぁ。

ブラック企業っぷりを紹介(続・小企業に勤務時間は必要ない)

前回の記事ではてブをいくつかもらえて、コメントを見ていてなるほどと思った。やはり皆様勤務時間についての考え方はシビアなのだね。ただ、僕もかつては雇われる側だったけれど、どこの会社も大なり小なり問題を抱えながら進んでいるのではないだろうか。社員を雇用してやっと１年経ったばかりだから、丁度いいタイミングなので、もう少し弊社のブラック企業っぷりを反省点として暴露しておこうと思う。

※ただし、これだけは最低限の誤解ないようにと思って言いますが、自己責任で勤務時間を設計できるようにしたことはあくまでも仕事に対する自由度と成果を期待してのことです。 この自由を与えたことにより労使関係が消えてなくなるわけは無く、法律によって定められた従業員の保護を放棄するものではありません。って言うかできない。当たり前だけど。

労働時間の管理は確かにできていない

悔しいけれど、これはその通りで、正直感覚でしか見れていない状況。 メンバーの働き方を見ていると、大体以下の通り。

1. たぶん１日７〜８時間くらい勤務しているのではないかと思う。休憩も思い思いに取っているのだが、このアバウトさは要改善のポイントだろう。
2. たまに在宅でやる人もいる。
3. そして出勤時間は朝８時の人もいれば、夕方４時の人もいる。
4. もちろんお客様とのお約束には合せる前提。
5. 土日は休みだが、人によっては土曜日仕事している人もいるはず。たまにメールが飛んでいる。
6. 年間20日の有給を設置しているものの、これも消化率は悪く、呼び掛けをしないとなかなか休まない状況。ここも要改善。

最近会社内で議論されているのは上記3番太字の部分。みんな自分を最適化するために勤務時間を設定しているんだけれど、労働時間ベースの管理がどうも合わない。会社が早朝出勤を善とするなどどちらかを優遇したり、どちらともつかない折衷案で勤務時間を決めれば、どちらの人間にも不都合なわけだ。

ゆえに勤務時間って本当に決めなければならないのか？要らないんじゃないの？と思っているわけです。

うちは管理できているもんねフフフっていう会社でも、結局実態と合っていない管理をする会社は多い。 結局帰宅後に勉強するよう強要してみたり、社員が労働時間を申告する形式になっていて残業時間のつじつま合わせを自主運用しなきゃいけない雰囲気になっていたりしていて、そっちの方が問題だろう。

成果成果と言うけれど正直それだけで給与は決定できていない

実は全く成果と連動しない基本給が少ないながらも設定してある。あとは家賃補助手当(家賃の半額相当、上限あり)があるくらい。旅費交通費は普通に支給している。言う人に言わせるとこれは本当の「成果主義」ではないかもしれないので、割合が大きいことから「成果中心」と表現した。

そして成果を正しく評価することも正直できていないと思っている。 これは永遠のテーマになると思っていて、今なお自信はない。

しかしひとまずここで言う成果とは何か、どこまでやると成果で、実際どのくらいリターンがあるのかは説明して合意をもらっているつもり。この算出アルゴリズムは社員と決めているんだけど、結局議論しているうちに「とにかくやってみて、数字出すしかないね…」という弱小企業故の悲しい結論に。失注なんかがあるとかなり悲しい空気に包まれます。

ただ、労働時間に対し対価を払うという考えだけは絶対によろしくないと思っている。成果が正しく評価できない以上に、同じ条件下のメンバー２名がいたとして、ダラダラ仕事している人の給料が高くて、サクっと１時間で仕事を終えた人の給料が低くなるというのはどう考えてもおかしいだろう。

生い立ちが制度無しのブラックスタート

社員を雇う環境整備が出来ていないことを理由(←ご指摘の通りこれはイイワケ)に、当初は２名の役員だけで進めていた。 残業なんて関係ない世界で徹夜もあった。 そんな中、偶然社員になりたいと言う人材に出会ったのをきっかけに、それならと急遽社会保険など最低限の仕組みだけは何とか準備。

そういう意味では基本的に社員の労働環境整備は全て後手に回っているのは事実。 せいぜいアーロンチェアとHHKを支給したくらいか。物的な改善しか出来ていない。

これまで「全て自前で勉強して環境整備する」という方針で進めてきたので、行政書士さんや社労士さん、税理士さんなどにお願いすることなくやってきた。本来なら迅速に会社を働きやすいものに仕立てていくところは犠牲にしてきた。そろそろ綻びも出てくるだろうと言うことで、税理士さんだけは付けてみることにした。今後は過去に独学でやった部分の修正をしていくことになるんだろうと思っている。

それから弊社は今フルタイムメンバーが７名しかいない。労使関係で言うと、取締役が4名もいて正社員は3名しかいない。まだ誰が何をどれだけやっているのか把握できない人数ではないと思っている。 「人数が増えたら今の制度ではダメなので変える」という話はメンバーに毎回言うことだが、今の段階では引き続き勤務時間というものを明確に規定しない方向でやってみようと考えている。