自動で台数が増える環境で、何に気をつけますか

立ち上がりの遅れと費用

台数がゼロや少ない状態で要求が来ると、新しい台を立ち上げる間だけ待たせます。最小の台数 (最小インスタンス数) を決めておくと、この遅れを減らせます。Google Cloud の Cloud Run の説明でも、最小インスタンス数でコールドスタートを減らせ、そのインスタンスは使っていなくても料金がかかる、とされています。AWS では ECS の最小のタスク数や、Lambda であらかじめ温めておく設定が近い役です。

夜はほとんど使われないサービスなら最小をゼロにして費用を抑え、朝の最初の数人だけ少し待たせる、という選び方もあります。利用者を待たせて困る画面かどうかで決めます。

台数と接続数の掛け算

アプリの台数が増えると、それぞれが DB に接続を張ります。DB が受けられる接続の数には上限があるので、台数が増えた瞬間に DB があふれることがあります。数字は架空の例です。

最大の台数               20 台
1 台が持つ接続の数       10 本 (コネクションプール)
合計                    200 本

DB が受けられる数        100 本  -> あふれる

手当ては、最大の台数に上限を付ける、1 台のコネクションプール (接続を使い回すための溜め) を小さくする、間に接続をまとめる中継を置く、のどれかです。1 台が同時に受ける要求の数 (同時実行数) も、この計算に効きます。多くすると台数は少なく済みますが、1 台のメモリや CPU が足りなくなります。

手元に状態を持たない (トレードオフ)

台数は増えるだけでなく、要らなくなると消えます。手元のディスクに上がったファイルや、メモリに持ったログインの状態は、その台と一緒に消えます。次の要求が別の台に来れば、見つかりません。だから、ファイルはオブジェクトストレージに、セッションは DB やキャッシュに出します。

外に出すと、そのぶん置き場への通信が増え、少し遅くなります。それでも、どの台でも同じに動くことのほうが、台数を増やして耐える仕組みには大事です。1 台を大きくして耐える (縦に伸ばす) 方法もありますが、上限があり、その 1 台が落ちると全部止まります。

話すときは、自分が関わったサービスで、最小と最大の台数をいくつにし、何を見て決めたかの例を 1 つ用意します。