ある企業では、設置以来丸5年を経過したシステムが、サーバ150台を数えるほどになっていました。そこで、ハード、ミドルウェア等を最新版へアップグレードし、さらにVMwareなどの仮想化ソフトウェアの採用を検討しながら、サーバ群を一気に13台に集約させようと考えました。
今回は、ユーザ企業はいかにして事業要件からプロジェクト発足のための未来図を作り、予算を確保し、案件化していくのかをストーリーをわかりやすくするために、架空のプロジェクトを利用して、案件の定義付け、ハード、OSの選択、プロジェクト化まで凝縮して紹介したいと思います。
案件の誕生まで
あるユーザ企業が、この連載の第1回に記載したポリシーで事業サービスを提供していましたが、システム的には丸5年目を迎え、Webサーバが100台と、Webサーバが参照するためのDBサーバが50台を数えるまでに増大。これらの設置、監視、保守に関しては全て外部委託されていました。
ここ数年はシステムとして安定期に入っているため、サービス施策に対応したプログラムの改修を行うといった運用的な局面でした。しかしながら、ハードウェアに関しては、同型サーバの販売打ち切りや、導入されている商用ミドルウェアバージョンのEOSL（End Of Service Life：サービス提供終了）等を迎えはじめてきたのをきっかけに、ハード、ミドルウェア共に最新版へアップグレードすることにより、保守の延命、スペック向上による台数の削減ができるのではないかと考えました。
そこで「今のシステムは何台に集約できるか？」「 業務アプリケーションの改修対応は必要なのか？」「 運用は変わってしまうのか？」等といった疑問に、どのように対応していくのか検討しました。
①大義名分を明確に
これはどのようなプロジェクトでも行っているように「目的」を明らかにする事にします。今回は、以下のように定義付けます。
事業（サービス）要件としては、提供サービス機能、応答などのSLAを共に現行踏襲とする。
運用要件としては、上記対象のすべてのサーバ／ミドルウェアを最新機器に置き換え、保守期間の延命を実現させる。
努力目標として、初期投資より性能向上が実現された分の台数を減少（集約）させ、運用費用軽減より費用の回収を実現させる。
②プロジェクトを進めるために
上記のような要件から予算を確保してプロジェクトをスタートさせるための資料に記載する内容を検討します。
これは、上記のような状態で、既存ベンダやSIerに向けて「弊社でサーバの入れ替えを行うことになったが、何台くらいになる？ 見積もりはくらいかな？」等と言っても、予算確保できるような実現的な計画、見積もりが出てくることはなかなか難しく、経営側へ説明をしても理解を得られない可能性があるためです。そこで、以下のように検討してみます。
・現行踏襲の定義を行う。
サーバのロードアベレージが高い状態でない場合は、上限のセッション数等、現行システムが保証できるであろう数値の明確化を実施する。
・5年前と直近のハードウェアはシステム係数を利用して性能向上を仮定する。
今回はわかりやすくするため、一律5倍の性能向上としました。
・ミドルウェアの検討は、現行プロダクトのバージョンアップと、同等のオープンソフトウェアの両方を検討する。
・上記の検討結果を検証する期間を設け、何を検証し、どのような結果を提出するか定義する。
これを元に机上にて検討を行い、結果については集約の目標に関する概算見積もりとともに、いったん本番対応までの全てを計画予算としてユーザ企業の経営側の承認を仰ぎ、プロジェクト開始とします。またこの際、集約後の運用費用軽減から損益分岐を割り出し、投資回収等も明記できればなお良いでしょう。
計画予算から実行できる部分は、机上の検討の裏付けとして、最小構成での検証を行い、本番対応部分として残分対応の信憑性を結果として取得することと、本番対応部分の再見積もりまでとします。
最悪、机上の計算に謝りがあった場合等は「最新ハードウェアでも思いのほかパフォーマンスが出ずに集約ができなかった」「 ミドルウェアのバージョンアップにより、業務アプリケーション側にクリティカルな対応が必要になった」といった場合の判断を行うべく、リカバリ可能にする必要があります。
構成の決定まで［Webサーバ編］
現行のシステム構成が以下となっていることを前提とします。
Red Hat Linux3.x（32ビット）
Apache 1.3 100プロセス
Tomcat 5.0 200スレッド／1コンテナ
上記の設定のマシンが100台あった場合、プロセス的には10,000の同時処理を実現できていることになり、これが現行のSLAに近いものと仮定します。
おおよそWebサーバの場合、ハードウェア側の性能を使い切ることは難しく、上記のようにアプリケーションセッションを1台あたりどの程度持たせ、処理を行わせるかというところから、HTTP／APサーバの定義を設定することとします。
ハードウェアの性能を使い切っていないのであれば、このままプロセスやスレッドなどを上げてしまえばいいかもしれませんが、どこかを境にミドルウェアが不安定になったり、ネットワークなどに負担をかけてしまったり別の場所で歪みが出てくる場合があります。このあたりは、ユーザ側の業務要件や事業の特性や設定項目、チューニングなどから値を決定していく必要があります。
ハードウェアの性能向上を考慮に入れ、新システムとして以下の構成を検討しました。
VMware ESXi 4.x（1台あたり2ゲスト構成）
CentOS 5.4（64ビット）
Apache 2.2 1,000プロセス
Tomcat 6.0 200スレッド／5コンテナ
上記の設定のマシンで10,000プロセスを実現するには、論理的には10台程度あれば可能となります。
今回は、さらにWebサーバにVMwareを採用し、1台のマシンに2ゲストを稼動させると、理論上の半分の5台で10,000プロセス稼動を実現できます。そのため、まずは最新スペックのマシンで、1ゲスト、2ゲストと、Apache 2.2で1,000プロセスずつ稼働することから検証を行います。
●Webサーバにオープンソースが貢献
上記の通り、Webサーバに関しては今回のプロジェクトで大幅に構成を変更しています。それぞれの要素について、もう少し詳しく見ていきましょう。
●OS
Red Hat LinuxからCentOSへの移行に関しては、大手メーカやベンダなど、採用実績や保守メニューなどがない場合があり、動作を保証しなければならない業務アプリケーション開発担当の顔色を見ながら検討する必要があります。ただし、Red Hat Linuxの場合は、オープンソースかどうかではなく、販売形態（サーバ本体に紐付くバンドル版によるイニシャル費用の軽減）や年額保守費用という考え方があり、ユーザ企業側としては立派にランニングコストがかかるもの（＝商用プロダクト）と認識します。
この場合、ユーザ側としては今までお金で保守を購入していたことになりますので、今日まで開発元へ問い合わせを行わなければ解決できなかった問題、障害があるか、また、その他プロダクト等でRed Hat Linux以外では保証されないものがどの程度あるのかを徹底的に調査し、その結果、Webサーバに関してはCentOSへ移行できると結論付けました。
●Apache／Tomcat
Apache／Tomcatに関しては一般化されているという認識があり、イニシャルや保守費用などに関してもよほどのことが無い限りは発生しないと思います。これらはアップグレードを実施して機能や性能の向上を実現する対応とします。
●仮想化－VMwareの商用版と無償版
昨今、着々と脚光を浴びている仮想化技術ですが、ここでは事業系企業が初めて仮想化技術を採用するためのアプローチ、検討事項、採用に向けてのシステム構成を記載したいと思います。
VMwareに関しても商用版を選択した場合、Red Hat Linux等を利用するのと同じく、イニシャル、ランニング費用が必要となります。しかし、VMwareに関しては、機能に対して費用が発生するイメージとなりますので、業務要件や、監視・運用等を考慮して採用する必要があるか否かを検討することなります。各機能や、価格帯についてはVMwareのサイト等を参照していただくとして、今回の案件では大まかに以下の3点について検討しました。
［検討1］ディスク装置に関してRAID 1を利用した運用からRAID 0に変更し、リソースの確保と運用の変更を行う。
→ディスク障害が発生した場合、サーバ自体を本番サービスから切り離し、パーツを交換し、最小限の設定後、外部ディスクからイメージファイルを戻し、アプリケーションの差分を埋めて改めて本番サービスへ組み込む運用を実現した。これにより、今まで行っていたテープでのシステムバックアップやディスクのリビルドなどの運用を廃止する事ができた。
［検討2］業務アプリケーションに関しては、単一のサービスを大量のサーバで提供していたが、サーバ自体が性能向上による台数集約が実現されるため、VMotionなど商用にしかない機能を利用せずに、サーバ自体を＋n台構成としてスケールで対応できるようにした。
→これにより、監視、運用の設計をしっかりする事で、無償版のVMware ESXiを採用することができた。（ ＋n台については、最小構成5台＋n台とし、イニシャル時に準備する事とした）
［検討3］サーバ側のディスク（スライス）設計として、ハイパーバイザが構築されるエリアをRAID 1とし、更に仮想OSごとにRAID 0のスライスを割り当てる事で、OS単体に障害が発生しても、他のOSやハードそのものが影響を受けない設計とした。
→その場合、XenよりもVMware製品の方が、システムに対する理解が薄い事業会社の経営陣向けに説明がしやすかった。
実際にゲストとして稼働させる数に関しては、本番にてサービスを提供するという観点より、当初2つのOSを稼働させ、システムの状況を見ながら再度検討する事としました。
構成の決定まで［DBサーバ編］
現行のシステム構成が以下となっていることを前提とします。
Red Hat Linux 3.x（32ビット）
Oracle 9i
現行のデータベース構成はレスポンス性能の担保を行うため、アップデート系とセレクト系を分けています。今回の対象はセレクト系のみとし、以下の構成を検討しました。
Red Hat Linux5.4（64ビット）
Oracle 11g（64ビット）
結果的に、DBサーバ側に関してはOracleからフリーソフトへの転用を見送りました。理由としては、今までOracleの機能に依存した運用を行っている（たとえばMaterialized View）ことにより、他プロダクトへの移行に時間的余裕が無い点などがあげられました。
また、XenやVMwareなどを利用した仮想化を検討しましたが、いずれも利用実績はありそうなものの、プロダクトベンダ（オラクル社）より正式なサポートが得えられそうになかった点がネックとなりました。逆にOracleVMなどの選択肢に関しては、一般的な事例が手の届く場所になく、業務アプリケーション開発部門や、保守ベンダーなどとも話し合い、今回は断念しました。その代わり、OSは64ビット版を採用し、OSそのものの機能向上と、データベース側のキャッシュエリアの拡大などで、ハードウェア以外の性能向上を期待する事とします。
さて、上記を元に、DBサーバ50台を何台へ集約できるか見積もりを実施します。
まず、実際にはシステム係数などで重み付け算出する必要がありますが、マシン性能差は5倍と定義付けました。マシン自体が処理可能なプロセス数は150と定義付け、Oracleを9iから11gへアップグレードすることによる性能向上の期待値を2倍と見込みました。以上より、単純に処理可能なプロセス数は150×2＝300プロセスとしました。
これはシステムが提供している事業によりますが、アクセスピーク時の必要プロセスを1500と予測し、
1500プロセス÷300＝5台
となります（あくまでも机上の計算です） 。
150台が13台になる？
サーバ集約に向けた削減プランでは、以下の台数に削減できそうだという計画としました。（ ハード待機用のマシンに関しては、本番稼働機器台数が少なく、保証しているプロセス数等が大きいほど、ダウン時等のインパクトが大きいため、きちんとしたポリシー定義等が必要なのですが、今回は省略します。）
Webサーバ： 100台→5台＋ハード待機用機器1台＋VM待機用（n台）として1台DBサーバ： 50台→5台＋ハード待機用機器1台監視保守、運用委託台数（合計） ： 150台→13台
上記に加え、スケールアップ用の待機マシン、開発機等を加味する必要がありますが、台数は単純に10分の1以下になるため、運用委託費用等に関しても、かなりの削減が望めます。また、劇的に台数が削減される場合、データセンターのラックや電源など、ファシリティ関連でも費用が軽減されます。さらに、地味ですが、テープバックアップ廃止に伴い、運用、メディア類とバックアップソフトウェア等も廃止にする予定です。
これら全てを取りまとめ、システム投資と回収計画を作成し、計画予算とプロジェクトスタートの承認を仰ぎます。
さて、次回は検証を行った結果、VMware ESXiやOracle 11gについてどのような設定を実施していったか記載できればと思います。
