はじめに
「誰の」とタイトルに書いたからには対象を明確にしないといけないので、ひとまず話を単純化するためにアプリケーションエンジニア、インフラエンジニアの２者にフォーカスして記載します。
※タイトルにサーバーサイジングと書きましたが、ネットワーク帯域や通信スループットなども含まれます。
誰のお仕事なの
サーバーサイジング、スペック決定などはアプリケーションエンジニアの方は普段関わる機会が少ないかもしれません。最終的にサーバー構成を決める際にはCPU、メモリ、ディスク容量、ネットワーク帯域、サーバー構成、可用性など様々な考慮をしてサイジングをするため、最終アウトプットを出すのはインフラエンジニアになることが多いでしょう。
しかし、インフラエンジニアからはどういうアプリケーションなのかわからないとサイジングできないよ、という恨み節も聞こえてくる気がします。
結論
元アプリエンジニア、現インフラエンジニアの著者の結論としてはアプリケーションエンジニア、インフラエンジニア 両方のお仕事だと思ってます。
以降、アプリケーションエンジニアにやってほしいことインフラエンジニアがやることを記載します。
フルスクラッチ サイジング
サイジングするフェーズごとに状況が変わってきます
■RFPや要件定義フェーズ、まだプログラムが全くないとき
予算計画を立てるためには正確なサイジングが求められるでしょうが、この時点でまともなサイジングができることはほぼありません。この時点のサイジング結果がぴったり正確だったら、ほぼ運だと思います。インフラエンジニアは過少になることを恐れるので必ずここでバッファを載せますが、それでもスペック不足になることはあります。だって動くプログラムないんだもん。
アプリケーションエンジニアにお願いしたいこと：
過去の類似案件があればその類似案件を共有、類似案件とのデータボリューム、トランザクション数、同時アクセス数などの差異を共有
インフラエンジニアがやること：
アプリケーションエンジニアから共有受けた類似案件のサーバー構成をベースに類似案件との差異をもとにサイジング。類似案件がなくてもそれっぽい案件をベースに何とか作る。
■設計フェーズ、開発フェーズ初期
一部のプログラムしかできていないので RFPや要件定義フェーズと条件はほぼ変わりません。しかしプロジェクトのスケジュール次第では、この時点でサーバを買わないと間に合わないことがあるので、一部のプログラムだけでサイジングをすることになります。
アプリケーションエンジニアにお願いしたいこと：
Webシステムなら最もアクセス集中するプログラムとデータ。バッチならもっとも処理が重いバッチと本番で使うのと同等のデータ。データの年間蓄積量を。これらを最初に作ったり考えてもらえるとサイジングが少し正確になります。
インフラエンジニアがやること：
アプリケーションエンジニアから共有受けたプログラムとデータをテストサーバをもとに負荷試験を実施し必要スペックを算出する。データが足りなければ、データ量が増えたことを想定して机上でサイジングする（例えばデータ量が半分なら、テスト結果の数値を倍にしてスペックを出す）。
■結合テストフェーズ、総合テストフェーズ
このフェーズになれば主要なプログラムはほとんど完成しているのでかなり精緻なサイジングができます。ただよほどスケジュールに余裕があるプロジェクトでない限り、このタイミングでサイジングした結果をもとにサーバを購入できることは少ないかもしれません。
アプリケーションエンジニアにお願いしたいこと：
多くのシステムは最初の1年は問題なくても、数年後データがたまってくるとパフォーマンス劣化するケースがあります。したがって、システムが複数年使われたことを前提としたテストデータを準備してくれるとインフラエンジニアは大変うれしいです。こういったデータを人為的に作ることが難しいこともわかっています。でもあると非常に助かります。
インフラエンジニアがやること：
アプリケーションエンジニアが準備してくれたプログラム、データをもとに負荷テストを実施してその結果をもとにサイジングを行いましょう。だいぶ正確なサイジングができると思いますが油断してはいけません。バッファは必ず乗せましょう。オンプレサーバの場合はメモリやCPUやHDDを追加で載せられるサーバを選択しましょう。
■運用フェーズ
アプリケーションエンジニアにお願いしたいこと：
データ量が膨大になるプログラムだったり、既存のプログラムよりアクセス数が多くなるWebシステムや処理が重いバッチプログラムが追加になる場合は、是非インフラエンジニアに一声かけましょう。
インフラエンジニアがやること：
アプリケーションエンジニアから共有された情報をもとにサーバーの増強が必要か計算しなおします。可能ならテスト環境で実際に負荷テストをしてから計算しなおせるといいですね。
パッケージ サイジング
パッケージの場合はフルスクラッチと違ってプログラムが既にあるので比較的容易と思われるでしょう。確かにフルスクラッチよりはましですが、汎用性が高いパッケージほどサイジングの難易度は上がってきます。Excelを思い出してもらえればわかると思いますが、1行しかデータがないExcelと1万行のデーがありマクロなどがかかれたExcelでは必要なPCスペックは変わってきます。
■パッケージ出荷時
アプリケーションエンジニアにお願いしたいこと：
そのパッケージで最もアクセス数が多くなると思われるアプリケーションと想定アクセス数、最も重いバッチ処理と想定データ量及びを共有していただき、本番想定データを準備していただきたいです。さらにユーザ様が複数年利用した想定のデータだと尚助かります。またパッケージソフトは同じプログラムを様々な規模のお客様が利用されるので、データパターンが複数あるともっと助かります。
インフラエンジニアがやること：
アプリケーションエンジニアから共有されたパッケージをもとに負荷テスト、データパターンが複数ある場合は複数回負荷テストしてデータ量の変化がサイジングに及ぼす影響を分析・検討しましょう。このパターンが多ければ多いほどサイジングが精緻になっていきます。また、パッケージを利用しているお客様が多ければ、お客様にお願いして稼働実績を共有していただき、さらにサイジングを精緻化していきましょう。そうするとどんどんサイジングが進化していきます。
■機能追加時
アプリケーションエンジニアにお願いしたいこと：
データ量が膨大になるプログラムだったり、既存のプログラムよりアクセス数が多くなるWebシステムや処理が重いバッチプログラムが追加になる場合は、是非インフラエンジニアに一声かけましょう。
インフラエンジニアがやること：
アプリケーションエンジニアから共有された情報をもとに再度負荷テストを行い分析・検討を行いサイジングの影響を検討します。場合によってはサイジングパターンの見直しも必要になるでしょう。また、新機能を利用されるお客様に対しては注意喚起や増強の必要性についてアナウンスが必要かもしれません。お客様サポートメンバーと情報共有して積極的に情報発信しましょう。
おわり
いかがでしたでしょうか。最近ではSaaSなどクラウドアプリケーションが多くサイジングを精緻にしなくてもスケールアウトで対応できることも多いかもしれませんが、ある程度サイジングしておくと無駄なインフラコストを抑えることができるかもしれません。
また、サイジング大好きだという人にはあまりお目にかかったことないですが、この記事をきっかけに少しでも幸せなサイジングライフを送っていただけると幸いです。