CODE IN TOKYO

放課後16時、サーバーが一気に唸り出す —— 「重い解析モジュール」と余力設計の話

学校向けサービスをやっていると、アクセスの波が本当に極端だ。

特に放課後。 チャイムが鳴った直後、秒単位でアクセスが跳ね上がる。

普段は静かなのに、16時を超えた瞬間に一気に人が流れ込む。 イベント開始直後なんかも同じで、アクセスグラフがほぼ垂直になる。

昔ながらのWebシステムなら、「ちょっと重いね」で済んだかもしれない。 でも、今回扱っていたのは少し特殊だった。

裏で動いていたのは、AIを使ったデータ解析モジュール。 しかも、Dockerコンテナとして動かす前提の、かなり重い構成だった。

「Auto Scalingで増やせばいい」が間に合わない

最初は普通にAWSのAuto Scalingを使っていた。

負荷が増えたらインスタンスを増やす。 クラウドでは定番のやり方だ。

ただ、現実はそんなに綺麗じゃなかった。

この解析モジュール、起動が重い。

Dockerコンテナを立ち上げ、内部ライブラリを初期化し、解析用データをロードし、ようやく処理可能状態になる。

数秒では終わらない。

ロードバランサーが負荷を検知し、「インスタンス増やします」と動き始めた頃には、もうアクセスのピークが来ている。

つまり、

“増えた頃には遅い”

のである。

Lambdaも試した

もちろんLambda構成も検討した。

ただ、結論から言うと厳しかった。

理由は単純で、このモジュールが「サーバーレス向き」ではなかったから。

軽量なAPIならLambdaは本当に美しい。 でも、重い解析処理を抱えた瞬間、思想が噛み合わなくなる。

特にリアルタイム性が必要な場合、「コールドスタート待ち」はかなり厳しい。

結局、常駐型の構成に戻ってきた。

最後はかなり泥臭い結論になった

色々試した結果、最終的な結論はシンプルだった。

「ピーク前に、余裕を持ってサーバーを立てておく」

これ。

放課後にアクセスが集中するなら、15:30くらいには全部起動済みにしておく。

解析モジュールもロード済み。 いつでも処理可能状態。

要するに「予熱」である。

しかも面白いのが、16時を過ぎてアクセスが少し落ち着いた後も、すぐには台数を減らさなかったことだ。

学校系のアクセスは読みにくい。 部活後なのか、塾前なのか、イベントなのか、急にまた波が来る。

だから、多少無駄でも、しばらくは余剰サーバーを起動したまま維持する。

17時、18時と時間が進むにつれて、ようやく徐々に台数を減らしていく。

もちろん手動ではない、スケジュールを作るのだが、夏休みとかまで対応できないので、 平日はこの時間帯は何台。。。で決め打ち。

クラウド的には非効率に見えるかもしれない。 でも現場感覚としては、

「落とす判断を急ぐ方が危険」

だった。

「そんなに常時動かしてコスト大丈夫なの？」問題

当然、言われる。

「普段そんなにアクセスないのに、なんでこんなにサーバー動かしてるの？」

これは本当にその通り。

ただ、サービスが止まった時の損失の方が大きかった。

特に学校系は、利用タイミングが集中する。 そこで待たせると、一気にクレームになる。

なので結局、

みたいな形に落ち着いた。深夜でも万が一のため複数インスタンス起動しておく。

クラウドって、「必要な時だけ使う」が理想として語られる。

でも現場では、

「必要になる前に準備しておく」

さらに、

「ピークを過ぎても、しばらく余力を残しておく」

方が正解になることがある。負け惜しみではない！

あとがき

エンジニアとしては、全部自動で綺麗に伸縮する構成に憧れる。

でも現場は、案外そうならない。

特に「重いもの」を扱い始めると、最後はかなり物理戦になる。

余裕を持ってサーバーを積む。 先回りして起動しておく。 ピーク後もしばらくは余力を残す。

気付けば毎日15:30、AWSコンソールを開いて点呼を取っている。

「EC2-01、起動よし」 「EC2-02、起動よし」 「解析モジュール、ロード完了……」

最新のクラウド技術を駆使した結果、私は学校のチャイムに合わせて働く担任の先生になっていた。

進化って、何だっけ。