1-4 システム構成要素
システム構成要素
業務システムは、複数のコンピュータ、ネットワーク、ソフトウェアを組み合わせて構成します。ITパスポートでは、構成方式の名前だけでなく、性能、信頼性、可用性、費用のどれを優先して設計したかを判断する問題が出題されます。
この節の目標は、集中処理・分散処理、クライアントサーバ、冗長化、仮想化、クラウドの特徴を比較し、要件に合う構成を選べるようになることです。
1. 処理をどこで行うか
| 方式 | 特徴 | 向いている場面 |
|---|---|---|
| 集中処理 | 中心となるコンピュータへ処理を集める | 統制や一元管理を重視する大規模業務 |
| 分散処理 | 複数のコンピュータで処理を分担する | 拠点分散、負荷分散、拡張性を重視する業務 |
| 並列処理 | 複数の処理装置で同時に計算する | 大量計算や短時間処理 |
| クライアントサーバ | クライアントが要求し、サーバが機能を提供する | Web、ファイル共有、業務アプリ |
| ピアツーピア | 端末同士が対等な立場で通信する | 小規模な直接共有 |
集中処理は管理しやすい一方、中心装置の障害が全体へ影響しやすくなります。分散処理は拡張しやすい一方、構成やデータ整合性の管理が複雑になります。
2. 利用形態を業務のタイミングで選ぶ
| 利用形態 | 内容 | 例 |
|---|---|---|
| 対話型処理 | 利用者の入力に応じて処理し、結果を返す | 予約検索、在庫照会 |
| リアルタイム処理 | 発生したデータを即時に処理する | 座席予約、交通制御、決済 |
| バッチ処理 | データを一定期間ため、まとめて処理する | 給与計算、月次請求、夜間集計 |
「すぐ処理する必要があるか」「まとめて処理できるか」を問題文から読み取ります。大量データだから必ずバッチ処理、少量だから必ずリアルタイム処理とは限りません。
3. 信頼性と可用性を数値で判断する
| 指標 | 意味 | 良い状態 |
|---|---|---|
| MTBF | 平均故障間動作時間 | 長いほど故障しにくい |
| MTTR | 平均修復時間 | 短いほど復旧が速い |
| 稼働率 | 利用可能な時間の割合 | 高いほど止まりにくい |
| レスポンスタイム | 要求してから応答するまでの時間 | 短いほど応答が速い |
| TCO | 導入から廃棄までの総費用 | 初期費用と運用費用を合計して比較する |
稼働率は次の式で求めます。
稼働率＝MTBF÷（MTBF＋MTTR）
MTBFが990時間、MTTRが10時間なら、稼働率は990÷1,000＝0.99、つまり99％です。故障回数を減らすだけでなく、修復時間を短くしても稼働率は上がります。
4. 障害に備える構成
| 構成・考え方 | 内容 | 判断のポイント |
|---|---|---|
| デュアルシステム | 2系統が同じ処理を行い、結果を照合する | 高い信頼性が必要だが費用も大きい |
| デュプレックスシステム | 主系と待機系を用意し、障害時に切り替える | ホット・コールドなど待機方式がある |
| クラスタ | 複数のサーバを連携させ、処理や障害対応を分担する | 負荷分散や可用性向上に使う |
| RAID | 複数ディスクを組み合わせて性能や耐障害性を高める | RAIDはバックアップそのものではない |
| レプリケーション | データを複数の場所へ複製する | 障害時の継続や参照負荷分散に使う |
信頼性設計の考え方も区別します。
- フォールトトレラント：障害が発生しても処理を継続できるようにする。
- フェールセーフ：障害時に安全側へ移行する。
- フェールソフト：一部機能を停止してでも重要機能を継続する。
- フールプルーフ：誤操作しても危険や重大障害が起きにくくする。
完全ケース：オンライン注文システムを止めない
24時間注文を受け付けるECサイトで、1台のWebサーバだけを使っているとします。このサーバが故障すると、全ての注文受付が停止します。
改善案は次のとおりです。
- Webサーバを複数台にし、負荷分散装置で要求を振り分ける。
- データベースは待機系を用意し、障害時に切り替えられるようにする。
- 商品画像や静的データは複数拠点へ複製する。
- 監視と自動切替えを設定し、復旧手順を定期的に試験する。
- 冗長化とは別にバックアップを取得する。
サーバを2台置くだけでは十分ではありません。両方が同じ電源、同じ通信回線、同じ建物に依存していれば、共通原因で同時に停止する可能性があります。
5. 仮想化とクラウドを区別する
| 用語 | 内容 | 利用者が管理する範囲の例 |
|---|---|---|
| 仮想化 | 物理資源を論理的に分割・統合して使う技術 | VM、コンテナ、仮想デスクトップ |
| IaaS | サーバ、ストレージ、ネットワークなどの基盤を提供する | OSより上を利用者が管理することが多い |
| PaaS | アプリの開発・実行環境を提供する | アプリとデータを中心に管理する |
| SaaS | 完成したソフトウェアをサービスとして提供する | 利用設定やデータを管理する |
| オンプレミス | 自社で設備を保有・運用する | 設備からアプリまで自社管理する |
クラウドは設備を自社保有せず、必要に応じて利用しやすい点が特徴です。ただし、利用者側のアクセス権管理、データ分類、バックアップ方針まで全て事業者任せにできるわけではありません。
6. 構成を選ぶ判断手順
- 停止が許される時間を確認する：業務影響と目標復旧時間を整理します。
- 性能要件を確認する：同時利用者数、処理量、応答時間を見積もります。
- 障害の単一箇所を探す：サーバ、回線、電源、ストレージのどこに集中しているか確認します。
- 冗長化とバックアップを分けて設計する：継続運転とデータ復旧は目的が異なります。
- 初期費用と運用費用を比較する：TCOで長期的に判断します。
- 監視、切替え、復旧を試験する：構成だけでなく運用手順まで確認します。
7. よくある誤りと理由
- RAIDがあればバックアップ不要と考える：誤削除、マルウェア、災害には別のバックアップが必要です。
- クラウドなら障害対策が不要と考える：利用者側でも構成、権限、データ保護を設計します。
- 初期費用だけで比較する：保守、電力、人件費、契約費用を含むTCOで判断します。
- 待機系があれば自動で切り替わると考える：切替方式と手順を設計・試験する必要があります。
- リアルタイム処理と高速処理を同じと考える：リアルタイム処理は必要な時点までに結果を返すことが中心です。
8. セルフチェック
- 集中、分散、並列のどの処理形態か。
- 対話型、リアルタイム、バッチのどれが業務要件に合うか。
- 信頼性をMTBF、MTTR、稼働率のどれで評価するか。
- 冗長化、バックアップ、災害対策を混同していないか。
- 初期費用だけでなくTCOを比較したか。
理解を確認したら、第1章の練習問題と第1章の知識カードで構成を選んでください。個々のCPUやメモリの役割は、コンピュータ構成要素で確認できます。
公式範囲との対応
本節は、IPA「ITパスポート試験シラバス Ver.6.5」のシステムの構成とシステムの評価指標に対応し、集中・分散・並列処理、クライアントサーバ、仮想化、クラウド、冗長化、MTBF、MTTR、稼働率、TCOを扱います。