アカウント名:
パスワード:
横浜市の事例で注意すべき数字としては、「予約の対象となった高齢者は80歳以上の計34万人で、HPとコールセンターへの電話で7万5000人分を受け付ける予定だった。」というのが挙がるだろう。予約が可能な人々は約34万人なのに開始直後に200万件のアクセス。そんなものだろうか。しかし、家族の祖父母の予約を取るべく若手皆でアクセスして予約を試みるみたいな話もネットにはあるので、200万件ものアクセスとなったのだろうか。
まぁそもそもこうやって予約を取る形式では殺到するのが必至なのであって、高齢者なぞどうせ暇なのだから、最初から行政が日時を指定してその日時を封書で送り、都合の悪い人は電話やインターネットでアクセスして変更するという形式にすべきだったという主張もある。ただ高齢者自身が暇だったとしても、付添をしたり自家用車で会場に連れていく家族は暇ではないとも言える。
単に制度設計の問題のように思えます。上のコメントでもあるように、本来は一人1回の受付ならたいした負荷ではないはず。事前の周知が不十分なまま、完全早い者勝ちの予約にしたから負荷が集中しただけ。
私も行政が接種日をランダムに決めればいいともうのですが、不公平だと不満がでるのでしょうか。それなら他国に見習って、属性によって受付日や接種日を制限したらいいと思う。誕生月ごとに受付日を分散するだけでも、負荷は数分の一に減らせる。
＞完全早い者勝ちの予約にしたから負荷が集中しただけ。激しく同意。先着ではなく、「第一次予約,○月1日0時から7日0時まで……」みたいにしてその期間内ならいつ予約しても同じってルールにしておけば、そこまで殺到しないし、仮に今重くて繋がらないなら数時間後にやり直せばいいだけ。
なんで分かってない人は「先着」ロジックを入れたがるのか。先着は最悪なのに。
＞行政が接種日をランダムに決めればいいともうのですがさすがにランダムじゃイロイロ難しいんじゃない？この日は手術の予約が入ってるとか、一人じゃいけなくて介護する人の予定で何曜日じゃないとダメとか、個別の事情は様々だろうし。
日付日時の第三希望くらいまで入れさせておいて各枠内で抽選すりゃいいだけなのにな。
ただ、「だけ」と言い切るのは雑だけどな。先着順は抽選システムから抽選機能を省いたつくりだから、「ネットに予約システムを公開したら数百万件のアクセスが集中するのは当たり前」という常識がなければ、わざわざ公平かつ低負荷な抽選機能を入れようという行動には繋がりにくい。
＞ 「ネットに予約システムを公開したら数百万件のアクセスが集中するのは当たり前」という常識がなければ、先着順にしたら行列できて大変なことになるのは、ネットでなくても普通にあるじゃん。人気チケットでも、バーゲンセールでも。それこそコミケでも40年ほど前のガンプラブームでも。
そこで整理券というのを使うわけで。
＞わざわざ公平かつ低負荷な抽選機能を入れようというましてこれは「抽選」にする必要さえなくて、いずれにせよ現住所や年齢などから、最寄りの接種会場を割り当てていくだけだし、答が出るまで数時間バッチを走らせても問題ないので、
「公平」「低負荷」「抽選」の全部が当てはまらない。
これを考慮したのだろうね。ランダムに決められると当日来れない人は多くなり、接種会場は余裕があるのに人が来ない状況になりえる。そして再抽選になり、また都合が悪く当日来れないとなると、運が悪い人はいつまでたっても接種できず、接種会場もいつまでも終われない…。（これもまた、不満の報道につながる）
＞誕生月ごとに受付日を分散するだけでも、負荷は数分の一に減らせる。あんまり詳しくないんだけど、送付した案内状に記載した受付サーバーを誕生月別にuketuke01,uketuke02,,,,, uketuke12にわけるだけでも負荷最大12分の1やないのかな。12個サーバー立てるのが難しかったのか？サーバー一回立ち上げたら維持費大変か？そんなことないでしょ。いまなら、AWSとかCloudでスケーラブルにサーバー立てられるのに請負業者は提案できなかったんかな？
うちは世田谷でしたけれど、ログインに成功した後はナンバリングしているようなサーバー名が表示されていましたよ確か34とかなんとか
重いことは重かったのですが、F5を繰り返していれば途中で弾かれたりはせずに登録できましたね
世田谷区ですが、2日目でようやく登録できました。たしか5分前時点ででつながらないようになってましたね。
トラブル案件で健康診断キャンセル2回したので電話で申し込みになったので今年も忘れそうです。
世田谷区長のツイートから計算すると、世田谷区のシステムはwebで予約を１分あたり15件ほど処理しているペースのようなのですが、web予約ってそんなものなのでしょうか？電話の方は１分あたり10件くらいの処理ペースのようです。
もしかしてwebも中で人が作業してる？
トランザクション処理＋排他制御(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:Anonymous Coward (スコア:3, すばらしい洞察)
単に制度設計の問題のように思えます。
上のコメントでもあるように、本来は一人1回の受付ならたいした負荷ではないはず。
事前の周知が不十分なまま、完全早い者勝ちの予約にしたから負荷が集中しただけ。
私も行政が接種日をランダムに決めればいいともうのですが、不公平だと不満がでるのでしょうか。
それなら他国に見習って、属性によって受付日や接種日を制限したらいいと思う。
誕生月ごとに受付日を分散するだけでも、負荷は数分の一に減らせる。
Re:Anonymous Coward (スコア:3, すばらしい洞察)
＞完全早い者勝ちの予約にしたから負荷が集中しただけ。
激しく同意。
先着ではなく、「第一次予約,○月1日0時から7日0時まで……」みたいにして
その期間内ならいつ予約しても同じってルールにしておけば、そこまで殺到
しないし、仮に今重くて繋がらないなら数時間後にやり直せばいいだけ。
なんで分かってない人は「先着」ロジックを入れたがるのか。先着は最悪なのに。
＞行政が接種日をランダムに決めればいいともうのですが
さすがにランダムじゃイロイロ難しいんじゃない？
この日は手術の予約が入ってるとか、一人じゃいけなくて介護する人の
予定で何曜日じゃないとダメとか、個別の事情は様々だろうし。
Re:Anonymous Coward (スコア:1)
日付日時の第三希望くらいまで入れさせておいて各枠内で抽選すりゃいいだけなのにな。
ただ、「だけ」と言い切るのは雑だけどな。先着順は抽選システムから抽選機能を省いたつくりだから、
「ネットに予約システムを公開したら数百万件のアクセスが集中するのは当たり前」という常識がなければ、
わざわざ公平かつ低負荷な抽選機能を入れようという行動には繋がりにくい。
Re: (スコア:0)
＞ 「ネットに予約システムを公開したら数百万件のアクセスが集中するのは当たり前」という常識がなければ、
先着順にしたら行列できて大変なことになるのは、ネットでなくても
普通にあるじゃん。人気チケットでも、バーゲンセールでも。
それこそコミケでも40年ほど前のガンプラブームでも。
そこで整理券というのを使うわけで。
＞わざわざ公平かつ低負荷な抽選機能を入れようという
ましてこれは「抽選」にする必要さえなくて、いずれにせよ現住所や
年齢などから、最寄りの接種会場を割り当てていくだけだし、答が
出るまで数時間バッチを走らせても問題ないので、
「公平」「低負荷」「抽選」の全部が当てはまらない。
Re: (スコア:0)
＞行政が接種日をランダムに決めればいいともうのですが
さすがにランダムじゃイロイロ難しいんじゃない？
この日は手術の予約が入ってるとか、一人じゃいけなくて介護する人の
予定で何曜日じゃないとダメとか、個別の事情は様々だろうし。
これを考慮したのだろうね。
ランダムに決められると当日来れない人は多くなり、接種会場は余裕があるのに人が来ない状況になりえる。
そして再抽選になり、また都合が悪く当日来れないとなると、
運が悪い人はいつまでたっても接種できず、接種会場もいつまでも終われない…。
（これもまた、不満の報道につながる）
Re: (スコア:0)
＞誕生月ごとに受付日を分散するだけでも、負荷は数分の一に減らせる。
あんまり詳しくないんだけど、送付した案内状に記載した受付サーバーを誕生月別に
uketuke01,uketuke02,,,,, uketuke12
にわけるだけでも負荷最大12分の1やないのかな。12個サーバー立てるのが難しかったのか？
サーバー一回立ち上げたら維持費大変か？そんなことないでしょ。いまなら、AWSとかCloudでスケーラブルにサーバー立てられるのに請負業者は提案できなかったんかな？
Re:Anonymous Coward (スコア:3, 参考になる)
うちは世田谷でしたけれど、ログインに成功した後はナンバリングしているようなサーバー名が表示されていましたよ
確か34とかなんとか
重いことは重かったのですが、F5を繰り返していれば途中で弾かれたりはせずに登録できましたね
Re:Anonymous Coward (スコア:1)
世田谷区ですが、2日目でようやく登録できました。
たしか5分前時点ででつながらないようになってましたね。
トラブル案件で健康診断キャンセル2回したので電話で申し込みになったので今年も忘れそうです。
１分で15件しか予約処理できない？ (スコア:0)
世田谷区長のツイートから計算すると、世田谷区のシステムはwebで予約を１分あたり15件ほど処理しているペースのようなのですが、web予約ってそんなものなのでしょうか？電話の方は１分あたり10件くらいの処理ペースのようです。
もしかしてwebも中で人が作業してる？
Re:Anonymous Coward (スコア: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)
あくまでスケーリングの要件策定は顧客やコンサルの責務であることが多いので、
（対象とするクライアント、見込数は業務要件の範囲）
システム屋からしたら言われた要件に耐えるだけのインフラ用意したのに
それ以上アクセスが殺到して落ちたからって知らんがなって話です。
コンサル部分まで担ってたなら見積が甘いと叱られてもしょうがないですけどね。
Re: (スコア:0)
ロックしない設計は面倒くさかったなあ…
Re: (スコア:0)
データベースも複数個作ってあとで結合すればいいのでは。
Re: (スコア:0)
そりゃ早くワクチンを接種すればそれだけ生き残れる確率が上がるからな。
Re: (スコア:0)
そんな簡単じゃない
無期限に効果があるもんでもない
Re: (スコア:0)
> 私も行政が接種日をランダムに決めればいいともうのですが、不公平だと不満がでるのでしょうか。
ランダムにすると都合が悪くて行けない人が続出して、用意したワクチンが余ってしまうから。
確実に接種会場に来れる日を選ぶ必要がありますよね。
抽選してランダムに決めて、その日に接種会場に来れるかどうかで確定すればよさそう。