【14】リプレースの費用の抑制

【14】リプレースの費用の抑制

ES/1の2年半のデータを活用して、メーカからのリプレース提案を検証
不要なコストの発生を抑制

きっかけ

保守切れに伴いリプレースを検討

保守切れに伴うリプレースを検討されており、システム部門からメーカへ見積もりを依頼されたところ、下記の内容にて提案
がありました。
  • シンクライアントサーバ : 36台
  • APサーバ         :16台
  • DBサーバ       :16台
※サーバ台数および構成は現行と同じだが、CPUスペックは数倍の提案
 
・費用の総合計は約3億円

システム部門の対応

IIMへメーカ提案の検証を依頼

システム部門では、メーカ提案が現行システムの利用状況を考慮していないのではないか、また過剰投資ではないのかとの懸念があり、IIMへ相談されました。


IIMによる性能評価

性能評価概要

1.考え方
  2年半分の性能データを活用し、必要なサーバ台数を求める

2.策定手順
 ①年次グラフにて稼働傾向を把握
 ②着目すべき指標の洗い出し
 ③洗い出された指標に応じたグラフ(積み上げ、折れ線、海温図)にて必要な資源量を検討

3.対象項目

   CPU使用率、空きメモリ状況、I/O負荷、Oracle稼働状況、業務量 (全支店のクライアントアクセスログ)

4.性能評価結果


(図1:全サーバの稼働傾向結果)
 対象項目 稼働傾向結果
CPU業務や地域、時間により負荷に偏りがある
メモリ 余裕あり
ディスク
余裕あり
Oracle
余裕あり
業務量
周期性は見受けられず、増減は少ない

図1の結果より、CPUを指標としました。



サイジングを行うにあたり、業務単位でどの程度システムを利用しているかを把握する必要があるため、最大CPU使用率を積み上げることにより必要なサーバ台数を算出することにしました。

なお、本来であれば実際にCPUを使用した使用量にて判断するべきですが、この環境では全て同一スペックのため、CPU使用率を用いました。

業務サーバ毎のサイジング

<シンクライアントサーバ>
全36台の最大CPU使用率を積み上げると、サーバ4台分に相当しました。
シンクライアントサーバは主にオンライン処理なので、CPU使用率が50%以内に収まるよう、同一スペックのサーバ8台構成としました。

(図2:最大CPU使用率の積み上げグラフ)


<APサーバ>
全16台の最大CPU使用率を積み上げると、サーバ8台分に相当しました。

なお、特定月にて88台分を超える使用状況となっておりますが、業務処理のスケジューリング改善によりCPU負荷が軽減できるため、同一スペックのサーバ8台構成としました。

(図3:最大CPU使用率の積み上げグラフ)


<DBサーバ>
全16台の最大CPU使用率を積み上げると、サーバ16台分に相当しました。
DBサーバは、バッチ処理を改善することでCPU負荷が軽減できるため、同一スペックのサーバ16台構成としました。

(図4:最大CPU使用率の積み上げグラフ)


ES/1による性能評価およびコンサルティングの結果を踏まえて、IIMから以下のとおり回答しました。

案1)リプレース後のサーバ台数
  • シンクライアントサーバ:36台→8台
  • APサーバ         :16台→8台
  • DBサーバ         :16台→16台
※全て現行と同一スペックを想定

案2)現行システムの継続使用
リプレースをせずに、現行システムを継続利用しても問題なし


システム部門のご判断

リプレースの延期を選択

IIMからの回答を検討した結果、システム部門はメーカと交渉し、現行システムの保守を2年間延長しました。

結 論

適切なリプレース案の策定

IIMからの報告を受け、保守を延長することも検討した結果、リプレースではなく延命できました。

さらに、次期リプレースに際しても、メーカ提案の約半分のサーバ台数で賄えることが判明し、メーカ提案額より約1億円の削減を見込めることになりました。