文系プログラマによるTIPSブログ

文系プログラマ脳の私が開発現場で学んだ事やプログラミングのTIPSをまとめています。

【過負荷】ZOZOTOWNに見るサーバダウンの機会損失【驚愕の損失額!?】

あけましておめでとうございます。今年もよろしくお願いします〜


f:id:treeapps:20180418112610p:plain

さて、新年初めての投稿となります。
今回のお題は「ZOZOTOWN」です。

zozotownはスタートトゥデイが運営しているファッション通販サイトです。
今日1/1の元旦に元旦セールを行っていたようですが、大変残念な状況が起きていました。
その様子を私は見ていたので紹介します。

元旦昼からセール開始だが・・・

f:id:treeapps:20140101234231p:plain

(;^ω^)<あー、HTTPステータス500だわ・・・

HTTPステータスコード500はシステム障害を意味しています。
つまりバッシバシエラーが返りまくっていた訳です。
コネクションが一杯で開放待ちのプロセスが並び、タイムアウトしまくったのかもしれません。
恐らくnagiosやzabbixでサーバを監視し、異常時はエラーメールを送るという一般的な監視を行っていたと思います。ということは、死ぬほどエラーメールが飛んだ事でしょう・・・

システム開発者なら誰もが経験する、鬼のようなアラートメール地獄です。
元旦だというのに現場の開発者たちはさぞ大変だったことでしょう・・

さて、その頃ユーザはどういう反応を示していたでしょうか?

twitterで見るユーザの反応

f:id:treeapps:20140101235536p:plain

(;^ω^)<まあ想像通りの反応だな・・・

インフラエンジニアの苦労も知らず、ユーザはZOZOを叩きまくるわけです。
しかもこの状態が数時間続いてしまったようで、炎上していました。

復旧した後のZOZOの対応

【重要】アクセス集中に関するお詫びと「全品ポイント2倍」のお知らせ

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【重要】アクセス集中に関するお詫びと「全品ポイント2倍」のお知らせ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

平素よりZOZOTOWNをご利用いただき誠にありがとうございます。

本日正午からの「ZOZOTOWN2014冬セール」開催に伴い
アクセスが集中し、サイトにつながりにくい状況となっておりました。
現在は復旧し、通常通りお買い物いただけます。

お客様には大変なご迷惑、ご不便をおかけいたしまして
誠に申し訳ございません。

また、このたびのお詫びとして
「全品ポイント2倍」とさせていただきます。

今後もZOZOTOWNをご愛顧いただきますよう、お願い申し上げます。

─【ポイント2倍実施期間】──────────────
2014年1月1日正午から2014年1月4日午前11時59分まで

※2014年1月1日正午から復旧までのご注文も対象となります。
※ZOZOPREMIUM特典の予約商品5%ポイント還元につきましては
 対象外となります。

ZOZOはこの件で全品ポイント2倍のお詫びをする事を決定したようです。

そして現在のサイトはこんな状態です。
f:id:treeapps:20140102000304p:plain

ZOZOTOWNのインフラはどうなっているのか

まずは以下の記事をご覧下さい。

● 10ギガオーダーのトランザクションスピードを視野に入れること。
● ネットワーク機器をシンプルに構成できること。
● ネットワーク構成の変更に迅速に対応でき、ダウンタイムを発生させないこと。
● ネットワークの複雑化に比例して増加する運用負荷とコストを削減すること。

■導入前の課題

アクセスの遅延による機会損失
ZOZOTOWNには苦い経験があった。今年1月のセール時に通常の3倍規模のアクセスが起こり、遅延とトランザクション処理の停滞を誘発し、ビジネスチャンスを逃してしまったのだ。
通常の路面店ビジネスにおいては、気に入った商品の在庫切れが3回続いた場合や、オーダー時・支払時に店員の対応力が低下した場合、その顧客の再来店は期待できなくなるという。
この傾向はインターネット上においてさらに強くなり、一度でもアクセスやトランザクションの遅延が起こると、第一アクセス率を落としてしまうとされている。年間のビジネス規模は、アクティブ会員1名平均5万円に達する。インターネットショッピングモールにおいては、アクセス遅延やトランザクションの停滞が致命傷となってしまうのだ。

http://www.uniadex.co.jp/nextalk/jirei/101116.html

f:id:treeapps:20090630205424j:plain
どうも以前同じ事をやらかしてネットワーク周りを強化したようですが、防げなかったようです。
というか・・・
3倍程度でサーバダウンって・・・
実は平常時から危険な状態だったという事じゃないでしょうか。
負荷テストは普通10倍位の負荷かけますし、サーバが危険な状態である事はcacti等のリソース監視ですぐ解る事なのではないか、と考えてしまいます。


続いて以下の記事をご覧下さい。
「ZOZOTOWN」が SQL Server 2005により構築 - Dell

いつの記事か定かではありませんが、SQLServer2005をデルのサーバで、ECサイト2台、バックヤード2台構成で運用しているようです。この記事の「データベースに関する経験がなくても早く理解できるのではないでしょうか」とか「SQL ServerならばWindowsサーバの知識があれば直感的に操作できます」とか見ると、ん?と思ってしまいます。大丈夫なのだろうか・・・シャーディングについてので技術解説とか、スケールアウトの仕組みとかの解説じゃないのか・・・

機会損失による損失額を計算してみる

以下を見ると、去年1月時点のアクティブユーザ数は1738669人となっています。
平成 25 年3月期 12 月度月次商品取扱高、会員数の状況について
そして前述の資料に「年間のビジネス規模は、アクティブ会員1名平均5万円に達する」と書いています。

単純に最大値で計算すると、

1738669人 × 50000円 = 86933450000円(約869億円)

最大で869億円の機会損失額となります。
(全員が購入失敗という前提です)

ちょっと数値を変えて損失額を計算してみましょう。

ケース 購入ユーザ数 購入金額 損失額
最大 1,738,669 50,000円 約869億円
ユーザ数が10分の1の場合 173,866人 50,000円 約86億円
ユーザ数が100分の1の場合 17,386人 50,000円 約8.6億円
ユーザ数が10分の1、金額が2.5万円の場合 173,866人 25,000円 約43億円
ユーザ数が100分の1、金額が2.5万円の場合 17,386人 25,000円 約4.3億円
ユーザ数が10分の1、金額が1万円の場合 173,866人 10,000円 約17億円
ユーザ数が100分の1、金額が1万円の場合 17,386人 10,000円 約1.7億円
ユーザ数が10分の1、金額が5千円の場合 173,866人 5,000円 約8.6億円
ユーザ数が100分の1、金額が5千円の場合 17,386人 5,000円 約8600万円
ユーザ数が1000分の1、金額が5千円の場合 1,738人 5,000円 約869万円

色々数値をいじってみた訳ですが・・・

(;^ω^)<下手したら億超えの損失でてないかこれ・・・

考えるだけで恐ろしいですね。
実際はこれに加えて、前述のポイント2倍サービスをやってしまうので、更にマイナスになるでしょう。

雑感

こういうシステム障害はtwitterの反応通り、「繋がらないなら別のサイト行くか」「リアルの別会社の店舗行ってくる」等、ユーザが離れてしまうのです。するとますます悪評が広まり、ますます売上が減少する負のスパイラルに陥るのです。

インフラについては、先ほどのSQLServerの資料を見ると「デルのサーバを使っている」とはっきり書いてあるので、オンプレミスでサーバを構築していると思われます(現在は違うかも)。そう、クラウドではないのです。これがもしAWS等であれば、セール期間中だけサーバ台数を10倍にする等して対応できたでしょう。

私が知っているファッション通販サイトでは、1時間の停止で1千万円の損失額がでます。
オンプレミスでセール時のみサーバ台数を増強して、サーバが50台近くあってもダウンしまくりだったようです。オンプレミスだとサーバの設定が都度必要だったり、サーバの準備自体も大変そうでした。

このように、機会損失による損失額は想像を絶する金額になるので、スケールアウトできるインフラが重要になります。
最近はAWSによるサーバのスケールアウトも容易で、chef等によるサーバ環境構築も自動化でき、capstrano等でオペレーションの自動化も行えます。これからはますますスケールアウトと自動化がテーマになってくる筈なので、勉強していきましょう!

今、ZOZOTOWNは何を考えているのか?

今、ZOZOTOWNは何を考えているのか?

なぜ、あの会社だけが選ばれるのか??成功し続ける会社がやっているたった3つの仕組み

なぜ、あの会社だけが選ばれるのか??成功し続ける会社がやっているたった3つの仕組み