MySQL Clusterその後（これから使ってみようと思っているみんなに） ― 2011/11/24 04:20
以前に書いた、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が主要な柱となるべく開発リソースが投入され続けるといいですね。
１．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が主要な柱となるべく開発リソースが投入され続けるといいですね。
事象→事故→アクション会議 ― 2010/08/16 00:14
最近、、事故だかとか、事象だとか、アクション会議にふれ合う機会が多いため、それぞれについて改めて考えてみた。
「事象（インシデント）」
システムを構成する要素において何らかのバグ、障害、その他人為ミスが発生した状態。
サービスに実害は出ていない（その時点では確認出来てない状況を含む）ところまでが事象の境界で、一旦外部に実害が出てしまうとそれは、事故に昇格する。
「事故（アクシデント）」
前段階として事象として認識されている事もあるし、突然発生することもあるが、実際にユーザに不利益、迷惑をかけるような障害を発生させてしまっている状況全体を指して事故と呼ぶことが多い。大抵は発生してしまった事態（事象）を分析する過程で、これは事故だな、と判定される。
「アクション会議」
事故内容については、ステークホールダー間において速やかに情報展開、共有が行われるが、それらを踏まえた上で当事者が集合して、これまでのアクションを評価し、次のアクションプランを検討する。だいたい日中に事故が発生したら、その日の夕方。夕方～深夜に発生したのであれば、翌朝一で開催される。会議の場においては次の２点が追求される結構厳しい会。
・事故対応の状況（概要影響範囲、顧客対応状況、現在のリカバリーの状況、原因の調査）
・再発防止策の検討（プログラムのバグなのか、設計上の考慮漏れなのか、運用上の人為ミスなのか、あるいはそれ以外なのか）
アクション会議は必ずしも一カ所で行われているわけではなく、大きな組織では、その結果を踏まえて別の上位レイヤーでのアクション会議へと、エスカレーションが行われる。
「事象（インシデント）」
システムを構成する要素において何らかのバグ、障害、その他人為ミスが発生した状態。
サービスに実害は出ていない（その時点では確認出来てない状況を含む）ところまでが事象の境界で、一旦外部に実害が出てしまうとそれは、事故に昇格する。
「事故（アクシデント）」
前段階として事象として認識されている事もあるし、突然発生することもあるが、実際にユーザに不利益、迷惑をかけるような障害を発生させてしまっている状況全体を指して事故と呼ぶことが多い。大抵は発生してしまった事態（事象）を分析する過程で、これは事故だな、と判定される。
「アクション会議」
事故内容については、ステークホールダー間において速やかに情報展開、共有が行われるが、それらを踏まえた上で当事者が集合して、これまでのアクションを評価し、次のアクションプランを検討する。だいたい日中に事故が発生したら、その日の夕方。夕方～深夜に発生したのであれば、翌朝一で開催される。会議の場においては次の２点が追求される結構厳しい会。
・事故対応の状況（概要影響範囲、顧客対応状況、現在のリカバリーの状況、原因の調査）
・再発防止策の検討（プログラムのバグなのか、設計上の考慮漏れなのか、運用上の人為ミスなのか、あるいはそれ以外なのか）
アクション会議は必ずしも一カ所で行われているわけではなく、大きな組織では、その結果を踏まえて別の上位レイヤーでのアクション会議へと、エスカレーションが行われる。
商用サポート・コンサル契約の組合せ問題 ― 2010/04/11 17:59
GPLなどで無料でも使えるソフトウェアについて、
商用サポート、コンサルティング契約はどのような意味があるのか？という疑問についての一つの解答と言えそうな事例を見たのでメモ。
【１．いわゆる年間サブスクリプション（商用ライセンス）を購入】商用サポート、コンサルティング契約はどのような意味があるのか？という疑問についての一つの解答と言えそうな事例を見たのでメモ。
・ライセンス購入者向けのWebサイトのアカウントが発行される
・購入者だけに提供されるツールが使えるようになる
・GPL版よりも高い頻度でリリースされる、商用版バイナリを入手可能になる
・テクニカルサポートを受けることができるようになる（とにかく一定の時間以内で解答してくれる、場合によってはリモートログイン作業も有り）。
・表面的な話だけでなく、製品のソースコードレベルでも原因を調査してくれ、場合によって開発チームにBug/要望として投げてくれる。
【２．コンサルティング契約を結ぶ】
・商用ライセンス（サポート有り）の存在を前提として、
・専任のコンサルタントが訪問。いろいろ個別の問題について相談に乗ってくれる
・実例に対応したチューニング、設定をし、場合によっては製品のソースコードレベルでの修正まで行い、開発チームにパッチを送ってくれる
・緊急時には電話での連絡・相談も可能
１，２どちらのサービスでも、製品ソースコードレベルでの調査を（一定の期限内に）してくれるところが、わざわざ大金を払う意味が持つところである。
コンサルタント談として、テクニカルサポートとの性格の違いは、
・問題発生時のQA→テクニカルサポートが得意
・パフォーマンス・チューニング→コンサルタントが得意
ということらしい。
しかしながら、
悲しいかな、開発チームは国外。国内法人のサポートスタッフ、コンサルタントからの発言力はそれほど大きなものではなく、要望、パッチを出してもなかなか取り込んでくれない（軽く数ヶ月は放置状態）。彼らに出来るのはとりあえずの代替手段の提案のみであった。
ここまで来て重要な働きをしてくれたのが、【営業責任者】だった。彼らは技術的な話は分からないかもしれないが、案件の状態、深刻度については敏感だ。結局、コンサルタントがパッチを出して数ヶ月放置されたものが、エスカレーション後は数日で対応が決定されたのである。こういうスピード感は重要で、それが出来るから会社として回っているところでもあるのだろう。
とは言え、今回の話の対比で、コンサルタントに非があるとも思わない。発言力がやっぱり無い、という事実はあるけれども、技術的にはちゃんと仕事をした（数ヶ月前のパッチ）結果があるから、営業責任者が決断、指令を出すことができたのだ。ただ単に顧客が怒っている、と営業サイドで騒いだところで、技術的な裏付けが無ければ、（問題の調査、解決法の検討で）やっぱり時間が掛かったことだろう。
商用サポート、コンサルタント契約の裏には営業がいつもいるけれど、これまで僕はあまりその重要性を考えていなかった。でも、やっぱり出るべき所はあるのであり、そこには営業でこそできる仕事があるのである。
・購入者だけに提供されるツールが使えるようになる
・GPL版よりも高い頻度でリリースされる、商用版バイナリを入手可能になる
・テクニカルサポートを受けることができるようになる（とにかく一定の時間以内で解答してくれる、場合によってはリモートログイン作業も有り）。
・表面的な話だけでなく、製品のソースコードレベルでも原因を調査してくれ、場合によって開発チームにBug/要望として投げてくれる。
【２．コンサルティング契約を結ぶ】
・商用ライセンス（サポート有り）の存在を前提として、
・専任のコンサルタントが訪問。いろいろ個別の問題について相談に乗ってくれる
・実例に対応したチューニング、設定をし、場合によっては製品のソースコードレベルでの修正まで行い、開発チームにパッチを送ってくれる
・緊急時には電話での連絡・相談も可能
１，２どちらのサービスでも、製品ソースコードレベルでの調査を（一定の期限内に）してくれるところが、わざわざ大金を払う意味が持つところである。
コンサルタント談として、テクニカルサポートとの性格の違いは、
・問題発生時のQA→テクニカルサポートが得意
・パフォーマンス・チューニング→コンサルタントが得意
ということらしい。
しかしながら、
悲しいかな、開発チームは国外。国内法人のサポートスタッフ、コンサルタントからの発言力はそれほど大きなものではなく、要望、パッチを出してもなかなか取り込んでくれない（軽く数ヶ月は放置状態）。彼らに出来るのはとりあえずの代替手段の提案のみであった。
ここまで来て重要な働きをしてくれたのが、【営業責任者】だった。彼らは技術的な話は分からないかもしれないが、案件の状態、深刻度については敏感だ。結局、コンサルタントがパッチを出して数ヶ月放置されたものが、エスカレーション後は数日で対応が決定されたのである。こういうスピード感は重要で、それが出来るから会社として回っているところでもあるのだろう。
とは言え、今回の話の対比で、コンサルタントに非があるとも思わない。発言力がやっぱり無い、という事実はあるけれども、技術的にはちゃんと仕事をした（数ヶ月前のパッチ）結果があるから、営業責任者が決断、指令を出すことができたのだ。ただ単に顧客が怒っている、と営業サイドで騒いだところで、技術的な裏付けが無ければ、（問題の調査、解決法の検討で）やっぱり時間が掛かったことだろう。
商用サポート、コンサルタント契約の裏には営業がいつもいるけれど、これまで僕はあまりその重要性を考えていなかった。でも、やっぱり出るべき所はあるのであり、そこには営業でこそできる仕事があるのである。
