導入
多くの Web サービスは、1つのプログラムで完結していません。役割の違う複数のソフトが連携して動いています。その代表が 「Webサーバー・アプリケーション・データベース」の三層構成。第7章で ss に出てきた 80・5432 といったポートが、実はこの構成を表していました。
説明
ユーザーのリクエストが、サーバーの中でどう処理されるかを見てみましょう。
flowchart LR
U["利用者<br/>ブラウザ"] -->|"HTTP :80/443"| N["① Webサーバー<br/>nginx<br/>(受付・静的ファイル)"]
N -->|"内部で橋渡し"| A["② アプリケーション<br/>あなたのプログラム<br/>(業務ロジック)"]
A -->|":5432 など"| D[("③ データベース<br/>PostgreSQL<br/>(データ保管)")]
D --> A --> N --> U
- ① Webサーバー（nginx など） … 最前線の受付。HTTP のリクエストを受け、画像や HTML などの静的ファイルはそのまま返し、動的な処理は後ろのアプリへ橋渡しします（リバースプロキシ）。ポート 80/443 で待ち受け。
- ② アプリケーション … あなたが書くプログラム本体。ログイン処理や検索など、業務ロジックを担当。必要に応じてデータベースに問い合わせます。
- ③ データベース（PostgreSQL/MySQL など） … データを保管し、問い合わせに答える。第7章で
127.0.0.1:5432としてssに出ていた——外部には公開せず、アプリからだけアクセスさせるのが定石でした。
第6章の ss -tuln を思い出してください。0.0.0.0:80（Webサーバーは外部公開）と 127.0.0.1:5432（DBは自分の中だけ）が並んでいました。あれは、まさにこの三層構成の「どこまで外に開くか」を表していたのです。
flowchart TD
A["ss -tuln の結果が語っていたこと"] --> B["0.0.0.0:80 → Webは世界に公開"]
A --> C["127.0.0.1:5432 → DBは内側だけ（安全）"]
なぜ分けるのか。役割を分離すると、それぞれを別々に増強・交換・保護できるからです。アクセスが増えたらアプリだけ増やす、DB だけ強いマシンに移す、といった調整ができます。1つの巨大なプログラムより、小さな部品を連携させる——これは第4章のパイプの思想（小さな道具をつなぐ）と、根っこは同じです。
この章のまとめ
- Web サービスは「Webサーバー・アプリ・DB」の三層が連携して動くことが多い
- Webサーバーは外部公開（80/443）、DBは内側だけ（127.0.0.1）——第6章の
ssの結果そのもの - 役割を分けると、増強・交換・保護を個別にできる