変更要約: 初版
5.1仮想化とコンテナ
サーバ仮想化・ストレージ仮想化を担うハイパーバイザ（Type1/Type2）の仕組みと、OSカーネルを共有し起動が速く軽量なコンテナ（Docker）の特徴、そして多数のコンテナを自動運用するKubernetesによるオーケストレーションの判断を学びます。
システムアーキテクトは、限られた物理ハードウェアの上に複数の実行環境をどう載せるかを設計する場面に必ず直面します。1台の物理サーバに複数のOSをまるごと動かす仮想マシン方式と、1つのOSカーネルの上でアプリケーションの実行環境だけを隔離するコンテナ方式は、隔離の強さ・起動速度・リソース効率の点で明確に性質が異なり、要件に応じて使い分けが必要です。この節では両者の違いと、コンテナを大規模に運用するための仕組みを学びます。
5.1.1ハイパーバイザとサーバ/ストレージ仮想化
- ハイパーバイザ＝物理ハードウェア上で複数の仮想マシン（VM）を稼働させる制御ソフトウェア。各VMは独立したカーネルを含むOS丸ごとを持ち、CPU・メモリ・ディスクをハイパーバイザが仮想化して各VMに割り当てる。Type1（ベアメタル型）＝物理ハードウェア上に直接インストールされ、ホストOSを介さず高い性能と隔離を実現（サーバ仮想化の主流）。Type2（ホスト型）＝既存のホストOS上でアプリケーションとして動作し、導入は容易だがオーバーヘッドが大きく検証環境向き。
- ストレージ仮想化＝複数の物理ディスク装置を論理的に1つのプールとして扱い、容量拡張・スナップショット・シンプロビジョニング（実使用量に応じた動的割当）を可能にする技術。物理構成の変更をアプリケーション側から隠蔽し、可用性（冗長化）と拡張性を両立させる目的で用いる。
5.1.2コンテナ（Docker）の軽量性と移植性
- コンテナ（代表例：Docker）＝ホストOSのカーネルを共有しながら、プロセス空間・ファイルシステム・ネットワークを隔離してアプリケーションを実行する方式。VMのように独立したOSを持たないため、イメージサイズが小さく、起動が数秒未満と高速で、1台のホストにより多くの実行単位を高密度に配置できる。一方でカーネルを共有する分、VMよりOSレベルの隔離が弱い（カーネルの脆弱性が全コンテナに影響しうる）という設計上のトレードオフがある。
- コンテナは「アプリケーションとその依存関係一式をイメージとして固定化する」ため、開発環境・検証環境・本番環境で同一のイメージを動かせる＝環境差異に起因する不具合を減らし移植性を高めるという利点がある。この特性から、頻繁なデプロイやスケールアウトを繰り返すマイクロサービス構成との親和性が高い。
5.1.3Kubernetesによるオーケストレーション
- Kubernetes（K8s）＝多数のコンテナを複数ホスト（クラスタ）にまたがって自動的に配置・スケール・自己修復するオーケストレーション基盤。宣言的な設定（あるべき状態）をコントローラが常時監視し、実際の状態との差分を検知すると自動でコンテナを再起動・再配置（自己修復）する。負荷に応じたコンテナ数の自動増減（オートスケール）、ローリングアップデート（無停止での段階的更新）も担う。
- 少数の固定的なコンテナを手動運用する規模であればKubernetes導入の運用コスト（学習・クラスタ管理）が見合わないことがあり、コンテナ数・変更頻度・可用性要件の規模に応じて導入要否を判断するのがアーキテクトの役割。逆に多数のマイクロサービスを頻繁にデプロイし、障害時の自動復旧が要件となる規模では、Kubernetesのようなオーケストレーション基盤の価値が大きい。
「ハイパーバイザ＝VMごとに独立OS・Type1はベアメタルで高性能」「コンテナ＝カーネル共有で軽量/高速起動/高密度・隔離はVMより弱い」「Kubernetes＝自己修復/オートスケール/ローリングアップデートのオーケストレーション」が最頻出です。コンテナの軽量性の理由（カーネル共有）とトレードオフ（隔離の弱さ）を対で覚えましょう。
あるシステムアーキテクトが、既存のモノリシックなECサイトを分割し、注文・在庫・決済の3つのサービスへ移行するプロジェクトを担当しているとします。まず実行基盤として、従来通り各サービスを独立したVM（ハイパーバイザ上）に載せる案と、コンテナ化してオーケストレーション基盤に載せる案を比較検討しました。このプロジェクトではセール時にアクセスが急増するため注文サービスだけを数秒単位で素早くスケールアウトしたいという要件があり、VM方式は起動に数分かかるため負荷急増への追従が遅く不利と判断しました。一方コンテナは起動が高速で、この要件に適していると判断しましたが、カーネルを共有するため決済サービスのような機密性の高い処理を他サービスと同一ホストに無配慮に混在させると、コンテナ間の隔離の弱さがセキュリティリスクになりうることにも留意し、決済サービスは専用のノード群（またはネットワークセグメント）に分離して配置する設計にしました。さらに、注文・在庫・決済という3つの独立したサービスを、需要変動に応じて個別に自動スケール・自己修復させる必要があることから、単一ホストでのコンテナ手動運用ではなくKubernetesによるオーケストレーションを採用し、宣言的な設定でサービスごとに異なるスケーリングポリシーを定義しました。このように、単に「コンテナは軽いから使う」ではなく、スケール速度の要件・隔離強度の要件・運用規模（自動化の要否）の3点を突き合わせて仮想化方式とオーケストレーションの要否を判断することが、この設計における核心です。
| 方式 | 隔離の強さ | 起動速度/密度 |
|---|---|---|
| VM（ハイパーバイザ） | 強い（独立カーネル） | 遅い（分単位）/低密度 |
| コンテナ（Docker） | 弱い（カーネル共有） | 速い（秒未満）/高密度 |
| コンテナ＋Kubernetes | 弱い（配置分離で緩和可） | 速い＋自動スケール/自己修復 |
ひっかけ： 「コンテナはVMより軽量だから隔離性能も常に優れる」は誤りです——コンテナはカーネルを共有するためVMより隔離が弱く、機密性の高い処理を無配慮に混在させるとリスクになります。また「コンテナ化すれば自動的にオーケストレーションも実現する」も誤り＝コンテナ化とオーケストレーション（Kubernetes等）は別レイヤであり、自己修復/オートスケールが必要な規模かどうかで導入を判断する必要があります。
5.1.4この節のまとめ
- ハイパーバイザはVMごとに独立OSを持たせ隔離が強いが起動が遅い、Type1（ベアメタル）は高性能でサーバ仮想化の主流
- コンテナ（Docker）はカーネル共有で軽量/高速起動/高密度だが隔離はVMより弱い＝機密処理の配置は要検討
- Kubernetesは自己修復/オートスケール/ローリングアップデートを担うオーケストレーション基盤で、運用規模に応じて導入要否を判断する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. セール時にアクセスが急増するECサイトの注文サービスについて、負荷急増から数秒単位で追従してスケールアウトしたいという要件がある。実行基盤の選択として最も適切な判断はどれか。
Q2. 決済サービスをコンテナ化するにあたり、同一ホスト上の他サービスとカーネルを共有することによる隔離の弱さがセキュリティ上の懸念となった。この懸念に対する設計判断として最も適切なものはどれか。
Q3. 注文・在庫・決済という3つの独立したマイクロサービスを、需要変動に応じてサービスごとに個別に自動スケール・自己修復させたいという要件がある。実行基盤の運用方式として最も適切なものはどれか。