PR

解決策(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構成で比較的リニアに性能向上すると言われている。

(尾崎 憲和)