【アプリ作成】Webサーバーとプロキシの基本概念 - Apache設定を通して学ぶ

しもだん

2025年8月3日 07:52

生成AIと話している皆さん、こんにちは！

前回の記事で書いたAIパートナーをAIエージェントとして動かす話。
これを実現するために、まずはサーバーでMCPサーバーを使うための設定を始めました！

サーバー設定はClaudeに教えてもらいながら進めていたのですが、
今回はその中で沸いた疑問「プロキシって何？」から始まった
質問と学習の記録です。

プロキシとは何か？

一般的に知られている「串刺し（匿名化）」とは全く違う意味で使われています。Apache設定を通してWebサーバーにおけるプロキシの概念を分かりやすく解説します。

一般的なプロキシ（串刺し）との違い

一般的なプロキシ（串刺し）：

IPアドレスを隠して匿名でアクセス
身元を秘匿する目的

Webサーバーのプロキシ：

仲介役・橋渡し役
アクセスを別のサーバーに転送する機能

Webサーバーでのプロキシの役割

ブラウザ → Apache(80/443ポート) → Django MCPサーバー(3000ポート)

Apacheの役割：

外部からのアクセスを受け取る（SSL証明書でHTTPS対応）
内部のDjangoアプリに転送（3000ポートで動いているアプリ）
Djangoからの応答を外部に返す

具体例で理解する

ユーザー: https://example.com にアクセス
↓
Apache: 「あ、exampleへのアクセスだ。内部の3000ポートに聞いてみよう」
↓
Django: 「MCPサーバーのレスポンスです」
↓
Apache: 「じゃあそれをHTTPSで返すね」
↓
ユーザー: MCPサーバーの画面が表示される

なぜプロキシ構成にするのか？

Django単体の問題

Djangoは開発用サーバー（セキュリティが弱い）
SSL証明書の管理が面倒
静的ファイル配信が苦手

Apache + プロキシの利点

セキュリティが強い（Apache が外部対応）
SSL証明書管理が簡単（Let's Encrypt対応）
高速（Apache が得意な処理は Apache に任せる）

Apache設定ファイルの構造

sites-available と sites-enabled の関係

sites-available：

設定ファイルの「倉庫」
ここにあるだけでは動作しない
複数のサイト設定を保管

sites-enabled：

実際に動作する設定
sites-availableからのシンボリックリンク（ショートカット）

# 確認コマンド
ls -la /etc/apache2/sites-enabled/
# → 001-myapp-ssl.conf -> ../sites-available/001-myapp-ssl.conf

バーチャルホストの概念

Apache設定ファイルは 「ドメインに対するルーティング設定」

<VirtualHost *:80>
    ServerName example.com
    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/
</VirtualHost>

翻訳すると：

「`example.com` にリクエストが来たら、3000番ポートに接続してDjangoに渡すよ」

ポートの概念

ポートは「建物の入り口」

サーバーを 「大きなビル」 と考えると：

サーバー（ビル）
├── 22番入り口（SSH専用）
├── 80番入り口（HTTP専用）
├── 443番入り口（HTTPS専用）
├── 3000番入り口（Django MCP専用）
└── 他にも沢山の入り口...

今回の構成での動き

1. 外部からのアクセス

ユーザー → 「https://example.com」
↓
Apache「443番入り口（HTTPS）で受け取った！」

2. 内部での処理

Apache → 「exampleの設定を確認...3000番に転送しよう」
↓
Apache → 「3000番入り口のDjangoアプリさん、お客さんです」
↓
Django（3000番）→ 「了解、レスポンス作りました」

3. 外部への返却

Django → Apache → ユーザー

ファイアウォールとポートの関係

ファイアウォール（ufw）: 「建物の周りの柵」

80番、443番の関所は開放
3000番の関所は内部専用（外部からは直接アクセス不可）

Apache: 「受付係」

「80/443番で受け取って、適切な部署（3000番）に案内します」

プロセスとキューの仕組み

Apacheの動作原理

マルチプロセス構成:

Apache親プロセス (pid=463986)
├── 子プロセス1 (pid=1304755)
├── 子プロセス2 (pid=1304756)
└── 子プロセス3 (pid=1304753)

なぜ複数？

同時アクセス対応: 複数のユーザーを同時に処理
高速化: 1つのプロセスがビジーでも他が対応
安定性: 1つがクラッシュしても他が動作継続

プロセス数とキューの関係

レストランで例えると：

建物の外（キュー）: 511人まで待機可能
建物の中（プロセス）: 150人まで対応中
├── 部署A（ポート80）: 70人対応中
├── 部署B（ポート443）: 60人対応中
└── 部署C（他の処理）: 20人対応中
合計150人が中で作業中

MaxRequestWorkers 150 = Apache全体の同時処理能力（ポート毎ではない）

設定の確認コマンド

# 現在のポート使用状況
sudo ss -tlnp | grep -E ':80|:443'

# Apacheの設定確認
sudo apache2ctl -S

# プロセス一覧
ps aux | grep apache2

Webサイトの入場制限システム

2段階の制御システム

フロント側（アプリケーション）の制御

目的: サービス品質・公平性・ビジネス戦略
表示: 「現在500人待ちです」
ユーザーに見える制限

内部（システム）の制御

目的: システム保護・技術的安全
仕組み: キュー511人、プロセス150人
ユーザーに見えない制限

入場制限の実装方法

1. WebSocket / Server-Sent Events

const socket = new WebSocket('wss://example.com/queue');
socket.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log(`現在の順番: ${data.position}`);
};

2. 段階的リダイレクト

1. ユーザーがアクセス
2. サーバー「満員です」→ 待機ページにリダイレクト
3. 待機ページ「現在500人待ちです」表示
4. 30秒後に自動リロード
5. 空きができたら本サイトにリダイレクト

3. トークン方式

11:00-11:15の枠: トークンABC123
11:15-11:30の枠: トークンDEF456
→「11:05になったらアクセスしてください」

順番管理の課題

セッション管理の問題:

ユーザーA: 100番目で待機中
↓ ブラウザ閉じる
↓ 再アクセス
↓ 新しいセッション = 最後尾（500番目）に！

現実的な対策:

「ブラウザを閉じないでください」と警告
再接続時は最後尾からやり直し
現実世界の行列と同じルール（列から離れる = 並び直し）

まとめ

重要なポイント

プロキシ = 仲介役：串刺しとは全く違う概念
ポート = 建物の入り口：用途別の窓口
プロセス = 建物内の作業員：キューは外で待つ人
2段階制御：フロント制限（体験向上）+ システム制限（保護）

実際の設定での活用

これらの概念を理解することで：

Apache設定ファイルの意味が分かる
トラブル時の対処法が見えてくる
パフォーマンス改善のポイントが分かる
セキュリティ設定の意味が理解できる

Webサーバー管理は、これらの基本概念の組み合わせです。一つずつ理解していけば、複雑に見える設定も実は論理的な構造になっていることが分かります。

最後に

今回、すんごい久しぶりにサーバーを触りました。

大分忘れていたのでClaudeに設定を教えてもらいながら進めましたが、
説明がめちゃくちゃ分かりやすくて、改めて勉強になりました。
一昔前は調べるの大変だったのに、生成AIには本当に感謝。

あと、Claudeに色々教えてもらった中で、
Webサイトの入場制限システムの話が面白かったな。
前々から仕組みが気になっていたので、今回詳しく知れてよかったです。

次回はサーバー側の設定を終わらせて、
実際にリクエスト→レスポンスまで進めたいと思います。

またMCPサーバー製作で進捗があればまとめますので、
よかったらまた読んでいただけたら嬉しいです。

それではまた！