今回は，サーバを集約する際に行う検証について，物品の調達や環境の構築，項目の精査より実際の検証を実施し，本番機器調達の台数根拠と設定項目等に関する設計の一歩を踏み出す部分までを，実例に近い形で紹介したいと思います。

検証項目，結果数値に関しては可能な限り具体的に出そうと思います。これらはできるだけユーザ企業側がポリシーを持ち，主導的に実施するのが好ましいでしょう。

※

前回，VMware ESXiに関しても記載する予定としていましたが，ボリュームの関係上，次回とさせていただきます。

なぜ検証を行うのか？

前回までに，現行踏襲の基礎数値の定義付け→机上の計算による集約台数を算出しました。会社や案件によっては，机上の計算から稟議が通ったのを受けて，すぐに本番機器発注という流れもあるかもしれませんが，本連載では検証局面を設け，1台あたりの処理性能の確認と，異なるスペックによるハードウェア，ミドルウェアの挙動の違いを確認し，マシン選定をより厳密に行う材料にしたいと思います。また，ミドルウェアに関しても，設定の違いによる処理性能の違いを把握し，本番適用時の根拠にすることを目的とします。

検証項目を決めてハードウェアを調達する

検証を行う際，最初に「何をするために」「何を調達する」のかを決めなければなりません。本番機器発注の台数見積もりの正当性を（なるべく正確に）検証しなければならないため，慎重に行わなければなりませんが，考え始めればきりがなく，軽くやるにしても「どこまで？」という感じになってしまいがちかも知れません。

最終的なゴールは，機器発注時に「このスペックのマシンを○台」と言えるように確認を行うことです。結果として一番避けたいのは「総スペックが足りない」場合と，逆に「誰が見ても大幅に買いすぎた」になることかと思います。

次に心がけたいのは「なるべく（キャパシティが）見積もりどおりの台数で運用できる」ということでしょう。そのために今回はWebサーバ，DBサーバに関して次のようなゴールを設けることにしました。また，ハードウェアに関しては，先に検証（開発）環境用として調達するのも良いのですが，今回はメーカ等から1ヵ月程度借用し，その期間内で検証を行うこととします。

Webサーバのゴール

Webサーバに関しては，スクリプト等を利用して以下の環境（起動項目に達すること）が確認できた場合，後はスケールの数に応じて現行保証ができることとします。

ハードウェア：X5570 (2.93GHz) / 8GB×4 / 147G×6(RAID1×3) 15krpm
VMware ESXi 4.x
CentOS 5.4（64ビット）
Apache 2.2 1,000プロセス
Tomcat 6.0 200スレッド／5コンテナ

こちらの検討については問題なく実施することができたので，詳細については割愛させていただきます。

DBサーバのゴール

DBサーバに関しては，プロダクトアップグレードによるアプリケーション改修等もあるため，ハードウェアの確認の他，アップグレードの手順やパラメータ設定項目等の検証項目も加えることにします。検証対象マシン，検証項目が多いのですが，一度やり方と内容が決まれば，あとは流れ作業的に実施することができます。機器借用機関を1ヵ月とした場合，調達→検証→返却までを3週間を目標にスケジューリングすると良いでしょう。

基本検証方法

検証環境にて利用するデータ類は，いったん本番環境からMaterialized Viewでデータを受けてから隔離された環境へ移します。このような環境の場合，よほどのことがない限りOracleのバージョンアップにデータ領域自体が影響することはほとんどないかと思います。

また，キャッシュ等の機能に関してはいったんOFFにするなど，極力無効化して検証を実施することとします。Oracle11gのリザルトキャッシュ，OS側でのファイルキャッシュなどの機能はオフとし，検証は再起動等を実施した後に実行します。具体的な検証は以下のように行います。

1．本番環境より一定の時間帯のSQLクエリを抽出し検証時に利用します。

詳細には，SELECT処理の行う10,000万個の一連のSQLバッチ処理を，メモリ初期化後に10並列，30並列の多重度で実行します。

2．SQLを実行した処理時間よりスループットを計算（逆算）します。

前提として，Oracleからの「複数列統計」機能は推奨されていますが，今回の検証では対象項目の判断ができなかったため対象外としています。 VLM環境での自動メモリ管理（AMM）設定に関しては，今回はサポートされていない環境があり，一律検証の対象外としました。

測定方法に関しては，SQL*PLUSのSPOOL機能で必要なログを残し，以下のように集計します。

• ①AP処理時間：終了時間時刻－開始時刻
• ②DB内部処理時間：開始と終了時点の「CPU時間 + 待機時間(NotIdle)」の差分
• ③物理読取数：開始と終了時点の「physical reads」の差分
• ④論理読取数：開始と終了時点の「logical reads」の差分

ハードウェア，設定項目等

検証に利用した機器は表1の通りです。ハードウェア的には3，4号機が現行機で，5年前に製造されたマシンです。リプレース目標の1，2号機に関しては，本当は統一されたマシンが望ましいのですが，発注を予定しているハードウェアベンダの借用プログラム等を利用する場合，スペック等に関して必ずしも要望通りのマシンになるとは限りませんので，多少ばらつきが出てしまっています。

Oracleのバージョンップ

Oracleデータベースのバージョンアップに関しては，Oracleのサイトや専門書籍を参照し，それぞれ対象システムに合ったアップグレード方式を選択してください。

今回は現行9i（9.2.0.7）からのアップグレードが対象となり，当時は10gR2への移行がおすすめパターンでした。これは恐らく移行実績が豊富にあり，リスクが少ないといった点からの結果であろうかと思いますが，幸いにも現行バージョンの9.2.0.7から11gへのダイレクトアップグレードが保証されていることや，今回のターゲットシステムがMaterialized Viewの受け側のみいうことで，11gに移行してもデータベースの再構築（フルアナライズ）など移行の手順，リスクが低いと判断しました。当然，最新バージョンにしておくことにより，次回EOSLまでの期間が長いという利点もあります。