大きくするか増やすか

大きくするか、台数を増やすか

席の予約サービスで1台の上限を超えそうになったら、増やし方を選びます。1台のCPUやメモリを増やすのが垂直、同じ役割の台数を増やすのが水平です。

垂直なら、要求を受けるアプリは1台のままです。いまの構成を保ちやすい一方、保存先の遅さが原因ならアプリを大きくしても解決しません。

水平なら要求を分けて処理できます。ただし、各台が同じ保存先に集中している場合、アプリの台数に比例して処理量が増えるとは限りません。

水平にすると、要求の振り分けとログイン情報の置き場所を決める必要があります。監視する台も増え、振り分けや共有の保存先が止まる場合も考えます。

処理量だけが不足し、垂直で足りるなら、まず少ない変更で解決する案を比べます。1台の故障でも続けるという要件があれば、処理量とは別に複数台を検討します。

垂直には天井がある

提供元が用意する最大のCPUやメモリにも上限があります。大きい台へ替え続けられる前提で、将来の構成を決めることはできません。

候補の台に予約要求を流し、目標の応答時間を保てる処理量を測ります。まだ試せないなら性能を仮置きし、測り直す条件も記録します。

判断の順番は、現状で足りるか、垂直で足りるか、それでも足りないかです。どの段階でも費用と故障時の要件を照合し、性能だけで案を決めません。

切り替え時の停止時間も確認します。1台を大きくする作業で予約を受けられない時間があるなら、公演の発売時刻を避けるなど、実施する条件を案に添えます。

予約サービスで解いてみる

DAU3万人が1日に6回要求する規模を考えます。平均を約2 QPSと丸め、ピーク係数50で100 QPSと置き、月5万円の予算に収まる手を比べます。

いまの1台の上限は毎秒40件、大きくした1台の上限は160 QPSと仮定します。現状は100に足りませんが、大きい1台なら計算上は収まります。

月額は比較用の仮定で、保存先などの費用を含みません。全体で月5万円までという条件を確認してから、今回は大きい1台を候補にします。

この例では停止への備えを別途扱い、変更の少なさを優先します。大きい1台なら、振り分けとセッション共有を新たに用意する必要がないからです。

次の発売でピークが160 QPSに近づく見込みになったら、余裕がなくなる前に水平の案を測ります。複数台の合計性能と、追加部品を含む費用の両方が判断材料です。