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

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

※

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

なぜ検証を行うのか？

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

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

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

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

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

Webサーバのゴール

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

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

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までの期間が長いという利点もあります。

【検証1】同一条件での比較

同一の条件にて処理を実行し、処理量（SQL数／秒）を比較しました。

表2は10,000万SQLを10多重、30多重平行で流した時間を測定した結果です。3号機が現行本番で利用されている環境なので、この結果を100％とした場合、その他のマシンがどの程度パフォーマンスが変わるのかを検証しました。

4号機は、ハードウェアはそのままでOracleのバージョンを11gへアップグレードさせ、インストール時におすすめのオプション等を極力外したものです。この状態でも現行（Oracle 9i）より性能が向上していることがわかりますので、ハードウェアはそのままに、Oracleプロダクトのアップグレードだけでも性能向上、現行システムの延命が実現できる可能性があります。

しかしながら、実際にはハードウェアの投資は削ることができても、アプリケーション、ミドルウェアのバージョンアップ対応には工数が必要となりますので、ある程度の初期投資が必要となることと、後々ハードウェアを入れ替える際にもアプリケーションの確認工数などが（さらに）余分に発生する可能性があります。

次に1、2号機です。CPUにintelの5500番台が搭載された最新マシンなので、現行機器から比べると衝撃的な性能向上が見込める可能性が証明されました。特に今回は参照系DBということもあり、キャッシュに乗らない時点でのリクエストにはディスクアクセスが必要となりますが、その部分の差でもあるSSD搭載マシンの結果数値は真剣に採用を検討する価値があるほどの結果となりました。

【検証2】データベース設定の違いによる比較

4号機を対象に、Oracleの設定項目を以下のように定義して実施しました。

ON：既存の初期化パラメータファイルを退避しておいて、現行運用中の11g環境の初期化パラメータ（メモリ部分は既存のまま）でデータベースを起動する

OFF：既存の初期化パラメータファイルで起動する

ON：
	ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 1;
	EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS(gathering_mode => 'INTERVAL',interval => 10, statown => 'SYSTEM');
	EXECUTE DBMS_STATS.GATHER_SYSTEM_STATS(gathering_mode => 'STOP');

OFF：
	EXECUTE DBMS_STATS.DELETE_SYSTEM_STATS() ;

ON：
	ALTER SYSTEM SET RESULT_CACHE_MAX_RESULT=100 ;
	ALTER SYSTEM SET RESULT_CACHE_MODE=FORCE ;
	ALTER SYSTEM SET RESULT_CACHE_MAX_SIZE=500M ;
	ALTER SYSTEM SET OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE;

OFF：
	「RESULT_CACHE_MAX_RESULT, RESULT_CACHE_MODE, 
	RESULT_CACHE_MAX_SIZE」パラメータを削除する
	「OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES」パラメータを削除する

検証2では、オラクルバージョンアップ時に設定する項目として上記の検証を実施し、採用の可否の材料としました。使用マシンはハードウェアの誤差に吸収されないように、旧型の現行機器を利用しました。今回のような利用用途における検証の結果考察として、以下のようにまとめてみました。

実行される並列度が高いほど、11g環境の性能がよい結果が得られた

各環境の多重度による実行統計を確認すると、おおむね30並列実行で処理時間が急増することが確認されます。多重度が低い時には11g環境とさほど変わりのない性能となる場合もありますが、30並列実行では11g環境にて軒並みスループットが改善されましたので、多重度が高くなるほど11g環境の性能が有利と考えられます。

掲載はできませんでしたが、当時の詳細指標を確認しますと、上位指標の値の差分から、その原因を推測できました。メモリ初期化後の1回目の30並列実行では9i環境で「latch free、buffer busy waits」が、11g環境では「read by other session」が上位にランクされていました。また、その値の大きな差からメモリ処理で9i環境より11g環境ではより効率的になっていると考えられ、メモリ初期化を行わなかった2回目の30並列実行でも9i環境の「latch free」発生量が目立ちました。

9i環境と比べ、11g環境では物理読取が多く、論理読取が少なくなった

30並列実行基準で、9i環境と比べ11g環境のほうが62％～750％ほど物理読み取りが増えていました。逆に、論理読み取りは67％程度減少する結果となりました。

結果キャッシュの設定で大幅な性能改善が期待できる

処理量の部分を抜粋して「環境C（11g⁠）⁠」とその他の環境の結果を比較すると、メモリ初期化後の1回目の30並列実行では1.84～3.18倍、メモリ初期化を行わなかった2回目の30並列実行では3.18～16.29倍を処理していますので、結果キャッシュの設定で大幅な性能改善が期待できると考えられます。

以上より、現行環境への影響を与える事がなく、最も効果が期待できる設定を基本設計とし、バージョンアップ手順の設定項目として反映するべく設計を実施します。

ハードウェアスペックに関する考察

データベース検証を行うのと同時に、ハードウェアの情報に関してもデータを取得しました。

既存マシンでもある3号機、4号機から見れば、1号機と2号機のスペック差は誤差になると思われ、注目はSSDを採用したディスクがどの程度パフォーマンスに貢献するかという点になります。そこで、それぞれのCPU I/O、Disk I/Oに関しての数値をグラフ化しました。図3はそのイメージです。

SSDを利用したベンチマーク等については各サイト等で公開されているので、「⁠何となくこういったことが得意そうだ」というのは事前情報として推測できますが、いざ自社のシステムにて稼働させてみると驚くことが多く、ここまできれいにグラフ化ができると感動します。

考察としては、SSDを利用したマシンではほとんどディスクI/Oが発生しておらず、瞬時にメモリ等にデータがロードされるため、CPUがかなり早い段階から仕事をする事ができることがわかりました。この結果、参考値ではありますが、CPU能力が劣るマシンでも50多重までSSDでアドバンテージを埋めることができていました。当然の結果なのですが、高速なCPUでメモリを多く搭載しSSDを採用したマシンは、高いパフォーマンスを期待できます。

また、メモリに関しては、Intelの5500番台から3スロットごと（2CPUでは6スロットごと）に利用するとさらにパフォーマンスが上がるので、12G／24G／48Gバイトといった形で採用を検討するのが良いので、自社で利用するメモリリージョンの割り当てがどこかに属すように設計することとしました。ただし、Red Hat Linuxでは16ビット版のサポートが12Gバイトのみとなってしまうため注意が必要です（今回は64ビット版を採用しているため問題ありませんでした⁠）⁠。

おわりに

さて、今回は断片的な記述となってしまい、大変読みにくかったかも知れませんが、実際に行った検証の（ほんの）一部について紹介しました。可能な限り実例での紹介となりますので、結果などの考え方は一般的なストーリーとは異なるかもしれません。機会があればぜひ皆さんの環境で試してみていただければと思います。

また、これらの検証結果は本番環境用マシン購入の根拠となったり、本番環境構築に向けた基本設計や設定項目は、そのまま詳細設計として利用することとなります。

次回は、今回紹介できなかった、Webサービス系の受け口として採用したVMware ESXiの環境構築と運用について述べたいと思います。