製品/技術の適用と実現性の検証ITアーキテクチャ構築の勘所(5)

前回「配置設計の手順と注意点」までの、機能的なアーキテクチャ設計と配置設計によりITアーキテクチャの骨格は出来上がる。今回のステップでは、描いたITアーキテクチャに実際の製品や技術を当てはめ、性能を検討してITアーキテクチャの実現性を吟味する。ITアーキテクチャが「絵に描いたもち」にならないためには、マシンを用いて技術検証や性能測定を行うことも重要だ。

» 2006年03月03日 12時00分 公開
[河野紀昭(日本IBM ICP-エクゼクティブI/Tアーキテクト),@IT]

 「アーキテクチャは一見完ぺきなのに、採用した製品の問題で動かない」。このような場合、製品のせいだからITアーキテクトの責任ではないといえるだろうか。ITアーキテクトは、製品や技術の選択やITアーキテクチャへの適合のさせ方についても、当然、責任を持つべきだろう。

 製品や技術の問題としては、バグなどの不具合を考えがちであるが、それだけでなく、以下のような点を考慮する必要がある。

  • 欲しい機能がITアーキテクチャ設計上の想定どおり動作するか
  • 開発が効率的に実施できるか
  • 用途に対して、レスポンスタイムやスループットが実用に耐えるか
  • 必要なセキュリティ・レベルが達成できるか

 筆者は以前、ある新技術を試して、ソースコードをコンパイルして本番用にビルドするのに時間がかかりすぎるので、採用をあきらめたことがある。このケースでは、機能的には要件を満たしていたが、1つの簡単なサンプルのビルドに10分程度かかり、サンプルの数十倍の規模の実システムでは、デバッグ/修正/ビルドを繰り返すことができないと判断した。

 このようなケースでは、製品の仕様を検討するだけでは、ITアーキテクチャの実現性を確認できない。筆者は新技術を用いる場合、次のような手順を踏んでいる。

ALT 図1 IT アーキテクチャの実現性吟味

 1)の製品/技術のトライアルは、設計者が使ったことない製品/技術であれば、取りあえず使って試してみよう、ということである。あまりITアーキテクトらしくないのであるが、適当にダウンロードして試すとか、デモを見せてもらうというので構わない。製品/技術の動きを見て感覚をつかんでおくのが重要である。

勘所:新技術は動かしてみて感覚をつかもう

 2)の製品/技術の適用では、ITアーキテクチャを構成するノードやコンポーネントに製品や技術を当てはめていく。現実の設計では、この段階の前に採用技術がおおむね決まっていることが多いだろう。このような場合には、想定していた技術がアーキテクチャ的に正しい選択であるか、机上検証する作業となる。

 2)で製品や技術を当てはめてみたとき、適合性に不安が残る場合は、3)のプルーフ・オブ・コンセプト(コンセプトどおり機能するか動かして試すこと)を行う。プルーフ・オブ・コンセプトでは、1)と違って、適当に動かしてみるのではなく、確認内容を明確にしてプロトタイピングなどを実施することが重要である。

勘所:目的を明確にしてプルーフ・オブ・コンセプトを行おう

 4)の性能見積もりでは、レスポンスタイム、資源所要量やスループットが要求を満たすか計算で見積もる。レスポンスタイムは、図2のように、ユーザーがシステムに要求を出してから、結果を受け取るまでの流れをアーキテクチャの図に書き込み、関連するコンポーネントの処理時間と処理待ち時間を合算して見積もればよい。

ALT 図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.

注目のテーマ