概念: 分散パターン
トピック
プロセッサとデバイスは、ノードの一般的なステレオタイプです。現在では多数のデバイスに各自の CPU が入っているので、この 2 つは区別しにくいかもしれません。しかし、プロセッサとデバイスの区別は、その上で実行されるソフトウェアのタイプにあります。プロセッサは、開発中のシステム用に明示的に作成されたプログラムやソフトウェアを実行します。プロセッサは、計算機能、メモリ、実行機能を持つ汎用の計算デバイスです。
デバイスは、デバイスそのものの機能を制御するために作成されたソフトウェアを実行します。デバイスは通常は、デバイスを制御するプロセッサに付属しています。通常は、組み込みソフトウェアを実行し、汎用のプログラムの実行はできません。デバイスの機能は、通常はデバイス ドライバ ソフトウェアによって制御されます。
システムの機能とアプリケーションのタイプに応じて、システム内の分散にはいくつかの典型的なパターンがあります。多くの場合、分散パターンは、システムの「アーキテクチャ」を記述するために非公式に使用されますが、アーキテクチャ全体には、このほかにも多数のものが含まれます。たとえば、システムは「クライアント / サーバー アーキテクチャ」を持つとしばしば記述されますが、これはアーキテクチャの分散の側面にすぎません。これによって、システムの分散の側面の重要性と、この側面がアーキテクチャのその他の決定に与える影響の程度が強調されます。
次に示す分散パターンは、特定のシステム特性、性能特性、プロセス アーキテクチャを暗に示しています。どれも特定の問題を解決しますが、それと同時に固有の難題が生じます。
いわゆる「クライアント / サーバー アーキテクチャ」には、クライアントと呼ばれる特化したネットワーク プロセッサ ノードと、サーバーと呼ばれるノードがあります。クライアントは、サーバーが提供するサービスのコンシューマです。クライアントは多くの場合、1 ユーザーにサービスを提供し、エンドユーザーのプレゼンテーション サービス (GUI) を処理します。これに対してサーバーは、普通は複数のクライアントに同時にサービスを提供します。提供されるサービスは、通常はデータベース、セキュリティ、印刷のサービスです。「アプリケーション論理」すなわちビジネス論理は、これらのシステムでは通常クライアントとサーバーの両方に分散しています。ビジネス論理の分散は、アプリケーション分割と呼ばれます。
次の図では、クライアント A が 2 層アーキテクチャの例を示し、ほとんどのアプリケーション論理がサーバー内に置かれています。クライアント B は典型的な 3 層アーキテクチャを示し、ビジネス オブジェクト サーバー内にビジネス サービスが実装されています。クライアント C は典型的な Web ベースのアプリケーションを示しています。

クライアント / サーバー アーキテクチャのバリエーション
従来のクライアント / サーバー システムでは、大部分のビジネス論理がクライアントに実装されますが、サーバーに置くほうが適している機能もあります。たとえば、サーバーに格納されたデータに頻繁にアクセスする機能です。このような機能をサーバーに置くことでネットワーク トラフィックを減らすことができます。ネットワーク トラフィックは、大抵の場合かなりコストがかかります (プロセス間コミュニケーションに比べて 1 ~2 桁低速です)。
特性の例:
- 1 つのシステムを、たとえば次のような数種類のクライアントで構成できる
- ユーザー ワークステーション
- ネットワーク コンピュータ
- クライアントとサーバーが、さまざまな技術を使用してコミュニケーションする (CORBA/IDL、RPC (リモート プロシージャ コール) などの技術を使用)
- 1 つのシステムを、たとえば次のような数種類のサーバーで構成できる
- データベース サーバー: Sybase、Ingres、Oracle、Informix などのデータベース コンピュータを扱う
- 印刷サーバー: 特定のプリンタのドライバ論理 (キューなど) を扱う
- コミュニケーション サーバー (TCP/IP、ISDN、X.25)
- Window Manager サーバー (X)
- ファイル サーバー (UNIX 下での NFS)
「3 層アーキテクチャ」は、特殊なケースの「クライアント / サーバー アーキテクチャ」であり、システム内の機能が 3 つの論理パーティション (アプリケーション サービス、ビジネス サービス、データ サービス) に分割されます。「論理パーティション」は実際、3 つ以上の物理ノードにマッピングすることができます。

3 層アーキテクチャの例
これらの 3 つの「層」への論理パーティション分割は、一般的なオフィス アプリケーションの機能がどのように実装される傾向にあるか、そしてどのように変更されるかについての観察を反映しています。アプリケーション サービスは、主として GUI のプレゼンテーションの問題を扱い、グラフィカルなウィンドウ オペレーティング環境を持つ専用のデスクトップ ワークステーション上で実行される傾向があります。機能の変更は、多くの場合は使いやすさや美的観点、基本的にはヒューマン・ファクターの問題によって要求される傾向があります。
データ サービスは、データベース サーバー技術を使用して実装される傾向があり、ネットワークで接続された数百~数千のユーザーにサービスを提供する 1 つ以上のより高性能で高帯域幅のノード上で実行される傾向があります。データ サービスは、格納された情報の間の表現と関係に変更があったときに変更される傾向があります。
ビジネス サービスは、ビジネス プロセスのエンコードされた知識を反映します。データ サービスから取得された情報を操作、合成し、アプリケーション サービスに提供します。ビジネス サービスは、通常は共通の多数のユーザーによって使用されるので、専用のサーバーにも置かれる傾向がありますが、データ サービスと同じノードに置かれることもあります。
これらの線に沿ったパーティション分割機能は、比較的信頼性の高いスケーラビリティのパターンを提供します。サーバーを追加し、データ サーバーとビジネス サーバーの間で処理の分散を変更することで、高度なスケーラビリティが実現されます。
クライアント上でほとんどすべてのものが実行されるので、クライアントが「ファット」、すなわち太ってしまいます (データ サービスが別個のノードに置かれる「2 層アーキテクチャ」と呼ばれるバリエーションは除きます)。アプリケーション サービス、ビジネス サービス、データ サービスがすべてクライアント コンピュータに置かれ、データベース サーバーは通常は別のコンピュータに置かれます。

従来の 2 層または「ファット クライアント」アーキテクチャ
「ファット クライアント」は、設計と構築が比較的単純ですが、大規模で一体構造になりがちなので、分散と保守が難しくなります。クライアント コンピュータは性能向上のためにデータをローカルでキャッシュする傾向があるので、ローカル キャッシュの結合性と一貫性が、特定の注意に値する問題と領域になる傾向があります。複数のローカル キャッシュ内にある共有オブジェクトに対する変更は、調整が困難で高コストになります。なぜなら、変更をネットワークでブロードキャストする必要があるからです。
「ファット クライアント」の正反対は、「ファット サーバー」または「シン クライアント」です。典型的な例は、HTML ページのセットを実行する Web ブラウザ アプリケーションです。クライアントにはほとんどアプリケーションが置かれません。ほとんどの作業は 1 つ以上の Web サーバーとデータ サーバー上で行われます。

Web アプリケーション
Web アプリケーションは分散と変更が容易です。比較的低コストで開発とサポートができます (なぜなら、アプリケーション インフラストラクチャのほとんどが、ブラウザと Web サーバーから提供されるからです)。ただし、必要な程度のコントロールをアプリケーションに提供できない場合があり、設計が不適切だと (そしてときには設計が適切な場合でも) ネットワークがすぐに飽和状態になる傾向があります。
このアーキテクチャでは、アプリケーション サービス、ビジネス サービス、データ サービスが異なるノード上に置かれ、ビジネス サービスとデータ サービスの層内でサーバーの特化が行われる可能性があります。3 層アーキテクチャの完全な実現です。
ピアツーピア アーキテクチャでは、システム内のプロセスやノードがクライアントとサーバーの両方になることができます。相互に関連するサービスをグループにまとめることで機能の分散を実現し、ネットワーク トラフィックを最小限にすると同時にスループットとシステム使用効率を最大にします。このようなシステムは複雑になる傾向があり、プロセス間のデッドロックや枯渇、障害の処理などの問題に対する注意を強める必要があります。
|