第2回 アーキテクチャ要件の洗い出しITアーキテクチャ構築の勘所

 ITアーキテクチャ設計の最初のステップは、アーキテクチャ要件の洗い出しである。ここで、アーキテクチャ決定に影響を及ぼす要件を的確に洗い出すことが、良いアーキテクチャ設計には欠かせない

» 2005年11月18日 12時00分 公開

 連載記事「ITアーキテクトを探して」の第1回目「ITアーキテクトが備えるべきスキル標準」では、ITアーキテクトの役割を、『ビジネスの要求』に的確に応える整合性の取れたアーキテクチャの構築、としている。ビジネスの要求に応えるというのが重要なポイントで、ここがずれていては、いかに「かっこいい」ITアーキテクチャも無意味なものとなってしまう。

 では次の2つの例では、どちらが良いアーキテクチャだろうか。

ALT 図1 3階層システムの例(A)
ALT 図2 3階層システムの例(B)

 Aのアーキテクチャは、ネットワークにクラスタリングしたUNIXサーバを接続してWeb画面の処理を行い、ここから、必要に応じてバックエンドの既存のメインフレームの業務ロジックが呼び出すというもの。これは、典型的な3階層アーキテクチャであり、通常のオンライン・バンキングなどでは、「正しい」アーキテクチャである。これに対して、BはメインフレームとUNIXサーバの配置が逆になっており、一見、「変な」アーキテクチャである。

 では、Bは間違ったアーキテクチャなのだろうか。実は、Bは次の2つの要件を同時に満たすための「正しい」アーキテクチャなのである。

  • 極めて負荷の高いシミュレーション処理を、比較的、低コストで高速に実行したい
  • 既存のメインフレームと端末、ネットワークはそのまま使用したい

 この要件に対しては、Aは逆に「間違った」アーキテクチャになる。つまり、アーキテクチャの良いも悪いも要件次第、というわけだ。

勘所:要件に適合したアーキテクチャが良いアーキテクチャである

 アーキテクチャ設計の最初のステップは、アーキテクチャ要件の洗い出しであるが、ここでは、ビジネス要求を念頭に置きながら、システムに対する次の2種類の要件を洗い出していく。

・機能要件

 データの格納、画面の表示、業務処理の実行制御や、認証、他システム通信、帳票出力など、業務を行うために、直接的に必要な機能要件

・品質要件

 可用性、信頼性、処理性能、データの保全性、セキュリティ、スケーラビリティ、拡張性、開発/保守性など、広い意味でシステムの品質に関する要件

 機能要件の洗い出しは、あくまで、ITアーキテクチャの視点で行い、細部に立ち入り過ぎないことがポイントである。さもないと、アーキテクチャを設計していたつもりが、いつの間にか業務を設計していたということになりかねない。本質を見失わないためには、アーキテクチャの特性を決定付けるような、 典型的な業務処理(ユースケース)をうまく選んで、アーキテクチャ・モデリングを 行う必要がある。


勘所:アーキテクチャ上、重要なユースケースを意識せよ 

 アーキテクチャ上、重要なユースケースは次のものであることが多い。

  • 業務の「目玉」となる重要なユースケース
  • 実装が難しそうな、「ややこしい」ユースケース
  • 処理量が多いユースケース
  • 認証などセキュリティが関係するユースケース
  • 他システムと連携した処理を含むユースケース

  これらのユースケースを分析して、システムに必要な機能が何であるか棚卸しを行い、次の機能的なアーキテクチャ設計ステップにつなげるようにする。特に、業務の目玉となるユースケースについては、これをうまく実現することが、アーキテクチャの良さに直結することが多い。

 品質要件としては、システムに対する業務上の次のような数値目標を把握しておく。

  • ピーク時のログイン・ユーザー数/処理件数/応答時間
  • サービス時間帯
  • 障害回復時間
  • 処理量の伸び率

 数値目標の把握に当たっては、欲張り過ぎた数値目標にしないことが重要である。「0.1秒のレスポンスで24時間365日稼働し、障害時には10秒以内に回復するシステム」といった目標にすると、大きな冗長性を持たせた高価なシステムになってしまうので、業務上の必要性に合わせた、現実的な目標を設定することがよい。365日無停止という目標を363日(年2回停止)に下げるだけでも、設計上の自由度はかなり増えるのである。


勘所:品質目標の設定は現実的に 

 アーキテクチャ要件の洗い出しでは、機能要件と品質要件に加え、アーキテクチャ設計上の制約事項の洗い出しを行うことも必要である。制約事項としては、次のようなものがある。

  • 採用が決定しているテクノロジ
  • 既存システムの制約
  • 予算
  • マシン設置場所/環境

 高い処理能力が必要と分かり、予算の制約もあるので、安くて小さいマシンを並べてクラスタリングしたとしよう。実際に稼働させようとしたところ、マシンの発する熱の総量が大き過ぎ、設置場所の空調能力を大きく超えてしまったとしたら、アーキテクチャ設計としては、大失敗である。


勘所:制約事項の把握も忘れずに 

 余談であるが、最近のスーパーコンピュータでは、処理能力当たりの発熱というのが重要な設計要素で、最高速のCPUチップを並べるのでなく、発熱の少ないCPUチップを並べるというハードウェア・アーキテクチャがトレンドであるらしい。


【プロフィール】

河野紀昭(こうの のりあき)

日本IBMにてITアーキテクトとしてさまざまなプロジェクトでアーキテクチャ設計を10年以上にわたって実施してきた。現在、エクゼクティブITアーキテクトとして、システムのアークテクチャ設計を担当するとともに、後進の指導にも当たっている。


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ