ネットワーク側から見たヨドバシカメラ問題

tech web scalability

ネットワーク側から見たヨドバシカメラ問題 - なぷさく

4. 近くのサーバも生きてるっぽい

商品画像はimage.yodobashi.comで、これはakamaiのコンテンツデリバリを使っているようなので今回の問題の影響は受けていない。また、https://order.yodobashi.com/ec/shoppingcart/index.doやhttps://order.yodobashi.com/ec/mailnews/index.doは無事のようだ。ショッピングカートサーバ（order.yodobashi.com,211.120.8.210:80） の裏側のサーバは元気な模様である。

IPアドレスから推測して恐らくは同一のネットワーク上、あるいは同一のロードバランサに収容しているかもしれないorder.yodobashi.comに問題がないということは、ボトルネックは純粋にwww.yodobashi.com/211.120.8.208:80の裏側にあることが推測される。

やっぱりCMSの問題？

外に出ているサービス群には総じて問題がなさそうだし、内側でもショッピングカート系は生きている。アイテムを入れるアクションや、決済関連の操作はスムーズに進むので、同じ裏方でも商品DBサーバが腐ってるというわけではなさそうだ。

逆に、http://www.yodobashi.com/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1172654511127&ssbinary=true のような埋め込み画像系はレスポンス低下の憂き目を見ているので、やはり原因はCMS側にあると結論付けられよう。

腐ったCMSをどう騙しながら使っていくのか、これからのヨドバシカメラの奮闘に期待したい。

ヨドバシドットコムのリニューアル失敗から学ぶべきたったひとつのこと - ホームページ制作のためのリンク集

さらに、外部から「あぁ、こりゃCMSが原因だわ」なんて分かる人たちもすごいね。どうやら、「もう少し性能試験（負荷試験）をやった方が良かったのでは？」ということみたいです。

 

それにしても、キノトロープさん、大々的に信用を落としてしまいましたね。機会損失が数億円規模に及ぶとか？・・・いやはや、他人事ながら心臓に悪い話しだなぁ。

JMeter - Apache JMeter日本語訳

Apache JMeter は以下の機能があります:

  • 負荷かけたパフォーマンステストを HTTPサーバ、FTPサーバ、それに任意のデータベースクエリ(JDBC経由)で行えます。
  • 完全にポータブルで 純粋に100% Java です.
  • 完全な Swing とライトウェイトコンポーネントサポート(コンパイル済みのJAR はパッケージ javax.swing.* を使う).
  • 完全な マルチスレッド フレームワークにより同時に多数のスレッドでサンプリングを行い、異なるスレッドグループによる同時異種サンプリングを行います。
  • 使いやすい GUI デザインにより素早い操作と正確なタイミングを提供します。
  • テスト結果を保存し、オフラインでの分析、リプレイを可能にします.
  • 拡張性の高さ:

ヨドバシのサイトが見れないのは不適切なKeep-alive設定のせいじゃないかな。 - ＊「ふっかつのじゅもんがちがいます。」withぬこ

例のヨドバシの騒ぎの件。あまり興味なかったのでわざわざ見に行って傷口に塩を塗りこむようなことはしてなかったんだけど、ネットワーク側から見たヨドバシカメラ問題というのを見ると、どうやらDBやらの過負荷じゃなくて、静的HTMLを出してるところの問題ぽいという切り分けをみて、そんなことあるんかいなとおもってヨドバシのサイトを見てみた。以下HTTPヘッダ

http://www.yodobashi.com/
GET / HTTP/1.1

Host: www.yodobashi.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: ja,en-us;q=0.7,en;q=0.3

Accept-Encoding: gzip,deflate

Accept-Charset: Shift_JIS,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Cookie: *************************************************************************************************************
HTTP/1.x 200 OK

Date: Thu, 30 Oct 2008 08:13:13 GMT

Server: Apache

Pragma: no-cache

Cache-Control: private

Expires: -1

Set-Cookie: ******************************************** Path=/cs

Set-Cookie: ************************************************* Path=/

Set-Cookie: ************************************************* Path=/

Set-Cookie: ************************************************* Path=/

Set-Cookie: ************************************************* Path=/

Set-Cookie: ************************************************* Path=/

Set-Cookie: ************************************************* Path=/

Set-Cookie: ************************************************* Path=/

Set-Cookie: ************************************************* Path=/

Set-Cookie: ************************************************* Path=/

Content-Length: 81066

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html;charset=Windows-31J

重要なところはレスポンスヘッダの


Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

画像やCSSやJSはすべてAkamaiかなんかのCDNから出していて、www.yodobashi.comへのアクセスはHTML一枚だけなので、おそらくKeep-Aliveする意味がまったくない。一方これだとクライアントが15秒くらいはコネクションを掴んでしまうのでC10Kな状況になるとプロセス足らなくなりそう。

事実、最初にHTMLを受信するのに30秒くらいかかってるけど、一度受信してしまうと(15秒以内に他のページに行けば)200msecとかで見れる（まあそれでも早くはないけど）のと、明け方なんかは早い？とかいうほかの症状とも符合するので、これが一因になってるのは確定的。これだけとは限らないけど。