STEP 2：Dockerが解決する問題

🎯 1. 環境差異の問題「私の環境では動くのに」

1-1. 開発者を悩ませる最も有名な問題

ソフトウェア開発の世界で、最も有名で厄介な問題の1つが「Works on my machine（私のマシンでは動く）」問題です。

この問題は、開発者が自分のパソコンで完璧に動作することを確認したコードが、別の人のパソコンや本番サーバーでは動かないという状況です。

🎬 よくある会話パターン

開発者：「データ処理スクリプト完成しました！動作確認もバッチリです」

テスター：「実行してみたけど、エラーが出て動きません…」

開発者：「えっ！？私のパソコンでは完璧に動くのに…」

テスター：「でも実際エラーが出てるんですよ」

開発者：「ちょっと待って、そちらの環境を見せてもらえますか？」

（1時間後）

開発者：「あ、Pythonのバージョンが違いますね…」

1-2. なぜ環境が違うと動かないのか？

プログラムが動作するには、そのプログラム自体だけでなく、周辺の環境が必要です。
この環境が少しでも違うと、同じプログラムでも動かなくなることがあります。

環境を構成する要素

要素	説明	違いによる影響
OS	Windows、Mac、Linux	ファイルパスの書き方、改行コード、利用可能なコマンドが異なる
言語バージョン	Python 3.8、3.9、3.10など	新しい構文が使えない、挙動が変わる
ライブラリ	pandas、numpy、requestsなど	インストールの有無、バージョン違いでエラー
環境変数	PATH、DB接続情報など	設定されていないと動作しない
外部サービス	データベース、APIなど	バージョン違い、接続設定の違い

具体的な環境の違いの例

【開発者Aさんの環境】

OS: Windows 11
Python: 3.10.5
pandas: 2.0.1
numpy: 1.24.0
PostgreSQL: 14.2
環境変数: DB_HOST=localhost

【テスターBさんの環境】

OS: Windows 10
Python: 3.8.10     ← バージョンが違う！
pandas: 1.3.5      ← バージョンが違う！
numpy: 1.21.0      ← バージョンが違う！
PostgreSQL: 13.5   ← バージョンが違う！
環境変数: なし      ← 設定されていない！

→ これだけ違えば、動かなくて当然…

1-3. 環境の違いで起きる具体的なエラー

実際にどんなエラーが起きるのか、具体例を見てみましょう。

例1：Pythonバージョンの違いによるエラー

📝 Python 3.9以降で追加された辞書のマージ演算子

以下のコードは、Python 3.9以降でのみ動作します。

# 開発者がPython 3.10で書いたコード
data = {1: ‘a’, 2: ‘b’}
result = data | {3: ‘c’}  # 辞書のマージ（|演算子）
print(result)  # {1: ‘a’, 2: ‘b’, 3: ‘c’}

⚠️ Python 3.8で実行した場合のエラー

SyntaxError: invalid syntax File “script.py”, line 2 result = data | {3: ‘c’} ^

原因：Python 3.8には|演算子による辞書マージ機能がない

例2：ライブラリバージョンの違いによるエラー

📝 pandas 1.0.0以降で追加されたto_markdown()メソッド

以下のコードは、pandas 1.0.0以降でのみ動作します。

# 開発者がpandas 2.0で書いたコード
import pandas as pd

df = pd.DataFrame({‘A’: [1, 2], ‘B’: [3, 4]})
print(df.to_markdown())  # Markdown形式で出力

⚠️ pandas 0.25で実行した場合のエラー

AttributeError: ‘DataFrame’ object has no attribute ‘to_markdown’

原因：古いバージョンのpandasにはto_markdown()メソッドがない

例3：OSの違いによるエラー

📝 Windowsで書いたファイルパス

WindowsとLinux/Macでは、ファイルパスの書き方が異なります。

# Windowsで書いたコード
file_path = “C:\\Users\\tanaka\\data\\sales.csv”
df = pd.read_csv(file_path)

⚠️ Linuxで実行した場合のエラー

FileNotFoundError: [Errno 2] No such file or directory: ‘C:\\Users\\tanaka\\data\\sales.csv’

原因：LinuxにはCドライブという概念がない。パスの構造が根本的に異なる。

1-4. Dockerによる解決方法

Dockerを使うと、環境ごとアプリケーションを配布できるため、環境差異の問題が解消されます。

✅ Dockerコンテナに含まれるもの

【Dockerコンテナの中身】

基盤:
  – Linux (Ubuntu 20.04)  ← OSレベルで統一

言語:
  – Python 3.10.5        ← バージョン固定

ライブラリ:
  – pandas 2.0.1         ← バージョン固定
  – numpy 1.24.0         ← バージョン固定
  – psycopg2 2.9.5       ← バージョン固定

外部サービス:
  – PostgreSQL 14.2      ← バージョン固定

設定:
  – 環境変数             ← すべて設定済み
  – 設定ファイル         ← 含まれている

アプリケーション:
  – 開発したコード       ← もちろん含まれる

↓

このコンテナを配布すれば…
→ 誰のパソコンでも同じ環境で動く！
→ 「私の環境では動く」問題が消滅！

💡 Dockerを使った後の会話

開発者：「コード完成しました。このDockerコンテナを使ってください」

テスター：「コンテナを起動しました。完璧に動いてます！」

開発者：「ですよね。環境は全部コンテナに入ってますから」

→ 環境の違いを心配する必要がなくなる！

🔥 2. 依存関係地獄（Dependency Hell）

2-1. 依存関係地獄とは何か？

依存関係地獄（Dependency Hell）とは、複数のアプリケーションが互いに矛盾するバージョンのライブラリを必要とする状況のことです。

この問題は、プログラミング言語やフレームワークを問わず、あらゆる開発現場で発生します。

📦 依存関係とは？

あるプログラムが動くために必要とする別のプログラム（ライブラリ）のことです。

例：「このPythonスクリプトを動かすには、pandasとnumpyが必要」
→ pandasとnumpyは「依存関係」

2-2. 依存関係地獄の具体例

シナリオ：2つのプロジェクトを同時に担当

🎬 よくある状況

あなたは2つのプロジェクトを担当することになりました。

プロジェクトA：5年前に開発されたレガシーシステム。Django 2.2が必要。
プロジェクトB：新規開発中のシステム。Django 4.0が必要。

同じパソコンで両方開発したいけど…どうする？

⚠️ 問題：Djangoは1つしかインストールできない

# Django 2.2をインストール
pip install django==2.2

# Django 4.0をインストールしようとすると…
pip install django==4.0

→ Django 2.2が上書きされて消える！
→ プロジェクトAが動かなくなる…

より複雑な依存関係の例

実際の開発では、もっと複雑な依存関係の問題が発生します。

【状況】

アプリケーションA（売上分析システム）:
  – requests 2.25.1 が必要
  – requests 2.25.1 は chardet < 5.0 に依存

アプリケーションB（顧客管理システム）:
  - requests 2.28.0 が必要
  - requests 2.28.0 は charset-normalizer >= 2.0 に依存
  – charset-normalizer は chardet と互換性がない

【図で表すと】

アプリA ──需要──▶ requests 2.25.1 ──依存──▶ chardet < 5.0
                                              ↓
                                           【競合】
                                              ↑
アプリB ──需要──▶ requests 2.28.0 ──依存──▶ charset-normalizer

【問題】
- chardet と charset-normalizer は同時に使えない
- どちらか一方しかインストールできない
- つまり、アプリAとアプリBは共存できない！

2-3. 従来の解決策とその限界

この問題に対して、いくつかの解決策が考えられてきました。

解決策1：Python仮想環境（venv / virtualenv）

項目	できること	できないこと
分離対象	Pythonライブラリを分離できる	Pythonバージョン自体は分離不可
データベース	–	PostgreSQL等は分離不可
OS	–	OSレベルの違いは解決不可
配布	requirements.txtで共有	環境自体の配布は不可

# venvの使用例
python -m venv project_a_env  # プロジェクトA用の仮想環境
python -m venv project_b_env  # プロジェクトB用の仮想環境

# 問題点
# 1. Pythonバージョン自体は共通（Python 3.8と3.10を切り替えられない）
# 2. PostgreSQLやRedisなどは分離できない
# 3. OSレベルの違いは解決できない

解決策2：Docker（完全な解決）

✅ Dockerなら「すべて」を分離できる

【コンテナA（プロジェクトA用）】
完全に独立した環境
├─ Linux (Ubuntu 18.04)
├─ Python 3.8
├─ Django 2.2
├─ PostgreSQL 12
├─ Redis 5.0
└─ 必要なすべてのライブラリ

【コンテナB（プロジェクトB用）】
完全に独立した環境
├─ Linux (Ubuntu 22.04)
├─ Python 3.10
├─ Django 4.0
├─ PostgreSQL 15
├─ Redis 7.0
└─ 必要なすべてのライブラリ

→ 2つのコンテナは完全に独立
→ お互いに干渉しない
→ 両方同時に動かせる！

2-4. Dockerによる依存関係問題の解決

実際にDockerでどのように解決するか見てみましょう。

# プロジェクトAで作業するとき
cd project-a
docker-compose up -d    # プロジェクトA用のコンテナを起動

# プロジェクトBに切り替えるとき
cd ../project-b
docker-compose up -d    # プロジェクトB用のコンテナを起動

# 両方同時に起動することも可能！
# ポート番号を変えれば競合しない

💡 依存関係地獄からの解放

Dockerを使うことで、以下の問題がすべて解決されます：

言語バージョンの競合：各コンテナで別のPythonバージョンを使用可能
ライブラリの競合：各コンテナで別のバージョンを使用可能
データベースの競合：各コンテナで別のPostgreSQLを起動可能
OS依存の問題：すべてLinuxで統一される

🚀 3. デプロイの複雑さ

3-1. デプロイとは？

📦 デプロイ（Deploy）= 配置・展開

開発したアプリケーションを、本番サーバーに配置して、ユーザーが使える状態にすることです。

デプロイは開発のゴールであり、ここでつまずくと、せっかく作ったアプリケーションをユーザーに届けられません。

3-2. 従来のデプロイの大変さ

Dockerを使わない従来のデプロイは、非常に多くの手順が必要でした。

😰 従来のデプロイ手順（Pythonアプリの場合）

【Step 1】サーバーにログイン
ssh user@production-server.com

【Step 2】OSの更新
sudo apt-get update
sudo apt-get upgrade

【Step 3】Pythonをインストール
sudo apt-get install python3.10
sudo apt-get install python3.10-venv
sudo apt-get install python3.10-dev

【Step 4】データベースをインストール
sudo apt-get install postgresql
sudo systemctl start postgresql
sudo systemctl enable postgresql

【Step 5】Webサーバーをインストール
sudo apt-get install nginx
# 設定ファイルを編集…

【Step 6】アプリケーションコードを転送
git clone https://github.com/yourcompany/app.git
cd app

【Step 7】仮想環境を作成
python3.10 -m venv venv
source venv/bin/activate

【Step 8】依存ライブラリをインストール
pip install -r requirements.txt
# エラーが出たら調査して対処…

【Step 9】データベースを設定
sudo -u postgres createdb myapp_db
sudo -u postgres psql -c “CREATE USER myapp WITH PASSWORD ‘xxx’;”
# マイグレーションを実行…

【Step 10】環境変数を設定
export DB_HOST=localhost
export DB_PASSWORD=xxx
export SECRET_KEY=xxx
# 設定ファイルに永続化…

【Step 11】アプリケーションを起動
gunicorn myapp:app –bind 0.0.0.0:8000 –daemon

【Step 12】Nginxを設定
# /etc/nginx/sites-available/myapp を編集
sudo nginx -t
sudo systemctl reload nginx

【Step 13】動作確認
curl http://localhost
# エラーが出たらログを確認して対処…

→ ここまでで合計: 数時間〜数日

⚠️ 従来のデプロイの問題点

時間がかかる：数時間〜数日
ミスが起きやすい：手作業が多いため
再現性がない：同じ手順でも結果が違うことがある
スキルが必要：サーバー管理の専門知識が必要
ドキュメント化が大変：手順書の作成・更新が必要

3-3. Dockerを使ったデプロイ

Dockerを使うと、デプロイが劇的に簡単になります。

✅ Dockerでのデプロイ手順

【Step 1】サーバーにログイン
ssh user@production-server.com

【Step 2】Dockerをインストール（初回のみ）
# 公式スクリプトで簡単インストール
curl -fsSL https://get.docker.com | sh

【Step 3】コンテナイメージをダウンロード
docker pull mycompany/myapp:v1.2.3

【Step 4】コンテナを起動
docker run -d -p 80:8000 mycompany/myapp:v1.2.3

【完了！】
→ 合計: 数分で完了

3-4. なぜDockerだとこんなに簡単なのか？

Dockerコンテナには、アプリケーションを動かすために必要なものがすべて含まれているからです。

🎁 コンテナの中身（すでに構築済み）Dockerコンテナの中身:
├─ OS環境（Linux Ubuntu）      ← 構築済み
├─ Python 3.10                ← インストール済み
├─ 依存ライブラリ全部          ← インストール済み
├─ アプリケーションコード      ← 配置済み
├─ 設定ファイル               ← 設定済み
└─ 起動コマンド               ← 設定済み

サーバー側で必要な作業:
├─ Dockerのインストール（初回のみ）
└─ コンテナの起動（docker run）

→ サーバー側ではほとんど何もしなくていい！

3-5. デプロイにおけるDockerのメリット

⏰ 時間短縮

従来：数時間〜数日
Docker：数分

100倍以上速い

🔒 安全性向上

手作業が減る
→ ヒューマンエラーが減る

ミスが起きにくい

🔄 ロールバック

問題が起きたら
前のバージョンに戻すだけ

数秒で復旧

📋 再現性100%

開発環境と同じコンテナ
→ 本番でも同じ動作

環境差異ゼロ

ロールバックの具体例

# 現在のバージョン（v1.2.3）に問題発生！
docker stop myapp
docker rm myapp

# 前のバージョン（v1.2.2）に戻す
docker run -d –name myapp -p 80:8000 mycompany/myapp:v1.2.2

# これだけ！数秒で復旧完了

💡 デプロイの心理的負担の軽減

従来のデプロイは「失敗したらどうしよう」という不安がつきものでした。
Dockerを使えば、簡単にロールバックできるため、安心してデプロイできます。

これにより、デプロイの頻度を上げることができ、小さな変更を頻繁にリリースする現代的な開発スタイルが可能になります。

📈 4. スケーラビリティ（拡張性）の課題

4-1. スケーラビリティとは？

📊 スケーラビリティ = 拡張性

システムへのアクセスや負荷が増えた時に、処理能力を拡張できる性質のことです。

ビジネスが成長すると、アクセス数も増えます。その時に素早く対応できるかどうかが、サービスの成否を分けます。

4-2. スケーラビリティが必要な場面

🎬 シナリオ：ECサイトの年末セール

あなたはECサイトのインフラ担当です。

通常時：1,000リクエスト/分 → サーバー1台で対応可能
セール開始：10,000リクエスト/分 → 10倍に急増！
問題：サーバー1台では処理しきれない → サイトがダウン！

→ 素早くサーバーを増やさないと、売上機会を失う！

4-3. 従来の方法（時間がかかる）

😰 従来のサーバー増設手順

【手順】
1. 新しいサーバーを準備・契約（数時間〜数日）
2. OSをインストール（30分〜1時間）
3. 各種ソフトウェアをインストール（数時間）
   – Python、PostgreSQL、Nginx等
4. アプリケーションをデプロイ（数時間）
   – コード転送、ライブラリインストール等
5. 設定ファイルを調整（1時間）
6. 動作テスト（1時間）
7. ロードバランサーに追加（30分）

→ 合計: 最短でも1日、通常は数日かかる
→ セールが終わってからサーバー増設完了…意味なし！

4-4. Dockerを使った方法（超高速）

✅ Dockerでのサーバー増設

# 負荷が増えたら、コンテナを追加で起動するだけ！

# コンテナ1台目（すでに起動中）
docker run -d –name app1 -p 8001:8000 myapp:latest

# コンテナ2台目を追加
docker run -d –name app2 -p 8002:8000 myapp:latest

# コンテナ3台目を追加
docker run -d –name app3 -p 8003:8000 myapp:latest

# さらに必要なら…
docker run -d –name app4 -p 8004:8000 myapp:latest
docker run -d –name app5 -p 8005:8000 myapp:latest

→ 各コマンドは数秒で完了
→ 合計でも数分でサーバー5台分の処理能力に！

4-5. 自動スケーリング

DockerとKubernetesなどのオーケストレーションツールを組み合わせると、負荷に応じて自動でコンテナを増減できます。

🤖 自動スケーリングの仕組み【自動スケーリングのフロー】

① 通常時
   コンテナ3台で運用
   CPU使用率: 30%

② 負荷増加を検知
   CPU使用率: 80%を超えた！
   ↓
   自動でコンテナを追加起動
   3台 → 5台 → 10台

③ ピーク時
   コンテナ10台で対応
   CPU使用率: 60%で安定

④ 負荷減少を検知
   CPU使用率: 20%に低下
   ↓
   自動でコンテナを削減
   10台 → 5台 → 3台

⑤ 通常時に戻る
   コンテナ3台で運用

【メリット】
– 人間が操作する必要なし
– 24時間365日自動で対応
– コスト最適化（使わない分は削減）

4-6. スケーラビリティの比較

項目	従来の方法	Docker
増設時間	数時間〜数日	数秒〜数分
自動化	困難（スクリプト作成が必要）	Kubernetesで簡単に実現
コスト	固定費（使わなくても費用発生）	従量課金（使った分だけ）
リスク	設定ミスのリスク高	同じコンテナなのでリスク低

🌟 5. Dockerの普及理由と業界での位置づけ

5-1. Dockerが業界標準になった理由

2013年に登場したDockerは、わずか数年で業界標準の技術になりました。
その理由を見てみましょう。

1️⃣ 学習コストが低い

基本コマンドは10個程度
初心者でも1週間で基礎習得
このコースで完全マスター可能

2️⃣ エコシステム充実

Docker Hub: 公式イメージ豊富
Docker Compose: 複数コンテナ管理
Kubernetes: 本番運用

3️⃣ クロスプラットフォーム

Windows、Mac、Linuxで動作
チーム全員が同じツール使用
OSの違いを気にしない

4️⃣ クラウドネイティブ

AWS、Azure、GCPが完全対応
クラウド時代の標準技術
将来性が高い

5-2. 市場データで見るDockerの普及

        📊 Dockerの普及状況（2024年時点）
        世界中で1,500万人以上の開発者が使用
Docker Hubからのダウンロード数：年間1,300億回以上
67%以上の企業がコンテナ技術を本番環境で採用
コンテナ関連の求人数：年々増加
Fortune 500企業の過半数がDockerを使用

    

5-3. 大手企業の採用事例

企業	Dockerの活用方法	効果
Netflix	数千のマイクロサービスを管理	世界中への高速な配信を実現
Spotify	開発・テスト・本番すべてでDocker使用	デプロイ時間を大幅短縮
PayPal	VM から Docker への移行	開発スピードが2倍に向上
Uber	世界中のサービスをコンテナで展開	グローバルな一貫性を確保

5-4. 就職・転職市場での価値

💼 データエンジニア・バックエンドエンジニアの求人要件

現在の求人市場では、以下のような要件が一般的です：

Docker経験：必須またはあると望ましい
Kubernetes経験：あると望ましい（大規模システムでは必須）
CI/CD経験：Docker と組み合わせて使用
クラウド経験（AWS/GCP/Azure）：Dockerデプロイ経験を含む

→ Dockerスキルは現代の開発者にとって必須！

5-5. データエンジニアリングでのDocker活用

データエンジニアリングの分野では、特にDockerの活用が進んでいます。

ツール	Docker活用方法	メリット
PostgreSQL	データベースをコンテナで起動	バージョン管理が容易、複数インスタンス起動可能
Apache Airflow	ETLパイプラインの実行環境	複雑な依存関係を一括管理
Apache Spark	分散処理環境の構築	クラスター構成を簡単に再現
Jupyter Notebook	分析環境をコンテナ化	プロジェクトごとに環境を分離

🔧 このコースで学ぶ内容

このコースでは、上記すべてのツールをDockerで構築・運用する方法を学びます。
コースを修了すると、以下のことができるようになります：

PostgreSQLコンテナでデータベース環境を構築
Airflowコンテナでワークフロー管理環境を構築
Sparkコンテナで分散処理環境を構築
Docker Composeで複数コンテナを連携
CI/CDパイプラインでの自動デプロイ

📝 STEP 2 のまとめ

        ✅ このステップで学んだこと
        環境差異の問題：「私の環境では動く」問題をDockerで解決
依存関係地獄：ライブラリの競合をコンテナの分離で解決
デプロイの複雑さ：数時間の作業が数分に短縮
スケーラビリティ：コンテナの複製で簡単にサーバー増設
業界標準：Dockerは現代の開発者必須スキル
データエンジニアリング：Airflow、Spark、PostgreSQLで活用

    

📊 Dockerが解決する問題の一覧

問題	従来の状況	Dockerでの解決
環境差異	開発者ごとに環境が違う	環境ごとコンテナで配布
依存関係	ライブラリのバージョン競合	コンテナで完全に分離
デプロイ	数時間〜数日の手作業	数分で完了
スケーリング	サーバー増設に数日	数秒で追加可能

💡 重要ポイント

Dockerは単なる便利ツールではなく、ソフトウェア開発の常識を変えた革命的な技術です。
「環境の違い」「依存関係の問題」「デプロイの複雑さ」という長年の課題を一気に解決しました。

次のSTEP 3では、いよいよDockerを実際にインストールして、使い始める準備をしていきましょう！

🎯 次のステップの予告

次のSTEP 3では、「Dockerのインストールと初期設定」を行います。

Windows、Mac、Linuxそれぞれのインストール方法
Docker Desktopの初期設定
Hello Worldコンテナの実行
トラブルシューティング

いよいよ実際にDockerを動かしてみましょう！

🐳 STEP 2: Dockerが解決する問題

📋 このステップで学ぶこと