昨今のWebシステムは，社内系ではサーバー・リソースに余裕が多くある半面，社外系では過負荷な状態になりがちです。こうした傾向を考慮に入れ，相反する運用要件を満たす運用設計術を説明します。
相反する二つの要求をかなえる
ここでは，「人事管理」「販売管理」「物流管理」「電子商取引」という四つのシステムを抱える企業を想定します。いずれもWebシステムで，電子商取引システムのみ社外系のシステムになります（図1）。これらのシステムの関係者にヒアリングしたところ，システム運用において二つの要求が挙がりました。
 |
| 図1●運用設計するシステムのイメージ 社内系の「人事管理システム」「販売管理システム」「物流管理システム」と，社外系の「電子商取引システム」で構成される。インフラ維持のコストを下げつつ，電子商取引システムのサービス・レベルを維持する運用設計を検討する [画像のクリックで拡大表示] |
要求1：「インフラ維持にコストがかかりすぎている。特に保守コストが目に余るので，何とかしてほしい」（情報統括責任者）。
要求2：「パフォーマンスを含め，電子商取引システムのサービス・レベルを維持してほしい」（電子商取引システムを使ってコンシューマ向けビジネスを実施している責任者）。
この二つの要求は一般的なWebシステムでも挙がりやすいものですが，インフラ維持のコストを安易に下げてしまうと，システムのサービス・レベルを下げてしまう恐れがあります。つまり，この二つの要求は，相反する意向を含んでいることに留意する必要があります。
インフラ維持のコストを下げるには，サーバー統合して管理対象のサーバー・マシンを減らす方法が考えられます。このとき生まれた余剰マシンで，サービス・レベルの維持に活かす仕組みを作れば，二つの要求を満たすことができます。一般にセキュリティ上の観点から社内系と社外系のシステムは分割すべきなので，以下では「社内系システムのインフラ・コストをサーバー統合で下げる」，「社外系システムのサービス・レベルを維持する」の順に，具体策を説明します。
インフラ・コストを削減
サーバー統合が可能かどうかを判断するため，まず各サーバーのリソース（CPU，メモリー，ディスクなど）使用量を調査します。
ピークの時間帯を調査
一般にオープン系のシステムでは，平均的なCPU使用率は小さくなりがちです。なぜなら，パフォーマンス設計におけるキャパシティ・プランニングを通じて，ピーク時を見越してリソースを準備しているからです。余裕を持ってリソースが準備されていますので，平均使用率が下がるのは当然です。
この企業のシステムも例外ではありませんでした。社内系システムのWeb/APサーバーの平均CPU使用率は，人事管理システムで約5％，販売管理システムで約17％，物流管理システムで約13％しかありません。ただし，販売管理システムと物流管理システムのピーク時のCPU使用率は，90％近くに達していました。
次に，システムごとのピークの時間帯を確認します。各システムのWeb/APサーバーのCPU使用率をグラフ化したところ，人事管理システムは午前2時から午前3時，販売管理システムは午前4時から午前5時，物流管理システムは午前6時から午前7時にピークを迎えていることを確認できました（図2左）。ピークは各システムの日次バッチの実行時間でした。
 |
| 図2●各システムのCPU負荷を基にサーバー統合の実現可能性を判断 左のグラフは，人事管理システム，物流管理システム，販売管理システムにおけるWeb/APサーバーのCPU使用率の推移を示したもの。この三つの累積グラフを右に示した。各システムごとにピーク時間帯がずれているので，サーバー統合してもCPU使用率が100％に達する（処理能力が不足する）可能性は少ないと判断できる [画像のクリックで拡大表示] |
サーバー統合可能かどうかを判断する際のポイントは，統合対象サーバーの合計のリソース使用量です。この例の場合，各時間のCPU使用率を足し合わせてみると，図2右のグラフになります。それぞれのシステムのピークの時間帯がずれているので，累積しても100％を超えることはありません。つまり，三つのシステムのWeb/APサーバーを1台の物理サーバーに集約しても，その物理サーバーのCPU使用率は100％を超えないと予測されます。ゆえに，サーバー統合でマシン台数を削減できる可能性が高いのです。
仮想化技術で障害の影響を小さく
次に，サーバー統合技術を説明しましょう。単純に1台の物理サーバーに複数システムを共存させると，一つのシステムで障害が起きたときにほかのシステムにも影響が出るなど，信頼性を大きく下げることになりかねません。そこで最近注目を集めているのが，サーバー仮想化技術です。
サーバー仮想化とは，物理的なサーバー上のリソースを仮想的かつ論理的な利用単位に分割・再配分する技術です。この技術は，（1）物理パーティション技術，（2）論理パーティション技術，（3）仮想マシン技術――の三つに大別できます。
（1）物理パーティション技術とは，仮想サーバーをハードウエア的に構築する技術です。1台のサーバーに複数のシステム・ボード（CPU，メモリー，I/O制御モジュールを載せたもの）を搭載し，このボードを最小単位として組み合わせて「物理パーティション」を作ります。物理パーティションはファームウエアで制御され，電気的に分離されますので，あるパーティションの障害が別のパーティションに悪影響を及ぼすことはありません。この技術はホスト機やミッドレンジ以上のUNIXサーバー機などに実装されています。
（2）論理パーティション技術とは，システム・ボードに依存せずにリソースを分割し，リソースの割り当てを自動的に増減できる技術です。ファームウエアと特殊なOSによって制御します。主要なUNIXサーバー機はこの機能を備えています。
「サーバー仮想化ソフト」と呼ばれるソフトウエアによって実現するのが，（3）仮想マシン技術です。サーバー仮想化ソフトとしては，米VMwareの「VMware Server」やオープンソース・ソフトの「Xen」などが有名です。サーバー仮想化ソフトの稼働環境となる汎用OS（＝ホストOS）が必要な場合と，サーバー仮想化ソフト自体に専用OSが組み込まれている場合があります。最近では，米Intelや米Advanced Micro Devices（AMD）のCPUにサーバー仮想化を支援する技術が盛り込まれるようになり，WindowsやLinuxでもサーバー仮想化技術を使用しやすくなりました。
ここでは，（3）仮想マシン技術（ホストOSが不要なタイプ）を利用してサーバー統合することを考えてみます。図1の三つの社内系システムを，仮想マシン技術で集約した構成例が図3です。旧システムのWeb/APサーバーとDBサーバーがほぼ同スペックのマシンで，負荷状況も同程度の場合，サーバーのリソース量を2倍にすれば，すべてのWeb/APサーバーとDBサーバーを1台に統合できます。可用性を考慮しても2台で済みますが，ここではあえて3台構成にしています。1台のサーバーに障害が発生しても，サービス・レベルを落とさないための措置です。また，サーバー仮想化ソフトのオーバーヘッドと，データ量の増大に伴うピーク時間帯の変動に伴うリスクを見込んで，図3の例ではメモリー容量は4倍にしています。
 |
| 図3●仮想化ソフトを使って3台のサーバーに統合 3台の物理サーバーに計18個の仮想サーバーを構築する。可用性を考慮し，3台のサーバーに「人事管理」「販売管理」「物流管理」という各システムを分散配置する。旧システムでは計11台だった物理サーバー台数が3台に減る。CPUやメモリーなどの増強コストはかかるが，サーバー機の保守費用，電気代，ラック・スペースなどが削減されるので，インフラ・コストの低減という要求に応えられる [画像のクリックで拡大表示] |
|
