承認画面には、動画をその場で作り直すボタンを付けてあった。ある日、それを押すと、しばらく待たされた末にエラー画面が出た。時間切れ、という素っ気ない表示。何度押しても同じだった。
奇妙だったのは、夜中の自動実行では、同じ動画作りが毎回成功していたことだ。同じ処理が、夜は通り、昼のボタンからは落ちる。
測ってみたら、二つの限界を超えていた
推測で直すのをやめて、サーバで実際に測った。動画一本の生成には約二分かかっていた。さらに、作業中に使う記憶領域は、この仕組みに割り当てた上限を大きく超えていた。時間と記憶。二つの数字が、それぞれ別の限界に触れていた。
一つめの限界は、画面の入口だ。入口に立つ中継役は、六十秒返事がないと時間切れにする決まりで動いている。二分かかる処理は、必ず途中で切られる。二つめの限界は、記憶領域の上限。ボタン経由の処理は、この仕組みに割り当てた枠の中で動くため、上限に当たったところで止められる。
夜は通って、昼だけ落ちた理由
では、なぜ夜中の自動実行は毎回成功していたのか。答えは、通り道だった。夜の実行は画面を経由せず、割り当ての枠とも別の場所で動く。だから六十秒の壁にも、記憶領域の上限にも、そもそも触れない。
同じ処理でも、通る道が違えば、かかる制約が違う。動くか動かないかは、処理の中身だけでは決まらない。どこを通って、誰に呼ばれたか、まで含めて初めて決まる。この当たり前のことに、実測してようやく気づいた。
受付だけ済ませて、すぐ帰す
直し方は、処理を速くすることではない。二分かかるものは二分かかる。変えるべきは、待たせ方だった。
ボタンが押されたら、生成の依頼だけを受け付けて、画面には即座に戻る。生成そのものは、画面とは切り離した別の流れで、裏で進める。画面には生成中の帯を出し、しばらくごとに自動で更新して、出来上がったら一覧に現れる。押した人は待たされず、時間切れも起きない。
あわせて、記憶領域の割り当ても実測に合わせて広げた。上限は守りの要だが、実態より狭い上限は、守りではなく、ただの自傷になる。
検証は、本番と同じ道を通す
反省が一つある。この仕組み、手元の環境では動画の生成まで確かめてあった。ただし手元には、画面の入口に立つ中継役がいない。六十秒の壁は、本番の道にしか存在しなかった。
手元で動いた、は、本番の道を通ったことの証明にならない。入口から出口まで、本番と同じ経路で一度は通す。この一件以来、それを検証の決まりにしている。
最終回は、投稿した後の話。届いた数と反応の数字を自動で集めて、次の投稿に返す仕組みについて書く。