第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アーキテクトとして、システムのアークテクチャ設計を担当するとともに、後進の指導にも当たっている。


「ITアーキテクチャ構築の勘所」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.