このページをはてなブックマークに追加このページを含むはてなブックマーク このページをlivedoor クリップに追加このページを含むlivedoor クリップ

目次

コンピュータの利用方法の変化

  1. 集中処理
  2. 分散処理
  3. クライアントサーバーシステム

処理形態による分類

 処理形態はバッチ処理とリアルタイム処理に大別される。さらに形態によって細分される。

  • バッチ処理←例:出欠のデータをまとめて処理する給与計算システムなど。
    • センターバッチ処理(接続方式:オフライン)
    • リモートバッチ処理(接続方式:オンライン)
  • リアルタイム処理←例:銀行のオンラインシステムなど。
    • 対話型処理(接続方式:オンライン)
    • オンライントランザクション処理(接続方式:オンライン)
    • リアルタイム制御処理(接続方式:オンライン)

センターバッチ処理

 バッチ処理とは、データをまとめて一括処理する方法である。そのバッチ処理がセンターの一ヵ所によってなされるタイプである。

リモートバッチ処理

 データを通信回線を利用してバッチ処理する方式。

対話型処理

 コンピュータと対話形式で処理を進める方式。プログラム開発などに適していて、速い応答が要求される。

 通常は複数のプログラムに短い時間の実行件を与えてあたかも一人でコンピュータを独占しているような感覚で使用する。こうした処理を時分割処理(TSS)という。

オンライントランザクション処理

 オンラインで接続された端末から、センターのオンラインファイルのデータを更新する処理方法。例えば、銀行のATMや座席予約システムなどがある。

 この処理ではたくさんの端末があるので、それぞれから送られたデータがきちんとデータベースのデータとして成立しなければならない。そのためには、ACID特性が保たれることが重要である。

リアルタイム制御処理

 制御系のシステムで時々刻々と変化する情報をもとにして即時に計算処理を行い、その結果を制御システムに出力する方式。例えば、航空管制システム、新幹線の運転制御などがそうだ。

集中処理と分散処理

 コンピュータの物理的配置によって、集中処理方式と分散処理方式に分けられる。

集中処理

 1台のコンピュータ(ホストコンピュータ)に多数の端末を接続してそのコンピュータだけに処理を行わせるシステム形態。

  • 長所
    • 設備や人員を集中できるので効率的
    • データの更新やセキュリティ対策が一ヵ所で済む
    • オンラインシステムは、スタンドアロンシステムに比べてターンアラウンドタイムが短い
  • 短所
    • OSのオーバーヘッドが大きい
    • ホストの障害がシステム全体に影響する
    • バックアップログが溜まりやすい
    • ネットワークのトラフィックの大小により、処理効率が左右される

 集中処理システムの代表的な処理として、次のようなものがある。

  • 照会応答型処理
    • 情報検索・行進が中心となる処理。
    • 入力メッセージと出力メッセージが対になっている。
    • 場合により、メッセージ長が大きいことがある。
  • データ収集処理
    • メッセージは一方向にだけ送られ、メッセージ長は小さい。
      • 例:販売時点情報処理(Point Of Sales:POS)
  • メッセージ交換処理
    • ホストコンピュータを経由した電文の交換処理である。
    • 入力・出力は非同期に発生する。
      • 例:為替の交換システム
  • リモートバッチ処理
    • 端末装置からネットワークを経由してバッチ処理を行う。
    • 入力・出力共に大量である。

分散処理

 ネットワークで接続された複数のコンピュータで処理するシステム形態。処理効率の向上に有効である。

 分散処理システムは、何を分散するかによって、次のように分類できる。

  • 機能分散
  • 負荷分散
  • データ分散

 機能分散を行えば、結果として負荷は分散される。したがって、これらの分類は明確な区別があるわけではない。LAN内で、ファイルサーバーやメールサーバーなどの構成で運用することは、機能分散させることによって、負荷の集中を避けることが目的である。

 分散処理システムの長所・短所は次の通りである。

  • 長所
    • 信頼性が向上する。
    • 災害や障害の影響が局所化できる。
    • 個々のシステムの資源管理が容易である。
    • システムの変更が容易である。
    • 通信量が削減する。
      • 通信量を削減できるということに意外性を感じるかもしれない。実はデータ利用については80-20の法則というのが成り立つことが多い。80-20の法則とは、「データに対するアクセスは、その80%が発生場所によるもので、その他の場所からのアクセスは20%に過ぎない」という法則である。
      • 例えば、ホストシステムの場合、すべてのデータがホストで管理されているから、データに対するアクセスには必ず通信が発生する。一方、分散システムで発生場所にデータを置いておけば、全体の20%に相当する他からのアクセスだけに通信が必要なので、通信量が削減できるということである。
    • 処理量が増えても、安価なシステムを組み合わせればよく(ダウンサイジング)、結果として少ない投資で対応可能。
      • 確かにハードウェアの導入コストは削減できるものの、ソフトウェアのメンテナンスや要員教育などを含めたコスト(TCO)まで考えると、逆にコスト高になるという評価が一般的である。
  • 短所
    • データが分散しているので、データの更新に手間・時間がかかる。
    • セキュリティ対策が個々(末端)で行う必要がある。
    • データの不整合が発生しやすい。
      • トランザクション処理ならば、原子性確保のために2相コミットメントなどが必要となる。
    • 異常が発生した際に、原因の特定が困難である。
    • 運用・保守費用が増大する。
    • 運用管理が複雑になりやすい。

 さらに、分散処理を採用したシステムには次のように分類できる。

  • 分散処理システム
    • 水平機能分散システム
    • 水平負荷分散システム
    • 垂直機能分散システム
    • 垂直負荷分散システム

 ○○分散とは次のような意味を持つ。

  • 機能分散
    • システム機能の特定部分を分担する。
  • 負荷分散
    • 同一機能を有して負荷を分担させる。
  • 垂直分散
    • 機能を階層的に分散させる。
    • 集中処理との混在、集中処理から分散処理へのシステム移行が比較的楽である。
    • ネットワークは論理的にスター型の構成となる。
  • 水平分散
    • 機能を対等に分散させる。
    • すべてのコンピュータが対等の立場でホストコンピュータとしてネットワークにつながっている。
    • 個々のコンピュータでのシステム開発・管理に関する自由度が大きい。
    • その逆に、システム全体の運用管理は難しくなりがちである。

例1:金融システムにおいて情報系用コンピュータと勘定系用コンピュータのようにコンピュータごとに機能を分けた場合、水平機能分散システムといえる。

例2:クライアントサーバーシステムは、垂直負荷分散システムである。

例3:水平負荷分散システムを用いると、MTBFが長くなってシステム全体のアベイラビリティは向上する。

分散処理システムの設計

 データの分散配置を検討する際は、データの更新処理の実行場所を特定して、マスターデータの配置を決定することから始まる。並列処理で問題がありそうな場合には、サーバー側に配置する。

分散処理システムの透過性

 分散処理システムでは、ユーザーに対して、分散システムの構成要素が分離していることを意識させないようにする必要がある。このような性質を透過性と呼ぶ。

  • 位置透過性
    • ネットワークに接続されている資源に対して、その存在位置を意識することなくアクセスできること。
  • アクセス透過性(ネットワーク透過性)
    • ネットワークに接続されている異なる種類の機種・OSの資源に対して、同一方法でアクセスできること。
  • 規模透過性
    • OSやアプリケーションの構成に影響を与えることなくシステムの規模を変更できること。
  • 並行透過性
    • 複数のユーザーが同じオブジェクトを共有して並列に処理できること。
  • 複数透過性
    • システムの信頼性や性能の向上のためにファイルの複数物を複数の機械上に持つこと。
  • 移動透過性
    • クライアントに影響を与えずオブジェクトの場所を変更できること。
  • 障害透過性(故障透過性)
    • 故障が発生した場合にも気付かせずに仕事の完了を可能にする。
    • 障害があっても、同じオブジェクトを持つ他の機械に切り換えて容易に復旧できること。
  • 性能透過性
    • 性能改善のためにシステムの再構成を可能にする。

まとめ

集中処理分散処理
システムの規模大きい小さい
開発費用高い低い
運用・保守費用高い低い
安全性高い低い
信頼性ホストコンピュータがダウンすると、全システムがダウンする。一部の端末がダウンしても他の端末で処理可能。
システムの管理システムの管理が比較的容易で、プログラムやデータを共有して、集中管理できる。システムの管理が複雑になり、手間がかかる。

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

 クライアントサーバーシステムとは、処理を要求するコンピュータと要求の処理を行うコンピュータを分けた構成のことです。処理を要求するコンピュータをクライアント(マシン)、要求を処理するコンピュータをサーバー(マシン)と呼ぶ。

 一般的なLANやインターネットシステムはクライアントサーバーシステムで構成されている。

 クライアントサーバーシステムの長所と短所を次に示す。

  • 長所
    • クライアントとネットワークの低価格化でシステム全体のコストを低減可能。
    • オープンシステム化が容易であり、負担増・機能増に対応した拡張性が高い。
    • 障害発生時の影響を局所化できる。
  • 短所
    • システム管理・保守の作業量が大きい。
    • 管理責任が不明確で、セキュリティが弱くなりがち。
    • 特定のサーバーに利用が集中すると性能が低下する。

分類

2層クライアントサーバーモデル

 2層クライアントサーバーモデル(2-tier client server system)は、旧来のクライアントサーバーシステムである。ユーザー側(GUI)がクライアント、データベース側サーバーの役割になる。ファンクション層の機能は、状況に応じて、クライアントもしくはサーバーに割り当てられる。

ファンクション機能の割り当てクライアントサーバー
サーバーに割り当てシンクライアントファットサーバー
クライアントに割り当てファットクライアントシンサーバー

 データ部は通常RDBMSになる。一方アプリケーションとUI(ユーザーインターフェース)はビジュアル開発ツールなどでユーザーが開発したプログラムである。そして、クライアントとサーバーはSQLを使ったプロセス間通信で会話する。

 処理の流れは次のようになる。

  1. ユーザーはUIを使って検索条件などを入力する。
  2. アプリケーションは検索条件をSQLに変換して、サーバーに渡す。
  3. データ部は渡されたSQLでデータベースを検索し、結果をアプリケーションに返す。
  4. 結果はアプリケーションで加工した後にUIで表示する。

 なお、データベースの更新を伴なう場合、一連の処理が完全に終了するまでセッション管理が必要である。

3層クライアントサーバーモデル

 3層クライアントサーバーモデル(3-tier client server system)とは、クライアントサーバー型のアプリケーションを論理的な3つのモジュールに分けたシステムのことである。3層アーキテクチャとも呼ばれる。

 アプリケーションの実行をプレゼンテーション層、ファンクション層、データベース層という3つの階層に区分して考える。

 2層クライアントサーバーシステムのクライアントは業務処理に係わる処理とユーザーインタフェース(GUI)をあわせて分担し、サーバーはデータベースとしてのみ機能していた。これに対して、クライアントにユーザーインタフェース機能のみを持つプレゼンテーション層を配置して、サーバー側にデータ管理を行うデータ層と、データ層とプレゼンテーション層の中間に業務処理を専門に行うファンクション層を配置した形が3層クライアントサーバーである。

[補講]3層は論理的に分けたものであり、別々のマシン上に搭載しても同一マシン上でも構わない。ただし、一般的に3階層システムといった場合は、物理的に別々のマシンにそれぞれの層を配置したシステムを指すことが多い。 ◇

PLL(プレゼンテーション層)ユーザーインタフェース部分(GUIに相当)
ALL(アプリケーション層・ファンクション層)データの加工処理部分
DMB(データ層)データベースにアクセスする部分

 この3層を機能的に明確に区分することで、システム性能や開発・保守効率の向上を狙う。結果として、拡張性、柔軟性に富んだシステムが構築できる。

 アプリケーションの追加・修正は、ファンクション層を変更すればよい。

 3層クライアントサーバーシステムにおいて、その3層をどこに置くかによって呼び方が次のように変わる。

  • サーバーにDMBとALL、クライアントにPLL
    • リモートプレゼンテーション
      • クライアントは見るだけ。
      • Webを使った予約システムなど
  • サーバーにDMB、クライアントにALLとPLL
  • サーバーにDMBとALL、クライアントにALLとPLL
  • サーバーにDMB、クライアントにDMBとALLとPLL
    • 分散データベース
      • データそのものの一部をクライアントにも持たせる。

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

  • クライアントとサーバーがそれぞれ処理を分散して行うことによって、システムへの負荷を分散することができる。
    • 3層クライアントサーバーシステム⇒それぞれのクライアントとサーバー間のデータ転送量が減少してネットワークの負荷が軽減することができる。
    • 2層クライアントサーバーシステム⇒ストアドプロシージャ*1を使うことで、クライアントとサーバー間のデータ転送量を減少させ、ネットワークの負荷を軽減することができる。
  • それぞれのコンピュータの役割が明確になり、冗長な機能の搭載が不要になるため、設備費用を抑えることができる。ただし、接続するコンピュータの代数が少ない場合は、P2P型と呼ばれる携帯のほうが設備費用がかからない。
  • 管理するコンピュータが増えるため、システムが複雑になるだけでなく、製品・技術を提供する体制も複雑になる。
  • 問題が発生したときの原因や責任の所在を明確にしにくい。

イベントリ収集

 イベントリ収集とは、クライアント管理ツールのひとつで、LAN上のクライアントが持っているデータやハードウェアの情報などを収集することができる機能のことである。

参考文献

  • 『実践コンピュータシステム』
  • 『らくらく初級シスアド図解教本 2004春』
  • 『超図解mini 基本情報技術者試験 平成19年度版』
  • 『平成12年度 【要点・重点】短期集中速攻対策 第1種』
  • 『2005年版 出る順情報セキュリティアドミニストレータウォーク問過去問題集』
  • 『ソフトウェア開発技術者 午前対策(基礎編) テキスト』
  • 『ソフトウェア開発技術者 合格エッセンシャルハンドブック』
  • 『2004/2005年版 情報セキュリティアドミニストレータコンパクトブック』


*1 データベースに対する一連の処理をひとつのプログラムにまとめて、データベースサーバーに保存してクライアントからの指示ですぐに実行できるようにする仕組み