世界を動かす技術を、日本語で。

コンテナはなぜ誕生したのか?

2025年10月13日原文(buttondown.com)

概要

  • DevOpsDays London での講演内容の要約
  • コンテナ技術 誕生の背景と仮想マシン(VM)との比較
  • DockerKubernetes の進化と現状
  • DevOps文化 の変遷と課題
  • 今後の 技術選択 やAIの影響についての考察

2025年秋のアップデート:DevOpsDays London講演要約

  • DevOpsDays London で講演実施、参加者と運営への感謝
  • 講演動画:https://www.youtube.com/watch?v=eMU2mZgo99c
  • 実際の発表内容と異なるが、以下は講演のラフアウトライン

コンテナ技術が生まれた理由

  • BroadcomによるVMware買収 に際し、FTCから「コンテナはVMの競合か?」と質問
  • VM はサーバー台数増加時代の産物、手動管理・低利用率(15%未満)が課題
  • Linux 環境では複数アプリ同居がやや容易、だが依然として非効率
  • コンテナ は「アプリケーション数の爆発」に対処するため登場
    • DotcloudがPaaS運営でDockerを開発、重要なのは「パッケージング」
  • 企業ではクラウド移行の一環としてコンテナを採用、VMの「リフト&シフト」非効率回避
    • MicrosoftはVM移行を提案、だがコンテナ+クラウドでモダナイズ推進
    • WindowsからLinuxへの移行も促進

Dockerの変革とイノベーション

  • Docker Hub による「共有可能なイメージレジストリ」が最大の革新
    • VMイメージは大きく、再利用性が低い
    • Cloud Initなどで若干改善も、コンテナイメージには及ばず
  • Dockerは「イミュータブル(不変)デプロイ」を強制
    • アプリ単位での再構築・再デプロイが容易、セキュリティ面の利点も
  • Docker登場で Go言語 が市民権獲得、現代の主要言語がTLS標準搭載

Kubernetesとオーケストレーションの進化

  • 初期のKubernetesは「スケジューリング」が主題、実際は「デプロイ自動化」が本質
    • Docker Swarmはデプロイスクリプト非対応、KubernetesでGitOpsなどの手法普及
  • データベース運用に関する議論
    • コンテナの「削除の容易さ」ゆえ、DB運用はクラウド依存傾向強化
    • ストレージ選択肢(NFS、ブロックストレージ等)の多様化

DevOps文化の変遷と課題

  • Kubernetesの複雑化が DevOps文化 を変質させた
    • かつては「開発と運用の融合」、今はKubernetes運用担当の「裏方」的役割へ
    • 技術志向が文化志向を凌駕
  • Dockerはローカル開発環境の標準化には至らず
    • PythonやRubyの仮想環境、Nixによる再現性確保が主流
    • Dockerは主にDBやサービスのテスト用途
  • OSSコンポーネントによるアプリ構築が主流化
    • 言語ごとのパッケージ管理が標準、ユニバーサルなビルド抽象化は不在
    • イミュータブル性の有用性は限定的、依存関係の複雑さが課題

現在の状況

  • 仮想化導入の動機は「リソース利用率15%」の改善
  • 2024年Datadogレポートによると「コンテナコストの83%はアイドルリソース」
    • 浪費の可視化は進んだが、規模の大きな自動化による浪費も増加
  • モバイルアプリ用途が中心、Armサーバーの普及
    • 効率的な運用の一方、長い非効率の「ロングテール」も継続
  • AIの登場で、高コストなアプリは急速に効率化
    • 推論コストの劇的低下

今後の展望

  • 2015年の「Choose Boring Technology」論文
    • 当時はDockerやKubernetesは「退屈でない」技術
    • 現在は「Dockerはほぼ退屈」「Kubernetesも退屈化進行中」(ChatGPT談)
  • 「退屈な技術を選ぶ」文化が定着、AIが変革予算を吸収
    • クラウドネイティブ・スタートアップ時代の終焉
    • LLMは「退屈な技術」に強み、さらなる変革には追加予算が必要

参考リンク

  • 講演動画:https://www.youtube.com/watch?v=eMU2mZgo99c

Hackerたちの意見

コンテナ(つまりDocker)は、CGroupsやネームスペースが難解で、ほとんどの人が直感的に理解できる「サンドボックス」を作るために多くの専門知識を必要としたからこそ生まれたんだよね。CGroupsとネームスペースは、セキュリティを追加するためにLinuxに導入されたけど、元々UNIXはセキュリティに対して根本的に弱い設計(共有グローバルネームスペースやユーザーなど)をしてるから、あんまりうまくいってない。最終的にはSEL4みたいなのがクラウドサーバーのワークロードのためにLinuxに取って代わってくれるといいな。ほとんどのアプリケーションはLinuxカーネルの機能をほとんど使ってないし、ネットワークスタックに初期引数として機能を渡して、他にはアクセスできないようにした非常に安全で高性能なウェブサーバーが作れるはずなんだ。仮想デバイスのドライバーはシンプルで、クラウドVMのためにLinuxの膨大なドライバーサポートは必要ない。SEL4用の仮想イーサネットデバイスドライバー、SEL4上で動くネットワークスタック、ネットワークデバイスのための機能を持ったネットワークスタックを読み込むシンプルなinitプロセスが必要なだけ。これをバイナリをコンパイルするみたいに簡単にイメージを作れるようにすれば、ほとんどのサーバーアプリケーションのデプロイから数千万行の複雑さを排除できるかも。LinuxもDockerもなしで。SEL4は実際にうまく設計されてるから、SEL4上でサブカーネルをプロセスとして比較的簡単に実行できるんだ。ほら、これでK8sもいらなくなるね。

コンテナをサンドボックスを作るための手段として見るなら納得できるけど、ホストシステムの依存関係を変えずに任意のアプリケーションを簡単に立ち上げる方法として考えると、あんまり意味がないよね。

それがコンテナの始まりの理由なの?依存関係地獄が原因で流行ったような気がするけど、簡単に仮想化できる時代じゃなかったからね。同じサーバー上で必要なソフトウェアのバージョンを全部動かすのは、調整するのが大変だったよ。

コンテナやネームスペースはセキュリティのためのものじゃないんだ。OSレベルでシングルトンオブジェクトを持たないためのもの。もし「仮想化」という言葉がそんなに使われてなければ、そう呼んでたかも。みんなが見落としてる大きな違いがあるんだ。バイパス可能なセキュリティメカニズムは、役に立たないどころか悪い。バイパス可能な仮想化メカニズムは役に立つ。悪意のあるプログラムが本当のルートでないことを検出できても、このプログラム専用の別のルートファイルシステムを持つのは便利なんだ。SEL4について言えば、難しい問題を上位層に任せるからこそ、すごくエレガントなんだよね(偶然にもそれらをもっと難しくしてるけど)。

SEL4は実際にうまく設計されてるから、SEL4上でサブカーネルをプロセスとして比較的簡単に実行できるんだ。ほら、これでK8sもいらなくなるね。K8sは、機械のクラスターをあたかも単一のリソースのように管理するためのものだから、その前の「ボーグ」という名前も納得だよね。私の知る限り、これはSEL4が扱うユースケースじゃないよね?

「カーネルに依存しない」Nvidiaドライバがあれば最高だよね。ベアメタル開発の経験があるけど、OSが提供するもののほとんどは、特定のハードウェアを動かすためのライブラリのセットとして、もっと良い形で提供できるように思うんだよね。それに、すごく良い「ビルド」システムも必要だし。

cgroupsは、確かIBMから出てきたリソース管理フレームワークから来たんだよね。しばらくの間、いくつかのディストリビューションのカーネルに入ったけど、上流には行かなかった。ネームスペースはセキュリティを追加するための試みじゃなくて、バインドマウントのようにインターフェースをもっと柔軟にするための作業から生まれたものなんだ。Unixのセキュリティは基本的に良いもので、ネームスペースがないことはあまり問題じゃないけど、今はあるからね。実際、うまくいってると思う。すべてのアプリは多くのカーネル機能を使っていて、非常に安全で高性能なウェブやその他のサーバーもある。L4システムはLinuxと同じくらいの歴史があって、特にSEL4は20年も続いてる。でも、あまり進展はないから、今のところあまりうまくいってるとは言えないかな。SEL4は重要なことをいくつか成し遂げた素晴らしいプロジェクトだけど、Unixの代替としてクーデターを起こす準備ができてるようには見えないね。

「セキュリティに対する根本的に悪いアプローチを持っている。UnixはVPSプロバイダーのために便利に設計されたわけじゃなく、1台のコンピュータが1つの会社のフロア全体にサービスを提供できるように設計された。セキュリティのアプローチは展開戦略に適している。すべてのOSと同様に、インターネットが現れて、すぐにすべてを台無しにした。」

「Cgroupsとネームスペースは、セキュリティを追加するためにLinuxに追加された。UNIXは根本的にセキュリティに対する悪いアプローチ(共有グローバルネームスペース、ユーザーなど)を持っている。すべてのリソースのネームスペース化(共有グローバルネームスペースへの制限なし)は、実際にはplan9から直接取られたものだ。これによりセキュリティが向上するが、それだけじゃなく、分散コンピューティングのための原則的な基盤も整える。コンテナ化がk8sのような低レベルの層を可能にする様子にこれが見られる - もちろん、実際には最もよく知られている高レベルの適応型展開と管理を考慮に入れずに。」

「SEL4みたいなのが、最終的にはクラウドサーバーのワークロードのためにLinuxの代わりになることを願ってる。9frontやディスクレスLinuxのマイクロVM、Firecracker/Kata-containersスタイルでもいいんじゃない?K8sよりも小さいOSで、ファイルシステムとプロセスの隔離が一緒になってるやつ。シンプルでUnixっぽく。既存のバイナリはそのまま使って、プレーンテキストの設定やリポジトリ、イメージもそのまま。スタックの一番下のレイヤーだけを入れ替えて、便利な時にホストOSに移行すればいい。」

聞いた話では、コンテナは仮想マシンに比べてメモリを少なく使えて、カーネルやCPUをより良く共有できるから、同じサーバーでより多くのアプリケーションを動かせるんだって。これが直接的なコスト削減につながるから、大規模なサーバーファームを持つ大企業は、技術を開発して移行するためにエンジニアにお金を払う価値があるんだよね。セキュリティに関しては、SEL4やコンテナ、VMよりも、各アプリケーションに別々の物理サーバーを用意して、CPUやメモリを全く共有しない方が安全だと思う。そうすれば、物理的にアプリケーション間にセキュリティの境界ができるからね。もちろん、ほとんどのビジネスケースにはそれが高すぎるから、みんな使わないんだよね。SEL4を使うのも同じ問題にぶつかると思う。コンテナに比べてサーバーの利用効率が悪くなるから、ビジネスケースには高くついて魅力的じゃない。コンテナに代わるものを求めるなら、それはもっと安くて安全でなきゃいけないけど、何になるかは分からないな。

私の妄想では、Dockerが存在するのは、Pythonのパッケージ管理と依存関係管理がひどすぎて、dotCloudがLinuxコンテナの上に何かを作らざるを得なかったからだと思ってる。Pythonアプリをデプロイするための快適な体験を提供するためにね。

Hacker Newsで議論の続きを見る