Apple Container (container) v0.7.1 パフォーマンス・リソース検証レポート

2026-01-25

macos
container
docker

📌 この記事は goose (gemini-3-flash-preview) が調査結果を元に作成しました。

⚠️ Apple container は現在 v0.7.1 であり、多くの機能や最適化が開発途上です。現時点では Docker Desktop 等を置き換えるものではありません。

前回の機能検証に続き、今回は Apple container コマンドのリソース管理とパフォーマンスについて、Docker Desktop との比較を交えて検証しました。 Apple Silicon (M-series) Mac 上での検証結果をまとめます。

検証結果サマリー

項目	結果	備考
メモリ管理	🙆	オンデマンド確保（Demand Paging）を確認
ディスク管理	🙆	シンプロビジョニングと fstrim による解放を確認
ネットワーク速度	🙆	Docker Desktop を大幅に上回るスループット
CPU 性能	🙆	Docker と同等のパフォーマンスを維持
ビルド時間	🙆	実タスクでは Docker に一日の長がある

1. リソース管理：オンデマンドな思想

Apple container の最大の特徴は、「必要な時に、必要なだけ確保する」 という macOS ネイティブなリソース管理です。

メモリ (Demand Paging)

Docker Desktop は VM があらかじめメモリを確保して常駐しますが、container は各コンテナが独立した VirtualMachine.xpc プロセスとして動作します。 -m 4g と指定して起動しても、実際にコンテナ内のアプリケーションがメモリを使用（タッチ）するまでホスト側のメモリは消費されず、コンテナ停止時には即座にすべてのメモリが解放されます。

検証では、コンテナを起動した後に stress-ng を用いてコンテナ内からメモリ負荷をかけ、ホスト側の空きメモリがリアルタイムに変動することを確認しました。

container run -d --name mem-test -m 4g alpine sleep 300
container exec mem-test sh -c "apk add stress-ng && stress-ng --vm 1 --vm-bytes 1G"

ディスク (Thin Provisioning)

ディスク領域（rootfs）も実使用量に基づいて動的に拡張されます。また、コンテナ内でファイルを削除した後に fstrim を実行することで、ホスト側のディスク領域を物理的に返却できることも確認できました。

container exec <ID> dd if=/dev/zero of=/test-1g bs=1M count=1024
container exec <ID> rm /test-1g
container exec <ID> fstrim -v /

ホスト上の ~/Library/Application Support/com.apple.container/containers/<ID>/rootfs.ext4 のファイルサイズが、fstrim 前後で実際に変化することを確認しています。

2. パフォーマンス比較 (vs Docker Desktop)

ネットワークスループット

驚くべき結果となったのがネットワーク性能です。iperf3 を用いた計測では、特にホストからコンテナへの通信において Docker Desktop を圧倒しました。

検証では、コンテナ側で iperf3 -s をサーバーとして待機させ、ホスト側からアクセスして計測を行っています。

通信方向	Apple `container`	Docker Desktop
Host -> Container (下り)	~24.1 Gbps	~8.0 Gbps
Container -> Host (上り)	~19.2 Gbps	~16.9 Gbps

Virtualization.framework の virtio-net 実装がダイレクトに効いていると考えられます。

CPU とディスク I/O

CPU 性能は両者でほぼ同等でしたが、ディスク I/O にはアーキテクチャによる特性の差が見られました。

Random Write (4KB): arm64 では container が、amd64 では Docker が優勢。
Sequential Write: Docker Desktop (VirtioFS) の方が一貫して高速な結果となりました。

計測には fio (Random Write) および sysbench (CPU) を使用し、いずれも標準的な負荷パラメータを用いて比較を行っています。

sysbench cpu --cpu-max-prime=20000 run

3. 実タスクでの検証 (Go ビルド)

実際の開発ワークフローを想定した Go プロジェクトのビルド時間計測では、Docker Desktop が優勢という結果になりました。

Arch	Apple `container`	Docker Desktop
arm64	~8.17s	~6.80s
amd64	~25.4s	~20.3s

# Go プロジェクトのビルド時間を time コマンドで計測
time container run --rm golang:alpine sh -c "apk add --no-cache git && git clone --depth 1 https://github.com/golang/example /tmp/ex && cd /tmp/ex/hello && go build"

なぜ Docker の方が速いのか（考察）

VM コールドスタートの有無: container は実行のたびに VM を起動するため、数秒の固定コストが発生します。
キャッシュの恩恵: Docker は VM が常駐しているため、Rosetta 2 の翻訳結果やファイルシステムのメタデータキャッシュを再利用しやすいと考えられます。これらの点を踏まえると、container はまだ初期段階にあると言えるでしょう。

まとめ

検証を通じて、Apple container と Docker Desktop のパフォーマンス特性の違いが明らかになりました。

ネットワークスループットやメモリの動的確保といった点では Apple container が優れた数値を示していますが、実タスクのビルド時間やエミュレーションの効率、ディスク I/O の一貫性においては Docker Desktop が依然として優位にあります。ネットワークスループットやメモリの動的確保といった点では Apple container が優れた数値を示していますが、実タスクのビルド時間やエミュレーションの効率、ディスク I/O の一貫性においては Docker Desktop が依然として優位にあります。