ほぼ独り言に近いです。間違ってたら指摘してください。
前提
システムデザインの面接を受けていたとする。
ここで、このサービスはトラフィックのスパイクがあります、と言われたとする。
何を考えて何と答えますか？という話。
考え方
具体的に 何request per secですか？と尋ね、「500 rpsです」と答えられたとする。
が、それを聞いても(面接の場では)どうしようもない。
ボトルネックを考えることが大事なのじゃないかと思う。
ボトルネックとなりうる可能性を示唆して、解決方法を提示すればいいと思う。
- web server -> DNS + LB + autoscaling で解決できそう。
- app server の CPU 処理 -> 同じく、DNS + LB + autoscaling で解決できそう。
- RDB の読み込み -> read replicaで解決できそう。
- RDB の書き込み -> mutli-master 構成や、shardingで解決できそう。(ただし、complexityは増す。)
となると、DB「read heavy か write heavy か」は聞く/考える必要がありそう。
以下をもとに考えると、RDBへのwriteが一番のボトルネックになるのかも、と思った。
数字の勘
具体的な数字を聞いても仕方ない、とは言ったものの、具体的な数字のイメージを持つのは大事そう。
app server
app server の CPU 処理に関しては、CPU usage 10% で 100ms かかるリクエスト (これが現実的な数字かはわからない) があるとする。これを８コアのサーバー1台で裁くとすると、rpsは、
10 * 10 * 8 * 1 = 800 rps。
オートスケーリングするならこれに台数をかけたものになる。結構捌けるのだなという感想。
いや、よく考えると、
CPU usage 10% で 100ms かかる
これは、処理の重さとCPUの性能に依存して決まる数字なので、前提がガバガバな気がしてきた。
RDB
PostgreSQLで考えてみる。以下に依存するはず。
- ハードウェアのスペック
- 現在のテーブルサイズ。とはいえ、処理時間はO(N)なので、影響は大きくないのかも。
- indexの個数。readは早くなり、writeは遅くなる。(indexの更新は非同期でもできるんだっけ？)
- レプリケーションの数。readは早くなり、writeは遅くなる。(ただし、replicationを非同期にやればwriteへの影響は軽微。)
- トランザクションのレベル。(最低レベルにすると、結構捌けるのかも。read/writeリクエストのそれぞれが、非同期に読み書きすればいいので。)
具体的な数字はわからなかったが、ネットでググると、PostgreSQLで、read queryを 20k/secとか、600k/secとか捌いたとかいう武勇伝が出てくる。本当なのだろうか。