「カゴに入れる」の背後には：インターネットサービスの新基準（2/2 ページ）

[大澤文孝，ITmedia]

　長くしすぎると、なかなかサーバのメモリが解放されず、メモリ圧迫の原因になるだろう。そこで、「一般ユーザーは、どの程度の間隔で次ページへと移動するか」を検討し、セッションタイムアウト時間の調整を図るのが一般的だ。

　実際、ショッピングサイトで操作していて、「タイムアウトです」「時間が経過しました」などというエラーメッセージを見たユーザーも多いだろう。

　またショッピングページで、数に限りがある製品の場合、「どの段階で在庫を減らすのか」も考慮すべきポイントだ。多くの実装では、「カゴに入れる」という操作をした段階では在庫を減らさないようにする。なぜならば、「カゴに入れる」という操作をしたまま、立ち去ってしまうユーザーがいるからだ。

　そこで実際に決済する直前に在庫数を減らす処理が一般的だ。当然、このときには在庫切れで「カゴに入っているのになぜ在庫がないのだ」という現象も起きるが、これはセッションを使っている以上やむを得ないものだ。

負荷分散の問題点はセッション情報受け渡し

　小規模なサイトの場合、セッションを構成するのは比較的容易だが、大規模になると、セッション構成が難しくなる。

　その理由は、大規模なサイトでは、負荷分散するために複数台のサーバで構築するからだ。それぞれのサーバにセッション情報を持たせると、負荷分散によって「ユーザーのデータを保存していないサーバが応答してしまう」という場合もあり得る（図3）。

　この問題を解決する方法は、2つある。1つは、全サーバで共通のデータ保存域を使うこと。例えばメモリにデータを保存するのではなく、データベースに保存するなどして全サーバで共有するのだ。もう1つは、負荷分散の際にCookieを追跡し、Cookieデータを送ったサーバが応答するよう構成することだ。

　どちらの方法を採用するかは、Webサイトに依存するだろう。Webサーバ群を1カ所に配備し、負荷分散に「ロードバランサ」と呼ばれる専用機器を使う場合にはCookieの追跡が可能だ（負荷を分散するためのネットワーク機器）。この際にはCookieの追跡で対応するパターンが多い。しかしロードバランサを配備しない場合や、複数拠点でWebサーバ群を構成する場合は、何らかの共通データ領域を持たせることが多い。

　また、負荷分散の際に多く採用されるのが「DNSラウンドロビン」と呼ばれる構成だ。これは、例えば「www.example.co.jp」といったドメイン名に複数のIPアドレスを割り当てておき、クライアントがアクセスする際に、どのIPアドレスを返すのかを任意に変えることで負荷分散する方法である。

図3■購入データが存在しないサーバが応答してしまう

セッションはユーザー情報を保持する基本技術

　今回は、比較的分かりやすい「カゴに入れる」という仕組みを例にとってCookieやセッションを説明したが、それ以外にも、Cookieやセッションを使っているケースは、たくさんある。

　ユーザーがログインするようなページは、すべて、Cookieやセッションが使われていると言ってよい。例えば、ユーザーがページをカスタマイズできる「パーソナライズ・ページ」はユーザーのカスタマイズ情報を保存するためにセッションを使っている。この場合には、次回ログオンした時にも設定したパーソナライズ・ページが表示されるよう、データベースなどにデータを永続保存している。

　従来であれば、Cookieというと「個人情報の追跡だから嫌われる」という傾向にあった。しかし、現在ではCookieを使わないWebアプリケーションは成り立たないと言ってもよい。これは、Cookie以外にWebを構成するHTTPが「前回の状態を保存する方法」がないからだ。