システム構成要素 ― 構成方式・性能・信頼性

システムの処理形態と構成方式

システム構成の話は「処理をどこに置くか（機能配分）」に尽きます。1 か所に集めるのが集中処理システム、複数のコンピュータに分けるのが分散処理システムです。どちらが優れているという話ではなく、コスト性能比・管理責任・障害の波及範囲のどれを優先するかで選びます。

分散処理では、利用者や応用プログラムに「どこで処理されているか」を意識させないことが設計目標になります。資源の物理的な位置を知らなくても同じ手続きで使える性質をアクセス透過性と呼び、位置・複製・障害などの透過性とあわせて分散システムの品質を測ります。機能配分を決めるときは、応答速度（手元で処理するほど速い）、管理責任（サーバに集めるほど統制しやすい）、通信量（データの近くで処理するほど減る）の 3 つを天秤にかけます。

利用形態では、一定量をためて一括処理するバッチ処理、事象の発生に即応するリアルタイム処理、人の応答を待ちながら進める対話型処理を区別します。夜間の締め処理はバッチ、在庫引当や決済はリアルタイム、というように業務要件（許容できる遅れ）で決まります。

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

クライアントサーバシステムは、機能をプレゼンテーション層（画面表示・入力）・ファンクション層（業務処理）・データベースアクセス層（データ操作）に分けて配置します。クライアントに画面と業務処理を置き、サーバに DB だけを置くのが 2 層、業務処理を独立したサーバへ出すのが 3 層です。3 層にすると業務ロジックの改修がサーバ側だけで済み、クライアントの配布が要らなくなります。

Web システムは層ごとに使うプロトコルが違います。ブラウザと Web サーバの間は HTTP／HTTPS、Web サーバと AP サーバの間はアプリケーション固有の呼出し、AP サーバと DB サーバの間は SQL です。HTTP は 1 回のやり取りが独立したステートレスなプロトコルなので、ログイン状態のような「続き」はセッション ID で結び付けます。ロードバランサで複数台へ振り分けるとき、このセッション情報をサーバ間で共有していないと、振り分け先が変わった瞬間にログイン状態が失われます。同じ利用者を同じサーバへ送り続けるか、セッションを外部の共有領域に置くかを設計で決めておく必要があります。

ハイパフォーマンスコンピューティングとグリッド

科学技術計算のように高精度な高速演算が要る分野では HPC（High Performance Computing）が使われます。実現手段は 2 つで、1 台のスーパーコンピュータに大規模並列のプロセッサやアレイプロセッサ（同じ演算を多数のデータへ一斉に適用する構成）を積む方法と、LAN で結んだ多数のコンピュータの CPU 資源を束ねて 1 台の高性能機のように見せるグリッドコンピューティングです。後者は遊休資源を使えるのが利点で、専用機を買わずに演算能力を得たいときに検討します。

冗長構成とクラスタ ― 止めないための並べ方

冗長構成は「同じ働きをする装置を 2 つ以上用意して、片方が壊れても続ける」ための構成です。試験では名前と挙動の対応がそのまま問われるので、2 台を同時に動かすのか（デュアル）、片方は待たせるのか（デュプレックス）という軸で整理します。

マルチプロセッサシステムでは、主記憶を共有するかどうかで密結合（共有する）と疎結合（各プロセッサが自分の主記憶と OS を持つ）に分かれます。データベースを複数ノードで扱うときの同じ対比がシェアードエブリシング（ディスクも主記憶も共有）とシェアードナッシング（何も共有せずデータを分割保持）で、後者は競合制御が軽く台数を増やしやすい代わりに、データ配置の設計が難しくなります。役割を固定せず対等なノードが相互に資源を提供し合う形はピアツーピアです。

クラスタは目的で 2 種類に分かれます。HA クラスタ（高可用性クラスタ）は待機系を用意して可用性を上げる構成で、障害時に待機系へ切り替えることをフェールオーバ、復旧した元の系へ戻すことをフェールバックと呼びます。負荷分散クラスタは同じ役割のノードを並べて処理能力を上げる構成で、1 ノードが落ちても残りのノードで処理を続けられるため、結果としてフェールソフトになります。前者はアクティブ-スタンバイ、後者はアクティブ-アクティブの構成が基本です。

災害対策では拠点そのものを冗長化します。切替先に用意する予備拠点をバックアップサイトと呼び、待機のさせ方で 3 種類に分かれます。設備・機器・データを常時同期して即座に切り替えられるのがホットサイト、機器は用意してあるがデータ復元と起動が要るのがウォームサイト、場所と回線だけ確保しておくのがコールドサイトです。復旧目標時間（RTO）が短いほど上のものが要り、費用も上がります。

信頼性設計の考え方と RASIS

信頼性設計には出発点が 2 つあります。フォールトアボイダンスは「そもそも故障させない」方向で、高品質な部品を選び、予防保守をし、テストを厚くします。フォールトトレランスは「故障は起きる前提で、起きても機能を保つ」方向で、多重化や縮退運転で対応します。試験の定番問題はこの 2 語と、トレランス側の具体策 2 語（フェールセーフ・フェールソフト）、それに人の誤操作を無害化するフールプルーフを加えた 5 語の説明を入れ替えたものです。フールプルーフは装置の故障ではなくヒューマンエラーへの対策なので、アボイダンス側（そもそも起こさせない側）に置いて整理します。

可用性を高める手段は、壊れにくくする（MTBF を伸ばす）、早く直す（MTTR を縮める）、冗長化して系として止めない、の 3 通りしかありません。施策の当否で迷ったら、それがこの 3 つのどれに効くのかを言い直すと整理できます。監視の強化は MTTR 側、部品の定期交換は MTBF 側、待機系の追加は冗長化です。

システム全体の評価軸としては RASIS を押さえます。頭文字は Reliability（信頼性、壊れにくさ）・Availability（可用性、使える割合）・Serviceability（保守性、直しやすさ）・Integrity（完全性、データが壊れないこと）・Security（安全性、不正から守られていること）です。MTBF は R、稼働率は A、MTTR は S に対応すると考えると、次節の指標が RASIS のどこを測っているかが見えます。

稼働率の計算 ― MTBF・MTTR と直列・並列

この節が中分類 4 の最重要ポイントです。直近 10 年で稼働率の計算が 10 問、MTBF・MTTR の関係が 8 問出ており、合わせて 18 問はこの中分類の 76 問の約 4 分の 1 に当たります。まず 2 つの平均値から確認します。

• MTBF（Mean Time Between Failures、平均故障間動作時間）＝ 故障と故障の間に「動いていた」時間の平均。大きいほど壊れにくい
• MTTR（Mean Time To Repair、平均修理時間）＝ 故障してから復旧するまでの時間の平均。小さいほど直しやすい

観測データしか与えられないこともあります。「2,000 時間の運用で 4 回故障し、修理に合計 40 時間かかった」なら、動作していたのは 2,000 - 40 ＝ 1,960 時間なので MTBF ＝ 1,960 ÷ 4 ＝ 490 時間、MTTR ＝ 40 ÷ 4 ＝ 10 時間、稼働率 ＝ 490 ÷（490 ＋ 10）＝ 0.98 です。MTBF は「動作していた時間」の平均なので、運用時間からまず修理時間を引く点に注意します。

MTTR を短くする施策と MTBF を長くする施策は別物です。障害箇所の特定を速くするエラーログの取得機能や、保守部品の現地常備、遠隔保守は MTTR 側の対策です。一方、高品質部品の採用・予防保守・冗長化は MTBF 側（あるいは系全体の稼働率）の対策で、MTTR は縮みません。装置の故障率は時間とともに変化し、初期故障期は下がり、偶発故障期はほぼ一定、摩耗故障期は上がるという U 字（バスタブ曲線）を描きます。

直列システムと並列システム

複数の装置からなる系の稼働率は、信頼性ブロック図が直列か並列かで式が変わります。直列は「全部動いていないと動かない」、並列は「どれか 1 つ動いていれば動く」です。

グラフで問われることもあります。横軸に 1 台あたりの稼働率、縦軸に系全体の稼働率を取ると、直列は原点側にたわむ下に凸の曲線、並列は左上に張り出す上に凸の曲線になり、両者は 1 台あたりの稼働率が 0 と 1 のときだけ一致します。選択肢は交点の位置と曲がる向きで作り分けられるので、「並列は必ず 1 台の稼働率より高くなる」「直列は必ず 1 台の稼働率より低くなる」の 2 点で消去できます。

冗長構成の稼働率を実務的に見積もるときは、切替に要する時間も停止時間として数えます。ホットスタンバイでも切替が完了するまでサービスは止まっているので、フェールオーバ時間が長いほど稼働率は下がります。SLA（Service Level Agreement、サービス品質の合意）を稼働率で示す場合、月間の総時間に（1 - 稼働率）を掛けたものが許容停止時間になります（30 日 ＝ 43,200 分なら、稼働率 99.9% で 43.2 分）。

性能指標と性能計算

性能は「1 件がどれだけ速く終わるか」と「単位時間に何件さばけるか」の 2 面で測ります。前者が応答時間系、後者がスループットです。

2 つの時間指標は測る区間が違います。利用者が入力を終えてから最初の応答が返り始めるまでがレスポンスタイム、ジョブを投入してからすべての結果を受け取り終えるまでがターンアラウンドタイムです。同じ処理でも、印刷や帳票出力の時間を含むターンアラウンドタイムのほうが必ず長くなります。オンライン処理の善し悪しを語るときはレスポンスタイム、バッチの締め処理が朝までに終わるかを語るときはターンアラウンドタイムを使います。

ボトルネックとパイプライン処理

複数の資源を順に通る処理では、系全体のスループットは最も能力の低い箇所（ボトルネック）で決まります。合計でも平均でもありません。

いっぽう、読取り・演算・書込みのように別々の装置が担当する工程は、重ねて動かせます（パイプライン処理）。このとき 1 件の所要時間は工程時間の合計のままですが、単位時間あたりの処理件数は最も長い工程だけで決まります。

キャパシティプランニングとシステムの経済性

キャパシティプランニングは、業務量の予測から必要な性能諸元（CPU・メモリ・ディスク・回線）を見積もり、稼働後も実測を続けて「将来にわたって応答時間の要求を満たし続ける」ための活動です。目的を「障害からの復旧」や「コスト削減」と取り違えた肢が誤答になります。手順は次の 4 段階で押さえます。

1. 性能要件を数値で決める（応答時間 2 秒以内、ピーク 200 件/秒 など）
2. 業務量を予測し、サイジングで必要な資源量を算出する
3. 資源を用意する（プロビジョニング）。クラウドなら自動化できる
4. モニタリングで使用率と応答時間を継続測定し、閾値を超える前に増強する（容量・能力管理）

増強の方向は 2 つあります。1 台の性能を上げるのがスケールアップ、台数を増やすのがスケールアウトです。逆方向はそれぞれスケールダウン、スケールインと呼び、需要が減った時間帯に台数を減らしてコストを最適化します。

資源を増やすときは、システムパラメータ（同時接続数、バッファ数、多重度など）の見直しも合わせて行います。ハードウェアを足しても上限値が古いままだと性能が出ないためです。

経済性の評価 ― TCO

導入判断は購入価格だけでは決められません。初期コスト（イニシャルコスト: ハードウェア・ソフトウェア購入費、開発費、初期設定費）と運用コスト（ランニングコスト: 保守料、電気代、回線費、運用要員の人件費、教育費）を合計したTCO（Total Cost of Ownership、総所有費用）で比較します。TCO には、機器費のように対象が明確な直接コストだけでなく、利用者が自分で調べて解決する時間などの間接コストも含めて考えます。集中処理から分散処理へ移すと初期コストは下がっても、拠点ごとの運用要員が増えて TCO が上がることがある、というのが典型的な論点です。

仮想化とクラウド

1 台の物理サーバの上に複数の実行環境を作る技術が仮想化です。台数を減らして機器と電力を節約するサーバコンソリデーション（サーバ統合）が主な動機で、実装方式は 3 つあります。直近 10 年ではコンテナ型が 3 回、ライブマイグレーションが 2 回、IaC が 2 回出ており、この分野の出題は概念から運用寄りへ移っています。

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

クラウドは「どこまでを事業者が持つか」で 4 段階に整理します。境目は利用者が管理する範囲で、ここが責任分界点になります。

オンプレミスとクラウドの違いは、機能そのものよりも費用の出方と調達の速さに表れます。オンプレミスはピークに合わせた設備を先に購入するため初期コストが大きく、遊休が出ます。クラウドは使った分を払う形なので初期コストが小さく、運用コストが業務量に連動します。逆に、ほぼ一定の負荷を長期間動かし続ける用途ではオンプレミスのほうが TCO で有利になることもあります。「クラウドは常に安い」ではなく、負荷の変動幅と利用期間で判断します。

配置の形では、事業者の共用基盤を使うパブリッククラウド、自社専用に構築するプライベートクラウド、両者や社内システムを組み合わせるハイブリッドクラウド、複数事業者のサービスを併用するマルチクラウドがあります。マルチクラウドは特定事業者への依存（ロックイン）を避け、障害の影響範囲を分ける狙いで採られます。

処理をどこで行うかという観点では、端末に近い場所で先に処理するエッジコンピューティング、端末とクラウドの中間層に処理を置くフォグコンピューティングがあります。カメラ映像をその場で圧縮・検知してからクラウドへ送れば、回線帯域とクラウド側の処理量を同時に減らせます。IoT や動画配信の設計問題では、この「どこで削るか」が定番の論点です。

ストレージ・RAID・バックアップ

ストレージはまず「どうつなぐか」で分類します。サーバに直結するのが DAS（Direct Attached Storage）、LAN 上でファイル共有として見せるのが NAS（Network Attached Storage）、ストレージ専用のネットワークを別に敷いてブロック単位で見せるのが SAN（Storage Area Network）です。SAN は光ファイバのファイバチャネルを使う FC-SAN と、既存の IP ネットワーク上で iSCSI などを使う IP-SAN に分かれます。

選び方の目安は、複数のサーバがファイル単位で共有したいなら NAS、データベースや仮想化基盤のように OS がブロックデバイスとして扱いたいなら SAN です。SAN は業務 LAN と経路を分けられるので、バックアップの大量転送が業務通信を圧迫しません。ただし FC-SAN は専用の機器と配線が要るため、既存の IP ネットワークを流用できる IP-SAN と費用を比較して決めます。

RAID

RAID（Redundant Arrays of Inexpensive Disks）は、複数のディスクをまとめて 1 台に見せ、速度か信頼性（あるいは両方）を上げる技術です。データを分割して並列に書くストライピング、同じ内容を 2 台に書くミラーリング、誤り検出用のパリティという 3 つの部品の組合せで理解します。ストライピングで 1 台に書く単位をチャンクサイズと呼びます。

バックアップ方式

バックアップは「取る時間」と「戻す手間」がトレードオフです。3 方式の違いはどこからの変更分を取るかだけで決まります。

日曜にフル、月曜から土曜まで毎日取る運用なら、木曜に障害が起きたときの復旧は、差分方式なら「日曜のフル + 水曜の差分」の 2 本、増分方式なら「日曜のフル + 月・火・水の増分」の 4 本になります。夜間のバックアップ時間を短くしたいなら増分、復旧を速く確実にしたいなら差分、というのが判断軸です。

関連する運用として、いつの時点に戻せるかを決める世代管理（何世代分を保存するか）、ある瞬間の状態を短時間で記録するスナップショット、別のストレージや遠隔地へ継続的に複製するレプリケーションがあります。スナップショットとレプリケーションは復旧目標時点（RPO）を短くしますが、論理的な誤削除は複製先にも伝わるため、世代を持つバックアップの代わりにはなりません。

科目 B システムアーキテクチャへの橋渡し

科目 B の問 4 は、構成図と条件表を読んで四則演算と短い記述で設計判断を答える形式です。直近 19 回のうち 14 回が計算を含み、1 問あたりの小設問は平均 6.5 個。解答欄の字数は 15〜40 字が中心で、50 字以上は出ていません。題材は「中堅企業の情報システム部門が新サービスや移行を検討する」場面が定番で、直近 11 回はクラウド移行・利用形態の選定と、IoT・エッジ・動画の 2 ジャンルで 8 割強を占めます。

本章の知識がそのまま設問になる論点は次のとおりです。解き方の手順は第 24 章で扱います。

ひっかけポイント

理解度チェック（科目 A 形式）

まとめ

この章の計算は、稼働率・使用率・スループットの 3 本柱を型どおりに解けるかで得点が決まります。式を覚えるだけでなく、問題文の「どの範囲を聞かれているか」を先に確定させる癖をつけてください。次章はソフトウェアです。ここで扱った資源の割り当てを、OS がタスクとメモリのレベルでどう管理しているかを見ていきます。