サーバー増強ゼロで負荷を100分の1にした話【後編】

前編では、センター試験合否判定システムの負荷問題を、サーバー増強なしで解決した話を書いた。後編では、その裏側と20年後への影響について語る。35年以上コードを書いてきた人間の、エンジニアリングをめぐる小さな備忘録だ。

そして、40度の熱

その翌年、私は40度の熱を出して寝込んでいた。

クライアントからの電話。「お大事に」の一言はなく、「システムは大丈夫ですか？」とだけ。

20年前、リモートワークなんて言葉もない時代。それでも、解熱剤を飲み、ベッドの中でノートPCを開いた。オフィスとSkypeで接続し、学生スタッフからの報告や指示要請に答えながら、VPN経由でサーバーに接続して状況を監視した。

冷たいと思うだろうか。でも、向こうも休みなしで働いている。センター試験直後の塾は戦場だ。保護者からの問い合わせが殺到し、職員全員が不眠不休。お互い、限界状態での戦いだった。

「サーバーを買えば解決する」

これは半分正解で、半分間違いだ。確かに一時的には解決する。でも、来年は？再来年は？生徒数が増えたら？

正直に「分かりません」と答えたことで、別の道を探すしかなくなった。

制約が創造性を生む とはこのことだ。

さて、ここでネタばらしをしよう。タイトルは釣りだ。

正確に言えば：

何をしたか？

判定処理中に、登録した全大学の結果をメールで送信した。

たったそれだけ。

23時から1時までの判定処理中、DBから結果を取り出しながら、順次メールを送信。受験生は午前1時を待たずに、メールで全ての判定結果を受け取れる。

ルールベースエンジンが複雑な配点方式で計算した結果 - 「英語と国語の高い方で計算したA判定」「数学400点換算でのB判定」- が、全てメールに記載される。

結果：

枯れた技術「メール」で、スケーラビリティ問題を回避した。もちろんメール送信にも限界はある。SMTPのスループット、配信失敗のリトライ、宛先誤り — このあたりは別途設計が必要だった。だが、午前1時のDB集中アクセスという「即死級」の問題を回避するには、十分に枯れていて、十分に堅牢だった。

もしあの時「大丈夫です！サーバー買えば完璧です！」と嘘をついていたら、この解決策は生まれなかった。

正直であることが、最高の解決策を生んだ。

サーバーの性能を100倍にする方法？簡単だ。 そもそもアクセスさせなければいい。

これが、私が現場で学んだエンジニアリングの一面だ。

だから、サーバーのスケーリングとか処理能力の見積もりは、私にはトラウマだ。

Azureが出たとき、Microsoftは「クラウドがそれを解決してくれる」と喧伝していた。期待した。だが、結局は何台のVMが必要で、どのスペックで、ピーク時にはいくつまでスケールして…という見積もり地獄は変わらなかった。

その後、コンテナ技術やオーケストレーションが実装された。 Dockerはまだいい。でも、Kubernetesを使うことには、どうしても心理的抵抗があった。

「またAzureのときみたいに、期待だけして見積もり地獄が形を変えるだけじゃないのか」

ノードは何台必要？ポッドのリソース制限は？HPA（Horizontal Pod Autoscaler）の閾値は？結局、見積もり地獄は形を変えただけじゃないか。

この問題を本当に解決したのは、サーバーレスだった。

アクセスが来たら勝手にスケール。来なければゼロ。見積もり不要。考えなくていい。ノードもポッドも知らなくていい。

だから、今ではCloudflareが大好きだ。 20年前のトラウマから、ようやく解放された。

追記：あの時、「サーバーを買えない」という制約が、「アクセスさせない」という逆転の発想を生んだ。今思えば、それが今のサーバーレス愛につながっている。制約は時に、最高の教師となる。

そして、技術の進化を素直に信じられなくなった自分がいる。「これで解決！」と言われても、「本当に？」と疑ってしまう。それもまた、20年の経験がもたらした「財産」なのかもしれない。