このブログ記事では、MySQLのシャーディングモデルについてとどのようにそれらをSaaSアプリケーション環境に適用するかについて議論します。 MySQLはもっとも人気のあるデータベース技術の1つで、多くのモダンなSaaSアプリケーション（単純な生産性向上のツールから、金融や医療と言ったビジネスクリティカルな領域まで）の構成要素として使用されています。 MySQLを使用している大規模なSaaSアプリケーションのほとんど全ては シャーディング を使用しています。 このブログ記事ではこのような種類のアプリケーションに対してどのシャーディング方法を選ぶかを議論します。
MySQLではよりモダンな技術の MongoDB のようなものとは異なり、アプリケーションから利用される上での標準的なシャーディング構成はありません。 事実、「スタンダードがない」ことがスタンダードなのです。 共通の事例と呼べるものは、自分自身でシャーディングのフレームワークを作ることです。MySQLユーザーとして有名なFacebookやTwitterはそうしています。 MySQL Cluster – MySQLの中に自動シャーディング機能が組み込まれている – はめったに利用されていません（これにはいくつかの理由があります）。 公式なシャーディングフレームワークだった MySQL Fabric は既に牽引力がありません。
今日シャーディングをするならば、いくつかの選択肢があります。スクラッチで作成する、 Vitess のような包括的なシャーディングプラットフォームを利用する、またはシャーディングの補助としてプロキシを使用することです。 プロキシのソリューションとしては MySQL Router が公式のソリューションですが、実際のところオープンソースの ProxySQL 、商用の ScaleArc 、準商用(BSL)の MariaDB MaxScale らサードパーティーのソリューションが広く使われています。 しかし覚えておいてください。トラフィックルーティングは大規模なシャーディング構成の問題点のうち、たった1つでしかありません。
これら全てのデータベース接続のフレームワークやデータベースプロキシなど「フロントエンド側」（訳注: MySQLから見たフロントエンド）の選択肢の下に、より低レイヤーな決断が必要です。 すなわち、MySQLノードにどのようにしてデータを分散させ、組織化するかです。
SaaSアプリケーションの文脈で語る場合、1つの答えはシンプルです。一般的に、あなたのデータを「顧客ごと」または「組織ごと」にマッピングテーブルを使って分割することが役に立つでしょう。 大多数のケースでは、シングルノード（またはレプリケーションクラスター）は全てのデータとそれぞれの顧客から来るトラフィックをハンドルするのに十分な性能が必要です。
今、何が必要とされているか
次の質問はあなたのSaaSアプリケーションについてあなた自身が確認しなければならないことです。
- 1顧客あたりどのくらいの収益を生み出せるのか
- 顧客（あるいは法令）はデータの分離を要求するか
- 全ての顧客たちはほぼ同じか、あるいは顧客ごとにバラバラか
- 全ての顧客を同一のスキーマの中で処理するのか
この答えは以下の段落で紹介します。
どのくらいの収益があるのか
1顧客当たりどのくらいの収益を生み出せるのかは重要な数字です。それは1顧客当たりどれだけのインフラコストを払うことができるかを決めます。 「フリーミアム」モデルの場合、または平均して1顧客の月当たりの収益が1ドル未満の場合、あなたはそれぞれの顧客にオーバーヘッドの少なさを提供する必要があるでしょう（たとえ、あなたが顧客間の分離を諦めなくてはならないとしても） 一般に収益の小さな顧客の場合、あなたは複数のデータを同じMySQLインスタンスの中に同居させなければいけません（同じテーブルに入れなければならない可能性もあります） 高収益な顧客の場合、別々のMySQLインスタンス（またはコンテナや仮想化OS）にデータを分離することが可能になるでしょう。
データの分離
データの分離は別の重要な面も占めています。あるエンタープライズの顧客は彼らのデータが物理的に他の顧客のものと分離されていることを要求します。 あるいは、政令により顧客情報が物理的に特定の場所におかれることを要求するかも知れません。 このようなケースでは、完全に専用の顧客環境を考えるか、どんなに少なくともデータベースインスタンスを分離しなければなりません（これは追加のコストを必要とします）
顧客のタイプ
顧客の数と要求事項も重要です。全ての顧客をほぼ同じスケールで扱うように設計されたシステム（たとえば、個人会計）はブログホスティングのビジネスとは違があります。 いくつかのブログは（訳注: そのホスティング環境内の）平均の10000倍有名だったりするでしょう。
同じデータベーススキーマ
最後に、あなたの全ての顧客が同じデータベーススキーマの上で、同じソフトウェアのバージョンを使うかどうか、という大きな質問があります。 もしあなたが、違うバージョンのソフトウェア（例えば、もしあなたの顧客がソフトウェアのアップグレードのためにメンテナンスタイムを交渉することを要求するなど）や、または違うデータベーススキーマ（例えば、カスタム機能や顧客が私用するモジュールごとにスキーマを独立させなければならないなど）をサポートしたいと思った場合、そのような顧客は別のMySQLスキーマを利用することが有意義でしょう。
シャーディングモデル
これは、以下のような分離モデルを与えてくれます。範囲は低いものから高い順に:
顧客がスキーマを共有する構成
- これはあなたがとても多くの低収益な顧客を抱えているケースの最善策です。このケースでは、複数の顧客が同じ構造をもったテーブルにマッピングされ、個々の顧客のデータをフィルタリングするために customer_id フィールドのようなものを含んでいます。
- このアプローチは顧客ごとのオーバーヘッドを最小化し、顧客ごとの分離性を低めます。個々の顧客に対するデータのバックアップ/リストアは難しく、コーディングのミスがあれば容易に他の顧客のデータへのアクセスを許すことになります。
- この方法はたった1つのスキーマのみが存在するという意味ではなく、スキーマと顧客の間に1対多のリレーションシップがあるということです。たとえば、1つのMySQLインスタンスあたり100のスキーマを作ったとしましょう。そのスキーマのそれぞれが1000から10000の顧客のデータを扱うということです（アプリケーションによりますが）
- シャーディング構成のより良い設計としては、顧客をそれぞれ別々にスキーマにマップすることです。これは重要な顧客のデータを別のスキーマに、あるいは、別のノードに配置することができるということです。
顧客ごとのスキーマ構成
- これはおそらくSaaSアプリケーションでMySQLを利用する場合のもっとも一般的なシャーディングのアプローチでしょう。特に確実な収益（1顧客1月当たり10ドル以上）がある場合に一般的です。
- このモデルでは、それぞれの顧客のデータを各自のスキーマ（database）に保管します。これは顧客単位でのバックアップ/リストアを容易にしますし、顧客ごとに別々のテーブル構成（たとえば、個別にテーブルを追加するなど）が可能です。もし望むなら、違うバージョンのアプリケーションを実行することもできます。
- このアプローチはアプリケーションサーバーが顧客ごとに異なるMySQLユーザーで接続する構成にできるため、事故（あるいは故意）による他の顧客へのデータアクセスに対する追加の予防策にもなります。
- 顧客ごとのスキーマ構成はシャード移動の際のメンテナンスの影響も制限することができます。
- このアプローチのデメリットは、オーバーヘッドが大きいことです。結果として1インスタンスあたりにたくさんのテーブルが出来上がり、たくさんの（管理しにくい）ファイルが増える可能性があるでしょう。
顧客ごとのデータベースインスタンス構成
- より良い分離性を成し遂げるには、顧客ごとにMySQLインスタンスを作成することです。
- しかしこのアプローチは更にオーバーヘッドを増加させます。最近注目を浴びている仮想化技術やコンテナがその手間を軽減してくれるでしょう。
顧客ごとのOSインスタンス/コンテナ構成
- このアプローチは分離レベルを更に高めることができます。これは全ての顧客に適用することもできますが、選ばれた顧客にだけこれを適用し、その他の多くの顧客には顧客ごとのスキーマ構成を適用することもできます。
- 分離されたOSインスタンスは分離性と良いパフォーマンスSLAを提供でき、特別な顧客に提供されるべき機能でしょう。この方法はより良い分離性だけでなく、外れ値的なトラフィックを扱うことにも適しています。
- その他の多くの顧客にはコストパフォーマンスの良いハードウェア（またはクラウドインスタンス）を選びます。いくつかの大規模な顧客にはハイパフォーマンスのノードを割り当てましょう。
顧客ごとの環境構成
- 最後に、顧客ごとに完全に分かれた環境を構成することもできます。これはデータベース、アプリケーションサーバー、その他必要なコンポーネントを全て含んだものです。
- これは特にアプリケーションを顧客に密接に提供しなければならない場合に役立ちます - アプライアンスモデル、顧客のデータセンターでのデプロイ、またはクラウド事業者などを含みます。
- これは顧客のデータが特定の物理的な場所に格納されなければならないという要件がある場合に適合します（政令で要求されている場合など）
- しかし、たとえ全ての環境が顧客ごとの環境構成になっていなくても、多くの複数の独立した環境を持つSaaSアプリケーションにはこの案に注目する価値があります。それらはしばしば違った場所、またはアベイラビリティーゾーンに収容されています。そのような構成は一部の顧客に対して大規模災害の影響を減らします。これはカスタマーサービスグループの負荷を減らしオペレーション組織がより小さな環境を復旧することに集中することを助けます。
- 更にこの道を下っていくと - 顧客がスキーマを共有する構成から、顧客ごとの環境構成まで - もっと重要なのは高レベルな自動化だと気付くでしょう。スキーマを共有する構成では、小規模な自動化をよく使い（そして、いくつかの環境については手作業でセットアップをし）全てのスキーマはあらかじめ作成されているでしょう。
- もし顧客が占有のデータベースインスタンスまたは占有の環境を要求する場合、手動での構築はスケールしません。このタイプの環境構築には、最先端の自動化とオーケストレーションが必要になります。
まとめ
この記事が、あなたのMySQLのシャーディングモデルに対する理解を深める助けになると良いと思っています。それぞれの違ったシャーディングモデルはそれぞれメリットとデメリットを持っています。 これまで見てきたように、これらのアプローチはあなたに数多くのテーブルと付き合うことを求めます - これは私の次の記事のテーマの1つです！
