【事例】CPU使用率「平均60％」の悪夢
2度目のサーバー増強で決着---日本旅行（下）

解決策(5)　さらなるスケールアップへ

図4●現行機とリプレース検討機の比較検証の結果 現行のアクセスに耐えられ，かつ拡張しやすいものに，サーバー機を入れ替えることにした。Itanium 2のサーバーが候補に挙がり，現行機と比較検証した。検証は，実際のデータとアプリケーションを使って実施した。実際に購入したマシンのCPUのクロック周波数は1.6GHz

図5●DBサーバーの入れ替えに伴うCPU使用率の推移 DBサーバーとOSを入れ替えたことで，ようやくレスポンス悪化の問題が解決した

図6●今後の拡張方針 今年の夏は現状の構成で乗り切れると判断している。さらにCPUを倍増できるため，拡張性は当面心配ない

　ここまでの対策を実施しても，事態はなかなか改善しない。2004年9月，山本氏はDBサーバー機のさらなる増強を決断する。

　動的キャッシュ・サーバーの当てが外れるという誤算があったとは言え，現行機は2004年7月に入れ替えたばかり。こうした事態を繰り返さないため，拡張性が高く長期間使い続けられることを重視し，米Unisysの「ES7000/420」を選定した。Itanium 2を最大16CPUまで搭載できるため「当初8CPUで稼働させ，その後，余裕を持ったスケールアップができることを評価した」（山本氏）。OSはRed Hat Enterprise Linux AS 3.0である。

　当初は，Oracle Real Application Clusters（RAC）を利用してサーバーを複数台並べるスケールアウト構成を検討した。だが，コスト面で断念した。RACは，Oracle Database 10gからStandard Editionの標準機能として利用できるようになったが，日本旅行が利用しているOracle9i Databaseでは，高額なEnterprise EditionとRACオプションの費用が必要になる。

　ハイエンドのUNIX/RISCサーバーも検討した。だが，Oracleのライセンス料が倍になることなどを嫌って，候補から外した。検討した機種は，デュアルコア技術を搭載したRISCチップの搭載機で，デュアルコアの場合Oracle Databaseのライセンス料は2倍になる。

　ES7000/420の採用を決めた後，現行機と比較してどの程度の改善が期待できるのか，メーカー担当者の協力を仰いで検証を行った。日本ユニシスからマシンを日本旅行に持ち込み，実際のデータとアプリケーションを使って性能を検証した。

　検証結果を見る限り，処理性能の改善は期待できそうだった。図4[拡大表示]は，現行機のSun Fire V880と，新たに購入するES7000を比較したものだ。ES7000は複数のスペックで検証したが，いずれも後者の方が性能が高く，同時アクセス数が増えるほど差は広がる。

成果「今年の夏休みは乗り切れる」

　昨年4月から10カ月後の2005年2月26日，日本旅行は新しいDBサーバーをカットオーバーさせた。効果は顕著に表れた。リプレース前後のCPU使用率を比較したのが図5[拡大表示]である。60％あった平均CPU使用率は，20％近くまで下がった。4月4日から4月11日までの1週間の推移を見ても，50％を超えることはほとんどない。

　「今年の夏休みは，現行のサーバーで乗り切れるだろう」（山本氏）と見ている。その後の拡張についても，当面はあまり心配していない（図6[拡大表示]）。日本旅行が導入したES7000/420は，最大16CPUまで搭載できる。現在搭載しているのは8CPUなので，8CPUを追加搭載する余裕がある。

　ただその場合，OSをRed Hat Enterprise Linux AS 4.0にバージョンアップする予定だ。現在利用しているRed Hat Enterprise Linux AS 3.0はLinuxカーネル2.4をベースにしており，カーネル2.4はSMP構成による拡張性が低く，一般には4～8CPUで性能が頭打ちになると言われている。それに対して，カーネル2.6ベースのRed Hat Enterprise Linux AS 4.0は，SMP構成で比較的リニアに性能向上すると言われている。