サーバ／インフラを支える技術　2章　(2.3 2.4 2.5)

勉強

２．３　MySQLのレプリケーション

レプリケーションとはデータを別の場所へリアルタイムに複製すること。
レプリケーションには二つの役割があり、それぞれマスタとスレーブと言います。
マスタは、

更新と参照の両方のクエリを受け付ける

スレーブは、

更新のみで、データの更新はマスタからの指示で行われる

つまり、マスタで更新があった場合に、スレーブに通知しスレーブで更新を行い同期を取ります。
そして、MySQLのレプリケーションは、「SQL文」単位で行われます。
この本にはこれらの他に、実際に設定する方法や注意事項について書かれています。
これまでは定期的にダンプして別のサーバに保存していたけど、レプリケーションを利用すればその必要はなさそう。むしろより柔軟な構成を作りデータもほぼリアルタイムで複製されることから、できる限り利用した方がよいと思う。
しかも決して難しい知識が必要ではない（知識を持っていないと結局問題があったときに解決できないと思うけど）ので、導入するハードルは非常に低くなっていると思います。ここまで記してくれるのはとてもうれしいですね。

２．４　MySQLのスレーブ＋内部ロードバランサの活用例

ここでは更新系はマスタに、参照系はスレーブにサーバを振り分けて、参照系の負荷を分散することを考えます。負荷を分散するには内部ロードバランサを利用します。
各種サーバーやロードバランサ、そしてMySQLの設定が実際に構成図に照らし合わされて示されます。

更新系と参照系を分けるのは、おそらく更新系よりも参照系のほうが圧倒的にリクエストが多いのでしょう。普通はそうだと思います。そもそもそんな風に分けられることすら知りませんでしたけど…

２．５　高速で軽量なストレージサーバの選択

大容量のコンテンツ（動画や音声など）をどうするかという問題。
ストレージサーバを導入したとしても、デメリットが多いそうで。

などが上げられます。
そこで、HTTPをストレージプロトコルとして利用することによって解決していきます。
このへんはやったことがないので全く実感が湧きません。そもそもHTTPをストレージプロトコルに利用しているけど、HTTPって遅くなかったっけ？.NETで使ったときは、TCP/IPの何倍も速度が遅い記憶があるんだけどなぁ、なんて疑問が湧いてしまいました。きっとなにか良い理由があるんでしょう。
この辺の構成を考えるのもとても楽しいです。きっと、実際に速くなったときはとても感動するんだと思います。