稼動傾向に合わせたCPUのサイジング事例

稼動傾向に合わせたCPUのサイジング事例

2015/11/18掲載

今回は、稼働傾向に合わせたCPUのサイジングを行った事例ををご紹介いたします。

評価案件の概要

物理環境で稼働しているサーバを仮想化環境に移行するため、次期マシンにおけるCPUのサイジング(割当てコア数の見積もり)をしてほしいというご依頼を頂きました。評価対象期間は7カ月で、対象システムはOracleが稼働しているDBサーバです。

サイジングの手順

始めにサイジングを行う手順の概略です。
  1. スペックの確認:Specintを用いて現行マシンのスペックと次期マシンの1コアあたりのスペックを確認
  2. CPUの稼働傾向分析:各サーバのCPUの稼働状況から傾向を分析
  3. CPUのサイジングと割当コア数の見積もり:稼働傾向に合わせたCPUのサイジングと新サーバでの
    割り当てコア数の見積もり
次に、確認した内容の詳細を説明します。

1.現行、新サーバのスペック確認
Specintを用いて現行マシンと次期マシンのスペックを確認した結果です。

<表1:現行マシンと次期マシンのスペック比較>
対象 CPU種類 クロック数 # Cores # Chips # Cores Per Chip スペック
現行マシン SPARC64 VI 2.15GHz 8 4 2 80
次期マシン SPARC64 X+ 3.2GHz 16 1 16 400

現行マシンのスペックは80でした。
次期マシンの1コアあたりのスペックは400/16=25と見積もりました。そのため、現行マシンのスペックでそのまま移行する場合、割当CPU数は80/25=3.2 よって4コア必要と見積もりました。

CPUの稼働傾向の分析とサイジング
現行サーバの対象期間を通したCPU使用率の稼働状況を確認したところ、時間帯によって稼働傾向が異なることがわかりました(図1)。08:00-21:00はオンライン業務、21:00-04:00はバッチ業務を行っているため、08:00-21:00はオンライン時間帯、それ以外の時間帯はバッチ時間帯と分けてCPUの稼働傾向の確認とサイジングを行いました。

図1
<図1:CPU使用率の推移(等高線グラフ)>

① オンライン時間帯の稼働傾向の分析とCPUのサイジング
対象期間を通してCPU使用率は47%以下で、増加傾向も見られませんでした(図2)。

図2
<図2:オンライン時間帯の日毎のCPU使用率(平均/最大)>

Oracleが稼働しているため、同様にオンライン時間帯に絞ってOracleの業務量の増加が無いかも確認したところ業務量も増加していませんでした(図3)。弊社ではConsistent Get(Select処理)とDBGET(更新処理)を併せたものをOracleの業務量の指標としています。

図3
<図3:オンライン時間帯のOracleのバッファキャッシュヒット率と論理DBアクセス回数>

以上の稼働傾向の分析結果からCPUのダウンサイジングが可能と判断しました。

オンライン時間帯はピークの業務量を処理できるCPU能力が必要となります。次期マシンで最大CPU使用率が90%になるCPU能力は、0.47(=47%/100)×80(現行マシンのスペック)×1.1=41.4 よって42と見積もりました。

② バッチ時間帯の稼働傾向の分析とCPUのサイジング
バッチ時間帯のCPU使用率の推移は日ごとのグラフでは傾向が把握できなかったため、月での推移を確認しました。2013年10月~2014年3月の平均/最大CPU使用率はほぼ変わらず4月はCPU使用率が他の月に比べてやや高いことがわかりました(図4)。

図4
<図4:バッチ時間帯の月毎のCPU使用率の推移>

オンライン時間帯同様、バッチ時間帯のOracle業務量の推移を確認しました。CPU使用率と同様、4月はやや業務量が増加していました。

次にCPU使用率が高い4月のある3日間のバッチ時間帯(21:00-04:00)におけるCPU使用率の詳細な推移を確認しました。その結果、バッチ終了期限の4時前にCPU使用率が低下していることがわかりました(図5)。

図5
<図5:バッチ時間帯(21:00-04:00)のCPU使用率>

以上の稼働傾向の分析結果から、CPUのダウンサイジングが可能と判断しました。
バッチ時間帯は、処理が終了期限までに終了することがダウンサイジングを行う際の条件となります。そのため、CPU能力をダウンサイジングした際のCPU使用率の推測を行いました(図6)。

図6
<図6:CPU能力をダウンサイジングした際のCPU使用率の推測>

推測の結果、CPU能力は60%までダウンサイジング可能と判断しました。
よって、バッチ時間帯で必要なCPU能力は0.6×80(現行マシンのスペック)=48 よって48と見積もりました(後日談:バッチ終了期限は厳守という事で余裕を持って見積もりをされているとのこと)。

③ CPUのサイジング結果と割り当てコア数
時間帯によって業務が異なるためオンライン時間帯、バッチ時間帯それぞれで必要なCPU能力を見積もりました。結果、オンライン時間帯:42、バッチ時間帯:48となり、DBサーバ1で必要なCPU能力は48となりました。
そのため次期マシンで必要な割当コア数は48/25(1コアの能力)=1.9 となり、2個と見積もりました。

現行マシンのスペックをそのまま移行した場合、各サーバの割り当てコア数は4コアとなります。ただし、CPU能力に余裕があるため、積極的なダウンサイジングを行った場合、各サーバの割り当てコア数は2コアと半分に削減可能です。

3.割り当てコア数削減のメリット
割り当てコア数を削減する事で下記2点のメリットがあります。
  1. サーバ購入費を削減可能
  2. アプリケーションの課金はCPUのコア数で行う事が多いため、アプリケーションライセンス費用を削減可能

まとめ

CPUのサイジングを行う際には稼働傾向を把握する必要があります。業務の違いや、CPU使用率の増加/減少の傾向でサイジングの方法が異なります。稼働傾向を把握する事で適切なCPUのサイジングが可能です。
また、稼働傾向を把握するには長期データが必要です。ピーク期間を含む数か月~年単位の稼働データを分析することで稼働傾向を把握することが出来ます。常日頃から稼働データを取得し、長期保存を行ってください。