株式会社ドワンゴ
MariaDB Galera Cluster でマイクロサービス化に対応

高可用性の実現と運用コストの削減に成功

概要
ドワンゴ株式会社（以下：ドワンゴ社）はユーザの多様なニーズに応えるため、数年前よりマイクロサービス化を推進している。
それに伴いサービスリリースの早期化やコスト削減などといった課題を解決するべく、各サービスで利用可能なデータベースシス
テム基盤の構築を決定。従来使用していた MySQL のマスタ / ス

レーブ構成ではなく、MariaDB Galera Cluster を利用したマルチマスタ構成を新たに採用し、以前よりも高い可用性を担保しながら運用体制の効率化を実現した。

課題バージョン

マイクロサービス化に対応するため、データベース運用の効率化と更なるMariaDB 10.1 系

安定的な運用を目指す

対象システムマイクロサービス化に伴う新サービスに対する新規データベース基盤解決策

MariaDB Galera Cluster を使用した新データベース基盤の構築

結果■

ダウンタイムの大幅削減によりデータベースの安定した運用を実現■

データベース基盤の集約化に伴い、運用コストの削減に成功

以前ではフェイルオーバ時に 1 時間以上かかっていたものが、Galera Cluster を利用したマルチマスタ構成に変更することでダウンタイムがほぼ “０” に。
１つの基盤から各サービスに必要なデータベースを払い出すことで、包括的な運用管理（メンテナンスの簡略化など）が可能になり、運用にかかるトータルコストの削減に成功。

導入インタビュー
導入の経緯

MariaDB Galera Cluster を導入するに至ったきっかけは、システム構成

当社全体で推進しているマイクロサービスへの対応のた

現在はおよそ 1000qps（Query Per Second）くらいの規模で、その大半は SELECT です。更新クエリは 20 〜

Application

めです。本システムの構築以前は、MySQL を使用したマ30qps くらい、データ量は全体で約 60GB となり、使いたいサービスごとにデータベースを払い出しして使ってスタ / スレーブ構成のデータベースシステムを利用していましたが、今回サービスごとに専用の MySQL を構築するいます。ひとつひとつのインスタンスは 10GB 程度ですが、HAProxy

サービスごとに使われ方は異なります。のではなく、運用管理の効率化や構築コストの削減のたMariaDB は 10.1 系を使用、ノード数はマスタ 3 台で、そめデータベースを提供する基盤をひとつ用意しその中かのうちの 1 台にバックアップ用のスレーブ 1 台をぶら下ら新規サービスに必要な容量を払い出していくという方針を取ることになりました。

read&write

read&write

read&write

その際にいくつかの方法（NoSQL, Oracle など）を検討しげています。スレーブはバックアップ目的です。また、マスタサーバの前段に HAProxy があります。Galera
Cluster のおかげで全ノードに対し read と write が可能なましたが、最終的に「MySQL との互換性」「マスタ / スレーマスタブ構成ではない点」「ダウンタイムが少ない」「導入コスマスタマスタ

ので、HAProxy で read と write の両方を全ノードに分散させるマルチマスタ構成にしています。サーバは全て物理ト」などの面から MariaDB Galera Cluster の導入を決定しました。また、今までは自社内で運用保守を行ってきたGalera Clusterのですが、基盤化に伴いより一層安定したシステム稼動を目指したいという考えの下、MariaDB 社の公式サポースレーブトが付随した MariaDB Enterprise Cluster※1 を利用するに至りました。

サーバ、ディスクは SSD。ただし、特別スペックが高いわけではなく、汎用的なサーバとなっています。

開発体制

基盤システム全体での開発期間は 4 ヶ月程度です。そのうち構築にかかった期間は検証なども含め 1 ヶ月程度でスマートスタイル社から購入した理由としては、提案を受けた際にエンジニアの方から直接詳しい技術的な要素

本システムは、当社の各サービスのデータベースの集約まで聞くことができたので、今後のやりとりもスムーズ化を目的として新しく構築した新データベースシステムに進めることができると感じたからです。

基盤となります。

株式会社スマートスタイル
TEL : 0120-936-088 MAIL : info@s-style.co.jp

す。それぞれデータベースに関連する業務に就いていたメンバー 5 人の体制で行いましたが、いわゆる DB 専門の「スペシャリスト」はいませんでした。

© 2017 Smart Style Co.,Ltd.

MariaDB Galera Cluster でマイクロサービス化に対応

導入手順

MariaDB Galera Cluster の導入に関しては yum でインス高可用性の実現と運用コストの削減に成功いました。しかし、新しく構築した本システムではMariaDB Galera Cluster を用いたマルチマスタ構成を採システムを組んでいました。Galera のマルチマスタ構成替えるだけで済むため、ダウンタイムはほぼなくなりまたが、ノード間の同期の部分で時折データのズレが発生トールを行いました。手順は MariaDB 社が公開している 用しているので、問題発生時には参照先のノードを切り公式マニュアルを参考にしましたが、設定なども含め簡単に出来たので、特に困ったことはありませんでした。
HAProxy については、以前から他のシステムでは利用していたのですが、私達のチームで扱うシステムとしてはGalera Cluster に併せて初めて導入する運びとなりましした。
運用に関しては、今のところ安定稼働していて、特に不具合は発生していません。今回の新システムから自動構ログインして直接コマンドを実行して…、などの作業も勿論ですが、Galera 特有のオプション（wsrep̲... 変数） 減り運用もかなり簡略化できました。また、Galeraも新しく監視対象としました。

Cluster では RSU（Rolling Schema Upgrade）※2 が可能なのでこれまで困難だった「マスタ」のメンテナンスもメリットにすれば、このような問題が発生しないと思っていまし
することがあり、やはりレプリケーションの遅延には気を付ける必要があると考えています。

運用面た。また、導入後の DB 監視については、「Zabbix」を使 築系のスクリプトを導入したこともあり、DB サーバに用しています。サーバリソースや MySQL ステータスはを参照することができないので、その部分に気をつけて容易になりました。DB のメンテナンスにかかるコスト注意した点

データの書き込み（更新クエリ）の際に、CPU の iowaitが発生することがありました。いくつかパラメータを調整することで対処することはできたのですが、その後もディスク I/O の負荷が高くなることがあるので、普段から注意して I/O の状況を見るようにしています。特に、本システムの新しい利用申請があった時は、更新クエリや手間を省くという面でも大きなメリットだと思います。
（Write）の qps をしっかり確認しています。参照クエリ
導入時（Read）に関しては qps ベースでは特に注意することはMySQL からの移行に関しては、ほとんどのパラメータが サポート同じでとてもスムーズに行うことができました。アプリ 本システムの構築時や運用の際に MariaDB 社のサポート ないのですが、レスポンスタイムに幅がある時は、調整を利用する機会が幾度かあったのですが、レスポンスもに関しても特に修正の必要がなく、設定ファイル早く回答内容もしっかりしており満足できるものでした。

（my.cnf）も流用することができたので、MariaDB は

具体的には、構築時にエラーが起こった際の原因特定（原MySQL に近しいものだと感じました。

因はバグでした）や、バックアップに関する戦略、ロー性能面
以前のマスタ / スレーブ構成のものであればサーバが高負荷となりマスタがダウンした際、フェイルオーバーに1 時間ほど時間がかかり、長いダウンタイムが発生していました。しかし、新しく構築した本システムではMariaDB Galera Cluster を用いたマルチマスタ構成を採用しているので、問題発生時には参照先のノードを切り替えるだけで済むため、ダウンタイムはほぼなくなりました。

リングアップデートに関する質問など幅広く対応してもらうことができ非常に助かりました。

することもあります。

全体を通しての感想

全体を通して運用面では人員コストも含め改善することができたので、MariaDB Galera Cluster を導入して良かったと感じています。また、新システムを使用して約 1 年経ちましたが、大きな問題もなく安定して運用することデメリット

本システムは新規サービスに対する新しいデータベース基盤のため、以前のデータベース環境との比較は難しいですが、クラスタという意味で比較すると、Galera 用のができています。今後もサービス向上のため、より高いパフォーマンスと可用性を求めシステムの改善を行っていきたいと考えております。

クライアントがないので HAProxy 等のプロキシを挟む必 ※1 MariaDB Enterprise Cluster性能面
以前のマスタ / スレーブ構成のものであればサーバが高負荷となりマスタがダウンした際、フェイルオーバーに1 時間ほど時間がかかり、長いダウンタイムが発生してMariaDB 社が提供する MariaDB Galera Cluster の公式サポート要があることが気になりました。

また、レプリケーション遅延が依然として発生する点はデメリットと感じています。以前のマスタ / スレーブ構
成では、レプリケーション遅延が起こったときにデータ※2 Rolling Schema Upgrade

1 ノードずつクラスタから切り離して、テーブルのメンテナンス（DDL）やバージョンアップを実施する方法。ノードを切り離している間も、クラスタに残ったノードでサービスが継続可能。

お客様プロフィール
株式会社ドワンゴ
URL: http://dwango.co.jp

住所: 〒104-0061

事業内容: ネットワークエンタテインメントコンテンツ及びシステムの企画 開発

東京都中央区銀座 4-12-15 歌舞伎座タワー

運用、サポート、コンサルティング

関連プロダクトGalera Cluster・ 「完全同期レプリケーション」を実現する、オープンソースのクラスタリングソフトウェア
・・

全ノードが「マスタ」となり、更新・参照の受付が可能（3 ノード以上の構成を推奨）

データベースとしての基本機能は MySQL と同じ（ストレージエンジンは InnoDB のみ）※ MariaDB Galera Cluster とは、「Galera Cluster」をベースとし商用環境での利用を想定した MariaDB 独自のクラスタリング製品

株式会社スマートスタイル
TEL : 0120-936-088 MAIL : info@s-style.co.jp© 2017 Smart Style Co.,Ltd.