RDBの拡張：Cluster 第08回 17年07月 / 最終更新：2017.07.21
みなさん、こんにちは。エンジニアの古庄道明です。
今回は「RDBのまま、重たい状況をどう打開するか」「大きくなってきたシステムで、RDBのまま、どうやってRDBをより拡張していくか」について、さらに言及を重ねていきたいと思います。
タイトルにもすでに書いてしまっておりますが、RDB製品のいくつかには、Cluster、と呼ばれる技術があります。
例えばMySQLですと、文字通り「MySQL Cluster」という製品があります。今回は、このMySQL Clusterについて少しお話をさせていただければ、と思います。
RDBですが、基本的には「スケールアウトが難しい」という側面があり、そのあたりについては、第５回目である「RDBMSの基本とNoSQL その２」にて、CAP定理と分断耐性のあたりでお話をさせていただいた、かと思います。
ただ、RDBで実はもう一つ比較的コストを食うのが「SQLの解析部分」になります。
SQLは、シンプルなクエリを扱う事も多いかと思うのですが、一方で「ものすごく複雑なクエリ」を発行することもできます。
そのために、SQLは結果的に「柔軟な記述が可能」で、つまりそれは「解析等のためにある程度、高いコストがかかる」事を意味します。
MySQL Clusterでは、これらを考えて
・「SQLを解釈する」SQLノード
・「データを扱う」データノード
という風に役割を切り分けて、かつこれらを「別々のマシンに配置しても動くようにする」事で、スケールアウト(サーバ台数を増やして全体の性能を上げる)が可能なようにしています。
SQLノードは文字通り「SQLを解釈していく」ためのノードです。
どのように配置をしてもよいのですが、筆者の周囲ですと「Webサーバと同じマシンに同梱させて、Webサーバを増やす時には合わせてSQLノードも増やす」といった形で設計をしているケースが多いように思います。
ただ、SQLノードは比較的「CPUをよく食う」性質があるので、もし「そもそものWebサービス側でも非常にCPUを大量に使う」ようなケースですと、Webサーバと共存させないほうがよい、という判断もあるか、と思います。
データノードは「実際にデータを預かっている」サーバになります。
データノードは複数台のマシンで構成されていて、例えば「データノード１マシン」と「データノード２マシン」は、相互にレプリカを持つような構成にします。
これによって「１台のサーバが倒れてもデータは死なない」ようにする事ができます。
また、今回は「１つのノードグループにデータノード１マシンとデータノード２マシンの２台」を想定してますが、１つのノードグループに３台４台とマシンを入れていけば、性能も上がりますし、全滅の可能性も下げる事ができるようになります。
性能などをヘルスチェックしながら、必要に応じてデータノードを追加していくとよいと思います。
ちなみにデータノードは比較的「たくさんのメモリを使う」ので、各マシンとも、メモリをしっかりと積んでおくとよいと思います。
上述のような状態から、基本的には最小構成で「データノードにマシンを２台」が必須になります。
SQLノードは、最小構成であれば「データノードマシンに共存」でもよいですし、もう少し現実的には「Webサーバに同居」のほうがわかりやすい、かと思います。或いは「SQLノードを別途、単独のマシンで用意する」というのも、手法的には可能です。
なお、「どこにデータノードがあるのか」などの全体を管理するために、実際には上述２ノードのほかにもう一つ「管理ノード」というものが必要になります。
ただ、管理ノードは「どこかに共存していればよい」「冗長構成は不要」なので、例えば「管理画面用のサーバに共存させる」などでよいと思います。
管理ノードは「ある」事が重要な一方で、それ以外にはあまり負荷がかからないので、比較的小さいマシンでも十分かと思います。
MySQL ClusterでRDBを構成する場合「外部キー制約が使えない」「JOINで性能が出ない」「インストールが難しい」など、少し癖のあるものではあり"ました"。
しかし、この手の製品……に限らず、大概の製品で言える事ではあるのですが「問題点は十二分に承知していて、改善を常に考えている」もの、なので、比較的最近の、新しいバージョンのMySQL Clusterですと、上述の問題が解消しています。
ですので、今まで以上に使いやすいのではないか、と思いますので、選択肢の一つとして考察してもよいのではないか、と思います。
MySQL Clusterをうまく使いこなせると、レプリケーションで出てきました「最終的に「書き込み用サーバが、書き込み切れない量の書き込みSQLを流した」時点でパンク」というボトルネックが解消しますので。
そういった状況が想定されうる状況であれば、十分に「考慮に入れるべき選択肢」になる、と思います。
また、クラウドならではの「最終手段」なのですが、もう一つ手段があります。
基本的に、RDBの制限は「CPUにしてもメモリにしてもHDDにしても、物理マシンに上限がある」事に起因するもの、なので。
また、一方でクラウドは「複数台の物理マシンを、仮想的に１台とみなす」事が出来る技術を、裏側にはらんでいるので。
非常に金額のかかる手法ではありますが「RDBにアサインするマシンインスタンスを極端に巨大なものにする」事で、一時的または恒久的に「RDBがボトルネックになる事を防ぐ」という方法も、存在します。
ただし、押し並べて「高額になりやすい」方法なので、収益なども含めて十分に熟慮してから選択をしたい手法、ではあります。
とはいえ、物理サーバのままですと「金額を積んでも解決できない」から、クラウドによって「金額を積めば解決できる」ようになった、というのは、非常に大きな、クラウドのメリットである、と思われます。
以上、８回にわたりまして、「ゲーム業界」における「クラウドの優位性」について、つれづれと書かせていただきました。
これまでの記事が、皆様の何かのお役にたてたり参考になったりしたのだとあれば、筆者望外の幸いです。
どうもありがとうございました。
サービス・ソリューション
