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

はじめに：釣られた皆様へ

最新のチューニング技術や、革新的なアルゴリズムを期待してクリックした方、申し訳ない。この記事にそんな高尚な話は出てこない。

でも、もしかしたら、もっと大切なことを持ち帰ってもらえるかもしれない。35年以上コードを書いてきた人間の、20年前のあるシステム開発の話だ。

地獄の初年度 - センター試験直後の戦場

20年前、某大手塾のセンター試験合否判定システムを学生チームと開発していた。

システムの流れ

受験生は複数の大学・学部を最初から登録できた。東大理Ⅰ、京大工学部、早稲田理工…第一志望から滑り止めまで、一度に判定を受けられる仕組みだ。

初年度、地獄を見た。

午前1時の公開と同時に、数万人が一斉にアクセス。タワーサーバー1台が見事に轟沈。

アクセスログを見ると、ピークは公開後2〜3時間続いていた。だが、これは見かけの数字だ。 本当はもっと鋭いピークだったはずが、サーバーがさばききれずに平坦化されただけ。 実際は、午前1時の瞬間に全員が殺到していたのだ。

正直者がバカを見る？

翌年に向けての対策会議。

我々には500万円のF5ロードバランサーがあった。これを貸し出すことは可能だ。あとはWebサーバーを数台買ってもらえれば…

クライアント：「それで絶対に解決するのか？」

私：「とりあえずは解決します。でも、2〜3年後に生徒数が10万人を超えたら、また同じ問題が…」

クライアント：「じゃあ、サーバー代は出せない」

正直に答えすぎた。でも嘘はつけない。 ボトルネックはDBだ。 Webサーバーを10台に増やしても、全てのリクエストは結局1台のDBに集中する。根本解決にはならない。

500万円のロードバランサーは、結局うちの倉庫で眠ったままだった。

発見した事実

真のピークの鋭さを理解して、改めて分析した。

• 午前1時の瞬間、数万人が「同時に」DBに問い合わせ
• 一人あたり平均5〜6大学を登録
• つまり、数十万クエリが「1秒間」に集中していた可能性
• DBが即死するのは当然

そして、もう一つ重要な事実。皆、 最初の結果確認 のためだけに殺到していた。

実装した解決策

具体的な手法は後編で詳述する。ここで言えるのは、ある方法を実装したということだけだ。コストはゼロ。既存のリソースだけを使った。

改善後のシステムフロー（ネタバレ注意）

結果 - CPU使用率10%以下に収まった

翌年の結果発表日。同じタワーサーバー1台。同じDB。サーバー追加ゼロ。

午前1時、Web公開。去年なら、DBが落ちる時間だ。

しかし…ピーク時でもCPU使用率は10%を超えなかった。DBへのクエリは激減。アクセスしてくるのは、自己採点を見直したい人や志望校を再検討したい人だけ。余裕を持ってシステムを使えた。

このシステムには、もう一つの強みがあった。それまで他社製品にはなかった 複雑な配点方式 への対応だ。

他社のシステムは、DBに配点（英語200点、数学100点…）しか入れていなかった。しかし、実際の大学入試はそんな単純ではない。

• 「英語と国語のうち、高い方の得点を採用」
• 「数学だけ400点換算」

こういった複雑な条件に対応するため、私は 「配点」＋「ルール」 という新しいアプローチを考案した。

DBには配点だけでなく、判定ルールも格納する。Prologのような論理型プログラミングの考え方をヒントに、ルールベースの判定エンジンを実装した。これにより、どんな複雑な配点方式にも柔軟に対応できるようになった。

20年前、これは革新的だった。数年後には他社も似たような仕組みを実装し始めたが。

次回【後編】では、この解決策の真相 — そして実は「100分の1」というタイトルにも仕掛けがあったことを明かす。20年後の今につながる教訓と合わせて語る。