# コンテナ仮想化 ## 定義 コンテナ仮想化(container-based virtualization)とは、既存の OS カーネルを変更してプロセス間の隔離を追加する OS レベル仮想化の手法である。仮想マシン(VM)がハードウェアを抽象化してゲスト OS を丸ごと動かすのに対し、コンテナはカーネルを共有したまま Linux namespace と cgroup により各コンテナのファイルシステム・プロセス・ネットワーク・ユーザ空間を分離する。[[Docker]] が 2013–2014 年に標準的なイメージ形式・管理ツール・リポジトリエコシステムを整備したことで OS レベル仮想化が広く普及した。([[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]], [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) ### 主要な Linux カーネル機構 | 機構 | 役割 | |---|---| | namespace(clone(2)) | ファイルシステム・PID・ネットワーク・ユーザ・IPC・ホスト名の分離 | | cgroup | CPU・メモリ・I/O のリソース上限と計測 | | AUFS / overlay2 | レイヤード読み書きファイルシステム(Docker イメージの差分管理) | | seccomp | システムコールのホワイトリスト制限 | ### VM との根本的な違い | 比較軸 | VM (KVM) | コンテナ (Docker) | |---|---|---| | カーネル | ゲスト OS ごとに独立 | ホスト OS 共有 | | 起動時間 | 数十秒(OS ブート) | 1秒未満(プロセス起動) | | CPU オーバーヘッド | NUMA トポロジ隠蔽による適応型アルゴリズム劣化あり | ほぼゼロ | | ランダム I/O | QEMU 経由で ~50% IOPS 低下 | ネイティブとほぼ同等 | | ネットワーク遅延 | +30µs/トランザクション(+80%) | NAT あり: 高並列で劣化; net=host: ほぼゼロ | | セキュリティ隔離 | ハイパーバイザ境界で強い | namespace 境界(脆弱性リスクあり) | ## Docker のパフォーマンス落とし穴 ISPASS 2015 論文([[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]])が発見した非自明なコスト: 1. **AUFS**: デフォルトストレージドライバ。I/O が複数のユニオンファイルシステムレイヤーを通るため、書き込み性能が低下する。volume(-v オプション)でホストファイルシステムを直接マウントすることで回避可能。 2. **NAT ネットワーク**: veth pair + Linux bridge + NAT の経路は、高パケットレートの Redis や MySQL で CPU を消費し遅延を増加させる。Docker net=host モードでネイティブと同等の性能を得られる。 ## 横断的知見 - **「コンテナ ≈ 軽い VM」という動機と、実際の差異**: Pahl ら(IEEE TCC 2019, [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]])の SMS では「デプロイ容易性」が「軽量リソース管理」より優先される動機として示された。一方、Felter ら(ISPASS 2015)の実測では軽量性は本当に本質的で、CPU・メモリ帯域の性能差はほぼ無いが、ランダム I/O とネットワーク遅延でコンテナが VM に対して 2–3 倍の性能差を持つ。両論文を突き合わせると「コンテナの訴求点は性能面でも非自明な優位があり、デプロイ容易性と性能の両軸で VM を代替できる」という強い結論が得られる。(Source: [[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]], [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) - **IaaS=VM・PaaS=コンテナという通説への反証**: Pahl ら SMS の測定(Fig. 14)では IaaS と PaaS がほぼ均等に登場し「コンテナは VM の IaaS 代替にもなれる」示唆があった。Felter ら(2015)はこれを定量的に支持し「コンテナは bare metal の性能と VM の隔離を両立できる」と明示的に主張している。2015 年時点で技術的必然性がない通説がどの程度崩れたかは、後続のクラウドプロバイダーの動向が証拠になる。(Source: [[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]], [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]) ## 未解決の問い - ISPASS 2015 の測定は Docker 1.0(AUFS + iptables NAT)が対象だった。overlay2・CNI プラグイン・eBPF ベースのネットワーク(Cilium)が普及した 2026 年現在では NAT オーバーヘッドがどの程度解消されているか。 - セキュリティ隔離強度と性能のトレードオフ: Kata Containers(VM 内コンテナ)・gVisor・Firecracker はどの性能ポイントを犠牲にして隔離強度を上げているか。ISPASS 2015 の「double virtualization は性能上の利点がない」という結論は現在も成立するか。 - 複数コンテナが同居するときの性能干渉(noise neighbor)は ISPASS 2015 の対象外だった。cgroup v2・PSI(pressure stall information)による改善はどの程度か。 - VM と比べてコンテナの namespace 境界は脆弱性のリスクがある。Linux seccomp + AppArmor + eBPF LSM の組み合わせが 2026 年時点で security hardening としてどの程度標準化されているか。 ## 関連 - ソース: [[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]] / [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]] - エンティティ: [[Docker]] / [[IBM Research]] / [[Wes Felter]] - 概念: [[コンテナオーケストレーション]] / [[コンテナ配置最適化]] / [[コンテナ起動高速化]] / [[カーネル内VM]] - 関連 MOC: [[Cloud Container Orchestration]] ## 出典 - [[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]]（§2 Background, §3 Evaluation 全体、§5 Conclusions） - [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]]（§2.1 Container Technology Principles）