はじめに：なぜ、全体像を「自分の言葉で」説明する必要があるのか

Webサービスを作るにはプログラミングが必要ですが、コードだけで動いているわけではありません。
その裏側には、ブラウザ・サーバー・データベース・通信の仕組みなど、いろんな要素が関わっています。

わたし自身も最初は「サーバーってなに？」「DBってどこにあるの？」「いま自分が書いているこのコード、Webサービス全体の中でどこに位置してるんだ？」という疑問にぶつかりました。
この疑問を解消するため、まずはWebサービスの全体像と、各コンポーネントがなぜ必要で、どう連携しているのかを理解することからスタートしました。
この記事では、Webシステムの全体像をざっくり整理しつつ、図と具体例でまとめます。
あくまで自分用の整理記事ですが、同じように学習している方の参考になれば幸いです。

全体像を知るメリット

「今やってる作業が全体のどこに位置するのか？」を理解できる
新しい技術を学ぶときに迷子になりにくい
チーム開発で「その処理はどのサーバー側で動く？」と会話がスムーズになる

Webシステムのざっくり構成図

まずは全体像を図で描いてみました。

[ブラウザ] ⇄ [Webサーバー] ⇄ [アプリケーション] ⇄ [DBサーバー]

ブラウザ：ユーザーの入り口。HTML/CSS/JSを表示。
Webサーバー：ApacheやNginxなど。リクエストを受けて、アプリに渡す。
アプリケーション：LaravelやRailsなど。ビジネスロジックを処理。
DBサーバー：MySQLやPostgreSQLなど。データを保存・取得。

この流れが分かっていれば、「今自分はどこを触ってるのか？」が見失いにくくなる。

「なぜ」Webサーバーとアプリケーションサーバーを分けるのか？

学習の中で最も腑に落ちたのが、サーバー側の役割分担です。「全部一つのプログラムで動かせばいいのでは？」という素朴な疑問がありました。

コンポーネント	役割	なぜ必要か（システムの安定性・効率性）
Webサーバー	静的コンテンツ（HTML, CSS, 画像）の配信	高速性・専門性：アプリケーションロジックを処理せず、ファイル配信に特化することで、大量のリクエストを迅速にさばく。
アプリケーションサーバー	動的コンテンツ（ユーザーデータに基づくHTMLなど）の生成、ビジネスロジックの実行	安全性・分離：ロジック部分をWebサーバーから分離し、外部からの不正なリクエストが直接ロジックに触れるのを防ぐ。負荷分散もしやすくなる。

具体例１：ブログサービス

ブログサービスの場合、ざっくりと以下のような処理が行われています。

Webサーバー：「お問い合わせ」ページのCSSファイル、サイトロゴ画像など、誰が見ても同じファイルを配信。
アプリケーションサーバー：ログインユーザーの「マイページ」や、データベースから記事一覧を取得して動的に生成するHTMLを処理。

この分離は、セキュリティやスケーラビリティを確保する上で必須だと理解しました。

具体例２：ログイン処理の流れ

より理解を深めるため、「ログイン画面からIDとパスワードを送信する」場合の処理の流れを図にしました。

1. **ブラウザ**

   * ユーザーが `email` と `password` を入力し、送信ボタンを押す。
   * 送信データは **HTTPリクエスト** としてサーバーに送られる。

2. **Webサーバー（例：Nginx, Apache）**

   * 受け取ったリクエストをアプリケーションに渡す。
   * ここは「交通整理役」。直接ロジックは書かない。

3. **アプリケーション（例：Laravel, Rails, Spring）**

   * コントローラーがリクエストを受け取り、入力値をチェック。
   * データベースに「そのユーザーが存在するか？」を問い合わせる。

4. **データベース（例：MySQL, PostgreSQL）**

   * `SELECT * FROM users WHERE email = ...` のようなクエリを実行。
   * 結果をアプリケーションに返す。

5. **アプリケーション**

   * パスワードを照合。正しければ「ログイン成功」としてセッションを発行。

6. **レスポンス**

   * Webサーバーを経由してブラウザに結果を返す。
   * 成功なら「マイページ画面のHTML」や「JSONレスポンス」が返る。

「通信の仕組み」を意識する：HTTPだけではない連係プレー

ブラウザとサーバー間の通信はHTTP（またはHTTPS）ですが、サーバー内部ではさらに専門的な通信が行われています。

ブラウザ $\leftrightarrow$ Webサーバー：
通常、この間はリバースプロキシが、クライアントからのリクエストを受け付け、バックエンドのWebサーバーに転送し、サーバーからの応答をクライアントに返す仲介役を担います。これにより、セキュリティの強化、Webサーバーへの負荷分散、パフォーマンスの最適化などを実現します。
アプリケーションサーバー $\leftrightarrow$ DBサーバー：
この間はSQLなどの専用プロトコルが使われます。データベースへの接続情報は外部に公開してはならないため、DBサーバーは外部からの直接アクセスを遮断し、アプリケーションサーバーと内部ネットワークでのみ通信するのが原則です。

現場での「なぜ？」を減らす視点:
データベース接続がうまくいかない場合、「アプリケーションのコードの問題」だけでなく、「DBサーバーのファイアウォール設定」や「アプリケーションサーバーからの内部通信が許可されているか」といったインフラレイヤーの視点が必要になります。この全体像の理解が、切り分け（デバッグ）のスピードを決定づけます。

さらに必要になる要素

Webサービスが本番で動くには、これ以外にも多くの要素が絡みます。

ドメイン・DNS
→ 「example.com」がどのサーバーを指すかを解決する仕組み。
セキュリティ
→ HTTPSによる暗号化、SQLインジェクション対策、CSRF対策など。
インフラ
→ サーバーはクラウド（AWS, GCP, Azure）に置かれることが多い。
キャッシュ
→ 毎回DBに問い合わせず、メモリ上に結果を保存して高速化。

具体例３：Webページ表示の流れ

表題の疑問を解消するべく、以下の処理の流れを図にしました。
「ブラウザにURLを入力してEnterを押すと、なぜページが表示されるのか？」

[ユーザー]
    ↓ URL入力
[Webブラウザ(Chrome等)]
    ↓ HTTPリクエスト(https://example.com/login)
    ↓ ① DNS問い合わせ → IPアドレス取得
    ↓ ② TCP接続確立(3ウェイハンドシェイク)
    ↓ ③ SSL/TLS通信開始(暗号化)
    │
[インターネット]
    │
[ファイアウォール]
    ↓ 不正アクセス遮断
[ロードバランサー]
    ↓ 複数サーバーに負荷分散
    │
┌───┴───┬───────┐
│       │       │
[Webサーバー1] [Webサーバー2] [Webサーバー3]
(Nginx/Apache)
    ↓
[アプリケーションサーバー]
(Rails/Django/Node.js等)
    ↓ ビジネスロジック実行
    ├→ [キャッシュサーバー] (Redis/Memcached)
    │   └→ よく使うデータを高速取得
    │
    └→ [DBサーバー](MySQL/PostgreSQL)
        └→ ユーザー情報、投稿データ等を永続化
    
    ↓ HTMLレンダリング
[Webサーバー]
    ↓ HTTPレスポンス(HTML/CSS/JS)
[Webブラウザ]
    ↓ 画面描画
[ユーザー]

各コンポーネントの役割を具体例で理解する

1. DNSサーバー：住所録のようなもの

何をしているか
example.comというドメイン名を203.0.113.45というIPアドレスに変換します。

なぜ必要か
コンピュータ同士は数字のIPアドレスで通信しますが、人間には覚えにくい。だから「google.com」のような名前で管理しています。電話帳で「山田さん」を探して電話番号を調べるのと同じです。

具体的な動き

ブラウザが「example.comのIPアドレスは？」と問い合わせ
DNSサーバーが「203.0.113.45だよ」と返答
ブラウザはそのIPアドレスに接続

2. Webサーバー：受付係

何をしているか
HTTPリクエストを受け取り、静的ファイル(HTML/CSS/画像)を返したり、動的な処理をアプリケーションサーバーに渡したりします。

なぜ必要か
アプリケーションサーバーは複雑な処理をするため重い。単純な画像配信などはWebサーバーが高速に処理したほうが効率的です。レストランで例えるなら、ホールスタッフ(Webサーバー)が注文を受けて、簡単なドリンクはその場で出し、料理はキッチン(アプリケーションサーバー)に回すイメージ。

具体的な動き

/style.cssへのリクエスト → そのままCSSファイルを返す
/api/usersへのリクエスト → アプリケーションサーバーに転送

3. アプリケーションサーバー：料理人

何をしているか
ビジネスロジックを実行します。ログイン処理、投稿の保存、検索処理など、Webサービスの核となる処理を担当。

なぜ必要か
「このユーザーは本人か？」「この操作は許可されているか？」「データをどう加工するか？」といった複雑な判断が必要だから。

具体的な動き(ログイン処理の例)

POSTでemail=user@example.com, password=secret123を受信
DBからemailに一致するユーザーを検索
パスワードをハッシュ化して保存されているものと照合
一致したらセッションIDを生成
CookieにセッションIDをセットしてレスポンス

4. データベースサーバー：倉庫

何をしているか
データを永続化します。ユーザー情報、投稿、コメント、いいねなど、すべてのデータを保存。

なぜ必要か
メモリ上のデータはサーバーを再起動すると消えてしまいます。ディスクに保存することで、電源を切ってもデータが残ります。また、複雑な検索(「東京都に住む20代のユーザーで、最近1週間投稿していない人」など)を高速に実行できます。

具体的な動き

SELECT * FROM users WHERE email = 'user@example.com';

このようなSQL文でデータを取得・更新します。

5. キャッシュサーバー：よく使うものを手元に置く

何をしているか
頻繁にアクセスされるデータをメモリ上に一時保存します。

なぜ必要か
DBへの問い合わせは遅い(ディスクI/O)。トップページのランキングなど、全ユーザーが同じデータを見る場合、毎回DBに問い合わせるのは無駄です。

具体的な動き

ランキング情報をリクエスト
まずRedisに「ranking_dataあるか？」確認
あればそれを返す(高速)
なければDBから取得してRedisに保存(次回から高速化)

なぜ複数のサーバーに分けるのか？

理由1：役割分担で効率化

料理でも、切る人・炒める人・盛り付ける人と分業したほうが早い。同じように、静的ファイル配信・ビジネスロジック実行・データ保存を別サーバーにすると効率的です。

理由2：スケーラビリティ

アクセスが急増したとき、ボトルネックになっている部分だけサーバーを増やせます。例えば、計算処理が重ければアプリケーションサーバーだけ5台に増やす、といった対応が可能。

理由3：障害対応

1つのサーバーがダウンしても、他のサーバーでカバーできます。DBサーバーが落ちてもキャッシュサーバーから一部データを返せる、など。

代表的なセキュリティ：なぜ「通信の暗号化」「DBの隔離」が重要？

全体像を理解すると、セキュリティ対策の「なぜ」も見えてきます。

HTTPS通信(SSL/TLS)

ブラウザとWebサーバー間の通信を暗号化します。これにより、途中の盗聴者がクレジットカード情報やCookie、パスワードなどの機密情報を読み取るのを防げます。

具体例

ブラウザとサーバー間でSSL証明書を交換
共通の暗号鍵を生成
以降の通信をすべて暗号化

DBサーバーの隔離

DBサーバーを外部ネットワークから完全に隔離することで、仮にWebサーバーやアプリケーションサーバーが攻撃されても、データそのものを保護する最後の砦となります。

ファイアウォール

特定のIPアドレスやポート以外からのアクセスを遮断。

具体例

ポート80(HTTP)と443(HTTPS)だけ開放
SSH(ポート22)は社内IPからのみ許可
不審なIPからの大量アクセスをブロック

アプリケーション層のセキュリティ

SQLインジェクション対策：ユーザー入力をエスケープ
XSS対策：HTMLタグを無効化
CSRF対策：トークンで正規リクエストか確認

具体例(SQLインジェクション)

// 危険な例
query = "SELECT * FROM users WHERE email = '" + user_input + "'"
// user_inputに "' OR '1'='1" を入れると全ユーザー情報が漏洩

// 安全な例(プリペアドステートメント)
query = "SELECT * FROM users WHERE email = ?"
execute(query, [user_input]) // 自動的にエスケープされる

実際にリクエストを送ってみる

理解を深めるため、ターミナルでHTTPリクエストを送ってみました。

curl -v https://example.com/

レスポンスの一部

> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.68.0
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Content-Length: 1256
< 
<!DOCTYPE html>
<html>
...

この>がリクエスト、<がレスポンスです。実際にどんなデータをやり取りしているか目で見ると理解が深まりました。

まとめ：全体像を把握する重要性

図を描いてみることで、以下が腹落ちしました。

各技術の存在理由：なぜNginxが必要か、なぜRedisを使うか、点ではなく線で理解できた
トラブル時の切り分け：「画面が表示されない」→どこに原因があるか推測できる(DNS?Webサーバー?DB?)
学習の優先順位：今自分はどこを学んでいるか地図がある状態で進められる

まだまだ浅い理解ですが、これをベースに実際に手を動かしてWebサービスを作りながら深めていきます。

参考にした書籍

改訂新版プロになるためのWeb技術入門