配置設計の手順と注意点

日本IBM
ICP-エクゼクティブＩ/Ｔアーキテクト
河野紀昭

2006/2/3

　アプリケーションの設計は良いはずなのに、うまく動かないシステムに出合ったことはないだろうか。システムは業務上の機能要件を満たすとともに、可用性、パフォーマンスといった非機能要件を満足させる必要がある。非機能要件を実現するうえで大きな役割を果たすのが配置設計だ。

　配置設計では、「機能的なアーキテクチャの設計」で導出されたコンポーネント を、ノード上に配置していく。前回、設計した機能的なアーキテクチャを、もし図1のように配置したらどうなるだろうか。

図1 ある設計

　この設計では、次のような点に問題が生じてしまう。

• DBサーバへの接続数が多くなり過ぎる（クライアントPCごとに直接DBサーバに接続するため、サーバの必要資源、特にメモリ、が大きくなり過ぎる）
  
  
• セキュリティ（SQLとデータがネットワーク上を流れるため、データの漏えいや不正アクセスなどのセキュリティ上の問題が生じる）
  
  
• アプリケーションの保守が困難（クライアントにアプリケーション・プログラムが置かれるため、特別なプログラム配布の仕組みを設けないと保守が難しい）

　これらの問題を回避するためには、図2のような設計がよい。

図2 いくつかの問題点を回避した

　ここでは、Webサーバで一元的にクライアントからの接続を受け、WebサーバとDBサーバ間の接続をプールすることにより、DBサーバの負荷を低減させている。また、クライアントPCには、アプリケーション・プログラムを置かないことにし、保守性を向上させている。

勘所！ 適切な配置設計により非機能要件を実現せよ

　 ITアーキテクトとして配置設計を適切に行うためには、順を追って論理的に配置を行った方がよい。これをトレーサビリティのある設計をするという。私は、次のような手順で配置設計を行っている。

1. 非機能要件の確認
   
   アーキテクチャ設計の最初のステップとしてアーキテクチャ要件の洗い出しが行われているが、この中から配置設計により実現すべき非機能要件を再確認する
   
   
2. リファレンス・アーキテクチャの参照
   
   要件を実現できるリファレンス・アーキテクチャを探して参照する。例えば、24時間365日稼働のシステムであれば、同様の要件のシステムがどのようなシステム構成でこれを達成しているかを調査するとよい
   
   
3. 論理的なノードの配置
   
   リファレンス・アーキテクチャを参考に、Webサーバ、DBサーバなどの論理的ノードを配置する。バックアップ・ノードを設けることやクラスタ化により障害対策を行っておく
   
   
4. 業務コンポーネントのグループ化とノードへの配置
   
   同じノードで実行するとよい業務コンポーネントをグループ化して、ノードに配置する
   
   
5. システム・コンポーネントの配置とシステム管理機能の追加
   
   業務コンポーネントを稼働させるために必要な、DBMSなどシステム・コンポーネントをノードに追加配置する。さらに、パフォーマンス・モニタなどの管理機能を必要に応じて配置する

勘所！ 要件が適合するリファレンス・アーキテクチャから先人の知恵を学べ

　ここまで進めたところで、非機能要件が十分に満たされているか改めて配置を吟味しよう。高い処理性能が要求されるシステムでは、1カ所に負荷が集中しボトルネックとなる部分がないか吟味することが重要である。ボトルネックになる部分がなければ、必要に応じてマシン台数を増やしシステムの処理能力を向上させることができる。

勘所！ ボトルネックをなくして、スケーラビリティのあるシステムにせよ

　また、高可用性を目指すシステムの場合、1カ所の故障でシステム全体が停止する設計ではいけない。システムを構成するどの要素が故障しても、代替できるように設計しよう。

勘所！ Single Point of Failureを避けよ

　図2の設計に以上の考慮を加えた例を図3として示す。ここでは、CPUの高負荷が想定されるWebサーバのノードをクラスタ化してスケーラビリティを確保するとともに、構成要素を2重化して信頼性を向上させている。

図3 Webサーバのノードをクラスタ化し、構成要素を2重化した

　さて、ここで、違う観点からの設計を検討してみよう。通常のWebブラウザでは実現できない操作性が求められた場合、リッチクライアントを用いてユーザーの使いやすい画面を提供する方法がある。また、センターの災害対策を求められるケースもあり、これらの要素を加味すると図4のような設計が適切かもしれない。

図4 リッチクライアントと災害対策の要素を追加した

　ただし、図4の設計ではソフトウェア配布の仕組みやデータ複製の仕組みが複雑になり費用も掛かるので、一概に図3より良いとはいえない。どの設計案を採択するかは、ビジネス要求に照らし合わせ総合的に判断すべきである。

勘所！ ビジネス要求に合わせて、アーキテクチャを判断せよ

■要約■
アプリケーション設計に問題はないが、まともに動かないシステムというものがある。システムというものは、業務上の機能要件を満たすとともに、可用性、パフォーマンスといった非機能要件を満足させる必要があるのだが、この非機能要件を実現するうえで大きな役割を果たすのが配置設計なのである。

＠IT情報マネジメント メールマガジン　情報マネージャのための情報源（無料）