落ちると全部止まる所

1つ隠して予約が止まるか見る

席の予約サービスの構成図で、部品を1つずつ指で隠してみます。その部品が使えないと全員が予約できなくなるなら、そこが単一障害点です。

アプリの台数だけでは判断できません。利用者の要求は振り分け、アプリ、保存先を順に通るので、途中のどこかが1つに依存していれば全体が止まります。

3台へ要求を配る振り分けが1台なら、その故障で3台とも使えなくなります。アプリを増やしたことは、要求を届ける経路が残ることを保証しません。

部品を隠したときは、代わりの経路で予約まで進めるかを追います。予備の台が置いてあるだけでは足りず、故障を検知して配り先を切り替える仕組みも必要です。

台数と置き場所を分けて数える

2台あっても同じ電源や回線に依存していれば、その共通部分の故障で両方が止まります。アプリが複数台でも、同じ置き場所に集まっていれば場所全体の障害には耐えられません。

構成図には台数に加えて置き場所も書きます。同じ場所にある箱をまとめて隠すと、台を1つずつ隠すだけでは見えなかった弱点が分かります。

離れた場所への通信には時間がかかり、費用も増えます。発売開始の数分を逃すと売上を失う予約サービスでは、その遅さと予約を続けられる価値を比べます。

月5万円の予算なら、すべてを同時に二重化できるとは限りません。予約を止める箇所と止まったときの損失を並べ、優先して手当てする箇所を決めます。

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

DAU 3万人が1人6回アクセスする想定では、1日18万件です。平均は約2 QPSと丸め、ピーク係数50を掛けると、設計上のピークは毎秒100件になります。

必要台数はピークの件数を1台の処理能力で割り、端数を切り上げます。1台40件なら、100÷40＝2.5なので、平常時は最低3台です。

ここでは振り分け1台、アプリ3台を同じ場所、保存先2台を別々の場所に置きます。保存先は片方の故障でも予約を書き込めるように切り替え可能とします。

この構成で全停止につながるのは、振り分けとアプリの置き場所です。保存先も、実際に切り替えられることを確認して初めて候補から外せます。

さらにアプリ1台の故障では2台で毎秒80件となり、ピーク100件を満たせません。全停止する箇所と、動き続けても能力が足りなくなる箇所は、別々に運用シートへ残します。