システムの処理形態とクライアントサーバ

このページでは、集中処理と分散処理、シンクライアントとVDI、クライアントサーバの2層・3層構造、ストアドプロシージャやRPCなどの技術、MVCがわかります。

システムの処理形態

• 一言で言うと：
  • コンピュータの仕事を「1か所にまとめてやる（集中処理）」か「何台かに分けてやる（分散処理）」か、という話。

1か所でやる（集中処理）→ 分けてやる（分散処理）→ 画面だけ手元に送る（VDI）

覚え方の軸

• 集中と分散は裏返しの関係：
  • 集中は「管理・セキュリティ・原因究明が楽、でも変更しにくく、1か所の故障が全体に響く」。分散はその逆
• 分散は「構成（水平・垂直）」×「対象（機能・負荷）」の2つの切り口：
  • 組み合わせは4通りあるが、実在するのは3つ（水平機能・水平負荷・垂直機能）。垂直負荷分散はない
• 「端末に何を持たせるか」で並べる：
  • 普通のPC（全部持つ）→ シンクライアント（最低限）→ VDI（画面だけ）

集中処理システム：1台のホストで全部やる

• 集中処理システム：
  • 情報資源や処理を1か所に集中させたシステム。代表は、1台のホストコンピュータで複数の業務（基幹業務）を行う構成
  • 処理方式は、データエントリとトランザクション処理が中心のオンライントランザクション処理
  • 過去のものと思われがちだが、管理しやすく安全性が高いので今も使われている
• オンライントランザクション処理：
  • 座席予約や銀行の入出金のように、通信回線経由で発生したトランザクションを即時に処理する方式
• シンクライアント端末：
  • 処理のほとんどをホストで行うので、端末は通信や入出力など必要最低限の機能だけでよい。そういう端末のこと
  • 長所：
    • 端末内にデータが残らないので情報漏えい対策になる
    • 端末を交換するとき、アプリやデータのインストール作業を減らせる
• 注意：
  • 集中処理は情報資源が1か所にあるので、災害に備えて予備システムを離れた場所に置くなどの対策が必要

分散処理システム：何台かで手分けする

• 分散処理システム：
  • データや機能を各コンピュータに分散させ、利用者がネットワークを通してすべての資源を共有しながら効率よく処理するシステム
• 特徴：
  • 局所的な処理は、近くの分散コンピュータで行う（分散処理方式）
  • システム横断的な処理は、中央コンピュータで行う（集中処理方式）
• 集中と分散の比較（★表ごと覚える）

項目	集中処理	分散処理
資源管理	容易	困難
セキュリティ確保	容易	困難
データの維持管理	容易	困難
要望による機能追加・変更	困難（すぐには応じられない）	容易（局所的な追加・変更は簡単）
障害による影響	一部の障害が全体に影響	影響を局所化できる
障害の原因究明	容易	困難

• 分散処理の分類（2つの切り口）
  • 構成による分散：
    • 水平分散、垂直分散
  • 対象による分散：
    • 機能分散、負荷分散
• 3つの形態

形態	中身
水平機能分散	業務の種類や、データベースの作成・維持管理の責任によって、処理するコンピュータを分ける
水平負荷分散	同じアプリを複数のコンピュータで実行できるようにして、負荷を分散する
垂直機能分散	一連の処理機能を階層的に分け、階層ごとのコンピュータが違う処理を行う（例：クライアントサーバ）

• 垂直負荷分散システムは実在しない（ひっかけ注意）
• 水平負荷分散のポイント：
  • 処理要求が来るたびに各コンピュータの負荷を見て振り分ける
  • 一部が故障しても他で処理を続けられるので、可用性の向上が期待できる

VDI（デスクトップ仮想化）

• VDI（Virtual Desktop Infrastructure）：
  • シンクライアントをさらに発展させたもの。デスクトップ環境をVDIサーバ上で仮想化し、利用者は手元の端末（PC、タブレットなど）で操作しているかのように使う
• 画面転送：
  • 端末とVDIサーバの間は画面転送プロトコルだけを使う。端末に送られるのは画面だけ
• 長所：
  • 端末側にデータがない
  • 画面しか来ないので、マルウェア感染の心配もない
  • セキュリティの向上、メンテナンスやコストの軽減

混同しやすいペア

• 集中処理（管理・安全・原因究明が楽）／分散処理（変更が楽、障害を局所化できる）
• 水平機能分散（業務ごとに分ける）／水平負荷分散（同じアプリを何台かで動かす）／垂直機能分散（階層ごとに役割を分ける）
• 水平負荷分散（実在する）／垂直負荷分散（実在しない）
• シンクライアント（最低限の機能を持つ端末）／VDI（デスクトップごとサーバに置き、画面だけ送る）

クライアントサーバシステム

• 一言で言うと：
  • 「頼む側（クライアント）」と「応える側（サーバ）」に役割を分けてシステムを作る話。役割を何層に分けるか、通信をどう減らすかがポイント。

頼む側と応える側に分ける → 2層から3層へ → Webでの3層 → つなぐための技術 → アプリの中も3つに分ける（MVC）

覚え方の軸

• 2層の弱点を、3層が解決する：
  • 2層は業務ロジックがクライアントに入っている → 直すとき全台修正。3層は業務ロジックを真ん中の層に切り出す
• 3層は「見せる・考える・しまう」：
  • プレゼンテーション層（画面）→ ファンクション層（業務処理）→ データベースアクセス層（DB）。Webでは Webサーバ → APサーバ → DBサーバ
• 関連技術は「何を遠くから呼ぶか」で分ける：
  • SQLのまとまり（ストアドプロシージャ）、手続（RPC）、ファイル（NFS）、オブジェクト（CORBA）
• 「3つに分ける」が何度も出る：
  • 3層クライアントサーバ、Web3層構造、MVCモデル

クライアントサーバシステムの特徴：頼む側と応える側

• クライアントサーバシステム：
  • 処理を、サービスを要求するクライアントと、サービスを提供するサーバに機能分割するシステム概念
  • 特定のアプリやコンピュータに依存しない、柔軟な分散処理（垂直機能分散）を作れる
  • クライアントもアプリを実行する機能を持ち、必要なときにサーバにサービスを頼む
  • ダウンサイジングとEUCというキーワードとともに主流になった形態
• 役割の例
  • クライアント（PC）：
    • ユーザインタフェース処理、問合せ内容の標準形への変換、データベース管理系との通信
  • サーバ：
    • トランザクション処理の実行（DBアクセス）、DBアクセス権の管理、DBの整合性管理
• 代表的なサーバ：
  • データベースサーバ、ファイルサーバ、プリントサーバ、通信サーバ
  • サーバの機能を専用化することで、個々のサーバの性能を比較的簡単に上げられる

クライアントサーバの実体

• 本来の意味：
  • サービスを要求するプロセスと、提供するプロセスが通信し合って処理する仕組み（機械の話ではなくプロセスの話）
• X Window（Xウィンドウ）システム：
  • クライアントサーバの始まり。UNIXの仕組み
  • Xサーバ：
    • 同じコンピュータ上で動き、Xアプリからの描画依頼を受けて画面に描いたり、キーボードやマウスの入力をXクライアントに知らせたりする
  • ポイント：
    • 画面を持つ手元の側が「サーバ」になる（一般のイメージと逆）

クライアントサーバアーキテクチャ：2層と3層

• 2層クライアントサーバシステム：
  • 従来型。DBサーバはDBの管理と要求されたDBアクセスだけを行い、その他の処理はすべてクライアントが行う
  • 問題点：
    • 業務ロジックがクライアント側にユーザインタフェースと一体化して入っている
    • アプリの肥大化、アプリ間の相互矛盾が起きる
    • 業務ロジックを変えると、何台ものクライアントのプログラムを同時に直す必要がある
• 3層クライアントサーバシステム：
  • 2層の問題を解決するため、クライアントから業務ロジックを切り離し、システムを論理的に3層に分けたもの（★各層の名前と役割が問われる）

層	別名	役割	置き場所（一般的）
プレゼンテーション層	―	GUI処理（ユーザインタフェース）。検索条件の入力、結果の表示	クライアント（PC）
ファンクション層	アプリケーション層	業務に依存する処理、データ加工処理。検索条件をSQL文に変換してDB層に頼み、受け取った結果を加工して返す	サーバ、または別に置くアプリケーションサーバ
データベースアクセス層	データベース層	データベース処理。DBにアクセスして結果を返す	サーバ

• 処理の流れ：
  • ①検索条件を入力（プレゼンテーション）→ ②SQLに変換して依頼（ファンクション）→ ③DBにアクセスして結果を返す（DBアクセス）→ ④結果を加工して返す（ファンクション）→ ⑤結果を表示（プレゼンテーション）
• 3層は論理的な分け方なので、3層とも同じコンピュータに載せてもよい
• 3層の利点
  • 業務ロジックが変わっても、クライアントへの影響が少ない
  • アプリの修正や追加が頻繁なシステムほど導入効果が高い
  • 各層の独立性が高く依存度が低いので、層ごとに並行して開発できる

Webシステムの3層構造：Web・AP・DBに分ける

• Web3層構造：
  • Webサーバ、アプリケーションサーバ（APサーバ）、データベースサーバ（DBサーバ）を、それぞれ別の物理サーバに置く形態

サーバ	役割
Webサーバ	HTTPリクエストの受付とレスポンスの返却。静的コンテンツ（静的HTML、画像など、負荷が軽い）の配信
APサーバ	アプリと動的コンテンツ（CGIプログラムなど、負荷が重い）の処理
DBサーバ	データベース機能

• WebサーバとAPサーバを分ける理由：
  • 役割を分けて負荷を分散するため。同じ物理サーバに置くより負荷が下がり、多くのリクエストを効率よく処理できる
• アプリケーションサーバ：
  • DBアクセス層への接続やトランザクション管理の機能を持ち、ファンクション層として業務処理の流れを制御する
• Webシステムの利点：
  • 汎用のWebブラウザを使うので、OSなどクライアント側の環境をそろえる必要がない。クライアント環境の保守とコストを減らせる
  • クライアントの性能が低くても、Webブラウザさえあればサービスを提供できる
• WebSocket：
  • HTTP/1.0はリクエストごとにTCPコネクションの接続・切断を繰り返し、コネクションを持ち続けない
  • WebSocketは、ブラウザとサーバの間にソケット接続を確立し、その後はHTTPの手順に縛られずに1つのTCPコネクションで双方向通信する

クライアントサーバ関連技術：遠くのものを手元のように使う

• ストアドプロシージャ：
  • 一連のSQL命令からなるDB処理手続（プロシージャ）を、実行できる状態でDBMSの中に格納したもの。クライアントは呼び出すだけで処理を実行できる
  • 利点：
    • クライアントからSQL文を1つずつ送らなくてよい
    • クライアントとサーバ間の通信量と通信回数を減らせる（★最も期待できる効果）
    • 共通のDBアクセス手続をクライアントに提供できる（データ操作の標準化、共有化）
    • 機密性の高いデータへの処理をプロシージャにすることで、セキュリティが上がる
  • 注意：
    • プロシージャにする単位が細かすぎると、かえって通信回数が増えて効果が出ない
• RPC（Remote Procedure Call）：
  • 他のコンピュータの手続を、同じコンピュータにある手続のように呼び出せる機能
  • 呼ぶ側と呼ばれる側が独立したプロセスとして動くので、異なるOS間でも呼び出せる。分散プログラミングができ、ネットワーク上の資源を有効に使える
• CORBA：
  • RPCをオブジェクト指向プログラミングに応用したもの。OMGが決めた分散オブジェクト技術の仕様。開発言語やプラットフォームに依存せず、オブジェクト間の連携ができる
• NFS（Network File System）：
  • RPCの上に作られた、主にUNIXで使うファイル共有システム。離れたコンピュータのファイルを、自分のファイルのように操作できる
  • プログラムは、ファイルが別のコンピュータにあっても場所を知らずにオープンや入出力ができる（NFSクライアント → RPC → NFSサーバ）

MVCモデル

• MVCモデル：
  • APサーバ上のアプリを作るときに使うアーキテクチャパターン。機能とヒューマンインタフェースの相互依存を弱め、修正しやすさや再利用性を上げるのが目的
• モデル層（Model）：
  • 処理の中核（業務処理、ビジネスロジック）
• ビュー層（View）：
  • 入力と表示
• コントローラ層（Controller）：
  • モデル層とビュー層の制御。例：
    • ビューからの入力を受けてモデルに処理を頼み、その結果の表示をビューに頼む

混同しやすいペア

• 2層（業務ロジックがクライアントにある、修正は全台）／3層（業務ロジックをファンクション層に分離）
• ファンクション層（業務処理）／データベースアクセス層（DB処理）
• Webサーバ（静的コンテンツ、HTTPの受付）／APサーバ（動的コンテンツ、業務処理）
• RPC（遠くの手続を呼ぶ）／NFS（RPCの上で、遠くのファイルを使う）／CORBA（遠くのオブジェクトと連携）
• ストアドプロシージャ（DBの中にSQLのまとまりを置いて通信を減らす）／RPC（他のコンピュータの手続を呼ぶ）
• 3層クライアントサーバ（システム全体を3層に分ける）／MVC（アプリの中を3つに分ける）
• HTTP/1.0（リクエストごとに接続・切断）／WebSocket（1本のTCPで双方向）

---

← 04 システム構成要素の目次に戻る