ちょっと業界では話題になっているヨドバシ.com のリニューアルですが、サーバーが WebLogic だという雰囲気になっています。
以前、ヨドバシ.com で Internal Server Error でエラーページを見たことがあるのですが、そのときは Tomcat の出力するエラーページでした。
リニューアルに伴いフロントのアプリケーションサーバは WebLogic になったのでしょうか？
・Web屋のネタ帳 – ヨドバシドットコムのリニューアル失敗から学ぶべきたったひとつのこと
↑、によると、
だそうです。WebLogic が悪い！、と言っているわけではなく「ちゃんと性能検証はしておきましょうね」という話なのですが。
しかし、SS_X_JSESSIONID ・・・って聞いたことないですね。
本当に WebLogic Server でしょうか？
試しに telnet でリクエストしてレスポンスヘッダを確認してみました。
Trying 211.120.8.208…
Connected to www.yodobashi.com.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Thu, 30 Oct 2008 13:36:06 GMT
Server: Apache
Pragma: no-cache
Cache-Control: private
Expires: -1
Set-Cookie: JSESSIONID=92D29232444310A7280EA8653B29AF08; Path=/cs
Set-Cookie: SS_X_JSESSIONID=D61F5E161FA4625C01490CBF945DE6B3; Path=/
Set-Cookie: SS_X_JSESSIONID=D61F5E161FA4625C01490CBF945DE6B3; Path=/
Set-Cookie: SS_X_JSESSIONID=D61F5E161FA4625C01490CBF945DE6B3; Path=/
Set-Cookie: SS_X_JSESSIONID=D61F5E161FA4625C01490CBF945DE6B3; Path=/
Set-Cookie: SS_X_JSESSIONID=D61F5E161FA4625C01490CBF945DE6B3; Path=/
Set-Cookie: SS_X_JSESSIONID=D61F5E161FA4625C01490CBF945DE6B3; Path=/
Set-Cookie: SS_X_JSESSIONID=D61F5E161FA4625C01490CBF945DE6B3; Path=/
Set-Cookie: SS_X_JSESSIONID=D61F5E161FA4625C01490CBF945DE6B3; Path=/
Set-Cookie: SS_X_JSESSIONID=D61F5E161FA4625C01490CBF945DE6B3; Path=/
Content-Length: 80918
Connection: close
Content-Type: text/html;charset=Windows-31J
Set-Cookie: BIGipServerPool_www_yodobashi_com_cms=1224845504.20480.0000; path=/
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>
<html lang=”ja”>
…
この結果から私が読み取れるのはロードバランサ(BigIP)を使っていること。それから何らかのサーブレットコンテナを使っていること、でしょうか。
確かに SS_X_JSESSIONID という見慣れないクッキーが発行されています。しかも9回も重複して・・・・。
これ本当に WLS の吐くクッキー?
ということで、手元にある WLS のインストールディレクトリを grep してみました。
手元にあるのは 8.1SP4〜SP6、9.2.1、10gRelease3です。
/Users/yusukey/bea81sp4$ grep “SS_X_JSESSIONID” * -r
/Users/yusukey/bea81sp4$ cd ../bea81sp5
/Users/yusukey/bea81sp5$ grep “SS_X_JSESSIONID” * -r
/Users/yusukey/bea81sp5$ cd ../bea81sp6
/Users/yusukey/bea81sp6$ grep “SS_X_JSESSIONID” * -r
/Users/yusukey/bea81sp6$ cd ../bea921
/Users/yusukey/bea921$ grep “SS_X_JSESSIONID” * -r
/Users/yusukey/bea921$ cd ../bea103
/Users/yusukey/bea103$ grep “SS_X_JSESSIONID” * -r
/Users/yusukey/bea103$
見つかりませんね。
また、WLS をクラスタ化しているときは JSESSIONID=Rand_Sess_ID!Primary_JVMID_HASH!Secondary_JVMID_HASH といった形式(JVMID_HASH はサーバ毎に割り振られるユニークなID)になるはすですが、そのような形跡も見られません。
エラーページを表示させればコンテナ独自の特徴的なページが見られるかと思い、おかしなリクエストを発行してみました。
Trying 211.120.8.208…
Connected to www.yodobashi.com.
Escape character is '^]'.
sdf
asdfas
sd
<html><head><title>Apache Tomcat/5.0.28 – Error report</title><style><!–H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}–></style> </head><body><h1>HTTPステータス 501 – メソッド sdf はRFC 2068には定義されておらず、サーブレットAPIではサポートされません。</h1><HR size=”1″ noshade=”noshade”><p><b>type</b> ステータスレポート</p><p><b>メッセージ</b> <u>メソッド sdf はRFC 2068には定義されておらず、サーブレットAPIではサポートされません。</u></p><p><b>説明</b> <u>The server does not support the functionality needed to fulfill this request (メソッド sdf はRFC 2068には定義されておらず、サーブレットAPIではサポートされません。).</u></p><HR size=”1″ noshade=”noshade”><h3>Apache Tomcat/5.0.28</h3></body></html>Connection closed by foreign host.
ん、WebLogic じゃなくて Tomcat ですね。
バージョンは5.0.28 と随分と古くて、2004年8月29日にリリースされたものです。
何を使うにしても最新のバージョンを使うのはセキュリティ上重要です。
パフォーマンス問題の原因は Tomcat だからとか、バージョンが古いからだとかは関係ないと思いますが早め早めのアップデートをお勧めします。
障害の原因はアプリケーションサーバにはないと思いますが、WebLogic の名誉はこれで回復できたでしょうか。
あと、WLS は EC サイトに必要ない、という論調が見られたのが個人的には残念です。
ライセンス料が無駄、かどうかはさておき、EC サイトに WebLogic などの J2EE / JavaEE のサーバを使うのは個人的にはオーバースペックではないと思います。
まず、ヨドバシカメラは多くの利益をオンライン取引からも得ているでしょうから、きちんとした SLA でサポートしてくれる信頼性のあるアプリケーションサーバを使ったとしても至極自然なことだと思います。
また、フルスペックの J2EE コンテナを利用すればトランザクションサービス、宣言的なセキュリティ、JMS / MDB を使った非同期処理などのアドバンテージを活かし、信頼性、スケーラビリティの高い堅牢なシステムを容易に構築することができます。
もちろん機能面で言えば Seasar や Spring などを使っても似たことはできるので好みといえば好みかもしれません。
コンテナに依存せず、標準に則った実装ができる、という意味で私は標準に従った実装が好きです。
アプリケーションサーバは急速にコモディティ化を成し遂げました。
「ライセンス料が無駄」なことが問題なのであれば「アプリケーションサーバを使う」ことにはお金を払う必要がなく、「サポートを受ける」ことに対して費用を払うだけで済む JBoss が最適ですね！
、という中の人ならではのオチにしておきます。
・JBoss – オープンソース ミドルウェア
さてさて、JBoss のイベント、JBoss Compass 2008 はまだまだ参加申し込み受付中です。
・レッドハット | オープンソース・カンパニー
関連記事:
・「ヨドバシ・ドット・コム」がリニューアル直後から表示が遅すぎて激重になる大規模障害が発生、一体何が起きているのか？ – GIGAZINE
・ヨドバシドットコムのリニューアル失敗から学ぶべきたったひとつのこと
・只今動かないコンピュータと評判のヨドバシカメラ通販サイトはWebLogic製だそうな。 – ねこら対策研究要塞日誌＠はてな
・shin3tky blog: ヨドバシカメラのトラブル原因を想像してみる
・ヨドバシドットコム – しんさんの出張所 はてな編
・ネットワーク側から見たヨドバシカメラ問題 – なぷさく