PR

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

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

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

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

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

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

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

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

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

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