第4回では対策立案フェーズのサイジングに関して説明していきます。サイジングとは、増設・交換するハードウェアの種類や数を具体的に選定することです。スケールアップなら、CPUを何個増設するか、メモリを何ギガバイト増設するか、スケールアウトなら、サーバを何台増設するか、そしてサーバリプレースなら、どのサーバに交換するかを決めます。

スケールアップ、スケールアウトは、数や種類が限られているため、比較的選定は容易ですが、サーバリプレースの場合は、選定対象が多いうえに、キャパシティに与える効果の予測が立てにくいので、選定が困難になります。第4回では、このサーバリプレースのサイジング手法について詳しく説明していきます。

サーバリプレースにおけるサイジング手法

サーバリプレースにおけるサイジング手法として「ベンチマーク値によるサイジング」「⁠シミュレーションツールによるサイジング」の2つがあります。以下、それぞれについて説明します。

ベンチマーク値を用いたサイジング

ベンチマーク値とは、さまざまなサーバの性能を比較するための値です。たとえば、サーバAのベンチマーク値が「10」ならば、その2倍の性能を持つサーバBのベンチマーク値は「20」と表されます。これらの値を使用して、サーバリプレースの対象を選定するのが、ベンチマーク値を用いたサイジングです。これらの値は、実際に性能測定を実施して測定された値です。

ただし、サーバの性能はその上で動く処理に依存するため、世の中にはさまざまな処理で測定されたベンチマーク値が存在します。たとえば、「⁠TPC-C」というベンチマークは、流通業の注文処理で測定された値で、「⁠SPECint」というベンチマークは、整数演算の処理で測定された値です。このように世の中にはさまざまな処理のベンチマーク値があります。

それでは具体的に「せいのう.jp」の例で見ていきましょう。今回は話を簡単にするために、架空のベンチマーク値を使用して説明していきます。また、第3回の最後に書いたとおり、「⁠せいのう.jp」の状況を見る限りは、DBサーバのチューニングか、CPUの増設が有効であるという話をしましたが、今回は、DBサーバをリプレースしてキャパシティ改善を図るという前提で説明します。まず、第3回で紹介した、せいのう.jpの改善目標と、「⁠せいのう.jp」の将来の性能を予測した図を掲載します。

表1と図2から、表2の内容が読み取れます。

図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アーキテクチャへのサーバ交換をする場合は、必ずベンチマーク値によるサイジングを行う必要があります。

シミュレーションツールによるサイジング

ベンチマーク値によるサイジングは、サーバリプレースの対象となっているサーバだけを考慮したものです。ですので、下記のようなことが発生しうる場合は、ベンチマーク値のサイジングによるサーバリプレースでは狙った効果が得られない場合があります。

• ① ボトルネック[1]となっているサーバをリプレースしても、すぐに別のサーバがボトルネックとなる
• ② 構成の複雑なシステムで、特定の処理の待ちがボトルネックとなり、サーバリプレースしても効果が出ない
• ③ 業務の種類が多く、また個々の伸び率が異なり、かつ、各サーバに掛かる負荷も異なるため、将来のリソースの使用率が予測できない

今回の「せいのう.jp」では業務の種類が少なかったので、キャパシティ限界が来る日 がいつで、その原因がDBサーバのCPU使用率であることがグラフから簡単に予測できましたが、業務の種類が多く、それぞれ負荷量が異なり、かつ、サーバの構成も複雑である場合、これを簡単にグラフから予測するのは容易ではありません。

このような複雑なシステムのサイジングを補助するツールとして「シミュレーションツール」というものが存在します。有名な製品としては、Hy-PerformixのPerformance Optimizerが挙げられます。

シミュレーションツールは、ツール上に仮想のシステムを構築し、それに対して仮想の性能測定をすることで、サイジングを行うことができるツールです。基本的に、ツール上の仮想システムは「ワークロード」「⁠ソフトウェア」「⁠ハードウェア」の3つの概念から成り立っており、それぞれの概念に値を定義することで、仮想の性能測定を実施し、キャパシティ改善目標を満たすことができるサーバを選定することができます。

「ワークロード」は仮想システムへ来るアクセスに関する値を定義します。たとえば、システムを使用するユーザ数や、各ユーザが実行する業務の種類とその実行比率などを定義します。「⁠ソフトウェア」は各業務が実行された際のリソースの消費具合を定義します。たとえば、業務Aが1回実行される際のCPU使用率などを定義します。「⁠ハードウェア」はハードウェアリソースの性能を定義します。この定義は、ツールが保持する固有のベンチマーク値が使われることが多いです。現状のサーバを基準に、各種サーバの性能をツールが自動的に定義します。この「ハードウェア」の部分をさまざまなサーバに変えていくことにより、最適なサーバを選定することができます。

このように、ベンチマーク値によるサイジングだけでは把握しきれない複雑なシステムをサイジングする場合は、シミュレーションツールの使用をお勧めします。

拡張性について

また、サーバリプレースのサイジングをする際には、今後の拡張性も視野に入れる必要があります。例えば、4CPUのサーバでも、最大4CPU搭載可能なサーバと、最大8CPU搭載可能なサーバでは、今後のキャパシティ改善計画が変わってきます。前者では、これ以上CPUを増やせないため、サーバリプレースでキャパシティ改善をするしかないですが、後者の場合は、CPU増設によるスケールアップが可能です。このように、将来のキャパシティ改善を見越したサイジングが必要になってきます。

効果確認

キャパシティ改善計画通りに改善を実施することができたら、次は効果確認をする必要があります。なぜなら、今まで緻密にキャパシティ改善計画を立ててきましたが、これらはどんなに緻密に計画してもあくまで予測に留まらないからです。ですので、稼働中のシステムのキャパシティが本当に改善しているのかを確認する必要があります。仮に対策が有効でなく、キャパシティ改善の目標を達成できていない場合は、またキャパシティ改善のサイクルを実施する必要があります。

効果確認には「性能試験」「⁠稼働中の性能監視」2段階のステップがあります。以下、それぞれについて説明します。

性能試験

性能試験では、キャパシティ改善を実施したシステムに対し、負荷生成ツールなどで負荷を掛け、キャパシティ改善の効果を確認します。この時に確認すべきことは、システム終了日の負荷が掛っても、キャパシティ改善目標を満たしていることです。また、この際にキャパシティの限界を確認しておくと、次回のキャパシティ改善時に役に立ちます。但し、性能試験はシステムのサービス提供が停止している状態でないとできないため、基本的にはキャパシティ改善実施と同じタイミングで実施することになります。ですので、キャパシティ改善実施の予定を立てる際は、性能試験に掛る時間も予定に入れておきましょう。

稼働中の性能監視

キャパシティ改善後にシステムのサービスが開始されたら、今度は稼働中システムの性能監視をする必要があります。ここでは、予測していた性能が実現できていることを確認します。仮に予想していた性能を大幅に下回っていた場合は、もう一度キャパシティ改善サイクルを実施する必要があります。また、その時点ではシステム終了日までの性能は確認できないので、日々の性能監視が必要になってきます。日々の性能監視は、次回のキャパシティ改善の判断材料にもなるので、必ず実施しましょう。

まとめ

全4回に渡り、稼働中システムのキャパシティ改善について説明してきました。今回説明してきた内容は初心者向けですが、キャパシティ改善の流れについては本格的なものとなっていますので、キャパシティ改善をする際には是非参考にして頂けると幸いです。キャパシティ改善の要は、性能問題が発生しないよう予防をしていくことです。システムに性能問題が発生してからでは手遅れですので、必ず定期的なキャパシティ改善サイクルを実施し、性能問題のない安定したシステム運用を目指しましょう。また、日々の性能データがキャパシティ改善の成否を分けますので、稼働中システムの日々の性能データは必ずとるようにしておきましょう。