プログラミングマガジン

プログラミングを中心にIT技術をできるだけわかりやすくまとめます。

  • ホーム
  • 設計
  • 【データベース設計】ハードウェアのサイジング(容量と性能)を決める。(物理設計)
 
 
  • Ruby
    • Ruby
    • Rails
  • DB
    • Oracle
    • DB設計
    • SQL
  •  
  • インフラ  
    • Linux
    • Git
  • Web
       
    • Web開発
    • JavaScript
  •  
  • 実装  
       
    • 設計
  • 問い合わせ
  

【データベース設計】ハードウェアのサイジング(容量と性能)を決める。(物理設計)

04.29

  • miyabisan2
  • コメントを書く

この記事は2分で読めます

「テーブル定義」の物理設計が終えたら、今度は二つの観点で、ハードウェアのサイジング(「容量」と「性能」)を決めていきます。

本タスクは、見積もるのが非常に難易度が高く、短納期の開発では、非機能要件になるので甘く見られがちな部分ですが、下手したらシステムが停止して巨額の損失を生み出してしまう可能性すらあるほど重要なタスクです。

容量について

該当システムで処理されうるデータサイズを見積もって、「十分な容量のストレージ(記憶装置)を決める」ことです。

「容量」を決めるに当たり必要な情報

システムで利用するデータ量

単純に、データベースに格納するレコードの件数の見積もりだけでなく、テキスト、画像、HTML等のファイル数の見積もりをする必要があります。

データ増加量

サービス開始時から、どれくらいの容量が増えるかを予測する必要があります。

中には、「直近1年のデータしか保管しない」というシステムであれば、それほど増えないかもしれませんが、基本的にはどんどん増えていくシステムがほとんどでしょう。

完全に新規開発で、予測が付かない場合は、下記のようにしておくとよいでしょう。

  1. ある程度余裕を持たせたストレージ容量にしておく。
  2. 簡単に、ストレージの容量を追加できるような構成にしておく。

性能について

具体的には、アプリが十二分に動作する「サーバーの性能を決める」ことです。

  • サーバーのCPU
  • サーバーのメモリ
  • ストレージのI/O

特に重要なのが、「ストレージのI/O」になります。実務での性能問題のほとんどが、ストレージのI/Oがボトルネックになっていることが多いです。

「性能」を決めるに当たり必要な情報

性能要件を具体的に決める。

処理時間

例:「~処理が何秒以内に完了すること。」というように決める。

スループット

単位時間あたり、どれくらいの処理ができるか決める。(「TPS」という指標を使うのが一般的)

リソース使用時の数値を得る。

処理が行われた時に、実際にどのくらいハードウェアリソースを消費するのか具体的な数値を見ておく。

現在稼動中のシステムであれば、予測しやすいですが、新規システムの場合はなかなか難しいです。

解決策としては下記でが、正直難しい所でしょう。

類似システムの数値を確認する。

類似システムと、構成が違ったら見当はずれな結果になる場合があります。

開発初期段階で、プロトタイプを作成し、性能試験を実施する。

ただ、短納期のプロジェクトが多く、実際にそこまでする余裕がないことがほとんどです。

最後に

冒頭でも語りましたが、非常に難易度の高いタスクになります。見積もってもわからないものは、わからないので、かなり余裕を持たせた容量や性能にするということを意識すると良いでしょう。過剰な性能の分には、「もっと安く済ませれたのでは…」と文句を言われる程度で済みますが、不足している場合は、障害が多発して下手したら多額の損害につながりかねないためです。

また、最近であれば、そうした問題を解決するために「クラウドサービス」の導入も十二分に検討の余地に入るでしょう。物理的にハードウェアを購入するよりも、かなり柔軟性が高い開発が可能になります。

【インフラ】クラウドサービスについて

 

  • 2018 04.29
  • miyabisan2
  • コメントを書く
  • データベース, 設計
  • Tweets Twitter
  • このエントリーをはてなブックマークに追加
  • LINEで送る

関連記事

  1. 2018 05.19

    【設計】クラス設計(オブジェクト指向設計)の基本(保守性、再利用性の高いソースコードを書くには?)

  2. 2018 04.25

    【データベース設計】基本的な流れ

  3. 2018 04.29

    【データベース設計】ストレージの冗長構成(RAID)の決定(物理設計)

  4. 2018 04.28

    【データベース】ER図の基礎知識(見方等)

  5. 2018 04.22

    【Webアプリ】設計の基本(Java)

  6. 2018 04.22

    【Java】JDBCをWebアプリで使う場合で考慮すること

  • コメント ( 0 )
  • トラックバック ( 0 )
  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

返信をキャンセルする。

【システム開発】開発モデルの歴史

【インフラ】クラウドサービスについて

RETURN TOP

アーカイブ

  • 2019年12月
  • 2019年11月
  • 2019年6月
  • 2019年5月
  • 2019年3月
  • 2019年1月
  • 2018年12月
  • 2018年7月
  • 2018年6月
  • 2018年5月
  • 2018年4月
  • 2018年3月

カテゴリー

  • .NET Framework
  • Ajax
  • Android
  • Auth0
  • AWS
  • Bitbucket
  • BootStrap
  • C#
  • C++
  • CGI
  • CSS
  • C言語
  • Django
  • Docker
  • Eclipse
  • Git
  • HTML5
  • Java
  • JavaScript
  • Javaサーブレット
  • jQuery
  • JSP
  • JSTL
  • JUnit
  • linux
  • Mac
  • Maven
  • Node.js
  • Nuxt.js
  • Oracle
  • PL/SQL
  • PostgreSQL
  • PowerShell
  • PWA
  • Python
  • Rspec
  • Ruby
  • Ruby on Rails
  • Salesforce
  • Slack
  • Spring Boot
  • Spring Framework
  • Spring MVC
  • SQL
  • Struts
  • Struts2
  • Sublime Text
  • Tomcat
  • UML
  • Unity
  • VB.NET
  • Visual Basic
  • VSCode
  • Vue.js
  • Webサービス開発
  • XML
  • インフラ
  • オブジェクト指向
  • ゲームプランニング
  • ゲーム開発
  • システム開発
  • スマホアプリ開発
  • セキュリティ
  • その他
  • データベース
  • デザインパターン
  • テスト
  • バージョン管理システム
  • プログラミング全般
  • マルチメディア
  • リファクタリング
  • 人間関係
  • 体調管理
  • 副業
  • 国際化
  • 文字コード
  • 日常生活
  • 未分類
  • 要件定義
  • 設計
RETURN TOP

Copyright ©  プログラミングマガジン | Wordpress Thema | @