サーバの見積もり方法

こんにちは。エンジニアの玉置です。

f:id:tama1029hq:20160330174059p:plain

今回はサーバの見積もり方法について紹介します。

クラウドサービスはとても便利な機能を提供してくれるようになっています。 サーバのオートスケールなども勝手にやってくれるようになり、開発者がアプリケーションのパフォーマンスを意識することが減ってきています。

しかし、パフォーマンスを意識しなくなることにもリスクが有ります。 クラウドサービスに任せっきりにした結果、無駄にコストを支払ってしまってることに気付けないかもしれません。 自分たちのサービスがどれだけのサーバーを稼働させているのかを把握しておくことは、消費されるコストの把握にもつながります。

サーバの見積もりを出すのに必要な情報ってなんでしょう?

現在自分が関わっているサービスだと、月間2000万ユーザーに使っていただいています。 サービスの性質上、短時間に大量のユーザーがアクセスすることもあります。 こうした状況で、サーバの見積もりを出すのに必要な情報は秒間最大アクセス数だと思います。

今回は秒間最大アクセス数を500と仮定して話を進めたいと思います。

今回扱うサーバの構成

Web Server、Application Server、DataBase Serverの3つのサーバを扱います。

図1. 基本構成

f:id:tama1029hq:20160330174324p:plain

図2. サーバ構成

サーバの種類 台数 CPUコア数
Web Server 1 2
Application Server 1 2
DataBase Server 1 2

それでは現状の把握をしてみよう

アプリケーションのパフォーマンスを測るのにjmeterを使用します。 jmeterはHTTPリクエストを大量に送ることで、大勢のユーザーがアクセスしている状況を作ることができます。

今回は単純なリクエストで使用しますが、シナリオ書いて実行などもできます。他のやり方もありますが、その先の事も考えjmeterの使い方を紹介します。

イメージ図

f:id:tama1029hq:20160330174325p:plain

jmeterの設定

100スレッドで、10秒間に10回送る設定の場合を見ていきます。

1.スレッドグループの追加と設定

テスト計画-> 追加 -> Thread(Users) -> スレッドグループ

f:id:tama1029hq:20160330174327p:plain

f:id:tama1029hq:20160330174333p:plain

2.HTTPリクエストの追加と設定

スレッドグループ -> 追加 -> サンプラー -> HTTPリクエスト

f:id:tama1029hq:20160330174339p:plain

好きなurlに書き換えてください f:id:tama1029hq:20160330174345p:plain

3.統計レポートの追加

テスト計画 -> 追加 -> リスナー -> 統計レポート

f:id:tama1029hq:20160330174351p:plain

これで100人が一気にアクセスしてくるのがテストでき、結果の集計も統計レポートがやってくれます。

上記の方法で出力したものがこちらです。

f:id:tama1029hq:20160330174358p:plain

このサービスがさばくことのできる秒間最大アクセス数は約60程度ということが分かりました。

ここまでで分かったこと

Web Server、Application Server、DataBase Serverを通して、秒間最大60アクセスをさばけるパフォーマンス、ということが分かりました。500アクセスをさばくためには、今の8倍必要です。 しかし、より詳細な見積もりをするにはそれぞれのサーバのパフォーマンスを見ていく必要があります。

それぞれのサーバのパフォーマンスの見方

dstatコマンドについて

まず、パフォーマンスを測るのに便利なコマンドについて説明します。

dstatのインストール $ sudo yum install dstat

およそ全部見れるdstatコマンド $ dstat -Tclmdrn --tcp --udp

試しに出力したもの f:id:tama1029hq:20160330174359p:plain

左から

  • epoch : 時間
  • total-cpu-usage : CPUの使用率
  • load-average : ロードアベレージ
  • memory-usage : メモリ使用量
  • dsk/total : ディスクI/O
  • io/total : I/Oリクエスト数
  • net/total : ネットワーク
  • tcp-sockets : TCPコネクション
  • udp : UDPコネクション

をそれぞれ一望することができます。

次にdstatコマンドを使って、Web Server、Application Server、DataBase Serverを前述したjmeterを使用した場合で見ていきましょう。

下記の例だと、dstatの結果を上から順にWeb Server, Application Server, DataBase Serverと並べてます。

f:id:tama1029hq:20160330174402p:plain

それぞれのサーバのパフォーマンスを見て分かること

パフォーマンスを見るときに、リクエストが詰まる要因は、メモリの使用量や、CPU使用率等、いくつか考えられます。 今回のケースだと、下図の赤で囲ってあるCPU使用率に着目すると、Application ServerでCPUリソースが足りない可能性があります。 Web Serverの最大パフォーマンスを測る場合を考えると、Application Serverがボトルネックになってしまっているので最大パフォーマンスを出せてるとは言えません。

f:id:tama1029hq:20160330174409p:plain

ですので、Application ServerのCPUのスペックを上げて測り直します。

すると、今度はWeb Server側のCPU使用率があがっているのが分かります。

f:id:tama1029hq:20160330174414p:plain

このように、詰まっている部分が解消されるようにスペックを上げていき、この手順を繰り返すことで、サーバ全体の最大パフォーマンスを測ることができます。

ではこの状態の秒間最大アクセス数を見てみます。

f:id:tama1029hq:20160330174417p:plain

Appliction Server でリクエストが詰まっていない状態だと、Web Serverは秒間最大アクセス数が 96.6 さばけることが分かりました。

Appliction Server は元々リクエストが詰まっていましたので、秒間最大アクセス数は 60 です。このように、それぞれのサーバで必要な台数は変わってくることが分かりました。

サーバの種類 秒間最大アクセス数500耐えるための台数 秒間最大アクセス数
Web Server 5 96.6
Application Server 8 60

終わりに

今回はサーバの見積もり方法を見てきました。jmeterを使用してサーバに対して負荷をかけ、サーバの最大パフォーマンスの見方を知ることで必要な台数の把握をすることができました。 これによって、何台起動するかを事前に知っておくことができ事前に費用の計算なども行えます。

余談

2コアを扱いましたが、実際はコア数が異なるサーバで運用すると思います。 扱いやすくするために1コアでの秒間最大アクセス数に置き換えておくと良いと思います。

また、CPUが1コアとマルチコアの場合で1コアあたりの処理能力が変わります。 自社サービスでの1例をあげますと

  • 1コアの場合、秒間最大アクセス数は22~24前後
  • 2コアの場合、秒間最大アクセス数は60~61前後

となっておりました。