Web屋のネタ帳

ヨドバシカメラの通販サイト「ヨドバシドットコム」が10/21ごろにリニューアルしたのだが、立ち上がりで見事に失敗したようだ。

• 大手ECサイトのヨドバシドットコムが、サイトリニューアルから大規模な障害を3日間... - Yahoo!知恵袋
• ヨドバシカメラのサイトが「動かないコンピューター」状態、機会損失は既に数億円規模？ - Technobahn
• 「ヨドバシ・ドット・コム」がリニューアル直後から表示が遅すぎて激重になる大規模障害が発生、一体何が起きているのか？ - GIGAZINE

ページ表示が激重でトップページの表示にすら1分近くかかる状態が１週間たっても改善できないという点と、サーバーがすいているであろう朝方に見るとまともに見れるが22時前後の混雑時間帯はまったくダメという点からすると、ネットワーク回線／機材の不備（サーバーやデータセンター移転の場合はよくある）ではなく、純粋にWebアプリケーションとしての性能が悪いのが原因と見ていいだろう。

DBサーバやAPサーバなどの設定値をひとつふたつ間違えてただけでしたってオチじゃね？とか、 いやそれなら1週間もあれば見つけられるだろとか、だとすればJavaのコードのどっかにおかしなsynchronized宣言でも入れちゃってるんじゃね？とか、 メモリバカ食いのオブジェクト／メソッドとかが紛れ込んじゃってフルGCしまくりなんじゃねとか、 キーになる社員が限界に達して失踪したらしいねシステム構築プロジェクトではよくある話だよとか、 キノトロープイントがかついでるパッケージソフトってFatwireじゃんこれCMS(コンテンツマネジメントシステム）であってECサイト構築パッケージとは似て非なるものでしょつまり油絵を書くプロジェクトに絵の具じゃなくてノミとトンカチ持ち出したみたいな？とか、 そもそもキノトロープ（とその関連会社）って90年代後半に雑誌関係から転進したWeb制作会社であってシステム屋じゃないんだからヨドバシクラスの巨大ECサイトのシステムを作らせたこと自体が間違ってね？とか、 httpのレスポンスヘッダを見るとSS_X_JSESSIONIDっていうクラスタ構成のWeblogicを使ってるときの独特のセッションIDクッキーが発行されているところを見ると本当にキノトロープがかついだCMSパッケージでヨドバシのサイトを作ってるぽいね、とか、 んじゃそのパッケージのスペック見てみるとデータベースにOracle使うのはいいとしていまどきAPサーバにWeblogicを使う意味がどこにあるのかよくわかんねーよTomcatで十分だろたぶんFatwireがJ2EE技術かなんかを使ってるのでサーブレットコンテナでしかないTomcatでは動かないんだろうけどいずれにせよ2008年現在の世の中じゃWeblogicなんてのは銀行や証券会社とか通信キャリアとかが徹底的に金をかけたシステム作りをするためのAPサーバであってECサイトごときにはオーバースペックでしょ要するにBEAに払うライセンス料が無駄、とか、 海坊主というかつまりシティハンターに出てくるファルコンが年を食うとこうなるみたいないかつい風貌のキノトロープのカリスマ社長（50歳前後？）によるときに優しく落ち着いた物腰ときにヤクザばりの威圧感を持ってくりだす独特のプレゼンテーションが古典的国内大手企業の役員クラスにはウケるんだよねそりゃそうだ2,30代の若造がカン高い声で「こんてんつまねじめんとしすてむとは！」なんて講釈タレたところで50代60代下手すると70代の役員クラスからするとバカにされたように感じてしまうのが団塊の世代の悲しきプライドなのさ、とか、 ああそういう感じのトップ営業だからベンチャー企業っぽいのに国内有名企業のサイト構築の実績が多いのね、とか、 うんそうなんだ2000年のITバブル時代にセブンイレブンとかNECとかソニーとか名だたる連合のなかにひょっこりと名の知れぬキノトロープが入り込んでセブンドリーム・ドットコムとかいう会社とサイトができたのはシステムは作れるけど絵心はまるでないオーソドックスでスーツなシステム屋としてのNECが当時唯一落ち着いたおっさんが率いている絵心の有る制作会社だったキノトロープに声をかけたのがきっかけだったんだよね実は、とか、 一方でヨドバシとかヤマダとか大手と呼ばれる家電量販店のほとんどがよく言えば悲しいくらい体育会系悪く言えばヤ○ザスレスレな体質だから予算とか納期とか要件定義とかメチャクチャだったんじゃね？ご愁傷様です、とか。

システムトラブルの原因なんてのはそれこそ千差万別で、起きてしまうときは起きてしまうし、起きてしまったものはしょうがない。キリがない。

だから、ここまでの話はすべてどうでもいい。すべて外野席の酔っ払いによる野次にすぎないので本当にどうでもいい。前置き長くてすまんね。

サイトの大小によらず、過去に集めたユーザーによるトラフィックがリニューアル後も継続して発生する前提において、Webシステムの基本的なアーキテクチャを変更してリニューアルする場合に、必ずやらなければならないたった一つのことそれは、性能試験である。負荷試験とも言う。

簡単なことだ。たとえばapache benchみたいな簡易ツールでも、トップページに集中アクセス浴びせたら平均何秒で帰ってくるか？なんてのは1分でできる。いろんなページに同時アクセスしたときにサーバのロードアベレージがどうなるか？なんてのも、たとえばそのへんのパソコン10台にapache入れてab.exeをいっせーのせで叩くといった原始的手法でもいい。少なくとも今回みたいな状況になることを事前に再現できただろう。そうすれば、リニューアルオープンを遅らせて既存システムを延命するなりしつつ落ち着いて対処できたはずだ。

もちろんECサイトは注文だとかなんだとかデータベース上でのトランザクション処理がからむ複雑な仕組みなのでApachebenchでの試験はあくまで簡易的なものにしかならない。変わりにapache jmeterなどを使うべきだろう。使い方はググればいくらでも出てくる。あるいは、性能試験専門の外注に依頼するべきだった。 もちろん性能試験用の環境も別に準備しておく必要がある。

たぶんキノトロープの海坊主社長かそれに近い立場の人間が後日談としてインタビューかなにかに応じたら「いやあ、負荷試験をまともにやるべきでしたの一言ですよ」みたいなことを言うであろう予想に5000カノッサ。