System Design入門 設計判断を数字とコードで確かめる
アクセスの偏り
この回でやること
読みと書きのどちらが多いかを数字にして、設計の前提にします。
- 読む 約 7 分
- 最後にクイズ 1 問
読みと書きは同じ数ではない
席の予約サービスでは、予約1件の前に空席の読み取りが何度も走ります。設計の前提になるのは、機能の目立ち方より、保存先が実際に受ける読み書きの件数です。
DAUは3万人、1人が1日に6回操作すると、要求は18万回です。そのうち書き込みが3000回なら、残る17万7000回が読み取りになります。
主役ではありますが、利用者は決める前に何度も見ます。空席を調べた全員が予約するわけではなく、見る回数が決める回数を上回ります。
ここでは1回の要求が保存先への1回の操作に対応すると仮定します。実際には1画面で複数回読むこともあるので、要求数と保存先の操作数は分けて測ります。
偏りで効く手が変わる
読みが多ければ、同じ結果を返すキャッシュや、読みを別の台へ送る複製が候補になります。キャッシュは保存先への読みを減らし、複製は読みを複数台へ分けます。
書き込みが多い場合、読みを逃がしても書く台の混雑は残ります。書く内容を減らす、まとめて書く、データを分けるといった別の手を検討します。
書いた内容は複製先にも送る必要があり、転送と適用の仕事が増えます。書く台から読む仕事を外せても、書き込みそのものが減るわけではありません。
月5万円の予算では、台を増やす費用も比べます。読み書きの割合だけで決めず、どの台が何で詰まり、表示がどれくらい古くてもよいかを確かめます。
読み取りが多くても、遅い1件の書き込みが原因なら、割合だけでは改善策を選べません。待ち時間も操作ごとに測り、減らす対象が本当に読みかを確かめます。
予約サービスで解いてみる
18万回の要求のうち3000回が書き込み、という条件で、読みを別の台へ逃がす案が有効か考えます。読みの割合は、全体から書きを引いた件数を全体で割って求めます。
読みの件数 = 180000 − 3000 = 177000
読みの割合 = 177000 ÷ 180000 × 100 ≒ 98.33%平均は18万回を1日の86400秒で割ると約2 QPSです。コースでは丸めた2にピーク係数50を掛け、ピークを100件/秒と見積もります。
読み書きの割合がピークでも同じなら、読みは約98.3件/秒、書きは約1.7件/秒です。読み取り1台40件/秒なら、読みを受ける台は98.3を40で割って切り上げ、3台が目安です。
この条件なら、読みを逃がす案を測る価値があります。ただし発売開始だけ書きの比率が増えるなら、この見積もりは変わるので、その時間帯の件数を取り直します。