DB統合による企業インフラの最適化手法 第2回:3ステップで実現する企業システムの統合基盤化

企業システムの統合――多くの企業がそのメリットや必要性を認識しつつも、既存システムを企業の戦略を推進する強力な武器にまで高めることができずに終わっているケースも散見される。今回は、将来的にも価値が下落しないシステムを構築するためのベストプラクティスをステップバイステップで伝授しよう。


 ブレードサーバや仮想化技術の登場以来、企業システムの統合はさまざまな手法で行われている。しかし、その実はといえば、ハードウェアを集約したところで止まっていたり、運用管理が統合されていなかったりといった様子であることが多い。将来的にも価値が下落しないシステムを構築するためのベストプラクティスというのは意外に企業には知られていないのが現状なのだ。

 前回までは、企業がシステムの統合へと向かっている現状の背景となる課題、それに対しアプリケーションを動かす統合基盤を構築することの有効性と、それを実現するHPアダプティブ・インフラストラクチャおよびOracle Gridソリューションについて紹介した。今回は、単にハードウェアだけでなくその上にあるデータベースさらにはアプリケーションの実行環境となるミドルウェア全体を統合することを目的にシステム統合をとらえ、そのためのシステムの構成とその具体的ステップ、さらにはそれぞれの段階で得られる効果について紹介しよう。

ステップ1:サーバ、ストレージのハードウェア集約

 システム統合と聞いて多くの方がまず頭に思い浮かべるのは、サーバ、ストレージなどの物理的なハードウェアの数を減らし、コスト削減やリスク削減を目指すことではないだろうか。これは間違いではなく、まずはこのステップを踏むことが必要である。分散しているシステムを個々に管理するのではなく、ネットワーク越しに接続して一元管理するだけでも管理コストや運用の手間は省ける。ハードウェアの数を減らすということは、ハードウェアやその上で動作するソフトウェアの費用、それぞれの保守費用、設置場所にかかわる費用、電気代などの光熱費が削減できることを意味しており、それはすなわち、TCOの低減へとつながることは理解いただけるだろう。

 分散した状態に比べ、集約が進めばデータベースサーバ環境などの構築時間の短縮が見込まれるため、アジリティ(俊敏性)の観点からも効果が高い。ハードウェアの物理的な統合が進んでいれば、わざわざサーバまで出向くといった作業も必要なく、また、統合の際に標準のハードウェアなども決められればその構築方法も統一して効率化が図れる。加えて、個々のシステムごとにバラバラだったハードウェアの運用方法が、集約を進める過程で標準化できることも見逃せない。ハードウェアが標準化するということは、管理方法の統一化にもつながるので、システムごとに必要だった管理者数も減らせる。そうなれば、ヒューマンエラーの確率なども低下し、結果的にITシステムで提供するサービス品質が向上するだろう。

 また、災害対策やセキュリティ対策なども個々に行わなくて済む。対象となるシステムの数が減れば、災害対策、セキュリティ対策のレベルの均質化が可能となるのだ。バックアップやリカバリー体制について、システムごとに異なるといったことが減らせればもちろん可用性の向上にもつながる。

 このように、ハードウェアやストレージなどの物理的な数を減らせるだけで、さまざまなメリットが生まれてくる。ここまで述べてきたことをまとめると、単に分散しているものを集めることから一歩踏み込み、集約段階で運用管理方法などを標準化することで、さらなるメリットを引き出すということである。物理的なハードウェアの数を減らすことによるコスト削減は、ある種瞬間的、短期的なメリットとして表面に現れるものだが、標準化によるさまざまなメリットは中長期的な運用管理コストの削減やリスクの低減につながる。そのため、中長期的な視野に立ったTCO低減に大きく貢献する。

ステップ2:アプリケーションやデータベースの集約

 物理的な集約は、誰でもそのメリットを得やすいものであると言える。しかし、ただ集約しただけでは、現実的に運用管理面の標準化を進めることはなかなか難しい。確かに、ハードウェアのコストやハードウェア管理のコストについては上述した施策によって削減が可能だろう。しかし、システムはハードウェアのみで構成されるわけではない。より現実的な視点で考えれば、ソフトウェア層での統合も視野に入れることで、その運用管理コストの削減、さらには新規サービスを立ち上げるにあたってのアジリティ確保が可能となる。標準化により本格的なシステム統合メリットを求めるならば、物理的なサーバの上で稼働するアプリケーションやデータベースについても集約することを考えるべきなのだ。つまり、物理的な統合の次のステップには、アプリケーションやデータベースを含めたソフトウェアレベルでの統合が考えられる。

fig01.jpg 統合DB環境へのロードマップ。後述するITシステムのユーティリティ化まで見据えれば、サーバ統合やデータベース統合は通過点に過ぎない

 ソフトウェアレベルでの統合

 ソフトウェアレベルでの統合が成されれば、まずはミドルウェアやデータベースの管理コストの削減ができる。開発した世代ごとに異なるOS、異なるソフトウェアを導入していると、企業内には複数の組み合わせのシステムが乱立しているはずだ。これらをハードウェアやソフトウェアの保守の切れるタイミングなどで、統合基盤へと順次移行できれば、ソフトウェアの運用管理の標準化が実現できる。

 また、個々のシステムの負荷ピークにあわせて用意していたハードウェアリソースも、最適化が可能となる。遊休リソースを多大に用意せざるを得なかった以前の状況から、ハードウェアの仮想化やグリッド技術なども利用し、最低限のリソースでも可用性、信頼性を確保した状態でピーク時の負荷に十分耐えうるシステム環境を構築できるのだ。

 全体としてハードウェアリソースに余裕のある形で統合データベースサーバが構築できれば、例えば新規にデータベースサーバの環境を構築したい場合でも、基盤から環境を切り出すことで迅速に対応することも可能だろう。

 言うまでもないが、管理するソフトウェア群が1つに統合化できれば、その運用管理も一元化できる。アプリケーションを動かすインフラ部分が1つになるので、個々に管理する必要があるのは、その上で稼働するアプリケーションだけとなる。統合基盤化されたインフラ部分に対し集中して管理が行えるので、当然ながらサービスレベルの大幅な向上が見込める。対象を減らすだけでなく、運用管理方法もセキュリティ対策や災害対策なども統一化できるメリットは大きく、日本版SOX法での監査対象の削減や災害時の事業継続性の向上など、いま企業全体として取り組まなければならない課題の解決につながる。

 理想的な統合基盤への現実的なアプローチ

 これまで述べてきたように、アプリケーションやデータベースの基盤を統合化するには、単にシステムを一カ所に集めるのではなく、アプリケーションを統合基盤の上に移行していく必要がある。企業に十分な体力と予算があるならば、既存のシステムで稼働しているアプリケーションすべてを、一気に統合基盤に移行することもできる。しかし、実際にこれを短期間で行うのは難しい。新規システム導入の際に、まずはアプリケーション稼働のためのデータベースやミドルウェアを含んだ統合基盤を構築し、その上にアプリケーションを構築する。構築された統合基盤に既存のシステムを順次移行していく、というのが現実的なアプローチだろう。

 ここで、アプリケーションAを2ノード構成のOracle Real Application Clusters(RAC)で構築する計画があると想定しよう。このOracle Gridの環境を統合基盤とし、従来2ノードのHA構成で稼働していたアプリケーションBも、このタイミングで統合基盤上に移行する。リソース的に問題がなければ、この段階で従来のHA構成の2ノード分が削減できることになる。

 こうしたステップで順次統合基盤に既存のアプリケーションを移行できれば、最終的には標準化された統合基盤の上で多数のアプリケーションが動く環境ができあがる。Oracle Gridの構成なので、稼働するアプリケーション数が増え負荷が高まれば、ノード追加で性能を維持していくことも容易だ。

 1台のHP Integrity Superdomeを用いこの方法で集約すると、既存アプリケーション環境を特に改変することなく統合化できる。そのためには、Superdomeのハードウェアとソフトウェアのパーティーショニング機能を活用することになる。ブレードサーバの場合はリソースの割り当ては1台ずつの物理的なCPUブレードが基準となるが、SuperdomeならばnPartitions(nPar)と呼ばれるセルボードを単位としたリソース分割が可能で、それぞれを独立したシステムとして運用できる。プロセッサ、メモリ、I/Oなどのハードウェアリソースを各パーティーションに割り当てられるので、システムに必要なリソースを柔軟に割り当て可能だ。その上で、HP Virtual Partitionsでは、ソフトウェア的に1つのハードウェアで複数OSを稼働でき、さらに細かいレベルでのリソース有効利用が可能となる。

 これらの機能を利用すれば、例えばSuperdome内の2つのnParを2ノードのRAC構成としてグリッド化し、新規のアプリケーションAと旧来のアプリケーションBをこの上で稼働できる。ほかの既存アプリケーションは、同一Superdome内の別のnPar上かHP Virtual Partitions上で稼働させることで、物理的サーバ統合の完成とデータベース統合の第一歩が実現できるのだ。

 この段階では、RACに統合化されたアプリケーションはデータベースまで統合化されているが、ほかのアプリケーションでは個別にデータベースが稼働している。ここから、順次既存アプリケーションをグリッド環境に移行すれば、最終的なアプリケーション稼働のための統合基盤への集約が完成し、データベースも1つになる。

 さらに、高度な信頼性、可用性を求めるならば、Superdomeを2台用意しこの2台にまたがる形でRACを構成するOracle Gridの提案ができる。実際、Superdomeを導入する顧客では、複数のSuperdomeでOracle Gridの環境を構築するケースが多いという。例えば、1台目のSuperdomeで2ノード、2台目で2ノードのnParで合計4ノードでのRACを構成し、複数のアプリケーションを同時稼働させ、筐体内だけの冗長性に加え筐体を超えた冗長性も確保して信頼性、可用性を向上させるような構成である。負荷に応じたノードの追加を考えても、双方の筐体で柔軟な構成を取ることができるだろう。

fig02.jpg SuperdomeとOracle Gridによる統合基盤環境の構築(クリックで拡大)

ステップ3:さらに高度な統合化となるITシステムのユーティリティ化

 SuperdomeとOracle GridによるITインフラの統合基盤化が実現し、ミドルウェア層までも含んだ統合が進めば、ITのユーティリティサービスの提供も現実のものとなる。さらに標準化を進め、SOAの手法に沿ったアプリケーションデザインを行うことで、需要に応じたリソースの提供と使用量に応じた課金も可能となり、より一層のコスト削減も見込むことができる。アプリケーション連携も容易となり、サービスの再利用による新たな要求への迅速な対応も可能だろう。

 ITインフラ基盤単位での運用管理の標準化と自動化も実現でき、内部統制も自立的に機能することが期待できる。集約、統合までは比較的TCOを低減するというスリム化から生まれるメリットとなるが、ユーティリティ化まで進めばITシステムが企業の戦略を推進する強力な武器として活用できるようになるだろう。

【特集】仮想化×グリッド――HPとオラクルが切り開く新境地

【関連記事】2007年新春特別対談 HP×Oracle

【関連記事】企業の内部統制対応に最適な統合プラットホームの実現

【関連記事】サービスとしてのITシステムは共有された「仮想化」と「グリッド」で実現される

【関連記事】いま求められるインフラ最適化のためのコンソリデーション、その背景と目指すものとは

【関連記事】エレガントなシステム統合ソリューションを実現する秘訣



提供:日本ヒューレット・パッカード株式会社
企画:アイティメディア営業本部/制作:ITmedia エンタープライズ編集部/掲載内容有効期限:2007年6月25日