管理画面のログインは、あっさり動いていた。パスワードを入れると入れて、しばらく操作でき、時間が経つと切れる。試したときは、何の問題もなかった。
処理を少し速くしようと、サーバーの働き手を一つから二つに増やした。その直後から、ログインが不安定になった。入れるときもあれば、入った直後に弾かれるときもある。同じ操作なのに、結果が揺れた。
入れたのに、弾かれる
再現の仕方が、つかみにくかった。
ログインは成功する。なのに、次の操作で「認証されていません」と返る。もう一度やると、今度は通る。まるで気まぐれだ。パスワードは合っている。時間も切れていない。それでも、二回に一回くらいの割合で、弾かれた。
一つの働き手で動かしていたときは、一度も起きなかった。増やした瞬間から始まった。だとしたら、原因は「増やしたこと」の中にある。
ログインの記録が、片方にしかなかった
犯人は、ログインの記録を置いた場所だった。
はじめ、誰がログイン中かという情報を、サーバープロセスのメモリの中に持っていた。働き手が一つのときは、それでよかった。ログインも、その後の操作も、同じプロセスが受けるからだ。
ところが、働き手を二つにすると、ログインを受けた働き手と、次の操作を受ける働き手が、別々になることがある。二つ目の働き手は、一つ目がついさっき記録したログインを知らない。だから「そんな人は知らない」と弾く。記録が、片方のメモリの中だけに閉じていた。
記録を持たずに、確かめられるようにする
直し方は、記録を持たないことだった。
ログインが成功したら、その事実を、署名つきの通行証に変えて相手に渡す。以降の操作では、その通行証を見せてもらう。署名が正しいかどうかは、どの働き手でも、その場で確かめられる。誰がログイン中かをメモリに覚えておく必要が、なくなる。
覚えておくのをやめ、渡した通行証を検証する方式に変えた。これで、どの働き手に当たっても、同じ答えになった。ログインの揺れは、止まった。
状態を抱えると、身動きが取れない
この一件で、はっきり分かったことがある。プロセスの中に状態を抱えると、そのプロセスは増やせない。
働き手を増やしたい。別の場所へ移したい。落ちても差し替えたい。そういう当たり前の身軽さは、「そのプロセスにしかない情報」があると、途端に失われる。増やした瞬間に、抱えていた状態が牙をむく。
だから今は、プロセスの中に大事な状態を置かない、を先に考えるようになった。記録は外に出すか、そもそも持たずに検証で済ませる。小さく作ることと、状態を抱えないこと。この二つは、あとで身軽でいるための、同じ準備だった。
次の回は、この媒体に、AIをいくつ渡したかを書く。