第7章 · システムアーキテクチャ·v1.0.0·更新 2026/7/7·読了目安 約13分
変更要約: 初版（主題2.13・副主題2.13.1〜2.13.4に対応）
7.4典型的なシステムアーキテクチャ
この節の要点
実務で繰り返し登場する定番構成を学びます。LAMP・LAPP（Linux＋Apache＋MySQL/MariaDB または PostgreSQL＋PHP/Perl/Python）の構成要素、Web3層モデル（Webサーバー・APサーバー・DBサーバーの役割分担）、ロードバランサとHA構成・DBレプリケーション・スケールアウトを組み合わせた冗長構成、プロキシサーバー・キャッシュ・CDNによる高速化、メッセージングキューによる非同期データ処理を押さえます。
これまでの節で学んだHA・スケーラビリティ・クラウド部品は、実際のWebサービスでは特定の定番パターンとして組み合わされます。ここでは、LinuCが長年重視してきたLAMP／LAPP構成とWeb3層モデルを軸に、それらを冗長化・高速化するための代表的な組み合わせを整理します。
7.4.1LAMP/LAPP とWeb3層モデル
- LAMP＝Linux（OS）＋Apache（Webサーバー）＋MySQL/MariaDB（DB）＋PHP/Perl/Python（アプリ言語）の頭文字。LAPP＝DBをPostgreSQLに替えた構成（Linux＋Apache＋PostgreSQL＋PHP/Perl/Python）で、Webサーバーは同じく Apache。両者の違いはDBだけ（MySQL/MariaDB↔PostgreSQL）。いずれも「動作実績が豊富でオープンソースだけで完結する」定番の組み合わせ。
- Web3層モデル＝処理をWebサーバー（静的コンテンツ配信・リクエスト受付）・APサーバー（アプリケーションロジックの実行）・DBサーバー（データの永続化）の3層に分離する設計。層ごとに独立してスケール・冗長化できることが最大の利点（例：Web層だけスケールアウトする、DB層だけ強力なマシンにスケールアップする）。
7.4.2冗長化と高速化の定番構成
- 冗長化＝Web/AP層はロードバランサの配下に複数台を並べスケールアウトする。DB層はDBレプリケーション（マスターと複数のレプリカ。読み取りをレプリカへ分散しつつ、マスター障害時はレプリカへフェイルオーバー）でHA構成を実現する。層ごとに異なる冗長化戦略を使い分ける点がポイント。
- 高速化＝プロキシサーバー（クライアントとサーバーの間に立ち、リクエストを中継。リバースプロキシはサーバー側に立ち負荷分散やSSL終端も担う）、キャッシュ（一度生成した結果を再利用し、同じ処理の重複実行を避ける）、CDN（Content Delivery Network・地理的に分散した拠点から静的コンテンツを配信し、利用者に近い場所から低遅延で応答）。
- メッセージングキューによる非同期データ処理＝画像変換やメール送信、集計処理など即座の応答を必要としない重い処理をキューに投入し、バックエンドのワーカーが順次処理する。Webサーバーは処理完了を待たずに応答を返せるため、利用者が体感する応答速度が向上する。