System Designとは

条件から設計を決める

System Design は、サービスの構成を決め、その理由を説明する仕事です。このコースでは、公演の席を利用者が予約するサービスだけを題材にします。

同じ予約サービスでも、利用者数や予算が違えば選ぶ構成が変わります。構成図を見る前に、何を優先し、どの条件を守るかをそろえます。

使い慣れた構成は候補になりますが、今回の条件を満たすかは別に確かめます。安さを優先する立ち上げ時と、混雑で予約が失敗する時期では、同じ判断を続けられません。

選ばなかった案まで残す

安い A 案と速い B 案を比べるときは、同じ項目で並べます。月額だけ、速さだけを見て決めると、選んだことで何を失うかが分かりません。

記録には、前提、選んだ案、選ばなかった案、その理由を残します。「A にした」だけでは、半年後に B を選ばなかった理由を思い出せません。

探して見つかれば比較に加えます。見つからなければ、今回守る条件を決め、満たせなかった条件も記録します。

捨てた案は失敗の記録ではありません。前提が変わったとき、最初に読み直す候補になります。

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

1日の利用者数を表す DAU は3万人、1人が1日に送る要求は6回とします。1日の要求数を1日の秒数で割ると、平均は約2 QPS、つまり1秒あたり約2件です。

平均2 QPS にピーク係数50を掛け、混雑時は100件/秒と見積もります。1台40件/秒なら、平均だけを見て1台で足りると決めるのは危険です。

今回は月5万円が上限で、次の2案を比べるとします。処理能力は仮の見積もりであり、実際の予約処理で測って確かめます。

A は1台40件/秒の台を3台使い、関連費用も含めて月4万円と見積もった案です。B はより速い構成ですが、今の予算を超えます。

今は A を選び、「B は速いが、費用を優先したため採用しない」と残します。A では120件/秒を超える混雑に対応できない点も、選んだ結果として書きます。

半年後に混雑が増え、予算も見直せるなら、まず B と落とした理由を読み直します。速さを優先する状況に変わったため、費用を理由に落とした判断が今も妥当かを確かめるのです。

B を自動的に採用するわけではありません。現在の要求数と費用を再確認し、条件が変わった箇所から比較をやり直します。