おれのIT日記
2006/05/02 (火)
Webアプリ
サーバ移行時の陥穽
「なんだ当たり前じゃないか」と言われそうだが、自分では、ちょっと面白かったので記録する。
ある会社で、あるWebアプリサーバを入れ替えるにあたって、ドメイン名を新しく振ることにした。
このシステムは、Websphereを使い、サーブレットを中心に構築されている。
実はサーバが切り替わるのはシステム側の都合であって、基盤システムとしての機能・性能はともかく、アプリとしてレベルアップするわけではなかった。
だから、切り替え直後は、旧サーバにアクセスする顧客も多いはずで、旧から新にリンクを貼ることにした。
このシステム会社は親会社に似て縦割りなので、基盤システムを担当する連中は特に深く考えず、今までは、
hogehoge.mountainroot.or.jp
という名前だったのを、
www.hogehoge.mountainroot.or.jp
に変えた。
アプリ構築を担当する連中は、いざリンクを貼るにあたり、よく似た名前なので紛らわしいと怒ったが、それでもまだ、誰もそれを、問題だとは気づかなかった。
さて、統合テストに入ったが、何の問題もなかった。
ネタばらしになるが、統合テスト環境はあまり金がかかってなくて、間に合わせの偽サーバなどで構成されており、本番とはドメイン名がまったく違っていたので、問題は起きなかったのだ。
稼動間近になってシステムテストに突入したとたん、エラーが見つかった。
旧サーバから新サーバにリンクを張ったところで、セッションIDの不正エラーになってしまうのである。
もうお分かりと思うが、ブラウザは、旧サーバから、hogehoge.mountainroot.or.jpのクッキーで、jsessionidを割り振られる。
その後ブラウザが新サーバに接続する際、ドメイン名を文字列比較する。すると、新ドメインのwww.hogehoge.mountainroot.or.jpは、同じドメインに見えてしまい、旧サーバのクッキー(jsessionid)を投げてくれちゃうのでエラーになる。
…と、こういうわけであった。新→旧も同様である。
つまり、サブドメイン名を新しくする際、誰もそこまで考えてなかったということだ。
で、アプリ画面側でいろいろ工夫したが、JavaScriptで消去（クッキー寿命を無効にする）しても、ブラウザ再起動まで無駄である。
ホスト名をIPアドレスで記述すれば、ブラウザから見て別ドメインと認識されるのだが、実はリンク生成は基盤システムの共通機能で実現しており、影響がありそうでダメだった。
というわけで、サーバ側でクッキーの消去をかける仕掛けを追加して、ようやく解決した。
最後に、読者の皆さんに問題です。
基盤システムの担当者は「こんなぎりぎりまでテストをしないのが原因だ」と言いました。
アプリシステム担当のほつまさんは「設計ミス、いや命名ミスだ」と言い返しました。
さて、どちらの言い分が正しいでしょう？
…自分で言うのもなんだが、どっちの言うことも正しいと思うよ。つまり、どちらも、間抜けだ。
とにかく、名前は重要だよ！というところで、今日はおしまい。