高可用性DBのフロントエンドにMaxScaleを使ってみた
老朽化した自宅サーバとサービス終了したCloudGarageからの引越し先として、
新サーバの構築を進めているのだが、内部データベースの構成をどうするかが課題だった。
当初、MariaDB Galera Clusterを利用しようと考えていたが、
安定稼働に必要なメモリ容量と、スプリットブレイン対策の奇数台数運用がネックだった。
また、DBが完全停止した時のサービス再起動にも細かい手順が必要だったり、
DBを本職としていない筆者には難易度が高すぎるのでお蔵入りになってしまった。
………
そうなると、レプリケーション構成が候補にあがるのだが、
こっちはこっちで、Master消失時にSlaveをMasterに自動昇格する方法が問題になった。
スクリプトを自作しても良かったが、日々のメンテナンスが辛くなりそうなので没に。
他に使えそうな物がないか調査した所、
MaxScaleを使うとクエリのロードバランスと自動昇格が出来る事が判明。
何処かのパブリッククラウド基盤にも採用していた筈で、稼働実績がありそうなのと、
MariaDB Galera Clusterの構成にMaxScaleも組み込まれている事が多いので、
今後の技術検証にも使えると判断し自鯖バックエンドDBに採用する事にした。
- 構築メモ ＞ MaxScale
概要図は次の通り。フロントエンドにMaxScaleを動かして、
バックエンドのMariaDBにクエリを分散させる構成にした。
VirtualIPは慣れたVRRPを使いたかったので、KeepaliveでVRRP v3を喋る事にした。
典型的な構成なので枯れていると言えばそれまでだが、
バックエンドのMariaDBを自動で昇格・降格出来るのと、
サービスの接続先がMaxScaleに集約出来るので、
MaxScaleが落ちない限りはセッションが切れず、可用性がかなり高くなった。
実際にSELECTを送りながらバックエンドのMariaDBをダウンさせてみたが、
クエリ停止せずに処理を継続する事が出来た。
流石に、UPDATE系はフェールオーバーするまで通らない事があるが、
3秒程度で収束出来るので自鯖レベルならば大満足の結果に。
チューニングすれば更に可用性を上げられそうだが、
MaxScale本体に負荷がかかるのでバランスを見極める必要がありそう。
………
流石に、エンタープライズ環境だとこんな簡単には行かないが、
アップデート系をクラスタDB、参照系をリードレプリカに分散させれば、
高可用性と負荷分散を両立する事が出来る。
DBクラウド使えばそれまでだが、バックエンドの仕組みを把握するとアプリ構成も最適化出来るのと、
勉強の領域としてデータベースはやる事が多いので、今後もアップグレードしながらテストしようと思う。
