2.2集中と分散・クライアントサーバ

システムの規模が拡大すると、システムアーキテクトは「処理を1か所に集約するか、複数の拠点・マシンに分散させるか」という選択に必ず直面します。集中処理は管理がシンプルで一貫性を保ちやすい一方、単一障害点（SPOF）になりやすく、拡張にも限界があります。分散処理は可用性・拡張性で優れますが、管理の複雑さやデータ整合性の課題を抱えます。この節では、集中/分散の判断軸と、その具体形であるクライアントサーバ方式の層構成を学びます。

2.2.1集中処理と分散処理のトレードオフ

• 集中処理＝処理・データを単一の拠点・サーバに集約する方式。管理が一元化され整合性を保ちやすく運用コストも抑えやすいが、その拠点が停止するとシステム全体が停止する単一障害点（SPOF）になりやすく、負荷増大時のスケールにも限界がある。
• 分散処理＝処理・データを複数の拠点・マシンに分けて配置する方式。一部の拠点が停止しても他が稼働を継続できるため可用性が高く、負荷分散によるスケールアウトもしやすいが、拠点間の通信オーバーヘッド、データ整合性の維持、障害の切り分けの難しさなど運用の複雑度が増す。

2.2.2クライアントサーバの2層と3層

• 2層クライアントサーバ＝クライアント側にプレゼンテーションとアプリケーションロジックの両方を持たせ、サーバはデータ管理のみを担う構成。開発が比較的単純だが、業務ロジックの変更のたびに全クライアントの更新（再配布）が必要になり、クライアント台数が増えるほど保守負荷が増大する。
• 3層クライアントサーバ（Web多層アーキテクチャの起点）＝プレゼンテーション層（画面表示）・アプリケーション層（業務ロジック）・データ層（データ管理）を分離する構成。業務ロジックをサーバ側（アプリケーション層）に集約するため、ロジック変更時にクライアントの再配布が不要になり保守性が向上し、各層を独立にスケールできる利点もある。反面、層間通信が増えるため2層よりレイテンシが増える傾向がある。

あるシステムアーキテクトが、全国50拠点の営業所で使われている在庫管理システムを刷新する設計を任されました。現行システムは2層クライアントサーバで構築されており、業務ロジック（在庫引当のルールや割引計算等）が各拠点のクライアントアプリケーションに組み込まれています。この設計では、割引ルールが変わるたびに50拠点すべてのクライアントを個別に更新する作業が発生し、更新漏れによる拠点間のルール不整合が頻発していました。この問題を解決するため、アーキテクトは3層アーキテクチャへの移行を提案します。業務ロジックをアプリケーション層としてサーバ側に集約すれば、ルール変更はサーバ側の1箇所を更新するだけで全拠点に即座に反映され、クライアントの再配布作業も不要になります。次に、この新システムを単一の中央データセンターに完全集中させるか、地域拠点ごとにサーバを分散配置するかを検討します。全店舗が単一データセンターに依存する完全集中構成は、そのデータセンターがネットワーク障害を起こすと全国の営業所で在庫確認ができなくなるという単一障害点のリスクを抱えます。一方、地域拠点ごとにサーバを分散配置すれば、一部地域で障害が起きても他地域は業務を継続でき可用性は高まるものの、拠点間で在庫データの整合性をどう保つか（ある拠点で確保した在庫が別拠点の在庫画面に即座に反映されない可能性）という新たな課題が生じます。この会社は「在庫データの即時一貫性」を強く求める業種（返品率が高く在庫の二重引当が致命的なアパレル小売）であったため、最終的に中央データセンターに主系を置きつつ、地理的に離れた場所にホットスタンバイのバックアップセンターを構える折衷案を採用し、集中処理の一貫性の利点を活かしながら単一障害点のリスクを軽減する設計としました。

2.2.3この節のまとめ

• 集中処理は管理容易だがSPOFになりやすく、分散処理は可用性・拡張性は高いが運用複雑度が増す
• 2層は業務ロジックがクライアント側で保守負荷大、3層は業務ロジックをサーバ側に集約し保守性向上
• 即時一貫性が強く求められる業務では、集中処理の利点を活かしつつSPOFを軽減する折衷設計を検討する