【CEDEC 2016】複数のdatabaseで展開するスケールアウトの手法とは―セッション「モンスターストライクを支える負荷分散手法」をレポート

ここでは、同社からリリースされている大人気スマホアプリ「モンスターストライク（以下、モンスト）」のサーバーサイドの負荷分散手法に関する解説が行われたほか、大規模運用時に発生する問題や、障害へのアプローチについても言及された。

セッションは、「Monitoring system」「How to scale-out」「Cache」の3つのテーマが語られたのだが、本稿では、その中の主題である「How to scale-out」にスポットを当ててレポートしていこう。

	大塚弘記氏

大塚氏はまず、databaseについてコメント。氏いわく、databaseはボトルネックになりやすく、ある程度事前に設計をしておかないとコストが高くなる。コードを直したり、データを移行するといったメンテナンスを挟むという手間が、ほぼ確実に発生してしまうのだ。

それは、ビジネス的に考えても好ましくはない。結果的にコストが高くなってしまうからだ。そのため、databaseは厳重に設計しておいたほうがいいと、念を押すように話していた。

ちなみにスケールアウトとは、databaseサーバーが2台3台4台と横展開していくような状態のことを指す。複数台の構成に、台数を増やすことによって対応していくのだ。

しかし氏いわく、スケールアウトを行う前にやっておくべきことがあるという。特に、snow queryやindexの貼り忘れや、databaseのpoolの調整などは、横展開する前にすべて終わらせておくべきとのこと。

非効率なものを横展開すると、余計に非効率になり、いずれ誰も直すことをしなくなってしまう。それは絶対に避けたいことだし、問題を先送りにするだけだと、氏は警告していた。

では、いざdatabaseを分割するとなったとき、どうすればいいのか。方法は、2つある。垂直分割と水平分割だ。垂直分割とは、一部のテーブルを別のdatabaseに移動させるというもので、割りと簡単らしい。一方の水平分割は、1つのテーブルの各行を別々のテーブルに分散させることで、いわゆるshardingと呼ばれるものである。

垂直分割の説明も行われた。	シャーディングの説明も。
アーキテクチャーの説明と、コード内容も紹介された。

後半で氏は、シャーディングミドルウェアについても言及。いわく、数百MBから数GBクラスのトラフィックを流したとしても、それに耐えられるものを知らないという。

Go製のMySQL Proxy、youtube/vitess/flike/kingshardなどもあるにはあるが、いずれも、バックエンドのロードに障害が起きた時などは、運用が複雑になってしまうという弱点がある。普段使いに耐えられるものではないため、今のところ、採用していないとのことだ。

最後に大塚氏は、シャーディングはサービスにマッチしたアルゴリズムを選ぶ必要があると、来場者にアドバイスを送った。加えて、ORMのツールのライブラリは長期的なメンテナンスが必要になってくるという課題が立ちはだかることも、問題点として挙げた。proxy型などは、最新登場したものの中には良い製品があるかもしれない。しかし、複雑であることや、パフォーマンス面での課題はどうしても残ってしまう。そのため、まだまだ課題は残っているとコメントして、スケールアウトに関する説明を締めくくった。

セッションでは、自身のことや、モンストの実績なども紹介。
後半ではCacheに関する説明も行われた。

※メーカー発表情報を基に掲載しています。掲載画像には、開発中のものが含まれている場合があります。