つくる 構成案

構成は利用者数について変わる

この章で4つを見ました。1台の上限、垂直と水平、振り分け、状態の置き場所です。

今回は新しいことを覚えません。どの段階でどれが要るかを1つの関数にします。

段階は利用者数ではなく、ピーク QPS で決めます。人数は要求の数に化けて初めて負荷になるからです。

よくありません。1人が1日1回しか使わないサービスと、100回使うサービスでは、同じ人数でも負荷が100倍違います。

数えるのは人ではなく要求です。

要るものが増える順番

台が1台のうちは、アプリと保存先の2つで足ります。

台が2台になった瞬間に、振り分けとセッションの置き場所が同時に要ります。この2つは必ず一緒に来ます。

# 1台     app, database
# 2台以上  load-balancer, app, session-store, database

振り分けだけ入れると、ログインが切れます。

2台にする決定と、状態を外へ出す決定は同じ決定です。 片方だけやると、状態を外に出す回で見た壊れ方になります。

キャッシュはこれとは独立で、読み取りが増えたら足します。

演習

ピーク QPS と1台の性能から、手・台数・要る部品の並びを返します。

1. qps_per_server は 1000 ÷ ms_per_request の整数部分 × workers
2. strategy と servers は第16回と同じ。peak が qps_per_server 以下なら as-is、max_qps_per_server 以下なら vertical、超えるなら horizontal で切り上げ
3. components は app と database を必ず入れ、servers が2以上なら load-balancer と session-store を、peak_qps が100を超えるなら cache を足す。並びは load-balancer / app / session-store / cache / database の順