インフラエンジニアの多分、華形のお仕事の１つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基本的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。
世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基本を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。
目次
- なぜ性能検証をするのか
- 環境の準備
- ボトルネックになりうる項目
- CPU Utilization
- Memory
- Network Bandwidth
- Disk Bandwidth
- Disk IOPS
- Disk Latency
- Disk Size
- Max Throughput
- データ採取と考察
- まとめる情報
なぜ性能検証をするのか
ある程度サービスを運用したことがある人にとっては当然の感覚ではありますが、サーバーの性能や予算が有限であることに対し、ユーザーのリクエスト数ってやつはそんなもん知るかと言わんばかりにそれらを超えて増加し続ける可能性を秘めているモンスターです。耳障りよく言えば『嬉しい悲鳴』ってやつですが、キャパシティーオーバーしたサービスは極端にレスポンスが遅くなるか、エラーを返してしまうかになってしまうため、一時的にはその状況をお祭りとして楽しまれたとしても、数十時間以上も継続するとユーザー達の心は潮が引くように離れてしまうため、絶対に避けなくてはいけません。
そのため性能検証をしておくことで、初期構成でどのくらいのトラフィックをさばくことができるのかを知り、想定以上の状況では何がボトルネックになるかを推測し、どのような対処方法があるか、といったことを計画しておくことができます。キャパオーバーしてしまう可能性をゼロにすることはできませんので、現実的には問題が生じた際、もしくは問題が生じると検知したその時に、いかに素早く的確な対処ができるかが重要になるということです。
今回、一般的な単語と思われる『
そういうベンチマークをするために必要な考え方ってやつを整理していきます。AWS事情を交えていきますが、どのような環境でも参考になるように基本を抑えていく感じにしていければと思います。
環境の準備
インスタンスの用意
パブリッククラウドのインスタンスを借りて検証をします。私の場合はたいていAWSです。AWSは普通はありえないようなハイスペックや太いネットワークを利用できるので、ゴリゴリ気兼ねなくベンチマークを採るには最高の環境です。インフラエンジニアは貧乏性なので、当然すべてスポットインスタンスで起動します。価格の荒れは相変わらずですが、数値の採取と考察の時間をハッキリ分けてメリハリをつけてやれば、スポットであるデメリットはほとんどありません。
各種リソースについては後でいっぱい書くので置いといて、起動時点でまず絶対に守っておきたいインスタンス事項を書いておきます。
インスタンスタイプの選択
t2系は絶対に使いません。CPUクレジット に影響される数値には信憑性がないからです。できれば c4, m4, r4 を使います。そもそも強くて本番で実際に使うだろうタイプということもありますが、EBSやネットワークにおいて最適な環境をデフォルトで利用できるようになっているからです。
スペックは large ～ 16xlarge までありますが、最初は large で十分です。なぜなら、ボトルネックに簡単に突き当たることができるからです。いきなり大スペックに大トラフィックを流し込むよりも、小さいサイズからコツコツと試していくほうが、試験者がより理解しやすく、数値にも信憑性が出てくると思います。モノにもよりますが、最終的に 4xlarge あたりまで試験できれば、数値の傾向と現実的な運用レベルという意味で十分な内容になるでしょう。
Subnet(AvailabilityZone)の選択
全てのインスタンスのSubnetは、必ず同一の場所を選択します。同一AZとAZ間ではネットワークのレイテンシが結構違い、ボトルネックを割り出すという目的ではレイテンシはただの不純物となるため、最速の環境を選択します。AZを分ける構成については、最速の数値での考察が落ち着いた後に追試験したらよいです。どちらも重要な結果であり、その差異は本番運用における消費リソースの偏りに理解を得ることができます。
拡張ネットワーキング
拡張ネットワーキングは有効にするだけで通信速度が速くなるので、必ず有効にしてから検証します（参考：EC2拡張ネットワーキングの性能と設定手順 | 外道父の匠）。Amazon Linux AMI はデフォで有効なので楽です。クライアントの用意
よほどマイナーなミドルウェアやプロトコルでなければ、ベンチマークツールは付属しているか、有志が作成・公開しているので、とりあえず探して使いやすいか・ボトルネックを割り出せるかを試してみるとよいです。まともなツールならば、データを蓄積するタイプのシステムならランダムなテストデータを任意の容量で作成でき、それに対して任意のマルチスレッド数でランダムアクセスできます。気に食わなければ、自分の得意な軽量プログラミング言語で書くとよいです。クライアントで気をつけたいこともいくつかあります。
ボトルネックにならないこと
1台のクライアントでブン回していると、サーバーのボトルネックが割れる前に、クライアントのCPUやネットワークがボトルネックになってしまうことが多々あります。これに気づかずデータ採取していると、明確なサーバーボトルネック項目が判明せず、なんとなくそれがこのシステムとしての限界スループットなんだな、という曖昧なゴミ結果になってしまいます。ベンチマーク中はクライアント・リソースの監視も必ず行い、CPUやネットワークが詰まってないか確認すること。そしてクライアントが足りなければ、複数台で同時に実行するように切り替えていきます。たいていのサーバーは、クライアント c4.4xlarge あたりを4～8台でぶん回せば、何かしら悲鳴を上げてくれますし、それですら手応えなければ何かリクエスト内容や設定が不十分であると思われます。
サーバーでクラスタ組んで、スケールアウトさせてそのオーバーヘッド度合いを確かめる時とかは、むしろクライアント1台固定で限界まで回し、分散具合を確かめる、といった場面もあります。
意味のないリクエストをしないこと
ログの転送とか、Pub/Sub系のような、データを横流しするタイプのシステムの場合は、それほどリクエスト内容のランダム性は重要にならないのですが、インデックスを含むデータベースのようなシステムの場合は、リクエスト内容に気を配らなくてはいけません。ここではわかりやすくMySQLのSQLで例をあげると、SELECT 1 のようなクエリをいくら何万QPS捌けたからって意味ないのは、さすがに誰でもわかります。SELECT text FROM table WHERE id = 1 というクエリだけでは QueryCache という仕組みを知っていればストレージ負荷には効果ないのがわかりますし、WHERE句の id 値を散らしたとしても、データがメモリに載りきっているのかハミ出てるのかの条件を理解していなければ、それもまた意味なし芳一です。UPDATE文も、ブロックサイズや定期的なディスクへの結果反映の仕組みを知らなければ、効果的にディスクへ負荷をかけられているか怪しいでしょう。
どんなミドルウェアも、できるだけ文献を読み込んでから始めないと、そういった目に遭うことがあり、不足に気づいてベンチマークを最初からやり直しということも、わりとよくあることです。先にある程度の知識をつけることは最も重要なのですが、それと同じくらい実際にベンチマークを動かしてみて挙動の感触を掴むことも重要で、進め方のバランスが難しいところです。最初から全てを知っているなら、ベンチマークなんて採ってないですしね。
じゃあどうするかというと、前にも書いたとおり、サーバーの何かしらの項目がボトルネックに到達することを目的としてクライアントを調整します。または、ある特定の項目をボトルネックに到達させるにはどういうリクエストにしたらよいかを考えます。下記に色々項目をあげますが、特にDisk IOPSを的確にボトルネックにすることが鍵となることが多いので、リクエストの有効性には十分注意していきましょう。
できる限りの計測値を出力すること
ベンチマークの実行が終わった後、よくできたツールはいくつかの情報を出力してくれます。1秒あたりのリクエスト数（req/sec）、1秒あたりの転送量（MB/s, Mbps）、1リクエストあたりのレイテンシ（max/min/avg/99.5th など）、といった情報です。クライアントでしか知り得ない（またはクライアントで出したほうが手っ取り早い）ものもあれば、サーバー側でも把握できるものもありますが、どちらにせよ集計できる情報は可能な限り出してくれるツールが良いですし、自作ならその辺に気を配ってプログラムすると実施時に凄く楽になれます。
また、ネットワーク転送量のようなクライアントとサーバーのどちらでも計測できるものは、どちらも観測して大きな差異がないことを確認することも、ベンチマーク手法に過ちがないことを確かめる有効な手立てになります。
サーバーの用意
1台1機能
最近のミドルウェアは、冗長化や負荷分散の機能を網羅しているものが多く、クラスタを組めたり、コンポーネントに分かれているものがあります。ですが、ベンチマークの初手としては、最小限の機能を1台ずつ動かして、その特定の機能1つ1つのボトルネックを割り出すことに専念すべきです。例えば、メインデーモン以外に zookeeper が必要な場合は、どれだけ zookeeper が軽量だとわかっていても、2台構成で別々に起動して計測します。そもそも本番も分けるでしょって意味もありますが、不純物が混在した計測結果は信頼性が低くなるからです。
1台1機能での限界を知った上で、台数を倍々に増やしていくことで、クラスタとしての分散度合い、またはオーバーヘッド度合いを丁寧に割り出すことができます。
デーモン管理
本番でも同じことなのですが、私の場合は複数のデーモンが稼働するシステムの場合、まず全てのデーモンのパッケージを作成し、それを全てインストールしたイメージを１つ作成してしまいます。そして、EC2のタグと systemd の ExecStartPre あたりを利用して、特定のタグ値がある場合に設定ファイル自動編集＆デーモン起動 が行われるように組み込みます。そうすることで、起動してから検証を始めるまで早くなったり、クラスタ構成にしたい時にデーモンを restart するだけ、というように手間を省くことができます。これは本番を見据えたものでもありますが、ミドルウェアに慣れるまでは失敗や疑問が多くてやり直しやスペック変更を何度もすることになるので、なんだかんだで先に楽な仕組みにした方がコスパがいいためです。
ボトルネックになりうる項目
ここまで長々と書いておいてなんですが、非常に基本的な項目しかありません。逆に言えば、ここを抑えていけば大体OKということでもあります。ただそれだとつまらないので、AWSでの上限値などで味付けしておきます。CPU Utilization
最も気にすべきCPU使用率ですが、まず観測する際は vmstat のようなCPU全体で100% の値ではなく、top のような vCPUs×100% の値をみて記録していきます。100%換算だとスペックを倍にした時に、半分の%値に減ることになりますが、それだとわかりづらいので実際に使った数値 200%, 400%, 800% などを記録します。※top そのままだと値が残らないので、-b を付けて grep と組み合わせるなりして標準出力に残すと記録しやすいです。
これはわかりやすさ以外に、そもそもそのミドルウェアがシングルスレッドしか使えないのか、マルチスレッドで動けるのかという重要な点もあります。シングルの場合、vCPUs=8 で 800% あったとしても 100% までしか使えないので、100%換算だと12.5% となりボトルネックになっているのかどうかパッと見で判断できません。
初見のベンチマークでは、とりあえず top コマンドを実行した後に 1 を押して、全スレッドの状況を眺めてみるとよいです。1スレッドで動いているのか、全スレッドでまんべんなく動いているのか、特定の1スレッドだけメイン処理で重くなっているのか、といったことがわかります。
基本的には、シングルモノは 100% を、マルチモノは vCPus×100% をボトルネックとして判断します。稀に特定の1スレッドが重くて詰まる性質のモノもあります。iowait% が2～3%以上になると、ディスクや（障害に近いけど）メモリとのデータ往復レイテンシが弊害になっているので、CPUがボトルネックとは断言できなくなります。
他に、ContextSwitch と Interrupt という項目もあって、回数が多すぎるとそれがボトルネックになることもあるのですが、可能性としてはかなり低い事象なので基本からはギリ外してよい、と思うので気になる人は調べておきましょうという塩梅です。
Memory
メモリ不足になると、新規処理ができなくなったり、ストレージへのアクセスが急増したりするのですが、感覚的にはボトルネックというよりは障害といった方がよいと思います。待機してもらえば遅くともレスポンスできる可能性があるキャパオーバーと違って、そもそも機能自体しないということが多いからです。最近はSWAPしない設定にしたり、そもそもSWAPがなかったり、OOM Killerすらさせない設定にしたりと色々ですが、メモリの使用量は十分に余裕を持った状態になるよう、接続数や使用量を設定で制限する、というのを前提とするべきです。それを的確にやるためにも、ベンチマーク中は ps コマンドの RSS列 などでデーモンプロセスでの実際の使用量を把握しておき、サーバーの流量とメモリ量が安心安全になるような設定とスペックに設計します。
Network Bandwidth
ネットワークI/O のボトルネックは、比較的CPU処理やストレージ保存が少ない、FORWARD的機能のミドルウェアで起こり得る事象です。昔の環境では 100Mbps とか 1Gbps だった上限ですが、AWSでは最大25Gbpsともの凄い太線を利用できるようになっています。が、一部の表記は「最大10Gbps」とか曖昧なので、実際に iperf で計測するとどんな感じかというと| InstanceType | Bandwidth |
| r4.large | 0.74 Gbps |
| r4.xlarge | 1.24 Gbps |
| r4.2xlarge | 2.47 Gbps |
| r4.4xlarge | 5.00 Gbps |
| r4.8xlarge | 3.34 Gbps |
| r4.16xlarge | 6.10 Gbps |
| c4.4xlarge | 5.14 Gbps |
r4 はネットワーク I/O クレジットの概念があるせいか、パッと計測しただけだとまばらな数値ですが、だいたいタイプが上がるほど太くなっていきます。あと当然ですが、異なる上限値間で計測すると、スペックが低い方の数値が上限となります。
サーバー側で簡単に観測するには、iftop が便利です。クライアント別の転送量と合計値を、グラフと数値で綺麗に表示してくれます。
比較的、他の項目よりも注意を怠りがちな項目ですが、明確に上限が存在するので監視は必須です。ただ、上限値が固定のCPUなどと違って、環境条件によって上限が変化する場合があるので、面倒くさい部分ではありますが、単純に Network I/O bps の二本線のグラフを作成するだけではなく、インスタンスタイプに合わせたベースラインとなるBandwidth値も同時に監視システムに送信し、アラートを作成すると頼もしくなります。
Disk Bandwidth
ディスクのボトルネックは、IOPSやレイテンシに目がいきがちですが、EBSを使うと明確にスループット上限が設定されているので注意が必要です。General Purpose SSD (gp2) は 1GiBあたり3IOPS ＆ 1IOPSあたり256KiB という条件の元、容量が170GiB(=510IOPS)以下なら 最大128MiB/秒、170GiB以上は最大160MiB/秒 となっています。容量100GiBで作成したならば、
(容量100GiB) * (3IOPS) * (256KiB/IOPS) / 1024 = 75MiB/s
となります。1000GiB で作成した場合、
(容量1000GiB) * (3IOPS) * (256KiB/IOPS) / 1024 = 750MiB/s => 最大160MiB/s
という感じで期待よりだいぶ低めな数値になります。
Provisioned IOPS SSD (io1) はIOPSは指定した値そのものが上限で、スループット制限はgp2同様 1IOPSあたり256KiB となっており、最大は1280IOPS以上で 320MiB/s となっています。
どちらも十分に高い上限値ではあるのですが、ひたすらネットワーク転送と追記書き込みをするだけのシステムなどは、案外引っかかりやすい上限値である、ともいえます。普通は gp2 を利用しますが、この上限を上げたいがために高価な PIOPS を利用するということもなくもない、かもしれません。gp2では 213GiB = 639IOPS で最大の 160MiB/s なので、PIOPSで640IOPS以上を指定した時にgp2よりスループットで優位になるため、明らかにスループットを重要視した場合はその辺を境に検討するとよいかもですね。
また、EBS最適化インスタンス というオプションがあります。c4, m4, r4 はデフォルトで有効なのでON/OFFは考えなくていいのですが、リンク先の表を見てわかるとおり、インスタンスタイプごとにも異なる上限が設定されています。
EBS単体の上限 もしくは インスタンスにおける上限 の低い方がボトルネックになるので、非常にわかりづらい条件となっています。これも面倒ではありますが、EBSの監視としては、I/O Bandwidth 以外に EBSタイプ・容量によるBandwidth上限、インスタンスタイプ別のBandwidth上限 をメトリックスとして送っておくと、より精密な検知をできることになります。
Disk IOPS
IOPSボトルネックはHDD時代に散々困ったアレですが、最近はSSD系が一般化したことで、それほど頭を抱えることはなくなりました。が、これがボトルネックになると、iowait% が2%～30% くらいになってCPU処理が進まず遅延に遅延を重ね、ほぼシステムが死に体になるので、今でも超注意事項であることに変わりはありません。AWSでは、さきほどと同じココに全て書いてあるので目を通すの必須ですが、
要約すると、gp2 は最小100 ～ 最大10000 IOPS で、ベースラインは GiB * 3 となっています。500GiB にしたら 1500IOPS ということです。それとこれに加えてI/Oクレジットによる3000IOPSまでのバースト機能がありますが、ボトルネックという観点ではバーストに頼ってたら死ぬだけなので、ベースラインだけを頼りに生きていきます。
PIOPSは指定した値そのものが上限です。
物理HDDだとSATAで100IOPS、SASで200IOPS、あとはRAIDのストライピングでどれだけ倍々にするか、という背伸びに比べれば随分ヌルい時代になりました、ありがとうございます:-)
監視の際は、やはり実際のread/write IOPS値を記録するだけではなく、EBS毎の可変IOPS上限値を送信することで、事前の検知を強固にするのが無難でしょう。
ちなみにベンチマーク時に、IOPSをボトルネックとして到達させるには少々コツが必要な場合があります。わかりやすい例をあげると、下記は EBS(gp2) 1000GB = 3000IOPS に対して fio で計測したIOPS値なのですが、
| Type | Disk Size | Disk IOPS | FileSize | Num of Jobs | IOPS計測値 |
| gp2 | 1000GiB | 3000 | 1GB | 1 | 1236 |
| 2 | 2249 | ||||
| 3 | 3015 | ||||
| 4 | 3124 |
見ての通り、1スレッドでは全く上限値に達せていなく、3スレッド3ファイルに対してでようやく、となっています。これはつまり、実際のベンチマークにおいても、クライアントが1スレッドや1台、書き込み先が1ファイル、ではIOPS上限に到達できない可能性が高いということです。計測値として結構なスループットが出せてるのにボトルネックを割り出せない場合、書き込み先のファイルやパーティションといったものが同時複数になるように調整してみるとよいです。
Disk Latency
データの保存は通常、いったんメモリに載って、それからディスクにフラッシュされます。ここでいうディスクのレイテンシとは、いざディスクに保存する際のインプットから完了までの待機時間のことになります。CPUやメモリでのデータ通信速度は ns(nano second) の世界なのでほとんど影響を体感できないですが、SSDやフラッシュメモリといったストレージで μs(micro second)から数ms(milli second)、HDDが数msから十数ms となり、人間からするとどれも速いじゃんって感じかもしれませんが、コンピュータが何度も高速に繰り返すとなると、その累積の差はかなりのものとなります。
人間はシステムを扱う時、3秒待たされると遅いと感じます。例えば、1回のHTTPリクエストにおいて、100回のストレージアクセスがあるとして、1回あたり100μsなら合計10msで済みますが、1往復が10msの場合は合計1秒になってしまい、人間が体感できてしまう遅さになります。そのため、HDD主流の時代は速度の改善に悩まされてきましたが、昨今の環境はほとんどSSD主体なので、より体感に影響しづらくなってきています。
AWSのEBS(gp2)の場合、１桁ミリ秒のレイテンシであると記載されており、そこそこの品質であることがわかります。
ただ、ディスクのレイテンシはボトルネックに十分なりうる項目ではあるのですが、ボトルネック以前に慢性的な処理遅延の原因である、といった捉え方をしておいた方がよいです。待機時間が長いせいで待ち行列的に処理が詰まりボトルネックになる── というのはもちろん最悪ですが、普段から常にユーザーへのレスポンスがあまり速くない、というのも次いで悪い事象だからです。
もし、他に上限的なボトルネックがないのに、iowait% が5%以上などと高い場合は、ディスクのレイテンシが原因である可能性が高いです。その場合、そもそもレイテンシが低いストレージに変更するだけで、iowait% が1%未満になったりするので、根本的な構成・予算の見直しをすることが賢明かもしれません。
Disk Size
太古の昔から存在する原因、ディスク容量ですが、いっぱいになるとほぼほぼ障害になるので推算・監視することは必須です。最近のクラウドサービスには、データ容量の制限がなかったり、現実的にはほぼ無制限に等しい容量まで拡張できたり、自動拡張されたり、とこの問題を根底から解消してくれるものも多く出ていますが、まだまだ注意すべき環境が多いのが現状です。ベンチマークにおいては、送信するデータはわりと適当な内容ではありますが、平均データサイズがこれでリクエスト数がこれならこのくらいの蓄積容量になる、といった程度の算出はしておけます。それさえあれば、本番で予定する平均サイズと一日のリクエスト数がわかれば、日々蓄積する容量を推測することができます。事前の推測と実際の本番は似たつもりが全く非なるものであるものの、ボトルネックとならない程度の容量確保、データのローテーションや間引き、拡張の手立てを計画しておくことは十分に可能です。
蓄積データがあるシステムの場合、ベンチマーク時には平均リクエストサイズとスループットに対する蓄積容量を記録し、備えておきましょう。
Max Throughput
たまにミドルウェアのアピール説明で、秒間何万リクエストをサバくことができます！という表現がありますが、アレはたいてい環境条件を明記していないことが多いので私は信用しません。が、最大でどれくらいのリクエストをサバけて、どれくらい高速に処理できるのか、という計測値を知っておくことに損はないとも思っています。例えば、送信データを 1byte にしたり、SQLを SELECT 1 にした場合、当然その計測値は爆速になることでしょう。そしてその時、ボトルネック・リソースを検出できる場合もあれば、単に色んなレイテンシが合わさってそれが最速である、といった結果になることもあります。
本番では平均 1KB だったり複雑なSQLだったりで意味ないといえばないのですが、その上回ることのない最速条件を知っておけば、改善を施す際にそれに近づくほどに改善効果が薄れていくという指標になったりします。が、ぶっちゃけ、検証を楽しむための趣味コンテンツに近いです。
でも、データ転送メインのシステムなどは、1byte から倍々に試していくと、必ずスループットがガタ落ちするタイミングがあって、全体のレイテンシに対するサイズ影響度合いが垣間見えると、ミドルウェアが自分に浸透していく感触をうんたらかんたら。
データ採取と考察
準備して取得項目も整理したところで、実際に検証を実施して、結果から考察します。とりあえずベンチマークツールを実行して、結果が正しく表示され、サーバーの挙動もいったん問題ないであろうことを確認したら、検証準備としてエクセル方眼紙でもなんでもいいので結果を記録していくファイルを用意します。結果は自分が見やすければなんでもいいのですが、項目は大きく分けてこんな感じで列を作っていきます。
条件値を色々変更して、計測値を記録していきます。最初はインスタンスタイプを小さい large から始めて、ボトルネックを見極めてみます。もし見つからなければ、Clientの並列数や台数を増やしてみるとよいです。
計測時間は何分もやる必要はなく、1回あたり数十秒で十分です。実行直後の数秒だけ負荷が高いシステムもありますが、基本的にはそれを除いて落ち着いた部分の平均値を記録します。もし計測中に、毎秒や数秒毎に計測値が大きくブレるようであれば、何かがボトルネックになって待ち時間が発生している可能性が高いという目安になります。
いくつか条件を変えて記録し続けていると、倍に増やしたから倍のリクエストを捌けたとか、倍に増やしたからちょうど半分のスループットになったという想定通りの気持ち良い数値の並びと、徐々に数値の伸び縮みの加速度が小さくなっていき、ほぼ一定の数値に収束しようとしている項目を観測することができます。
収束値を発見したら、いったんベンチマークをやめて考察に入ります。なぜその項目がボトルネックになっているのか、本当にボトルネックになっているのか、何の上限値によって制限されているのか、といったことに考えを張り巡らせます。
もしかしたらAWSリソースの上限値かもしれませんし、Linux OS の上限値かもしれませんし、ミドルウェアの設定値によるものかもしれません。とにかくボトルネックを発見したことはメデタイことなので、その原因を取り除く もしくは 上限値を拡大して解決することに注力してみます。
ある条件を倍に増やして同スループットを流し込んでみて、その停滞値が伸び始めればその条件が原因ですし、変わらなければまた違う条件を考えます。条件を複数一気に変えてしまうとフワフワと地に足が着かない検証になってしまうので、あせらず１つ１つ丁寧に変更して検証するのが重要です。
それを繰り返し、最終的にはサーバーのタイプが large から 4xlarge あたりまでの単体結果と、必要があればクラスタ台数が1台から2, 4, 8台くらいまでの結果があれば、ボトルネックと分散効率について、十分な傾向を観測することができるはずです。
それを得られれば、あとは本番運用における予定値を推測し、1台あたり、1クラスタあたり捌けるスループットを算出して、いったん性能検証の概算としては完了です。
それで採用ということになれば、よりベストパフォーマンスを目指すために、サーバーのスペック構成を考え直したり、同様のベンチマークを今度はもっと細かいOSやサーバー設定値を変更しながら計測とチューニングマラソンを繰り返すことになります。
まとめる情報
とまぁこんな感じでベンチマークのデータを採取し、最終的には社内の情報共有ツールにまとめ直します。まとめる情報はベンチマーク結果だけではなく、私の場合はだいたいこんな情報をページで分けています。まとめ終わったあと、公に出してもいいかなと思ったり、気が向いたら、ブログに大体そのまま移してきて駄文を加えて公開する感じです。
ぶっちゃけ、私の在籍するWeb界隈ってやつは、良い意味でも悪い意味でも大雑把なので、計測の方法とか計測値のまとめ方とかも大雑把だと思っています。もっと精密な検証とかしてる人もいるんだろうなと思いつつも、求められる結果が、不測のスループットに対して多少盛ってでもガツンと対処できる方法とパワーなので、あんま言いたくはないけど１割２割は誤差の範囲なんですよね……２倍３倍が実戦の変動範囲なので。
それでも理屈や筋道が通らない結果だけは残さないようにと心がけています。
インフラ業をやってると、他社サービスでのリリース開幕ダウンとかの炎上をウォッチしたりするんですが、正直なところ、そういうところで勝負が決まっていくのってサービスそのものの品質競争としては不健全だよなぁとしみじみ思う一方で、一瞬にして他人事じゃねぇと褌を締めなおすわけなんですが、ちゃんと性能検証と監視と拡張手法の確立までしてたら、よっぽどじゃなければ大丈夫なんで、皆さんホントに頑張りましょうねといった感じに良い子ぶってフィニッシュです:-)
