「テーブル定義」の物理設計が終えたら、今度は二つの観点で、ハードウェアのサイジング（「容量」と「性能」）を決めていきます。
本タスクは、見積もるのが非常に難易度が高く、短納期の開発では、非機能要件になるので甘く見られがちな部分ですが、下手したらシステムが停止して巨額の損失を生み出してしまう可能性すらあるほど重要なタスクです。
容量について
該当システムで処理されうるデータサイズを見積もって、「十分な容量のストレージ（記憶装置）を決める」ことです。
「容量」を決めるに当たり必要な情報
システムで利用するデータ量
単純に、データベースに格納するレコードの件数の見積もりだけでなく、テキスト、画像、HTML等のファイル数の見積もりをする必要があります。
データ増加量
サービス開始時から、どれくらいの容量が増えるかを予測する必要があります。
中には、「直近1年のデータしか保管しない」というシステムであれば、それほど増えないかもしれませんが、基本的にはどんどん増えていくシステムがほとんどでしょう。
完全に新規開発で、予測が付かない場合は、下記のようにしておくとよいでしょう。
- ある程度余裕を持たせたストレージ容量にしておく。
- 簡単に、ストレージの容量を追加できるような構成にしておく。
性能について
具体的には、アプリが十二分に動作する「サーバーの性能を決める」ことです。
- サーバーのCPU
- サーバーのメモリ
- ストレージのI/O
特に重要なのが、「ストレージのI/O」になります。実務での性能問題のほとんどが、ストレージのI/Oがボトルネックになっていることが多いです。
「性能」を決めるに当たり必要な情報
性能要件を具体的に決める。
処理時間
例：「～処理が何秒以内に完了すること。」というように決める。
スループット
単位時間あたり、どれくらいの処理ができるか決める。（「TPS」という指標を使うのが一般的）
リソース使用時の数値を得る。
処理が行われた時に、実際にどのくらいハードウェアリソースを消費するのか具体的な数値を見ておく。
現在稼動中のシステムであれば、予測しやすいですが、新規システムの場合はなかなか難しいです。
解決策としては下記でが、正直難しい所でしょう。
類似システムの数値を確認する。
類似システムと、構成が違ったら見当はずれな結果になる場合があります。
開発初期段階で、プロトタイプを作成し、性能試験を実施する。
ただ、短納期のプロジェクトが多く、実際にそこまでする余裕がないことがほとんどです。
最後に
冒頭でも語りましたが、非常に難易度の高いタスクになります。見積もってもわからないものは、わからないので、かなり余裕を持たせた容量や性能にするということを意識すると良いでしょう。過剰な性能の分には、「もっと安く済ませれたのでは…」と文句を言われる程度で済みますが、不足している場合は、障害が多発して下手したら多額の損害につながりかねないためです。
また、最近であれば、そうした問題を解決するために「クラウドサービス」の導入も十二分に検討の余地に入るでしょう。物理的にハードウェアを購入するよりも、かなり柔軟性が高い開発が可能になります。
この記事へのコメントはありません。