こんにちは。株式会社X-Tech5 取締役CTOです。
先日株式会社Topotalと共同で、 新型コロナウィルス感染症のワクチン接種予約システムのアクセス集中の、不具合の調査支援及び改善提案を無償提供するプレスリリースをしました。
新型コロナウィルス感染症のワクチン接種予約システムのアクセス集中による不具合の多発を踏まえ、不具合の調査支援及び改善提案を無償提供
このエントリでは、実際に行った負荷対策の要点を公開し共有します （というわけで、宣伝半分・事例紹介半分です）。
この考え方・やりかたが正しいのだ、という意図はありません。
新型コロナウィルス感染症のワクチン接種予約システム（以下接種予約システム）のアクセス集中対策の参考にしていただき、世の中から接種予約システムの負荷トラブルが減ると嬉しいです。
ポイント1：価値基準の確定・すりあわせ
まずは関係者で価値基準を確認し合意します。
接種予約システムは、わたしが普段携わる多くの業務システムともWebサービスとも異なる前提条件を持っているので、それらを踏まえて価値基準を見直す必要があると考えました。
基本的な前提条件
- 「販売」ではない
- 多くのチケットや物品の販売とは異なり「売上最大化」が目的ではない
→スループット最大化よりも、システム利用者が安心して待てて、時間がかかっても処理できるほうが重要
考慮事項
- 多くのWebサービスと比較するとシステム利用者のターゲットがとても広い
→マーケティングによるターゲッティングがほとんど行われない（行えない）ため、幅広いバックグラウンドのシステム利用者が想定される
（ただし電話など複数の予約手段があるため、手段選択により多少の傾向はあると思われる）
→家族総出の申し込み代理操作がありえるため、接種対象者数を越えるシステム利用者数が想定される
（可能性があり、実際にアクセス数を見るとそのように感じられる）
補足
- システムの役割はコンテンツ配信ではなく、広告システムよりはECやチケット販売に近い考え方が必要
- 具体的には接種会場・時間帯ごとの在庫管理（残枠数管理）が必要
- 多くのECやチケット販売と比較して、システム利用者数に対して接種会場・時間帯ごとの枠が小さい
- （物品の販売とは異なり）在庫は増えない
- 物品販売では、増産等により在庫を増やす調整が可能なことがある
- 一部のチケットや物品の販売とは異なり、在庫枠バッファを持っておくことはできない
- 使い切るベースの考え方
→在庫管理を緩くしてスループットを上げ、後でつじつまを合わせる手法が使いづらい
（仮発注しキャンセルで適宜調整や、見込み受注は厳しい）
以上をもとに、ポイント2以降の判断・行動を行っていきました。
ポイント2：アーキテクチャ観点の重要事項
わたしたちの判断は、以下の優先順位でした。
- 流速制御が一番大事
- とにかく落ち着いて待ってもらう
- 流速制御したうえでシステムのキャパシティ・スループットをあげる
- 結果として現実的な待ち時間に収まるようにしたい
主な判断理由
- 前提条件を考慮すると、全ての利用要求をエラーなく処理するシステムを、短期間で用意することは不可能
- 先着順なのは予約枠であり、ワクチン自体は強い先着順ではない
- 実際、当日昼過ぎには待ちがほぼなくなったが、当日中にすべての予約枠が埋まることはなかった
- 今回は高齢者対象であり、（他の年代と比較して）日程調整の融通が効きやすいことが想定されたため、予約枠のピンポイント指定のニーズが低いと想定した
ポイント3：遂行観点の重要事項
とにかく対策時間がありません。
「早期決断」が一番大事でした。
決断の根拠は必要ですが、データを集めて積み上げて慎重に判断しては間に合わないケースがあります（ありました）。
今回は、手続きより結果、強固な論理的根拠より荒い論理的根拠と早期決断、コスパよりプログレスが重要と判断しました。
時間的制約が強かったので「今判断すればできるが、1日後ではできない」ことがほとんどです。
いま判断することが結果に資するなら、いま判断するのがシステムに関わるエンジニアの責務と考えました。
遂行の優先順位をつけ、ラインを引くことで、関係者を落ち着け着実に対策を進められる効果もありました。
わたしたちの判断
- まず流速制限
- これは絶対
- Cloudflare Waiting Roomを導入しました
- Classmethodさんに多大なご協力をいただきました
- Project Fair ShotによりWaiting Roomは無償提供いただきました
- とはいえ結果的に他の機能も組み合わせて使うことになるので有償契約しました
- Cloudflareは高くないので、いいプランにしておくとよいです
- AWSへのシステム移設
- 大きなシステムの一部機能を流用して作られていたため、該当部分をAWSへ移設
- もともとのシステム基盤は国内大手SIのクラウドサービスだったが、キャパシティ・アジリティともに不足
- 「わたしたちも、開発チームも、全力を尽くせる」「全力を尽くすことが結果に資する」と判断し移設決定
- 開発チームが3日程度で移設完了（ただし徹夜含むとのこと。お疲れさまでした。ありがとうございました）
実際のサイジング
AWSのキャパシティ・アジリティを生かした力技スケールアウトでした。
- Cloudflare
- ALB
- EC2：m6g.xlarge ×64
- Aurora Serverless：256 ACU
AWSで接種予約システムに必要なレベルまでキャパシティをあげるためには、Quotaの引き上げが必要です。
Quotaの引き上げは、程度によって時間がかかる・負荷テストの結果提出が必要なことがあり、融通が効かないことがあるので、とにかくシステム利用者のためには流速制限が一番大事です。
インスタンス数、CPU数のQuota引き上げが必要でした。十分な負荷テストが実施できたとは言い難いこともあり、最初は流速制限を厳しくし、徐々に緩和。
その他
Tipsです。
- ユーザリアクション確認のためにTwitterをみるとよいでしょう
- 「○○市 コロナ」「○○市 ワクチン」等で検索しました
- 心無い人・口が悪い人はいるので、事実だけを見て、ミュートorブロックするとよいでしょう
- HRMの文脈で、口が悪い人に触れると、触れた人全員のパフォーマンスが落ちるそうです。体験的には的を射ていると思います
- チームの雰囲気が悪くなったらオシマイ
- えらいひとも、ふつうのひとも、どの担当も、事実だろうが事実でなかろうが、的を射ていようがいまいが、チームの雰囲気を悪くしてはいけません
- HRMの文脈で、口が悪い人に触れると、触れた人全員のパフォーマンスが落ちるそうです。体験的には的を射ていると思います
ざっと主要な点を紹介しました。
接種予約システムを運用する自治体、開発会社、運用会社のみなさまへ
接種予約システムの負荷対策でお困りで、わたしたちがお手伝いできそうなケースがあれば、以下からお問い合わせください！
今回紹介した取り組みのうち、最初のざっくりとした調査支援と改善提案を無償提供いたします。 その後に一緒に対策をやっていく場合、そちらは有償対応になります。 見通しがたてば実施は自分たちでできる、という場合もぜひご相談ください。
新型コロナウィルス感染症のワクチン接種予約システムのアクセス集中による不具合の多発を踏まえ、不具合の調査支援及び改善提案を無償提供
ではでは。