前回「配置設計の手順と注意点」までの、機能的なアーキテクチャ設計と配置設計によりITアーキテクチャの骨格は出来上がる。今回のステップでは、描いたITアーキテクチャに実際の製品や技術を当てはめ、性能を検討してITアーキテクチャの実現性を吟味する。ITアーキテクチャが「絵に描いたもち」にならないためには、マシンを用いて技術検証や性能測定を行うことも重要だ。
「アーキテクチャは一見完ぺきなのに、採用した製品の問題で動かない」。このような場合、製品のせいだからITアーキテクトの責任ではないといえるだろうか。ITアーキテクトは、製品や技術の選択やITアーキテクチャへの適合のさせ方についても、当然、責任を持つべきだろう。
製品や技術の問題としては、バグなどの不具合を考えがちであるが、それだけでなく、以下のような点を考慮する必要がある。
筆者は以前、ある新技術を試して、ソースコードをコンパイルして本番用にビルドするのに時間がかかりすぎるので、採用をあきらめたことがある。このケースでは、機能的には要件を満たしていたが、1つの簡単なサンプルのビルドに10分程度かかり、サンプルの数十倍の規模の実システムでは、デバッグ/修正/ビルドを繰り返すことができないと判断した。
このようなケースでは、製品の仕様を検討するだけでは、ITアーキテクチャの実現性を確認できない。筆者は新技術を用いる場合、次のような手順を踏んでいる。
1)の製品/技術のトライアルは、設計者が使ったことない製品/技術であれば、取りあえず使って試してみよう、ということである。あまりITアーキテクトらしくないのであるが、適当にダウンロードして試すとか、デモを見せてもらうというので構わない。製品/技術の動きを見て感覚をつかんでおくのが重要である。
勘所:新技術は動かしてみて感覚をつかもう |
---|
2)の製品/技術の適用では、ITアーキテクチャを構成するノードやコンポーネントに製品や技術を当てはめていく。現実の設計では、この段階の前に採用技術がおおむね決まっていることが多いだろう。このような場合には、想定していた技術がアーキテクチャ的に正しい選択であるか、机上検証する作業となる。
2)で製品や技術を当てはめてみたとき、適合性に不安が残る場合は、3)のプルーフ・オブ・コンセプト(コンセプトどおり機能するか動かして試すこと)を行う。プルーフ・オブ・コンセプトでは、1)と違って、適当に動かしてみるのではなく、確認内容を明確にしてプロトタイピングなどを実施することが重要である。
勘所:目的を明確にしてプルーフ・オブ・コンセプトを行おう |
---|
4)の性能見積もりでは、レスポンスタイム、資源所要量やスループットが要求を満たすか計算で見積もる。レスポンスタイムは、図2のように、ユーザーがシステムに要求を出してから、結果を受け取るまでの流れをアーキテクチャの図に書き込み、関連するコンポーネントの処理時間と処理待ち時間を合算して見積もればよい。
資源所要量の見積もりでは、まず、トランザクション・レートを、さまざまな処理のパターンごとに業務処理量から見積もっておく。この上で、レスポンスタイムと同様にアーキテクチャ図を用いて、特定の処理に関連するコンポーネントを洗い出し、特定の処理を行うために必要なCPUなどの資源量を見積もって、積み上げる。
レスポンスタイムと資源所要量の見積もり例を表に示す。なお、表内の数値は説明 のための例示であり、推奨値や平均等を示唆するものではない。
処理の種類 | ネットワーク ファイアウォール 負荷分散 | Web アプリケーション サーバ | 業務画面 | 業務ロジック | DB関連 | レスポンス合計CPU時間合計(1) | トランザクション率(2) | |
---|---|---|---|---|---|---|---|---|
商品検索 | レスポンス CPU時間 |
1000ms- | 30ms 10ms |
60ms 20ms |
60ms 20ms |
400ms 20ms |
1550ms 70ms |
- 15trx/秒 |
商品選択 | レスポンス CPU時間 |
1000ms - |
30ms 10ms |
30ms 10ms |
30ms 10ms |
200ms 10ms |
1290ms 40ms |
- 3trx/秒 |
注文内容確認 | レスポンス CPU時間 |
1000ms - |
30ms 10ms |
60ms 20ms |
60ms 20ms |
200ms 10ms |
1320ms 40ms |
- 1trx/秒 |
注文 | レスポンス CPU時間 |
1000ms - |
30ms 10ms |
60ms 20ms |
60ms 20ms |
200ms 10ms |
1320ms 40ms |
- 1trx/秒 |
CPU時間合計 (トランザクションごとの CPU 時間(1)にトランザクション率(2)をかけて合計したもの。この例ではCPU が最低2個は必要なことになる) | 1280ms/ 秒 | |||||||
スループットは、ボトルネックがない場合、上記の見積もりの下に、与えられた資源量に使用率の余裕を設定したうえで、最大限処理可能な処理量として見積もることができる。ボトルネックが生じる場合には、ボトルネックとなる部分の最大処理可能量がスループットとなるが、できるだけボトルネックが生じないように設計するのがIアーキテクトの腕の見せ所である。
勘所:アーキテクチャ図を用いて、性能を見積もろう |
---|
アーキテクチャ図を用いた積み上げによる性能見積もりを行うためには、各コンポーネントの処理性能を見積もる基礎データが必要である。例えば、DBアクセスを行う業務コンポーネントの性能は、1回のSQL処理を行うために必要なCPU時間、ディスク処理時間などが分かっていれば、SQL発行回数から見積もることができる。
必要な基礎データの値が不明の場合には、5)のベンチマークを行って基礎データを把握するとよい。テストケースとしては、プルーフ・オブ・コンセプトのケースを改良し、SQL発行などの所定の処理を、1回、2回、n回と行った場合のCPU時間などの測定を行い、見積もりのための原単位を求めるようにする。
一般的な性能測定は、アプリケーションがある程度出来上がらないと実施できないことが多い。アーキテクチャ設計の一環として行うベンチマークでは、アプリケーションの完成を待つわけにはいかないので、基礎データ把握に注力する方法が効果的である。
勘所:基礎データを把握して、積み上げによる見積もりを行おう |
---|
Copyright © ITmedia, Inc. All Rights Reserved.