Wakame-vdcプロジェクトは少数で開発していて、新規の機能開発や、複数の商用環境への投入とメンテナンスなどの全て並行して賄って来ました。 自動化を進めてもらったおかげで、人手に依存せず、少人数でもうまくいくようになってきました。 その中で僕達自身が一番困っているのがドキュメンテーションです。

やはりWakame-vdcをできるだけ色々な方々にインストールしてご利用いただけるようにしようと、インストール手順をWikiなどに掲載したりしてきました。 しかし、今もなお実装の改善が入ることがあって、すぐにインストール手順は古くなってしまいます。 ちょっと気を抜くと、ユーザ様から、インストール手順通りに試したけどインストールできません、とご指摘いただく形になってしまうのです。 この状態を解消するために、rpmによるインストールの簡略化や、マシンイメージでの提供によってインストールそのものを無くす手法を試みて来ましたが、これはインストール手順そのものへの対策ではあっても、ドキュメントがあっと言う間に古くなると言う本来の課題には応えられていません。

結局のところ、開発のスピードを犠牲にしてでも、ドキュメンテーション専門の時間を明確に作らない限り、整備はされないのだなと言う当たり前の結論に落ち着きまして、最近は少しずつではありますが、作業のアサインをするようになりました。 その成果が、GitHubのリポジトリにあるWikiのページです。 今回は、そのWikiページに何が書かれているのか、ご紹介します。

基本方針

基本的には、できるだけ全て英語で記述するようにしています。 世の中は英語ができるエンジニアの方が多いので、理にかなってはいるかなと思っています。 また、先述した通り、ドキュメンテーションに割けるリソースも限界があるため、まずは英語で集中的に仕上げていこうと考えています。 日本語に翻訳してくださる方を募集中です。

仮想データセンターのコンセプト

Wakame-vdcとは一体何なのかが書かれています。 特にコンセプトである、仮想データセンターのあたりが重要です。 このコンセプトは2009年にクラウドコンピューティングと言う単語が先行する中で、本当に自分たちが一番実現したいことは何なのかを考えた結果でもあります。 もう5年は経過しているのですが、未だに実現まで少し距離感があります。 ただ、時代は着実にそれを求めていると、昨今では当時よりも強く確信しています。

簡単なインストール

Wakame-vdcはインストールが簡単です。CentOSであれば、サクッとインストールが出来ますし、デモが見たいならば、ここからインストール済みの仮想マシンイメージをダウンロードして、お手元のコンピューターで動作させる事ができます。

冗長化についても、いくつかある商用環境でのノウハウをいずれ公開したいと思っていますが、基本的には、複数サーバへの分散とフェイルオーバー、プロセス監視と再起動が出来ていれば問題ありません。 その他、MySQLサーバなど、既存ミドルウェアの冗長化などは既に様々なノウハウがインターネットに溢れていますので、少しでもOSSの取り扱い経験があれば、さほど問題にはならないでしょう。

仮想マシンの利用が簡単にできる

Wakame-vdcが標準で備えるGUIをとりあえずウォークスルーしてみています。基本的な部分のひと通りの使い方が分かるよう、スクリーンショット多めに交えての紹介です。

独自のマシンイメージも作成できる

ここでは、OpenVZコンテナベースの環境に、httpdが標準インストールされ、ブート後に自動で起動してきるCentOSイメージを作成し、登録する手順が記載されています。 wakame-initと呼ばれるブート専用のスクリプトを導入することで、マシンイメージはWakame-vdcのsshの鍵管理と連携することができるようになります。 最後に、出来上がったマシンイメージをWakame-vdcの管理専用コマンドであるvdc-manageを用いて登録すれば、無事ブート可能なマシンイメージとして選択できるようになります。

起動した仮想マシンへの通信をセキュアにできる

Wakame-vdcの優れた機能として、セキュリティグループの機能があります。これはエッジネットワークで全て制御されるため、Tagged VLANを一切使わず、低コストに動的ファイアウォールとして機能するのが最大の特長です。現在はNetfilterを標準利用しており、OpenFlowと切り替えられるようにはなっていますが、いずれはOpenFlowの方を標準にしていくことになります。

機能的にはL2/L3レベルのフィルタリングをしており、仮想マシンへ論理名を持ったルールセットを動的に適用して、通信の制御することができるものです。Referenceの機能説明に記載されている部分が最もセキュリティグループらしい箇所であり、簡単にティアを組める所以でもあります。

簡単にバックアップも取れる

バックアップ用のストレージを設定し、そこに仮想マシンのバックアップを作る方法を示しています。

Wakame-vdcは、ローカルディスクだけでなく、NFSやWebDAV形式のインターフェイスを持った外部ディスクに、仮想マシンのコピーを作成することができます。外部ディスクに論理名を付けて登録し、それをバックアップ先に設定するだけで利用できます。

ドキュメントのメンテナンス方法

これらドキュメントは、下記リポジトリで管理されています。

上記リポジトリをcloneするなどして、編集します。その後、gollumと言うWikiエンジンで閲覧して確認をします。gollumは、Gitで利用できる文法と多少差異はありますが、レイアウトも含めてほぼ同じなので、手軽で良いでしょう。何か良いドキュメントができたら、ぜひpull-requestをくださいませ。

マシンイメージを手軽に生成できて、環境構築ができる世界を作る

1つ目は、担当授業でのフィードバックからの気付きだった。2010年頃、Immutableや、Blue-Green Deploymentと言うキーワードが無かったものの、その都度マシンイメージから新規環境を構築して、環境を丸ごと切り替える手法は、2010年に私が国立情報学研究所(NII)で担当するクラウド関連の授業で教えていた。これがもっともクラウドらしいデプロイメントだと考えていたためだ。しかし、当時の受講生の反応の大半は、これは実用的ではないと言うものだった。どこに課題があるのかを考えてみたが、結局のところ次のような点に集約される。

1. マシンイメージをどう作り直すか
2. 新規環境をどう本番環境へ昇華させるか

これら2点に良い手法があれば、アプリケーションデプロイは大きく変わるのだろう、と言う感覚が十分にあった。

状態管理を放棄しても差し支えない

2つ目は、VMの状態管理が大変だと言うことだ。同じくして2010年頃、その頃はChefはまだ新しくて日本ではそんなに有名ではなかったが、Puppetを使っている人がちょっと先を行っているぞ、みたいな雰囲気だった。我々もアプローチは異なるが、2009年4月に似たような手順エンジンとしてWakame-fuelと言うものをリリースしていて、オートスケールの手順をサンプルに、簡単な状態管理をしたりしていた。

状態管理が大変なのは、頭の中では同じ状態のVMだと思っているだけであって、厳密には全てのVMは状態が異なっていると言うところにある。LBの下には「同じWebサーバ用のVMが複数動いている」と思いこんでいる。しかし実際は違う。細かいが、簡単なところでは、メモリやディスクの使用容量は一致しない。LBが均一にバランスしているわけではないので、準じてログのサイズなどに偏りが出る。例えば、ディスク上のワーキングエリアが十分ある前提でスクリプトを組んで走らせると、タイミングによっては失敗するWebサーバも出てくると言うことだ。

同じWebサーバなのに、違う結果を返す。生きているサーバを管理している以上、それぞれは稼動した瞬間から違う状態になると思っていた方が良い。ChefやPuppetでそれを封じ込めるのには限度がある。スクリプトを走らせる時は、それが状態の違うものに対する差分の手順であることを、常に意識しなければならない。僕らがWakame-fuelの開発をあるときから止めた要因のひとつは、そこに限界を感じたからだ。システムを外部から「維持しよう」とする設計である以上、必ずこの限界にぶち当たるのだ。(ちなみにそうじゃないアプローチが必要だと考え、プロトタイプした結果は、とある研究成果として利用されているが、その話はまた別途...)

それ以降、当時から「ChefやろうかPuppetやろうか、今ならどっちが良いですかね?」と相談される度に「どちらでもない。同じ状態になるマシンイメージを、いつでもポンと作れるようにした方が良い」と言うようになった。

環境をスクラップ&ビルドできるようにしてみたら快適だった

3つ目は、CIとクラウド基盤の運用ノウハウこそが答えだったと言うことだった。僕達には、2009年の秋くらいから開発を始め、2010年4月にリリースしたWakame-vdcと言うIaaSの基盤ソフトウェアがある。これを実際お客様に向けて機能追加し、運用もする中で、僕らは色々と苦労をしてきた。

特に、テストが大問題だった。理由の一つは、お客様毎にインストールする環境が異なること。これらを本気で網羅的にテストをやろうとしたら、それぞれの物理環境が必要になってしまうので、仮想で何とかしたかった。その上で様々な構成をテストしよう、と。 通常のWebアプリケーションのテストの場合、デプロイが繰り返しできれば良くて、足回りが何パターンもあるとかあまり無い。IaaS基盤ソフトウェアは、Webアプリケーションを稼動させるための文字通り基盤であるため、これをテストしようとするとインストールのパターンがいくつか必要になる。

テスト環境はお客様に持っていただいているものもあるが、これはお客様都合で用途が変わることがある。お金の問題もあって、テスト環境の一部がいつの間にか別のものに利用されるなど、融通されることは良くある話だ。毎日動いていて欲しいが、保証はない。

そこで、僕達は小企業ではあるが、ある程度はオンプレでテスト環境を持つことにした。潤沢なリソースがあるわけではないので、その上を仮想化して環境ごとのテストをスクラップ&ビルドしようと言う目論見だ。

結局出来上がったのは、以下のようなCI環境だった。

1. リポジトリへコード修正が上がる
2. rpmなどのパッケージを自動生成する
3. テスト環境が無い場合、
   いくつものマシンイメージを自動生成し、rpmパッケージも自動インストールする
4. 上記マシンイメージをテスト環境でVMとして起動し、コンフィグする
5. テスト環境があれば、そこにデプロイスクリプトが走り、rpmなどが更新される。
6. テストスクリプトが走る
7. 上記プロセスの進捗がHipchatに逐次報告される
8. 必要なければ好きな時にテスト環境を廃棄できる

僕達の場合は、テストをどうするかと言う観点から始まったが、これは当然一般のアプリケーションのデプロイと言う視点でも捉えられる。Webアプリケーションの場合、テストのための環境をVMで再度構築するようなプロセスは大げさすぎるかもしれない。しかし、このプロセスがあれば、いつでもアプリケーションをゼロから構築しなおせる。上流のネットワークで切り替えれば、このテスト済みの環境をそのまま本番環境に仕立てることもできる。あとはデータベースなどのデータをどうマイグレートするかを検討すれば良さそうだ。

ImmutableでBlue-Green Deploymentをやろう

ここまでで、パッケージを基にマシンイメージを作り、起動したらテストを流して確認し、本番環境として切り替えて利用する、そんなプロセスが出来上がった。この過程でまた細かなツール群が誕生し、僕達の中でも、何だか全部こんな感じで良いんじゃないかって言う気がしてきたわけです。

あとは、いかにマシンイメージをオンデマンドに作るかと言う手軽さが論点になってくる。望む状態のマシンイメージが好きな時に手に入りさえすれば、現在稼動中のサーバを維持する必要がなくなる。

マシンイメージの作成って面倒くさいけど、もし、簡単に好きなイメージがポンと作れたら、生きているインスタンスを触ってミドルウェアをちまちまとインストールする現在のスタイルは変わる気がする。

— Yasuhiro Yamazaki (@sparklegate) December 25, 2012

そして、色々議論して約1年前の2013年春には、こんな結論に達した。

当時のWakame-Fuelやめた理由は、環境の差分をコードで表現するのに限界を感じたから。某パペも某シェも、結局良い答えが見つかっていないと思う。最近、僕らのなかでは、もうマシンイメージから作り直すのが一番合理的って事になってる。

— Yasuhiro Yamazaki (@sparklegate) May 27, 2013

それが、Immutableな発想に基いて準備されたマシンイメージを用いて、Blue-Green Deploymentが日常的になされている世界なんだね。

ここ1年ほど、様々な方と仮想ネットワークについて議論を重ねてきた。いつも決まって話題になるのは、ユーザのメリットは何があるのかと言う点。 よく言われるのは、柔軟性だ。確かに、仮想のネットワークのレイヤに、L2やL3を自由に組み上げられるその仕組みは柔軟性が高く、物理ネットワークで苦労してきた人には外し難いメリットの一つなのかもしれない。 見方を変えると、これは仮想ネットワークで複雑な構成が組める、と言うことを意味するわけだが、本当にそれがメリットなのだろうか。

アプリケーションエンジニアが作るネットワークこそ究極の姿になる

私が仮想ネットワークに期待するのは、プレイヤーが変わることによる、「思いもつかないユースケースの発生」だ。つまり、かつて物理ネットワークを触ってきた人ではない人が、仮想ネットワークから触り始めることによって、何が起こるのかに興味がある。

アプリケーションエンジニアと呼ばれる人々の中には、物理ネットワークの変更操作まではできない人がそれなりにいる。そうなると、彼らはそれが出来る他の専門の人へ作業をお願いすることになる。組織としても、ここで役割が大きく分かれているため、コミュニケーションのオーバヘッドが大きい。これがプロジェクトの持つスピードを損ねる要因になったりもする。

仮想ネットワークは、物理ネットワークを隠蔽し、本来自分が欲しかったネットワークを仮想のレイヤへ、自由に構築できるものである。アプリケーションエンジニアのような人々にも、ネットワークのコントロール権限を与えるものだ。物理ネットワーク専門の人へ作業を依頼せずとも、おおよそのことはこの仮想レイヤで賄えるようになる。

シンプルなネットワークへのパラダイムが起こる

そしてパラダイムはここから起こる。物理ネットワークの世界で、職人芸を見せてきたエンジニアの方々であれば、軽々しく賛同いただけないような構成を、アプリケーションエンジニアは試し始めるのだ。「ヒャッハー」「ネットワークちょろいぜー」って言いながら、ネットワークを我流で組み始める。時はまさに世紀末だ。そして仮想の世界は、ソフトウェアの力が全てである。Try & Errorが圧倒的にやりやすい世界であるので、アプリケーションエンジニア達は、あっという間にベストプラクティスを作り上げることになるだろう。そして、そのベストプラクティスは、物理ネットワークのエンジニア達が想像もしなかったような、一種原理主義的で、極端に合理的な結論として姿を見せる。

その結論が今何なのか具体的に述べられないが、間違いないのは、複雑なものではなく、シンプルなものだ、と言うことだ。何でもできるようにと議論が重ねられ、複雑になったXMLやSOAPは世界を制しなかった。結局程々に大体のことができ、シンプルなJSONやRESTが主流になった。仮想ネットワークを使い倒して行くと、想像もできないほどシンプルで合理的なものがベストプラクティスとして生き残る。

僕には、それが生み出せるポテンシャルこそ仮想ネットワークの真価だと思える。

The virtual network simplifies our network.

仮想ネットワークは、複雑なネットワークを作り出すためのものではない。仮想ネットワークは、複雑な物理ネットワークを意識することなく、究極にまで削ぎ落とされたシンプルなネットワークをオーバレイするものだ。

僕はそう信じている。

IaaSに強力なメッセージ監視を備えられる!

京セラコミュニケーションシステム様にて運営なさっている"GreenOffice Unified Cloud (GOUC)"と言うサービスがあります。特長的なのは、IaaSであるWakame-vdcを拡張した運用管理の統合ツールとなっている点です。システムそのものはシンプルで面白い試みがたくさん詰まっており、特に本日記事に取り上げるFluentdを用いたログ監視(メッセージ監視)はお手軽で強力なので、ご紹介します。

おおまかな手順としては下記の通り進めます。

1. ブラウザからログ内で検出したい文字列を指定する
2. サーバ内部の設定を修正する
   • td-agent.confに監視対象のログファイルを指定する
   • td-agentを再起動する
3. アラートを動作させ、ブラウザで確認をしてみる

ブラウザからログ内で検出したい文字列を指定する

上図のようなUIを用いて、サーバを起動し、グローバルIPを割り当てて、セキュリティグループはssh接続とhttp(80)のアクセスを許可しておきます。起動ができたらログ監視の設定をしていきます。

上図にあるように、起動したサーバに対し、ログ監視の設定をします。ここでは、apacheのアクセスログの中に、"HelloWorld"と言う文字列を見つけた際に、アラートを上げるように仕掛けてみました。実際は、UIではこの程度の設定をするだけで準備が完了します。あとは、サーバの内部の設定をしましょう。

サーバの設定を変更する

これも簡単です。お手元のターミナルからsshを用いてサーバへログインします。この辺りはIaaSを使ったことのある方ならもはや説明は不要でしょう。

起動したサーバには、下記する通り、予めtd-agent 1.1.13がインストールされています。

$ rpm -qi td-agent
Name : td-agent Relocations: (not relocatable)
Version : 1.1.13 Vendor: Treasure Data, Inc.
Release : 0 Build Date: Tue 23 Apr 2013 02:56:08 PM JST
Install Date: Fri 27 Sep 2013 12:50:40 PM JST Build Host: ip-10-123-31-198.ec2.internal
Group : System Environment/Daemons Source RPM: td-agent-1.1.13-0.src.rpm
Size : 94742991 License: APL2
Signature : (none)
URL : http://treasure-data.com/
Summary : td-agent
Description :

まずは、設定ファイル(td-agent.conf)を修正しましょう。

$ sudo vi /etc/td-agent/td-agent.conf

<source>
 type tail
 format /^(?<message>.*)$/
 path /var/log/httpd/access_log
 pos_file /var/log/td-agent/position_files/httpd_access_log.pos
 tag var.log.httpd.access_log
</source>
<match **>
 type forward
 flush_interval 60s
 <server>
 name logservice
 host fluent.local
 port 24224
 </server>
</match>

$ sudo /etc/init.d/td-agent restart
Shutting down td-agent: [ OK ]
Starting td-agent: [ OK ]

アラートを作動させてみよう!

あとは、access_logをtailしつつ、このサーバ上のapacheにアクセスをしてみます。

$ tail -f /var/log/httpd/access_log
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:03:28 +0900] "GET / HTTP/1.1" 403 5039 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:03:28 +0900] "GET /icons/apache_pb.gif HTTP/1.1" 200 2326 "http://yyy.yyy.yyy.yyy/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:03:28 +0900] "GET /icons/poweredby.png HTTP/1.1" 200 3956 "http://yyy.yyy.yyy.yyy/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:03:29 +0900] "GET /favicon.ico HTTP/1.1" 404 290 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36"

xxx.xxx.xxx.xxx - - [16/Dec/2013:13:05:35 +0900] "GET / HTTP/1.1" 403 5039 "-" "HelloWorld"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:05:35 +0900] "GET /icons/apache_pb.gif HTTP/1.1" 304 - "http://yyy.yyy.yyy.yyy/" "HelloWorld"
xxx.xxx.xxx.xxx - - [16/Dec/2013:13:05:35 +0900] "GET /icons/poweredby.png HTTP/1.1" 304 - "http://yyy.yyy.yyy.yyy/" "HelloWorld"

アラートを確認してみよう!

しばらくすると、UIからはアラートが確認できます。設定されていれば、メールも飛んできますよ。 [画像:gouc_alert]
詳細画面からは、実際にどのようなメッセージを検出しているのかが閲覧できる他、自動的にチケットとして起票して、解決の運用フローへとつなげることもできます。 [画像:gouc_monitoring_detail]
このように、Wakame-vdc基盤側に、サービスとしてFluentdを埋め込んでおくと、サーバからそれを利用するだけで良くなります。ログに関する様々な厄介事から逃れることができます。アラートはサーバに近いところでやり、将来的には分析のためにTresure Dataさんに直接ログを飛ばしても良いかも知れません。実際目の当たりにすると、更に色々な応用を思いつきますね。

以上、商用のIaaS基盤GOUCで使われているWakame-vdcがFluentdを活用しているお話でした。

前日12/1に、記念すべき本企画最初の記事「Wakame-vdc編 - nested KVM を用いた環境で Wakame-VDC 環境の作り方」が羽深さんの手によりリリースされました。おかげさまで幸先良く無事開幕しました。Wakame-vdcのインストールに試行錯誤をした素敵な記事だったので、僕は最近リリースされたOpenVNetのインストールについて書いてみることにしました。これでアナタもOpenFlowの世界へ飛び込んでみてください!ちなみに、今からでもエントリは遅くありません。参加記事の中から最も素敵な記事には、なんとプレステ4を差し上げます。

OpenVNetは、GitHubにrpmを構築する方法が記載されています。このrpmを、あらかじめ置いておいたものを利用して、インストールすることもできます。 現在、公式なものではありませんが、rpmが下記URLにて提供されています。

• http://dlc.openvnet.axsh.jp/packages/rhel/6/vnet/current/

• http://dlc.openvnet.axsh.jp/packages/rhel/6/third_party/current/

前準備

とりあえず簡単にインストールするために、下記の環境を用意してみました。

• ホスト環境: MacBook Pro 2.4GHz Intel Core i5 / 16GB RAM
• ハイパーバイザー: VMware Fusion Professional Version 5.0.3
• ゲスト環境: CentOS 6.4 / GNOME Desktop

yumコマンドを利用する場合は、冒頭のrpm群を、リポジトリファイルとして書いておくと便利です。早速作業にとりかかりましょう。

/etc/yum.repos.d/openvnet.repo

[openvnet]
name=OpenVNet
baseurl=http://dlc.openvnet.axsh.jp/packages/rhel/6/vnet/current/
enabled=1
gpgcheck=0

/etc/yum.repos.d/openvnet-third-party.repo

[openvnet-third-party]
name=OpenVNet Third Party
baseurl=http://dlc.openvnet.axsh.jp/packages/rhel/6/third_party/current/
enabled=1
gpgcheck=0

インストールしてみよう

epelも必要ですので、下記にまとめてあるrpmをインストールしておきます。

$ rpm -Uvh http://dlc.wakame.axsh.jp.s3-website-us-east-1.amazonaws.com/epel-release

先述したリポジトリファイルがあれば、下記するコマンドでインストールすることができます。

$ yum install -y wakame-vnet

設定ファイルを見てみよう

設定ファイル類は、おおよそ /etc/wakame-vnet/ 以下に配置されています。

$ ls /etc/wakame-vnet/
common.conf vna.conf vnmgr.conf webapi.conf

vna (Virtual Network Agent)

これが、OVSのコントロールをするエージェントです。ネットワークを流れるパケットの動きを変えたいと思ったところに、OVSと対になるようにこのエージェントを配置する必要があります。現在ではそのような配置から、vnaはOVSとUnix Socket通信するように書かれています。いずれはOVSをオフロードするようになれば、一般的なTCP通信へと切り替えるのが良いのでしょう。設定ファイルのアドレスは、ZeroMQと言うキューサーバーへの接続先です。

vnmgr (Virtual Network Manager)

キューネットワークを介したMySQLへのアクセスを司る他、データセンター全体の物理・仮想ネットワーク構成を俯瞰して観ることができるプログラムです。必要なvnaへの指令を出し、ネットワーク全体を正しく動かす役目を持ちます。

webapi (Web API)

HTTPサーバとして機能し、curlや、wgetのような、HTTPクライアントからの接続と要求に応じて、vnmgrに向けて処理の依頼を投げかけるプログラムです。どのようなインターフェイス定義になっているかは、ドキュメントを御覧ください。ただし、ソースコードは日々更新されているため、ドキュメントが少し古くなっていることがあります。

MySQLを起動し、データベースを設定しよう

手動での起動のついでに、自動起動もONにしておきましょう。

$ service mysqld start
$ chkconfig mysqld on

$ cd /opt/axsh/wakame-vnet/vnet
$ bundle exec rake db:init

$ mysql -u root
mysql> use vnet;
mysql> show tables;

OpenVNetのサービスを起動してみよう

とりあえずここまでで基本的なインストールはおしまい。あとは各プログラムを起動してみましょう。

$ initctl start vnet-vnmgr
$ initctl start vnet-webapi
$ initctl start vnet-vna

$ initctl status vnet-vnmgr
vnet-vnmgr start/running, process 41789

さて、次回はこれらのノードの説明と、データパスの設定などがあり、それから応用としての使い方などの説明へとつなげて行きたいと思っています。

ルータの機能をVMとして実装してしまうのは、あまりに効率的ではない

最初に、分かりやすいがオススメできない実装を述べておきます。それは、Vyattaみたいなものを、VMの内部に立てて、そいつのコンフィギュレーションを外部から行うことでルーティングさせる方法です。VMがあるのでトポロジが従来のルータとして見えやすく、その辺りが理解を助けているのでしょう。ここでは、便宜上このようなVMになったルータを、VMルータと呼んでおきましょう。

しかし、動作実験と決め込むなら良いですが、これを商用ネットワークの基盤として標準機能にしてしまうのは、下記する理由で、全くあり得ないなと思っています。

• (1) 管理やコントロールが悪くなる
• (2) スケーラビリティが低い
• (3) エッジネットワークになっていない

最後の(3)は、エッジネットワーキングと言っているのに、エッジで処理されていないと言うアーキテクチャ上の一貫性が無いと言うだけなので、説明は割愛しておきます。最初の2点について詳しく述べておきます。

(1) VMルータだと管理やコントロールが悪くなる

まず、仮想ネットワーク上にVMルータを置いて制御すると、エッジ側の物理ネットワークのVM間をパケットが走ります。 エッジネットワークは、仮想ネットワークを解釈された結果として、物理のピアができて、そこにパケットが流れるのですが、VMルータを持つことで、異なる仮想L2に属するVM間が、VMルータを経由し、純粋に物理のピアとはならなくなるのです。

このような状態で、トラフィックを管理/コントロールしようと思うと、これが非効率なのは明らかです。 物理のピアで通信しないとなった以上、パフォーマンスの面からも、VMルータのネットワーク的な距離も重要になってきますね。 無駄なトラフィックを生まないように、帯域を踏まえた設計をする必要があり、クラクラしてきます。 物理ネットワーク上の経路制御が困難になるのです。

(2) VMルータだとスケーラビリティが低い

これも大きな課題です。現段階であまり必要がありませんが、将来的に大規模ネットワークを仮想ネットワーク上に設計する場合、仮想ルータを数個配置し、ルーティングさせるようになるかもしれません。 VMルータを複数設置すると、それぞれのVMルータ間にパケットが走るため、ルーティングのホップ数が増えるだけでトラフィックを消費してしまいます。 エッジネットワークでは、おおよそのトラフィックは集約された帯域の物理ネットワークに収容されることが多いため、ルーティング程度でLANの帯域をどんどん消費してしまうのはマズい。

これらの課題は分散ルータで解決できる!

解決方法は、VMルータを止め、ルーティングが必要なパケットを物理のピアで届くように最適化することです。 特に仮想ネットワーク内では、パケットが最終的に届く先が物理的にどこになるのか判定することができるため、複数の仮想ルータで複雑にホップするように指定していても、物理のピアとして決めて届けられるはずです。

OpenVNetの分散ルータは、パケットの最終到着地を決定するために、エッジノード内部でルーティングを済ませ、物理のピアを決定してから転送をするものです。 VMルータのように、どこかにVMとして起動されていて、そこでルーティングの処理を集中的に行うものではありません。 全てのエッジノード内部にルーティングを解決する処理を持たせるのです。 物理ネットワークに対して集中型のトポロジをもたらしてしまうVMルータと対比して、OpenVNetでは上記のようなルーティングの仕方を、分散ルータと呼んでいます。

もちろん良いことだけではない

最終的に物理でピアになる分散ルータは、複雑なルーティングを設定された仮想ネットワークであっても効率的にパケットを転送することが分かりました。 しかし、そのせいで、tracerouteのようなものを仕掛けると、最適化されたホップで結果を返してしまいます。 運用時のトラブルシュートが難しくなるので、ここでは「仮想化されたネットワークの特性として、そうなるものだ」と捉えるか、「シミュレーションするモードを入れるべきだ(それで得られた結果がどんな意味を持つのか)」など、今後は考え方が色々出てくると思います。

何にしても仮想ネットワーク面白いです!

ちょうど2週間前にOpenVNetを無事リリースいたしました。 仮想ネットワークを無料で誰もが作れるようになる、そんなオープンソースライセンス(LGPL v3)の最先端ソフトウェアです。 同じ分野には、プロプライエタリソフトウェアとして、Nicira(現VMware)社のNVP(現NSX)や、ミドクラ社のMidoNet、ストラトスフィア社のSSPなどがあり、オープンソースプロジェクトとしては、このOpenVNetの他に、OpenDaylightや、OpenContrailがあります。細かなものも拾うと、OpenStackのプラグイン類も含まれそうですが、オープンソースのものは、他にも色々あるので、SDN Centralの一覧ページをご参考になさってください。

色々あって悩ましいですが、オープンソースだけで手軽に仮想ネットワークを実現できるOpenVNetをぜひお試しください。ハードウェアに特殊なスイッチも必要がありません。

OpenVNetは何が良いのか

まず、オープンと言うこと。最先端技術がブラックボックスではいけません。また、実績が多くあると言うこと。OpenVNetのソフトウェアアーキテクチャは、エッジネットワーキングと言うWakame-vdcのモダンな設計を踏襲しており、パブリッククラウドの構築実績を含め、多くのプロジェクトで既に利用されてきたものです。

OpenVNetの経緯

簡単に言うと、OpenVNetは、Wakame-vdcからのスピンアウトプロジェクトとして2013年4月に始まりました。それ以前に、2011年12月時点でWakame-vdcがOpenFlow 1.0に対応を済ませて、現在の設計の基礎を完成させました。その後、機能を仮想ネットワークへと拡張していますが、この辺りの経緯は別のエントリにまとめてあります。2012年3月には、仮想ネットワークは動作していました。それから1年間はWakame-vdcもやることが増えてきたため、仮想ネットワーク以外の部分に力を入れていました。無事、仮想ネットワークについてもニーズが見えてきたので、2013年4月から本格的にOpenVNetと言う独立したプロジェクトにまとめなおすことになりました。新しく考えなおしたのは、OpenFlow 1.3へのアップグレード対応と、新機能(仮想L3やゲートウェイなど)を追加した部分で、基本設計と言う意味ではWakame-vdcと大きな違いはありません。

Wakame-vdcの時代から、Tremaを利用してきたのもきっかけとなり、NEC様のご協力をいただき、OpenVNetの検証がなされています。現場の技術者グループとは良く意見交換をさせていただくのですが、お互い実際に動くコードを使いながらの話なので非常に明快で、活用方法にもきちんとしたビジョンがあり、非常に楽しいです。ここからコミュニティを発展させていくつもりですので、ぜひ皆様もご一緒しませんか。

特に4章は、ファイルサーバ作ってみよう!とか、データベースを管理してみよう!とか、Ruby on Railsを使えるようにしよう!とか、目標が明確だから良いのです。モチベーションの湧かない人は、こういうところから入るべし、です。第4章を進める上で、基礎部分に課題が見えたら、その前の章までに記述がありますので、その時遡って読んでもいいかも知れない。そして、最後の5章で、この書籍の中で一番ディープなところに踏み込みます。おそらく4章を読み終えたら、Linuxってそもそもどう言う概念で作られているんだっけ?みたいなところが気になってきますよね。完全に網羅されているわけではありませんが、期待通りエッセンスは書かれています。

実際、ここまで読み進めていくと、このまま第6章が読みたくなってきますが、残念ながら本書はここでおしまい。でも、気がつけば、自力で羽ばたくことができるようにはなっているのではないでしょうか。最後には、読者の学習意欲に期待しつつ、著者も学びの手を止めません、という旨が書かれていました。

「分かりやすさ」でオススメしたい

中井さんの文章は分かりやすい。つい最近もそれを知らしめるエピソードがありました。僕から、中井さんに、昨今考えている技術の話を説明したんです。この話は3年くらい色々な人に話しをしたけれど、なかなか理解してもらえなかった。きっと難しいんだろうと思って諦めていたんです。でも、中井さんは、そんな僕の話を理解してくださっただけでなく、自分の言葉で皆に分かるように直してしまった。実際にその言葉を聞いた皆さんが納得している。つまり、僕の話は決して難しいものではなく、ただややこしいだけだったんですね。そう言う視点で僕はこの本を読みました。

平易な言葉でありながら、決して足りなくはない。慎重に選ばれています。脳みそに染みこんで来ます。だから今からLinuxを始める人もそうですが、復習がてら自分の理解をまとめるためにも、この本はきっと役立つと思いますよ。知識を得た皆様は、いつか誰かに自分も誰かへLinuxの「いろは」を教えなければならない日がくるかも知れません。その時は、この本に書いてある言葉で伝えてみてください。いや、この本を手渡してしまった方が早いかな。

Wakame-VDCを用いたオンデマンドなリソースコントロールと、仮想データセンターの技術コンセプトが活かされているのはもちろんです。それだけでなく、クラウド上でのサービス開発・運用に必要な機能が付いている!と言う点が、僕が個人的に思う最大の特長です。

記録を残しながらクラウドを管理する

GOUCで実現されている機能のうち、一番運用を意識していて面白いと感じるのは、チケットシステムです。チケットを起票して、それのステータス管理やら、コメント記入やらをやるものです。

これに類する仕組みは、どの現場でも割りと広く使われているのではないでしょうか。しかし、特にユニークだと思うのは、チケットにコメントを書くのと同じ要領で、インフラの操作をしたものもチケットへ記録に残せると言う点です。そう、チケットシステムが、インフラとガッチリ連携しているのです。

想像してみてください。運用時には様々なトラブルが起こるわけです。特定のサーバだけレスポンスが悪いだとか、リリースのために新しいマシンイメージを作るだとか、監視してたらアラート来たとか。

それらを全部チケットで管理するわけですが、GOUCでは、手動で任意のチケットを作るのはもちろん、アラートなどはできるだけ自動でチケット化されます。その上で、各チケットに関連した作業として、マシンのリブートをしたとか、新しいインスタンスを追加で起動したとか、そんなのがコメントと一緒に残るのです。

通常、この辺りはデータセンターリソースを操作する事だけを目的に作られたコンパネではやらない部分です。仮想マシンを再起動したりする操作はGUIで提供されますが、その操作が「何のために行われたのか」は管理していません。チケットに基いて操作を行う、このコンセプトが運用のシーンでは嬉しいですし、基盤とガッチリ連携していなければ実現できない部分でもあります。

この辺り、現場の方とはお客様に何が必要なのかと言うところを議論したり、実際にヒアリングに行ったりして、組み立ててきた背景があります。そのプロセス自体がとてもおもしろい試みでしたし、結果的に面白いものができた実感につながっています。これからもお客様の声で成長していくものですから、ぜひ使ってみて、ご意見ください。

技術的なところ

前回同様、今回も機能面が色々パワーアップしています。

一番大きいのは、東京と京都の二拠点にデータセンターがあり、Wakame-VDCはそれぞれに分散してインストールされて、相互にマシンイメージの転送を行うことができるようになっています。これで、バックアップサイトや、激甚災害対策(DR)等の構築の役に立てることができると思います。bkstaと言う専用のエージェントが追加されています。

次に、グローバルIPを任意のVMに割り当てることができるようになりました。Wakame-VDCにはnatboxと呼ばれるエージェントが追加されており、ここには、OpenFlowのフローテーブルがバリバリ使われています。

それから、割りと地味な機能ですが、Wakame-VDCのログ保存方式が、fluentd+cassandraになりました。今までのファイルベースのやり方でもいいのでしょうけれども、今後ログの収集は基本的にこの仕組を横展開しようと考えています。

メッセージ通知サービス(プロジェクト名"Dolphin")も追加されています。これは内部では死活監視Zabbixと連携して、イベントメッセージを吸い上げるためのインターフェイスとして利用されています。

※(注記)public/masterへのソースコード公開はもう少々お待ちください

Wakame-VDCはまだまだ成長します

順調に成長していますので、今後もご期待ください。無い機能、欲しい機能は一緒に作りましょう!OSSはそうして成長をしていくのです。そしてまた、いつでもそのフィードバックを得ることができます。

ぜひ使ってみてください。今ならキャンペーン中なので、2013年5月13日までに申し込むと、最大3ヶ月間、プラン100が無料になってお得です。

Wakame-VDCの進化

実際、NTTPCコミュニケーションズ様とは、Wakame Software Foundationにご加盟いただいて、一緒にWakame-VDCを育てていこうと言うところからスタートしています。最初の頃の打ち合わせは、どうやってWakame-VDCを活用するのか四六時中議論をしました。Wakame-VDCは、なぜ現在のアプリケーションデザインになっているのか、未来のクラウドコンピューティングの形、そしてOpen Source Software (OSS)に対する考えなどを共有していくにつれ、サービスのイメージが出来てきた、と言った感じです。そこから足りないものを、共同でどんどん実装し、リリースとなったわけです。

OSSは製品ではなく、生き物です

個人的に思うのは、OSSを製品として見ても良いのですが、製品として見過ぎると、今ある機能に目が行きがちです。OSSの最も重要なポイントは、自らの力で変化をさせられるところです。「製品」と言うよりは、未来をどうするべきか考えながら成長をさせていける「生き物」なのです。機能比較表みたいなものを作って、現時点版のOSSに、○しろまる×ばつだったものも数カ月後には○しろまるになる。未来を共に作れるのです。それがOSSの意義なのであり、Wakame-VDCのような、オープンな技術を採用した効果と言えるわけです。

割りとこの辺りで、主体的に動こうとする企業様が少ないのは事実です。どうしても自分でやるよりは、誰かにやらせようとします。OSSは自分で学ぶことができ、それを怠りさえしなければ、ベンダーロックインから開放されるのです。実装を誰かに任せ、取り扱いも誰かにやらせ続けていたら、ベンダーロックインに自ら嵌り込むだけなのです。OSSがプロプライエタリ製品と大きく違うのは、ソースコードを見て自ら学習できる点です。ここに投資しなければ、OSSである意味がありません。

僕達は、本当にオープンな技術とは何か、真の意味を問うています。Wakame-VDCは、それを応援できる数少ないOSSです。関連する全ての技術をお渡しします。皆様と共に、Wakame-VDCの輪を広げたいと思っていますので、どうぞよろしくお願いいたします。気軽にご連絡ください。

以前、Twitterなんかでは呟いていたのだけれども、OpenFlow実践入門と言う本が出まして、そこにWakame-VDCの仮想ネットワークの仕組みについて書いていただきました。感謝です。改めて献本いただいたので、他の章も合わせて読んでみました。

プログラマブルなネットワークを体験するのに十分な知識が詰まった本

一番良いのは、Rubyを使った大量のサンプルが掲載されているところです。Tremaはコードがとにかく短くなるので、この手の実践書籍にはサンプルを掲載するには向いていて、十分な情報量にあって尚、可読性が保たれています。まぁTremaじゃなかったら、サンプルのコードはクソみたいなコメントが大量についていて、やっと理解できるような代物だったでしょう。

Rubyを知らない人に向けて、Rubyの読み方・書き方までも、きちんと補足されていて、これも良い点だと思いました。テーマがネットワークとTremaに絞られているので、Rubyそのものも理解しやすい。個人的には言語だけを学ぶと、すぐに飽きますので、テーマがありつつ、コーディングした方が飲み込みが早くなります。とにかく、インフラエンジニアはコードを書く機会が少ないですし、いいチャンスですから、この本からプログラマブルな世界に飛び込むのはアリだな、と思います。

Wakame-VDCの仮想ネットワークの説明

Wakame-VDCならではの特徴的なアプローチについて、分かりやすく書いていただきました。僕はネットワークの専門家ではないので、このアプローチが「他と比較してどうなのか」まで横断的に理解してやっているわけではないのです。目の前にある課題を、1つずつソフトウェアで解決しているだけに過ぎず、そう言う意味では、やっと自分たちの何がユニークな点なのかについて、客観的な理解ができたような気がしています。

詳しくはぜひ、書籍をご購入いただいて、お読みいただけたらと思います。Wakame-VDCも、ここから今後どんどん新しい実装を加えていきますので、引き続きご注目ください。

技術のユーザも技術者

新しい技術は大体海外からやってくる

何としてでも生み出したい

2009年秋〜2010年4月の初期バージョンリリースまでネットワークは悩みのタネ

Wakame Software Foundation (WSF)は、2009年の秋からWakame-VDCの開発に取り組み始めた。それから数ヶ月後の2010年2月に、中間成果報告と言う形で、WakameTechと称する会合を開いたのです。当時はスライドに明記されている通り、ネットワークの課題が大きいことだけが分かって来ていて、とりわけAWSのセキュリティグループをどうやって実現するかが興味の対象でした。この時考えていたのは、Netfilterによる分散スイッチの構成でした。今で言うエッジネットワーキングです。スライドでは、本当に999台のシステムに1台加えた時に、1000台分のNetfilterの設定が変わってしまって良いのだろうか、と心配事が記されています。

その時のリリースでは、物理NICを使い分けて逃げることにしていました。

初期リリースから半年後に、エッジネットワーキングへ

WakameTechの後、Wakame-VDCのセキュリティグループの実装に着手し、2010年11月にはリリースをしました。エッジネットワーキングしている様子は、下記のダイアグラムで示されています。各物理サーバで動いているVMから出てくるパケットを、Netfilterで処理させます。VMのオーナーが設定変更を指示し次第、このフィルタ部分をダイナミックに書き換えるのです。

1年後の2011年12月に、OpenFlow対応を実現

そして、2011年12月には、エッジネットワーキングの仕組みをそのまま、OpenFlowが使える構成に置き換えました。基本的なアーキテクチャはそのままにして、使うプロダクトだけをOpenFlowのために置き換えたのです。それが、Open vSwitchとTremaでした。当時のTremaはイベントループの部分で独自のメッセージングを行なっていました。改善したものをTremaプロジェクトへコミットしたところ、無事に取り込まれたので、そのまま利用しています。

OpenFlowを採用した理由はスライド中にありますが、将来パケット処理のオフロードに期待できそうだと言う部分です。それ以上の理由が見当たりません。

2012年3月には仮想ネットワークが動作し、今に至る

セキュリティグループは、Netfilter版とOpenFlow版の2つありますが、お客様に必要とされるのは以前からあるNetfilter版でした。そのため実装差が少しずつ出てきており、それを埋めながら、OpenFlow版に期待される仮想ネットワークとSDNをやり切るのでは、問題を複雑にします。そのため、ここから我々は仮想ネットワークとSDNに注力するようにしました。

結果として、3ヶ月後の2012年3月には、仮想ネットワークが動作するようになりました。GUIからも使えるように、利便性を上げるための実装を追加し、今に至ります。

IaaS基盤のOSSとして、ここまで出来ているのは、今のところWakame-VDCだけです。ぜひ皆様、お試しください。

• RPMを利用したRHEL/CentOSへのインストール方法

理由1: いつでも改変できる自由を保証したいから

自分達のプロジェクトのために、機能追加や改変ができることがとても重要だと思っているからです。

こんな話があります。GNUプロジェクトを始め、GPLを作ったリチャード・ストールマンの話です。彼は、購入したプリンタのドライバに不具合があるのを見つけました。不便であったので、自分で修正するためにソースコードを手に入れようと企業に掛け合ったが、開示されることは無かったのです。重要なのは「自分が不便だと思ったので、自分で改善する」と言う手段が絶たれている事です。自分がお金を払って買ったものなのに、なぜ自分のためにソフトウェアを修正することが許されていないのでしょうか。

僕はこの話はもっともだと思います。物理的な物も、買ってきたまま使って不便であれば、日曜大工をして工夫をします。バラバラに分解して、組み立て直すこともできます。部品を交換したり、新しい装置を取り付けることだってできます。それがソフトウェアになると、なぜ許されなくなるのでしょうか。

自分達のプロジェクトで使おうと思っていたソフトウェアだって同じ事です。不便なまま使い続けなければならない理由は無いはずです。自分達のために、改変するべきです。より便利なものにして利用すれば良いのです。

一方で、不便な物や、使えないソフトウェアは捨てて違うものを探せば良い、と言う人もいると思います。ユーザであればそれで十分です。自分にぴったりの物が登場するのを、いつまでも待ち続け、使えない使えないと文句を言い続ける必要があります。しかし、私たちは技術者であって、現状を変えていける力を持っているのですから、行動をするのが先でなければいけません。

理由2: 課題を共有し合うことができるから

多くのオープンソースプロジェクトでは、共通した課題をどう乗り越えるのかが議論されています。言ってみれば、ソースコードは、そうした知の集合体であり、再利用可能なノウハウなのです。コミュニティの中で、ひとつずつ解決されて、蓄積されていくものです。あとは、自分達のためにどうやって応用するか、更に何を改変していけば良いか考えるだけで良いのです。

このような活動の中で、小さな新規のコードや、変更でも、大きな効果を生むことがあります。自分達のためにやったことではあるが、これを共有すれば、同じ問題で困っている人の役に立てるかも知れません。その1つ1つが、コミュニティの中で、また良いスパイラルを作るのではないか、と思います。

理由3: いずれサポートも不要にできるから

オープンソースソフトウェアは、しばしばサポートを受けられない、と懸念されることがあります。近年は、サポートを名乗り出る専門家集団も、少しずつですが現れ始め、懸念も和らいでいるのではないでしょうか。オープンソースであれば、専門家にサポートしてもらいながら、自分達も学習をすることができます。最も信頼できるマニュアルが、ソースコードとして開示されているからです。秘密にされているものは何もありません。最終的に、専門家のサポートを不要にして、コスト構造を変えることができます。実際サポートを無しにしてしまうかどうかは別ですが、選択肢があるのは大きな意義があります。

プロプライエタリ製品では、ヘビーユーザーにはなれますが、いつまで経っても専門家にはなれないのではないでしょうか。

さぁ、ソースコードを読もう!

僕たちがオープンソースに魅力を感じ、お客様にオススメするのも、このような考え方がますます重要になってきていると感じているからです。コスト削減をしたいと考えて、プロプライエタリ製品からオープンソース製品へと安易にシフトしてはいけません。ソフトウェアの価格がゼロになったから達成できたと言うべきものではないのです。短期的にはそれで良いのかも知れませんが、結局サポートを他人任せにしている以上、プロプライエタリ製品であろうと、オープンソース製品であろうと、コスト構造は変わらないのです。自分達が専門家にならない限り、それは変えられません。オープンソースライセンスは、全てのコードを開示して、あなたが専門家になるための道へと導いてくれます。

IaaS型クラウド基盤ソフトウェアであるWakame-VDCも同じ考えです。最初はサポートをお手伝いしますが、最も重要な「自ら専門家になる」と言うポイントも同時にお手伝いしたいと考えています。最終的には、自分達の力で機能開発できるようになること、これがオープンソースソフトウェアの世界では大切なのではないでしょうか。

参考資料

• OpenFlow in IaaS - Wakame
• ネットワークの仮想化について考えてみた結果がこれだよ!

最初に一言

私は、かつてネットワークプログラミングを好んでやっていたものの、特にネットワークの研究者ではないので、間違ってる点は指摘していただけますと幸いです。

ここで言う仮想ネットワークの定義と処理の概要

仮想ネットワークとは、物理ネットワークの構成とは無関係に、ユーザが任意にあたかも物理ネットワークを構成できる機能だ。
どのように無関係にするか。ユーザが送出したパケットには仮想ネットワークの中を通るようにアドレス類が書き込まれている。これを物理ネットワークでも通じるように変換し、目的のサーバーへパケットを届ける。受け取った側はパケットを送出時の状態に戻せば良い。大雑把に言えば、Ether Frameに送信先、送信元として書き込まれたアドレス類を、仮想と物理の境界で読み変える技術さえあれば実現できる。

パケットは書き換えてしまうと、パケット単体では元の情報に復元しづらい。そのためGREのような、カプセル化の技術を利用するのも良さそうだ。物理ネットワークを通過できる新しいパケットを作り、そのペイロードに元のパケットをそのまま載せる事ができる。実際、この処理のオーバヘッドは小さく、現実的だ。

仮想と物理の境界線をどこに設けるか

仮想ネットワーク上のノードで生成されるパケットは仮想ネットワークでしか流通させられない。当たり前だが、そのまま物理ネットワークに流しても届くわけがない。その為、物理ネットワークへ出て行く前にはパケットは物理ネットワークへの変換を完了していなければならないだろう。そう考えると、ノードの持つOS(Kernel)から出た直後、もしくはその直前に処理をするのが、差し当たって良いポイントになる。

最近ではデータセンターのホスティングサービスや、社内のコンピューティングリソースを集約するソフトウェアとして、IaaSの基盤技術を活用する企業が増えている。このソフトウェアは、コンピューティングリソースを管理するために仮想サーバを利用している事が多い。IaaSは仮想と物理の境界に立つソフトウェアだとも言える。このソフトウェアに変換の契機を作ってもらうのが良さそうだ。仮想サーバは仮想ネットワークのパケットを物理ネットワークに向けて送出するのだから、VNICの辺りで直ぐにパケットを処理できる。

こうして、エッジノードに配された仮想サーバにできるだけ近い場所で、パケットの変換をする。物理ネットワークを抜けて無事に目的となるエッジノードに到着したら、そのパケットを復元するようにする。エッジノードはIaaSの仕組みが分散管理しているのだから、パケットを正しく変換できるように、それぞれのエッジノードをIaaSにコントロールさせる。
IaaSは、あるユーザが作った自分だけのネットワーク…すなわち仮想ネットワークを定義できるようにし、そのネットワーク上にセットアップされた仮想サーバが、うまくパケット物理ネットワークに流せるようVNICの出口それぞれに仕掛けを施す。この仕掛けが仮想と物理をうまくマッピングし続けられるよう、IaaSはユーザの要求に合わせて自動的に設定を調整していけば良い。

ここでのポイントは、このシステムは物理ネットワークの設備に依存しないと言う点だ。物理から独立した形で仮想ネットワークを作れるようになる。仮想マシンもそうだった。物理マシンに依存せず、独立した形で仮想マシンを動作させられる。同じことがネットワークについても起こる。

パケットの変換に使える技術

さて、後は仮想サーバのVNICにてパケットの変換をする技術に言及することにしよう。現時点で我々が利用しているのは、GRE Tunnelだ。先ほど触れたが、パケットのカプセル化が可能であるため、物理ネットワークを通過できるパケットの中に、仮想ネットワークのためのパケットを内包させることができる。
これを用いれば、元のパケットを傷つけること無く物理ネットワークに流せる。 また、サブネットを越えないL2レベルに収まるネットワークであれば、ARPのコントロールをするだけで、スイッチの学習機能を騙す事ができるため、GREに頼らず目的の仮想ネットワークは構築できる。 このようなテクノロジを組み合わせて仮想ネットワークを作る。効果は一様だが、実現には様々な方法が考えられるので、試しながらベストプラクティスを組み立てて行く事になるだろう。

Wakame-VDCと仮想ネットワークの歩み

Wakame-VDCは、v10.11 (2010年11月リリースのバージョンと言う意味でもある)で、セキュリティグループと言うAWSと同等のパケット制御機能を入れた。Wakame-VDCにとって、セキュリティグループの実装方法はプロジェクト開始直後からずっと悩んで来た部分だ。
Eucalyptusがそれをスケールしない形で実現しているのも知っていたし、実装次第ではWakame-VDCでも課題になってしまうため、慎重に設計する必要があった。

そのため、このフェーズであらゆる調査を行った。何社かスイッチベンダーの技術者とも議論したが、彼らもわからない(もしくは、分かっているけど言えなかったのかも知れない)と言う。悩み続けている最中、たまたまAWSのセキュリティホワイトペーパーを読む機会があった。これを見る限りどこか中央集権的にネットワークが処理されているのでは無い。恐らく全てのネットワークがインスタンスを出た直後に分散スイッチのようなものでコントロールされているのではないかと言うヒントを得た。
早速そのアーキテクチャを社内で議論し、行けそうな感覚がつかめたので、直ぐに分散スイッチを設け、そこにファイアウォールを実装してみた。これをセキュリティグループのスタイルで管理できるようにし、v10.11はリリースされた。Wakame-VDCは、おそらくエッジネットワーキングが組み込まれた最初のオープンソースなIaaSだろう。このアーキテクチャはスケーラビリティが非常に高く、物理ネットワークと分離されているため、特殊な機器を用意しなくても良いのが最大の特徴だ。VLANすら必要がない。

ここでエッジノードでのネットワークコントロールの可能性がはっきりした。エッジにインテリジェンスを持たせれば、Fabricに影響無く自由に仮想ネットワークが実現できる。現に、v10.11はVLANを一切使わないため、VLANに対応していない時代の古いスイッチでも機能する。これは非常に大きいアドバンテージである。
米国でコンピュータサイエンスが専門の大学教授にもこの実装をみてもらったが、非常にユニークで面白く、他の類似するクラウド基盤には無いテクノロジだと評価していただいた。

Wakame-VDCは、エッジノードではLinuxを利用していたため、Netfilterを使って、パケットのコントロールを行うようになっている。よくよく考えてみればKernelの仕事は山積みだ。エッジノードでは仮想マシンを動かし、その上今後は仮想ネットワークも押し付けられる。CPUは、より高速かつ超並列に処理できる装置になって行くだろう。しかし、同様にネットワークも10Gbを超え、高速化して行く。CPUのワークロードを減らすには、Kernelの上にある仕事を減らさなければならない。これが課題だった。

また、早いうちから次のようなアイディアもあった。仮想ネットワークと物理ネットワークをハッシュテーブル式のデータベースで管理し、パケットが仮想と物理の境界を越えるタイミングでこのテーブルを使ってパケットの変換を行えば、仮想ネットワークが作れる、と言うもの。
ちょうどOpenFlowを見ていたエンジニアが、そのアイディアとダブらせ、こんな技術があると教えてくれた。よく読んでみるとOpenFlowはNetfilterの代わりになるだけで無く、SwitchとControllerが分離されているためKernelから遠隔の操作を可能にしている。この性質を利用してオフロードできる装置が用意された暁には、そちらに仕事を寄せられるはずだ。

ひとまず興味を持っているエンジニアにセキュリティグループをこれで置き換えられるかどうか実験をお願いした。ネットワークの基本的なアーキテクチャはv10.11から変える必要がない。OpenFlowの使い方が分かったので、そのまま実装して組み込むことにした。こうしてWakame-VDCはOpenFlowでエッジネットワーキングできるようになった。それが2011年12月にリリースしたv11.12になる。

一方でv11.12の着地点を議論しながら、社内ではネットワークの未来像の議論を並行してきた。製品のビジョンも整理し直した。v10.04リリース当初から仮想データセンターを作る事を標榜してWakame-VDCと名付けたはずだ。我々が作りたいのはクラウドではない。仮想データセンターだ。その為、Wakame-VDCの位置付けを表す言葉として、データセンターハイパーバイザーを使う事にした。Wakame-VDCは、仮想化されたデータセンターを動かせるハイパーバイザーである。ハイパーバイザーは、仮想と物理の境界線に立つ。それはサーバだけではなく、ネットワークも同様だ。これがWakame-VDCのあるべき姿なんだと思う。

さて、引き続きどんどん実装して未来へ進みたい。

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

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

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

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

補足

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

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

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

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

分散NATの仕組み

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

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

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

$ # 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

開発者募集中

$ 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

制約

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

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

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

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

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

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

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とも連携できるようにしていきます。

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

Wakame-vdcの意義

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

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

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

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

Wakameのアップデート

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

Amazon VPCをやってみた

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

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

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

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

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

当日のスライド

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

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

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

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

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

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

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

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

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

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

こんな感じ

[画像:gss_00]
↑管理者は空っぽのSheetを開いてじっと見ています。

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

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

こんなのを作ろうと言うわけです。
調べていたら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   => 'your_account@gmail.com',
    :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を無料で配布してしまって、御社はどこで儲けるんですか?」という質問をいただくのですが、この書籍「フリー」をご覧いただくとわかるかもしれません。大体この本に書かれているモデルはうちの会社も似た感じなんです。

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

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

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

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

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

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

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

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

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

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

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

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

もちろんこれにはデータセンタ側でもやるべきことがあります。
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(金)までに一度仕事内容や関わり方をミーティング形式でご相談させていただきましてその後、弊社基準で判断してからお見積もりをお願いします。

■しかく一言

設立3年目の若い会社です。
来年からは「世界のクラウドソリューションを」をテーマに事業展開していく予定です。
そのために今後は弊社で開発している"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のユーザーデータのすべてを失う

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

NFS無用

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

やってみよう!

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

注意点

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

% cat>> hoge

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

修理前にと思って代替機として準備しました。これで4万円切る価格ですよ。最大の特長は以下の通り。

1. 超軽量798g!これでバッテリ込みの重量。
2. 電源アダプタが小さい&2個も付いてくる!片方は事務所に常設。
3. 回転するタッチパネル液晶!マウス要らない。

1. キーボードが小さすぎる!でもこれは軽量化・小型化とのトレードなので正直目をつぶれます。キータッチは好き。メモを取ったりちょっと編集したり小一時間作業する分には全く問題ない作り。
2. とにかくダサい!起動時に出るギラギラとしていて旧近未来なロゴはいただけない。これは本当にひどい。筐体も「小さい=カワイイ」を否定できる底力を秘めている。
3. 本体が結構早々に熱くなる。

8ヶ月は最短です。今年1月にType-Tが壊れ、開発の一部実装を担当していたまっただ中、急遽買い替えた法人向けモデルのType-Sだったが、8ヶ月経った最近になってキーボードのShiftが接触不良のような感じになり時々効かなくなるようになった。

仕事では外出で必ずと言っていいほど持ち運んでいたので、壊れやすい境遇ではあったのかも知れない。Shiftが効かないのは色々不便なので、早速サポートに連絡した。

SonyStyleのサポート電話があまりにひどすぎる

最初のうちは、ソフトの不具合なのかハードの故障なのかを見極めたいという趣旨で質問が始まったので了解し、変なソフト入れたんじゃないかとか、リブートしろだの何だの電話で30分やりとりしていたのだけれども、一向に改善されない。調査要求も次第にエスカレートしてきて、ついにサポートから電話越しに「それではOSの再インストールをしましょう。バックアップしてください。」と切り出された。すごい!やる気だ!

さすがにびっくりです。そんなのやる時間があったらとっくにやっているだろうと思い、代替機もない状況で他に仕事もあるので、修理に出してキーボード取り替えたいだけだと伝える。すると「それでハードのせいじゃなかったら調査費に3,500円とる」と言う案内。高いとか安いじゃなくて、サポート電話の質問や要求に全て答えなきゃならない前提になっている事にガッカリ。質問攻めでオールグリーン、送ってよし!って言う流れ。例外は無いのだろう。

VAIOはこれで3台目で、製品そのものは気に入ってはいたんだけど、うーん。今回初めて法人向けのモデルを買ったのですが、それはそれですぐに対応してくれるワケでもなさそうです。個人で買うのと実質何が違うのかわからない。(サポートの電話の人も良くわかっていないようでした)ノートPCを持ち運ぶ人にとって壊れたときの迅速な対応は結構重要だと思います。

調べてみたら、SonyStyleの対応については別の内容だけれど堀江さんもイラっとしていらっしゃるご様子です。電話長過ぎ。

1. 成果中心のワークスタイルに合わない
2. ペナルティの多い会社が魅力的とは思えない
3. 守ったところでそれを評価する意味がない

成果中心のワークスタイルに合わない

なぜならば、メンバーに成果を期待する企業が、メンバーに対してルールをもって律しようとするのはある種の矛盾がある。ルールは成果に対してあまりに大きな足かせであると思う。

ルールが少ないからこそ成果を発揮するためのワークスタイルを設計できる。 自分が成果を出そうと試行錯誤したい時に、会社がそのやり方はダメだと言う必要があるだろうか?

成果を発揮するためには、自分を最適化する必要がある。自分のルールを自分で作らなければならない。これは自分のルールを他人に強要しないことでもあるわけで、善とされるルール、悪とされるルールはあくまでも当人だけの価値観なのだと思う。

だから1日1時間働いて帰ろうが、夕方に出社しようが、周囲と調整した上で自由にやって欲しい。これについて文句を言ったことは無いわ けだが、ただし、成果が上がっていない時には1時間で帰ったことに対して文句を言われることがあるというだけ。最適化のための自分ルールが間違えていると言うことを示している。

ペナルティの多い会社が魅力的とは思えない

社内のルールはただ作っても形骸化を待つだけ。
「守れなかった」→「次こそ守りましょう!」という話を繰り返すことに何の意味もない。チェックを増やそうとか強化しましょうとか言ったところで同じ事。
それを避けるため、今度はどうしても守らせる力学の議論が必要になる。つまり、ペナルティをどう設計し運用するのか、だ。

企業内においてのペナルティというのはすなわち給与・賞与との連動だろう。ただし、昨今は旧産業が新産業の創出を可能にし、より多様化されてきている中で、それなりに「仕事を選択できる時代」にあると思う。
メンバーに給与・賞与をそもそも低く設定している状況下では、これ以上に「選択されなくなる条件を増やす」ことを行うのは得策ではないように思える。

守ったところでそれを評価する意味がない

ルールとは「成果への足かせ」であり「ペナルティとセット」であるとは先述した通りなんだけど、今度は逆にこのルールを守った人をどう評価すれば良いかということにもなる。

足かせを乗り越えるエネルギーで売上があがっていくわけでは決してない。ある者は与えられてしまった足かせを振り払えないまま、その閾値を超えることをあきらめ、ルールに従うことが仕事であるかのように振る舞うようになるだろう。
そんな状況で企業が「成果を出せ」「イノベーションを起こせ」と叫ぶのは矛盾ではなかろうか。こうした事象の一側面が、大企業病の何かと共通している気がしてならない。

ここで言うルールは約束とは違う

そもそもペナルティのあるものは守るべきだと思うが、それって大抵はルールじゃなくて約束に類するものだったりする。お客様とのミーティング、打ち合わせ予定、納期...などなど。

元は勤務時間の議論だが、何でもルール化して従うか否かを善し悪しとするのではなく、個々はもちろん、組織が成果を出すためにどうあるべきなのかという観点で柔軟に考え直すことが大切なんじゃないだろうか。

実は4年前に全く同じ事考えて少しだけ実装してみたことがあります。
いつか時間ができたらコードを増やしていこうと思っていたのですが、気づいたらすっかり時間が経過していました。

以前も書きましたが、第二のMesaになることを想定していたので、寿命は長くて1年。ブラウザの基本機能として組み込まれたらすぐに置き換えられるだろうと考えていて、あまりモチベーションが沸かなかったのは事実です。結果論ですが実際はこうして4年あったので、ある程度でも実装を進めていたら面白かったのかなとは思います。

今回大きく変更されたのは以下の3つ。

1. Wakame masterへのコマンド発行がWeb APIになった
2. Agentが必要ないリソースを定義できるようになった
3. 対応プロダクトが増え、MySQL Slaveの追加をサポートした

• MySQL_Slave
• Nginx
• Elastic IP
• Elastic Load Balancer

バグレポートなどよろしくお願いいたします。