変更要約: 初版
2.3Web多層アーキテクチャ
3層クライアントサーバをWeb向けに発展させたプレゼンテーション層・アプリケーション層・データ層の構成、サーバがクライアントの状態を保持しないステートレス設計、セッション情報を外部ストアへ切り出すセッション外部化、そしてサーバ台数を増やして負荷に対応するスケールアウトの考え方を学びます。
Webシステムの利用者数が急増すると、システムアーキテクトは「サーバを増やして負荷を捌けるか」という問いに直面します。この問いに簡単に「はい」と答えられるかどうかは、実は各サーバのステートレス設計にかかっています。サーバがクライアントごとの状態（ログイン情報や作業途中のデータ）を自分の中に抱え込んでいると、サーバを単純に増やすだけでは正しく動作しません。この節では、Web多層アーキテクチャの層構成と、スケールアウトを可能にするステートレス設計・セッション外部化の考え方を学びます。
2.3.1プレゼンテーション・アプリケーション・データ層
- プレゼンテーション層＝画面表示・入力受付を担う層（Webサーバ・フロントエンド）。アプリケーション層＝業務ロジックの実行を担う層（APサーバ）。データ層＝データの永続化・管理を担う層（DBサーバ）。3層クライアントサーバの考え方をWeb向けに具体化した構成であり、各層は独立にスケール・変更できる。
- 層を分離する最大の利点は、負荷特性の異なる層を別々にスケールできること——例えばアクセス数の急増でプレゼンテーション層・アプリケーション層はスケールアウトが必要でも、データ層（特に書き込みが多いRDBMS）は単純な水平分散が難しいことが多く、ボトルネックになりやすい層を見極めて対策を集中させる判断が求められる。
2.3.2ステートレス設計とセッション外部化
- ステートレス設計＝各サーバがリクエストをまたいでクライアント固有の状態（ログイン状態・カート内容等）を保持しない設計方針。どのサーバが応答してもリクエストを正しく処理できるため、ロードバランサ配下でサーバ台数を自由に増減できる（スケールアウトしやすい）。逆にステートフルにサーバ内メモリへ状態を保持すると、同じクライアントは常に同じサーバへ振り分ける必要が生じ（セッションアフィニティ）、負荷分散の自由度が下がる。
- セッション外部化＝アプリケーションサーバ自身にセッション情報を持たせず、Redis等の外部の共有ストア（セッションストア）に切り出す設計手法。これにより各APサーバは実質的にステートレスとなり、サーバが障害で入れ替わっても別サーバがセッションストアを参照して処理を継続でき、スケールアウトの自由度も確保できる。
「ステートレス設計＝サーバがクライアント状態を保持せずスケールアウトしやすい」「セッション外部化＝APサーバのセッションを外部ストアに切り出し実質ステートレス化する」「データ層は水平分散が難しくボトルネックになりやすい」が最頻出です。「サーバを増やせば必ず負荷分散できる」という短絡はステートフルな設計では成立しない点に注意しましょう。
あるシステムアーキテクトが、会員制ECサイトのアクセス急増（セール開催時にピーク時の10倍のトラフィック）に備える設計を任されました。現行のアプリケーションサーバは、ログイン中の利用者のセッション情報（カート内容・ログイン状態）を各APサーバのメモリ内に保持するステートフルな実装になっており、ロードバランサは同じ利用者からのリクエストを常に同じAPサーバへ振り分ける設定（セッションアフィニティ）で運用されています。この状態でAPサーバを単純に増設しても、新しいセッションを開始する利用者は新規サーバに割り当てられ得ますが、既存のセッションを持つ利用者は元のサーバに固定され続けるため、特定のサーバに負荷が偏り続けるという問題が残ります。さらに、セッションアフィニティが効いている状態で、あるAPサーバが障害で停止すると、そのサーバのメモリ上にあったセッション情報が失われ、ログイン中の利用者は強制的にログアウトされカートの中身も消失します。この2つの問題を根本的に解決するため、アーキテクトはセッション情報をAPサーバのメモリから排除し、外部の共有セッションストア（Redis等）へ切り出す設計へ移行することを提案します。これにより各APサーバは実質的にステートレスになり、ロードバランサはリクエストごとに空いているどのサーバへでも自由に振り分けられるようになり、セール開催時にはAPサーバの台数を機械的に増やすだけでピークトラフィックに対応できます。また、あるAPサーバが停止しても、セッション情報はストア側に残っているため、別のAPサーバがそのセッションを引き継いで処理を継続でき、利用者は強制ログアウトを経験しないという可用性の向上も同時に得られます。一方、データ層（会員情報・注文データを持つRDBMS）については、書き込みが多い特性上、APサーバのように単純な水平分散はできないため、アーキテクトは読み取り専用のレプリカを増やして参照系の負荷を分散しつつ、書き込みが集中する主系の性能をキャパシティプランニングで別途見積もる方針とし、層ごとに異なるスケール戦略を使い分ける設計としました。
| 項目 | ステートフル（サーバ内保持） | ステートレス＋セッション外部化 |
|---|---|---|
| セッション情報の所在 | 各APサーバのメモリ | 外部の共有セッションストア |
| スケールアウトの自由度 | 低い（セッションアフィニティが必要） | 高い（どのサーバでも処理可） |
| サーバ障害時の影響 | 該当セッションが消失 | 他サーバが引き継ぎ継続可能 |
ひっかけ： 「APサーバを増設すれば自動的に負荷分散できる」は誤りです——セッション情報がサーバ内メモリに保持されるステートフルな実装では、セッションアフィニティにより既存利用者は元のサーバに固定され続け、負荷の偏りは解消されません。スケールアウトの効果を得るには、まずステートレス化（セッション外部化）が前提になります。また「データ層もAPサーバと同じ発想で単純に水平分散すればよい」も誤り＝書き込みが多いデータ層は水平分散が難しく、読み取りレプリカの追加やキャパシティプランニングなど層ごとに異なる戦略が必要です。
2.3.3この節のまとめ
- Web多層アーキテクチャはプレゼンテーション/アプリケーション/データ層に分離し各層を独立にスケール・変更できる
- ステートレス設計＋セッション外部化でAPサーバはどのサーバでもリクエストを処理できるようになりスケールアウトしやすくなる
- データ層は書き込み特性上、水平分散が難しくボトルネックになりやすいため層ごとに異なるスケール戦略が必要
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. セール開催で10倍のトラフィックが見込まれるECサイトで、APサーバはセッション情報を各サーバのメモリ内に保持し、ロードバランサはセッションアフィニティで同一利用者を同一サーバへ固定している。このままAPサーバを増設した場合に起こる問題として最も適切なものはどれか。
Q2. 前問のECサイトで、APサーバのセッション情報を外部の共有セッションストアへ切り出す設計に変更した。この変更によって得られる効果として最も適切なものはどれか。
Q3. Web多層アーキテクチャにおいて、プレゼンテーション層とアプリケーション層はスケールアウトで負荷に対応できたが、データ層（書き込みが多いRDBMS）は同じ手法での水平分散が難しかった。この状況への最も妥当な設計対応はどれか。