chiaki99のブックマーク / 2010年5月25日

chiaki99 id:chiaki99

2010年5月25日のブックマーク (4件)

キャパシティ・プランニングの進め方：業務による負荷を洗い出す
キャパシティ・プランニングの作業手順は，3つのフェーズに分かれる。(1)構築対象のシステムが実行する処理の種類や量である「ワークロード（負荷）情報」の収集と，それを基にした性能要件の決定，(2)性能要件からリソースのスペックを見積もる「サイジング」，(3)サイジング結果を評価して精度を高めていく「評価・チューニング」である。トランザクション処理とターンアラウンドタイムに関する情報を収集してシステムに必要な性能を見積もり，サーバーやストレージなどのスペックを決定する「キャパシティ・プランニング」の進め方を見ていこう。図1には，キャパシティ・プランニングの基本的な作業手順を示した。作業手順は，大まかに次の3つのフェーズに分かれる。 (1)構築対象のシステムが実行する処理の種類や量である「ワークロード（負荷）情報」の収集と，それを基にした性能要件の決定，(2)性能要件からリソースのスペックを
chiaki99 2010/05/25
し：システム

じ：上流工程
リンク
[方式設計編]性能要件はユーザーが決めると思ってはいけない
「ユーザーが要件を決めてくれないので…」「性能要件を出していただかないと機器が見積もれません，早く要件を出してください！」。要件定義フェーズのみならず，プロジェクトの様々な工程でよく耳にする言葉である。非機能要件はユーザーにヒアリングして洗い出すのが，インフラ設計における一般的な手法だ。だが，インフラ設計者はヒアリングによって得られたユーザーの「要望」を絶対的な「要件」としてとらえてはいけない。非機能要件を洗い出すに際しては，要望の裏にあるリスクやそこから派生する制約を先読みすることが重要である。その思考を停止してしまうと，後工程で様々な問題が発生する。今回は，非機能要件の中でも読者にとって最も身近だと思われる「（オンラインの）性能要件」を例に解説する。なお，現在のシステム構築では，現行システムが存在せずゼロから開発することはほとんどない。従って，ここでは現行システムで何らかの稼働統計
chiaki99 2010/05/25
し：システム

じ：上流工程
リンク
パフォーマンス要求をどう定義するか
要求定義の検討項目の主たるものは機能要求であるが，それ以外にも運用要求やセキュリティ要求，品質要求，そしてパフォーマンス要求などがある。パフォーマンス要求は記述の方法が難しい。開発を受託する側との取り決めも容易ではない。システムのパフォーマンスに影響を与える要素の種類が多すぎるののに加え，その多くが変動したり不確定であったりするからだ。そもそも，パフォーマンスという概念があいまいである。特にオンライン・レスポンスに至っては感覚的な側面もあって，当事者間で概念を共有するのが難しい。パフォーマンスに関する各社の態度を比べてみると二極化していることが分かる。第一グループ・・・・ハードウエア・ベンダー，パッケージ・ベンダー自社製品や提供するソリューションのパフォーマンスの良さを強調する態度が顕著。特に，ライバル製品に対しては決して譲らない。第二グループ・・・・SIベンダー，ソフトウエア・
chiaki99 2010/05/25
し：システム

じ：上流工程
リンク
Í×·ïÄêµÁ¡¦´ðËÜÀß·× - µ»½Ñ¾ðÊóWiki
´ðËÜÀß·× † ¥·¥¹¥Æ¥à¤Î¥ê¥×¥ì¡¼¥¹°Æ·ï¤¬ºÇ¤â´í¸±¤ÊÍýÍ³ 2008.2.24 ±¿ÍÑ¤·¤Æ¤¤¤¯¤¦¤Á¤Ë¡¢¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤äµ¡Ç½ÄÉ²Ã¤Ç¡¢¶²Îµ¤Î¤è¤¦¤ËÇÏ¼¯¤Ç¤«¤¯¤Ê¤Ã¤¿Ãæ¿È¤Ï¡¢ºÇ¿·¤Î¥ª¥Ö¥¸¥§¥¯¥È»Ø¸þ¸À¸ì¤Ç¡¢Æ±¤¸¤è¤¦¤Ë¤¿¤¯¤µ¤ó¤Î¥Ð¥°¥Õ¥£¥Ã¥¯¥¹¤ò½Å¤Í¤ÆÀÑ¤ß¾å¤²¤¿¤â¤Î¤ËÊÑ¤ï¤ë¡£ Æ±¤¸¥½¡¼¥¹¥³¡¼¥É¤ÎÃÇÊÒ¤Ï°ì¤Ä¤â¤Ê¤¤¤Ï¤º¡£ ¥×¥í¥°¥é¥à¤ÎÊÝ¼éÀ¤ä°Ü¿¢À¡¢ºÆÍøÍÑÀ¤¬¡¢¤É¤Î»þÂå¤Ë¤Ê¤Ã¤Æ¤â¡¢¸À¸ì¤¬¤¤¤¯¤éÈ¯Å¸¤·¤Æ¤âÆñ¤·¤¤¤³¤È¡£ ÆÃ¤ËºÆÍøÍÑÀ¤Ï¡¢¤½¤Î¥
chiaki99 2010/05/25
し：システム

じ：上流工程
リンク
- 2010年5月27日
- 2010年5月25日
- 2010年5月23日