企業コンピューティング15領域のテクノロジー・トレンド予測［前編］
InfoWorld米国版
1. グリーンIT
仮想サーバのシャッフルで電力効率を最適化
データセンターは電源消費の無駄が大きい。もし、仮想サーバ・ファームを瞬時に構築して必要な分だけ電力を使えるようになったらどうだろうか。 テッド・サムソン／InfoWorld米国版
ある日の昼下がり、米国ニュージャージー州ニューアークでデータセンター・オペレーターを務めるあなたは、サーバ・ルームを歩きながらふと気づく。たくさんのサーバが多数のアプリケーションを走らせているわりには、不気味なほど静かだ。
動作音がしないのは、重大な障害の前触れとも考えられる。だが、管理コンソールを見るかぎり、アプリケーションは正常に稼働しているようだ。
種明かしをすれば、インドのデータセンターがほとんどの負荷を肩代わりしているのだ。そのうえ、現地はオフピークの時間帯であるため、節約できている電気代はかなりの額に上る。しかも、各サーバ・マシンが消費電力と仮想ワークロードを自己調整し、必要に応じて電源のオン／オフに切り替えていることが電気代のさらなる節約につながっている。
地元の電力会社から割り当てられる電力は限られているうえに、データセンターのスペースも無制限ではない。その一方で保有するサーバ・マシンの消費電力は年々増え続け、冷却設備のためにもますます電力が必要になる。こうしたことに頭を抱えるデータセンター管理者にとって、グリーンITの重要コンセプトの1つであるエネルギー効率は切実な問題だ。ベンダー側を見ても、チップからソフトウェアに至るまでサーバの負荷を軽減するための対策を施し、サーバ台数を減らせるように努力しているようだ。
こうしたデータセンターの現状から判断すれば、グリーンITの分野で次に来るのは、電源管理、システム管理、Webサービス、そして仮想化技術を統合した「ダイナミック・サーバ・ファーム」だと予測できる。
その技術要素の1つであるハードウェア・レベルの電源管理は、すでにサーバ管理ツールに搭載され始めている。例えば、ヒューレット・パッカードは最近、同社のハードウェア管理プラットフォーム「Systems Insight Manager」に、サーバ・マシン単位で消費電力を制限する新機能を取り入れた。
HPが指摘するとおり、ハードウェア・ベンダーが所要電力を1,000ワットと設定していても、それはサーバ・マシンがフル稼働している状態のことだ。しかし、データセンターの運用にあたっては、マシンをフル稼働させないのがベスト・プラクティスとされている。もし、常時100％使い切ってしまっていたら、処理量が増えたときにトラブルが発生するのは目に見えている。
では、80％程度の利用率でサーバが稼働しているときに突然、処理量が急増したらどうなるのか。この場合、ダイナミック・サーバ・ファームにおいては、電源管理ソフトが立ち上がり、それまでリソースを費やすことなく休んでいた他のサーバを目覚めさせるようになるだろう。アピストリが同社のプラットフォーム「Enterprise Application Fabric」のために用意した「EnergySaver」というテクノロジーはまさにこれにあたる。
筆者は、VMwareからもサーバ仮想化製品ラインに電源管理機能を搭載する計画を聞いた。利用率の低い仮想マシンをできるだけ少数のサーバに動的に転送して、仮想マシンが稼働していないサーバをスリープさせるという仕組みだ。各サーバは必要なときだけ起動するようになり、消費電力を最低限必要な分だけにとどめられるようになる。
サーバ仮想化はハードウェアの利用効率を高めるのに有効な技術だが、今のところ、仮想マシンが動的に移動できるのはサーバ間に限られている。では、仮想マシンがデータセンターという枠を超え、電力供給量とそのコストの判断に基づいて、時差のあるほかの地域のデータセンターにまで動的に移動できるとしたらどうなるだろうか。
例えば、カリフォルニアにあるデータセンターで需要が急増しているとしよう（図1）。そのとき、電力会社から、電気料金がもうすぐ倍になり、また、電圧低下も差し迫っているというWebサービスのアラートが届く。だが、ダイナミック・サーバ・ファームは、ニューヨークがすでに就業時間外で、電力コストが安く供給量も十分だと知っている。そこで、仮想マシンをニューヨーク州アルバニーの施設に動的に移すわけだ。もちろん、サービス・レベルさえ十分であれば、インドのバンガロールや中国の上海など、電力コストがさらに安い地域のデータセンターにも移せるはずだ。
以上のようなグリーンITの将来像は、現実離れしたものに聞こえるかもしれない。だが、そのためのテクノロジーはすでに存在しており、ユーザー企業側もそれを求めている。エンジニアはデータこそITの生命線だと考えがちだが、マシンに燃料を送り込むのはデータではなく電力なのだ。
2. ストレージ管理
ストレージ管理の簡素化。その切り札はサービス化
ストレージ管理が簡単になるなんて、まだまだ夢の話だ。困難さが改善される兆しはほとんど見られない。解決策は、第三者に任せることだ。 マリオ・アピセラ／InfoWorld米国版
ストレージ・ベンダーのうたい文句とは裏腹に、ストレージの管理は簡単になるどころか逆に難しくなっているのが実情だ。ベンダーは、原始人でさえ容易にストレージを管理できるようになるとして管理ツールを声高に宣伝する。それは、接続先のデバイスやサーバを自動検出し、それに従って構成も自動で実行してくれるという。
どのようなセールス・トークにも言えることだが、こうしたうたい文句のすべてが真実だとは言えない。標準構成からほんの少し逸脱しただけで、容易なセットアップという約束はいとも簡単に破られてしまうのだ。経験の浅いストレージ管理者は、何とかしようと四苦八苦するはめに陥る。
シンプルさを売りにするiSCSIでさえ、実際はそうではなかった。ファイバ・チャネル（FC）と比較したiSCSIの優位点は、IPベース以外のネットワーク装置について学ばなくて済むこととされている。しかし、iSCSIのホストとターゲット・デバイスを連携させるには、通常のLAN管理では学ぶことができなかったスキルを要求されることになる。
これだけでも大変なのに、ほとんどのストレージ管理スイートはiSCSIを完全に無視するのだから始末が悪い。FCoE（Fibre Channel over Ethernet）のような、今後登場するテクノロジーにしても、もともと難しいストレージ管理をいっそう複雑にするだけだと筆者は考えている。
データ容量増大への対応とストレージ管理の費用対効果の向上──ユーザー企業が抱えるこの相反する2つの要求が満たされることはないのだろか。
多くのユーザーにとって、その答えはストレージのサービス化、つまりSaaS（Storage as a Service）である。ストレージとその保守に莫大な金額を払う代わりに、ストレージ・スペースをレンタルすれば、節約した予算とリソースを戦略的なプロジェクトに割り当てられるようになる。
SaaSはまず、アマゾン・ドットコムやグーグルのような企業が抱える余剰容量の利用という形で火がつくだろう。そして、その流れに乗ろうとするベンダーが現れ、過去に例がないほど大規模なストレージ・サービスがインターネット上で利用できるようになる。それは、EMCやHP、IBMといった既存ストレージ・ベンダーの市場にまで食い込んでいくはずだ。
SaaSでは、使用する分だけ料金を払えば済むため、ストレージ・コストは大幅に削減される。それによって、これまではコスト的に無理があったテクノロジーでも導入できる余裕が生まれるだろう。
3. SMBテクノロジー
SMBはスタンドアロン・アプリを捨て去る
SMBが選択するアプリケーションはWebブラウザ経由で利用するものになる。つまり、SaaSもしくはホステッド型アプリケーションだ。 オリバー・リスト／InfoWorld米国版
近い将来、SMB（小・中規模企業）がビジネス・ソフトウェアを購入する際の選択肢はオンデマンド・ソフトだけになるかもしれない。スタンドアロンのパッケージ・ソフトは消え去ることになる。Webブラウザからアプリケーションのあらゆる機能にアクセスできるフルSaaSであれ、マイクロソフトのExchangeのようなホステッド型アプリケーションであれ、その費用対効果はSMBにとって大きな魅力だ。
今のところ、唯一気がかりなのはインターネットの信頼性だ。SMBの多くは、インターネットを基幹アプリケーションのインフラとして十分な信頼性を備えているとは見なしていない。
だが、この状況は変わりつつある。米国におけるほとんどの都市部では、ビジネスを麻痺させるようなインターネット障害の件数はこの5年間で激減している。さらに、インターネット・バックアップ・サービスがSMBに提供しているオプションが増えて料金も手ごろになってきたという事情もある。
つまり、インターネットであっても、冗長性を手軽に確保できるようになってきたわけだ。DSLでバックアップするT1サービスにしろ、企業の専用ケーブルでバックアップするDSLにしろ、2本のインターネット回線を同時に走らせても、かなり低コストで済むようになってきた。
そのうえ、スタンドアロン・アプリケーションを全面的にSaaSに切り替えることで、社内アプリケーションの管理のために雇っていたITスタッフに支払う給与が不要になることを考えれば、コスト削減効果は絶大だ。特殊な用途のソフトウェアを必要とするケースではスタンドアロン・アプリケーションも残るだろうが、標準的なもので間に合うのであれば、これまでは社内のITスタッフだけで導入するのが難しかったような高度な機能も容易に利用できるようになる。
しかも、これは今すぐにでも始められることなのだ。セールスフォース・ドットコムのようなSaaSベンダーのアプリケーション・フレームワークを使えば、専門のソフトウェアを必要とするSMBでさえオンラインで十分対応できるだろう。
大企業の場合は別の懸念もあるかもしれない。だが、最小限のTCOで最大限の機能と柔軟性を求めるSMBには、SaaSやホステッド・アプリケーションが注目株として急浮上することはまちがいなさそうだ。
4. データベース
次なるフロンティアは新たな圧縮技術
データベース容量の肥大化は深刻な問題だ。データ圧縮を利用するという手があるが、従来の技術ではパフォーマンスの面などに問題が残る。 ショーン・マッカウン／InfoWorld米国版
現在、データベース容量の肥大化が大問題になっている。個々のデータベースがペタバイト級に膨れ上がるなか、IT/IS部門は、それに見合うストレージを探すのに苦労している。この原因はテーブルの数が増えたからではなく、今まで数百万行だったテーブルが数十億行になってきたことだ。数百億行になるのも時間の問題だろう。
だが、増え続けるデータをいかに格納するかは、問題の3分の1にすぎない。次の3分の1は、データにいかにアクセスするかだ。ディスクの容量単価は低下してきているものの、ペタバイト単位で安定したパフォーマンスを引き出すには数千ものドライブが必要になる。
残りの3分の1は、この膨大なデータをどこにバックアップするかだ。バックアップが必要なデータベースが数テラバイトの現在でさえ、これを圧縮せずにバックアップするとしたら、コストは大きくなりすぎる。
筆者の予測では、次に来るデータベース・テクノロジーは、テーブル・データ（および可能性としてデータベース全体）に対する圧縮アルゴリズムと周辺構造のさらなる効率化だ。現在のデータベース圧縮技術は広く普及してもいなければ、DSS（意思決定支援システム）やOLTP（オンライン・トランザクション処理）システムといった過酷な条件を十分に満たせるほどパフォーマンスが高いわけでもない。
バックアップについては、SQL Server用の圧縮ツールであれば、いくつかのベンダーが取り扱っている。だが、他のRDBMS用には、それほど効果的なツールがない。どれも通常のオープンAPIと標準的な圧縮アルゴリズムに頼っており、将来的にデータベースに要求される高度な圧縮とパフォーマンスに対応するには、別の技術が必要となるだろう。
こうした理由から筆者は、ライブ・データの圧縮とバックアップの圧縮が、データベース領域における次のビッグ・フロンティアになると予測する。
5. ミドルウェア
真のサービス指向に不可欠なビヘイビア管理
まるでアプリケーション基盤全体が1つの巨大なローカル・システムで走っているかのように見せるのが次のミドルウェアの姿である。 デイブ・リンチカム／InfoWorld米国版
ミドルウェアは、ある場所から別の場所に情報を移すだけの役割から、SOA（サービス指向アーキテクチャ）に基づいて、より洗練された役割を持つ基盤へと変貌を遂げつつある。今後は、サーバ間の統合から、真のサービス管理やビヘイビア管理へと重点が移っていくはずだ。
では、具体的に何が違うのか。ミドルウェアは過去10年間、トランスフォーメーション、アプリケーション・セマンティックの整合化、そして場合によっては情報が正しいシステムに届くという保証など、さまざまな機能を追加し、その利便性を高めてきた。ただし、ミドルウェア上に流れるデータのほとんどは、顧客データや売上げデータといった単なる情報にすぎない。
だが、真のサービス指向ミドルウェアは、機能のビヘイビアをどのように扱うのか、そしてそのビヘイビアをシステム間でどのように共有するかを決められなければならない。つまり、単なる情報共有基盤として機能するのではなく、リモート・メソッドの相互呼び出しやサービス・コールがまるでローカル上で行われているかのように実行されなければならない。データはメソッドにバインドされ、従来と同様にデータへのアクセスを制御するにはメソッドを活用することになる。
なぜ、このようなミドルウェアが新しいと言えるのか。これまでもミドルウェアは、統合サーバ、メッセージ・ブローカ、サービス対応のキューイング・システムとして機能していたが、その焦点はサービスでなく情報を交換することに置かれてきた。
今日、サービス指向の環境を構築するために情報指向のミドルウェアが利用されているが、成功しているとは言えない。今後、サービス指向という必要性から、ビヘイビアの共有に焦点が移り、ミドルウェアの構築や展開方法を根本的に変えるだろう。
［中編］に続く
（月刊Computerworld 2007年12月号に掲載）
提供：Computerworld.jp
