システムの構成

要点と定義

システムの構成では、処理形態や利用形態、構成要素の機能分担を、業務の応答時間や運用条件に合わせて考えます。集中処理は処理を集約する形態、分散処理は複数のコンピュータに機能を分担する形態です。バッチ処理は一定量の処理をまとめて実行します。リアルタイム処理では、要求や事象に対して定められた時間制約の中で処理を完了することが要点です。単に応答が速いことや、即時反映することと同義ではありません。

分散処理システムの障害透過性とは、構成要素に障害が起きても、利用者がその障害を意識せずにシステムを利用できる性質です。障害を管理者が把握することや、データを一か所に集めることとは別の観点です。過去の出題で扱った補足です。

信頼性設計では、故障時に安全な状態へ移すフェールセーフ、故障時にも機能を保つフォールトトレラント、誤操作を防ぐフールプルーフを区別します。安全側への移行と、冗長化による運転継続は目的が異なります。過去の出題で扱った補足です。

適用条件と例

例えば、月末の売上集計を翌朝までに仕上げればよい業務なら、対象データをまとめて処理するバッチ処理が候補になります。一方、注文確定後の在庫確認のように、要求ごとに定められた時間制約内で結果を返す必要がある業務では、リアルタイム処理が候補です。判断の軸は、処理をまとめられるか、結果をいつまでに必要とするかです。

エッジコンピューティングは、データ発生源に近い場所で処理し、遠隔との通信に伴う遅延や通信量を抑える考え方です。例えば、設備の近くで異常の一次判定を行い、集計用データは後で遠隔側へ送る構成が考えられます。即時性が必要な処理をどこに置くかを決める際の補足として、過去の出題でも扱われました。

クラウドではサービスモデルによって利用企業と提供者の管理範囲が異なります。IaaSでは利用企業が仮想マシンのゲストOSを管理しますが、ハイパーバイザは通常、提供者側の管理範囲です。PaaSやSaaSでは、提供者が管理する層がより広くなります。利用企業の具体的な設定範囲はサービスの機能にもよります。過去の出題で扱った補足です。

ライブマイグレーションは、仮想サーバ上のOSやソフトウェアを稼働させたまま、実行先の物理サーバを移す技術です。例えば、保守のために仮想サーバの稼働先を移す用途が考えられます。無停止での移行を説明する用語ですが、あらゆる条件下で停止がないと保証する意味ではありません。過去の出題で扱った補足です。

ロードバランサは複数のサーバへ要求を振り分けます。ヘルスチェックに失敗したサーバを振り分け先から外す構成が可能です。例えば、異常が検出されたサーバへの新たな要求を避け、稼働が確認されたサーバへ送ります。過去の出題で扱った補足です。

HAクラスタで本番系のハートビートが届かない場合、過去の出題では、待機系がまずネットワーク状態を確認し、次にディスクハートビートのログを調べ、その後に論理ドライブの専有権を取得します。最後に、本番系がOSへシャットダウン要求を発行し、自ら強制シャットダウンします。信号が届かない原因を確認してから共有資源の扱いを決め、停止処理へ進む判断が必要です。