連載 アプリケーション・アーキテクチャ設計入門 第5回（最終回）　物理配置および運用上の要求 日本ユニシス　猪股 健太郎 2004/02/14
Page1 Page2 Page3 Page4

■物理配置の計画

　以上のような構成要素に対してコンポーネントの配置を考えていくわけだが、注意しなければならないのは、パフォーマンス、可用性、再利用性、セキュリティといった非機能要件についてトレードオフが発生するということだ。例えば、パフォーマンスを最優先してギリギリまで最適化された設計では柔軟性や機能性が失われたり、高度なセキュリティを実現した通信技術では暗号化と解読の負荷によりパフォーマンスが低下したり、といったことが起こる。物理配置の選択に明確な正解はないが、「コンポーネントの分散はパフォーマンスに悪影響を及ぼす」という原則は常に意識するべきだろう。

　物理配置を決定するときの、アプリケーションのアーキテクチャ責任者とインフラのアーキテクチャ責任者の作業は以下のようになる。

1. アプリケーションの機能上必要となる最小限のインフラを明確にする
   　例えば、サービス･エージェントが外部のWebサービスを呼び出すのでインターネット接続が必要であるといったことである。

2. インフラの制限や制約条件を洗い出し、上記1.の結果に適用する
   　例えば、COM+の分散トランザクションのために、ファイアウォールのポートを開く必要があるとか、Webファームが置かれているDMZからはActive Directoryへアクセスさせないといったことである。

3. アプリケーションとインフラを最適化する
   　要件や制約が整理されて矛盾が解消されたならば、アーキテクチャのまだ定義されていない部分を決定していく。例えば、ファイアウォールの不要なポートを閉じたり、SQL Serverの認証モデルを選んだりといったことである。

　物理配置を決定するときに特に考慮すべき問題となるポイントを挙げてみよう。

●セキュリティ

• セキュリティ的に重要なものの配置場所
  暗号化キーや、データアクセス・ロジック・コンポーネントなど。

• セキュリティ境界
  複数の物理階層（ティア）に分割することは、攻撃者が狙うポイントを増やすことにもつながる。

• アプリケーションの実行アカウント
  物理階層（ティア）に応じてOSの実行アカウントは異なる。ログインしたユーザーのアカウントで動作する場合もあれば、特定のサービスに専用のアカウントを用意する場合もあるだろう（例：ASP.NETが使用する「ASPNET」アカウント）。その際、認証情報をどのように受け渡すかや、アカウント偽装（Impersonate）の実現などが問題となる。

●運用管理

• 運用および監視の方法
  アプリケーション・ロジックを1個所に配置して集中管理するかどうかや、データベースをバックアップ／復元する方法など。

• コンポーネントの配置場所
  特定のソフトウェアやハードウェアに依存するために同一のハードウェアに配置しなければならないなど。

• ライセンス
  ユーザー数やCPU数に応じて追加の費用が必要となる。

• 政治的な要素
  コンポーネントの所有権が問題になる場合もある。

●性能（パフォーマンス、可用性、スケーラビリティ）

• インターフェイスの複雑さ
  分散コンポーネントの間でやり取りされる情報を最小限にすることが要請される。

• 通信経路
  分散トランザクションが利用するポートは閉じてはいけない。

• 可用性
  クリティカルな業務活動を物理的に独立させることで、ほかの物理階層（ティア）でのトラブルによる影響を受けないようにする。

• パフォーマンス
  先に述べたとおり「コンポーネントの分散はパフォーマンスに悪影響を及ぼす」が、スケーラビリティの向上にもつながる。

• ハードウェアの性能
  典型的なWebサーバには十分なメモリとCPUパワーが必要だがストレージは不要である、といったようなこと。

■コンポーネント分散境界

　AAfNの第2、第3章に従って設計しているのであれば、いくつかのコンポーネントは同じ位置に配置し、いくつかのコンポーネントは別の位置に配置するのがより効果的であることが分かるだろう。

●ユーザー・インターフェイス・コンポーネント

　ユーザー・インターフェイス・コンポーネントの場合は単純に考えてよい。Windowsベースのアプリケーションであればクライアントに、ASP.NETのWebアプリケーションであればWebサーバに配置する。そして、同じ位置にユーザー・プロセス・コンポーネントも配置する。ただし、.NETアセンブリとしては独立させて、再利用性と保守性を高める。

●ビジネス・コンポーネント

　ビジネス・コンポーネントの物理配置にはいろいろなパターンがあるが、以下の指針を推奨する。

• ユーザー・インターフェイス・コンポーネントやユーザー・プロセス・コンポーネントから同期的に呼び出されるビジネス・コンポーネントは、それらと同じ位置に配置するのがよい。特にWebアプリケーションであればなおさらである。しかし、セキュリティ上の要求がある場合や、複数のユーザー･インターフェイスでビジネス・コンポーネントを共有したい場合は、ビジネス・コンポーネントを別の物理階層（ティア）に配置することも考える。

• ビジネス・プロセスがサービスとして実装されて非同期的に呼び出される場合は、一般的に別の物理階層（ティア）を用意するべきだ。

• サービス・エージェントは、基本的に呼び出し元であるビジネス・コンポーネントやビジネス・ワークフローと同じ位置に配置する。ただし、サービス・エージェントがインターネットを通じてサービスを呼び出す場合は、インターネット・セキュリティ固有の処理をビジネス・コンポーネントから独立させることも考える。

• ビジネス・エンティティや型付きデータセットなどは、利用するコードとともに配置する。ビジネス・エンティティのリモート呼び出しはパフォーマンスを悪化させる。

　ビジネス・コンポーネントは状態を持たない設計であるので、ファーム構成やクラスタ構成における制約はない。しかも、複数の場所に配置させることもできる。

●サービス・インターフェイス

　サービス・インターフェイスはビジネス・コンポーネントやビジネス・ワークフローと同じ位置に配置してもよいし、別の場所に配置してもよい。指針はユーザー・インターフェイス・コンポーネントの配置と同じである。もし、サービス・インターフェイス・コンポーネントがインターネットのような信頼できないネットワークに接続しているのであれば、セキュリティに対する特別の考慮が必要になる。

●ビジネス・ワークフロー

　BizTalk Serverのクラスタは、ASP.NETによるUIや、そのUIが呼び出すビジネス・コンポーネントを配置したサーバとは別のサーバに配置することを推奨する。それによってビジネス・ワークフローの非同期呼び出しなどのCPU使用率を最適化できる。また、ビジネス・ワークフローが呼び出すビジネス・コンポーネントやデータアクセス・ロジック・コンポーネントも同じ位置に配置する。ただし、ユーザー・インターフェイス・コンポーネントから呼ばれるものと、ビジネス・ワークフローからしか呼ばれないものは物理的に区別しておく。

●データアクセス・ロジック・コンポーネント

　データアクセス・ロジック・コンポーネントは、それを呼び出すコンポーネントと同じ位置に配置することを勧める。メリットは、「データ転送を最適化できる」「ファイアウォールにトランザクション関連のポートを開けなくていい」「自動的にセキュリティが保たれる」、といったことである。また、Webアプリケーションの場合は、もしDataReaderオブジェクトを使っているのであればユーザー・インターフェイス・コンポーネントやユーザー・プロセス・コンポーネントと同じ位置に配置することを勧める。ただし、Webファームからデータベース・サーバに直接アクセスさせたくない場合や、データアクセス・ロジック・コンポーネントを複数の場所に配置したくない場合などはその限りではない。

■アセンブリ分割

　.NETアセンブリは配置やバージョン管理の最小単位である。ただし、バージョン管理のメリットを生かすためにはアセンブリ分割を注意深く計画する必要があるだろう。アセンブリを分割する際にはアプリケーションの大きさやチーム構成、管理プロセスなどを考慮した上で以下のポイントに気を付ける。

• コンポーネントの種類ごとに別のアセンブリにする

• 1つのアセンブリを複数の場所に配置しない

• コンポーネントの種類ごとに1つ以上のアセンブリを作る
  同じ種類のコンポーネントでも開発・運用のサイクルは異なるはずである。ビジネス・パートナーごとにアセンブリを分けたり、アセンブリが利用するコンポーネントやデータソースごとにアセンブリを分けたりすることを推奨する。

• 共通的な型は独立したアセンブリにする
  共通的な型として考えられるのは、例外クラス、インターフェイス、基底クラス、ユーティリティ・コンポーネントなどである。

• 開発プロセスに与える影響を考慮する
  開発チームのスキルやチーム開発の進め方に合ったアセンブリ分割にする。

• 使われないコードは配置しない

• アセンブリ分割をリファクタリングする

• Visual Studio .NETのエンタープライズ・テンプレートを活用する
  エンタープライズ・テンプレートを使うことで、開発者にプロジェクトの構造やデザイン パターンを強制することができる。

■コンポーネントのパッケージングと配布

　アプリケーションを配布する方法としてVisual Studio .NETに用意されているのが、CABファイルを作る機能とWindowsインストーラを作成する機能である。また、.NETアプリケーションであれば、単純にファイルをコピーすることでアプリケーションを配置することもできる。その他にも、Application Center、System Management Server、Active Directoryなどが分散アプリケーションを配布するときに利用できる。

INDEX
	[連載] アプリケーション・アーキテクチャ設計入門
	第5回（最終回）　物理配置および運用上の要求
	1．物理階層（ティア）の構成要素
	2．コンポーネントの物理配置計画とコンポーネント分散境界
	3．コンポーネントの配置パターン
	4．運用上の要求に対する設計方針

　

「アプリケーション・アーキテクチャ設計入門」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）