導入の経緯
MariaDB Galera Clusterを導入するに至ったきっかけは、当社全体で推進しているマイクロサービスへの対応のためです。
本システムの構築以前は、MySQLを使用したマスタ/スレーブ構成のデータベースシステムを利用していましたが、今回サービスごとに専用のMySQLを構築するのではなく、運用管理の効率化や構築コストの削減のためデータベースを提供する基盤をひとつ用意しその中から新規サービスに必要な容量を払い出していくという方針を取ることになりました。
その際にいくつかの方法（NoSQL, Oracleなど）を検討しましたが、最終的に「MySQLとの互換性」 「マスタ/スレーブ構成ではない点」 「ダウンタイムが少ない」 「導入コスト」などの面からMariaDB Galera Clusterの導入を決定しました。
また、今までは自社内で運用保守を行ってきたのですが、基盤化に伴いより一層安定したシステム稼動を目指したいという考えの下、MariaDB 社の公式サポートが付随したMariaDB Enterprise Cluster※を利用するに至りました。
スマートスタイル社から購入した理由としては、提案を受けた際にエンジニアの方から直接詳しい技術的な要素まで聞くことができたので、今後のやりとりもスムーズに進めることができると感じたからです。
※ MariaDB Enterprise Cluster…MariaDB社が提供するMariaDB Galera Clusterの公式サポート
MariaDB Galera Clusterについて
システム構成
本システムは、当社の各サービスのデータベースの集約化を目的として新しく構築した新データベースシステム基盤となります。
現在はおよそ1000qps（Query Per Second）くらいの規模で、その大半はSELECTです。更新クエリは20～30qpsくらい、データ量は全体で約60GBとなり、使いたいサービスごとにデータベースを払い出しして使っています。ひとつひとつのインスタンスは10GB程度ですが、サービスごとに使われ方は異なります。
MariaDBは10.1系を使用、ノード数はマスタ3台で、そのうちの1台にバックアップ用のスレーブ1台をぶら下げています。スレーブはバックアップ目的です。また、マスタサーバの前段にHAProxyがあります。Galera Clusterのおかげで全ノードに対しreadとwriteが可能なので、HAProxyでreadとwriteの両方を全ノードに分散させるマルチマスタ構成にしています。
サーバは全て物理サーバ、ディスクはSSD。ただし、特別スペックが高いわけではなく、汎用的なサーバとなっています。
開発体制
基盤システム全体での開発期間は4ヶ月程度です。そのうち構築にかかった期間は検証なども含め1ヶ月程度です。それぞれデータベースに関連する業務に就いていたメンバー5人の体制で行いましたが、いわゆるDB専門の 「スペシャリスト」 はいませんでした。
導入手順
MariaDB Galera Clusterの導入に関してはyumでインストールを行いました。手順はMariaDB社が公開している公式マニュアルを参考にしましたが、設定なども含め簡単に出来たので、特に困ったことはありませんでした。HAProxyについては、以前から他のシステムでは利用していたのですが、私達のチームで扱うシステムとしてはGalera Clusterに併せて初めて導入する運びとなりました。また、導入後のDB監視については、「Zabbix」を使用しています。サーバリソースやMySQLステータスは勿論ですが、Galera特有のオプション（wsrep_…変数）も新しく監視対象としました。
メリット
導入時
MySQLからの移行に関しては、ほとんどのパラメータが同じでとてもスムーズに行うことができました。アプリに関しても特に修正の必要がなく、設定ファイル（my.cnf）も流用することができたので、MariaDBはMySQLに近しいものだと感じました。
性能面
以前のマスタ/スレーブ構成のものであればサーバが高負荷となりマスタがダウンした際、フェイルオーバに1時間ほど時間がかかり、長いダウンタイムが発生していました。しかし、新しく構築した本システムではMariaDB Galera Clusterを用いたマルチマスタ構成を採用しているので、問題発生時には参照先のノードを切り替えるだけで済むため、ダウンタイムはほぼなくなりました。
運用面
運用に関しては、今のところ安定稼働していて、特に不具合は発生していません。今回の新システムから自動構築系のスクリプトを導入したこともあり、DBサーバにログインして直接コマンドを実行して…、などの作業も減り運用もかなり簡略化できました。また、Galera ClusterではRSU（Rolling Schema Upgrade）※が可能なので、これまで困難だった「マスタ」のメンテナンスも容易になりました。DBのメンテナンスにかかるコストや手間を省くという面でも大きなメリットだと思います。
※ Rolling Schema Upgrade：1ノードずつクラスタから切り離して、テーブルのメンテナンス（DDL）やバージョンアップを実施する方法。ノードを切り離している間も、クラスタに残ったノードでサービスが継続可能。
サポート
本システムの構築時や運用の際にMariaDB社のサポートを利用する機会が幾度かあったのですが、レスポンスも早く回答内容もしっかりしており満足できるものでした。具体的には、構築時にエラーが起こった際の原因特定（原因はバグでした）や、バックアップに関する戦略、ローリングアップデートに関する質問など幅広く対応してもらうことができ非常に助かりました。
デメリット
本システムは新規サービスに対する新しいデータベース基盤のため、以前のデータベース環境との比較は難しいですが、クラスタという意味で比較すると、Galera用のクライアントがないのでHAProxy等のプロキシを挟む必要があることが気になりました。
また、レプリケーション遅延が依然として発生する点はデメリットと感じています。以前のマスタ/スレーブ構成では、レプリケーション遅延が起こったときにデータを参照することができないので、その部分に気をつけてシステムを組んでいました。Galeraのマルチマスタ構成にすれば、このような問題が発生しないと思っていましたが、ノード間の同期の部分で時折データのズレが発生することがあり、やはりレプリケーションの遅延には気を付ける必要があると考えています。
注意した点
データの書き込み（更新クエリ）の際に、CPUのiowaitが発生することがありました。いくつかパラメータを調整することで対処することはできたのですが、その後もディスクI/Oの負荷が高くなることがあるので、普段から注意してI/Oの状況を見るようにしています。特に、本システムの新しい利用申請があった時は、更新クエリ（Write）のqpsをしっかり確認しています。参照クエリ（Read）に関してはqpsベースでは特に注意することはないのですが、レスポンスタイムに幅がある時は、調整することもあります。
全体を通してのご感想
全体を通して運用面では人員コストも含め改善することができたので、MariaDB Galera Clusterを導入して良かったと感じています。また、新システムを使用して約1年経ちましたが、大きな問題もなく安定して運用することができています。今後もサービス向上のため、より高いパフォーマンスと可用性を求めシステムの改善を行っていきたいと考えております。
Galera Clusterとは
- 「完全同期レプリケーション」を実現する、オープンソースのクラスタリングソフトウェア
- 全ノードが「マスタ」となり、更新・参照の受付が可能（3ノード以上の構成を推奨）
- データベースとしての基本機能はMySQLと同じ（ストレージエンジンはInnoDBのみ）
※ MariaDB Galera Clusterとは、「Galera Cluster」をベースとし商用環境での利用を想定したMariaDB独自のクラスタリング製品
