MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは

前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。

master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。

台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。

  • slave * 2 → 残り 1台で処理継続
    • 生き残った1台あたりの処理が 2倍になる
  • slave * 3 → 残り 2台で処理継続
    • 生き残った1台あたりの処理が 1.5倍になる

たとえば 1台あたり最大 1000qps の処理能力があるとします。slave 1台がダウンした場合にも安定して処理を継続するためには、平常時に許容される負荷は以下のようになります。

  • slave * 2 → 500qps * 2 = 1000qps * 1 = 合計 1000qps
  • slave * 3 → 666qps * 3 = 1000qps * 2 = 合計 2000qps

slave 台数は 1.5倍ですが、平常時に許容できる処理能力は 2倍になるので、3台構成のほうがお得です。

さて、障害が発生して切り離した slave は復旧作業を行う必要があります。slave を構築するにはざっくりと

  1. mysqldump で取得したバックアップからのレストア
  2. 既存のデータを丸ごとコピー

の二つの手段があると思います。

ファイルコピーに比べて、バックアップからのレストアは時間がかかります。また、毎日1回バックアップを取っている場合、レストア時には最大24時間(平均12時間) の時間差があるため、レストア後にその時間分の更新を追いつかせる、という作業が必要になります。
ファイルコピーで済めば、それに越したことはないわけです。

slave 2台構成の場合、生き残っている 1台をファイルコピーを行うために停止することは、全体のサービス停止に繋がります。(LVM snapshot などを使用すれば停止時間は最小に抑えることはできますが)
slave 3台構成の場合は生き残った 2台のうち 1台を、負荷の低い時間帯に停止してまるごとコピーすることができます。
つまり 2台構成よりも 3台構成のほうが、slave の作り直し作業が格段に楽になる、ということですね。

ということで、初期コストは上がりますが障害時のことを考えると、slave で参照を分散するなら 2台よりも 3台構成ではじめるのがよいのでは、というのが個人的な結論です。