システム構成要素

コンピュータシステムは、1台のマシンだけで動くものから、複数のマシンが協調して動くものまで様々な形態があります。たとえば、皆さんが日常的に使っている Web サービス（SNS やネットショッピング）は、裏側で多数のサーバが連携して動いています。

このセクションでは、システムの 処理形態 （集中処理と分散処理）から始め、代表的なシステム構成である クライアントサーバシステム 、 Web システム 、 ピアツーピア を学びます。さらに、現代の IT インフラに不可欠な 仮想化技術 と クラウドコンピューティング 、そしてシステムを止めないための 冗長化構成 と 負荷分散 まで体系的にカバーします。

クライアントサーバシステム（C/S）

サービスを要求する側（ クライアント ）と、サービスを提供する側（ サーバ ）に役割を分けたシステム構成です。

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

クライアント（プレゼンテーション層 + ビジネスロジック層）とサーバ（データ層）の2層に分かれます。クライアント側にアプリケーションをインストールして使う形態で、業務用の社内システムなどで使われてきました。

• 利点: サーバの負荷が軽い
• 欠点: クライアントへのソフト配布・更新が大変（ ファットクライアント ）

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

処理を プレゼンテーション層 ・ ファンクション層（アプリケーション層） ・ データ層 の3層に分離します。

層	役割	担当
プレゼンテーション層	ユーザーインターフェース（画面表示・入力受付）	クライアント（ブラウザ等）
ファンクション層	ビジネスロジック（業務処理）	アプリケーションサーバ
データ層	データの永続化（保存・検索）	データベースサーバ

3層に分けることで、ビジネスロジックの変更がクライアントに影響しない 疎結合 な設計が可能になります。現在の Web システムはほぼこの3層構成です。

Web システムの構成

Web システムは3層 C/S の代表的な実装です。ブラウザがクライアントとなるため、ソフトの配布が不要です（ シンクライアント 的な利点）。

サーバ	主な役割	代表的なソフトウェア
Web サーバ	HTTP リクエストの受付、静的ファイル配信、リバースプロキシ	Nginx, Apache
AP サーバ	ビジネスロジック実行、セッション管理	Tomcat, Node.js, Rails
DB サーバ	データの永続化、トランザクション管理	PostgreSQL, MySQL, Oracle

ピアツーピア（P2P）

クライアントとサーバの区別がなく、各ノードが 対等な立場 でサービスの提供と利用を行う構成です。

• 利点: 特定のサーバに負荷が集中しない、1台が停止しても全体は継続
• 欠点: セキュリティ管理が難しい、データの一貫性確保が困難
• 利用例: ブロックチェーン、ファイル共有ソフト、ビデオ通話（WebRTC）

シンクライアント

クライアント側に最小限の機能だけを持たせ、処理の大半をサーバ側で行う方式です。「thin（薄い）クライアント」の意味で、反対に多くの処理をクライアントで行う方式を ファットクライアント と呼びます。

方式	説明
サーバベース方式	サーバ上でアプリを実行し、画面だけをクライアントに転送（VDI: Virtual Desktop Infrastructure）
ネットブート方式	OS やアプリをサーバからネットワーク経由で起動

• 利点: データがクライアントに残らない（情報漏洩対策）、ソフトの一元管理
• 欠点: ネットワーク障害時に業務停止、サーバ負荷が大きい

仮想化技術

1台の物理マシン上に複数の仮想マシンを動かしたり、逆に複数の物理マシンを1つに見せたりする技術です。

サーバ仮想化

ハイパーバイザ というソフトウェアが物理ハードウェアを抽象化し、複数の仮想マシン（VM）を実行します。

種類	特徴	例
Type 1（ベアメタル型）	ハードウェア上に直接ハイパーバイザを配置。性能が高い	VMware ESXi, Hyper-V, KVM
Type 2（ホスト型）	OS の上にハイパーバイザを配置。導入が容易	VirtualBox, VMware Workstation

コンテナ型仮想化

OS カーネルを共有し、アプリの実行環境だけを分離する軽量な仮想化方式です。VM に比べて 起動が速く 、 リソース消費が少ない のが特徴です。代表的なソフトウェアは Docker です。

クラウドコンピューティング

インターネット経由で IT リソース（サーバ、ストレージ、ソフトウェアなど）を必要なときに必要な分だけ利用するサービス形態です。自社でサーバを所有・管理する オンプレミス と対比されます。

サービスモデル

モデル	提供範囲	ユーザーが管理する範囲	例
IaaS（Infrastructure as a Service）	ハードウェア + 仮想化基盤	OS、ミドルウェア、アプリ	AWS EC2, Google Compute Engine
PaaS（Platform as a Service）	IaaS + OS + ミドルウェア	アプリケーション	Heroku, Google App Engine
SaaS（Software as a Service）	すべて	設定・データのみ	Gmail, Salesforce, Microsoft 365

身近な例で考えると、 IaaS は「土地と建物だけ借りて、内装は自分で」、 PaaS は「キッチン付きの店舗を借りて、料理だけ自分で」、 SaaS は「レストランで食事する（全部お任せ）」とイメージできます。

オンプレミスとクラウドの比較

比較項目	オンプレミス	クラウド
初期費用	高い（サーバ購入）	低い（従量課金）
運用コスト	固定（自社管理）	変動（使った分だけ）
拡張性	低い（物理増設が必要）	高い（即座にスケール）
カスタマイズ性	高い	モデルによっては制限あり
セキュリティ管理	自社で完全制御	プロバイダに依存する部分あり
災害対策	自社で構築	複数リージョンで自動対応可

システムの冗長化構成

システムを止めないために、予備の装置を用意する構成を 冗長化 と呼びます。

デュアルシステム

2系統のシステムが 同時に同じ処理 を実行し、結果を照合（クロスチェック）します。一方に障害が発生しても、もう一方がそのまま処理を継続できます。

• 利点: 切り替え時間ゼロ（即座に継続）、結果照合で信頼性が高い
• 欠点: コストが2倍、通常時もリソースをフル稼働

デュプレックスシステム

主系（現用系） と 従系（待機系） に分け、通常は主系だけが本番処理を行います。主系に障害が発生したら従系に切り替えます。

方式	待機系の状態	切り替え時間	コスト
ホットスタンバイ	起動済み・データ同期済み	短い（秒〜分）	高い
ウォームスタンバイ	起動済み・一部同期	やや長い	中程度
コールドスタンバイ	停止状態	長い（分〜時間）	低い

負荷分散とクラスタリング

ロードバランサ（負荷分散装置）

複数のサーバにリクエストを振り分けて負荷を均等化する装置（またはソフトウェア）です。Web システムでアクセスが集中する場合に不可欠です。

主な振り分け方式:

• ラウンドロビン: 順番に振り分け
• 最小接続数: 接続数が最も少ないサーバに振り分け
• 重み付け: サーバの性能に応じて振り分け比率を設定

クラスタリング

複数のサーバを1つのシステムとして束ねる技術です。目的によって2種類に分かれます。

種類	目的	説明
HA クラスタ（高可用性）	可用性向上	障害時に別ノードが処理を引き継ぐ（フェイルオーバー）
HPC クラスタ（高性能計算）	性能向上	複数ノードで並列計算して処理能力を高める

スケーリング方式として、サーバ1台の性能を上げる スケールアップ と、サーバの台数を増やす スケールアウト があります。クラウド環境ではスケールアウトが主流です。

どんなに高性能なシステムでも、故障やトラブルが起きれば価値がありません。たとえば銀行のATMが頻繁に停止したら、利用者は困るだけでなく銀行への信頼も失われます。

システムの信頼性を定量的に評価する指標が RASIS です。さらに、信頼性を高めるための設計思想として フォールトトレラント 、 フェールセーフ などの考え方があります。このセクションでは、FE試験で頻出の 稼働率計算 も複数パターンで練習します。

RASIS

システムの信頼性を5つの観点で評価する指標です。それぞれの頭文字を取って RASIS （レイシス）と呼びます。

指標	英語	意味	測定の観点
R	Reliability（信頼性）	故障しにくさ	MTBF が長いほど高い
A	Availability（可用性）	使いたいときに使えるか	稼働率が高いほど高い
S	Serviceability（保守性）	修理のしやすさ	MTTR が短いほど高い
I	Integrity（保全性）	データの完全性・一貫性	データが壊れない・矛盾しない
S	Security（安全性）	不正アクセスからの保護	認証・暗号化等の対策

FE試験では特に R（信頼性） ・ A（可用性） ・ S（保守性） の3つが計算問題として出題されます。

MTBF・MTTR と稼働率

MTBF（Mean Time Between Failures: 平均故障間隔）

システムが正常に稼働し続ける平均時間です。長いほど信頼性が高い ことを意味します。

MTTR（Mean Time To Repair: 平均修復時間）

故障が発生してから復旧するまでの平均時間です。短いほど保守性が高い ことを意味します。

稼働率

システムが利用可能な時間の割合です。

稼働率 = MTBF / (MTBF + MTTR)

計算例:

• MTBF = 950時間、MTTR = 50時間のとき
• 稼働率 = 950 / (950 + 50) = 950 / 1000 = 0.95（95%）

稼働率は 0 から 1 の値を取り、1 に近いほど可用性が高いシステムです。金融系や医療系のシステムでは 99.99%（フォーナイン） 以上が求められることもあります。

稼働率	年間停止時間の目安
99%（ツーナイン）	約3.65日
99.9%（スリーナイン）	約8.76時間
99.99%（フォーナイン）	約52.6分
99.999%（ファイブナイン）	約5.26分

直列システムと並列システムの稼働率

複数の装置を組み合わせたシステム全体の稼働率を求める問題は FE 試験の定番です。

直列システム

すべての装置が動いていないとシステム全体が停止する構成です。どれか1つでも故障すると全体が止まります。

全体の稼働率 = 各装置の稼働率の積

装置 A（稼働率 0.9）と装置 B（稼働率 0.8）が直列の場合:

• 全体 = 0.9 × 0.8 = 0.72

直列に装置を増やすほど全体の稼働率は 下がり ます。

並列システム

少なくとも1つの装置が動いていればシステム全体が稼働する構成です。

全体の稼働率 = 1 - (各装置の故障率の積)

故障率 = 1 - 稼働率 なので、装置 A（稼働率 0.9）と装置 B（稼働率 0.9）が並列の場合:

• 全体 = 1 - (1 - 0.9) × (1 - 0.9) = 1 - 0.1 × 0.1 = 1 - 0.01 = 0.99

並列に装置を増やすほど全体の稼働率は 上がり ます。

複合システムの稼働率計算

実際の試験では、直列と並列を組み合わせた複合システムの稼働率が問われます。解法は 内側の並列部分から先に計算し、次に直列として掛け合わせる ことです。

例題: 以下のシステムの稼働率を求めよ（各装置の稼働率は 0.9）

構成: 装置 A と「装置 B と装置 C の並列」が直列に接続

ステップ1: 並列部分（B と C）の稼働率を計算

• 並列 = 1 - (1 - 0.9) × (1 - 0.9) = 1 - 0.01 = 0.99

ステップ2: 直列として掛け合わせる

• 全体 = A × 並列(B,C) = 0.9 × 0.99 = 0.891

---

応用例題: 2つの並列ペアが直列に接続（各装置の稼働率 0.8）

構成: [装置A, 装置B の並列] → [装置C, 装置D の並列]

ステップ1: 各並列部分の稼働率

• 並列1(A,B) = 1 - (1 - 0.8)² = 1 - 0.04 = 0.96
• 並列2(C,D) = 1 - (1 - 0.8)² = 1 - 0.04 = 0.96

ステップ2: 直列として掛け合わせる

• 全体 = 0.96 × 0.96 = 0.9216

計算のコツ: まず図を描いて並列部分を四角で囲み、内側から順番に計算すると間違いが減ります。

障害対策の設計思想

故障が起きることを前提に、被害を最小化するための設計思想が試験で問われます。

設計思想	考え方	具体例
フォールトトレラント	故障が起きても 正常動作を継続 する	デュアルシステム、RAID、ECC メモリ
フェールセーフ	故障時に 安全側に倒す	信号機の故障→赤になる、踏切の故障→遮断機が下りる
フェールソフト	故障時に 性能を落として稼働を継続 する	CPU1つ故障→残りのCPUで処理継続（縮退運転）
フールプルーフ	人間が 誤操作しても問題が起きない 設計	電子レンジのドアを開けると停止、USB端子は逆挿し不可

これらは排他的ではなく、1つのシステムに複数の思想を組み合わせて適用します。日常生活の例で覚えると区別しやすいです。

• フェールセーフ と フェールソフト の違い: セーフは「止める」方向、ソフトは「機能を減らしても動かす」方向
• フールプルーフ は「障害対策」ではなく「人間の操作ミス対策」

バックアップの種類

システムの障害やデータ破損に備えて、データを複製して保管することを バックアップ と呼びます。

種類	対象データ	所要時間	復旧時間
フルバックアップ	全データ	長い	短い（最新のフルだけで復旧）
差分バックアップ	前回のフルバックアップ以降の変更分	中程度	中程度（フル＋最新の差分）
増分バックアップ	前回のバックアップ（種類問わず）以降の変更分	短い	長い（フル＋全ての増分を順に適用）

バックアップ容量の計算例:

フルバックアップのデータ量が 100GB、1日あたりの変更量が 10GB の場合（月曜にフル実施、火〜金は日次バックアップ）:

方式	火	水	木	金	合計（火〜金）
毎日フル	100	100	100	100	400GB
差分	10	20	30	40	100GB
増分	10	10	10	10	40GB

増分バックアップはバックアップ時間・容量が最小ですが、復旧時はフル＋火＋水＋木＋金の全てを順に適用する必要があり、復旧時間が最長になります。運用ではこのトレードオフを考慮して方式を選択します。

システムがどれだけ速く処理できるか、どれだけ多くのリクエストをさばけるかを評価するのが 性能評価 です。日常の例でいえば、レストランの「1時間に何組のお客さんを捌けるか（スループット）」や「注文してから料理が届くまでの時間（レスポンスタイム）」に相当します。

FE試験では、性能に関する用語の理解に加え、処理時間やスループットの 計算問題 が出題されます。

性能評価の基本指標

指標	定義	ポイント
スループット	単位時間あたりの処理件数	システム全体の処理能力を示す
レスポンスタイム（応答時間）	リクエスト送信から最初の応答が返るまでの時間	ユーザーが体感する速さ
ターンアラウンドタイム	処理依頼から全ての結果を受け取るまでの時間	レスポンスタイム + 結果出力時間

レスポンスタイムとターンアラウンドタイムの違いに注意してください。レスポンスタイムは「最初の応答まで」、ターンアラウンドタイムは「すべての結果が揃うまで」です。大量のデータを返す処理では、この差が大きくなります。

関連する性能指標

指標	説明
CPU 使用率	CPU がどれだけ忙しいか。100% に近いとボトルネック
メモリ使用率	物理メモリの使用割合。不足するとスワップが発生し性能低下
MIPS（Million Instructions Per Second）	CPU が1秒間に実行できる命令数（百万単位）
FLOPS（Floating-point Operations Per Second）	1秒間に実行できる浮動小数点演算数。科学技術計算の指標

ベンチマーク

標準的なテストプログラムを実行して、システムの性能を定量的に比較するための指標が ベンチマーク です。

ベンチマーク	対象	説明
SPECint	CPU（整数演算）	SPEC が策定。整数演算性能を測定
SPECfp	CPU（浮動小数点演算）	SPEC が策定。浮動小数点演算性能を測定
TPC-C	トランザクション処理	オンライントランザクション処理（OLTP）の性能を測定
TPC-H	意思決定支援（DSS）	データウェアハウスの分析クエリ性能を測定
Linpack	科学技術計算	連立方程式の求解性能。スーパーコンピュータの TOP500 ランキングに使用

ベンチマークの注意点:

• 特定のベンチマークで高いスコアが出ても、実際の業務処理で同様の性能が出るとは限らない
• 異なる種類のベンチマークの数値を直接比較しても意味がない
• 実際の業務に近いワークロードでテストすることが重要

キャパシティプランニング

将来のシステム需要を予測し、必要なリソース（CPU、メモリ、ストレージ、ネットワーク帯域等）を計画的に準備することを キャパシティプランニング と呼びます。

キャパシティプランニングの手順

1. 現状把握: 現在のリソース使用状況を監視・記録
2. 需要予測: 業務の成長率やイベント等を考慮して将来の負荷を予測
3. ボトルネック特定: 最も制約となるリソースを見つける
4. 対策計画: スケールアップ/スケールアウト、チューニング等の対策を計画
5. 検証: 負荷テストで計画の妥当性を確認

システムの監視とチューニング

システムを安定稼働させるには、性能指標を継続的に 監視（モニタリング） し、問題があれば チューニング（最適化） を行います。

監視対象	具体的な指標
CPU	使用率、コンテキストスイッチ数
メモリ	使用率、スワップ発生頻度
ディスク	I/O 待ち時間、使用率
ネットワーク	帯域使用率、パケットロス率
アプリケーション	レスポンスタイム、エラー率

チューニングの代表的手法:

• ボトルネック解消: 最も遅い部分のリソースを増強
• キャッシュ活用: 頻繁にアクセスするデータをメモリに保持
• SQL 最適化: データベースのクエリを効率化（インデックス追加等）
• 負荷分散: リクエストを複数サーバに分散

性能に関する計算問題

FE試験では、処理時間やスループットの計算が出題されます。基本的な考え方を押さえましょう。

例題1: MIPS から処理時間を求める

問題: 100 MIPS の CPU で 5000万命令のプログラムを実行すると何秒かかるか？

解答:

• 100 MIPS = 1秒間に 1億命令（100 × 10⁶）を実行
• 5000万命令 / 1億命令毎秒 = 0.5秒

例題2: スループットの計算

問題: あるシステムは1件の処理に平均 20ミリ秒かかる。このシステムのスループット（件/秒）はいくらか？

解答:

• 1件あたり 20ms = 0.02秒
• スループット = 1 / 0.02 = 50件/秒

例題3: 複数装置がある場合の処理時間

問題: ある処理は CPU 処理（30ms）→ ディスク I/O（50ms）→ CPU 処理（20ms）の順で実行される。この処理を連続して3件実行した場合の最短処理時間はいくらか？（CPU とディスクは並列動作可能）

解答:

CPU とディスクが並列動作できるため、パイプライン的に処理を重ねられます。

時間(ms)	0-30	30-50	50-80	80-100	100-130	130-150
CPU	処理1前半		処理1後半		処理2後半
ディスク		処理1 I/O		処理2 I/O		処理3 I/O

※ 実際には各処理のCPU前半→ディスクI/O→CPU後半が順序依存するため、パイプラインで重ねて計算します。

• 1件目: 30 + 50 + 20 = 100ms
• 2件目以降は、前の処理のディスク I/O 中に次の CPU 前半を開始できる
• 2件目の追加時間: max(50, 30) + 20 = 50 + 20 = 70ms（ディスクI/O待ちの間にCPU処理を実行）
• 3件目も同様: 70ms
• 合計 = 100 + 70 + 70 = 240ms

このように、装置間の並列動作を活用して処理時間を短縮する考え方が重要です。

待ち行列理論（M/M/1モデル）

システムにリクエストが到着して処理を待つ状況を数学的に分析するのが 待ち行列理論 です。FE試験では M/M/1 モデル （到着がポアソン分布、処理時間が指数分布、窓口1つ）が出題されます。

基本指標:

• 到着率 λ（ラムダ）: 単位時間あたりの平均到着件数
• サービス率 μ（ミュー）: 単位時間あたりの平均処理件数
• 利用率 ρ（ロー） = λ / μ（ρ < 1 でないとキューが無限に伸びる）

主な公式（M/M/1）:

• 平均待ち時間 Wq = ρ / (μ × (1 - ρ))
• 平均応答時間 W = 1 / (μ × (1 - ρ))
• 平均待ち行列長 Lq = ρ² / (1 - ρ)

計算例:

• 到着率 λ = 4件/秒、サービス率 μ = 5件/秒
• 利用率 ρ = 4/5 = 0.8
• 平均待ち時間 Wq = 0.8 / (5 × 0.2) = 0.8秒
• 平均応答時間 W = 1 / (5 × 0.2) = 1.0秒

利用率が1に近づくと待ち時間が急増します。利用率 0.8 で平均待ち時間は処理時間の4倍になります。この性質から、サーバの利用率は 70〜80% 程度に抑えるのが一般的な目安です。