連載 アプリケーション・アーキテクチャ設計入門 ―― Application Architecture for .NETに学ぶ.NETシステム設計 ―― 第5回（最終回）　物理配置および運用上の要求 日本ユニシス　猪股 健太郎 2004/02/14

Page1 Page2 Page3 Page4

Back Issue

1 .NET開発者のための設計ガイドライン 2 論理アーキテクチャを構成するコンポーネントの設計（プレゼンテーション層編） 3 論理アーキテクチャを構成するコンポーネントの設計（ビジネス／データ層編） 4 セキュリティ、運用管理、および通信のポリシーとその設計

はじめに

　さて、今回は連載の最後を締めくくる、Application Architecture for .NET（以下AAfN）の最終章（APPENDIXを除く）となる「物理配置および運用上の要求」を解説する。

　ここまでの章では、アプリケーション・アーキテクチャを論理階層（レイヤ）の面から取り上げてきた。この論理階層（レイヤ）は、アプリケーションの中に含まれるさまざまな機能について語るには都合がいいが、分散アプリケーションとして複数台のコンピュータに配置する際には必ずしも論理階層（レイヤ）のとおりに分割されるわけではない。

　どうして、論理階層（レイヤ）と物理階層（ティア）との間に違いがでるのだろうか。それは、論理階層（レイヤ）への分割と物理階層（ティア）への分割では、目的が異なるからである。論理階層（レイヤ）への分割は、カプセル化や抽象化といったテクニックで複雑なアプリケーション・システムの設計・実装を容易にし、保守性を高めることが主な目的となる。一方、物理階層（ティア）への分割は、性能、セキュリティ、運用といった非機能的な要求を満たすことが主な目的となる。

　もし論理階層（レイヤ）と物理階層（ティア）を独立に取り扱うことができるのであれば、その方が理にかなっている。ところが現実には、論理階層（レイヤ）と物理階層（ティア）は互いに影響を及ぼし合っている。要素技術の選択によって技術的な制約が発生するのである。

　従って、アーキテクチャを定めるときは、ハードウェアやネットワーク、OSといったインフラが本番環境ではどのようになるのかをあらかじめ確認した上で、論理的なアーキテクチャによる技術制約とインフラから来る技術制約を常に意識しながら設計をしなければならない。でないと、アプリケーションを物理階層（ティア）に分割配置する段階になって初めて、「つながらない」「動かない」などのトラブルが発生してしまうだろう。

コンポーネントの物理階層（ティア）への配置

■物理階層（ティア）の構成要素

　当連載の第2回および第3回で説明した各種コンポーネント群を物理階層（ティア）に分割して配置するに当たって、物理階層（ティア）がどのような要素から構成されるかをまず知る必要があるだろう。AAfNでは、物理階層（ティア）は以下の構成要素がファイアウォールで区切られたものだとしている。

− Webファーム −

　Webファーム（Web Farm）は、Webサーバの負荷分散構成のことを指す。負荷分散装置を使いハードウェア的に実現されたり、Windows Server付属のネットワーク負荷分散機能のようにソフトウェア的に実現されたりする。クライアントからの要求が特定のサーバに継続して振り分けられる保証がない場合と、クライアントのIPアドレスを判断基準に特定のサーバに振り分けられる場合がある。

　Webファーム構成で利用される負荷分散技術は、HTTPのように状態を持たない通信プロトコルが前提である。状態を持たない通信プロトコルとは、1回のクライアント要求に対し1回のサーバ応答で通信が完結していて、同一クライアントからの複数の要求であっても完全に独立した要求として扱われる通信プロトコルのことを指している。このような通信プロトコルであるからこそ、クライアントの要求を異なるサーバに振り分けることが可能になるのである。

　ところがほとんどのWebアプリケーションでは、複数の要求にまたがって存在するセッション状態を扱う。従って、Webファーム構成ではセッション状態の維持に特別な配慮が必要となる。

• ASP.NETでは、Webサーバでセッション状態を管理するための機能としてHttpSessionStateというオブジェクトが用意されている。しかし、HttpSessionStateで管理されたセッション状態は、デフォルトではサーバ・プロセスのメモリ上に置かれる。これでは、クライアントからの要求が毎回異なるサーバに振り分けられる場合にセッション状態が維持できない。そのような場合は、ステート・サーバと呼ばれる、サーバ・プロセスの外にセッション情報を保存する手段を用い、Webファーム内のすべてのWebサーバでセッション状態を共有する構成が推奨される。

• ビューステート（ViewState）はHttpSessionStateと異なり、クライアントとやり取りするHTMLのフォーム中にセッション情報を埋め込むことで、サーバ・プロセスのメモリを使わずにセッション状態を維持する仕組みである。Webファーム構成でビューステートを使う場合は、サーバの動作設定ファイルであるmachine.configで、ビューステートの設定を統一させておく必要がある。

• 通信プロトコルにHTTPSを使って通信を暗号化する場合は、クライアントの要求が毎回同じサーバに振り分けられるようにしなければならない。スケーラビリティとパフォーマンスのためには、HTTP要求を受け取るサーバとHTTPS要求を受け取るサーバを分割し、HTTPSサーバに限って要求を特定のサーバに振り分けるように構成することが推奨される。

− アプリケーション・ファーム −

　アプリケーション・ファームのコンセプトはWebファームと同じだが、こちらはアプリケーション・サーバの負荷分散が目的である。ここでアプリケーション・サーバとは、ビジネス層のコンポーネントを管理し、要求に応じて適切なビジネス・コンポーネントを動作させるサーバを指す。

　ビジネス層のコンポーネントでは、例えばCOM+の分散トランザクションを利用する場合など、通信プロトコル自身が状態を持つこともある。そのような場合ではWebファームと同じ負荷分散技術は適用できないため、Application Centerの機能であるコンポーネント負荷分散を利用する必要がある。

− データベース・クラスタ −

　負荷分散を目的としたファーム構成では、基本的には各サーバは独立していて情報を共有せず、要求をまたがって保持しなければいけない業務データはデータベースに格納することを前提にしている。逆にいうと、ファーム構成が可能なのはサーバが状態を持たないからであるともいえる。

　ところがデータベース・サーバはハードディスクなどのストレージ（記録装置）にデータを記録するので、全体として状態を持つといえる。従って複数台のデータベース・サーバを並べただけでは記録されるデータの整合性がとれない。データベース・サーバを冗長化するときにはWindows Server付属のMicrosoft Cluster Service（MSCS）機能のようにストレージを共有するしくみが必要になる。

− EAIクラスタ −

　AAfNがビジネス・ワークフローの実装に推奨しているBizTalk Serverは、必要とする情報をSQL Server上で管理する。従ってBizTalk Server自身は状態を持たず、ファーム構成による負荷分散が可能になる。

− リッチ・クライアント −

　コンポーネントをクライアントのコンピュータに配置することもできる。クライアント・アプリケーションは.NET Frameworkで作成されたWindowsアプリケーションであってもいいし、Microsoft Officeのようなアプリケーション製品でもいい。リッチ・クライアントを利用することで、Active Directoryによるユーザー管理や、高度なセッション状態の管理、オフラインでのアプリケーション利用などを実現することができる。

− シン・クライアント −

　シン・クライアントは、HTMLなどの簡素なユーザー・インターフェイスで実現される。通常はシン・クライアントのコンピュータはコンポーネントの配置場所にならない。

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

　

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

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