図で理解するWebサーバとDBサーバの仕組み【初心者向け】

ゲームで例えると、
何もスキルを持っていないキャラクターに魔法を覚えさせて「魔法使い」にするイメージです。

サーバも同じで、ソフトウェアを入れることで役割が決まります。

実際の流れ（Webサイトへログインする流れ）

ここで、実際にクライアントがWebサイトへログインする流れを見てみましょう。

クライアントのブラウザ（例：Chrome）でIDとパスワードを入力し、ログインボタンをクリックします。

① ブラウザからWebサーバへ「ログインしたい」というリクエストを送信
② Webサーバが受け取り、DBサーバへ「このユーザー情報を確認してほしい」と問い合わせ
③ DBサーバがユーザー情報をWebサーバへ返す
④ Webサーバが、入力されたパスワードとDBの情報を照合（認証）
⑤ 問題なければログイン成功としてページを表示、問題があればエラーメッセージを表示

このように、DBサーバはあくまで情報を返す役割で、実際の判断はWebサーバ側で行われます。

なぜWebサーバとDBサーバは分けるのか？

ここまでで、WebサーバとDBサーバの役割について説明してきました。

ただ、ここで一つ疑問が出てきます。

「最初から1つのサーバで全部やれば楽なのでは？」

確かに小規模なシステムであれば、Web機能とDB機能を同じサーバで動かすことも可能です。

しかし実際の現場では、ほとんどの場合でサーバは役割ごとに分けられています。

その理由はいくつかあります。

負荷を分散するため

WebサーバとDBサーバでは、求められる処理が大きく違います。

・Webサーバ：リクエストを受けて画面を返す処理
・DBサーバ：データの検索・更新などの重い処理

同じサーバでWebとDBを動かすと、CPU・メモリ・ディスクといった限られたリソースを両方が使い合うため、結果として処理待ちが発生しやすくなり、パフォーマンスが低下します。

そのため役割を分けることで、それぞれに適した負荷分散ができるようになります。

セキュリティを高めるため

DBサーバには、ユーザー情報やパスワードなどの重要なデータが保存されています。

もしWebサーバとDBサーバを分けずに構成してしまうと、以下のようなリスクが発生します。

・DBサーバがインターネットから直接アクセスできる状態になる
・攻撃者によりデータベースが直接狙われる可能性が高くなる
・ユーザー情報（氏名・パスワードなど）に直接アクセスされる危険がある
・システムの防御層がなくなり、セキュリティが大幅に低下する

システムの可用性を高めるため

同じサーバにWebとDBをまとめている場合、そのサーバ自体がダウンすると、Web機能とDB機能の両方が同時に停止してしまいます。

つまりシステム全体が止まる“単一障害点”になってしまいます。

そのため役割を分けることで、障害が発生しても影響範囲を限定し、システム全体が止まるリスクを下げることができます。

まとめ

WebサーバとDBサーバは、単なる名称の違いではなく、それぞれに明確な役割があります。

同じサーバでまとめて運用することも可能ですが、実際の現場では基本的に分けて構成されます。

その理由は以下の3つです。

・負荷を分散させるため
・セキュリティを高めるため
・システムの可用性を高めるため

このように役割を分けることで、システムの性能・安全性・安定性をバランスよく確保することができます。

インフラ設計では、「分けること」が安定性を高める基本的な考え方になります。