ITPro Expo 2009

に行ってきました。
展示の内容は大したものはあまりありませんでしたが、フォーラムの内容がとても有意義でした。私が今日のテーマとして受講したのがサーバーの仮想化でした。
仮想化万歳が続いて、睡眠学習することになると思っていたら、仮想化のメリットと現実を知ることができて、良い意味で期待を裏切ってくれました。
○仮想化にまつわる用語
・マイグレーション(migration) システムを新しいプラットフォームに移行すること。仮想化では、メンテナンスや障害時において、仮想サーバーを別の物理サーバーに移動することを指す。
・スケールアウト(scale out) サーバーの台数を増やして、パフォーマンスを向上すること。サーバーの性能向上をすることはスケールアップという。
・プロビジョニング(provisioning) 必要な時に必要な分だけシステムにリソースを割り当てること。オーバープロビジョニングは、システムが高負荷時でも最適にサービスができるように余剰にリソースが割り当てられている状態のこと。
○一般的に言われているサーバーの仮想化のメリット
1.集約できるので、サーバーリソースをより効率的に利用でき、ランニングコストを抑えられます。
2.マイグレーションにより、物理ハードが故障しても別サーバーに無停止で移動できます。それによって稼働率を飛躍的に向上できます。
3.システムを構築するたびにサーバーを購入しなくて済むようになるので、安価にシステム構築ができます。
4.P2Vという機能を使って既存システムを仮想化することで、Windows NT4.0で動いているレガシーシステムも利用できるようになります。
しかし、メリットが成功に結び付くには現実は避けて通れない。
○メリットに対する現実
1.ランニングコストを抑えられるのは、主に電気代だが、データセンターにてサーバーを置いている場合には、電気代は定額であることが多く、仮想化するためにブレードサーバーなどを購入する費用だけがかかることになる。また、集約を進めていくと通信用のネットワーク以外にも死活監視するためのネットワークや仮想マシン上の差分をバックアップするためのネットワークなどどんどんLANケーブルが増えてしまって、LANケーブルでラックが倒れそうになることも現実として起こっているらしい。また、LANケーブルが張り巡らされて放熱も悪くなって、結果的に電気代がかかってしまうこともあり得る。
さらに、監視する方法が抽象化されるので、保守要員のスキルなども向上させる必要があり、ランニングコストは変わらないかむしろ高くなる可能性がある。
2.集約はできるが、集約した結果ハイパーバイザの停止は、仮想化システムすべての停止を意味する。また、仮想化サーバーに対して接続されるディスクドライブは、物理的に1つ(ディスクが1つということではない)だったりするので、物理ディスクのメンテナンスを行うときには、そのディスクにつながる仮想化マシンを一度停止しなければならない。(停止しなくてもできるはずだが、基幹システムなどにおいては、計画停止しているのが一般的だそうだ)
「仮想化は今後当たり前になるが、あえて仮想化しないという選択肢をとれるようにする必要がある。」(日本仮想化技術研究所 宮原さん)
また、仮想化はまだまだ始まったばかりの技術。仮想化特有の問題が起こることがあり、長期的に利用した時に何が起こるか分からない。また、パフォーマンスを見れば、仮想マシンとして動かすと物理サーバー上で稼働するよりも、パフォーマンスは10%以上低くなる。最も顕著なのが、I/Oアクセスだそうだ。ユニアデックス 高橋さんのお話によると、DMAコントローラーはCPUとハードディスクの速度差によってCPUが占有されることを防ぐために導入されたにもかかわらず、ソフトウエアでエミュレーションした結果、DMAコントローラーの処理がCPUで行われることとなり、ボトルネックになってしまっているとの指摘だった。今後は、Intel VTなどのように仮想マシンからエミュレーションされたDMAコントローラーを介さなくてもアクセスできるように改善されているので、もう少しすれば仮想化のデメリットも少なくなるのではないかという内容だった。
3.仮想化が最も有効に働くのは、スケールアウトする時だ。ただ、重要なことは、仮想マシンがデータとなっており、それを保持するためには、ハードディスクをあらかじめ大規模にしておかなければならないということだ。仮想マシン1台のオーバープロビジョニングが、数十台集まると、それこそ膨大なストレージの無駄が生まれてしまう。それを防ぐために、日立製作所であったりユニアデックスはストレージ仮想化という技術でもって解決しようとしている。
4.P2Vは仮想化の中でも最もリスクの高い内容であると日立製作所 高衣良さんやユニアデックス 高橋さんはお話しされていた。原因は、Hyper-Vを例にとれば、仮想マシンにするためにWindows PEを起動させて既存サーバーをバックアップする必要があるが、サーバー自体にWindows PEを動かすためのドライバが必要であったりするからだ。また、もし仮想化に成功したとしても、まれにサポートが終息しているOSの不具合によってブルースクリーンが起こってしまったりすることがあり、長らくレガシーシステムに頼らざるを得ないミッションクリティカルなシステムを仮想化することはそもそも危険なことであるということをベンダーは認識しなければならない。
「なぜ仮想化なのか?をよく考える必要がある。仮想化はゴールではない。」(日本仮想化技術研究所 宮原さん)
ところで、仮想化のもたらす劇的な変化訪れようとしていることを、先日Windows 2008 R2を発表しているマイクロソフトが教えてくれた。
社内の物理サーバーに乗っている仮想マシンを一時的に利用したいが、どの物理サーバーもリソースが不足しているとき、IIJのクラウドに申し込んでサーバーを確保し、ライブマイグレーションを使って仮想サーバーを移動させて稼働させるというものだ。実際にデモンストレーションを行っていたが、数分でライブマイグレーションが完了していた。
この前提にあるのは、IIJのサーバーとVPNで接続されており、同一ネットワーク上にある前提がもちろん必要だろうと思われるが、プロビジョニングにより、自動的にサーバーの稼動する物理サーバーが変わるようになれば、今動いているこのシステムは社内にあるのか、データセンターにあるのか、はたまた海外にあるのかそんなことすら意識しなくて済むようになる。自動化がすすめば、ビジネス規模に応じて契約を進めていけばいいので、コストを最適化できる。
ユーザーから見れば夢のような技術だが、保守ベンダだから見れば、こんな面倒な話はない。物理サーバーの位置が変わるとネットワーク遅延が発生する(海外に移動してしまうと数msの遅延が数百msの遅延になってしまう。たいした違いではないかもしれないが100倍遅くなることは事実なのだ)ことで、アプリが動かないとかそんなトラブルに悩まされるようになりそうだ。
仮想化、仮想化、仮想化。。。Webサーバーが耐障害性と性能向上を目的に台数が増えた結果、ネットワーク機器を仮想化して冗長化しなければならなくなり、さらに耐障害性の向上とスケールアウトを進めた結果、物理サーバーすら仮想化の対象となった。あまりに物事が抽象的になった結果、本質が見えにくくなってしまっている。仮想化という時代をまのあたりにしていくエンジニアは、私を含めてその内容自体を理解することが難しくなりつつあるが、仮想化が当たり前で育つエンジニアは、それが理解できるのだろう。しかし、今後仮想化特有の不可解な現象に行き着いたときに本質がわかっていなければ、解決が難しいだろう。これは、きっとDBアクセスにおけるO/Rマッピングのようなものに近いのかもしれない??
今後は、アプリケーションエンジニアも仮想化技術とネットワーク技術を身につけていかなければ、立ちいかなくなると個人的には考える。(そんなのはネットワークエンジニアの仕事だろうという声が聞こえそうだが。。。)

ShellとControllerで処理を共有する

cakePHPでCronなどでタスク処理をしたい場合やコマンドライン実行をしたい場合にロジック部分を提供するShellクラスとWebアプリケーションのロジック部分を提供するController。いずれも同じロジック部分だけに、共有したいことが多い。
しかしながら、いずれもクラスはObjectから継承されたものであり、Objectクラスにゴリゴリ書かない限りは共有できないが、バージョンアップ時のメンテナンス負荷が高くなってしまう。
そしたら多重継承だ!という考えもPHPでは残念ながらできず、代わりにPHPにはinterfaceという仕組みが用意されているが、残念ながらcakePHPで使う方法がよくわからなかった(おそらくrequireするとか強引な手法であればできるはず)。
実はcakePHPにはコンポーネントという方法で対応することができる。しかし、このコンポーネントも癖があって、通常なら、
var $components = array(‘コンポート名‘);
とすれば
$this->コンポート名
で使えるようになるのだが、Shell側はそうはいかない。
App::import(‘Component’, ‘コンポート名‘);
と定義したうえで、
function startup(){
  $this->コンポート名 = new コンポート名Component();
}
を定義しなければ、Controllerと同等には使えない。
ただ標準で用意されているEmailコンポーネントなどは、上記手法を使う必要がなく、$components変数に突っ込めば使えるようになっている。もう少し調べてみる必要がありそうだ。

ITサービスマネージャー試験

受けてきた。試験会場まで自転車で45分かかった。まぁまぁ遠い。。。
午前Iは春の試験のデータベーススペシャリストの結果で免除になっていたので、午前IIからの試験。午後IIが小論文になっているITサービスマネージャー試験では、午前I免除がどれだけありがたかったか、あとで身にしみてわかった。
情報処理技術者試験を毎回受験していて思うことは、年々受験心得の項目が増えていっていること。おそらく自分のミスに対して屁理屈こねて、ごねる人がいるための対応の結果だろうと思うけれど、「ネコを電子レンジに入れないでください」というレベルと同じような内容が増えてきていることに今後の試験のあり方を心配してしまう。
そして午前の試験において、退出可能時間が設定されなくなったことも気がかりだ。試験の回数が多くなったことで1回あたりの試験時間が短くなった。結果、退出可能時間を作ることができなくなったのだろうが、早く終わったのに出られないという状況があるのはつらいところであって、逆に30分遅刻しなければ受験できるところが今後は悪用されてしまうのではないだろうか?
また、試験休みの時間は十分にあるのだが、20分前に着席しなければならなくなった結果、実質的にトイレに行ける時間が短くなり、トイレ混雑が激しい。20分間前に着席しなければならないのは、説明時間が長いからではなく、ぎりぎりに入ってくる受験生のために問題用紙と解答用紙を個別に配布しなければならない手間を減らしたいという事務的な部分が見え隠れしてならない。
といってもどんなに事情が変化しようとも、合格しなければ同じなのであり、自分もそれに従うまでである。
さて結果だが、午前IIは正答率68%以上、午後Iは計算問題に誤りがなければ合格、午後IIも問題の趣旨に合った回答ができていたかどうかは微妙なところがあるが、文字数制限は問題なかった。
12月の合格発表を待ちたいところだ。

可用性を極限までに高める

Webサービスをやっていてもなかなか可用性を高めるためのノウハウを学習することは難しい。というのも大容量トラフィックを体験することが小規模サービスにおいてはまれであり、可用性の検討を迫られるのは、マスコミに取り上げられるなど、急な時が多い。
そんな時に技術者はそこから調べているようでは手遅れであることがほとんどので、前例に学ばないことはない。というわけで、今日読みたい本は4Gbpsを超えるWebサービス構築術である。ライブドアで実際に仕事をしていた人の著書だけに内容に対する期待は大きい。

ARPスプーフィング

インターネットや他のネットワークに接続する際に必ず必要なゲートウェイだが、ゲートウェイと通信する際には、ネットワーク層は使わず、データリンク層を使う。
つまり、IPアドレスを使って通信しているわけではなく、MACアドレスを使って通信しているわけだ。
ところで、ゲートウェイのIPアドレスはDHCPサーバーから割り振られたり、自分で手動で登録したりするわけだが、そのゲートウェイのMACアドレスが実は、ゲートウェイのハードウェアに割り振られたMACアドレスではないとするとどうなるだろうか?
もし実在しないMACアドレスならば、インターネットや他のネットワークに接続することはできなくなるが、実在する悪意あるホストのMACアドレスならば、通信がのぞき見られたり、改ざんされることを意味する。それがARPスプーフィングである。
同じネットワーク内に悪意あるホストが存在するわけがない。普通はそうだが、そのマシンがウィルス感染していたらどうだろう。。。。
IT ProではARPスプーフィングがどのように行われるかを紹介しているので、ぜひ参考にしてほしい。
ところで、そもそもARPプロトコルはIPアドレスからMACアドレスを解決するプロトコルなのにもかかわらず、なぜARPスプーフィングが起こるのだろうか?
実は、IPアドレス衝突を検出したり、他のマシンのARPテーブルを更新するために宛先IPアドレスを自分に設定したARPパケットであるGratuitous ARPというものが存在する。性善説に基づけば、便利なパケットであるし、ARP認証を実現している今でも非常に重要なパケットであることは間違いないが、他のマシンのARPテーブルを更新できるという仕様は、IPアドレスを別の端末に付け替えた後でもすぐに通信できるという便利さや、マシンを二重化していて仮想IPアドレスでパケットを受け渡ししているようなシステムにおいて障害時における装置の切り替えを実現するHSRPが現在でも一般的に使われている一方で、(HSRPの用途以外では、)本来はつけ変わるはずのないゲートウェイのIPアドレスに対応するMACアドレスのテーブルが差し替えられてしまう問題をはらんでいる。

Prefix利用時のPaginatorHelperが吐くURLが正しく表示されない

財テク.jp 価格比較サイトモバイルサイトをPrefixを使って実現しようとしたのだが、Prefix利用時のPaginatorHelperが吐くURLが正しく表示されないにて指摘されているようにURLが正しく設定されない。そのため、このスレ主が情報提供していただいていると思われるブログを元に同様にURL置換を行うことで対応した。
ビューで置換するのは根本的な対応とは言えないが、逆にビューで置換するので、routes.phpで変更を加えるより、影響が(想定)限定されるともいえる。
今回もKtai Libraryを使って非常に簡単に作成することができた。バージョンが0.2.0になっており、cakeHPでモバイルサイトを作るならKtai Libraryとなりつつあり、今後もますます注目度が高いライブラリである。

CEATEC JAPAN2009

今年も行ってきましたCEATEC。東京に出てきた2000年から欠かさずほぼ毎年行っているので、今年で9回目。
新しい製品に詳しくない時には、何もかもに目が輝いていましたが、最近は、既存の技術の組み合わせから新しい製品が生まれているということが少しずつ分かってきて、なんだか新鮮味を感じなくなってきました。
そんな中でも、新鮮味を感じたのは次のものです。
・入場口に長い列
とうとうCEATECも一般の人に広く認知され、海浜幕張駅近くまで延びる長い列ができていたのかと思ったら、AKB48のイベントでした(笑
・検索エンジンに新しいアプローチ
NiCTでは現在の検索エンジンの主流である関連性の高い被リンク数の多いコンテンツを上位に掲載する手法ではなく、サイトの信頼性(外観、発信者情報、内容分析)によって掲載順序を並び替えたり、対立する意見を平等に掲載する「Web 情報信頼性分析システム WISDOM」というものが出品されていました。
現在の応答性能は1分以上とまだまだ実用化には至っていませんが、この応答性能がかなり上がってくれば、十分に検索の新しい方法として確立される可能性がありそうです。
実際に検索することができます。検索するときには、コーヒーを片手に持っている必要があります。 http://wisdom-nict.jp/
・直流コンセント
太陽光発電は、他の発電方式とは違って、電気を直流で取り出すため、家庭用機器で使用するときには、直流から交流に変換しなければらなず、電力ロスが発生する。そこで直流でも問題ない家電製品を直流対応とする(整流器を通すだけでよい)とともにコンセントに直流対応のものを設けようというコンセプト。
たしかにエコというからには、太陽光発電とセットでなければならないと思ったけれど、それにかかるコストは相当なものだ。
・電力監視省エネシステム
ブレーカーとコントローラーのセットになっているシステムで、導入コストが少ない割には、経営層が好みそうな情報を提供してくれる。また、家電がIPv6に対応していれば、このコントローラーから電源のON/OFFが可能であり、また、リモートからも制御できる。近い将来、一般家庭でもこのような仕組みになってきそうな気がする。
http://www.daido-g.com/sinsei/
・企業的農業経営を支えるプラットフォーム・サービス
「農業にITを」の声が聞こえて久しいが、具体的にどのようにITを活用するのかは目に見えにくかったが、富士通がプラットフォームという形でどのように実現していくかを提示しているところは大きいと思う。
資料によれば、よく聞くPDCAサイクルを農業でも活用しましょうということであり、そのためには、生産できたものを販売するのではなく、販売できそうなものを生産しましょうということだった。
別に農家が販売できそうにもないものを生産しているほど愚かではないと思うのだが、IT業界からみれば、まだまだ効率化からほど遠いとみているのだろうと思った。というIT業界も建設業界と構造がなんら変わらないにもかかわらず、他業界を変革できるような仕組みを提案できるとは個人的には思えないのだが。。。
・毎日の統計情報を簡単にデータ通信するFelica Plus
Felicaのタッチするだけでデータをやり取りするものを更に進めて、通信機能を持たない端末(体重計などの健康機器)にFelica Plusを取り付けて、データを提供するだけのさまざまな端末から集計する端末にFelica Plusを介して集計してそこから得られる情報をユーザーへ提供するというもの。
Docomoが提案しており、おもに健康機器向けということで「ウェルネスサポート」というサービスになっているのだが、他の分野にも応用できそうだと思った。ただ、説明員の人に「ほかの分野でも応用できそうですね」と聞いたら、「たとえば、肌の情報を取得して…」という答えが返ってきてしまい、サービスのコアにいる企業の社員の頭の柔軟性が課題のような気もした。(自分がエラそうに評価できるほど柔軟性があるのかというのは別の話ですが。。。)
というものでした。
また、UQコミュニケーションズ株式会社がWiMAXを提案していたんですが、日経ネットワークを読んでいると、別に新鮮味は何も感じないし、逆にサービスエリアの狭さを何とか説明でカバーしているようにも感じて、今このタイミングでわざわざ苦しい出品をする必要性もないのではないかと思ったほどでした。
ここで出品されている参考技術はおおよそ3年後には一般製品化されているものがほとんどだと思いますので、あと3年後には上記で触れたテーマが当たり前の世の中であると期待しています。

VMWare ESXiを試す

VMWare ESXiを試そうとVMWareから最新版の4.0をダウンロードした。
ターゲットマシンは、HP ML110 G2という古めのIAサーバー。
CDを入れてインストーラーが起動したが、
Module: install.tgz
Loading install.tgz..
Booting: MBI=0x000100f0, entry=0x00100212
のあとになにも応答がない状態になった。
何度やっても同じ。インターネットで調べてみると、4.0が32bitは対応していないことがわかった(笑
といういわけで、3.5をダウンロードした。
VMware ESXi を USB メモリにインストールして HP ML115 で起動と同じようにCD-ROMからは起動できず、USBから起動することになった。
しかし、紹介されている手順と同じようにしても、インストーラーのところで
Starting VMWare ESX Server 3i: Loading module ipmi_si_drv …
でハングアップしてしまうように見える。
しかし実はHP ML110G2 で ESXiにあるようにロードに時間がかかっているだけであるらしい。もはやフロッピーディスクドライブなんてものは存在しないので、ファームウェアも当てられず・・・・1時間放置しておいた。
すると画面が切り替わっており、
Using /mod/ipmi_si_drv.o
Using /mod/ipmi_devintf.o
Module load of ipmi_devintf succeeded.
config explicitly loaded
Wating for USB boot partition to show up… retrying after 1 additional seconds
Wating for USB boot partition to show up… retrying after 2 additional seconds
Wating for USB boot partition to show up… retrying after 4 additional seconds
Wating for USB boot partition to show up… retrying after 8 additional seconds
Wating for USB boot partition to show up… retrying after 16 additional seconds
Wating for USB boot partition to show up… retrying after 32 additional seconds
PANIC: Failed to find USB boot partition
となってしまう。一連の過程でかなり時間をロスしてしまった。今回はこれであきらめることにしよう。