ソフトウェア業界２５（マラソン大会申し込み）
大手のマラソンのwebサイトで、
人気のあるマラソン大会(2大会）の先着順の申し込みが、
6/1 20:00開始だったのですが、
アクセスが集中して、エラー画面が多発してなかなか申し込めなかったようです。
（定員に達したのは3:00くらい。皆さん7時間くらいエラーと闘いながらずっとやってたようです。）
去年も、遅いしエラーが出ると悪評でして、
今年はサーバを増強したから大丈夫という触れ込みだったのですが、
ダメだったようです。
東京マラソンのように抽選ならよいのですが、
早い者勝ちなのに途中でエラーになってやり直しというのはまったく困ったものです。
原因は、プログラムやサーバマシンの性能ではなく、ネットワーク系で、
公式HPによると
「アクセス集中においてネットワーク機器（ロードバランサーとルーター）の故障が発生し、処理が滞りました。」
とのことです。
ロードバランサーとルーターの両方なのでしょうか？
ロードバランサーは複数サーバある場合に、すいているサーバに処理を振り別けるという機器。
ルータは複数サーバを繋いでるネットワーク上の中継機器。
たぶん、機器の性能を超えるアクセスがあったのでしょう。
ネットワーク構成にもよりますが、高いのに変えれば大丈夫でしょう。
「さらにアクセス集中により、暗号化と復号を行うＳＳＬアクセラレーターにもエラーが生じ、」（公式HPより）
いわゆるhttpsの暗号の処理。通常はWebサーバで行いますが、
Webサーバでの負荷を減らすために、外出し（ＳＳＬアクセラレーター）することがある。
このシステムは混み合っている時は「混雑しています」と画面表示されて、次の画面に進めないような仕組みになっていますが、
「混雑しています」の時はまだhttpで、混雑を脱して入力画面に繋がってからがhttpsなので、
入力画面に進める敷居が低いんじゃないのかな。つまりＳＳＬアクセラレーターの性能を考慮して、
「混雑しています」から入力画面に進める条件を決めないといけなかったでしょう。
敷居値を下げるか、高いＳＳＬアクセラレーターにするかですかね。
今までは「混雑しています」のみではなく、
「次の画面に進むのに○人待ってます。予想待ち時間は○分です」と丁寧な表示だったので、
「混雑しています」の仕組みを変えると同時に、敷居値も変えたのでしょう。
なお、ＳＳＬアクセラレーターの性能確認のついでに、Firewallの性能も確認しておいたほうがよいでしょう。
なにをやったにせよ事前にアクセス集中・多量アクセスの試験をしなかったんでしょうね、
やっていれば判ったはずなので。
（実際にやらなくても、想定アクセス数やスペックから、ルータの性能を超えているかどうかは算出はできると思うが）
申し込み枠は2大会併せて2万くらい？
定員を超えるアクセスがあるだろうし、1名で複数ブラウザ、スマフォとか使用することを考えたらその
3,4倍の6～8万くらいでの同時アクセスでの確認をしておくべきでしたね。（3,4倍でも足りないかも）
（満員の東京ドームとか埼玉スタジウムの観客が一斉にアクセスするような規模ですね）
ま、マラソン大会に出場するのも大変ということです。
今回システム障害のあったのは、湘南国際マラソンという大会で、大磯-鎌倉の海辺を走るものらしいです。
個人的には、参加費は1万円するし、人がうじゃうじゃいるところをわざわざ走らなくてもよいと思うので、出場したいとは思わないです。
「抽選」と違って「先着順」のよいところは、
当たれば儲けものという人でなく、絶対に出場したいという人のみが時間かかっても頑張って申し込もうとするところだから、
その点では当初の目的は果たせたのかもｗ
人気のあるマラソン大会(2大会）の先着順の申し込みが、
6/1 20:00開始だったのですが、
アクセスが集中して、エラー画面が多発してなかなか申し込めなかったようです。
（定員に達したのは3:00くらい。皆さん7時間くらいエラーと闘いながらずっとやってたようです。）
去年も、遅いしエラーが出ると悪評でして、
今年はサーバを増強したから大丈夫という触れ込みだったのですが、
ダメだったようです。
東京マラソンのように抽選ならよいのですが、
早い者勝ちなのに途中でエラーになってやり直しというのはまったく困ったものです。
原因は、プログラムやサーバマシンの性能ではなく、ネットワーク系で、
公式HPによると
「アクセス集中においてネットワーク機器（ロードバランサーとルーター）の故障が発生し、処理が滞りました。」
とのことです。
ロードバランサーとルーターの両方なのでしょうか？
ロードバランサーは複数サーバある場合に、すいているサーバに処理を振り別けるという機器。
ルータは複数サーバを繋いでるネットワーク上の中継機器。
たぶん、機器の性能を超えるアクセスがあったのでしょう。
ネットワーク構成にもよりますが、高いのに変えれば大丈夫でしょう。
「さらにアクセス集中により、暗号化と復号を行うＳＳＬアクセラレーターにもエラーが生じ、」（公式HPより）
いわゆるhttpsの暗号の処理。通常はWebサーバで行いますが、
Webサーバでの負荷を減らすために、外出し（ＳＳＬアクセラレーター）することがある。
このシステムは混み合っている時は「混雑しています」と画面表示されて、次の画面に進めないような仕組みになっていますが、
「混雑しています」の時はまだhttpで、混雑を脱して入力画面に繋がってからがhttpsなので、
入力画面に進める敷居が低いんじゃないのかな。つまりＳＳＬアクセラレーターの性能を考慮して、
「混雑しています」から入力画面に進める条件を決めないといけなかったでしょう。
敷居値を下げるか、高いＳＳＬアクセラレーターにするかですかね。
今までは「混雑しています」のみではなく、
「次の画面に進むのに○人待ってます。予想待ち時間は○分です」と丁寧な表示だったので、
「混雑しています」の仕組みを変えると同時に、敷居値も変えたのでしょう。
なお、ＳＳＬアクセラレーターの性能確認のついでに、Firewallの性能も確認しておいたほうがよいでしょう。
なにをやったにせよ事前にアクセス集中・多量アクセスの試験をしなかったんでしょうね、
やっていれば判ったはずなので。
（実際にやらなくても、想定アクセス数やスペックから、ルータの性能を超えているかどうかは算出はできると思うが）
申し込み枠は2大会併せて2万くらい？
定員を超えるアクセスがあるだろうし、1名で複数ブラウザ、スマフォとか使用することを考えたらその
3,4倍の6～8万くらいでの同時アクセスでの確認をしておくべきでしたね。（3,4倍でも足りないかも）
（満員の東京ドームとか埼玉スタジウムの観客が一斉にアクセスするような規模ですね）
ま、マラソン大会に出場するのも大変ということです。
今回システム障害のあったのは、湘南国際マラソンという大会で、大磯-鎌倉の海辺を走るものらしいです。
個人的には、参加費は1万円するし、人がうじゃうじゃいるところをわざわざ走らなくてもよいと思うので、出場したいとは思わないです。
「抽選」と違って「先着順」のよいところは、
当たれば儲けものという人でなく、絶対に出場したいという人のみが時間かかっても頑張って申し込もうとするところだから、
その点では当初の目的は果たせたのかもｗ