sugilogのブログスマートフォン用の表示で見るsugilogのブログこの広告は、90日以上更新していないブログに表示しています。2018-05-28ツールド東北2018先着順エントリー@JTBスポーツステーションの問題点をウェブアプリケーションプログラマー視点で考えてみる5月26日(土)20時からツールド東北2018一般参加者のための先着順エントリーが開始され、まさかの状態になりました。検索しただけのまとめを作っておいたのでそちらで見ていただけます。togetter.comまさかの状態とは?ざっくりいうと、アクセス集中によるサーバー負荷高等のため、ユーザーがエントリーをうまく進めることができない状態(=不具合がある状態)が続きました。5月26日22時現在、参加エントリーページにアクセスしづらい状況が続いておりご迷惑をおかけし大変申し訳ありません。サイトに接続しづらい状態、一部のお客様のエントリーが完了できない状態が続いております。恐れ入りますが、しばらく時間をおいてアクセスいただきますようお願い申し上げます。Japan)のお詫びによると、不具合が5時間ほど続きました。tourdetohoku.yahoo.co.jpちなみにシステム的に当事者に当たるJTBスポーツステーションがお詫びを出したのは2日たった5月28日(月)。jtbsports.jpこのエントリーでは謝罪が遅いとかうんぬんとかそういう話には触れません。ウェブアプリケーションプログラマー的に今回の問題を考えてみる自分はウェブアプリケーションのプログラマーです。ウェブアプリケーションプログラマーとして、今回のツールド東北2018@JTBスポーツステーションの問題を考えてみます。サーバーをあらかじめ増やしておくべき、みたいな話は出しません。そもそも今回のトラフィックが結局どのくらいあったのかもわかりません。問題点を以下の3点で整理してみます。申し込みステップが多すぎる。一部のサーバー負荷がシステム全体をダウンさせてしまう。JavaScriptによるフォームコントロールの存在によってUIが期待しないエラー状態になってしまう。申し込みステップが多すぎる今回のツールド東北2018@JTBスポーツステーションの申込みは、ステップをまとめると以下のようになっていました。(覚えている範囲です。)JTBスポーツステーションログインイベントページ申し込みコースの選択をするページ申し込み内容の入力をするページ申し込み内容の確認をするページ申込みの確認、というページ支払い方法の選択をするページ申込み内容の確定ページ支払い方法でクレジットカード決済を選択すると、更にステップが増えます。マイページから未決済イベントを選択。支払いの注意事項の確認をするページ。支払い方法の入力をするページ。覚えているだけで12ページあります。12ページのページ遷移全てでアクセスエラーになる可能性があります。エントリーは大事な内容を入力していますし、決済方法も大事な入力をしています。簡単にページ数を減らすことがいいとは言いづらいですが、ちょっと過剰です。申込み内容の入力は、連絡先の入力と緊急連絡先の入力をしています。事前でも事後でも入力できる内容=イベントとは本来直接関係しない入力内容です。申込みの確認、というページは、「申込み内容の入力ができました」「次は支払い方法を選択します」ということを言っているだけで、何も情報がありません。申込みの途中なので、仮受付状態になっている、みたいな話でもありません。するの?より前工程の申込みステップをシンプルに省略することができれば、それだけアクセスを削れます。丁寧な確認ステップを進ませたいのであれば、それだけインフラコストへ投資する必要がある、という言い方もできるかもしれません。一部のサーバー負荷がシステム全体をダウンさせてしまうJTBスポーツステーションは、システム全体が単一サーバー群で構成されていたような雰囲気があります。ツールド東北2018のエントリーが始まると同時に、JTBスポーツステーション自体へのアクセスや、JTBスポーツステーションへのログイン処理もアクセスエラーになり始めました。クレジットカード決済についても同様に、アクセスエラーが何度も発生しました。アクセス集中していたのは、ツールド東北2018イベントページ〜申し込み内容の入力あたりまでです。(すくなくとも、クレジットカード決済にアクセス集中していたことは考えづらいです。)つまり、一部の機能へのアクセス集中によって、システム全体がダウンしてしまっていた、という状態が考えられます。するの?クリティカルな機能をサーバー負荷から切り分けられるような構成をすることを検討できます。イベント申し込み機能クレジットカード決済機能その他の機能イベント申し込みは、先着順のような申込みの場合、一気にアクセスが集中する傾向があります。イベント申し込みにアクセス集中したとしても、クレジットカード決済には影響させない、というような切り分けを考えておくとよさそうです。アクセス集中する場合には、イベントの規模に合わせて、サーバーを増強しておくことができます。クレジットカード決済を切り分けるといいのは、お金のやりとりが発生する部分だから、です。決済方法を入力したあとにアクセスエラーが発生すると、決済ができたかどうかが不安になります。多重決済をしてしまった場合、ユーザークレーム〜補填をする必要もでてきます。アクセスするサーバー群を整理できたら、ボトルネックがデータベースに移るはず。JavaScriptによるフォームコントロールの存在によってUIが期待しないエラー状態になってしまうJTBスポーツステーションの申込みフォームのいくつかは、JavaScriptによってコントロールされていました。そのJavaScriptは、別ファイルで追加リソースとして読み込まれる内容に記述されていました。いえ、ここまではよくある話。問題は、アクセス集中によってサーバーへのアクセスがし辛い状態の中で、同じサーバーからJavaScriptを読み込もうとしていたのです。UIにはみえないところで、JavaScriptの読み込みがエラーしていました。JavaScriptの読み込みがエラーしたことで、申込みフォームを動かすためのJavaScriptコードが存在しないため、申込みフォームが反応しない、ということが発生していました。ちなみにですが、JTBスポーツステーションは、JavaScript以外にも画像やCSSもアプリケーションサーバーから配信しているように見えます。する?3つくらい方法があります。ミッションクリティカルなフォームのコントロールにJavaScriptを使わない。ミッションクリティカルなフォームコントロールするJavaScriptはHTMLの中に書いてしまう。JavaScriptのような静的ファイルはCDNを使って配信し、アプリケーションサーバーへアクセスさせない。1つ目の方法は最も簡単な方法ですが、申込みフォームの入力内容チェックなどができなくなります。2つ目の方法はありがちですが、JavaScriptライブラリに依存し始めた途端に実現が難しくなるかもしれません。単純にHTMLのファイルサイズが大きくなるだけなので、読み込みが遅くなることも予想されます。3つ目の方法はコストがかかる方法になりますが、JavaScriptに依存したUIをつくることが当たり前のようになっている今なら、最も現実的な方法だろうと考えます。先日ツールド東北2018のエントリーで起きたあれこれについて自...2015-01-24Go言語:HTTPサーバーのコーディングをしてみる↓のslideshareのコードを写経していく。勝手なまとめはてなブログをはじめよう!sugilogさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。