変更要約: 初版
2.3システム構成と仮想化
FE/SGのクライアントサーバ・Web3層・クラスタ構成を踏まえ、仮想化の中核であるハイパーバイザ(ホスト型/ゲスト型)の仕組みと、より軽量なコンテナ(Docker等)との違いを深掘りします。さらに負荷分散の方式(ラウンドロビン/最少コネクション)、IaaS/PaaS/SaaSの責任分界、冗長構成(デュアルシステム/デュプレックスシステム)まで扱います。
システム構成の選択肢は年々増えていますが、応用情報技術者に求められるのは「名前を知っている」ことではなく、それぞれの構成がどのようなトレードオフの上に成り立っているかを実務判断として説明できることです。仮想化とコンテナ、そしてクラウドの責任分界という、現代のシステム基盤を支える判断軸を精密に整理します。
2.3.1ハイパーバイザとコンテナの違い
| 区分 | 動作の仕組み | 起動速度・オーバーヘッド | 分離の強さ |
|---|---|---|---|
| ホスト型ハイパーバイザ(Type1) | 物理ハードウェア上に直接載り各VMに個別のゲストOSを持たせる | OS起動が必要なため遅め・オーバーヘッド大 | ゲストOSごと分離されカーネルも独立し強い |
| ゲスト型ハイパーバイザ(Type2) | 既存のホストOS上でアプリケーションとして動作しVMを提供 | ホストOS経由のためさらにオーバーヘッド大 | ホスト型と同様にゲストOSごと分離 |
| コンテナ | ホストのOSカーネルを共有しプロセスとして分離実行 | OS起動が不要で高速・オーバーヘッド小 | カーネルを共有するためVMよりは分離が弱い |
- ハイパーバイザ=物理ハードウェアの資源を複数の仮想マシン(VM)へ分割・割り当てる制御ソフトウェア。物理ハードウェア上に直接載るホスト型(Type1)は、既存のOSを経由しない分オーバーヘッドが小さく、サーバ用途で主流です。既存のOS上でアプリケーションのように動くゲスト型(Type2)は導入が手軽な反面、ホストOSを経由する分オーバーヘッドが大きくなります。
- コンテナ(例:Docker)は、ホストのOSカーネルを共有しながらプロセス単位でアプリケーションとその依存関係を分離実行する技術です。個別のゲストOSを起動する必要がないため、VMに比べて起動が数秒〜数百ミリ秒と高速で、消費するメモリ・ストレージも小さく済みます。ただしカーネルを共有する構造上、VMほど強固な分離ではない(カーネルの脆弱性が全コンテナへ波及しうる)という点はトレードオフとして押さえておく必要があります。
2.3.2負荷分散方式とクラウドの責任分界
- 負荷分散(ロードバランシング)の代表的な方式には、各サーバへ順番にリクエストを割り振るラウンドロビン方式(単純だが各サーバの負荷状況を考慮しない)と、その時点で処理中の接続数が最も少ないサーバへ優先的に割り振る最少コネクション方式(各サーバの実際の負荷を反映しやすい)があります。処理時間がリクエストごとに大きくばらつく場合は、単純なラウンドロビンより最少コネクション方式の方が偏りを抑えやすいという実務判断につながります。
- クラウドサービスのIaaS/PaaS/SaaSは、利用者と提供元のどちらが何を管理するかという責任分界点が異なります。IaaSは仮想サーバ・ネットワークなどインフラのみが提供され、OS以上(ミドルウェア・アプリケーションを含む)は利用者が管理します。PaaSはアプリケーション実行基盤(言語ランタイム・ミドルウェア)まで提供され、利用者はアプリケーションの実装・データに責任を持ちます。SaaSは業務アプリケーションが完成品として提供され、利用者は利用設定とデータ入力のみを担います。
「ホスト型(Type1)=物理ハード直接でオーバーヘッド小・ゲスト型(Type2)=既存OS上でオーバーヘッド大」「コンテナはOSカーネル共有で起動が速いがVMより分離が弱い」「負荷分散=ラウンドロビン(単純)/最少コネクション(実際の負荷反映)」「責任分界はSaaSが利用者管理範囲最小・IaaSが最大」が最頻出です。デュアルシステム(2系統が独立して同一処理を行い結果を照合)とデュプレックスシステム(主系+待機系の構成)の違いも定番です。
冗長構成の選択を、実務のシナリオで考えてみましょう。ある基幹システムで「絶対に誤った計算結果を出してはならない」という極めて高い信頼性が求められる場合、2系統の処理系が同一の入力に対し独立に同一処理を行い、結果を突き合わせて一致を確認するデュアルシステムが候補になります。処理結果そのものの正しさを相互検証できる反面、常に2系統を並行稼働させるためコストは高くなります。一方、多くの業務システムでは「片方が故障してもすぐに処理を引き継げれば十分」という要件で足りるため、普段は主系(現用系)のみが処理を行い、故障時に待機系(予備系)へ切り替えるデュプレックスシステムが採用されます。デュプレックスシステムはさらに、待機系が主系と同じ状態を常に保ちながら電源も入れて待つホットスタンバイ(切替が最速)、待機系のプログラムは起動済みだがデータの同期は都度行うウォームスタンバイ、待機系は電源すら入れず必要になってから起動するコールドスタンバイ(コストは最小だが切替に最も時間がかかる)に分かれ、復旧速度とコストのどちらを優先するかで選び分けます。同様の判断軸はクラウド活用にも当てはまります。基幹業務のデータベースのように独自のチューニングやミドルウェア構成を細かく制御したい場合はIaaS上に自前で構築し、開発チームがインフラ管理から解放されアプリケーション開発に集中したい場合はPaaS(例:マネージドなアプリケーション実行基盤やデータベースサービス)を選び、勤怠管理や会計処理のような業界標準的な業務であれば自社開発をせずSaaSを利用する、というように、独自性が必要な範囲だけを自社管理に残し、それ以外は提供元へ委ねるのが合理的な判断です。
ひっかけ: 「コンテナは独立したゲストOSを持つためVMと分離の強さは同等である」は誤りです。コンテナはホストのOSカーネルを共有するため、ゲストOSを個別に持つVMより分離は弱くなります。また「ホットスタンバイは待機系の電源を入れず必要時に起動する方式である」も誤り=それはコールドスタンバイの説明で、ホットスタンバイは待機系を常時稼働させ主系と同じ状態を保つ方式です。「PaaSではOSやミドルウェアの管理も利用者の責任範囲に含まれる」も誤り=PaaSではOS・ミドルウェアは提供元が管理し、利用者はアプリケーションとデータのみに責任を持つのが原則です(それを含めて利用者管理とするのはIaaS)。
2.3.3この節のまとめ
- ハイパーバイザはホスト型(Type1・低オーバーヘッド)/ゲスト型(Type2・高オーバーヘッド)。コンテナはOSカーネル共有で高速起動だがVMより分離弱い
- 負荷分散=ラウンドロビン(単純)/最少コネクション(実負荷反映)。IaaS/PaaS/SaaSは責任分界点が異なり、管理範囲は狭い順にSaaS<PaaS<IaaS
- デュアルシステム=2系統で相互検証(高コスト・高信頼性)。デュプレックスシステム=主系+待機系(ホット/ウォーム/コールドスタンバイで復旧速度とコストがトレードオフ)
進捗の記録にはログインが必要です。
理解度チェック
(軽い確認用)Q1. コンテナ型仮想化が、ホスト型ハイパーバイザによる仮想マシンと比べて起動が速く消費資源も少ない本質的な理由はどれか。
Q2. 主系が稼働中は待機系の電源を入れず、故障発生後に初めて待機系を起動する冗長構成の方式はどれか。復旧の速さよりもコストを重視する場合に選ばれる。
Q3. クラウドサービスのうち、アプリケーションの実行基盤(言語ランタイムやミドルウェア)まで提供元が管理し、利用者はアプリケーションの実装とデータにのみ責任を持つ形態はどれか。

