図1 A社は販売会社からの発注データなどが消えるトラブルに遭遇
サーバーが発行したクッキーを使ったため負荷分散装置が対応付けできず,セッション維持が不可能に。アクセスごとに別のサーバーに接続する事態に陥った。
図2 A社はユーザー側からクッキーを発行することでセッション維持を実現
負荷分散装置がWebサーバーとクッキーを正しく関連付けるようにするため,ユーザー側がクッキーを発行する形式に切り替えた。セッションを維持できるようになり,処理の途中でデータが消えるトラブルを解決できた。

クッキー利用でも発注情報が消える

 ところが,導入前のテストで,販売会社が入力した発注情報が消えたり,在庫情報が不正確になるトラブルが発生した。販売会社のアクセスが,異なるサーバーに割り当てられてしまったからだ。調査しても,クッキーの書き込みや読み出しは正常だった。

 この問題は,負荷分散装置によってクッキーとWebサーバーを関連付ける機能に違いがあることに起因していた。ブラウザからサーバーへの上り方向で関連付けたり,固定的な文字列とサーバーを関連付けるなど,製品や設定モードで機能が異なっていたのだ。

 A社が採用したのは,ブラウザからの上りでクッキーとWebサーバーを関連付ける製品だった。Webサーバーがクッキーを送った下り方向では関連付けない。このため,ブラウザが返信したクッキーに対して,どのサーバーを割り当てるかという情報を負荷分散装置が持っていない。この結果,負荷分散装置がラウンドロビンで別のサーバーを割り当てていた(図1[拡大表示])。

 この場合,新しいサーバーには前のサーバーのホスト名がクッキーとして届くことになる。A社はサーバーが自身とは異なるホスト名を受け取ると,自身のホスト名を上書きするように設定していた。障害時に他のサーバーに接続できなくなることを恐れてのことだ。このため,毎回サーバーがクッキーを発行し,ユーザーが別のサーバーを渡り歩く結果となった。

ユーザーIDを入力させる処理を作成

 そこでA社では,負荷分散装置がクッキーを対応付けるタイミングと合わせるため,ブラウザ側で発生するユーザーIDをクッキー情報として使うことにした(図2[拡大表示])。こうすれば,最初にクッキーを送った時に,負荷分散装置が接続したWebサーバーと対応付けるため,セッションを維持できる。

 ブラウザ・ユーザーにユーザー名を入力させるために,JavaScriptを使って新たにスクリプトを作成。WebページをJavaScriptで記述して,サーバーからブラウザに送る仕組みにした。

 負荷分散装置は,クッキーで受け取ったユーザーIDとサーバーとの対応表を作成する。ユーザーが別のページに移る時も,ブラウザが同じユーザーIDを送信するため,負荷分散装置は1台のWebサーバーに処理を固定できるようになった。