zak blog

以前に書いた、MySQL Clsuterを使ったシステム本運用開始直後のログから2年近くが経過しました。ちょうどいい機会なので、その後の運用を踏まえての感想と、今後の展開について記録を残します。現時点で秘密でない事項についてのみ書きます。


１．SunからOracleへ

知っての通り、MySQLはSunを経てOracleの所有物になりました。
気がついてみるとOSSの主要なデータベース技術のうち、Berkeley DB、InnoDB、MySQLがOracleになってしまいました。

（よかったこと）
GPLのデュアルライセンスは今のところ守られています。そのためMySQLにお金を払ってくれるユーザは、今まで通り限られたままで財政的には厳しいはずなんですが、今のところOracleはMySQLに対してコミットを守っているようです。特に変わったところとして、「リリースのスケジュールが守られるようになった」、「GA版のソフトウェア品質を高いものにするためによりコストをかけるようになった」、「リファクタリングを積極的に展開している」というような話を、しばしば聞く機会が多くなりました。

（よくなかったこと）
僕達のようなユーザ側にしてみると契約絡みが面倒になった以外では良くなかったことというのはありませんでした。とはいえ、Oracleと言う会社はそういうことをやって大金を稼いでいるわけで、商品・役務の売り方と、契約には個人的には興味深いです。


２．MySQL Clusterのバージョンについて

導入時には7.0.8aを使用し、当時はまだ7.1.xはGAになっていなかったわけですが。２年を経た現在においては２つともGAになっています（7.0.28、7.1.17が最新）。community版では7.0.xの積極的な配布は行わず、最新版は提供されていないようです。


品質としてはかなり安定的であるように感じます。バージョンアップ不可避な事象に当たったのはこの２年で１回で、データが壊れる、不整合が生じるといったようなデータベースとして最低限守らなければならないラインで疑義が生じた事はありませんでした。ただ、コンサルタント、サポートも知らなかった隠れた仕様、性能限界、その裏にある設計思想が導入後に明らかになったことは残念でした。


7.0.x系と7.1.x系はEOLのスケジュールが同時タイミングに設定されており、今すぐ新規構築するのであれば、7.1.x系(7.1.17)になるでしょうし、既存の7.0.x系のシステムが動いているのであれば、7.0.28になるでしょう。
ただ、噂では7.0.xの最新版には7.1.xの新機能がバックポートされているため、完全なメンテナンスリリースとも言い難いという話もあるようです。

本当はバージョンアップはなるべく近いバージョンで細かく実施することが、継続的デリバリ(CD)の観点からは必須なのですが、現実には、商用環境において、DBのバージョンアップは、相当難しく、セットアップした使ったバージョンを使い続ける傾向があるため、バージョンの選択は慎重にする必要があります。

何故バージョンを上げないかというと、業務システムのような特殊なアプリでは発行されるクエリは一定のサイクル（時間、日、週、月、年）で似ているため、そうやって一回商用環境で業務を遂行したこと自体が、（DBを含む）システムが枯れた、と認識されるからなのです。このため、逆にDBのバージョンアップとは、それが故の問題が発生する可能性が否定出来ないリスクの高い行為と考えられ、業務が全部問題なく遂行できるだけの担保が求められてしまいます。（※もっとも自社サービスであるならば、状況は違うかもしれません）。

これに答えるための方策として、まだ、僕自身うまい方法を考えついていないのですが、全く同じデータをコピーした新環境に全く同様にクエリを旧環境と新環境の両方にミラーして投げ続けて検証する、といったことができないかな、と考えています（RBRミラーリングではデータはコピーされますが、データベースへのクエリを再現することはできないですし）。


３．初めてMySQL CLusterの導入を考える皆さんへのアドバイス

MySQL Clusterに求める機能として、【高速な読み書き】、【Active/Active構成の高可用性システム】のどちらかに大きなメリットを感じないのであれば、採用を見送ることを考えるべきでしょう。特に、今はSSDという選択肢もありますから、まずはそれで十分か、不足があるかの観点で考えてみてはいかがでしょうか。

以下には、MySQL Cluster導入時の検討事項について導入後～２年間の運用を振り返って記載します。

・MySQL Clusterの皮を被ってはいるが、完全ではない。できることが、できなかったりするので、差違について十分に調査・見当すること。そのままInnoDBがオンメモリになったつもりで使うと、GCP Stopが発生する。

・高速な読み書きができるのは、基本的に主キー（プライマリキー）に帰着できるケースのみ。インデックスを使ったアクセスは性能上の限界値が低い。

・JOINは使えるがパフォーマンスが出ない（開発中の7.2のAQLで改善の見込みあり）。

・ユニークインデックスは主キーに次いで高速なアクセスを実現するけれども、特別なサポートテーブルを内部に生成するため、それが故の制約が存在する。

・ストレージエンジンが異なるテーブル通したトランザクションを張ることはやめるべき(InnoDBとNDBなど、分離レベルも異なるし、出来ないと考えるべき）。

・ここで言うところの高可用性は、Active-Active構成で、SPOF無しの構成を本気で組む前提がある場合で、そうでないならば、無理にMySQL Clusterではなく、通常版のMySQLを使用することを勧める。


最初に書いたとおり、MySQL Clusterと通常版のMySQLは似て非なるものです。普通のMySQLの知識は30%くらいしか通用しないので注意して下さい。できれば、そばに詳しい人を置くか、最低でもサポート契約が無いと、プロダクション環境で使用するのは厳しいと思います。



４．今後の展開に期待すること

昨年ぐらいにNoSQLがもてはやされましたが、MySQL ClusterのベースとなっているNDBはもともとそのNoSQLで、NoSQLは速いけれど、スキーマを投入してデータ抽出をSQL構文でやりたいというのがそのモチベーションなわけで、ある意味、時代を先取りした部分もあると考えています。

SSDが安価になり、性能観点で、無理にインメモリDBにこだわる時代では無くなりましたが、超高可用性と、比較的容易にスケールアウト可能なアーキテクチャーであることにはまだまだ魅力的な所があります。僕は試していませんが、NDB Disk storageも（スピードは出ませんが）安定して動いているという噂です。

今後もMySQL Clusterが主要な柱となるべく開発リソースが投入され続けるといいですね。