新型コロナワクチンの予約システムが軒並みボロボロだ。
東京都はKintoneにフォームをかぶせた仕組みを使って完全にアクセスが停止しただけじゃなくて、どうもセッションが奪われるという嘘みたいなニュースも流れてきた（真偽は不明）。
他の小規模な自治体（市区町村）は、両備システムズのSaaSっぽい仕組みでやってるが、プライバシーポリシーもないし、あったとしても情報を自治体に預けているのが両備システムズかが分からない。
いずれにしてもコンシューマー向けWebを作った経験がないSIerがやるからそんなことになる。
じゃぁってことで私も構成を考えてみる。
そもそも一気にアクセスさせるの？
一気にアクセスさせたとしても、予約の書き込みがどうしてもボトルネックになりそう。時間帯を分散させてやるしかない。台湾なみにマイナンバーが使えたなら、マイナンバーの下○桁の人は○時から予約してくださいという案内は可能。それだと不公平かもしれないけど、マイナンバー発番時点でそこは公平に分散してる。
予約直前まで極力フロントエンドJSのみでバリデーション
CDN使っていれば、HTMLとJSはオリジンサーバーの負荷なく配信できる。最後の予約の投稿だけDBにアクセスさせればいい。「残予約数」みたいなものを集計するクエリを画面からはリクエストしない。別プロセスが各施設の予約可／不可のスイッチをON/OFFし、できるだけ静的コンテンツにする。画面単位で柔軟にキャッシュをコントロールするなら、ちょっとお値段は高いかもしれないけど、Fastlyみたいな高機能なCDNがいい。
非同期処理という手もある
書き込みでさえも、S3にJSONをポストさせるだけにしちゃう。DBアクセスはしない。その代わり在庫をリアルタイムに反映はできない。がーっと予約を受け付けるだけ受け付けて「後ほどメールで返信します」にしちゃう。受付サーバーが落ちる心配はないし、DBにアクセスするプロセスも限られる。DBのスペックを上げてからバッチ処理をしてもいい。不便だけどそもそも「限られた接種機会を奪い合う」という状態で不便なんだから諦めていい。「ちゃんとあきらめてもらう」というのが正しいUX。
技術面ではFirebaseみたいなのが正解
データの書き込み含めえてNoSQLでスケールしてくれるサーバーレスアーキテクチャがこの手のヤツでは正解のはず。ただ、国民の個人情報を預かるのが、自治体＞ベンダー＞Googleと階層が深い。どこのデータセンターに個人情報を置いてるかなんて全然答えられない。Googleに送ればチェックシート埋めてくれるの？なさそー。「スケール」という観点ではPaaSは便利なんだけど、「責任の所在」がさっぱり分からない。
とはいえこの手のBaaSはめちゃくちゃ作りがこなれてる。ゲームのバックエンドとかにも使われるレベルなのでバックエンドとしては申し分ない。Firebase自体のお作法を覚え直さないといけないけど、変にフルスクラッチでやられるよりもずっと「ふつうのインターネットサービス」ができる。Firebaseでできる範囲でのみサービス提供するべき。
ただ、本当に心残りなのは、この手のBaaSって定期的に仕様が変わる。継続して使いたいときには、どの程度保守工数が発生するかが読めない。少々お金積んでもGoogleがバージョンアップを止めてくれたりはしない。
まとめ
- 許されるならBaaS使う
- 自前でやるなら、極力DBアクセスしない作りにする
