Containerization
コンテナ化では、アプリをランタイム、ライブラリ、設定とともにイメージにまとめます。このイメージは、ホストOSのカーネルを共有する独立したプロセスとして実行されます。
コンテナ化とは、アプリケーションと、ランタイム、ライブラリ、システムパッケージ、設定などの実行に必要なすべての要素をイメージにまとめ、コンテナと呼ばれる分離されたプロセスとして実行するソフトウェアのパッケージ方法です。各コンテナは独自のファイルシステム、プロセスツリー、ネットワークインターフェースを持ちますが、ホスト上のすべてのコンテナはホストのオペレーティングシステムカーネルを共有するため、仮想マシンよりも大幅に軽量です。機械学習 (ML)では、コンテナ化によって異なるバージョンのPython、CUDA、PyTorchを必要とするプロジェクト間の競合を防ぎ、ワークステーションで学習したモデルを、変更せずにサーバー、クラスター、またはエッジコンピューティングデバイスで実行できます。
コンテナの仕組み#
Linuxコンテナは、主に2つのカーネル機能を基盤としています。名前空間はプロセスから見える範囲を制御し、独自のプロセスID、ネットワークスタック、マウントポイント、ユーザーを提供します。cgroups(コントロールグループ)はCPU、メモリ、I/Oに上限を設定し、使用可能なリソースを制御します。この考え方は1979年のchrootと2000年のFreeBSD jailに端を発し、cgroupsは2008年にLinuxカーネルに導入され、Dockerが2013年にコンテナを普及させました。2015年に設立されたOpen Container Initiative (OCI)は、イメージとランタイムの形式を標準化しました。そのため、あるツールで構築したイメージを別のツールでも実行できます。
コンテナランタイムが実際の処理を担います。containerdやCRI-Oなどの高レベルランタイムはイメージを取得してコンテナのライフサイクルを管理し、runcなどの低レベルOCIランタイムは名前空間とcgroupsを作成してプロセスを開始します。LinuxコンテナにはLinuxカーネルが必要なため、macOSとWindowsでは小規模なLinux仮想マシン内でコンテナを実行します。
イメージ、レイヤー、レジストリ#
イメージは、読み取り専用レイヤーを積み重ね、実行するコマンドを指定する設定を加えたものです。起動時にランタイムがレイヤーを1つのファイルシステムに統合します。通常はOverlayFSを使い、そのコンテナ用の薄い書き込み可能レイヤーを追加するため、多数のコンテナでディスク上のイメージを共有できます。Docker Hub、GitHub Container Registry、各クラウドプロバイダーのレジストリなどでは、latestなどのタグや、常に同じバイト列を識別するSHA-256ハッシュであるコンテンツダイジェストを使ってイメージを保存します。変更されていないレイヤーはビルド時に再利用されます。そのため、Dockerfileでは頻繁に編集されるコードをコピーする前に依存関係をインストールします。
MLワークフローにおけるコンテナ化#
MLOpsパイプラインでは、コンテナがプロジェクトを実験から本番環境へ運びます。NVIDIA NGC Catalogなどのフレームワークイメージでは、CUDA、cuDNN、フレームワークのバージョンが固定されるため、分散学習ジョブのすべてのノードで同じソフトウェアが実行されます。ホスト側が提供するのはGPUドライバーだけで、NVIDIA Container Toolkitがこれをコンテナに公開します。継続的インテグレーションのテストは、後にリリースされるものと同じイメージ内で実行されます。モデルサービング用の推論サーバーはイメージとして実行され、Kubernetesがトラフィックに応じて複製・スケーリングします。また、NVIDIA JetsonボードなどのエッジAIデバイスでは、新しいイメージタグを取得してモデルを更新します。
Enterprise ワークスペース向けのオンプレミス統合機能を備えたUltralytics Platformでは、必要に応じてDockerをインストールし、ホストのARM64、CPU、またはNVIDIA GPUハードウェアに対応するUltralytics公式イメージからワーカコンテナを1つ起動します。ワーカーはデータセットフォルダーを読み取り専用でマウントするため、ソース画像はそのコンピューター内に保持され、トレーニング指標と各YOLO26の実行で得られた最良のチェックポイントはPlatformに送信されます。
コンテナと仮想マシンの比較#
仮想マシンは、ハイパーバイザー上で独自のカーネルを持つ完全なゲストオペレーティングシステムを実行します。そのため、各VMは数ギガバイトのOSイメージを持ち、独立したコンピューターのように起動します。一方、コンテナは共有ホストカーネル上の通常のプロセスなので、アプリケーションと同じ速さで起動し、追加するのは独自のファイルだけです。カーネルを共有するため、カーネルの脆弱性によってホスト上のすべてのコンテナが危険にさらされる可能性があります。そのため、この2つを組み合わせることがよくあります。パブリッククラウドでは顧客のコンテナをVM内で実行し、信頼できないコード(AIエージェントがエージェントサンドボックス内で記述・実行するコードなど)には、サンドボックス化されたランタイムで第2の境界を設けます。GoogleのgVisorは、独自のユーザー空間カーネルでコンテナのシステムコールを仲介します。Kata Containersは各コンテナを軽量な仮想マシン内で実行し、AWSはAWS Lambda関数を同様に分離するため、FirecrackerマイクロVMを開発しました。










