ワクチン接種の予約受付におけるサーバー負荷について 154
ストーリー by headless
不可 部門より
不可 部門より
あるAnonymous Coward 曰く、
各自治体でCOVID-19に対するワクチン接種の予約受付が続々開始されているが、とくに多数の接種希望者が殺到した大都市では住民からの不満の声が渦巻いているようだ(朝日新聞デジタルの記事、 カナロコの記事、 デイリースポーツオンラインの記事)。
これら報道の中でとりわけ興味深かったのは、横浜市の事例で、具体的に予約受付サーバーにおける瞬間的負荷が報じられていたことだ。それによると、1分あたり最大100万件のアクセスを想定していたが、開始直後に200万件のアクセスがあった
とのことであり、秒間1万6千強の要求を想定していたところ、実際には3万3千あまりの要求があったことが伺える。
タレコミ主は瞬間的な高負荷が予想されるような大規模サーバーの構築に携わったことはないが、通販サイトの構築の一端を担った経験から、静的なレスポンスを返すだけの単純な処理にとどまらずバックエンドのDBでのトランザクションを含めた処理も考慮しての高負荷処理への対応はそもそもどの程度まで可能なのか、技術的観点から興味がある。ざっと調べたところ、あるネットゲームでは秒間10万のトランザクションが可能ということなので、横浜市の事例は十分対応可能範囲内に収まる計算にはなる (編注: 記事で言及されているのはCygamesのシステムで、東証アローヘッドやTwitterよりも規模が大きい)。
CDNが待機室を提供するサービスとか (スコア:5, 興味深い)
CDN(ここではCloudflare)が待機室を提供するサービス。
アクセスしたユーザが、CDNでキューイングされるので、オリジンサイトが落ちる最悪の事態が防げる。
キューに入った人には、「おとなしく待ってろよ」みたいなメッセージが出るみたい。
DNSからCDN(Cloudflare)に向ける必要があるけど、オリジンサイトの修正がほぼ不要なのがメリットかな。
現時点ではワクチン予約サイト向けに無償で利用できるみたいだけど、実際に利用されてるかどうかは不明。
https://www.cloudflare.com/ja-jp/waiting-room/ [cloudflare.com]
https://www.classmethod.cf/fairshot [classmethod.cf]
そもそもこんなのを自治体にバラバラに投げてるのが悪い (スコア:1)
10万円の給付金の時もそうだったけれど、日本全国で同じことをするのに、バラバラにやらせようとするのが頭が悪い。
共通の申し込みシステムを国が用意するだけで済むのに。
Re:そもそもこんなのを自治体にバラバラに投げてるのが悪い (スコア:4, すばらしい洞察)
それな
こういうシステム作って自治体に配る仕事じゃないのか
ディジタル庁って
Re:そもそもこんなのを自治体にバラバラに投げてるのが悪い (スコア:1)
> それができるのがマイナンバー制だけど
現実は全く追い付いてない。
現場は予算もノウハウも全くなし。
確か、10万円の時、電子化とか言って、Webにしたが、裏では職員が手作業で照合とか。
野党云々以前に、見掛け倒しのシステム。
Re:そもそもこんなのを自治体にバラバラに投げてるのが悪い (スコア:1)
え?マイナンバーの前身である住基システムですでに可能になってなかった?
https://www.pref.fukuoka.lg.jp/uploaded/attachment/62500.pdf [fukuoka.lg.jp]
住民基本台帳ネットワークシステム(以下「住基ネット」という。)は、全国の地方公共団体を専用回線で結び、市町村ごとに運用されていた住民基本台帳(住民票を各市町村でまとめたもの。)に関するシステムをネットワーク化することにより、全国共通の本人確認を可能とするシステムで、平成14年8月から運用が開始されています。
ポンチ絵見ると機構に全国サーバがあって、そこで全国の住民の本人確認情報が集約されてることになってる。
Re:そもそもこんなのを自治体にバラバラに投げてるのが悪い (スコア:2, 興味深い)
それ仕事で絶対に受けたらダメなやつだ。
全都道府県の個別のデータベースに対応した、汎用の予約ソフト?
個別にデータ変換する機能も込みで?
テストだけでどれだけの工数かかるやら…え、1か月でリリースしろと?
アホな営業が何も考えずにこういう話持ってきて、開発側から袋叩きにあうのはそこそこある話か。
Re:そもそもこんなのを自治体にバラバラに投げてるのが悪い (スコア:1)
何を指しているか意味不明なクラウドって言葉に置き換えれば満足するかい?
もともとある言葉を、逆に分かりにくい言葉に置き換えるのは馬鹿げている。
Re:そもそもこんなのを自治体にバラバラに投げてるのが悪い (スコア:2)
全自治体が受け付け開始時間を同日同時刻にしたらそうなるね
東証アローヘッドは(オフトピ (スコア:1)
東証アローヘッドはサーバー内の処理時間を0.2msec以下に収めて応答してるらしいので、普通のWEBシステムの比較対象に出さないであげて・・・
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)
>誕生月ごとに受付日を分散するだけでも、負荷は数分の一に減らせる。
あんまり詳しくないんだけど、送付した案内状に記載した受付サーバーを誕生月別に
uketuke01,uketuke02,,,,, uketuke12
にわけるだけでも負荷最大12分の1やないのかな。12個サーバー立てるのが難しかったのか?
サーバー一回立ち上げたら維持費大変か?そんなことないでしょ。いまなら、AWSとかCloudでスケーラブルにサーバー立てられるのに請負業者は提案できなかったんかな?
Re:Anonymous Coward (スコア:3, 参考になる)
うちは世田谷でしたけれど、ログインに成功した後はナンバリングしているようなサーバー名が表示されていましたよ
確か34とかなんとか
重いことは重かったのですが、F5を繰り返していれば途中で弾かれたりはせずに登録できましたね
Re:Anonymous Coward (スコア:1)
世田谷区ですが、2日目でようやく登録できました。
たしか5分前時点ででつながらないようになってましたね。
トラブル案件で健康診断キャンセル2回したので電話で申し込みになったので今年も忘れそうです。
Re:Anonymous Coward (スコア:2, 興味深い)
トランザクション処理+排他制御(1人1予約)が入るから、(アルゴリズムに工夫を入れないと)単純にサーバを増やすだけじゃさばききれないよ。
「過負荷に耐えるWebの作り方――国民的アイドルグループ選抜総選挙の舞台裏」(2013年12月)を読むと分かるけど、Webブラウザってアプリと違って自由なふるまいするし。AKB48の総選挙より高いか同程度の負荷ってかなりつらいよ。
Re:Anonymous Coward (スコア:1)
タレコミ主です。
「過負荷に耐えるWebの作り方――国民的アイドルグループ選抜総選挙の舞台裏」(2013年12月)を読むと分かるけど
なるほど、こういうのを探すことができれば端的に個人的な興味を充足させることができたわけですね。
うちも1つ上の#4025226のコメ主と同じで世田谷だったんですけど、エラーメッセージなどからすると選定業者はまさにこのパイプドビッツ [pi-pe.co.jp]というところでした。
そうなると、すくなくともこうした高負荷・過負荷に耐えるような技術力は持っていたということは認めるべきで、それ以上の負荷がかかってしまったということなのでしょうかね。
それともそもそも手に余るような処理だったんでしょうか。想定しうる負荷を見積もる能力も含めての"技術力"と考えれば、こちらの捉え方のほうが的確か。
その辺のところを今後に向けても(注文主・請負主ともに)きちんと検証してもらいたいところです。
Re:Anonymous Coward (スコア:2)
高負荷になるウェブサービスは私でもJavaを第一選択にするな。
負荷設計がやりやすいし、単純に性能も出しやすい(ノウハウが転がってる)
Re:Anonymous Coward (スコア:1)
親が横浜市に住んでいるので、私のほうで予約を取るようにしていたので、200万アクセスの片棒を担いだ一人です。
対象となる方が、約53万人で、その人全員に対して、3日 9時から予約申し込みをさせるのですから、
こうなるのは、予想していましたが、あまりにも無策でしたね。
さらに、この日は休日なので、家族全員でアクセスをしたところもあるでしょうから、
もっと多めのアクセス数を見積もるべきだと思います。
区ごとにサーバを分けるなり、人によって開始時期をランダムにするなど、
もっと負荷分散をするべきだったかなと思います。
ソシャゲ運用をしたことのある会社なら、うまくいったのかもしれません。
有名なIPものだと、サービス開始やCMを打ったあとは、もっとアクセス数は集中するので
神奈川県民どんだけいると思っているのか (スコア:0)
史上最大の最大瞬間風速に対応するべきか、そこまでは想定しない瞬間最大風速にすべきかという考え方ではだめかなあ?
神奈川の中でも自治体をして申し込めるようにすれば、最初は横浜市中区、次は川崎市中川区、みたいにすれば負荷は減らせるような。
それでも今回は厳しいか。
Re:神奈川県民どんだけいると思っているのか (スコア:3, おもしろおかしい)
神奈川県町田市、神奈川県熱海市、神奈川県三島市、神奈川県御殿場市等々含めると、みなさんが想像しているよりも神奈川県民は多いですよね
Re: (スコア:0)
ソース記事読もうよ
なんかアクセスが多くないか? (スコア:0)
予約対象者は34万人しかいないから100万アクセス/分は妥当そうにみえるんだけど、何をどうすれば200万アクセス/分も来るんだろ。攻撃も受けていたのかな?
Re:なんかアクセスが多くないか? (スコア:2)
予約対象者は34万人しかいないから100万アクセス/分は妥当そうにみえるんだけど、何をどうすれば200万アクセス/分も来るんだろ。攻撃も受けていたのかな?
想像(偏見?)ですが、80歳以上だとWEBから予約できる人は少数で、電話が多いでしょうね。
予約可能対象者(max34万人)ではない人たちからのアクセスが殺到してそう。
・高齢者周辺で代行で予約をしようとした友人家族や介護をしている方達。
・対象者ではなくて興味本位でアクセス(マスコミ?)。
・それ以外(攻撃?)。
そして 05/05 09:00から再開してたらしい
https://www.city.yokohama.lg.jp/kurashi/kenko-iryo/yobosesshu/vaccine/... [yokohama.lg.jp]
集団接種は5月17日から開始だそうで、市内全域で集団接種できるのは6月以降みたいですね。
順番は
1.医療従事者
2.高齢者、80歳以上、65歳以上 -5/17,6月から
3.基礎疾患持ち -夏?
4.その他の人 -秋以降(冬)?
2回目3回目の予定はあるのかな。
Re: (スコア:0)
繋がらないからってリロードしまくりだと思うけど、タイミングに合わせてDoS攻撃したバカがいる可能性も多少はあるかもね。
それでもアクセス過多で遅延や接続不能は兎も角、システムダウンしちゃうのはダメだと思うけど。
Re:なんかアクセスが多くないか? (スコア:1)
一人が申し込むのにhtmlファイル1個だけを表示して終わりってわけじゃないからな
Re:なんかアクセスが多くないか? (スコア:4, すばらしい洞察)
1ページで申し込みまで完結する通販サイトを見習って欲しい。
Re:なんかアクセスが多くないか? (スコア:1)
・ベンダー:「100万アクセス(HTTPリクエスト)/分まではOKですからね」
・役所側:「100万人/分までOKなんだね、よし大丈夫だね」
もしかしから、こんなことが原因かなって思っちゃうね。
1ページにCSSやJSや画像で10ファイルのリスクエストが来るとれば(勝手な数値ですが)
10万人のアクセス/分が限界だったりして。
もしくは、サーバは十分な負荷に耐えられても、回線帯域や、スイッチ等のネットワーク機器がボトルネックになってて...
なんてことがあるかも。
Re:なんかアクセスが多くないか? (スコア:3, 興味深い)
この手の話のボトルネックは結構な割合で「予算」
超過できないし、余らせてもいけないから、クラウドで動的スケーリングして、みたいな選択肢が潰される
Re:なんかアクセスが多くないか? (スコア:1)
> この手の話のボトルネックは結構な割合で「予算」
だから、誰(頭の固い上司)にでも判る事を起こして、予算を確保するのですね!
Re:なんかアクセスが多くないか? (スコア:1)
内閣官房・総務省より「第二期政府共通プラットフォームにおけるクラウドサービス調達とその契約に係る報告書」が発表されました | Amazon Web Services ブログ [amazon.com]でもまとめられているけど、
つまり自分で何とかしろ、だからね。
他にも、複数の自治体の寄り合いクラウドでリソースを融通することはやっているけれど、ワクチン接種予約を全国一斉に始めるとなると結局は一極集中でパンクする可能性が高い。
Re:なんかアクセスが多くないか? (スコア:1)
先着でも落ちてたかもよ。
IIJ mioが5月1日から適用になる新プランを4月1日からプラン変更できるようにしたけど、急ぐ必要はまったくないにも関わらず、4月1日から数日は高負荷で申し込めなくなってたし。
Re:なんかアクセスが多くないか? (スコア:1)
アクセスして何も表示なかったら1分も待たずにリロードなりするだろ。
表示されても1ページ1分ってわけでもないだろ。
本当に考えてたのは何人からのアクセスを考えていたのか
Re:なんかアクセスが多くないか? (スコア:2)
Re: (スコア:0)
これもあるね。表示遅かったら5秒でも待たずにページ更新するんじゃない。
Re:なんかアクセスが多くないか? (スコア:2)
昔は、8秒ルールと言うのがあって・・・
そもそもなぜコロナワクチン接種を「予約」しなければならないのか (スコア:0)
個人や家庭ごとに交通手段が異なるから行ける接種会場に限りがあり
都合の良いところを選べと言う話なのだろうか。
個人や家庭ごとに交通手段を確保している勤務先や就学先があるからそこに集約させればいいように思うけど
インフルエンザ予防接種では勤務先や就学先ごとの接種があるのでそれでいいのでは?
Re:そもそもなぜコロナワクチン接種を「予約」しなければならないのか (スコア:3, すばらしい洞察)
「会場に直接行け」って言ったら、そこで三密作ってクラスタが発生するからだよ。
事前に予約をとって日時と会場を、計画的にばらけさせる必要がある。
今は発熱外来も予約とれって言われるそうだね。さもありなん。
Re: (スコア:0)
インフルエンザワクチンより取り扱いが難しい(温度条件等)
例年のインフルエンザワクチンほど供給が追いついていない(順次追加される)
最終的な接種の必要数は例年のインフルエンザワクチンより多い
条件が違いすぎて同一視は無理。
Re: (スコア:0)
他者よりも早く、1日でも早くという人がそこそこの数いるのでしょうね。
行政側が整理して決めると、どこが早かった遅かったと揉めそう。
だからそういう行政の手間は放棄して、完全早い者勝ちにしたと。
面倒な人と優先順位で揉めるより、予約殺到で大変ですと不満のはけ口にしておけばいい。
少し経った後なら、行政側で接種場所や順番決めても、そういう面倒な人は既に終わってるので平和そう。
#後半は個人の妄想ですよ
Re:そもそもなぜコロナワクチン接種を「予約」しなければならないのか (スコア:4, 興味深い)
役人AC
どこが早かった遅かったと揉めそう。だからそういう行政の手間は放棄して、完全早い者勝ちにしたと。
よくある役所の方策
合理的解決策よりも、いかに文句を言われないかの方策を採る
だがしかし、
予約殺到で大変ですと不満のはけ口にしておけばいい。
このコストは払いたくない。
承認欲求の強い義憤に駆られた高齢者が、数人/日くらい電話を掛けてくると、役人の人件費がそれに食われてしまう。
Re:一方京都市は (スコア:2, 興味深い)
>設定値以上のアクセス(tcpコネクション数)を超えるとサーバーにアクセスせずに、設定したhttpエラーレスポンス(503とか)を骨髄反射で返してくれた
LBで閾値以上のアクセスをはじいている環境の大半が適当なGETのクエリ付けるとはじかずリクエストが通ってしまうという・・・
直近て有名どころだとSHARPのマスクの初日もURL開くときに適当なクエリ付けて、フォームをPOSTするURLもChromeの開発者ツールでHTML書き替えれると手前で弾いてくれてる分なんの問題も無くアクセスできましたとさ・・・
Re:簡単にスケールさせたいならAWS使え (スコア:2, 興味深い)
余裕でいける。
ただし、ちゃんとロードバランサを設定しておくことと、
後ろに控えるDBをShardingなりなんなりで負荷分散するようにしておけば。
DynamoDBとかをうまく使えばさらにスケールできる。
静的なコンテンツをS3 + CloudFrontの組み合わせで送るようにしておくと申し分ない。
Re:簡単にスケールさせたいならAWS使え (スコア:2, すばらしい洞察)
それをきちんと設計できる人間ならAWSじゃなくても作れる
出来ない人はAWS使ってもダメ
Re:簡単にスケールさせたいならAWS使え (スコア:1)
ま。御説ご尤もだが、AWSに限らずクラウド系プラットフォームはリソースの柔軟な調達がキモなわけで。
#別のコメントツリーにも書いてあったけど「予算は使い切れ。超過も余らせるのもよろしくない」が一番厄介ね。
Re:簡単にスケールさせたいならAWS使え (スコア:1)
3万 req/sをサーバーレス(SPA+API)でやろうとすると、デフォルトではクォータに引っかかりそうなので、事前の申請はいくらか必要な気もする。
といっても3万 PV/sなので、登録で呼び出されるAPIの方が3000 req/sとかなら余裕かもしれない。
- 静的コンテンツの配信用のCloudFrontは余裕の25万 req/s
- API Gatewayが10000 req/s
- AWS Lambdaが1000 並列
- DynamoDBが40000 WCU(1 KB/req) (ただし、On-Demandでは初期スループット4000 WCU)
即応性が必要なわけではないので、さばき切ろうとせず適宜フロントエンドで待たせればいいし(API Gatewayでスロットリングしちゃう)、ユーザーフレンドリーに順番待ちさせたければElastiCache(Redis)とかSQS、Kinesisあたりを組み合わせることになるだろうか。
Re:簡単にスケールさせたいならAWS使え (スコア:1)
東京リージョンに置けばいいだけの話をなぜ誰も突っ込まないんだ?
すでに政府共通PFでもAWSが採用されてるし、ISMAP準拠リストにも含まれているんだが
IPA、政府の調達に適したクラウドサービスのリストを公開
https://it.srad.jp/story/21/03/16/1620220/ [it.srad.jp]
Re:65歳以上全員に接種券を配るのが悪い (スコア:3, 参考になる)
いや、一応横浜市は接種券の発送日を、
80歳以上(約34万人):4月23日
75〜79歳(約19万人):4月30日
70〜74歳(約25万人):5月10日
65〜69歳(約19万人):5月14日
という具合に、分けてたのよ。
https://www.city.yokohama.lg.jp/kurashi/kenko-iryo/yobosesshu/vaccine/... [yokohama.lg.jp]
だけど、受付開始したら200万アクセス/分も来ちゃったと、、、
Re: (スコア:1)
知人とこがそうだが、いきなり本番(高齢者施設)に飛ばさず、デプロイテストしてる感ある。