Groovin' High

最近、時間があれば何かしら運動してるんだけど、ちょっと激しく動くのが好きなんで、時々思いっきり吹っ飛んだり、転倒したりする。（関係者のみなさん、激しく危険な状況ではないので、ご心配なく）

それでも、何故か擦り傷程度ですむ。「あっ！」という間に体は宙に舞って、みたいな状態で、地面に叩き付けられたとする。それでも、なんとかなってる。なぜかっちゅうと、それが「受け身」。

受け身にも、柔道流受け身っつうのと、少林寺拳法流受け身っつうのがある。

柔道流は、体の側面から吹っ飛んだ場合、もしくは、回転しながら飛ばされた場合。そんで、少林寺拳法流は、体の真っ正面から吹き飛んだ場合。つまり顔面から地面に飛ばされたような場合だね。

柔道は有名だから説明不要として、少林寺の場合、体が地面に落ちる瞬間に、両手で勢いを一瞬和らげる。そんで、体を丸めて転がる。まぁ、そんな感じ。

高校の少林寺拳法部は、校舎の屋上で練習してたもんだから、受け身の練習も、コンクリートの上でやっていた。後輩を５人くらい寝かせて、助走つけてその上を頭から飛んで、頭から落ちる寸前に受け身をとる。なんていう練習を、遊びがてらやっていたんだな。

これ結構強力で、高校時代に結構高いところから、真っ逆さまに落ちたことがある。でも、擦り傷一つしないでなんともなかったのは、この受け身のおかげ。

受け身の特徴は、「あっ！」と思った時は、もう受け身を取り終わっていること。体に染み込むまで、繰り返し練習した賜物。

ちゃんと練習すれば、「俺、もしかして不死身なんじゃないか」と勘違いするほど、見事に決まる。

いや、だから、あの。一応、大人だから。そんなに危ない事はしてないって。 

所謂、「クラウドコンピュータ」を目指してみると、すぐに気がつくことがある。「仮想化」で考えを止めないで、もう少し考えれば誰でも気がつく事。

仮想化された環境っていうのは、ハードウェアのソフトウェア化というか、サーバーイメージをファイル化して保存しておけるところに特徴がある。ソフト化されてるわけだから、複製が容易にできる。つまり、「全く同じサーバーイメージ」から「複数のサーバーを起動」することが、とても簡単にできるってわけ。

同じ構成のサーバーを、必要に応じて大量に複製して動作させる。これ、別の言い方をすると、「同じ動作をするサーバーを、必要に応じて大量に投入して並列的に利用する」、つまり分散処理つうわけだ。

分散処理っていうと、Hadoopがすごい人気で、特に、理解しやすいMapReduceを実践でも使い始めている人たちがとても多くなって来た。

MapReduceは、簡単に言うと、MapフェーズとReduceフェーズという２つのパーツをプログラミングするだけで、分散処理が行えるというもの。

Mapフェーズでは、あるデータを、Keyと何らかのデータへの仕分け処理をする。勿論、分散して動いているわけだから、同じようなことを沢山のサーバーで同時に処理する。つまり、結果は分散している分、沢山できてしまうわけだ。HadoopのMapReduceライブラリは、 こうして沢山できてしまう結果を、まとめてソートしてくれる。なので、Reduceフェーズのプログラムが動き始める時には、受け渡されるデータは、Key順にソートされ、Keyの固まり毎になっている。そういう前提になってるんだったら、Reduceフェーズはとても対応しやすい処理になるよね。

原理わかったところで、どういうところで使えるのかの一例。例えば、経理系締め処理。

Mapフェーズでは、何らかの元データから、勘定科目と金額に変換する所謂仕訳処理を行う。そいつが勘定科目毎にソートされ、かつ勘定科目毎の固まりになってReduceフェーズが呼び出される。あとは集計処理をすれば、ほら、締め処理になるでしょ？現実は、もっと複雑なんだろうけど、商品毎とか、地域毎とか、切り口変えてMap & Reduceすれば、管理会計的なことは解決できることが多いように思う。

こんな風に、クラウド環境を利用することの、最大のメリットは、分散処理の恩恵を、簡単・安価に利用できることにあると思うんだ。

そんなこと言ったって、一企業の環境じゃ、プライベートクラウド作ったって、仮想サーバーを数百台も用意することなんてできないし。てなこと考えてしまうかもしれない。でも、実際、大抵の企業は、仮想サーバー10台〜30台くらいで十分効果を出せると思うんだな。

「サーバー統合」はいいけど、折角統合してサーバー台数を弾力的に運用できるようになったんだったら、次のフェーズは、分散処理の効果を確かめるべき。

で、最後に。分散って言っても、Hadoopだけじゃないし、MapReduceばかりじゃなくて、もっともっと色んな方法があって。難しくもなく、コストもほとんどかからない。

要するに、知ってる人は、より大きく成功して、知らない人はお金ばかりかかって、人並みの性能しか出ない。そういう時代なんだと、つくづく思うよ。 

ＡＷＳ（つまりＡｍａｚｏｎ Ｗｅｂ　Ｓｅｒｖｉｃｅね）使っている人は多いと思うけど、日本で言われている「クラウド」なるサービスと、Amazonがやっていることは結構違う。

ＡＷＳの最大の特徴は、ＡＰＩが公開されていること。つまりどういうことかっていうと、サーバー台数を「今」追加したいと思ったとする。そうすると、アマゾン君に対して、「えー、登録しておいたサーバーイメージ使って、ちょっくらサーバーを５台追加してくんない」てなことを、自分で制御できる。もちろん、自分のプログラムから制御してもいい。

てなこと話すると、「クラウドって看板出しているとこって、そんなの当たり前なんでしょ？」と誤解している人がいるけど、これが意外で、たぶん国内のクラウド事業者は、誰もやってないんだな。（内部的にＡＰＩがあるか、じゃなくて、利用者側が使えるようになっているかってことだよ）

外部に公開しているＡＰＩが無いっつうことは、「スケールするシステム」なんて作れないよね。だって、「スケールするタイミング」は、自分で決めるんでしょ？データセンターの都合じゃなくてさ。

「そんなぁ、勘弁してよぉ。」って言いたくなるかもしれないけど、なんとなくそれで済んでしまっているのはなぜなんだろう。

そもそも、「サーバー台数を動的に増減」したら、それでいいんのかっていうと、それはちょっと違う。当たり前だけど、サーバー台数を増やしても、それがシステムの性能強化につながるためには、「そうなるように」システムを設計しておかなきゃならない。それでも、実際に台数増減したら、「あっち」と「こっち」の設定を変更変しなけりゃ、そもそも追加したサーバーにトランザクション流れないしね。

こんな単純なことだけど、そうなるようにつくられてなけりゃ、｢オンデマンドでサーバー増えますです。」って言われても、何にもなりゃしない。

一方で、アマゾン君のような、簡単にサーバーリソースの増減を制御できる環境を駆使して、今までではできなかった「素敵な」システムを、「安価に」構築することに挑戦し、成功している人たちは、とても、とても多いわけで。（２回言ったからね）

だからこそ、「なんでもクラウド」じゃなくって、本当の「価値の転換」に対応しなければならない。そういうタイミングなんだと思う。

最近、「クラウド」に絡んだ話が多くて、おかげで色々なものに出くわす。

よくあるのが、「プライベート・クラウドなんですわ」とかいいつつ、単純に仮想化の仕組を売込むもの。ちょっと、それはどうかなー。って思うのは、以下のような手口。

仮想化すれば、サーバー統合ができて、物理サーバーが減ります。だからコスト削減につながります。とか言っておいて、結局仮想化するためのソフトウェアが物理サーバー当り100万円近くもして、しかも諸々便利にするために、高価なスイッチングハブとかストレージを買わなきゃならない。結局、物理サーバー買って増設するのと値段変わらないんじゃないかてなぐらい。

じゃぁ、何が安くなったかというと、物理サーバーが減って、スペースが産まれたこと。だから、もっとサーバー買えます。

ほらほら。結局、こうしてギリギリ　ハードやらソフトやらを買うはめになる。

じゃぁ、仮想化の意味はないのかっていうと、そういうことではなく、仮想化に求めていることは、そんなに製品をジャカジャカ買わなければ実現できないことじゃないということ。

これからユーザー企業だろうが、データセンターだろうが、ベンダー論理に飲み込まれないで、自力で判断できる企業が、より強くなっていくんじゃないかと思う。

ソフトウェア会社の決算短信を見てると、相変わらず開発が上手くいってないプロジェクトは多くて、特定の会社の問題というよりも、なんかそういう時代なのかなぁと思ってしまう。そもそも、プロジェクトが始まった段階では、発注者側も開発者側も、最終的な姿を正確には見通せていないプロジェクトが多いようにも思うし。当たり前な開発を、当たり前にやるのではなく、いつもどこかに「チャレンジ」が含まれていて、その割には、「チャレンジ」の具体策は、それほど明確じゃなかったりするし。

最近は、自分が関わる「開発絡みのプロジェクト」というのが幾つかあって、全てAgileで進めている。とは言っても、まぁ自分流の進め方だったりするので、教科書的な素晴らしいやり方かどうかわからないけれど、そこで実感していることが、今の諸々の問題を解く鍵があるように思う。

結局、ウォーターフォール開発って何なのよ、って言われたら、「資産を作り上げて行くプロセス」と言えるんじゃないかと思う。つまり「仕様書」だとか、「設計書」だとか、「ソースコード」とか。そういう資産を順番に作って行く過程を大切にするっていうか。

資産を順番に組み立てて行けば、最後はゴールに到達するのかっていうと、それがそういう訳にはいかないから難しい。だって、「ゴールがどこにあるのか分からない」状態で開発をスタートさせなければならないことが、マジであったりするからね。

じゃぁ、どーすんのさ。ってことになるんだけど、だから「ゴールがどこにあるのかを探して行く」ことなんじゃないかなと思うんだよ。

ウォーターフォールが資産を作って行くことを軸に組み立てるのだとしたら、Agileは、「人の成長」を軸に組み立てて行くのだと思う。（少なくとも、自分の周りで起きているAgileの成功ポイントはそういうこと）最初は、全てを見通せていない状況でも、小さな目標を立ててそこに到達することを目標に頑張る。重要な点は、その小さな目標に到達すると、少し見えてくることがある点。そういうことを何回か繰り返すと、はっきりと見通せることがあるから、そこでアーキテクチャとか、やんなきゃいけないこととか、もう一度見直してみる。「今まで作ったコードとか、捨てちゃえ」ってよく言うんだけど、言いたいのは「資産」に縛られるな。ってこと。生産性の高いプログラミングテクニックを駆使して開発すれば、成長していないチームが作った資産を継承するよりも、成長したチームが資産を再構築する方が、よっぽど効率がよかったりするからね。

でも、こういうやりかたって、プロジェクト内部を見通せてないと、なんか不安だしドキドキしちゃうかもしれない。だから、受託開発というよりも、自分ところの製品とかを開発するには、最高の方法だと確信している。

ということは、受託開発でも顧客が「その気」になってやれるんなら、最高の方法ということになるわけだけどね。

自分ちの製品を作る時には、最高の方法を選択して、ヨソのシステムを作る時には、分の悪い方法を選択するなんて、やっぱなんか変だと思うんだけど。まぁ、しゃぁないのかな。 

とうとうというか、当然というか、人民元が切り上げられる方向に、また一歩踏み出した。

中国というと、安い人件費を背景に、低価格な生産を行う拠点として活用されてきた。ソフトウェア業界も同じような発想で、中国開発拠点を次々開設してきた経緯がある。

だけど、実際に中国へ行くと、沿岸部は年を追うごとに普通の先進国化してきており、上海なんて東京と全くひけをとらないんじゃないかと思うことすらある。

去年、中国で活動している日本人ビジネスマンから聞いたんだけど、上海のエンジニア単価は、下手したら福岡のエンジニア単価よりも高いんじゃないかということだ。

経済が活発化し、事業が成長に乗ってくれば、当然労働者はより良い生活のために企業を選択するので、給与は増加傾向になる。所得が向上すれば、豊かさを求めて消費が行われ、内需が拡大する。豊富な人口を背景にするなら、内需の拡大が好循環してこそ、中国は本当に豊かな国になっていくのだと思う。

だからこその流れが、人民元切り上げにもあらわれているのだと思う。決して、アメリカの圧力に屈した訳でもないんだろう。

さて、こうなってくると、「中国だから安いんだろう」的な理屈は、全く通用しなくなってくる。知り合いの会社は、中国に「安さ」ではなく「能力」を求めて拠点を運営している。日本の中だけで通用するレベルの能力ではなく、世界で通用する高い能力。（サッカー日本代表みたい）

Agileを実践することで有名になったPivotal Lab.社で、こういうオフショア開発について話をしたことがある。安いエンジニアを活用して、コスト効率を高めるという話をどのように思うか。という話。

CTOのIan曰く「安いエンジニア単価を元にオフショア開発を行うことが、効率の良い開発につながるとは思えない。確かに顧客はコスト効率を、今まで以上に求めて来ている。だからこそ、安い単価を求めすぎて効率を犠牲にするより、徹底的な開発効率を求めた開発スタイルを追求しなければならない。」だから、Agileな開発スタイルは、今まで以上に重要なのだということ。

結局、他人の所得水準が低いから、いつまでも安いままでこき使って「一儲けしよう」なんて魂胆は、うまくいけばいくほど、いつまでも続かないという至極当たり前の流れっつうわけだ。 

HBaseの構造を理解すると、「分散」であることの合点がいくところがある。例えば、ソートされたKey。

HBaseの各行は、Regionという場所に保存されている。

Tableを作ったばかりなら、Regionは一つだけ。Table一つにRegion一つ。ここにデータをputするたびに行が追加される。

冒頭の話。行は、Key順にソートされて保存されている。

だんだん行の数が多くなってきて、一つのRegionでまかない切れなくなってくると、Regionを分割して、二つのRegionでデータを受け持つ。

このとき、各Regionには、当然先頭行と最終行がある。行はKey順にソートされているから、欲しい情報がどこにあるか。もしくは追記すべき情報はどこに保存するのか。こういうことは、先頭行と最終行のKey情報を見ればわかる。

こういう情報を、「.META.」というテーブルに保存して管理してあって、これがRegion毎にある。そして「.META.」に関する情報を、「-ROOT-」が管理している。

Regionは、同一のマシンに複数存在するかもしれない。そしてRegionは、場合によって移動するかもしれない。

もし見当たらなければ、一つ戻ってたどり直せば、居場所はわかる。

単純に言うならば、ある情報をアクセスしたければ、「-ROOT-」を見て、アクセスしたいKeyがどの範囲にあるかによって対象とすべき「.META.」テーブルを探す。そうすれば、Regionを保存しているRegionServerがわかるので、そこに要求を出す。

つまり情報量が増加しても、アクセス数は比例して大きくなる訳じゃないから、レスポンスが急に劣化することはない。そして、利用状況を見ながらRegion分割をしていくことで、負荷分散を実現することもできる。

シンプルな構造だけど、シンプルさを思い切って許容することで、今までに無い性能を手にすることができる。

MapReduceもそうだけど、そういうことなんだろうな。と思う。 

Key Value Storeと聞いたら、KeyがあってValueがあるんだから、昔のISAMみたいなもんだ。てな具合に解釈してる人がいるかもしれないけれど、それは「KVS」という言葉の響きだけに影響されているように思う。HBaseのサイトでは、次のように説明している。

HBase ia an open-source, distributed, column-oriented store modeled after Google' Bigtable: A Distributed Storage System for Structured Data by Chang et al.

「column-oriented store」というところがミソな訳で、ここをちょっと考えてみたい。

KeyとValueの組み合わせだけで考えるなら、例えば「Key:社員番号」と「Value:名前」とか。「Key:製品番号」「Value:価格」とか。

もう少し考えるなら、Valueが構造的なデータだとする。

key:社員番号 => value:名前　じゃなくて

key:社員番号 => 
  key:名前 => value:xxxx,
  key:部署 => value:xxxx

つまり
'A0012' =>
 name => '田中'
 div     => 'sales'

てな具合に表現する。さらに構造化するなら

key:xxxx(社員番号）=> 
  key:名前 => value:xxxx,
  key:部署 => value:xxxx

つまり
'A0012' =>
 name => '田中'
 div     => 
   unit => '営業本部'
   sec  => '営業推進部'

とか。

HBaseの場合、こうしたValueの構造を、column familiesと呼んでいて、一つの行に対して、 複数の列（column）を構造的に配置することで、表形式のデータ表現を行えるようにしている。
HBaseが、column-oriented storeと言われる所以は、このcolumn familyの構造が、設計上の重要なポイントであり、パフォーマンス・チューニングも、ここをどのような構造にするかで左右される。

大きく捉えるなら、Hash構造なわけで、このあたりが分散構造を可能にしていることにもつながっている。

この話は、またあとで。

商用ソフトでデータセンターをクラウド化した人から、価格を聞いてビックリしたことがある。なんというか、やれやれだ。

それで買ったソフトの機能をどのくらい使っているのかと聞いたら、使っているのは一部なんだそうだ。

仮想化だけだったら、KVMで十分だろうし。後はEucalyptusかな。データセンター周りだったら他にも候補はあるし。migrationとか、autoscaleとかだったら、色々と方法もあるし、Wakameもあるしな。

あ。そうか。色々組み合わせなきゃいけないのか。

組み合わせることができない人が、莫大なお金を払って。。

ま。GoogleもAmazonも、そういう所にお金を払っている訳じゃないから、そういう所にお金を払っている人は、そもそも彼らに匹敵するサービスは作れないと考えるべきだな。

「なんでもアメリカに委ねていいのか」 的な議論があるけど、結局はなから勝負になっていないことしてて、何してるんだろうと思うよ。

会社が品川に移転したのをきっかけに、スケートボードで通勤している。スケートボードと言っても、普通のスケボーで何キロも走るのはしんどいので、使っているのはロングスケートボード。

これは元々サーフィンの陸トレ用につくられたもの。スケートボードというよりも、サーフボードっぽい動きをする。だからサーフィン風にのる。

 

当たり前だけど、全く平坦な道なんてほとんどない。下っていたり登っていたり。片側が上がっていたり、凹んでいたり。

だからそういう斜面を波だと思って、体全体を使ってリズミカルに走破していく。サーフボードと同じなんで、アップス使えばどんどん加速することだってできる。 

動力は、ほとんどウェスト周りの筋肉。だからウェストは、あっという間に引き締まる。

これで、東京だったら品川から銀座もしくは六本木くらいだったら、十分移動圏内。福岡だったら、天神から百道かな。

本当の海だったら、一時間も波に乗り続けるなんて不可能だし。片手で持てるし、電車もバスも持ち込めるし。シェイプアップもできるし。難点は、汗かくことかなぁ。だから着替えのTシャツは、何枚も持つ。

ほんと、おすすめです。 

うちの会社が開発したサービスが、新聞で報道されたので、ちょっと正しく訂正しておきます。

もともと九州大学で開発された無線LANの中継機があった。この装置は、無線LANの電波を中継して、無線のカバーエリアを広げるというもの。この機械に、うちでちょっと変わったソフトウェアを組み込んだというわけなんだな。

無線LANっていうのは、端末とルーター間では通信をしていなくても、相手の存在を検知することができる。例えば、iPhoneをもって通過すると、無線LANルーターは、何らかの機械が近くに現れたことがわかる。勿論、電話番号だとか、持ち主だとか。個人を特定する情報は全くわからないけどね。

 で、ルーターがある程度の密度で設置されていると、複数のルーターが、「この端末、こちらから見えてます」という情報が、報告されるわけ。これを、外部のサーバーで計算すると、緯度経度とフロア、そして目撃された時間がわかる。

実験レベルでは、誤差３mという極めて高い精度が出ている。しかも、端末側にはソフトウェアなどを入れる必要は一切ない。 つまり、電波だけ出していれば位置を捕捉することができるというわけ。 

この情報は、継続的に収集することができるので、それをトレースしていくと、どこから現れてどこに立ち寄って、どこから出て行ったかがわかる。

単純に電波だけ出していればいいので、そういうペンダントみたいなものがあれば、位置を掴むためのタグとしてもつかえる。

てなことを、九州最大の商業施設「キャナルシティ」で実験しようというもの。

収集されたデータは、分散ファイルシステム上におかれて。てなことになる。 

福岡でのイベントが続いていたので、東京での開催は久しぶりになってしまった。この間もろもろあり、「クラウド」っぽい話に関わることが多くなってきた。

ひと頃、「Googleを支える技術」というキャッチで有名になったMapReduceだとかBigTable。そのオープンソース実装として有名な「Hadoop」。

所謂、どでかいマシンを用意して、「高性能ですよ」という世界ではなく、小粒でも沢山のマシンが分散して処理を行うという世界。だから、性能をあげるにはマシン台数を増やせばいい。

こうした技術が、コンピュータベンダーではなく、GoogleだとかYahoo!だとか。コンピュータの利用者である企業から生まれてきているところに考えなければならない時代の変化があると思う。

革新的な技術は、時としてビジネスにも革新をもたらす。

だから今回の勉強会。

多くのコンピュータが分散して大量のデータを処理する技術である「MapReduce」について、ゲームを通じてわかりやすく理解する。コンピュータの知識もいらないし、ましてやプログラムを理解する必要もない。仕組みを理解して、ビジネスを考える。

そんな勉強会を行います。

参加は無料。興味のある方は、是非いらしてください。


開催概要

１．日時：10月17日（土）13時〜18時

２．場所：株式会社イーシー・ワン　本社会議室（品川に移転しましたので、ご注意ください）
東京都港区港南1-6-34東京日産ビル8階
tel. 03-6710-1221

３．持ってくるもの：筆記用具（サインペン）、夢、情熱

４．費用：無料

５．応募方法：以下のサイトから申し込みをしてください。

http://form1.fc2.com/form/?id=472011
 

なんか驚くほど多くの人が、「クラウド」について話題にしている。

あっちの話から、こっちの話まで。この言葉を使って語っているものがあまりにも幅広い。

SaaSとかPaaSとか。つまり「サービス化」したら「クラウド」なのか。それに、仮想化。仮想化してたら「クラウド」なのか。

GoogleのGMailは「クラウドだよねー」という人はいても、大塚商会がやっている「アルファメール」は、クラウドと思っている人はいない。（関係者の人ごめんなさい。少なくとも私の周りではそんな感じ。）

「サービスが仮想化」という言葉も、なんだか怪しい。「実際にはどこで誰がサービスをしているかわからない状態」を「仮想化」だという人がいるけど、今こうやって使っている電気だって、誰がどこで発電したものなのかわかんないし、ポストに投函した葉書は、誰がどうやって相手に届けているのかわかんない。つまり世の中の大抵のことは、実は誰がやっているのかわかんない状態で成立している。今日の昼飯、パスタだったんだけど、そういや誰が調理しているのかわかんなかったもんな。
 
そんな当たり前すぎることを、あらためて「仮想化」だとか「クラウド」だとか言うことには、ちょっと抵抗がある。

じゃぁ、どうなのか。ちなみにAmazon EC2の「E」。つまりElasticという言葉を辞書で調べてみた。

「伸縮性がある」という意味以外に、人の感情とかに使って「不幸があってもたちなおる」という意味があると研究社辞書には書いてあった。

伸び縮みする柔軟性と、トラブルがあってもこけない。なんかしっくりくるのは俺だけかな。

ちなみに名詞で使った場合、「輪ゴム」になるそうだ。輪ゴムかぁ。。 

久しぶりのエントリ。

この間いろいろありまして。ホットな話題から。

タイトルの通り、Rubyビジネス・コモンズがNPO法人を持つようになりました。正確に言うと、今まで通りコミュニティとしてのRBCは、そのまま継続。それとは別に、NPO法人としてのRBCが誕生した。

そのココロは何かというと、活動を色々やってくると、福岡でやったコンテンツを東京でも。とか。そういうことをもっとやると、人同士の交流が生まれて、もっと面白くなるなって思うんだよ。

そんなことをやろうとすると、ボランティアで協力してくれる人はいても、さすがに飛行機代とか宿泊費とかは足枷になってくる。だから、そこら辺はなんとか賄えるようにしたい。そうすると法人を持っていた方が、お金のやりとりもしやすいし、経理も明瞭になるし。

昨日、法務局に再度訪問して、これで登記手続きは完了。

無事NPO法人としてのスタートです。

キリンとサントリーが経営統合するというニュースは、この何年かで最も驚かされたニュースだ。

どちらの企業とも、それなりにつきあいがあるので、両社の社風の違いとか諸々考えると、「それでも一緒になった方が良い」という経営判断の重さを感じる。

報道されていることを聞くと「少子高齢化」によって日本市場に限界があり。というようなことを言っている。

つまり、日本の人口が減少しつつある状況、市場は必然的に右肩下がりになる。一方、世界の人口を見ると、世界は拡大する途上にある。

「だから」ということなんだろうけど、これはとても重要なメッセージだ。

そんなニュースが流れていた日に、ある中国ソフトウェア企業幹部と食事をした。

その会社は、これまで日本のSI会社経由で日本の仕事を受注することが多かったらしいのだけど、先日顧客から直接取引をしたいと言われたらしい。でも、途中に入っていたSI会社にお願いしたいこともあるらしく、今ではその中国企業経由で、日本企業に発注しているらしい。つまり逆転しちゃったということ。

冷静に考えてみれば、別にどこの国の企業だろうが、能力と価格があえば、仕事を受注するのは当然。こんなことは、これからもっともっと普通の事になるんだろうな。

内需は減少しつつ、外部から同業者が次々に参入する。

だからどうするのか。その答えは、キリンとサントリーが感じていたことに符号するのだと思う。

国内だけでビジネスをしてきた企業にとって、海外に向けてビジネス展開をはじめるのは、並大抵のことではないと思う。でも、それしか大きく発展する未来を描けないとしたら、一体どのような行動をするのか。これは、よく考えなければならない。

RBCの勉強会は、いつも円陣を組んではじまる。

この円陣について、この間話をしていたら、「円陣組む系」の運動部に所属したことのない人が、なんか誤解していたみたいだったので、ちょっと解説しとこうかなと思う。あー、ちなみに、野球部円陣です。

１）円陣は、誰が組むの？
円陣は、選手が組むもの。監督だとか、コーチだとか。そういう「指導者」的な人は、円陣には入らない。「円」陣というくらいだから、円になってお互い向き合うので、どこにいると偉いとか、そういうことはなく、みんなは同じ仲間として向き合う。

２）いつ組むの？
野球部の場合、試合開始前に守備練習があって。そんで時間になると一旦ベンチに入り、主審の合図でホームで一列になって相手と向き合う。相手チームと審判に挨拶をして試合開始。
そして、さぁ試合という直前に円陣を組む。

試合が佳境に入ってくると、攻撃前に円陣を組むというのもあり。

３）円陣では何をやってるの？
今日の試合は、自分たちにとってどういう意味がある。とか。鉄壁の守備をするから、一人で頑張って押さえようとせず、打たせていけ。とか。要するに、これまで苦しい練習を乗り越えてきた仲間が、一つになって勝利しよう。とか。そうやって気持ちを一つにして、失敗とかあっても一緒に乗り越えていくことを確認しあっているとも言えるんだな。

RBCで勉強会をはじめようとした時、集まった人同士が一体感を持って学べたら、ちょっと素敵なんじゃないかなと思ったんだよ。最初のうちは、勉強会コンテンツ作りも慣れなかったし、集まってきてくれた人と自分との間は、全く同じ試合に臨む選手同士と同じだったわけで。だから自然と「こりゃ円陣かもな」って思ったわけ。

で、やってみると、びっくりするほど自然に「円陣」になったし。あー、なんか助けられたなぁ。って思った。

それからどの場所に行っても、勉強会のはじまりは「円陣」という習慣になった。同時に、どの場所に行っても、「円陣組む系」運動部に所属した人たちは必ずいて、普通に受け入れられていくのを見るにつけ。円陣文化は、日本全国に根付いているんだなぁって思った。

で、RBC。今では、都度都度色んな人が声をかけてはじまる。これやんなきゃ、はじまんないよー。とか。円陣をuStreamで流してよ。とか。なんか、祭っぽくなってきている。

あ。ちなみに、シリコンバレーでも円陣組んだことがあるよ。日本人だなぁって感じた瞬間でもある。

えー。数日前に、オーストラリアから私の携帯に電話した人いますか？
おっかなくて折り返し電話してないけど、間違いじゃなければ、メールください。

IBMやらSunやらが、「クラウドの標準化」を進めようとしたところ、最大手のAmazonから断られたことがあった。理由は、「標準はベンダーが決めるのではなく、利用されたものが標準になっていく。」ということだった。先行するAmazonならではの発言だよな。と同時に、AmazonはIT業界の人じゃなく、小売業なんだよな。って、思い直したりもした。

確かに群雄割拠するクラウドが、標準的なAPIで利用できるのだとしたら、とても便利なことだと思う。しかし、複数の会社が集まって標準を決めるよりも、Amazonが推し進めているAPIにみんながあわせてしまうというのも、一つの方法かもしれない。

そんななか、Eucalyptus Systems, Inc.という会社が、面白いチャレンジをしている。この会社は、Amazonのように動き（といっても、EC2とS3とEBS）、Amazonと同じAPIを持つクラウドソフトウェアを開発した。しかも、オープンソース！製品名は、Eucalyptus。

つまり、「Amazonクローン」というわけなんだな。

APIが同じなんで、Amazon toolkitがそのまま使えたりもする。しかも、アプライアンスは、AMIをそのまま使える。

Amazonクラウドの管理サービスを展開しているRightScaleは、自社のサービスを、このEucalyptusにも対応したりしている。

Eucalyptusを使えば、プライベートクラウドをAmazonクローンにすることができて、同じ管理ツールを使えるのなら、自社プライベートクラウドのバックアップに、Amazon自体を置くこともできるんじゃないかとも思う。

こうやって、データセンター自体、仮想化されていって、横断的に利用できるようになるなら、ますますハードなんて購入しなくてよくなっていくのかもね。

つくづくソフトウェア業界を、従来の枠組みだけで見ちゃいけないと思う。

今月の11日だったかな、New York Timesが、Rubyのライブラリをオープンにしたことを発表した。

New York Timesと言えば、Amazon EC2とS3を使って、過去130年分の記事データを、たった一日でPDF化して、かけたコストが滅茶苦茶安かったと評判になった会社。短時間で終わった理由は、Hadoopを使って100台の仮想サーバーをぶんまわしたから。Hadoopの並列処理機構をつかったので、台数が増えると性能が上がるという訳。聞いたところによると、従来の手法を使ったら、完成に数ヶ月かかったとか。しかも、かけたコストは、20万円もしなかったとか。

しかも開発したのは、たった一人のエンジニア。

そんな経験を活かして、ノウハウをRubyで実装し、オープンソースにしたのが、mrtoolkit。

いわゆる大規模なバッチ処理を、一人で作って。Amazon使って、多分インフラ構成するのに数時間。データ送り込むのに数時間。処理するのに数時間。終わったデータ受け取るのに数時間。

「人月の神話」どころの話じゃないよな。

しかし、この現実を受け入れていかないと、逆からみたらアホみたいだよ。本当に。

Elasticという言葉は、「伸縮性のある」という意味だということを、Amazonのおかげで覚えた。でも、実際のEC2は、何もしなければ単なるサーバーであって、自分で工夫するか、第三者サービスを使って伸縮性を担保しなければいけなかった。

なんだー。これでelasticとか言っちゃっていいの？と思っていたら、今年のはじめくらいかな。elasticな機能を追加すると発表したのは。

で、「とうとう」というか、「ようやく」というか。Elasticなサービスがスタートした。

新しく加わった機能は、

１．Amazon Cloud Watch
２．Auto Scaling
３．Elastic Load Balancing

の３つ。

Cloud Watchは、その名の通り、実行中の仮想サーバーを監視するもの。CPUやDISKの負荷、そしてネットワークの利用状況などを監視する。Auto Scalingの設定をしておくと、負荷状態が一定水準を超えた場合、自動的に別の仮想サーバーを起動する。だから、Spikeが発生しても、Amazonのリソースを使って対応していく。もちろん、負荷が下がってくれば、起動した仮想サーバーを停止させるので、不必要にコストがかかることもない。

最後のElastic Load Balancingは、ズバリ負荷分散。

Auto Scalingの恩恵にあずかる前に、そもそも負荷が混んできたら複数のサーバーで受け答えすることで、スループットを安定化させる。もちろん、そのおかげで、単一サーバーの障害が、全体障害につながらないような構成をくめる。

Amazonの発表によると、Elastic Load Balancingは、同じデータセンター内で分散するだけじゃなく、異なるデータセンター間で分散させることもできる。

現在Amazonは、アメリカで3カ所のデータセンターを運用しているから、この3カ所を使うことになる。同時に、EUのデータセンター2カ所の利用も、近々行えるようになるらしい。

前から噂のある、「そろそろ日本でデータセンター事業を開始するらしい」という話。最近は、妙に生々しい話も伝わってくる。