読者です 読者をやめる 読者になる 読者になる

かっぱラクガキ帳

ごはんがおいしい日々を

システム屋から見た土屋鞄ランドセル戦争

世界一かわいくてかしこくてかっこいい我が家のムスコさん、いよいよ来年から小学生。わりとよくある話だけれど、おばあちゃんがランドセルを買ってくれることになりました。

ヨメさんのサジェストで見に行ったのは「土屋鞄のランドセル」。なるほどしっかりした作りとトラディショナルなデザイン。大人がいいと思う要素を備えています。

ショールームで実物を確認し、7/1 10時からのネット販売で予約することに。その結果…

www.itmedia.co.jp

なんということでしょう。

それでもシステム屋としての知識と経験を活用し、11時半ごろには予約をゲットすることができました(スマホから)。あとは現物が届くのを待つだけなので、この騒動についてWebシステムの視点から考えてみることにします。

問題はどこにあったのか

この騒ぎにはいくつか自明の問題がありました。順に見てみましょう。

  • 予想できる高負荷への対応のまずさ
    • 「2016年7月1日 10時から予約開始!」などと書けば、その時間帯にアクセスが殺到するのは当然のことです。それに備えるのはシステム屋として当然のことでしょう。
  • システムの設計・実装のまずさ
    • 外から触っているだけでも「ここはあかん…」と感じられる箇所が多々ありました。高負荷は予測されていても、システムの品質が低いために対応が間に合わなかったのかもしれません。
  • 10時前から購入できる不公平さ
    • 10時10分前から購入できた、という声も見られました。僕自身も2分前にはカートに入れることに成功していたのですが、購入手続きの途中で高負荷状態になり、注文確定には至りませんでした。

Amazon Web Servicesではじめる新米プログラマのためのクラウド超入門 (CodeZine BOOKS)

Amazon Web Servicesではじめる新米プログラマのためのクラウド超入門 (CodeZine BOOKS)

実録・予約注文攻略法

システム屋として、ブラウザの操作をしているだけでもなんとなく中身の想像がつく箇所が多々ありました。それらを活かして注文確定までたどり着いたので、その手順を記録しておきます。

事前準備

サイトでは事前の会員登録と決済情報の登録を推奨していました。これはこのシステムの良心とも言える部分でしたし、その勧めにしたがって事前登録しておいた自分にはGJと言ってやりたいところです。

全般的なTips

リロードは気長に効率的に

リロードすると、Safariなら青いバー、ChromeならタブのFavicon部分がアニメーション状態になります。この状態が一瞬で終わって画面が真っ白ならレスポンスはありませんのでリロードしましょう。アニメーションが続いているなら、サーバーにリクエストが届いているのでしばらく待ちましょう。

「SytemError」のときはしばし待つ

データベースサーバーとの接続に(おそらくタイムアウトで)失敗すると「SystemError」と表示されます。これが出るときは何度試しても失敗するようなので、少し時間をおきましょう。

ログインした状態で購入履歴ページが表示されれば、データベースサーバーは生きています。

お目当てのランドセルをカートに入れる

幸い事前にWebサイトを見ていたので、個別の商品ページは履歴に残っていました。以下のようなURLのページが、個別の商品詳細ページです。

https://www.tsuchiya-randoseru.jp/products/detail.php?product_id=***

ここで「カートに入れる」ボタンが動作すれば、購入手続きに進むことができます。ただしこのボタンはJavaScriptで動作しているため、スクリプトファイルが存在しないと動作しません。「カートに入れる」ボタンを押しても反応がないなら、リロードして再挑戦が必要です。

情報入力〜最終確認

うまくカートに入れることができたら、そこからは忍耐で先に進めることができます。フォームに必要な情報を入力し「次へ」などのボタンを押します。画面が出てこなかったらリロード。「フォームの情報を再送信しますか?」のようなダイアログがでたら「送信する」「はい」などのボタンを押します。

購入確定

クレジット決済の場合、最後の画面はクレジットカードのセキュリティコードを入れて「注文を確定」ボタンを押すことになります。このボタンもJavaScriptで動いており、サーバーに飛ばした購入確定リクエストが受理されてやっと注文確定となります。

この画面はデータベースサーバーが生きていても「システムエラー」が表示されることがあるので、リロードを試してみましょう。

「注文を確定」ボタンを押しても画面が変化せず、再度「注文を確定」ボタンを押すと「処理中です」のダイアログが表示される場合、JavaScriptのリクエストがサーバーまで届いていません。リロードしてセキュリティーコードの入力からやり直しです。

JavaScriptの処理が完了すると、ほぼその場で注文確定メールが飛んできます。おめでとう!

システム屋としての分析

ここからはWebシステムについての少し技術的な話になります。

外から見ると、システムはこんな感じで動いています。

  • システムは(おそらく全体的に)AWS上で構築されている
  • Webサーバは4台、ELBではなくDNSラウンドロビン
  • アプリケーションはPHP
  • CDNは使わず、Assetの大半はAPサーバーから配布している
    • 一部S3から配布しているものもある

Amazon Web Services実践入門 (WEB+DB PRESS plus)

Amazon Web Services実践入門 (WEB+DB PRESS plus)

システム担当の中の人のことを考えるとこっちまでゾッとする気持ちですが、勝手に問題点と改善方法を考えてみました。

  • ELBを導入する
    • 現在の設定では高負荷時のスケールアウトが非常に大変です。ELBを導入し、ピークに備えて暖気しておく / APサーバーを増やしておく必要があるでしょう。
  • データベースサーバーを強化する
    • データベースサーバーでのタイムアウトが頻発しているように見えました。インスタンスタイプを大きくする、RDSに乗り換えるなどの増強策が必要でしょう。停止メンテを伴う事前準備をしなければなりませんが、「7/1 10:00」が急に決まったわけでもないはずだし…。
  • 静的ファイルはCDNから配布する
    • 「カートに入れる」ためのスクリプトが落ちてこないため、最初のステップがいきなりハードルの高いものになっていました。js、css、画像などはS3→CloudFrontなどのCDN経由で配布することで、アプリケーションの動作も軽くなるし、APサーバーの負荷も軽減できます。
  • JavaScriptによる注文確定処理の改善
    • 注文確定ボタンを押しても結果が表示されず、経験がない人はそのまま無限に待たされる状態になっていました。JSによるリクエストの成否はその場で表示するべきでしょう。
  • 冗長な購入フローの改善
    • 「カートに入れる」→「確認画面」までは、単に入力情報をサーバーサイドでバリデーション(検証)し、その結果はローカルで引き回していたようです(フォームの再送信を何度も行えたことから推測)。今回のような事情では逆に助かりましたが、アプリケーションの作りとしては不安が残ります。また、画面数が多いことで購入が煩雑に感じられてしまいます。

現場のインフラ屋が教える インフラエンジニアになるための教科書

現場のインフラ屋が教える インフラエンジニアになるための教科書

ということで

「ラン活」とやらに巻き込まれた経験についてまとめてみました。

  • 世の中からヘボなWebシステムが撲滅されますように
  • 中の人、強く生きてね
  • 世界一かわいくてかしこくてかっこいい我が家のムスコさんがランドセルを背負うのが楽しみだ

追記 [2016-07-02 11:26]

システム屋から見た土屋鞄ランドセル戦争 - かっぱラクガキ帳

ここはEC-CUBEを採用しているような?EC-CUBEってそもそもサーバ負荷が高そうなイメージがあるんですけどどうなんでしょうね。

2016/07/02 11:13
b.hatena.ne.jp

…というブコメをもらいました。JSのfunction名でググってみるとEC-CUBEの記事が引っかかるので当たりっぽいですね。つらそうだ…いろんな意味で…(PHPの大規模OSSプロダクトにいい思い出がない…)

EC-CUBE 3 店舗運営&デザインカスタマイズガイド

EC-CUBE 3 店舗運営&デザインカスタマイズガイド