第4回では対策立案フェーズのサイジングに関して説明していきます。サイジングとは，増設・交換するハードウェアの種類や数を具体的に選定することです。スケールアップなら，CPUを何個増設するか，メモリを何ギガバイト増設するか，スケールアウトなら，サーバを何台増設するか，そしてサーバリプレースなら，どのサーバに交換するかを決めます。
スケールアップ，スケールアウトは，数や種類が限られているため，比較的選定は容易ですが，サーバリプレースの場合は，選定対象が多いうえに，キャパシティに与える効果の予測が立てにくいので，選定が困難になります。第4回では，このサーバリプレースのサイジング手法について詳しく説明していきます。
図1 対策立案フェーズの流れ
サーバリプレースにおけるサイジング手法
サーバリプレースにおけるサイジング手法として「ベンチマーク値によるサイジング」「シミュレーションツールによるサイジング」の2つがあります。以下，それぞれについて説明します。
ベンチマーク値を用いたサイジング
ベンチマーク値とは，さまざまなサーバの性能を比較するための値です。たとえば，サーバAのベンチマーク値が「10」ならば，その2倍の性能を持つサーバBのベンチマーク値は「20」と表されます。これらの値を使用して，サーバリプレースの対象を選定するのが，ベンチマーク値を用いたサイジングです。これらの値は，実際に性能測定を実施して測定された値です。
ただし，サーバの性能はその上で動く処理に依存するため，世の中にはさまざまな処理で測定されたベンチマーク値が存在します。たとえば，「TPC-C」というベンチマークは，流通業の注文処理で測定された値で，「SPECint」というベンチマークは，整数演算の処理で測定された値です。このように世の中にはさまざまな処理のベンチマーク値があります。
それでは具体的に「せいのう.jp」の例で見ていきましょう。今回は話を簡単にするために，架空のベンチマーク値を使用して説明していきます。また，第3回の最後に書いたとおり，「せいのう.jp」の状況を見る限りは，DBサーバのチューニングか，CPUの増設が有効であるという話をしましたが，今回は，DBサーバをリプレースしてキャパシティ改善を図るという前提で説明します。まず，第3回で紹介した，せいのう.jpの改善目標と，「せいのう.jp」の将来の性能を予測した図を掲載します。
表1 せいのう.jpのキャパシティ改善目標
| ① スループット目標 | 36,000リクエスト／5分間 |
|---|---|
| ②レスポンスタイム目標 | 5秒 |
| ③リソース使用率目標 | DBサーバCPU使用率70％ |
図2 将来の性能予測
表1と図2から，表2の内容が読み取れます。
表2 キャパシティ改善前後のスループット，DBサーバのCPU使用率，ベンチマーク値
| スループット | DBサーバのCPU使用率 | ベンチマーク値 | |
|---|---|---|---|
| キャパシティ改善前 | 24,000リクエスト／5分間 | 70％ | 10 |
| キャパシティ改善後 | 36,000リクエスト／5分間 | 70％ | ？？？ |
図2から，キャパシティ改善前では，DBサーバのCPU使用率が70%の状態で，24,000リクエスト／5分間を処理できていることがわかります。そして，キャパシティ改善後には，同じCPU使用率で36,000リクエスト／5分間を処理できるようにすれば目標達成です。ですので，単純に，36,000÷24,000＝1.5倍の性能を持つサーバにリプレースしてあげれば良いことがわかります。
仮に現在のサーバのベンチマーク値を「10」だとすると，10×1.5＝15ですので，「15」のベンチマーク値をもつサーバにリプレースしてあげればよいことがわかります。このように，ベンチマーク値から適切なサーバを割り出すことが可能です。
ここで問題になってくるのが，どのベンチマーク値を使用するかです。上で説明したとおり，世の中にはさまざまなベンチマーク結果が存在します。今回の例である「せいのう.jp」はオンラインショッピングサイトなので，流通業の注文処理で測定された「TPC-C」が適切だと考えられますが，このベンチマーク結果だけで判断するのは問題があると言えます。なぜなら，「TPC-C」の処理が「せいのう.jp」の処理と同じ性能の傾向をもっているかどうかの確証がないためです。似た処理であることは確かですが，そこに生じる差がどれだけ性能にインパクトを与えてくるかはわかりません。
ですので，1つのベンチマーク結果に判断を左右されないよう，複数のベンチマーク値を使用してサイジングを行うことが多いです。中でも「SPECint」は結果の登録数が多く，汎用的なベンチマーク値ですので，このベンチマーク値を参考値の1つとして含めることをお勧めします。
また，ベンチマーク値を使わずに，単純にCPUのクロック周波数でサイジングを行う場合がありますが，この際は1点注意が必要です。同じCPUのアーキテクチャに交換するのであれば，そこそこ正確なサイジングが可能ですが，異なるCPUアーキテクチャに交換する場合，この方法では正確なサイジングは行えません。なぜなら，クロック周波数＝性能値ではないからです。同じCPUアーキテクチャではこの式は成り立ちますが，CPUアーキテクチャが異なれば，全く成り立たなくなります。
たとえば，IntelのXeonとSun MicrosystemsのSPARCは，同じ周波数でも性能は異なります。さらに，Xeonの場合は世代によってアーキテクチャが異なるので，たとえ同じXeonを搭載したサーバへリプレースをするとしても注意が必要です。このように，異なるCPUアーキテクチャへのサーバ交換をする場合は，必ずベンチマーク値によるサイジングを行う必要があります。
