「RDBの拡張：レプリケーション」

鈴与シンワートは古庄親方が連載しているコラムの最新号「RDBの拡張：レプリケーション」を掲載しました。

###
みなさん、こんにちは。エンジニアの古庄道明です。
今回は「RDBのまま、重たい状況をどう打開するか」「大きくなってきたシステムで、RDBのまま、どうやってRDBをより拡張していくか」について、言及をしていきたいと思います。

RDBは、基本的には「一貫性と可用性を選択した結果として、分断耐性がない」設計になります。
そのため、本質的には「スケールアップ」が唯一の規模拡大の方向なのですが、スケールアップは比較的容易に限界がきてしまう、という問題があります。
しかし、運用の仕方によっては、RDBも「ある程度の」分断耐性を持たせることができます。

さて。
ゲーム業務問わず、Webアプリケーションを解析してみるとわかるのですが。
サイトの作りと構成にもよりますが、DBに対するwrite系動作(insert/update/delete)と比較して、read系動作(select)のほうが「多い」ケースが圧倒的に多数である、という事実があります。
仮に、writeとreadの比率を「1:4」である、と仮定します(これよりもreadに傾くサイト、も、少なからずありますが、一端仮の数値です)。

この場合「レプリケーション」という方法を使うことで、ある程度「１台のサーバでは難しい分量の処理を、複数台サーバを使ってこなす」事ができるようになります。
レプリケーションは「複製」と和訳される事があり、本来的な意味としては「同じ計算機を複数台横に並べることで性能の向上を目指す」といったところになります。
DBの場合、細かく言います「データレプリケーション」と呼ばれるもののひとつ、になります。

（この続きは以下をご覧ください）
(リンク »)