アカウント名:
パスワード:
横浜市の事例で注意すべき数字としては、「予約の対象となった高齢者は80歳以上の計34万人で、HPとコールセンターへの電話で7万5000人分を受け付ける予定だった。」というのが挙がるだろう。予約が可能な人々は約34万人なのに開始直後に200万件のアクセス。そんなものだろうか。しかし、家族の祖父母の予約を取るべく若手皆でアクセスして予約を試みるみたいな話もネットにはあるので、200万件ものアクセスとなったのだろうか。
まぁそもそもこうやって予約を取る形式では殺到するのが必至なのであって、高齢者なぞどうせ暇なのだから、最初から行政が日時を指定してその日時を封書で送り、都合の悪い人は電話やインターネットでアクセスして変更するという形式にすべきだったという主張もある。ただ高齢者自身が暇だったとしても、付添をしたり自家用車で会場に連れていく家族は暇ではないとも言える。
単に制度設計の問題のように思えます。上のコメントでもあるように、本来は一人1回の受付ならたいした負荷ではないはず。事前の周知が不十分なまま、完全早い者勝ちの予約にしたから負荷が集中しただけ。
私も行政が接種日をランダムに決めればいいともうのですが、不公平だと不満がでるのでしょうか。それなら他国に見習って、属性によって受付日や接種日を制限したらいいと思う。誕生月ごとに受付日を分散するだけでも、負荷は数分の一に減らせる。
＞誕生月ごとに受付日を分散するだけでも、負荷は数分の一に減らせる。あんまり詳しくないんだけど、送付した案内状に記載した受付サーバーを誕生月別にuketuke01,uketuke02,,,,, uketuke12にわけるだけでも負荷最大12分の1やないのかな。12個サーバー立てるのが難しかったのか？サーバー一回立ち上げたら維持費大変か？そんなことないでしょ。いまなら、AWSとかCloudでスケーラブルにサーバー立てられるのに請負業者は提案できなかったんかな？
トランザクション処理＋排他制御(1人１予約)が入るから、（アルゴリズムに工夫を入れないと）単純にサーバを増やすだけじゃさばききれないよ。「過負荷に耐えるWebの作り方――国民的アイドルグループ選抜総選挙の舞台裏」(2013年12月)を読むと分かるけど、Webブラウザってアプリと違って自由なふるまいするし。AKB48の総選挙より高いか同程度の負荷ってかなりつらいよ。
タレコミ主です。
「過負荷に耐えるWebの作り方――国民的アイドルグループ選抜総選挙の舞台裏」(2013年12月)を読むと分かるけど
なるほど、こういうのを探すことができれば端的に個人的な興味を充足させることができたわけですね。うちも1つ上の#4025226のコメ主と同じで世田谷だったんですけど、エラーメッセージなどからすると選定業者はまさにこのパイプドビッツ [pi-pe.co.jp]というところでした。そうなると、すくなくともこうした高負荷・過負荷に耐えるような技術力は持っていたということは認めるべきで、それ以上の負荷がかかってしまったということなのでしょうかね。それともそもそも手に余るような処理だったんでしょうか。想定しうる負荷を見積もる能力も含めての"技術力"と考えれば、こちらの捉え方のほうが的確か。その辺のところを今後に向けても（注文主・請負主ともに）きちんと検証してもらいたいところです。
パイプドビッツの採用情報見たけど、これ技術持ってる社員が転職していくパターンじゃなかろうか
まあ引継ぎ資料くらいは作らせるでしょ。引き継ぐ人間が理解できるかはともかく。
ちょっと良いかもと思ったけど、今時PHPやJavaって時点で・…・
じゃあ何だったらイマドキなの？今時じゃない言語は劣ってるの？
高負荷になるウェブサービスは私でもJavaを第一選択にするな。負荷設計がやりやすいし、単純に性能も出しやすい（ノウハウが転がってる）
あくまでスケーリングの要件策定は顧客やコンサルの責務であることが多いので、（対象とするクライアント、見込数は業務要件の範囲）システム屋からしたら言われた要件に耐えるだけのインフラ用意したのにそれ以上アクセスが殺到して落ちたからって知らんがなって話です。
コンサル部分まで担ってたなら見積が甘いと叱られてもしょうがないですけどね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
Anonymous Coward (スコア:0)
横浜市の事例で注意すべき数字としては、
「予約の対象となった高齢者は80歳以上の計34万人で、HPとコールセンターへの電話で7万5000人分を受け付ける予定だった。」
というのが挙がるだろう。予約が可能な人々は約34万人なのに開始直後に200万件のアクセス。そんなものだろうか。
しかし、家族の祖父母の予約を取るべく若手皆でアクセスして予約を試みるみたいな話もネットにはあるので、200万件ものアクセスとなったのだろうか。
まぁそもそもこうやって予約を取る形式では殺到するのが必至なのであって、高齢者なぞどうせ暇なのだから、
最初から行政が日時を指定してその日時を封書で送り、都合の悪い人は電話やインターネットでアクセスして変更するという形式にすべきだったという主張もある。
ただ高齢者自身が暇だったとしても、付添をしたり自家用車で会場に連れていく家族は暇ではないとも言える。
Re: (スコア:3, すばらしい洞察)
単に制度設計の問題のように思えます。
上のコメントでもあるように、本来は一人1回の受付ならたいした負荷ではないはず。
事前の周知が不十分なまま、完全早い者勝ちの予約にしたから負荷が集中しただけ。
私も行政が接種日をランダムに決めればいいともうのですが、不公平だと不満がでるのでしょうか。
それなら他国に見習って、属性によって受付日や接種日を制限したらいいと思う。
誕生月ごとに受付日を分散するだけでも、負荷は数分の一に減らせる。
Re: (スコア:0)
＞誕生月ごとに受付日を分散するだけでも、負荷は数分の一に減らせる。
あんまり詳しくないんだけど、送付した案内状に記載した受付サーバーを誕生月別に
uketuke01,uketuke02,,,,, uketuke12
にわけるだけでも負荷最大12分の1やないのかな。12個サーバー立てるのが難しかったのか？
サーバー一回立ち上げたら維持費大変か？そんなことないでしょ。いまなら、AWSとかCloudでスケーラブルにサーバー立てられるのに請負業者は提案できなかったんかな？
Re: (スコア:2, 興味深い)
トランザクション処理＋排他制御(1人１予約)が入るから、（アルゴリズムに工夫を入れないと）単純にサーバを増やすだけじゃさばききれないよ。
「過負荷に耐えるWebの作り方――国民的アイドルグループ選抜総選挙の舞台裏」(2013年12月)を読むと分かるけど、Webブラウザってアプリと違って自由なふるまいするし。AKB48の総選挙より高いか同程度の負荷ってかなりつらいよ。
Re:Anonymous Coward (スコア:1)
タレコミ主です。
「過負荷に耐えるWebの作り方――国民的アイドルグループ選抜総選挙の舞台裏」(2013年12月)を読むと分かるけど
なるほど、こういうのを探すことができれば端的に個人的な興味を充足させることができたわけですね。
うちも1つ上の#4025226のコメ主と同じで世田谷だったんですけど、エラーメッセージなどからすると選定業者はまさにこのパイプドビッツ [pi-pe.co.jp]というところでした。
そうなると、すくなくともこうした高負荷・過負荷に耐えるような技術力は持っていたということは認めるべきで、それ以上の負荷がかかってしまったということなのでしょうかね。
それともそもそも手に余るような処理だったんでしょうか。想定しうる負荷を見積もる能力も含めての"技術力"と考えれば、こちらの捉え方のほうが的確か。
その辺のところを今後に向けても（注文主・請負主ともに）きちんと検証してもらいたいところです。
Re: (スコア:0)
パイプドビッツの採用情報見たけど、これ技術持ってる社員が転職していくパターンじゃなかろうか
Re: (スコア:0)
まあ引継ぎ資料くらいは作らせるでしょ。
引き継ぐ人間が理解できるかはともかく。
ちょっと良いかもと思ったけど、今時PHPやJavaって時点で・…・
Re: (スコア:0)
じゃあ何だったらイマドキなの？
今時じゃない言語は劣ってるの？
Re:Anonymous Coward (スコア:2)
高負荷になるウェブサービスは私でもJavaを第一選択にするな。
負荷設計がやりやすいし、単純に性能も出しやすい（ノウハウが転がってる）
Re: (スコア:0)
あくまでスケーリングの要件策定は顧客やコンサルの責務であることが多いので、
（対象とするクライアント、見込数は業務要件の範囲）
システム屋からしたら言われた要件に耐えるだけのインフラ用意したのに
それ以上アクセスが殺到して落ちたからって知らんがなって話です。
コンサル部分まで担ってたなら見積が甘いと叱られてもしょうがないですけどね。