⚙️

開発環境の性能比較：Docker vs devenv ベンチマーク

yushi-s

2025/08/24に公開

 開発環境の性能比較：Docker vs devenv ベンチマーク
 はじめに現代のソフトウェア開発において、開発環境の選択は開発効率に直接影響します。APIなどのリソース取得時間、コンパイル時間、依存関係の管理は開発サイクルに大きな影響を与えます。

 なぜDockerとdevenvを比較するのか？Dockerとdevenvは異なる目的で設計されたツールですが、実際の開発現場では両方とも開発環境の構築・管理に使用されています。
Dockerの主な目的:
アプリケーションのコンテナ化とデプロイメント
本番環境との一貫性の確保
環境の完全な分離とポータビリティ
OSレベルでプロセス分離することにによるマイクロサービスアーキテクチャのサポート
devenvの主な目的:
開発環境の高速な構築と管理
開発者体験の向上
依存関係の効率的な管理
チーム間での環境統一
比較する理由:

実際の開発現場での選択肢: Dockerが圧倒的にメジャーだが、devenvも開発効率向上の選択肢として注目されている

開発効率への影響: どちらのツールを選択するかが開発速度に直接影響する

トレードオフの理解: 各ツールの利点と欠点を定量的に把握する必要がある

プロジェクト要件との適合性: プロジェクトの特性に応じた最適な選択の指針を得る

 CI/CDにおける役割の違いdevenvのCI/CDにおける役割:

開発とCI環境の統一: devenv testやdevenv buildコマンドをCI/CDスクリプトに含めることで、開発者のマシンとCIサーバーで全く同じツールチェーンや依存関係を使用

依存関係の宣言的管理: プロジェクトに必要なすべてのツールやライブラリをdevenv.nixファイルに記述し、CIスクリプトの複雑性を軽減

ビルド環境の再現性向上: 開発環境とCI環境の一貫性を保証
DockerがCI/CDで優位な理由:

環境のポータビリティ: アプリケーションとその依存関係をコンテナイメージとしてパッケージ化し、テスト環境、ステージング環境、本番環境など、異なるプラットフォーム間で全く同じように実行可能

実行環境の隔離: OSレベルでプロセスを隔離するため、複数のプロジェクトが同時に実行されるCI/CDパイプラインで、あるプロジェクトのビルドやテストが他のプロジェクトに影響を与えない

デプロイとの親和性: Kubernetesなどのコンテナオーケストレーションツールとの高い親和性により、CIパイプラインでビルドしたイメージをコンテナレジストリにプッシュし、本番環境にプルして実行する一連の流れが効率的
重要な違い:

devenv: 開発者のローカル環境のセットアップとCI環境の統一に特化

Docker: CI/CDの核となるビルド、実行、デプロイの全工程で優位性を発揮
この記事では、実際のベンチマーク結果に基づいて、Dockerとdevenvの性能を詳細に分析し、それぞれのユースケースを明確にします。目的の違いを理解した上で、実際の開発現場での選択基準を提供します。

 ベンチマーク概要
 測定環境
OS: macOS 14.6.0 (Apple Silicon)

プロジェクト: Rust Axum バックエンド

測定項目: 依存関係インストール、コンパイル、サーバー起動、データベース接続、API応答時間

キャッシュ: 両環境ともキャッシュを活用した現実的な測定

 測定方法実際の開発フローをシミュレートする具体的な測定手順:
プロジェクト作成フェーズ
一時ディレクトリにテストプロジェクトを作成
必要なファイル（enhance_react_app.js, api_server.js, create_large_project.js, test_external_api.js）をコピー
プロジェクトタイプに応じた初期化（Rust Axumバックエンド）
依存関係インストール測定

Docker: コンテナ内でのcargo buildによる依存関係ダウンロード

devenv: Nix環境での依存関係解決とインストール
キャッシュを活用した現実的な測定
コンパイル時間測定

Docker: コンテナ内でのRustコードのコンパイル

devenv: ネイティブ環境でのコンパイル
リリースビルドの実行時間を測定
サーバー起動時間測定
バックエンドサーバーの起動プロセス
ポート待機状態までの時間
プロセス初期化の完了確認
データベース接続測定
SQLiteデータベースへの接続テスト
接続確立からクエリ実行までの時間
データベース初期化の完了確認
API通信測定

内部API: ローカルエンドポイントへのHTTPリクエスト

外部API: 複数の外部APIエンドポイントへの並列リクエスト
レスポンス時間とスループットの測定
統計的妥当性の確保:
複数回の測定（デフォルト3回）による平均値算出
最小値、最大値、標準偏差の計算
キャッシュ効果を考慮した現実的な測定
キャッシュを活用した継続的開発の測定:
Docker: イメージレイヤーのキャッシュを活用
devenv: Nixストアのキャッシュを活用

 ベンチマーク結果の詳細分析
 結果サマリー

項目
Docker
devenv
差
倍率


依存関係インストール
17.65秒
24.50秒
+6.85秒
0.7倍

コンパイル
5.01秒
1.52秒
-3.49秒
3.3倍高速

サーバー起動
1.07秒
0.84秒
-0.23秒
1.3倍高速

データベース接続
1.20秒
0.72秒
-0.48秒
1.7倍高速

API応答時間
11.46秒
9.58秒
-1.88秒
1.2倍高速

外部API応答時間
12.22秒
9.59秒
-2.63秒
1.3倍高速

合計時間
48.63秒
46.74秒
-1.88秒
1.04倍高速


 各項目の詳細分析
 1. 依存関係インストール時間Docker: 17.65秒
コンテナ内での依存関係ダウンロード
イメージレイヤーの構築
ネットワークオーバーヘッド
devenv: 24.50秒
Nixパッケージマネージャーの依存関係解決
キャッシュの活用
ネイティブ環境でのダウンロード
分析: Dockerが0.7倍（devenvより1.4倍高速）。この結果は、Dockerの効率的なレイヤーキャッシュとイメージの再利用によるものです。

 2. コンパイル時間Docker: 5.01秒
コンテナ内でのコンパイル
仮想化レイヤーによるオーバーヘッド
リソース制限の影響
devenv: 1.52秒
ネイティブ環境でのコンパイル
最適化されたビルド環境
高速なファイルシステムアクセス
分析: devenvが3.3倍高速。コンテナ化によるオーバーヘッドが明確に現れています。

 3. サーバー起動時間Docker: 1.07秒
コンテナ起動のオーバーヘッド
プロセス起動の遅延
ネットワークスタックの初期化
devenv: 0.84秒
ネイティブプロセス起動
直接的なリソースアクセス
最小限のオーバーヘッド
分析: devenvが1.3倍高速。コンテナ起動のオーバーヘッドが現れています。

 4. データベース接続時間Docker: 1.20秒
コンテナ間通信のオーバーヘッド
ネットワーク設定の影響
仮想化レイヤー
devenv: 0.72秒
ローカル接続
最小限のオーバーヘッド
直接的なリソースアクセス
分析: devenvが1.7倍高速。コンテナ間通信のオーバーヘッドが影響しています。

 5. API応答時間Docker: 11.46秒
コンテナ化による若干の遅延
ネットワークスタックの影響
リソース制限
devenv: 9.58秒
ネイティブ実行
最適化されたパフォーマンス
直接的なリソースアクセス
分析: devenvが1.2倍高速。実行時のパフォーマンス差が現れています。

 6. 外部API応答時間Docker: 12.22秒
コンテナ化によるネットワーク遅延
仮想ネットワークスタックの影響
リソース制限
devenv: 9.59秒
ネイティブネットワークアクセス
最適化されたネットワークパフォーマンス
直接的なリソースアクセス
分析: devenvが1.3倍高速。外部APIへのアクセスでもコンテナ化の影響が現れています。

 技術的考察
 パフォーマンス差の根本原因
 1. コンテナ化オーバーヘッドDockerの性能差は主にコンテナ化によるオーバーヘッドが原因です：

仮想化レイヤー: コンテナランタイムによる追加レイヤー

ファイルシステム: オーバーレイファイルシステムの性能制限

ネットワーク: 仮想ネットワークスタックのオーバーヘッド

リソース制限: コンテナのリソース制限による影響

 2. ネイティブ環境の利点devenvの高性能はネイティブ環境の利点によるものです：

直接的なリソースアクセス: ホストリソースの直接活用

最適化されたファイルシステム: ネイティブファイルシステムの性能

効率的なプロセス管理: オーバーヘッドのないプロセス起動

キャッシュの活用: システムレベルでのキャッシュ効率

 3. 依存関係インストールの逆転現象興味深い発見: 今回の測定では、依存関係インストールでDockerがdevenvより高速でした。
原因分析:

Dockerのレイヤーキャッシュ: 既存のイメージレイヤーの再利用

Nixの依存関係解決: より厳密な依存関係解決による時間増加

キャッシュ状態: 測定時のキャッシュ状態の違い

 開発サイクルへの影響
 体感的な差が生じる具体的な場面1. コンパイル時間の差（3.3倍の差）

体感: Dockerでコンパイル中にコーヒーを飲みに行く時間がある vs devenvではすぐに完了

影響: デバッグサイクルが長くなり、問題の特定に時間がかかる

具体的な場面: エラー修正後の再コンパイル、新機能追加後のビルド確認
2. サーバー起動時間の差（1.3倍の差）

体感: Dockerでは起動完了まで待機時間がある vs devenvではほぼ瞬時に起動

影響: 開発の流れが途切れ、集中力が低下する

具体的な場面: 開発サーバーの再起動、設定変更後の確認
3. データベース接続の差（1.7倍の差）

体感: Dockerでは接続確立まで待機 vs devenvでは即座に接続

影響: データベース操作の確認が遅れ、開発効率が低下

具体的な場面: マイグレーション実行後の確認、データ投入後の動作確認
4. API通信の差（1.2倍の差）

体感: DockerではAPI応答に若干の遅延 vs devenvでは即座に応答

影響: フロントエンド開発でのAPI連携確認が遅れる

具体的な場面: APIエンドポイントの動作確認、フロントエンドとの連携テスト

 パフォーマンス計測外で考えられるオーバーヘッドについて
 ホットリロード性能の違い注意: 以下の説明は実際のベンチマーク測定外の一般的な傾向についてです。今回の測定ではホットリロード性能は含まれていません。
一般的な傾向: Dockerは開発環境（devenv）に比べてホットリロードの時間が長くなる傾向があります。
技術的な背景:

これは、Dockerがコンテナ内でアプリケーションを実行するという性質と、ファイルシステムの仕組みが関係しています。
ホットリロードの仕組み:
開発環境（devenv）:
ローカルPCのファイルシステムでアプリケーションが直接実行されます
ファイルを変更すると、開発サーバーがその変更を即座に検知し、メモリ上のコードを書き換えることでホットリロードを実現します
このプロセスは非常に高速です
Docker:
Dockerは、ホストPC（あなたのPC）のファイルシステムとは独立したコンテナ内でアプリケーションを動かします
ホットリロードを実現するには、ホストPCのコード変更をコンテナ内のファイルシステムに同期させる必要があります
この同期処理がオーバーヘッドとなります
体感的な影響:

開発体験: 頻繁なファイル変更を行う開発では、この差が累積して大きな影響を与えます

フィードバックループ: 変更から反映までの時間が長いと、開発の流れが阻害されます

生産性: 特にフロントエンド開発では、この差が開発効率に直接影響します

 ユースケース別の推奨環境
 1. 個人開発・小規模チーム推奨: devenv
理由:
開発速度が最優先事項
チーム規模が小さいため環境統一の複雑性が低い
高速なフィードバックループが重要
具体的なメリット:
コンパイル時間が3.3倍高速
サーバー起動が1.3倍高速
データベース接続が1.7倍高速
設定例:
# devenv.nix
{ pkgs, ... }: {
  packages = [ pkgs.git pkgs.ripgrep ];

  languages.rust.enable = true;
  
  services.postgres.enable = true;
  
  scripts.dev.exec = "cargo watch -x run";
  scripts.test.exec = "cargo test --watch";
}

 2. 中規模チーム（4-10人）推奨: ハイブリッドアプローチ
理由:
開発速度と環境統一の両方が重要
チーム間の協調が必要
本番環境との一貫性も考慮
具体的なアプローチ:

開発環境: devenv（高速性重視）

CI/CD: Docker（一貫性重視）

本番環境: Docker（信頼性重視）
設定例:
# docker-compose.yml (CI/CD用)
version: '3.8'
services:
  app:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/app
  db:
    image: postgres:15
    environment:
      - POSTGRES_DB=app
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass

 3. 大規模チーム（10人以上）推奨: プロジェクト要件による選択
Dockerを選択する場合:
本番環境との一貫性が最重要
複雑なマイクロサービスアーキテクチャ
厳格なセキュリティ要件
devenvを選択する場合:
開発速度が最重要
モノリシックアーキテクチャ
チームがNixやdevenvの使用に習熟している
ハイブリッドアプローチ:
開発環境: devenv
ステージング環境: Docker
本番環境: Docker

 4. マイクロサービス開発推奨: Docker
理由:
サービス間の分離が重要
本番環境との一貫性が必須
スケーラビリティの要求
具体的なメリット:
サービス間の完全な分離
本番環境との同一性
オーケストレーションとの親和性

 5. モノリシックアプリケーション開発推奨: devenv
理由:
開発速度が最重要
単一のコードベース
高速なフィードバックループ
具体的なメリット:
高速なコンパイル
効率的な依存関係管理
迅速な開発サイクル

 6. 研究・実験プロジェクト推奨: devenv
理由:
高速なプロトタイピング
複数の技術スタックの実験
柔軟な環境設定
設定例:
# devenv.nix
{ pkgs, ... }: {
  packages = [
    pkgs.nodejs_20
    pkgs.python311
    pkgs.go
    pkgs.rustc
  ];

  languages.rust.enable = true;
  
  # 複数の言語環境を同時に利用
  scripts.experiment.exec = "echo 'Multi-language experiment ready'";
}

 実践的な導入ガイド
 devenvの導入
 1. 初期セットアップ# devenvのインストール
curl -fsSL https://devenv.sh/install.sh | sh

# プロジェクトの初期化
devenv init

 2. 環境定義# devenv.nix
{ pkgs, ... }: {
  packages = [ pkgs.git pkgs.ripgrep ];

  languages.rust.enable = true;
  
  services.postgres.enable = true;
  services.postgres.package = pkgs.postgresql_15;
  
  env.DATABASE_URL = "postgresql://localhost:5432/app";
  env.RUST_LOG = "debug";
  
  scripts.setup.exec = "cargo install cargo-watch";
  scripts.dev.exec = "cargo watch -x run";
  scripts.test.exec = "cargo test --watch";
}

 3. チーム共有# 環境の構築
devenv up

# 開発の開始
devenv shell
cargo run

 Dockerの導入
 1. 開発環境# Dockerfile
FROM rust:1.82-alpine as builder
WORKDIR /app
COPY Cargo.toml Cargo.lock ./
RUN cargo build --release --bin dummy
COPY src/ ./src/
RUN cargo build --release

FROM alpine:latest
RUN apk add --no-cache ca-certificates
COPY --from=builder /app/target/release/app /usr/local/bin/
CMD ["app"]

 2. 開発用Compose# docker-compose.dev.yml
version: '3.8'
services:
  app:
    build: .
    ports:
      - "8000:8000"
    volumes:
      - .:/app
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/app
  db:
    image: postgres:15
    environment:
      - POSTGRES_DB=app
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass

 パフォーマンス最適化
 devenvの最適化
 1. キャッシュの活用# devenv.nix
{ pkgs, ... }: {
  languages.rust.enable = true;
  
  # ビルドキャッシュの設定
  env.CARGO_BUILD_JOBS = "8";
  env.RUSTFLAGS = "-C codegen-units=16";
}

 2. 並列処理の活用# devenv.nix
{ pkgs, ... }: {
  packages = [
    pkgs.cargo-watch
    pkgs.cargo-edit
    pkgs.cargo-audit
  ];
}

 Dockerの最適化
 1. マルチステージビルド# ビルドステージ
FROM rust:1.82-alpine as builder
WORKDIR /app
COPY Cargo.toml Cargo.lock ./
RUN cargo fetch
COPY src/ ./src/
RUN cargo build --release

# 実行ステージ
FROM alpine:latest
RUN apk add --no-cache ca-certificates
COPY --from=builder /app/target/release/app /usr/local/bin/
CMD ["app"]

 2. レイヤーの最適化# 依存関係の事前インストール
COPY Cargo.toml Cargo.lock ./
RUN cargo build --release --bin dummy
COPY src/ ./src/
RUN cargo build --release

 結論
 ベンチマーク結果の総括devenvの優位性:
合計時間で1.04倍高速（4.0%高速）
コンパイル時間で3.3倍高速
サーバー起動で1.3倍高速
データベース接続で1.7倍高速
API応答時間で1.2倍高速
Dockerの利点:
依存関係インストールで1.4倍高速
本番環境との一貫性
完全な環境分離
豊富なエコシステム
📊 パフォーマンス計測のソースコード: https://github.com/YSawc/docker-vs-devenv

 実用的な推奨事項
 開発速度重視の場合devenvを選択
個人開発
小規模チーム
モノリシックアプリケーション
研究・実験プロジェクト

 一貫性重視の場合Dockerを選択
大規模チーム
マイクロサービス
本番環境との同一性が重要な場合

 バランス重視の場合ハイブリッドアプローチ
開発環境: devenv（高速性）
CI/CD: Docker（一貫性）
本番環境: Docker（信頼性）

 最終的な判断基準
開発速度が最重要: devenv

本番環境との一貫性が最重要: Docker

両方のバランスが重要: ハイブリッドアプローチ

 重要な発見依存関係インストールの逆転現象: 今回の測定では、Dockerがdevenvより依存関係インストールで高速でした。これは、Dockerの効率的なレイヤーキャッシュとイメージの再利用によるものです。
全体的な性能差の縮小: 前回の測定と比較して、全体的な性能差が縮小しています。これは、両環境の最適化が進んでいることを示しています。
このベンチマーク結果は、実際の開発環境での性能差を明確に示しており、プロジェクトの要件に応じた最適な選択の指針となります。
この記事は実際のベンチマーク結果に基づいて執筆されています。測定環境やプロジェクトの特性により、結果が異なる場合があります。

項目	Docker	devenv	差	倍率
依存関係インストール	17.65秒	24.50秒	+6.85秒	0.7倍
コンパイル	5.01秒	1.52秒	-3.49秒	3.3倍高速
サーバー起動	1.07秒	0.84秒	-0.23秒	1.3倍高速
データベース接続	1.20秒	0.72秒	-0.48秒	1.7倍高速
API応答時間	11.46秒	9.58秒	-1.88秒	1.2倍高速
外部API応答時間	12.22秒	9.59秒	-2.63秒	1.3倍高速
合計時間	48.63秒	46.74秒	-1.88秒	1.04倍高速

コラボスタイル DevelopersPublication

「ワークスタイルの未来を切り拓く」を理念に掲げ、リアルとデジタルの2つの働く場に向けた事業展開に留まらず、自社が率先して新しいワークスタイルに挑戦し、発信を行うことでワークスタイルの未来を切り拓いていきます。

開発環境の性能比較：Docker vs devenv ベンチマーク

はじめに

なぜDockerとdevenvを比較するのか？

CI/CDにおける役割の違い

ベンチマーク概要

測定環境

測定方法

ベンチマーク結果の詳細分析

結果サマリー

各項目の詳細分析

1. 依存関係インストール時間

2. コンパイル時間

3. サーバー起動時間

4. データベース接続時間

5. API応答時間

6. 外部API応答時間

技術的考察

パフォーマンス差の根本原因

1. コンテナ化オーバーヘッド

2. ネイティブ環境の利点

3. 依存関係インストールの逆転現象

開発サイクルへの影響

体感的な差が生じる具体的な場面

パフォーマンス計測外で考えられるオーバーヘッドについて

ホットリロード性能の違い

ユースケース別の推奨環境

1. 個人開発・小規模チーム

2. 中規模チーム（4-10人）

3. 大規模チーム（10人以上）

4. マイクロサービス開発

5. モノリシックアプリケーション開発

6. 研究・実験プロジェクト

実践的な導入ガイド

devenvの導入

1. 初期セットアップ

2. 環境定義

3. チーム共有

Dockerの導入

1. 開発環境

2. 開発用Compose

パフォーマンス最適化

devenvの最適化

1. キャッシュの活用

2. 並列処理の活用

Dockerの最適化

1. マルチステージビルド

2. レイヤーの最適化

結論

ベンチマーク結果の総括

実用的な推奨事項

開発速度重視の場合

一貫性重視の場合

バランス重視の場合

最終的な判断基準

重要な発見

Discussion