# コンテナ仮想化 ## 定義 コンテナ仮想化(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]]) - **隔離と性能のトレードオフはリソース単位で再設計可能**: Subaco はコンテナのネットワーク隔離のみを para-passthrough ハイパーバイザで強化し、他のリソースは既存の軽量隔離を使うことで、runC と同等の起動時間(約 1.15 秒)を維持する。これは「コンテナは VM の隔離を諦めるか、VM のオーバーヘッドを受け入れるか」という二者択一を、Sandbox Tailoring によって緩和する例である。(Source: [[@2021__UCC__Concentrated Isolation for Container Networks Toward Application-aware Sandbox Tailoring]] §6.2.1, §6.2.2) - **OS カーネル移植による攻撃面削減も軽量性を維持しうる**: Container Transplantation は Linux コンテナを FreeBSD カーネルへ移植し、Linux カーネル固有の脆弱性を無力化する。UnixBench では gVisor が runC 比 96% 悪化するのに対し、Linuxulator with Jail は 22% 悪化に抑えた。これは Sandbox Tailoring と異なる抽象階層(OS カーネル)で、同じく「VM/gVisor のような完全統合型サンドボックスを避けつつ隔離を強化する」方向性を示す。両者を合わせると、コンテナの軽量性と隔離強度のトレードオフは、リソース単位でも OS カーネル単位でも緩和可能であることが示唆される。(Source: [[@2023__APSys__Reducing Attack Surface with Container Transplantation for Lightweight Sandboxing]] §5.2, §6) - **ISPASS 2015 が「対象外」とした noisy neighbor 問題に、ch.11 のリソースコントロール機構が定量的な観測手段を与える**: Felter ら(ISPASS 2015)は単一コンテナのベンチマークに限定し、複数コンテナ同居時の性能干渉(noise neighbor)を明示的に今後の課題として残した。『詳解 システム・パフォーマンス 第2版』11章は、この干渉を CPU シェア(バースティング)と CFS 帯域幅の数式(「コンテナに与えられる CPU 時間 = 全 CPU 時間 × コンテナのシェア / システムのビジーシェアの合計」)で定量化し、cgroup の `cpu.stat` にある `nr_throttled`/`throttled_time` という具体的な観測指標、および throttled_time・非自発的コンテキストスイッチ・ホストのアイドル CPU 等 5 指標からの原因切り分けフローチャートを与える。ISPASS 2015 が測定対象外とした問いに、2020 年の書籍が測定手段を用意した形になる。(Source: [[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]] §5 Conclusions, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] §11.3.3.1.2, §11.3.4.2.5) - **軽量仮想化の具体的なオーバーヘッド数値が、隔離強度と性能のトレードオフ論争に定量的な参照点を与える**: 「Kata Containers・gVisor・Firecracker はどの性能ポイントを犠牲にして隔離強度を上げているか」という問いに対し、ch.11 は Firecracker の VMM コード量(5 万行、QEMU の 140 万行超の約 1/28)とメモリオーバーヘッド(5MB 未満、Intel Clear Containers 2.0 の 48〜50MB の 1/10 程度)という具体的な数値を与える[Agache 20]。ただしこれらはコード量とメモリの指標にとどまり、ISPASS 2015 型の CPU/ネットワーク/ディスク I/O ベンチマークとは直接比較できない点は未解決のまま残る。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] §11.4.1, §11.4.2) ## 未解決の問い - ISPASS 2015 の測定は Docker 1.0(AUFS + iptables NAT)が対象だった。overlay2・CNI プラグイン・eBPF ベースのネットワーク(Cilium)が普及した 2026 年現在では NAT オーバーヘッドがどの程度解消されているか。 - セキュリティ隔離強度と性能のトレードオフ: Kata Containers(VM 内コンテナ)・gVisor・Firecracker はどの性能ポイントを犠牲にして隔離強度を上げているか。ch.11 はコード量・メモリオーバーヘッドの数値は与えたが、ISPASS 2015 の「double virtualization は性能上の利点がない」という結論を CPU/I/O ベンチマークで再検証した比較はまだ本 wiki に蓄積されていない。 - Sandbox Tailoring のようにリソースごとに隔離手法を組み合わせた場合、全体の攻撃面をどのように評価・保証するか。異なる隔離手法の境界が新たな脆弱性を生まないか。 - 複数コンテナが同居するときの性能干渉(noise neighbor)は ISPASS 2015 の対象外だったが、ch.11 は cgroup v1 ベースの throttled_time 等で部分的な観測手段を示した。cgroup v2・PSI(pressure stall information)による改善は、ch.11 執筆時点(2020年)ではまだ「今後数年で移行が進む」段階にとどまり、定量評価は未解決のままである。 - VM と比べてコンテナの namespace 境界は脆弱性のリスクがある。Linux seccomp + AppArmor + eBPF LSM の組み合わせが 2026 年時点で security hardening としてどの程度標準化されているか。 - Container Transplantation のように Linux 以外のカーネル上で Linux コンテナを実行する場合、カーネル互換性の限界がどの程度の実用アプリケーションに影響するか。Sandbox Tailoring と組み合わせた際の統合的な攻撃面評価はどう行うか。 ## 関連 - ソース: [[@2015__ISPASS__An Updated Performance Comparison of Virtual Machines and Linux Containers]] / [[@2019__TCC__Cloud Container Technologies - A State-of-the-Art Review]] / [[@2023__APSys__Reducing Attack Surface with Container Transplantation for Lightweight Sandboxing]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] - エンティティ: [[Docker]] / [[IBM Research]] / [[Wes Felter]] / [[FreeBSD]] / [[Linuxulator]] / [[gVisor]] / [[Kata Containers]] / [[Kubernetes]] / [[Firecracker]] / [[Brendan Gregg]] - 概念: [[コンテナオーケストレーション]] / [[コンテナ配置最適化]] / [[コンテナ起動高速化]] / [[カーネル内VM]] / [[Sandbox Tailoring]] / [[Container Transplantation]] / [[Capability-based Security]] / [[Lightweight Sandboxing]] / [[Capsicum]] / [[クラウドコンピューティング]] ## 出典 - [[@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） - [[@2023__APSys__Reducing Attack Surface with Container Transplantation for Lightweight Sandboxing]]（§2 脆弱性分析、§4 実装設計、§5 評価） - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]](§11.3.1〜§11.3.4 OS仮想化の実装・オーバーヘッド・リソースコントロール・可観測性、§11.4 軽量仮想化)