7.4典型的なシステムアーキテクチャ

これまでの節で学んだ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サーバーは処理完了を待たずに応答を返せるため、利用者が体感する応答速度が向上する。

実際のサービス構築を追いながら全体像を組み立てましょう。あるブログサービスをLAMP構成（Linux＋Apache＋MySQL＋PHP）で立ち上げたとします。アクセスが増えてWebサーバー1台では遅くなってきたら、Web3層モデルの発想でWeb層とDB層を別マシンに分離し、Web/AP層はロードバランサ配下に複数台を並べてスケールアウトします。この時点でロードバランサ自体がSPoFになるため、ロードバランサも冗長化（アクティブ・スタンバイ構成）しておくのが定石です。DB層は単一のMySQLでは書き込みが集中しボトルネックになるだけでなく単一障害点にもなるため、DBレプリケーションでマスター1台・レプリカ複数台の構成にし、読み取りクエリをレプリカへ分散しつつ、マスターに障害が起きたらレプリカの1台を新マスターへ昇格させるフェイルオーバーを用意します（この昇格の自動化にPacemaker等が使われることもあります）。さらに画像やCSSなどの静的ファイルはCDNから配信して自前サーバーの負荷を減らし、頻繁に読まれるが更新頻度の低いデータ（例：トップページの集計結果）はキャッシュに置いて同じ計算を繰り返さないようにします。ユーザーが投稿した画像のサムネイル生成のような待たせる必要のない重い処理は、メッセージングキューに投入してバックエンドのワーカーが非同期に処理し、Webサーバーは「受け付けました」の応答だけをすぐ返します。こうして、LAMPという素朴な出発点から、層ごとの冗長化・キャッシュ/CDNによる高速化・非同期処理による疎結合化を積み重ねていくのが、実務でもLinuCでも問われる典型的なシステムアーキテクチャの発展の姿です。

7.4.3この節のまとめ

• LAMP=Linux+Apache+MySQL/MariaDB+PHP/Perl/Python／LAPPはDBがPostgreSQL（Webは同じApache）。Web3層モデルは層ごとに独立してスケール・冗長化
• Web/AP層＝ロードバランサ＋スケールアウト／DB層＝レプリケーション＋フェイルオーバー。CDN・キャッシュ・非同期キューで高速化と疎結合化