読み込みが増えて DB が重いとき、どんな手をどの順で打ちますか

打つ手の順番

安くて戻しやすい手から順に打ちます。

1. 測るどの SQL が、どれだけの回数と時間で重いかを掴みます。CPU が高いのか、ディスクの読み込みが多いのか、接続が足りないのかも見ます
2. SQL とインデックスを直す 全部の行を読んでいる、同じ SQL を何十回も流している (N+1)、といった物を直します。台数を増やさずに済むことが多い手です
3. 接続の数を整えるアプリの台数が増えると、DB への接続が上限に近づきます。コネクションプールの大きさをそろえ、必要なら間に接続をまとめる仕組みを置きます
4. 手前で返すよく読まれて、少し古くてもよい物はキャッシュに置き、DB まで来ないようにします
5. 読み込みを複製に分ける書き込みは元の DB (主)、読み込みは複製 (リードレプリカ) へ送ります。複製は台数を足して読み込みの力を増やせます
6. DB を大きくする、分割する 1 台を大きくするのは早くて作りを変えずに済みますが、上限があります。表を複数の DB に分ける分割は、最後の手です

複製の遅れ

多くの構成では、複製は元の DB の変更を少し遅れて写します。ふだんは短い遅れでも、重い書き込みが続くと遅れが伸びます。

その間に複製から読むと、「プロフィールを保存したのに、画面には古い名前が出る」ことが起きます。手当ては次の通りです。

• 書いた直後の画面や、自分の書いた物を読む所は、元の DB から読む
• 書いてからしばらくの間は、その人の読み込みを元の DB に寄せる
• 残高や在庫のように、古い値で判断すると困る読み込みは、いつも元の DB から読む

複製の遅れは監視し、遅れが大きいときは複製から外す仕組みも考えます。

分割を最後に回す理由

表を利用者の id などで複数の DB に分けると、書き込みも読み込みも分けられますが、別の DB にまたがる結合やトランザクションが使えなくなり、アプリの作りを大きく変えることになります。分け方を間違えると一部の DB に偏り、後から分け直すのは大仕事です。だから、ほかの手で足りないことを数で確かめてから選びます。

トレードオフ

キャッシュも複製も、「少し古い値を読むかもしれない」ことと引き換えに、DB の負担を減らします。どの画面ならどれだけ古くてよいかを、画面ごとに決めることになります。台数を増やすほど費用と見る物も増えるので、目標の速さを数字で置き、届いたら止めます。

話す例は架空の例で構いません。「ランキングの画面が重く、まず SQL を直し、次に結果をキャッシュし、それでも朝の山で足りないのでリードレプリカに分けた」のように、どの順で何を打ったかを話せると伝わります。