Skip to content

docker-build-performance.md

Latest commit

 

History

History
328 lines (235 loc) · 8.77 KB

docker-build-performance.md

File metadata and controls

328 lines (235 loc) · 8.77 KB
Raw

Dockerビルドのパフォーマンス分析

このドキュメントでは、異なるプラットフォームでのDockerビルドのパフォーマンス特性と、クロスコンパイルビルドが遅い理由について説明します。

パフォーマンス比較

ビルド時間の実測値

ホスト環境 ターゲット ビルド時間 QEMUエミュレーション
macOS (x64) x64 Linux 8-12分 不要 ✅
macOS (Apple Silicon) x64 Linux 10-15分 Rosetta 2使用
Windows (x64) x64 Linux 10-15分 不要 ✅
Windows (x64) ARM64 Linux 30-60分 必要 ❌

重要な観察

なぜWindows x64→ARM64 Linuxビルドがこれほど遅いのか？

macOSでx64→x64 Linuxビルドが速いのに対し、Windows x64→ARM64 Linuxビルドが極端に遅い理由は、主にアーキテクチャの違いにあります。

技術的な理由

1. QEMUエミュレーションのオーバーヘッド

同一アーキテクチャ（高速）

# macOS x64 → x64 Linux
ホスト: x86_64
ターゲット: x86_64-unknown-linux-gnu
処理: ネイティブ命令実行
速度: ほぼネイティブ速度

CPUアーキテクチャが一致している場合、バイナリ命令はネイティブで実行できます。DockerコンテナはLinuxカーネルの違いを吸収するだけで、CPU命令はそのまま実行されます。

クロスアーキテクチャ（低速）

# Windows x64 → ARM64 Linux
ホスト: x86_64
ターゲット: aarch64-unknown-linux-gnu
処理: QEMU経由でARM命令をエミュレート
速度: 10-50倍遅い ❌

異なるアーキテクチャの場合、すべてのARM命令をx86_64命令に変換する必要があります。

QEMUのオーバーヘッド:

# Dockerfile内でQEMUが使用される
RUN apt-get install -y qemu-user-static

# ビルド時、すべてのARM命令が変換される
# ARM: ADD R0, R1, R2
#   ↓ QEMU変換
# x86: mov eax, [r1]
#      add eax, [r2]
#      mov [r0], eax

このような変換が数百万回実行されるため、極端に遅くなります。

2. Dockerバックエンドの違い

macOS Docker Desktop

仮想化技術:
  - Apple Virtualization Framework (macOS 13+)
  - QEMU + HVF (Hypervisor Framework)

最適化:
  - ネイティブ仮想化サポート
  - 効率的なメモリ管理
  - VirtioFS (高速ファイル共有)

ファイルシステム:
  macOS APFS → VirtioFS → Linux ext4
  オーバーヘッド: 小

Windows Docker Desktop + WSL 2

仮想化技術:
  - WSL 2 (Linux VM on Hyper-V)
  - Docker Engine in WSL 2

レイヤー構造: Windows (NTFS)
  ↓ 9P protocol (遅い)
  WSL 2 (ext4 in VM)
  ↓ Docker bind mount
  Container (ext4)

オーバーヘッド: 大

3. ファイルシステムのオーバーヘッド

Windows環境でのI/O経路

C:\Users\...\DropWebP (NTFS)
  ↓ 9Pネットワークプロトコル
/mnt/c/Users/.../DropWebP (WSL 2)
  ↓ Docker bind mount
/workspace (Container)

9Pプロトコルは、ネットワーク経由でファイルシステムを共有するプロトコルです。ローカルファイルシステムと比較して：

  • 小ファイルの大量読み書き: 10-100倍遅い
  • メタデータ操作: 特に遅い
  • Rustコンパイル: 数万の小ファイルI/Oが発生

macOS環境でのI/O経路

/Users/.../DropWebP (APFS)
  ↓ VirtioFS (最適化済み)
/workspace (Container)

VirtioFSは、仮想化環境専用に設計された高速ファイル共有プロトコルです：

  • 9Pより2-5倍高速
  • メタデータキャッシュが効率的
  • 大規模プロジェクトで特に有利

4. Rustビルドの特性

// Drop Compress Imageの依存関係
dependencies {
  libavif,      // AVIFエンコーダー
  jpegxl-rs,    // JPEG XLエンコーダー
  libwebp-sys,  // WebPエンコーダー
  oxipng,       // PNGオプティマイザー
  jpegli,       // 高速JPEGエンコーダー
  // ... 多数のネイティブライブラリ
}

これらのネイティブライブラリをARM向けにクロスコンパイルする際：

  1. Cコンパイル: gccでARM用バイナリを生成
  2. アセンブリ: NASM/YASMでARM最適化コード
  3. 静的リンク: すべてのライブラリを1つのバイナリに結合
  4. LTO: リンク時最適化

すべてのステップがQEMU経由で実行されるため、累積的に遅くなります。

パフォーマンス最適化戦略

推奨アプローチ

開発フェーズ

# x64 Linuxのみビルド（10-15分）
pnpm run build:tauri:linux-x64

理由:

  • QEMUエミュレーション不要
  • ファイルI/Oも最小限
  • デバッグ・テスト用には十分

リリースフェーズ

# GitHub Actionsで並列ビルド
jobs:
  build-x64:
    runs-on: ubuntu-latest
  build-arm64:
    runs-on: ubuntu-latest

理由:

  • GitHubの高性能インフラ
  • 並列実行で時間短縮
  • ローカルマシンの負荷ゼロ

高度な最適化

オプション1: WSL 2内でビルド

# Windows側でWSL 2に入る
wsl

# WSLネイティブパスでビルド
cd ~/DropWebP  # ← /mnt/c/ではなく、WSLネイティブ
bash scripts/build-linux-docker.sh arm64

効果: 9Pプロトコルのオーバーヘッドを回避。20-30%高速化。

オプション2: Docker Volumeの活用

# ソースコードをVolumeにコピー
docker volume create dropwebp-source
docker run --rm `
    -v "${PWD}:/host:ro" `
    -v dropwebp-source:/workspace `
    alpine cp -r /host/. /workspace/

# Volumeからビルド（I/Oが超高速）
docker run --rm `
    -v dropwebp-source:/workspace `
    # ...

効果: すべてのI/OがVM内で完結。30-40%高速化。

オプション3: sccacheでコンパイルキャッシュ

# Rustコンパイルキャッシュツール
cargo install sccache

# 環境変数設定
export RUSTC_WRAPPER=sccache
export SCCACHE_DIR=/cache/sccache

効果: 再ビルド時に50-80%高速化。

オプション4: 段階的ビルド

# Dockerfile.deps
FROM base-image

# 依存関係のみビルド
COPY Cargo.toml Cargo.lock ./
RUN cargo build --release --target aarch64-unknown-linux-gnu

# メインビルドは差分のみ
FROM deps-image
COPY src/ ./src/
RUN cargo build --release

効果: 初回以降、60-70%高速化。

ビルド環境の選択ガイド

シナリオ別推奨

シナリオ 推奨環境 理由
日常開発・テスト Windows x64 → x64 Linux 速い、十分
リリース前テスト GitHub Actions 並列、高速
緊急リリース WSL 2内でビルド ローカルで完結
CI/CD GitHub Actions 自動化、並列化

実用的な開発フロー

# 1. 日常開発（x64のみ）
pnpm run build:tauri:linux-x64

# 2. プルリクエスト作成時
#    → GitHub Actionsが自動的に全プラットフォームビルド

# 3. リリースタグ作成時
git tag v3.2.1
git push origin v3.2.1
#    → GitHub Actionsが成果物を生成

技術的な補足

なぜmacOSは速いのか？

  1. Rosetta 2の最適化 (Apple Silicon)

    • x86_64バイナリを高速に実行
    • JITコンパイルで最適化

  2. 統合された仮想化

    • カーネルレベルでの最適化
    • Appleが全スタックを制御

  3. VirtioFS

    • macOS専用に最適化
    • Metal APIとの統合

Windowsでの制約

  1. WSL 2のアーキテクチャ

    • Hyper-V上の完全なLinux VM
    • ネットワーク経由でファイル共有

  2. 9Pプロトコル

    • 汎用プロトコル（最適化不足）
    • Windowsカーネルとの統合が弱い

  3. QEMU

    • ソフトウェアエミュレーション
    • ハードウェアアクセラレーションなし

まとめ

キーポイント

✅ 同じアーキテクチャは速い: x64 → x64は10-15分 ❌ クロスアーキテクチャは遅い: x64 → ARM64は30-60分 🚀 実用的な解決策: 開発中はx64のみ、リリースはGitHub Actions

開発者への推奨

# 普段はこれで十分
pnpm run build:tauri:linux-x64

# リリース時は自動化
git tag v3.2.1 && git push origin v3.2.1

時間とリソースを効率的に使い、ストレスなく開発を進めましょう！