[TS-5301]Continuous Integration in the Cloud with Hudson
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5301&yr=2009
Hudsonをクラウドで使うためにやった工夫などを紹介するセッション。
前提知識として、↓のエントリの内容を押さえておくと良い。
主な観点は3つ。
クラウドコンピューティングのパターン。 - せろ部屋
1. プロビジョニングの方法、要するに「OSやミドルのデータや設定情報」を、どう管理するか。
2. モニタリングの方法。性能や障害情報を、どう監視するか。
3. リソースの管理方法。リソースといってもCPUやメモリじゃなくて、IPアドレスやマシンIDなど。
HudsonのMasterやSlaveをクラウド（Amazon EC2）上で動かそうという話。
繰り返すようだけど、こちらでクラウドと言えば、Amazon EC2やSun CloudのようなIaaSだ。
まず、Slaveのプロビジョニングについて。
Hudsonでは、MasterからSlaveを（PXEで）ネットワークインストールできる。
また各Slaveでは、JDKやMavenなど、必要なものを
インターネットから自動に取ってきて、追加インストールすることができる。
追加インストールでは、apt-getなんかも使える。便利！！
＃ Slaveが取りに行くのか、Masterが取りに行くのかは、再確認しておきます。
＃ Masterが取りに行った方が、効率的だと思うので。
次は、リソース管理。
複数のJOBが、Windows環境のSlaveを利用したい場合に、
Windowsが入ったSlaveが複数あるにも関わらず、片方に処理が集中していては、効率が悪い。
Hudsonでは、Slaveにタグをつけることができて、たとえば「Windows」とタグをつければ
自動的にWindowsの中から、利用されていないSlaveを探して、JOBを割り当てることができる。
そして、モニタリング。
Hudsonでは、実行されているJOB数と、実行可能な最大JOB数を監視していて、
空いているSlaveをシャットダウンして、Slaveが足りない時に起動することができる。
こうすれば、必要十分なだけAmazon EC2のリソース（＝費用）を利用することができる。
特にHudsonの処理は、短時間に負荷が上昇しやすい特性のため、
このようなモニタリングのおかげで、費用を必要十分に抑えることができる。
HudsonにはAmazon EC2プラグインが用意されていて、上に書いたようなことは
絵空事ではなく、実際に可能で、デモもしていた。
日本ではクラウドの理論や評判ばかりが先行していて、
なかなか具体的な利用例が聞けなかったんだけど、
クラウド関係のセッションをいくつか聞いたおかげで、実際の使いどころがよく分かった。
こういう利用例を見ていると、GAEJはあまりにベンダーロックインが強すぎて
（HudsonのSlaveを、わざわざGAEJで実装しなきゃいけないわけで）
ちょっと扱いづらいんじゃないかな、と思うようになってきた。
もっと率直に言うと、GAEJはナイ。
