大規模なWebサイトは、複数のマシン間で「負荷分散」される場合があります。多くの負荷分散セットアップでは、セッション中にユーザーがバックエンドマシンのいずれかにヒットする場合があります。このため、多くのマシンがユーザーセッションを共有できるようにするための方法がいくつかあります。
選択される方法は、使用される負荷分散のスタイル、およびバックエンドストレージの可用性/容量によって異なります。
Cookieのみに保存されるセッション情報：セッション情報（セッション識別子だけではありません）はユーザーのCookieに保存されます。たとえば、ユーザーのCookieには買い物かごの内容が含まれる場合があります。ユーザーがセッションデータを改ざんするのを防ぐために、CookieとともにHMACが提供される場合があります。この方法は、ほとんどのアプリケーションにおそらく最適ではありません。
- バックエンドストレージは不要です
- ユーザーは毎回同じマシンにアクセスする必要がないため、DNSロードバランシングを使用できます。
- データベースマシンからのセッション情報の取得に関連する待ち時間はありません（HTTPリクエストで提供されるため）。サイトが異なる大陸のマシンによって負荷分散されている場合に役立ちます。
- セッションに保存できるデータの量は制限されています（4K Cookieサイズの制限により）
- ユーザーがセッションの内容を表示できないようにする場合は、暗号化を使用する必要があります
- セッションデータのユーザーによる改ざんを防ぐために、HMAC（または同様の）を使用する必要があります
- セッションデータはサーバー側に保存されないため、開発者がデバッグするのはより困難です
ロードバランサーは常にユーザーを同じマシンに誘導します。多くのロードバランサーは、ユーザーがどのバックエンドマシンからリクエストを行っているかを示す独自のセッションCookieを設定し、将来それらをそのマシンに送信します。ユーザーは常に同じマシンに誘導されるため、複数のマシン間でセッションを共有する必要はありません。これはいくつかの状況で良いかもしれません：
- 既存のアプリケーションのセッション処理は、複数のマシンに対応するために変更する必要がない場合があります
- セッションを保存するために共有データベースシステム（または同様のもの）は必要ありません。おそらく信頼性は向上しますが、複雑さが犠牲になります。
- バックエンドマシンがダウンすると、それで開始されたすべてのユーザーセッションがダウンします。
- 機械をサービスから外すことはより困難です。メンテナンスのためにマシン上でセッションを終了するユーザーは、マシンの電源を切る前にタスクを完了することができます。これをサポートするために、Webロードバランサーには、特定のバックエンドマシンにリクエストを「排出」する機能があります。
共有バックエンドデータベースまたはキー/値ストア：セッション情報はバックエンドデータベースに格納され、すべてのWebサーバーがクエリと更新にアクセスできます。ユーザーのブラウザーは、セッション情報を指す識別子（セッションIDなど）を含むCookieを保存します。これはおそらく3つの中で最もクリーンな方法です。
- ユーザーは、保存されたセッション情報にさらされる必要はありません。
- ユーザーは毎回同じマシンにアクセスする必要がないため、DNSロードバランシングを使用できます。
- 1つの欠点は、採用されているバックエンドストレージシステムに配置できるボトルネックです。
- セッション情報は期限切れになり、一貫してバックアップされる場合があります。
全体として、ほとんどの動的Webアプリケーションは多数のデータベースクエリまたはキー/値ストアリクエストを実行するため、データベースまたはキー/値ストアはセッションデータの論理的な保存場所です。