世界的な経済危機下、コスト構造の見直しは企業にとって喫緊の課題である。経営と直結しIT分野と言えど、もはや聖域ではありえない。では、具体的にどこにメスを入れるか。大きくスリム化可能な領域の1つはデータベース・インフラまわりである。長年この分野で経験とノウハウを蓄積したアシストより、コスト削減というテーマでデータベースに焦点を絞り、限りある予算を有効に活用する方法を紹介したい。
大きなボリュームを占めるストレージ・コスト
実際に、弊社の顧客数社を対象にデータベース・インフラのコスト構造を調査してみた。OracleのEnterprise Editionを導入し、RAC（注1）構成でデータベースを構築した事例の初期コストを見たところ（図1）、そこで大きなボリュームを占めていたのが、ソフトウェア関連とストレージ関連のコストであった。
ソフトウェア関連は、データベース性能を評価して選択したソフトウェアのライセンス料などのコストであるため削るのは難しい。となると、狙うはストレージ関連コストである。
現状、顧客企業は、なぜストレージにコストをかけているのか。それは大きく下記の4点が気になるからだ。
１．I/O性能
データベース・システムは、インプット、アウトプットともにデータのロードを迅速に行うという大前提があり、ミッション・クリティカルなシステムであればある程、その要請はシビアなものになる。そのため、高いI/O性能をストレージに求めたくなり、秒間I/Oリクエスト数（IOPS値）の多寡を見てしまうのはある意味自然である。
２．信頼性／可用性
OLTP（OnLine Transaction Processing）分野ともなれば、無停止のデータベース運用は必須条件となる。止められないシステムであるがゆえに、データを収めるストレージに冗長構成機能、データの保護機能など、高い信頼性／可用性を満たしてほしくなる。
３．予測しづらいデータ量への対応
データベースのサイジングは難しい。事業環境の変化が激しい今日、どのようなタイミングでデータが増加するか、簡単には予測できないからだ。そのため、管理する側としてはデータがいつ“バースト”しても、動的なディスク追加対応機能や動的な領域拡張、縮退機能でデータベース領域を柔軟に構成し直せるよう備えておきたいと思う。
４．厳しくなるリカバリ要件への対応
万全を期していても、障害は起きることを前提に体制を組んでおかなければならない。すぐに復旧できるよう、バックアップ・リカバリ時間、およびデータ複製に要する時間をできるだけ短縮するよう求められる。それを実現するために、ストレージの高速コピー機能やこれ自体が持つデータ・ミラー機能が候補に挙がる。
つまり、データベース・システムの非機能要件充足をストレージに求めているため、すべてを高いレベルで満たそうとすれば、上記のようにコストがかかるのも無理はない。さらにアシストでは、機種グレード別にストレージ・コストの内訳も調べてみた。その結果、上位機種が高価になるのは、高いI/O性能や信頼性／可用性などを発揮するためにストレージ・ヘッドの価格がはね上がるためで、ディスクそのものの性能／価格は、機種が変わってもそれほど変わらないということが判明した（図2）。
（注1）RAC ：
Oracle Real Application Clusters の略。複数のノードで実行されるOracleインスタンスで1つのデータベースを管理することにより可用性と拡張性を両立させたActive/Activeのクラスタ構成。
ストレージ・ヘッドの役目をOracleソフトウェアに
コストを大きく削減する1つの方法は、ストレージ・ヘッドが担う機能を別に求めることだ。例えばこの機能をデータベース・ソフトウェア側（Oracle
Database）に担わせることができる。まずI/O性能は、ストレージ・ヘッドに高速に読み書きさせることで稼ぐのではなく、データの読み書きをできるだけ分散させて少ないデータを同時に読み書きさせる方が効果的だ。Oracle
Database 10gから搭載された論理ボリューム・マネージャ「Automatic Storage Management」（ASM）なら、複数のディスクをディスク・グループとして管理でき、論理割り当てユニット（AllocationUnit）単位かつ粒度を自在に設定可能なストライピングでデータのI/Oを分散させることができる。ASMを積極的に活用するOracleユーザはあまり多くないが、実は非常に使える機能なのである。実際、同一ストレージでディスク5本とディスク10本のケース設定で、ランダムI/OによるIOPS値を比較計測してみたところ、前者を100とすると後者は221.37という2倍以上のMAX
IOPS値を稼ぎ、その効果のほどが実証された（図3）。
高信頼性、可用性の実現においても、ASMが活躍する。ディスク・グループごとに多重度の設定が可能なミラーリング機能を利用してソフトウェアRAIDを行えばよいのである。ソフトウェアRAIDはオーバーヘッドがあるのでは、と心配される向きもあるだろう。これも、受注入力系のOLTPを実行し、秒間トランザクション数を計測するハードウェアRAID（RAID0およびRAID5）との比較実験を行ってみたが、ASMで三重化を行ってもハードウェアRAIDとの差は2％程度だった(図4）。
さらに、ASMであれば、ストレージ筐体をまたいだミラーリングとストライピングが可能である。これによりストレージ・ヘッドの障害などで片方がダメージを受けても、プライマリ・データとミラー・データの同時損失を回避することと、I/O性能の向上を両立することができる。柔軟なデータベース領域管理という点では、動的なディスク追加／領域拡張ができるというだけではなく、データが再配置できることが肝心である。これもASMなら難なく行える。リバランシングといって、ディスクの追加や削除を自動的に検知して、割当ユニットをオンラインで再配置することが可能なのだ。
それでは、バックアップ・リストア対応はどうか。アシストの提案は、OracleのRecoveryManagerを活用することである。Oracle
Database Enterprise Editionなら、必要のないブロックにはアクセスせず更新されたブロックのみをバックアップする高速増分バックアップ機能で、バックアップ・サイズの軽量化およびバックアップ時間の大幅な短縮が可能になる。
またロールフォワード・イメージ・コピー機能を使えば、計画メンテナンスなどの際にイメージ・コピー・バックアップを取得し、日々は高速増分バックアップで差分のみ取得してイメージ・コピーへ適用しておけば、万一の時はそれがそのまま利用できる。つまり、障害発生から復旧まで大半の時間を占めるリストアが不要になる。
さらに、ASMとRecovery Managerの合わせ技で、バックアップ出力先のI/O性能も確保可能な「ディスクtoディスク」のバックアップも実現可能である。もちろん、出力先のストレージもエントリー・モデルで十分だ。
ストレージ・コストがなんと全コストの約1割に
ASMおよびRecovery ManagerというOracleのソフトウェアの有効活用は、ストレージ・コストの削減に効く。環境構築時の初期費用を比較してみると、エンタープライズ・モデルのストレージを採用した時には、全コストの半分を占めていたストレージ・コストが、エントリー・モデルに変更したことで、なんと約1割に抑制できる。それでいて、秒間トランザクション数は後者の方が上回ったという驚異の結果となった（図5）。
Oracle VMをベースにしたサーバ仮想化で
インフラ徹底活用
IT投資のコスト削減を考える場合、もう1つの希望の星が“サーバ仮想化”である。
アシストは、2008年7月、日本アイ・ビー・エム、日本オラクルとアライアンスを組み、Oracleのサーバ仮想化製品Oracle VMをベースとした仮想化ソリューションの展開をスタートさせた。これは、IBM(R)
System x(R)上に仮想化環境のベスト・プラクティスを構築すべく、IBM、オラクル、アシストの技術者が様々な性能検証、動作確認、運用管理性などを追求していくというものだが、ここに来てその有用性がはっきりと見えてきた。
サーバ仮想化には確かに、以下のようなコスト削減を始めとした様々な効果がある。
- サーバ統合による電源、空調、設置スペースの削減
- 日常の運用／管理コスト削減
- ソフトウェアのライセンス・コストの削減
- 可用性確保を安価に実現
- 物理サーバの使用率向上および有効利用
- 運用の柔軟性、拡張性向上
- 新規システム構築時のリード・タイム短縮
例えば、統合先のスペックがある程度高ければ集約時のスケーラビリティは高いということが、アライアンスの基本性能検証でわかった。IBM System
xTM 3850 M2にOracleVM Serverを搭載し、外付けストレージIBM System Storage N3600を接続した環境を用意し、この上でいくつまで仮想マシン（DBサーバで実験）を稼働させることができるかを試したのだが、トランザクション・スループットは、なんと7VMまで物理環境とほぼ同じ性能を保った。同時並列稼働によるスループットへの影響は軽微だ。これはつまり、少し乱暴な言い方かもしれないが、1台のサーバにサーバ7台分の役割を割り振ることができるということだ（図6）。
導入効果の事前見積が可能なZodiac Light Plus
自社でどれだけ導入効果があるか事前に見積もっておきたいという企業には、IBMが立案したZodiac Light Plusという分析サービスがあるので少しご紹介しよう。これは同社が全世界で蓄積した経験／ノウハウをもとに、サーバ・ベンダー、モデル、CPU情報、台数、ホスト名、OS、メモリ、内蔵ディスク、必要ネットワーク帯域という9つの項目だけで、統合サーバ構成や価格規模の見積もりを提供するというもの。分析のためシステムにツールを仕掛ける必要はなく、分析も最短4日というスピーディさである。
Zodiacの試算では、Xeon(R)プロセッサ2.0GHz（2way）を搭載したIBM xSeries(R)225 30台が、Xeon X7350
2.93GHz（2way）を搭載したIBM System x 3850 M2 2台に統合可能となったケースもあった。これにより、スペース、空調、電気、ハードウェア保守料を合計したコスト削減額は5年間でなんと約4,817万円、CO2排出削減量も同じく5年間で1,008トンに上るという。これはなかなか看過できない数字ではないだろうか（図7）。
※1
Zodiacによる試算値
Zodiac詳細：ibm.com/systems/jp/zodiac/
※2
電気代については、1kWhあたり21.25円、空調代については、1kBTUh当たり9円とし、24時間365日使用しているものとして算出
※3
CO2排出原単位を0.555［CO2 Kg/kWh］として計算。（環境省「地球温暖化対策の推進に関する法律施行令で定める排出係数一覧」より）
（注2）HA構成 ：
本稿ではOracle VMで実装されているHA機能を指す。仮想マシンの障害を検知して、他の物理サーバ上で仮想マシンを再起動させるOracle VMの標準機能。
仮想化すれば、高い可用性を安価に確保可能
仮想化することで得られるシステム設計まわりの大きなメリットとしては、高い可用性を安価に確保できるという点がある。これには大きく、HA構成（注2）で実現するもの、RAC
on Oracle VMで構成するものと2つあって、システムのサービス・レベルに応じて選択できるようになっている。
HA構成は、障害発生時におけるOracle VMの仮想マシンの自動再起動を可能にする。つまり、物理サーバに障害が発生した際、すべて、あるいは特定の仮想マシンを自動的に他の物理サーバで再起動させることができる。これは「Oracle
Clusterware」技術をベースに開発されており、仮想マシン側にHA実装のための修正や付加機能の実装は不要で、伝統的なHAクラスタ・ウェアのようなリソース監視設定などの複雑性がない。
一方、RAC on Oracle VM構成は、RACを仮想化環境上で実装できることを意味している。従来、本番環境はRAC構成であるのに、開発環境やステージング環境はコスト的な問題によってRAC構成でない場合が散見される。RAC構成特有のアプリケーションからデータベースへの接続形態やフェイルオーバ時の挙動などが十分にテストできず、アプリケーションとデータベースを含めたシステム全体の可用性を下げてしまう問題があったが、RAC
on Oracle VM構成によって、可用性と信頼性を高めながら、ソフトウェア・ライセンスの圧縮による、コスト削減効果も得られるようになった。
Oracle VMテンプレートの活用で
セットアップ時間も大幅に短縮
構築プロセスでぜひ推奨したいのが、Oracle VMテンプレートの積極利用である。これは、CPU数、メモリ・サイズ、ディスク・サイズ、NICなどの基本的な構成情報が含まれている、OSも梱包された圧縮ファイルだ。これを適用することにより、仮想マシンのセットアップ時間を大幅に短縮することができる。このイメージに慣れたら、自作テンプレートを用意するのも一法だ。仮想環境を自由にテンプレート化できるので、開発環境やステージング環境などをあらかじめ作成しておけば、必要な時にすぐに適用できる。サーバ環境をファイル形式にカプセル化可能であるため、機敏で柔軟性の高い運用が実現できる。
このOracle VMテンプレートはまた、仮想マシン単位のバックアップ用、 仮想マシン間のディザスタ・リカバリ用、開発環境の世代管理用と多彩な用途に活用することができる。
導入に少しばかり必要な“コツ”はアシストがお手伝い
サーバ仮想化には多岐にわたる利点がある。弊社でもハードウェア障害により、重要な社内ポータル・サービスが停止した際、仮想化環境にシステムを移行することで翌日のサービス復旧が実現した実績がある。システム復旧のための調査や修理手配が不要だったばかりではなく、かえって既存の物理サーバ上での運用より快適に動作したぐらいだった。
ただ実際の導入には、物理サーバのリソースに少し余裕を持って緊急の高負荷VMの出現に備えること、ストレージは仮想化を使ったエミュレーションによるアクセスではなく、直接接続させた方がオーバーヘッドが少なくパフォーマンスが良い、など、少しばかり“コツ”がある。しかし、それはアライアンスでナレッジを蓄積したアシストがお手伝いできる部分だ。疑問、質問、何でも気兼ねなくぶつけていただければ幸いである。
（文責 ： 株式会社アシスト 広報部）
従来の1/3のコストと期間で構築できる
データベース基盤ソリューション
アシストでは、信頼性、可用性、運用管理性、パフォーマンスに優れた事前設計済み、事前検証済みのデータベース基盤ソリューション「DODAI （ドダイ）」シリーズのラインナップとして、本稿でご紹介した、ストレージ・コスト削減モデルや、データベース統合に最適な統合基盤モデルなど、システムの規模／用途に合わせ、様々なスタックをご用意しております。
お問い合わせ
株式会社アシスト 情報基盤販売推進室
TEL 03-5276-3653
E-Mail oracle_sal@ashisuto.co.jp
URL http://www.ashisuto.co.jp/solution/dodai/
